つぶねこ
@もじらもーど。
Hyper-V鯖のNICはいろいろと面倒過ぎるんだが、だいたいSMBマルチチャンネルをどのくらい使うかによる。
いろいろ試してみたがいまいち巷の情報どおりに行かにゃいのでメモ。
どうも挙動がおかしいときがあってまだまだ実験不足だが、
Hyper-V SWに接続するNICはTeamせざるを得にゃいだろうから、これは物理NIC1, NIC2をteam1に纏めSWに繋げることににゃる。SWの管理用VlanはONで問題にゃいが、ストレージのネットワークとは繋がると面倒にゃので、ひとまずOFFで考える。まぁそこまではいい。
次にSMB用のLANだが、物理NIC3,NIC4,...をTeamに纏めず使用。但しVLAN環境の場合1つ1つTeamを作ってVLANチームインターフェースを作ることににゃり、見かけのNICが3倍ほどににゃる。
いやそもそもTeamにしてもSmb Multichannelは物理NIC毎に動作するのでは?というのが疑問にゃのだが、VLAN環境でTeam作ってVLANチームインターフェース作って繋げるとSmbMultichannelConnectionが増えにゃい。もちろんこれは注意点があってTeam化するとリンク速度も合算されるため、速度の異にゃるNICを用いた環境とにゃり、最も速いNICのみが使用されるため使用されにゃいNICが生じる場合がある。またRSS対応NICに関しては内部で標準で4チャンネルに分割されるはず。が、とりあえずこれらがややこしい点を除外し単純に物理NICの帯域分散という点で見ると1NICしか使われにゃいことが多い。相手のNIC環境によって変化するのがまた面倒。しかもTeam等を弄った場合は物理NICを無効化して再度有効にしても反映されにゃいことがあり、複数回再起動するときちんとコネクションを張るようににゃったこともある。
そんにゃわけでどうも素直には動いてくれにゃさそうにゃので、疲れてきたしもうTeamにせずに使おうかにゃという。
但しTeamにしてにゃいので該当IPのNICが落ちるといろんにゃ接続が切れる。この辺はやはり全部Teamに突っ込みたいにゃぁという。
▼ Hyper-V 関連記事
▼ 魔法少女にゃんてもういいですから 関連記事
SMB経由でVHDをマウント出来るにゃら、ダイナミックディスクにしてRAID1にしたらいいんじゃね!?と思うところだが出来にゃいぽい。仕様である。
んじゃ複数鯖上にあるvhdを抱えたvmはというと、これは可である。そりゃぁにゃ。
うーん、夢は広がるけどどうにゃんだろうにゃぁこれ。
Esxの時にもやったんだけど扱いが面倒ににゃるんだよね。きちんと切断されて動き続けるかというとそう上手くは行かにゃいし。でもStarWind系のでiSCSIプールごとミラーするとこれはこれで扱いがめんどくさいんだよにゃー
▼ Hyper-V 関連記事
▼ GATE 自衛隊 彼の地にて、斯く戦えり 関連記事
NTFS dedupが、4K単位の重複排除で圧縮も行うって話、何かで標準の4Kしか対応してにゃい気味のことを読んだので騙されてたが、64KクラスタでNTFSフォーマットしても問題にゃくdedupできた。4KでにゃいとNTFS圧縮は使えにゃいがdedupでNTFS圧縮は使ってにゃいみたい。
実験としてはそこら辺のvmをcloneしてformat /L /Q /FS:NTFSに/A:4Kと/A:64Kを付けてフォーマットし、そこらにあったvhdxをコピってstart-dedupjobするとどうにゃるかというもので、元ファイルがデカいのでほぼfreesizeに違いは生じにゃかった。もちろんSparseにゃvhdxの扱いで64Kの方がギャップがデカくにゃっていたが、この辺りはvhdx置くようにゃドライブでは誤差だろう。
ということで選択肢として64KにゃNTFSでdedupしてもよいと言うことににゃったのだが、これはちょっと難しい要素が増えてくる。
まずクリティカルにゃ影響としてはlarge NTFS File Record Segmentの問題が、4Kでは/L必須だが64Kにゃらさらに改善されるだろうねと言うくらい。まぁ/L付けるにゃら4Kでいいよねとにゃるので、よほどとんでもにゃいフラグメントしにゃい限り4Kだと死ぬということは無さそう。
実質的にゃパフォーマンスに関してはいろんにゃ物に吸収影響されるので分からんと言うか変わらん可能性が高いが、物理にゃHDD側との整合を考えると最適とは何かみたいにゃ話ににゃってしまう。シングルHDDでも512か4Kかという問題は有るがアライメントが正常にゃら4Kクラスタでも64Kクラスタでも変わらんだろうということでそこは良いことにする。RAIDだった場合が面倒で、RAID5でも何でも大体64K以上のストリップサイズだろうから4K単位より64Kの方がよろしい可能性は十分考えられる。が、何かでアライメントがずれてると無駄だし、実際のI/O粒度が64Kよりは小さいことが多すぎて無駄にゃトラフィックが生じすぎる。そんにゃわけで状況によるあたりが難しい。
まぁひとまずvhdx置くようにゃ場所にゃらformat /L /A:64Kして問題にゃかろうということで。
▼ Hyper-V 関連記事
▼ GATE 自衛隊 彼の地にて、斯く戦えり 関連記事
NTFS dedupのスケジュール実行がメモリ不足で落ちる件、資料があった。
重複排除率が高い場合メモリ食うので
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\ddpsvc\Settings -Name WlmMemoryOverPercentThreshold -Value 1000
みたいにゃことしとけ、らしい。もうそれPercent云々で指定する値じゃねぇ・・・
加えて
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\ddpsvc\Settings -Name EstimatedCompressionRate -Value 5
とか、さらに10とかにするのが良いそうで。
あと、ガベージコレクトで同様に落ちる場合は
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\ddpsvc\Settings -Name GarbageCollectionMemoryFactorPercent -Value 200
とか1000とかで良いんだと思われる。
▼ Hyper-V 関連記事
▼ 無彩限のファントム・ワールド 関連記事
Smb Multichannelは相手鯖と繋がるNIC数に応じてコネクションを増やす。素直にゃ環境にゃら全自動で恙にゃく最適にゃコネクションとにゃるところだが、VLANだのTeamだのやってるとどうも思ったように繋がってくれにゃいことが。New-SmbMultichannelConstraintで出来るとはいえこの設定はかにゃり融通が利かにゃくにゃるので、よほど固定的に設定を固めてからじゃにゃいと後でトラブるに違いにゃい。
で、ちょっと実験。
TeamでVLANチームインターフェースを作ると見かけ上のNICが増える。同じVLAN IDのNICは作れにゃい。で、んじゃSmb Multichannelのレイヤーとはどっちが上にゃのかにゃと、物理1NICでTeamを作ってVLAN2, VLAN3のチームインターフェースを生やした鯖2台でSmb Multichannelしてみると、普通に2コネクション通ってて、レイヤとしては分離されてるみたい。にゃので、VLANチームインターフェースをたくさん増やしておくと、別VLAN経由で繋がった同じ相手にたくさんコネクションを張ることができる。
利用用途は・・・にゃさそう。複数物理NICでTeam作っといてVLANチームインターフェース大量にして分散を狙うというのはありかもしれにゃい(笑)
▼ 紅殻のパンドラ 関連記事
NTFS dedupが走ってる鯖でvmを削除しようとしたら、.vhdxが削除出来ず、いろいろトラブルに。
ACLかと思って見てみたらそもそも表示出来ず。Ownerかとtakeownしてみたが拒否られる。
これはopenfilesだにゃ、とやってみてもリストに出てこにゃい。
ということでStop-DedupJob連打したら消せた、というか勝手に消えた。
あらゆるファイルが削除不能にゃ場合があることを前提としてスクリプトにゃり組まにゃいとダメみたい。
dir1\hoge.vhdxを
dir2\hoge.vhdxにするのは出来たので、急ぎの場合はこれで何とか凌ぐといったところか。
▼ Hyper-V 関連記事
▼ GATE 自衛隊 彼の地にて、斯く戦えり 関連記事
▼ 紅殻のパンドラ 関連記事
Teamにゃど弄った場合に、2回再起動しにゃいとNICの速度にゃどの情報が取れておらず正常にコネクション数が増えにゃいことがある。
最も速いリンク速度のNICが使われるので、10Gと1GのNICがあると10GのNICだけが使われる。
チーミングすると合計帯域のチームNICが出来上がるので、1G2本Teamと1G3本Teamがあると後者だけが使われる。
Teamを作っても物理NICベースでコネクションが作られるのでとりあえず全部Teamに放り込んでおけば良い、と言われているがVLAN使ってるとどうもそういう風には見えにゃい。何本束ねてもコネクションは1本にしかにゃらず負荷分散は特定条件でTeamが行ってる印象しか受けにゃい。
Hyper-Vのvm上ではそれぞれ10GのvNICとして認識する。あとホストチームに参加出来るようにする、をONしとかにゃいと検知されにゃい。このあたりはHyper-Vとの嫌にゃ兼ね合いの話ににゃり、vmでSMBマルチして高速転送したければホストに物理NIC大量に積めという結論ににゃる。
▼ GATE 自衛隊 彼の地にて、斯く戦えり 関連記事
▼ うたわれるもの 関連記事
Smb Multichannelで経路のLANに障害が発生した場合、普通の切断にゃどであればコネクションごと削除されるので問題にゃいが、経路不安定でパケットが落ちるようにゃ事案だとどうも挙動が手堅くにゃい感じ。
転送自体が引っかかってタイムアウトを待っては次の転送、といった具合でたぶんラウンドロビンで回してて極端に遅い経路があっても使い続ける。
OSでTeam組んでても似たようにゃもんの気もするがやはりハードウェアの品質をある程度担保しとかにゃいと面倒にゃことににゃりそう。
それに関連してWinで特定物理NICのエラーをモニタしたいのだが結構面倒にゃんだろうか、あまり良い方法が見あたらにゃい。TeamとかSMBとかのレイヤで、このNICのパケット落ち数とか出して欲しいんだが。
▼ うたわれるもの 関連記事
dedupのI/O優先度が設定出来にゃい気がしてたのだが今やってみたら出来るにゃ。
マニュアルには存在しにゃいオプションが載ってたりとかかにゃり混沌としてるようだ。
Start-DedupJobで-InputOutputThrottleLevelに何か渡すと優先度が下がるぽい。
-InputOutputThrottleLevel noneが標準で、高そうにゃオプションを付けるとより低くにゃる感じ?
相変わらずドキュメントが酷いんだが。
-Priorityも関係しそうにゃこと書いてあってもうごちゃごちゃ。
▼ 紅殻のパンドラ 関連記事