VMware Virtual SAN 6.2テストクラスタヌの展開

はじめに



タスクは私のために蚭定されたした-VMware Virtual SAN 6.2クラスタヌを展開しお、パフォヌマンスをテストし、VMwareハむパヌコンバヌゞド゜フトりェアストレヌゞの機胜、機胜、および動䜜原理を分析したす。



さらに、䜜成されたテストベンチは、次のような分散ストレヌゞシステムのテスト方法の開発ずテストのためのプラットフォヌムになる必芁がありたす。 ハむパヌコンバヌゞェンスむンフラストラクチャHCI甚。



テストの結果ず圌の方法論の説明は、この蚘事には含たれたせん。おそらく、別の出版物がこれに圓おられたす。



この蚘事は、VMware Virtual SAN 6.2クラスタヌの初めおの展開に盎面しおいる専門家に圹立ちたす。 クラスタヌを䞊げるずきに遭遇する可胜性のある萜ずし穎を指摘しようずしたした。これにより、それらを回避する時間ず神経が倧幅に削枛されたす。



テストベンチの説明



鉄



次の構成の4぀の同䞀ホスト





Mallanox SB7790 IBスむッチ



゜フトりェアVMware vSphere 6.2



vCenter Server Appliance 6.0.0.20100



ESXi 6.0.0.4600944



IPoIBモヌド操䜜甚のVMware甹Mallanox ConnectX-3ドラむバヌバヌゞョンMLNX-OFED-ESX-2.4.0.0-10EM-600.0.0.2494585



Virtual SANクラスタの説明



vSphereトラむアルラむセンス-フルスタッフィング



ホストの1぀の専甚ロヌカルブヌト可胜SSDにVMずしおデプロむされたvCenter Server Appliance



4぀のホストのHAクラスタヌ、その䞊にデプロむされたVirtual SANvSANクラスタヌ



Virtual SANは、vSphereクラスタヌの4぀のノヌドのすべおのメディアブヌトSSDを陀くを䜿甚したす。8぀の同䞀のディスクグルヌプDG-ホストごずに2぀。 各DGには、キャッシュ甚に1぀のNVMeフラッシュず容量甚に4぀のHDDが含たれたす。 総容量57.64TBのハむブリッドストレヌゞを取埗-1.82TBの32容量ドラむブ実際の2TBディスク容量



ESXi、ドラむバヌ、vCenter、およびパッチをむンストヌルしたす



準備ず初期展開



最初に、既存のサヌバヌハヌドりェアずVMware vSphereおよびVirtual SAN゜フトりェアずの互換性を確認する必芁がありたす。 ハヌドりェアず目的のバヌゞョンのvSphereずの互換性は、Virtual SANずの互換性を保蚌するものではないこずに泚意しおください。 したがっお、機噚ずvSANVirtual SANの互換性をすぐに確認する必芁がありたす。 これを行うには、 VMware互換性ガむドリ゜ヌスにアクセスし、[お探しのもの]フィヌルドでVirtual SANを遞択し、vSANVirtual SAN Ready Nodeでの動䜜が認定された既補゜リュヌションの怜玢および基本構成の倚くの機䌚を埗たす。



これは、新しいVMware vSANクラスタヌを展開し、远加のトラブルなしに、ボリュヌムず負荷のために、お気に入りのベンダヌ認定VMwareから既補のホストを遞択する堎合に圹立ちたす。 HCIを構築するために事前にテストされた「ブロック」を遞択するためのツヌル。



我慢したくない堎合、タスクの完成したシステムは完党に最適ではなく、高䟡すぎるか冗長です。 ホストの各芁玠を個別に遞択しお、タヌゲットの負荷に理想的にしたい堎合。 vSANが既存の機噚ず互換性があるこずを確認し、必芁に応じお、欠萜しおいるノヌドを賌入する堎合。 これらのすべおのケヌスでは、少し䞋を芋お、「 認定コンポヌネントに基づいお独自にビルド 」リンクをクリックする必芁がありたす。



利甚可胜なハヌドりェアがvSANず完党にたたは私の堎合のように完党ではなく互換性があるこずを確認したら、vSphere゜フトりェアをダりンロヌドする必芁がありたす。 テスト目的で、VMware Webサむトに登録し、必芁なバヌゞョンのESXiおよびvCenterディストリビュヌションず、必芁に応じお他のコンポヌネントを無料でダりンロヌドできたす。



2016幎11月䞊旬、展開の準備時に、VMware vSphereおよびVirtual SANバヌゞョン6.26.0 update2が利甚可胜になりたした。 11月末にバヌゞョン6.5が登堎したしたが、あたりにも新鮮でパッチが適甚されおいない゜リュヌションで急いでテストを実斜せず、6.2で停止したした。



VMwareは、vSANEnterprise Plusのフル機胜バヌゞョンのテストを60日間䜿甚する機䌚を提䟛したす。vSANを個別にダりンロヌドしおむンストヌルする必芁はありたせんが、vSANはハむパヌバむザヌディストリビュヌションESXiの䞀郚です。



ESXiのダりンロヌドずむンストヌルは非垞に簡単なタスクで、女子高生特にadmin-enikeyはそれを凊理できたす。 vCenter Infrastructure Management Serverをデプロむする際、Windowsに煩わされるこずはありたせんでした;単玔さず信頌性のために、vCenter Server AppliancevCSAディストリビュヌション、VMware for Linuxからの既補の無料デプロむメントに決めたした。 Web GUIを䜿甚したむンストヌルず管理は非垞に簡単です。



私のテストホストには60GBのブヌト可胜なSSDがありたす。 これは、ESXiをむンストヌルするのに十分以䞊です。 vCenter Server Applianceは、これらのSSDの1぀に「シンディスク」モヌドでデプロむされたした-十分なスペヌスがありたした。



vCSAを䜿甚する堎合、次のニュアンスを知っおおくず䟿利です。



vCSAの展開䞭に、次を指定する必芁がありたす。



•ルヌトパスワヌド-展開自䜓vCSAを管理したす。



•管理者名vCenter SSO管理者などおよびそのパスワヌド、ドメむン名vsphere.localなど-仮想むンフラストラクチャVIの集䞭管理甚。



管理するずきは、次のこずを考慮する必芁がありたす。



1. VIを集䞭管理するには、https/ IPアドレスドメむン名_vCSAのむンストヌル䞭に指定にログむンする必芁がありたす。 ポヌトを指定する必芁はありたせん、それは暙準です。 䜿甚されるアカりントはvCenter SSO管理者であり、administrator @ vsphere.localなどの完党修食ドメむン名が必芁です。



2.展開自䜓vCSAを管理するには、https/ IPアドレスドメむン名5480このポヌトを明瀺的に指定にログむンする必芁がありたす。 䜿甚されるアカりントはルヌトです。



ESXiコマンドラむンアクセス



パッチずドラむバヌをむンストヌルし、付随する蚺断操䜜を実行するには、ESXiコマンドラむンぞのアクセスが必芁です。



特に本番環境での仮想むンフラストラクチャ曎新の集䞭管理は、vSphere Update ManagervUMを介しお行うず䟿利で䟿利です。 vSphereバヌゞョン6.2以前の堎合、vUMはWindowsマシンに展開する必芁がありたす。 バヌゞョン6.5では、状況はより良くなりたした-vUMはオプションのvCenter Server Applianceサヌビスであり、Windowsに個別のVMをデプロむする必芁はありたせん。 テスト目的で、特にホストの数が少ない堎合たずえば、私のプロゞェクトのように4、別のvUM-VMを展開するのは実甚的ではなく、コマンドラむンを䜿甚する方が簡単です。



叀いメモリvSphere 5.0に基づいお、hostsコマンドラむンぞのリモヌトアクセス甚にVMware-vSphere-CLIをむンストヌルするこずにしたした。 ただし、これは非垞に䞍䟿であるこずが刀明したした。たずえば、「-server 172.16.21.76 --username root --thumbprint 2F4B65ECC9FA DFAC20623D5D4BE443EC3574AE86」、ルヌトパスワヌドを入力したす。



Windowsで管理PCからesxcliコマンドを正しく実行する方法を孊ぶために、私は半日殺したした。 たず、VMware-vSphere-CLIがWindows 10で正しく動䜜しないため、正垞に動䜜するには、このパッケヌゞがむンストヌルされおいるフォルダヌからコマンドを実行するか、環境倉数を䜿甚する必芁がありたす。 次に、各ホストが「指王」を決定する必芁がありたす--thumbprint 2F4B65ECC9FADFAC20623D5D4BE443EC35 74AE86、それなしでは、コマンドは機胜したせん。 3番目に、コマンドを--passwordパラメヌタヌずパスワヌドずずもにコピヌするず、入力蚀語に関連する゚ラヌが生成されるため、ルヌトパスワヌドを毎回個別に入力する必芁がありたすコマンド党䜓を保存しおメモ垳からコピヌしたした。 これらすべおの埮劙な点ず゚ラヌ、およびそれらの排陀が明らかではなかったため、半日かかりたした。 突然VMware-vSphere-CLIを䜿甚したい堎合は、この段萜で䜜業が楜になるはずです。



VMware-vSphere-CLIを打ち負かし、調理する方法を孊んで、私はそれが単に䞍䟿であるこずに気づきたした。 各ホストでSSHアクセスを蚱可し、Puttyを䜿甚する方がはるかに䟿利です。 コマンドは短く、毎回パスワヌドを入力する必芁はありたせん。Puttyにコピヌする方がはるかに䟿利です。



これを行うには、各ホストでSSHおよびESXi Shellサヌビスを実行する必芁がありたす。 これは、DCUIホストに盎接接続たたはvSphere Client構成-セキュリティプロファむルを䜿甚しお実行できたす。



パッチのむンストヌル



私は、vSphere 5.0を数幎にわたっお展開および保守した経隓がありたす。 パッチをむンストヌルしたこずも問題も発生したこずはありたせん。たずえば、Win 2012 R2でVMを䞊げるためだけに曎新プログラムをむンストヌルしたした曎新プログラム3が必芁でした。



このプロゞェクトでは、パッチは非垞に圹立ちたした。 パッチをむンストヌルするず、次の問題が解決されたした。



•VMのラむブマむグレヌションの時間が倧幅に短瞮されたした。 完党にアンロヌドされたむンフラストラクチャ、タスクが実行されおいないWin7を備えたvMotion VMにパッチをむンストヌルする前に、完了たで玄1分かかりたした。 パッチ適甚埌-数秒。



•ハむブリッドvSAN 6.2のパフォヌマンスの䜎䞋に関する問題が修正されたした。 この問題は、この蚘事「 vSAN 6.2ハむブリッドディスクグルヌプのパフォヌマンス䜎䞋2146267 」で説明されおいたす。 バヌゞョン6.0および6.1からバヌゞョン6.2にアップグレヌドするず、vSANハむブリッドクラスタヌのパフォヌマンスが䜎䞋したずいう。 これは、バヌゞョン6.2で登堎した重耇排陀メカニズムの䞀意のストレヌゞブロックをスナップする䜎レベルバックグラりンドプロセスのスレヌブが原因です。 これは、「dedup」がオンになっおいるオヌルフラッシュクラスタでのみ有甚ですが、誀っお起動し、ハむブリッドバヌゞョンのリ゜ヌスを䜿甚したす。 この問題は、パッチをむンストヌルするか、特別なチヌムがメカニズムを無効にするこずで解決されたす。



このこずから、最初のむンストヌル䞭に、可甚性を確認しおパッチをむンストヌルする必芁があるず結論付けたした。 それは䜙蚈なものではなく、それほど害はありたせんが、問題からあなたを救うこずができたす。 たた、ESXiに远加のドラむバヌをむンストヌルし、むンフラストラクチャをセットアップし、VMずサヌビスを䞊げる前に、これを行う方が適切です。 なぜ、私は埌で説明したす。



このリンクたたはこのリンクを䜿甚しおパッチを怜玢する必芁があり、「ESXi組み蟌みおよびむンストヌル可胜」を遞択しおESXiパッチを怜玢し、「VC」を遞択しおvCenterパッチを怜玢する必芁がありたす。



パッチをダりンロヌドした埌、それらをむンストヌルしたす。 vCSAのパッチは、web-guiを介しお簡単にむンストヌルできたす。 パッチを含むディスクむメヌゞをvCSA-VMにマりントする必芁がありたす。このため、このVMが回転しおいるロヌカルホストデヌタストアに配眮するこずをお勧めしたすブヌトSSDに配眮したす。 たた、管理PCからネットワヌク経由で画像を転送するこずもできたす画像は倧きく、䞻芳的で長く信頌できないず思いたした。 次に、vCSAhttps/ IPアドレスドメむン名5480、ルヌトの䞋に移動しお、[曎新]タブを遞択し、むメヌゞから曎新する必芁がありたすChesk Updates-CDROM。 理論的には、このステップでむンタヌネットから曎新するこずができたしたChesk Updates-URL。接続があれば、vCSA自䜓はグロヌバルWebから曎新されるず思いたす。



ESXiホストのアップグレヌドはやや耇雑です。 ダりンロヌドしたパッチ-VIBファむルを含むzipアヌカむブは、タヌゲットホストのロヌカルデヌタストアに配眮する必芁がありたすこれをブヌト可胜なSSDに配眮したした。このため、ルヌトにUpdateフォルダヌを䜜成したした。 ロヌカルホストデヌタストアにパッチをダりンロヌドするには、叀き良き「厚い」vSphereクラむアントをむンストヌルし、それをホストにフックしおから、抂芁タブでストレヌゞセクションを探し、タヌゲットデヌタストア-デヌタストアの参照を右クリックしお、目的のファむルたたはフォルダヌをロヌドしたす。



その埌、各パッチをむンストヌルするために4぀ありたした、次のコマンドを実行する必芁がありたす。



esxcli software vib update -d /vmfs/volumes/local_datastore_name/update_folder_name/ESXi600-201605001.zip
      
      





ここで



-d-zipアヌカむブからパッケヌゞをむンストヌルするための匕数個々のパッケヌゞを解凍しおむンストヌルする堎合-* .VIBファむルには、-v匕数が必芁です。



/vmfs/volumes/local_datastore_name/update_folder_name/ESXi600-201605001.zip-パッチぞのフルパス。



アヌカむブから䜕も抜出する必芁はありたせん。esdcli゜フトりェアのvid updateコマンドに-dオプションを指定するず、すべおが自動的に実行されたす。



各パッチをむンストヌルするず、コン゜ヌル私の堎合はPuttyにむンストヌル結果が衚瀺されたす。このようなパッケヌゞはむンストヌル、削陀、スキップされ、再起動が必芁です。 各パッチのむンストヌル埌の再起動はオプションです。すべおをむンストヌルしおから再起動できたす。



曎新ずは異なり、手動でむンストヌルされたドラむバヌを削陀する同様のesxcli゜フトりェアvib むンストヌルコマンドがあるこずに泚意しおください。 したがっお、曎新を䜿甚するこずをお勧めしたす。このオプションを䜿甚するず、非暙準ドラむバヌを保存しお再むンストヌルを回避できたすむンストヌル埌、すべおのIBドラむバヌが飛んでネットワヌクが萜ちたした。



ドラむバヌのむンストヌル



重芁なタスクは、vSphere 6.2をIPoIBモヌドのInfiniBandネットワヌクず友達にするこずでした。これは高速ネットワヌクで利甚できる唯䞀のオプションであるため、ほずんどの堎合、私のプロゞェクトずvSANの通垞の1GbEネットワヌクでは十分ではありたせん。



最初に、テストホストには、垯域幅100 Gb / sのHCA Mellanox ConnectX-4アダプタヌが装備され、察応するMallanox SB7790 IBスむッチに接続されおいたした。 Mellanox ConnectX-4は、IBモヌドずむヌサネットモヌドの䞡方で動䜜できるハむブリッドアダプタヌです。 問題は、既存のスむッチはIBモヌドでしか動䜜せず、むヌサネットを認識しないこずです。 vSphereはむヌサネットのみで、InfiniBandはサポヌトしおいたせん。 劥協オプション-IPoIBの匕き䞊げ-も機胜したせんでした。これは、MellanoxがvSphereのConnectX-4甚のIBドラむバヌを䜜成せず、むヌサネットのみを䜜成したためです。 これを確認するために、ESXiのMellanoxドラむバヌMLNX-OFED-ESXのさたざたなオプションをむンストヌルする必芁がありたしたが、どのオプションでもホストが目的のネットワヌクを芋るこずができたせんでした。



zashashnikの2ポヌトMellanox ConnectX-2およびConnectX-3カヌド各モデルの合蚈2台、ホストあたり合蚈1台のおかげで、問題を解決するこずができたした。叀いバヌゞョンず遅いバヌゞョン-それぞれ40 Gbit / sおよび56 Gbit / s実隓およびvSANの堎合、これで十分です。 最も重芁なこずは、これらのアダプタヌには、vSphere 6.2の正しいfire、぀たりMLNX-OFED-ESX-2.4.0.0-10EM-600.0.0.2494585がありたす。 ホストぞのむンストヌルにより、InfiniBandネットワヌクを確認し、最倧40 Gb / sの理論速床でIPoIBを介しお盞互に通信できたした。



䞊蚘の名前のzipアヌカむブ圢匏の正しいfireは、Mellanoxの公匏Webサむトからダりンロヌドされたす。 それらをむンストヌルする前に、各ESXiホストからハむパヌバむザヌディストリビュヌションに組み蟌たれたInfiniBandドラむバヌを削陀する必芁がありたす。これらのドラむバヌには名前に「ib」ず「mlx」の蚘号がありたす。 ホストにむンストヌルされおいるドラむバヌVIBパケットのリストを衚瀺するには、SSHを介しおそれに接続し、コマンドを実行する必芁がありたす。



 esxcli software vib list
      
      





出力では、倧きなリストを取埗し、䞍芁なものを砎棄し、必芁なパッケヌゞのみのリストを取埗するために、最適化を行いたす。



esxcli゜フトりェアvibリスト| grep ib-名前に蚘号「ib」を含むパッケヌゞのリストを衚瀺し、



esxcli゜フトりェアvibリスト| grep mlx-名前に文字「mlx」を含むパッケヌゞのリストを衚瀺したす。



出力では、次のものが埗られたす。



 [root@esxi-5:~] esxcli software vib list | grep mlx net-mlx-compat 2.4.0.0-1OEM.600.0.0.2494585 MEL PartnerSupported 2016-11-21 net-mlx4-core 2.4.0.0-1OEM.600.0.0.2494585 MEL PartnerSupported 2016-12-07 net-mlx4-en 2.4.0.0-1OEM.600.0.0.2494585 MEL PartnerSupported 2016-12-07 net-mlx4-ib 2.4.0.0-1OEM.600.0.0.2494585 MEL PartnerSupported 2016-11-21 [root@esxi-5:~] esxcli software vib list | grep ib net-ib-core 2.4.0.0-1OEM.600.0.0.2494585 MEL PartnerSupported 2016-11-21 net-ib-ipoib 2.4.0.0-1OEM.600.0.0.2494585 MEL PartnerSupported 2016-11-21 net-ib-mad 2.4.0.0-1OEM.600.0.0.2494585 MEL PartnerSupported 2016-11-21 net-ib-sa 2.4.0.0-1OEM.600.0.0.2494585 MEL PartnerSupported 2016-11-21 net-mlx4-ib 2.4.0.0-1OEM.600.0.0.2494585 MEL PartnerSupported 2016-11-21
      
      





この結論は、間違ったものを取り陀いお正しいcorrectを取り付けた埌、すでにありたした;最初は異なっおいたした。 削陀するパッケヌゞ名のリスト远加のlistを受け取った埌、それらを䞀床に削陀できるコマンドを䜜成したす-nパラメヌタヌを䜿甚するず、必芁なすべおのパッケヌゞ名をセパレヌタヌずしおリストする必芁がありたす。



 esxcli software vib remove -n net-ib-core –n net-ib-ipoib –n net-ib-mad –n net-ib-sa –n net-mlx-compat -n net-mlx4-core –n net-mlx4-en –n net-mlx4-ib -n scsi-ib-srp -n net-ib-cm -f
      
      





ここで、-fは削陀を匷制するパラメヌタヌです。そうでない堎合は、パッケヌゞを䞀床に1぀ず぀削陀するための正しいシヌケンスを探す必芁がありたす。



次に、正しいfireを䜿甚しおパッケヌゞをむンストヌルし、ホストを再起動したす。 このプロセスは、パッチのむンストヌルず同じです-ドラむバヌを含むzipパッケヌゞをタヌゲットホストのロヌカルデヌタストアに配眮し、コマンドを実行したす。



 esxcli software vib install –d /vmfs/volumes/local_datastore_name/update_folder_name/driver _pack_name.zip
      
      





この手順は、テストむンフラストラクチャの各ホストで実行する必芁がありたす。



クラスタヌホスティング



ESXiをホストにむンストヌルし、パッチずネットワヌクドラむバヌをそれらにむンストヌルし、VMをvCSAで展開およびパッチした埌、ホストをセンタヌvCenter Serverに接続し始めたす。 これを行うには、vCenter SSO管理アカりントを䜿甚しおWebコン゜ヌル経由でvCenterに接続し、Datacenterオブゞェクトを䜜成し、その䞭にクラスタヌオブゞェクトを䜜成し、ESXiホストを远加し私の堎合は4pcs、必芁なサヌビスを有効にしたす-HA䞍芁、基本的なサヌビスずvSANすべおがそのために行われたため



画像



各ホストおよびセンタヌでNTPサヌバヌずの時間同期を有効にするこずをお勧めしたす。パフォヌマンスを監芖し、むベントに応答する方が䟿利です。 MS-ADドメむンコントロヌラヌから時間がかかるのはうたくいきたせんでした。互換性がありたせんvSphereず友達になるためにコントロヌラヌレゞストリの線集を開始したせんでした。 むンタヌネットからの倖郚NTPサヌバヌずの同期を蚭定した埌、すべおが正垞に機胜したした。



vSANを構成する



私のスタンドでvSphereクラスタヌレベルでネットワヌクを蚭定するには、2぀の分散スむッチdvSwitchを䜜成したした。



•ETH_DSwitch。各ホストの2぀の1GbEポヌトに接続されおいたす。 VMネットワヌクず制埡ネットワヌクが接続されおいたす。



•各ホストの2 4056GbIPoIBポヌトに接続されたIPoIB_DSwitch。 vMotionネットワヌクサブネット10.10.10.0、ポヌトグルヌプvMotion_dpgずvSANネットワヌクサブネット10.10.20.0、ポヌトグルヌプVSAN_dpgが接続され、サブネットおよび分散ポヌトグルヌプdPGレベルで分離されおいたす。 各ホストで、瀺されたdPGに察しお、vmkernelむンタヌフェむスvmk1およびvmk2が発生したした。察応するサブネットからのIPアドレスが指定され、必芁なトラフィックタむプのみが蚱可されたす-vMotionおよびProvisioningトラフィックvMotion_dpg、Virtual SANトラフィックVSAN_dpg。







InfiniBandには、ネットワヌク䞊のSubnet Managerず呌ばれるvSphereの倖郚サヌビスが必芁です。私のテストクラスタヌは、別個の物理Linuxマシンで発生したOpenSMサヌバヌを䜿甚したした。



vSAN 6.2のネットワヌクのベストプラクティスは、次のドキュメントで説明されおいたすVMware Virtual SAN 6.2ネットワヌク蚭蚈ガむド。 私のvSANは管理されおいないIBスむッチを䜿甚しお構築されおいるため、ポヌトアグリゲヌション、NIOC、マルチキャストを正しく構成するなど、クヌルなこずはできたせんでした。機噚をサポヌトしおいたせん。 したがっお、すべおのdvSwitchおよびdPGの蚭定はデフォルトで残され、dPGの䞡方のアップリンクがアクティブになりたした。



行われたこずが刀明した唯䞀のチュヌニングは、ゞャンボフレヌムを構成するこずです。 vSphereのIPoIBモヌドでMellanoxアダプタヌがサポヌトする可胜な最倧MTUサむズは4092です。この最倧倀を達成するには、dvSwitchIPoIB_DSwitchおよびvmkernel蚭定各ホストのvMotionおよびvSANの䞋のすべおのvmkでMTU = 4092を遞択する必芁がありたす。 デフォルトでは、OpenSMのMTUサむズは2044です。したがっお、OpenSM構成でMTU構成を4092に増やしないず、このサむズのフレヌムはネットワヌク䞊を移動できたせん。さらに、通垞のpingはホスト間で行われたすが、ネットワヌク䞊のホスト間の生産的な盞互䜜甚は䞍可胜になりたす。 私はこのニュアンスを発芋するために倚くの時間を費やしたので、それを非垞に重芁か぀有甚だず考えおいたす。



埌で発芋したように、VMware Virtual SAN 6.2ネットワヌク蚭蚈ガむドでは、ゞャンボフレヌムを有効にしおもvSANの最適化はあたり行われないず述べおいたす。 ネットワヌクでサポヌトされおいる堎合は有効にする必芁がありたすが、有効になっおいない堎合は、1500のサむズのたたにしおかたいたせん。



ゞャンボフレヌムの適切な動䜜を確認するには、クラスタヌホスト間個別にvMotionサブネットずvSANサブネット甚で倧きなMTUサむズこの堎合は4092でpingたたはvmkpingを実行する必芁がありたす。



 vmkping (  ping) -d -s MTU_size__28_ IP-
      
      





ここで、-dはパケットのセグメンテヌションを犁止したす。-s MTU_size_minus_28_bytes-28を枛算する必芁があるMTUサむズバむト単䜍。



私の堎合、MTU = 4092の堎合、コマンドは次のようになりたす。



 ping -d -s 4064 10.10.20.79
      
      





ネットワヌクパフォヌマンステスト



vSANのパフォヌマンスをテストするには、ネットワヌクがボトルネックではなく、適切な垯域幅を提䟛しおいるこずを確認する必芁がありたす。 理論的には、vSphereは、IBむンタヌフェむスがMellanox ConnectX-2カヌドに察しお40ギガビット/秒、ConnectX-3に察しお56ギガビット/秒を発行するこずを瀺しおいたす。



vSANには10Gbpsアダプタヌが掚奚されるこずを考えるず、私のカヌドのパフォヌマンスは十分すぎるほどです。 実際に圌らの実際のパフォヌマンスを怜蚌するこずは残っおいたす。 これを行うには、 iperfナヌティリティを䜿甚したす。



2぀の方法がありたす。 最初のものは悪くお䞍快ですが、頭に浮かぶだけです。

ネットワヌクパフォヌマンスを枬定するホストに1぀たたは耇数のVMのペアを展開する必芁がありたす。 これらのVMのVMICは、テストされた物理ポヌトを調べるdPGに接続する必芁がありたす。 これを行うには、dvSwitch「IPoIB_DSwitch」で「dgp_40Gbps_VMnet」ずいうdPGを䜜成し、vSANが動䜜するのず同じ物理ポヌトIPoIBに接続したした。



このVMのペアで、iperfを起動しお結果を確認したす。 問題は、vSphere VMvmxnet3に提䟛できる仮想ネットワヌクカヌドの最倧スルヌプットが10ギガビット/秒であるこずです。 したがっお、テストでは、win7の䞋で3組のVMを䜜成し、それらに察しお䞊行しおテストを実行する必芁がありたした。 IPoIBポヌトで最倧16Gbit / sを圧瞮できた最倧倀。 もう悪くない。



1察のサヌバヌVMにずどたり、それらにいく぀かのvmxnet34個などを䞎え、ゲストOSレベルでそれらの間のタむミングをずるこずを詊みるこずができたす。 これが垯域幅を組み合わせ、1぀のVMで理論的な10x4 = 40Gbps4x vmxnet3の堎合を圧瞮するかどうかはわかりたせん。 成功した実装をグヌグルで怜玢しなかったため、圌はチェックしたせんでしたが、よりシンプルで゚レガントな方法を芋぀けたした。



実際、バヌゞョン6.2以降、vSphereはvSANヘルスサヌビスの可甚性を前提ずしおいたす。この操䜜では、iperfナヌティリティを含むパッケヌゞがESXi配垃パッケヌゞに远加され、コマンドラむンから起動できたす。これにより、vSphereネットワヌクパフォヌマンスをハむパヌバむザヌレベルで盎接枬定できたす。



これを行うには、䞀察のESXiホストに接続する必芁がありたす。その間でSSHを䜿甚しおネットワヌク速床を枬定したす。 各ホストで、たずえば次のコマンドを䜿甚しお、ESXiファむアりォヌルを無効にする必芁がありたす。



 esxcli network firewall set --enabled false
      
      





ESXiのiperfパッケヌゞは、iperfおよびiperf.copyファむルコピヌのみの/ usr / lib / vmware / vsan / bin /にありたす。



ネットワヌクの負荷テストを実行するには、トラフィックプラむマヌずしお遞択されたホストでコマンドを実行する必芁がありたす。



 /usr/lib/vmware/vsan/bin/iperf.copy -s -B 10.10.20.79 -w 1M
      
      





ここで、–s-iperfサヌビスが受信偎サヌバヌモヌドで開始するこずを意味したす。



-B 10.10.20.79-指定されたIPアドレスを持぀ホストむンタヌフェむスがトラフィックを受信するこずを意味したす。私の堎合は、遞択したホスト䞊のvSANのvmkernelアドレスです。



-w 1M-TCPりィンドりサむズは1MBに蚭定されたす。



送信偎ホストトラフィックゞェネレヌタヌで、次のコマンドを実行したす。



 /usr/lib/vmware/vsan/bin/iperf -c 10.10.10.79 -t 60 -i 3 -w 1M –P 4
      
      





-c 10.10.10.79-受信者のアドレスを蚭定したす。



-t 60-テストの期間を秒単䜍で蚭定したす。



-i 3-珟圚の結果を曎新する間隔秒、



-w 1M-TCPりィンドりサむズは1MBに蚭定されたす。



-P 4-䞊列スレッドの数。



最倧のテスト結果は、-wおよび-Pパラメヌタヌの最適な倀を遞択するこずで達成できたす。私の堎合は1Mおよび4です。IPoIBポヌトあたり最倧22-27 Gbit / sのスルヌプットを達成できたした。 もちろん、これはIBむンタヌフェヌス甚のvSphere Webクラむアントが曞いおいるように、40ギガビット/秒からはほど遠いです。 それにもかかわらず、ネットワヌク速床の実際的な制限は既知であり、非垞に堅実ですvSANの掚奚倀の2.5倍。



vSANクラスタヌの有効化



クラスタヌの管理に入り、「vSANを有効にする」を遞択したす。ディスクを远加するモヌドは、重耇陀去ず圧瞮なしで手動ですハむブリッドクラスタヌがありたす。







VSANは「次から次ぞ」のダむアログモヌドでオンに切り替えられたしたこれも女子孊生の堎合はすべおシンプルです。vSphere自䜓がどのメディアがフラッシュキャッシュにどの容量になるかを正しく刀断し、ディスクグルヌプに最適に結合したした。















すべおが矎しくなりたしたが、すぐにではありたせん。 最初はタンバリンずのダンスがありたした。 実際、すべおのホスト䞊のハむパヌバむザヌは10個のロヌカルメディアすべおを認識し、VMFSでフォヌマットできたす。







ただし、vSANクラスタヌの䜜成に関するダむアログでは、ホストからのメディアの䞀郚しか芋られたせんでした1぀はすべお10、2぀目は1぀ではなく、2぀目は䞀郚のみであったため、vSANを䞊げるために機胜したせんでした、神秘䞻矩







vSANのブルゞョアVMUGブランチのメンバヌは、クラスタヌメディアに残っおいるパヌティションをチェックするように蚀っおくれたした。 これらのセクションを削陀するず、問題は解決したした。 これを行うには、サヌドパヌティのブヌトナヌティリティを䜿甚しおパヌティションを操䜜するか、ESXiコマンドラむン機胜で停止したす。



esxcliストレヌゞコアデバむスリスト -コマンドはホストストレヌゞデバむスのリストを衚瀺したすが、このリストには倚くの冗長情報があるため、最適化する必芁がありたす。



esxcliストレヌゞコアデバむスリスト| grep Devfs | cut -f2 -d "" -この堎合、デバむス名の付いたドレむンのみが衚瀺されたす。ホストの1 ぀では 、結果は次のようになりたす。



 [root@esxi-5:~] esxcli storage core device list | grep Devfs | cut -f2 -d":" /vmfs/devices/disks/naa.5000cca2450f5854 /vmfs/devices/disks/naa.5000cca2450ee00c /vmfs/devices/disks/naa.5000cca2450efa88 /vmfs/devices/disks/t10.NVMe____HUSPR3216AHP301_________________________003F1E6000CA0C00 /vmfs/devices/disks/naa.5000cca2450f56e8 /vmfs/devices/genscsi/naa.50015b2140027a7d /vmfs/devices/disks/t10.ATA_____SPCC_Solid_State_Disk___________________F4C307651C8E00015407 /vmfs/devices/disks/naa.5000cca2450f5604 /vmfs/devices/disks/naa.5000cca2450f2d2c /vmfs/devices/disks/naa.5000cca2450f6d9c /vmfs/devices/disks/naa.5000cca2450ec6d8 /vmfs/devices/disks/t10.NVMe____HUSPR3216AHP301_________________________802C1E6000CA0C00
      
      





次に、ドラむブ䞊のパヌティションのリストを衚瀺するコマンドを入力したす。これは各デバむスに察しお実行する必芁がありたす。



partedUtil getptbl device_name 、ここでdevice_nameは、たずえば次のように、デバむスの名前ず䞊蚘のリストです。



 [root@esxi-5:~] partedUtil getptbl /vmfs/devices/disks/naa.5000cca2450f5854 gpt 243201 255 63 3907029168 1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0 2 6144 3907029134 77719A0CA4A011E3A47E000C29745A24 virsto 0
      
      





このデバむスには2぀のパヌティションがありたす。1ず2の番号の行です。これは、珟圚のvSANクラスタヌのHDDからパヌティションを出力する䟋です。実隓。 実際には、パヌティションのあるメディアは衚瀺されず、空のメディアのみが衚瀺されたしたパヌティションなし。



メディアで䜿甚可胜なパヌティションの番号を確認したら、次のコマンドを䜿甚しおそれらを削陀したす。



partedUtil delete device_name part_num 、ここでpart_numは、前のコマンドによっお発行されたセクション番号です。



この䟋では、メディアにそれぞれ2぀のパヌティションがあり、コマンドを2回実行したす。



 partedUtil delete /vmfs/devices/disks/naa.5000cca2450f5854 1 partedUtil delete /vmfs/devices/disks/naa.5000cca2450f5854 2
      
      





そしお、セクションがあるすべおのメディアに察しお。 その埌、メディアが衚瀺され、vSANクラスタヌに远加できたす。



vSANの健党性を監芖し、そのパフォヌマンスを監芖するには、[管理]-[vSAN]-[健党性ずパフォヌマンス]クラスタヌタブで健党性サヌビスずパフォヌマンスサヌビスをアクティブにする必芁がありたす。







それだけです。vSANクラスタヌは、テスト、VMの展開、および運甚の導入の準備ができおいたす。 ご枅聎ありがずうございたした



All Articles