09/11/13 23:52:51 f6I0Q3Z0
>>510
レスありがとうございます
この例はあぼーんするが
[PC1:Win7/NTFS] <---iSCSI---> [NAS鯖:Linux/EXT3] <---iSCSI---> [PC2:Win7/NTFS]
この例は大丈夫ってことですね
[PC1:Win7/NTFS] <---Samba--->
[PC3:XP/NTFS] <---Samba---> [NAS鯖:Linux/EXT3] <---iSCSI---> [PC2:Win7/NTFS]
[PC4:XP/NTFS] <---Samba--->
512:login:Penguin
09/11/14 00:21:38 +VAB2Vbe
どっちがどっちだ？
iSCSIはブロックデバイス、sambaはファイルシステム
ブロックデバイス(HDD)を適当なファイルシステムでフォーマットして
sambaで共有させれば、結果的にiSCSIの中にあるファイルを共有したことになる。
iSCSIのイメージをsambaで共有しても、HDDイメージファイルを共有したことにしかならない。
513:login:Penguin
09/11/14 01:43:55 VYhG1dBU
>>512
NAS鯖
・24h常時稼動
・iSCSI Target（物理ストレージ側）
・Sambaファイル共有サーバー
PC1～4
・電源ON/OFFのある完全なクライアントPC
・iSCSI Initiator
・Windowsファイル共有クライアント（Windowsファイル共有サーバーの設定はせず）
他PCがマウント中のHDDイメージの中身を、NAS鯖自信ならば読み書きできると勘違いしました
あくまでHDDイメージなんですね
514:login:Penguin
09/11/14 01:49:18 VYhG1dBU
>>511の上の例では、
NAS鯖内に複数の異なるHDDイメージを作成して、
それぞれマウントすればあぼーんすることはないが、
同一のHDDイメージをマウントするとあぼーんするわけですね
>>511の下の例では
PC2がマウント中のHDDイメージを、NAS鯖がマウントするとあぼーんするから、
PC2をWindowsファイル共有サーバーにする方法しかないと理解しました
経路も迂回するし、PC2が電源OFFの時は読み書きできずとうまくいかないもんですね
515:login:Penguin
09/11/14 02:28:02 BeeV1uH3
クラスタファイルシステムでも使えばよろし。
516:login:Penguin
09/11/14 11:14:06 uNeLWaHl
クラスタファイルシステム何種類かあるけど一番有力なのはどれだろう
Windowsでも一つくらいサポートしてもいいような
517:login:Penguin
09/11/15 15:16:24 ePzVhxKF
iSCSIをocfs2で使うのと、
iSCSIをサーバのどれかがNASになってNFS/SMBで共有するのは
どちらが性能いいのかな。Linuxのみで使うとして。
518:login:Penguin
09/11/17 06:14:39 a96ySKqK
ん？HDDイメージの場合、Targetとしてマウント中でも
HDDイメージそのものはそれがおいてある物理HDD上で
コピーしたりすることはできるよね？
519:login:Penguin
09/11/17 06:45:30 Pxf5jnD2
できるけど・・・・
イメージの前半と後半でコピーした時間が違うなんてことになるぜ
>>517
ocfs2は、CPU負荷が高くなると、同期・調停信号が遅れて、
ファイル壊れるとか消えるとか色々変な事が起きる。
ので、smbで済むような用途ならsmbの方が良い。
タイムスタンプの精度が必要とか、
inodeの値まで揃える必要があるような場合だとocfs2
520:login:Penguin
09/11/17 19:05:11 1HFYnidh
>>516
Windowsで使えるクラスタファイルシステムだとOCFSくらいじゃね？
521:login:Penguin
09/11/18 00:58:59 rJYbboFq
認識があってるかも分からんが
linuxのkernel-stageに /fs/dst つ～ブロックデバイスのネットワークプロトコルが入ってた
nfsの替わりもあってpohmelfsというらしい
5年後に名前が残ってるかさえわからんが…
522:login:Penguin
09/11/18 07:54:19 FFt/LoHq
>>518
それがやりたい人はSolaris使ってZFS pool上にiSCSI targetを構築しましょう。
523:login:Penguin
09/12/09 13:10:23 9E8Tibsd
LVMじゃ駄目なの？
524:login:Penguin
09/12/09 16:29:39 mfbKKGPQ
ﾊｧ?
525:login:Penguin
09/12/09 20:11:48 6+62WSPY
>>523
とりあえず、SolarisのZFS + iSCSIがどう動作しているのか
お勉強してきた方がいい
526:login:Penguin
10/01/12 16:36:58 w40rcvma
ターゲットの0.4.16と1.4.19を比べて
特に高負荷時のパフォーマンス上がってますか？
527:login:Penguin
10/01/23 18:41:25 QbcguuY2
CentOS5.4(2.6.18-164.11.1.el5) + iet(1.4.19)
でターゲット構築してるんですがローカルで
iscsiam -m discovery -t sendtargets -p hogehoge
とやってもタイムアウトしてしまって、ターゲット名が表示
されません。
iscsiadm: socket 3 header read timed out
iscsiadm: Login I/O error, failed to receive a PDU
とあるので、iscsi-targetが接続要求に反応していないのではないかと
思うのです。ietd.confはデフォルトのLun 0 Path=の部分のみ書き換えて
後はそのままです。
#cat /proc/net/iet/session
tid:1 name:iqn.2001-04.com.example:storage.disk2.sys1.xyz
#cat /proc/net/iet/volume
tid:1 name:iqn.2001-04.com.example:storage.disk2.sys1.xyz
lun:0 state:0 iotype:fileio iomode:wt path:/dev/VG00/test
と出るので、IETの起動も一見正常に行われているように見えます。
ただ、この状態でservice iscsi-target stopとやると正常に停止できず、
psで見るとietadm --op deleteがうまくいっていなくて止まっているようです。
何かヒントだけでも頂けませんでしょうか？
528:login:Penguin
10/01/25 19:49:44 aSKgaJKw
3260番ポートを開けてない、とか?
ところで、単なる好奇心ですが
CentOS標準の tgtd ではなく
ietd を選んだのは何故でしょう?
529:login:Penguin
10/01/25 20:56:40 hFoz9GXq
CDNって分散fsって言っていい物?
530:login:Penguin
10/01/26 01:12:07 a1BNkstq
>>528
iptablesではローカルホスト、ローカルネットワークからは全部開けてて、
一応telnetで接続するとコネクションまでは出来てるっぽいです。
わざわざietを使う理由ですけど、クライアントでMacを使ってて、
GlobalSAN iSCSI initiatorとの相性が悪くてマウントは出来るけど
書き込みが出来ないんですね。Windowsでは普通に使えるんですけど。
で、仕方なくietを使おうとしている次第でした。
まぁ、バックアップ用途なので最悪NetatalkかSAMBAで代替とします。
531:login:Penguin
10/02/09 00:24:52 1/aTaa6E
VMware vSphere 4を試す【第三回】
iSCSIストレージをESXiサーバーに接続する
URLﾘﾝｸ(enterprise.watch.impress.co.jp)
532:login:Penguin
10/02/18 18:12:57 S4o+jKbV
tgtd でターゲットを作成する際、
過去に使った(既に消された) tid ってのは再利用不能なんでしょうか?
tgtadm --lld iscsi -m target -o show で何も表示されない
(ターゲットが一つも存在しない)状態でも
--tid=0 などと既に削除した ID を指定して新規作成しようとすると
tgtadm: 'tid' option is necessary と断られてしまいます。
もちろんまだ一度も使ってない ID を指定すれば作成可能なのですが、
これでは「どこまで使ったか」を別途記録しておかないといけないことになり
テストで作成/削除を繰り返した後など、非常に不便です。
これは「そういうもの」なんでしょうか?
また「既に使ったもの」はどこを見れば確認できるのでしょう?
使用 OSは CentOS 5.4です。
533:login:Penguin
10/02/18 21:36:17 ZSkw0RMa
ietdとscstは使ったけどietdは使ったこと無いな
534:login:Penguin
10/02/25 20:36:04 xfOpcbwI
kernel-2.6.33 で iscsitargetを利用したいのですがpatchなどありましたら教えてください
535:login:Penguin
10/02/26 13:02:46 3V2vXHVf
2.6.14以降なら普通に使えると思うが
何かパッチが必要なの?
536:login:Penguin
10/02/26 21:08:41 bdyWSyHq
ietdの場合は一応モジュール作らないとならないんじゃなかったかな
パッチが大量に当たっているディストリのkernelだとconflictすることもあるだろう。
そういう場合はディストリ配布のパッケージ使えばいいわけだけど。
537:login:Penguin
10/03/03 01:38:04 AYjFbTBQ
iscsitarget-1.4.19で、writeよりreadの方が圧倒的に遅いんだけど、こういうもの？
イメージではwriteの方が遅くなるよな気がしてたんだけどなぁ。
fileioでもblockioでも同じ結果。
>>534
RH系なら、rpmbuildでkmod出来るから、それを先にｲﾝｽｺすればおｋ
538:login:Penguin
10/03/03 01:57:01 6BwB45aL
以前動かしていたietdでは、read/writeによる速度差は感じなかった。
どちらかのNICが送信に弱い/受信に弱いとか、なんかあるんじゃね？
そもそも、ietdも動作おかしい点がいくつもあるけど。
539:login:Penguin
10/03/06 04:01:44 r/V4APzv
NICそのものかドライバが原因てのはあるかもね。
iperfだとワイヤースピード出るのに、
iometerでブロック流すとリードだけ安定しないってのは遭遇したことある。
その時はドライバ変えたら改善した。
とりあえずオフロード無効にしてみ？
540:login:Penguin
10/03/06 12:34:55 g68idANf
>>538-539
tgtdにしてみたら嘘みたいに解消した…。
負荷的にもtgtdの方がかなり有利みたい。
Cent雄5.4 x86_64環境。
まだ詳しく検証してないから、はっきりしたことは分からんけど、
NICドライバ周りも含めて色々調べてみる予定。
今のところ、
＞ そもそも、ietdも動作おかしい点がいくつもあるけど。
これには同意せざるを得ない感じ。
541:login:Penguin
10/03/26 00:27:05 H69kQD6z
ho
542:login:Penguin
10/04/08 00:57:57 I4A2fDWU
ze
543:login:Penguin
10/04/15 01:57:24 5j98vEiw
Hyper-V2.0 Live-Migration 用に、WSFC構築時のiSCSIとして、
ietdとtgtdを使ってみました。
すったもんだあって、結局・・・OpenSolarisのZFSでiSCSI-Targetを
使って、何となくWSFCを構成していますが、クラスタ検証テストはNG、
でも、Hyper-Vのクイックマイグレーション程度なら使えるっぽいです。
最初、dladmとか使ってNICチーミングしていた時は、ごまかしごまかしで
クラスタ検証テストも警告状態でスルーしたのですが、MPIOに切り替えると
クラスタ検証テストは完全にNGで終了しました。（涙
なお、NICはIntel系×４ポート、Mem16GB、Xeon3440、SATA1TB×４：Raid-5
構成の同一ハード仕様サーバを複数台使って検証しました。
＃金出して、StoregeServerStandard以上を使えって事でしょうか？
まぁ、・・・ご参考まで。
544:527
10/05/12 23:33:11 5KXCICkg
超亀報告ですが、ietdのバグだったようで
正常に動作してなかったみたいです。1.4.20.1で
rpmパッケージを作成してインストールしてみたら、
あっさりつながった…。
545:login:Penguin
10/05/28 03:30:19 t2OL57fu
IETでBlockSize使うとWindowsからまともに使えないな
546:545
10/06/06 19:41:12 083/OJg7
冤罪だった
WindowsもIETも悪くない
VirtualBoxだ
547:login:Penguin
10/06/07 16:10:36 uzQTf5Qz
乙