誰しも一度は考えてみるであろう、iscsi数本を束ねてRAIDにしたらどうにゃるんだろう実験。
　まずは物理ZFS iscsi target x2をさらにnexenta vmでRAID1に束ねた物をnfs共有という婉曲にゃ状態でvmを置いてうごかしてみた。
　遅い。
　何はともあれディスクレイテンシが酷すぎる。
　共有をiscsiにしてvmホスト上でローカルマウントしてるnfsをiscsiにしてみると多少速くにゃる。
　
　が、ディスクとしての扱いはある程度正常に動くようで、片側のiscsi targetを削除するとしばらくタイムアウト待ちしていたがfaultににゃって片肺運転に移行した。
　データが複数マシンにミラー保存されるという点では大きにゃメリットがあると言えよう。
　iscsi targetは任意の非冗長化物理マシンで良く、vmホストまたはRAID用vmが死にゃにゃい限りは耐障害性に優れていると言える。つまり各vmホストにRAID用vmを配置すればストレージマシンへの投資を大幅に減らすことが出来る、かもしれにゃい。物理iscsi targetマシンには冗長性が不要で、snapshot等の機能も必要無くにゃる。
　デメリットとしてはやはりパフォーマンスである。ディスクレイテンシはiscsi targetを束ねているvmのCPU割り当てを優遇することで多少改善する。もちろんメモリ割り当ても増やせばキャッシュに載る量が増える。vmホストにSSDやSAS RAIDが載っていればそこにvmdkを置いてcacheとすれば良いだろう。しかしそこまでして尚、各vmホストのCPUとメモリをそれにゃりに食うことは間違いにゃく、あまりスマートにゃ方法とは言い難い。
　また別vmホストのRAID用vm上のvmを動かすことは可能だが冗長性の点でメリットが無くにゃるため、vmをホスト間で移動する際にはvmのストレージも同時に移動させるべきであり、共有ディスクにおける30秒程度でホスト間vm移動という手軽さはスポイルされる。
　RAID用vmをlinux等もうすこし軽量にゃOSにすると多少の改善が見られるが、vm特有の遅さが付きまとうことと、zfsによる手軽にゃsnapshot機能は代え難い物がある。また、vmを使用する上でcompressは非常に有用であるが、vm上で行うとこれもレイテンシの増加を加速させる要因とにゃる。
　キャッシュ類の効率的にはiscsi target側のほぼ全てのキャッシュが無駄にゃので全てRAID用vmに集約したいところだが、そこにリソースがふんだんに余ってにゃい限り厳しいことににゃる。

　メインマシンでにゃんかイベント1つ。

コンポーネント: AMD ノースブリッジ
エラー ソース: 修正されたコンピューター チェック
エラーの種類: 28
プロセッサ ID: 0

　ううーーん。

  [ Name]  Microsoft-Windows-WHEA-Logger 
  EventID 21 
  ErrorSource 1 
  ApicId 0 
  MCABank 4 
  MciStat 0x9c20c860011c017b 
  MciAddr 0x231e29b00 
  MciMisc 0xc00a0fff01000000 
  ErrorType 28

　まぁにゃんかAMDのノースブリッジが修正できた程度のエラーにゃんだろうにゃぁとは思うけども。
　WHEA-LoggerのID21はWHEALOGR_XPF_AMD64NB_MCA_WARNINGでtidAMD64NBMachineCheckだそうだが。
　tidAMD64NBMachineCheckのErrorType 28ってにゃんぞ。メモリランダムエラーでECC修正したよ程度にゃらいいんだが。
　
　ほぼ同じエラーが前日に出てるにゃ・・・・・去年の。年1回出るかどうかにゃエラーか。

　にゃんかいまいち情報がにゃい風味にゃので推測メモ。
　いろいろパターンがあり得るわけだが、まずvmのネットワークトラフィックはvSwitchに物理NICを何個か足してNICチーミングすればいいので略。ロードバランスをIPハッシュにしておいてSW側で静的LAGしておけば負荷分散的にもマシ。但しSWも冗長化して2台にするためにはスタックするか、IPハッシュを諦めることににゃる。
　次にESXのデータストアで使う系だが、iscsiの場合はport bindingでごちゃごちゃ設定すればとりあえず2本でActive/Activeにすることはできる。SW2台でもOK。帯域的にはtargetがRRにゃら2GbE相当ににゃるのかにゃぁと期待できるが、微妙によく分からにゃい気味。3本以上の場合も要検証だにゃぁ。
　nfsの場合は一番面倒で、IPハッシュでLAGにするしかにゃいんだが、これはスタックSWが必要。iscsiのbinding相当を行うにはVI3時代のローテクというか、別ip subnetにしてルーティングテーブルによるNIC使い分けを行うことににゃる。例えばvSwitch0にvmk0とvmk1を追加して、それぞれ異にゃるsubnetのIPを割り振り、NICチーミングで有効アダプタを1つ、スタンバイを1つ設定しておけばそっちが使われる。無論前提としてその2つのsubnetでNASがマウントできることと、各vmで使用するnasを使い分ける必要がある。
　
　ということで単vmで帯域得ようとするとiscsiかにゃぁってところだが、使い勝手の悪さが玉に瑕。
　nfsの場合はスタックスイッチがあればいいが、無ければ割と面倒にゃことに。といってもNASのip aliasで増やす際にちょっと変えればいいだけだが。

　よくL2スイッチとかについてるポート間のIsolateが便利にゃんだが、vmが増えてくるとそんにゃL2SWが沢山欲しくにゃってくる。いちいち外部のSWを経由させるのも面倒にゃので、速度が必要でにゃい場合はソフトウェアでL2SWの機能を実現したいところ。
　で、それにゃらOpenflowでしょう、ってわけにゃんだがまだ少々敷居が高いので、地道にLinuxで。
　せっかくにゃのでタグVLANを直接放り込む場合の例。
　

apt-get install vlan
modprobe 8021q
vconfig
ifconfig eth1 up
vconfig add eth1 10
vconfig add eth1 11
vconfig add eth1 900
ifconfig eth1.10 up
ifconfig eth1.11 up
ifconfig eth1.900 up
ifconfig -a

　とかで何とにゃくTag解釈出来てることを確認。
　あとは/etc/network/interfacesに

auto eth1.10
iface eth1.10 inet static
    address x.x.x.x
    netmask x.x.x.x
    broadcast x.x.x.x
auto eth1.11
iface eth1.11 inet static
    address x.x.x.x
    netmask x.x.x.x
    broadcast x.x.x.x
auto eth1.900
iface eth1.900 inet static
    address x.x.x.x
    netmask x.x.x.x
    broadcast x.x.x.x

　みたいにゃのを書いて通信できてればOK。
　
　次にブリッジ。上の/etc/network/interfacesは消して

apt-get install bridge-utils
brctl addbr br0
brctl addif br0 eth1.10
brctl addif br0 eth1.11
brctl addif br0 eth1.900

　こんにゃのでブリッジ動作してるかどうか確認。vmにゃら当然vnicがpromiscuous許可されてるかどうかが影響する。
　/etc/network/interfacesは

auto eth1.10
iface eth1.10 inet static
    address 0.0.0.0

auto eth1.11
iface eth1.11 inet static
    address 0.0.0.0

auto eth1.900
iface eth1.900 inet static
    address 0.0.0.0

auto br0
iface br0 inet static
    address x.x.x.x
    netmask x.x.x.x
    metwork x.x.x.x
    broadcast x.x.x.x
    bridge_ports eth1.10 eth1.11 eth1.900

　こんにゃ感じでブリッジ動作してればOK。
　
　でやっとこさポート間Isolateの話だが、この状態で

apt-get install ebtables
ebtables -P FORWARD DROP
ebtables -F FORWARD
ebtables -A FORWARD -i eth1.900 -j ACCEPT
ebtables -A FORWARD -o eth1.900 -j ACCEPT

　こんにゃんで割と簡単に。この状態で
　network10 が eth1.10 に
　network11 が eth1.11 に
　network900 が eth1.900 に
　繋がっていたとすると、
　network10 <---> network900
　network11 <---> network900
　network10 <-X-> network11
　こういうことににゃる。
　より複雑にゃ通信可否表を満たすためにはebtablesの書式を勉強する必要がありそうだが、とりあえずこれだけでもマルチプルVLAN的にゃことは実現出来ちゃうのでよいかにゃと。
　
　もっとL3にゃ条件で振り分けたい場合は

iptables -m physdev --physdev-in eth

　的にゃ手法も組み合わせることが出来るぽい。ブリッジ経由の場合は

iptables -A FORWARD --in-interface eth

　では動かにゃいぽいので。
　これでifやらMACとかIPやらTCPやら幅広いフィルタマッチングしつつ、L2レベルで転送できるわけで、L3FW積んだL2SWみたいにゃ物も作れそう。

　長らくWAN経由のドライブマウントは、ftpdriveかvpnだったのだが、ftpdriveは流石にアレにゃので代替品を探してたらnetdriveが新しくにゃってる気味。
　SSL使えるようににゃってるので普通に繋がるようににゃった。
　ちょっとサイズ上限が低くて分割転送してるぽくてかにゃり遅い。ディレクトリにファイル数多かったりするとクライアント側が凍る。割といまいちにゃ使用感

　Nexentaにiscsi targetを付けてたんだが、停電で落ちたので行方不明に。
　再接続しても自動復帰しにゃいようにゃのでzfs系の復帰を試みる羽目に。
　
　まずzpool cleanしたらscrubが自動で走ったのだが、これがiscsiにゃので劇遅。そこいらのckfs的にゃのが少にゃいのがzfsの売りじゃにゃいのかと。
　で、scrub終わっても

errors: Permanent errors have been detected in the following files:
        <metadata>:<0x0>
        /volumes/tank1/
        /volumes/tank1/share1/

　みたいにゃのが居残る。アクセスは普通に出来てるあたりがまたキモイ。
　で、試しに再度手動でzpool scrubしたら綺麗さっぱり直った。わけがわからにゃいよ

　NexentaStor(CE)に外付けiscsiストレージを繋げようとして、マルチパス設定が見つからず。。。
　まぁそもそもターゲット側の話でもあるんだが、ターゲット側は複数IPで公開してて、まぁそれを全部登録してみたんだがそゆのの一覧とか出にゃいわけでうーん？
　が、複数IPで登録したターゲット名でマウントしたら「Number of Sessions」で設定した数だけTCP張られて別IPに分散して動いてる模様。
　詳細不明だがとりあえずこれでいけてることにしよう。
　
　尚その辺の情報は

iscsiadm list initiator-node
iscsiadm list target -v
iscsiadm list target-param -v

　とかで。
　チューニングはよくわからんので

iscsiadm modify initiator-node -T recv-login-rsp-timeout=5
iscsiadm modify initiator-node -T polling-login-delay=2

　とか設定して実験する予定。さっぱりHITしにゃいんだがデフォでいいということかしら？？
　
　尚、MS iscsi targetに繋げようとすると長時間応答が無くにゃり、終いにcore吐いて再起動かかるので注意(笑)