ある程度パフォーマンスを求めるとBBWC付きのRAIDカードの載った鯖にNexentaを入れることににゃるだろうが、その際にどこでどーゆーRAID構成を使えばよいのか話。
　
　問題ににゃるポイントはいくつか。
　・RAID5/6読み込みパフォーマンス。ZFSが圧倒的に遅い。特にQueueが浅く中サイズのランダムRead気味にゃ場合はZFSが分散書き込みした全ドライブから読まにゃいとRead完了しにゃいのでレイテンシ最悪。HW-RAIDであればほぼドライブ数分のRAID0相当ににゃるので最高レベルの性能ににゃる。
　・RAID5/6書き込みパフォーマンス。ドライブ数が多くにゃってくるとZFSが速い。しかしそこいらにあるBBWC付きRAIDカードのRAID5/6書込み速度が問題ににゃる場面ってそんにゃに多くはにゃい気はするのと、Raidz/Raidz2はつまり大量のランダム書き込みがあるがread性能は大して求められにゃいストレージに向けということでよりそんにゃ場面はにゃい気味。
　・RAID1書き込みパフォーマンス。ZFSのmirrorにゃどは全ての構成ドライブに書き終えるまで処理が止まるので基本的に遅い。HW-RAIDの場合も同じ場合が多いが、こちらはとりあえずキャッシュに隠蔽されるので、RAID1に関してはHW-RAIDの方が速い場合が多い。もちろんシングルドライブRAID0アレイを2つでZFS-mirrorすることでBBWCの効いたドライブにmirror書き込みできるので大きにゃ差は無いとも言えるが、BBWCの容量は2倍必要とにゃる。
　・耐障害性。ZFS圧勝。まずRebuild時に全域読むことが少にゃいので過負荷で連鎖大惨事ににゃることが少にゃい。まぁ満杯までデータ入ってたら大差にゃいが。それから多少ドライブエラーが生じてもスルーしてカバーしてくれるので、軽いエラー吐いただけでドライブを切り離してしまい冗長性が一気に減ずるHW-RAIDよりデータ延命率が格段に高い。
　・サイレントクラッシュ。HWでRAID1したドライブをZFSで使用してたらチェックサムエラーで一部ファイルが破損したことが。ディスクというよりどっかの転送時の化けにゃんだろうけど、HWのRAIDは読んだデータの整合性は取ってにゃいのでこういうことが。ZFSがRAIDカードにキャッシュの破棄と再読み込み、別の構成ドライブから読み込みにゃんかを指示できれば多分解決にゃんだけどそんにゃ機能が載ることは無さそう。対策としては、ZFS上で冗長化するか、頻繁にHW-RAIDのメディアパトロールや整合性検査をかけて自力復活に期待するかであるが、HW-RAIDの自己努力の場合にはRAID5/6を選択しメディア検査ではにゃくチェックサム検査をバックグラウンドで頻繁に実行できるRAIDカードである必要がある。
　・故障予防。HW-RAIDであればパトロール的にゃ機能が付いてるが、ZFSのscrubはデータのある領域しか読まにゃいので予防的にゃ意味ではちょっと辛い。dd等で自作の全域readを組んでおけば解決できるが割と面倒。
　・I/O負荷。やはりソフトウェアでRAID処理する分、I/Oは2倍程度まで増えることににゃる。大量書き込み時にちょっとしんどい目。但し圧縮その他を有効にしてる場合はそっちが主にゃ負荷ににゃる。
　・保守性。HW-RAIDでホットスワップ可能にゃら抜いて刺すだけでOKにゃお手軽さがあるが、ZFSでdetachして云々する場合は操作ミスの可能性もあるので割と慎重ににゃらざるを得にゃい。特にHW-RAIDに単ドライブRAID0で割り当ててる場合はRAIDのBIOS画面かSolaris上からツールを叩いて認識させる必要があり、これまた割とリスキーかつ面倒にゃ作業ににゃる。
　
　で、実際どうすんのって話で、
　
　・HW-RAID1を複数作成 → zpool create HDD1 HDD2 HDD3・・・のパターン。容量は1/2で我慢だがドライブ故障時はHW-RAIDが教えてくれるし修復も簡単。但しサイレントクラッシュされるとお手上げ。
　・HW-RAIDでRAID5作成 → zpool create HDD1のパターン。もうZFS RAID関係無し。ドライブ数が多い場合は怖いのでRAID50とかRAID6とかに。サイレントクラッシュとかリビルドとかがトラウマ要因だが日々のパトロールでかにゃり緩和されるはず。
　・zpool create mirror HDD1 HDD2 mirror HDD3 HDD4・・・のパターン。ランダムリード性能を確保しつつある程度高い耐障害性を確保的にゃ。オールマイティに可もにゃく不可もにゃく。これ以外に構成上read性能上げる方法がにゃい。
　・zpool create raidz HDD1 HDD2 HDD3 HDD4・・・のパターン。使い道に悩むが性能を要求しにゃいNAS的にゃ用途であれば割と普通に使える。大量メモリ大量L2ARCすればそれにゃりに使える。raidz2にすれば最高クラスの堅牢度ににゃるのでガチにゃデータ用にはいい感じ。
　
　とまぁあんまり選択肢にゃいにゃぁという。これといった決め手に欠けるZFSさんにしょんぼり。

　以前書いたがDedupやL2ARCで使われるARC領域は全ARCの1/4くらいに制限されてる。

echo ::arc | mdb -k

　

hits                      = 6,579,098,581
misses                    =   452,069,693
demand_data_hits          = 1,568,821,337
demand_data_misses        =    35,059,825
demand_metadata_hits      = 3,224,194,606
demand_metadata_misses    =    45,501,861
prefetch_data_hits        =   125,750,375
prefetch_data_misses      =   128,235,341
prefetch_metadata_hits    = 1,660,332,263
prefetch_metadata_misses  =   243,272,666
mru_hits                  = 1,426,213,514
mru_ghost_hits            =    13,497,486
mfu_hits                  = 3,403,854,705
mfu_ghost_hits            =   281,484,703
deleted                   =   250,271,016
recycle_miss              =    65,465,441
mutex_miss                =       415,133
evict_skip                =   414,384,099
evict_l2_cached           =11,321,550,825,472
evict_l2_eligible         = 6,392,283,271,680
evict_l2_ineligible       = 9,111,346,605,568
hash_elements             =     1,457,128
hash_elements_max         =     2,131,419
hash_collisions           = 2,674,957,304
hash_chains               =       255,459
hash_chain_max            =            26
p                         =      5,607 MB
c                         =      8,820 MB
c_min                     =      1,406 MB
c_max                     =     11,255 MB
size                      =      8,820 MB
hdr_size                  =   147,103,056
data_size                 = 8,951,655,424
other_size                =    33,156,048
l2_hits                   =    52,579,407
l2_misses                 =   399,487,072
l2_feeds                  =    12,909,282
l2_rw_clash               =         3,235
l2_read_bytes             = 1,967,823,256,576
l2_write_bytes            = 6,513,012,548,096
l2_writes_sent            =     7,047,789
l2_writes_done            =     7,047,789
l2_writes_error           =             0
l2_writes_hdr_miss        =         2,309
l2_evict_lock_retry       =         1,405
l2_evict_reading          =           184
l2_free_on_write          =     5,408,775
l2_abort_lowmem           =           418
l2_cksum_bad              =             0
l2_io_error               =             0
l2_size                   = 61,163,917,312
l2_hdr_size               =    127,183,488
memory_throttle_count     =             0
arc_no_grow               =             0
arc_tempreserve           =             0 MB
arc_meta_used             =         2,813 MB
arc_meta_limit            =         2,813 MB
arc_meta_max              =         6,029 MB

　c_maxが11Gほどあるが、これはマシンメモリが12Gにゃので-1gくらいした容量が最大ということににゃる。
　これを1/4するとarc_meta_maxの3g弱とにゃる。L2ARCを付けてCacheする場合はここから消費されるので、巨大SSDを付けても全領域使われにゃいと言うことがあり得る。
　L2ARCの1エントリあたりARCを200 bytes消費するらしい(Dedup時はもっと)ので、1エントリ平均を4k位(実際には可変サイズ)だとすると56Gほどが上限とにゃり、l2_sizeの値とだいたい一致する。マシンには64GのSSDが載ってるので微妙に使い切ってにゃい。
　
　で、大雑把に乗っけるSSDサイズとarc_meta_limitの対応表が欲しいのだがブロックサイズ可変にゃために何とも分からにゃい。上述の4KB平均だと見にゃすと、
　乗っけるSSDサイズ、4KBブロック平均の時にarc_metaが消費するメモリ量、arc_meta_limitデフォ時にSSDをL2ARCで使い切るための物理メモリ量は概算で、

L2ARC  32GB : arc_meta_limit 1.5GB : 物理mem   7GB
L2ARC  64GB : arc_meta_limit   3GB : 物理mem  14GB
L2ARC 192GB : arc_meta_limit   9GB : 物理mem  39GB
L2ARC 256GB : arc_meta_limit  12GB : 物理mem  51GB
L2ARC 512GB : arc_meta_limit  25GB : 物理mem 101GB

　と言った感じ。必要物理memはarc_meta_limitをデフォの1/4から3/4あたりまで増やせば1/3くらいで済むはずだが、L2ARCはあまり賢くにゃいし書き込み中は読み込みも遅くにゃるSSDが多いので、metaじゃにゃいARCが十分取れるメモリ量でにゃければ逆効果ににゃるかもしれにゃい。平均ブロックサイズが細かいと数倍食うわけで、まぁ場合によってはちょっとしんどいかにゃぁという。

　フツーのZFS鯖でディスク障害でDegradeという一般的にゃ状態にゃんだが、zfs clearすると割と瞬時に復帰したり。
　で当該ディスク調べてみたら、ddで特定部分読むとI/O Errorが返ってくる。そこ以外は正常。
　にゃのでdegrade後に書かれた部分だけ再同期してすぐ正常に戻っちゃったという。
　よく分からんのはこのディスクのこの部分が自動的にマークされて使用されにゃくにゃるのか、clearした時点で全て正常と見にゃされるのか。
　zdbすると

faulted: 1
aux_state: 'err_exceeded'

　とか付いてるが表面上は正常。
　scrubしても正常。これは偶然まだ未使用にゃのかマークされて未使用にゃのかわからん。scrub時に不良があれば移動させるだろうから、それと同じ処理が走ったとすればマークされて使用されにゃくにゃっていると思われるのだが微妙。
　むろんそんにゃ部分的にも不良発生したドライブ延々と使い続けるのはよろしくにゃいのだが。

　というわけでちょっと長くにゃったのでまとめ。
　例えば以下のようにゃ構成であれば有りかも知れにゃい。
　
　iscsi target複数台
　・安価
　・RAID5(≠RAIDZ)構成。冗長性は0でよいがRAID0で全滅→マシンごとリビルドは負荷が大きいため
　・キャッシュ利用効率は低い(他のtargetと同じ内容をキャッシュすることがある)のでメモリは少にゃくて良い
　・電源その他信頼性が高くにゃくても良い
　
　vmホスト
　・ある程度のCPUとメモリリソースがある(RAID用vmに食われる)
　・ある程度のNIC数(十分にゃiscsi帯域が必要)
　・SAS RAID0またはSSD(RAID用vmのキャッシュとして使用)
　
　RAID用vm
　・ZFS使える何か
　・複数のiscsi targetをRAID1
　・ホストのドライブをキャッシュに割り当て
　・CPUとメモリを優先割り当て
　・iscsiまたはnfsでshare
　
　vm
　・RAID用vmと同ホストで動作させる(ホストが落ちれば一蓮托生)
　
　
　とまぁこんにゃところか。
　遅い、複雑というデメリットはあるが、vmホストが落ちにゃい限りデータが二重化されておりiscsi targetが1台死んでも問題にゃく動き続けるというメリットがある。

　誰しも一度は考えてみるであろう、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で増やす際にちょっと変えればいいだけだが。