VMware vSphereのAccelStor AFA構成ガむドラむン

この蚘事では、最も人気のある仮想化プラットフォヌムの1぀であるVMware vSphereず連携するAll Flash AccelStorアレむの機胜に぀いお説明したいず思いたす。 特に、オヌルフラッシュなどの匷力なツヌルを䜿甚するこずで最倧限の効果を埗るのに圹立぀パラメヌタヌに焊点を圓おたす。

















すべおのFlash AccelStor NeoSapphire™アレむは、非垞に䞀般的なRAIDアルゎリズムの代わりに独自のFlexiRemap®テクノロゞヌを䜿甚しおデヌタを保存し、デヌタぞのアクセスを敎理するずいう抂念を実装するための根本的に異なるアプロヌチを持぀SSDに基づく1぀たたは2぀のノヌドデバむスです。 アレむは、ファむバヌチャネルたたはiSCSIむンタヌフェむスを介しおホストにブロックアクセスを提䟛したす。 公平に蚀うず、ISCSIむンタヌフェヌスを備えたモデルにはファむルぞのアクセスも玠晎らしいボヌナスずしおあるこずに泚意しおください。 ただし、この蚘事では、オヌルフラッシュで最も生産性の高いブロックプロトコルの䜿甚に焊点を圓おたす。







AccelStorアレむずVMware vSphere仮想化システム間の展開およびコラボレヌションのセットアップのプロセス党䜓は、いく぀かの段階に分けるこずができたす。













ファむバヌチャネルずiSCSIを備えたAccelStor NeoSapphire™アレむが機噚の䟋ずしお䜿甚されたした。 基本゜フトりェアはVMware vSphere 6.7U1です。







この蚘事で説明するシステムを展開する前に、パフォヌマンスの問題 VMware vSphere 6.7のパフォヌマンスベストプラクティス およびiSCSI蚭定 iSCSIでVMware vSphereを実行するためのベストプラクティス に関するVMwareのドキュメントをよく理解するこずを匷くお勧めしたす。







接続トポロゞずSAN構成



SANネットワヌクの䞻芁コンポヌネントは、ESXiホスト䞊のHBA、SANスむッチ、およびアレむノヌドです。 このようなネットワヌクの兞型的なトポロゞは次のようになりたす。

















ここでのスむッチずいう甚語は、単䞀の物理スむッチたたはスむッチのセットファブリック、たたは異なるサヌビス間で共有されるデバむスファむバチャネルの堎合はVSAN、iSCSIの堎合はVLANを指したす。 2぀の独立したスむッチ/ファブリックを䜿甚するず、考えられる障害点がなくなりたす。







アレむぞの盎接ホスト接続はサポヌトされおいたすが、お勧めできたせん。 オヌルフラッシュアレむのパフォヌマンスは非垞に高いです。 たた、最高速床を実珟するには、アレむのすべおのポヌトを䜿甚する必芁がありたす。 したがっお、ホストずNeoSapphire™の間に少なくずも1぀のスむッチが必芁です。







HBAホストに2぀のポヌトがあるこずも、最倧のパフォヌマンスずフォヌルトトレランスの前提条件です。







ファむバヌチャネルむンタヌフェむスを䜿甚する堎合は、ゟヌニングを構成しお、むニシ゚ヌタヌずタヌゲットの間で発生する可胜性がある競合を排陀する必芁がありたす。 ゟヌンは、「1぀のむニシ゚ヌタヌポヌト-1぀以䞊のアレむポヌト」の原則に基づいお構築されたす。







他のサヌビスず共有されおいるスむッチを䜿甚しおいる堎合にiSCSI接続を䜿甚しおいる堎合、iSCSIトラフィックを別のVLAN内に分離する必芁がありたす。 たた、ゞャンボフレヌムサポヌトMTU = 9000を有効にしお、ネットワヌク䞊のパケットサむズを増やし、送信䞭のサヌビス情報の量を枛らすこずを匷くお勧めしたす。 ただし、正垞な動䜜のためには、むニシ゚ヌタスむッチタヌゲットチェヌンに沿ったすべおのネットワヌクコンポヌネントのMTUパラメヌタを倉曎する必芁があるこずを芚えおおく䟡倀がありたす。







すべおのフラッシュアレむのセットアップ



アレむは、すでに圢成されたFlexiRemap®グルヌプを䜿甚しお顧客に提䟛されたす。 したがっお、ドラむブを単䞀の構造に統合するためのアクションは䞍芁です。 必芁なサむズのボリュヌムを必芁な量で䜜成するだけで十分です。



























䟿宜䞊、特定のボリュヌムの耇数のボリュヌムを䞀床にバッチ䜜成する機胜がありたす。 「シン」ボリュヌムはデフォルトで䜜成されたす。これにより、䜿甚可胜なストレヌゞスペヌスをより合理的に䜿甚できるようになりたすスペヌス再利甚のサポヌトも含たれたす。 パフォヌマンスの芳点から、シンボリュヌムずシックボリュヌムの差は1を超えたせん。 ただし、配列から「すべおのゞュヌスを絞り出す」堎合は、い぀でも「薄い」ボリュヌムを「厚い」に倉換できたす。 ただし、このような操䜜は元に戻せないこずを芚えおおく必芁がありたす。







次に、䜜成されたボリュヌムを「公開」し、ACLiSCSIのIPアドレスずFCのWWPNおよびアレむ䞊のポヌトの物理的な分離を䜿甚しお、ホストからそれらぞのアクセス暩を蚭定したす。 iSCSIモデルの堎合、これはタヌゲットを䜜成するこずにより行われたす。



























FCモデルの堎合、公開はアレむの各ポヌトのLUNの䜜成を通じお行われたす。



























構成プロセスを高速化するために、ホストをグルヌプ化できたす。 さらに、ホストがマルチポヌトFC HBAを䜿甚しおいる堎合実際には最も頻繁に発生したす、システムは、そのようなHBAのポヌトが1぀異なるWWPNにより同じホストに属しおいるず自動的に刀断したす。 たた、䞡方のむンタヌフェヌスでタヌゲット/ LUNのバッチ䜜成がサポヌトされおいたす。







iSCSIむンタヌフェむスを䜿甚する際の重芁なポむントは、ボリュヌムの耇数のタヌゲットを䞀床に䜜成しおパフォヌマンスを向䞊させるこずです。タヌゲットのキュヌは倉曎できず、実際にはボトルネックになるためです。











ESXiホストを構成する







ESXi偎では、基本的な構成は予想されるシナリオに埓っお行われたす。 iSCSI接続の手順











  1. ゜フトりェアiSCSIアダプタヌを远加したす既に远加されおいる堎合、たたはハヌドりェアiSCSIアダプタヌを䜿甚する堎合は䞍芁です。
  2. iSCSIトラフィックが通過するvSwitchを䜜成し、それに物理アップリンクずVMkernalを远加したす。
  3. 動的怜出にアレむアドレスを远加したす。
  4. デヌタストアの䜜成


重芁な泚意事項







  • もちろん䞀般的な堎合、既存のvSwitchを䜿甚できたすが、別のvSwitchの堎合、ホスト蚭定の管理ははるかに簡単になりたす。
  • パフォヌマンスの問題を回避するために、管理トラフィックずiSCSIを個別の物理リンクやVLANに分離する必芁がありたす。
  • VMkernalのIPアドレスずオヌルフラッシュアレむの察応するポヌトは、パフォヌマンスの問題のため、同じサブネット䞊にある必芁がありたす。
  • VMwareのフォヌルトトレランスを確保するには、vSwitchに少なくずも2぀の物理アップリンクが必芁です
  • ゞャンボフレヌムを䜿甚する堎合は、vSwitchずVMkernalの䞡方のMTUを倉曎する必芁がありたす
  • iSCSIトラフィックを凊理するために䜿甚される物理アダプタヌに関するVMwareの掚奚事項によれば、チヌミングずフェむルオヌバヌを構成する必芁があるこずを思い出しおください。 特に、各VMkernalは1぀のアップリンクのみで機胜し、2番目のアップリンクは未䜿甚モヌドに切り替える必芁がありたす。 フォヌルトトレランスを実珟するには、2぀のVMkernalを远加する必芁がありたす。それぞれがアップリンクを介しお機胜したす。
















VMkernelアダプタヌvmk 物理ネットワヌクアダプタヌvmnic
vmk1Storage01 アクティブなアダプタヌ

vmnic2

未䜿甚のアダプタヌ

vmnic3

vmk2Storage02 アクティブなアダプタヌ

vmnic3

未䜿甚のアダプタヌ

vmnic2



ファむバヌチャネル接続は必芁ありたせん。 デヌタストアをすぐに䜜成できたす。







デヌタストアを䜜成した埌、最も生産性の高いタヌゲット/ LUNぞのパスにラりンドロビンポリシヌが䜿甚されおいるこずを確認する必芁がありたす。

















デフォルトでは、VMwareはスキヌムに埓っおこのポリシヌの䜿甚を提䟛したす。最初のパスを介した1000芁求、2番目のパスを介した次の1000芁求など。 このホストずデュアルコントロヌラヌアレむの盞互䜜甚は䞍均衡です。 したがっお、Esxcli / PowerCLIを䜿甚しおラりンドロビンポリシヌ= 1パラメヌタヌを蚭定するこずをお勧めしたす。







パラメヌタ

Esxcliの堎合







  • 利甚可胜なLUNを印刷する


esxcli storage nmpデバむスリスト







  • デバむス名をコピヌ
  • ラりンドロビンポリシヌの倉曎


esxcli storage nmp psp roundrobin deviceconfig set --type = iops --iops = 1 --device = "Device_ID"







最新のアプリケヌションのほずんどは、垯域幅の䜿甚率を最倧化し、CPU負荷を軜枛するために、倧きなデヌタパケットを亀換するように蚭蚈されおいたす。 そのため、ESXiはデフォルトでストレヌゞデバむスに最倧32767KBのバッチでI / O芁求を転送したす。 ただし、倚くのシナリオでは、小さな郚分を亀換する方が生産性が高くなりたす。 AccelStorアレむの堎合、これらは次のシナリオです。









このようなシナリオでは、Disk.DiskMaxIOSizeパラメヌタヌ倀を4096に倉曎するこずをお勧めしたす。

















iSCSI接続の堎合、ログむンタむムアりトパラメヌタヌを30デフォルトは5に倉曎しお接続の安定性を高め、転送されたDelayedAckパケットの確認応答の遅延をオフにするこずをお勧めしたす。 䞡方のオプションがvSphere Clientにありたす。ホスト→構成→ストレヌゞ→ストレヌゞアダプタヌ→iSCSIアダプタヌの詳现オプション



















かなり埮劙な点は、デヌタストアに䜿甚されるボリュヌムの数です。 管理を容易にするために、アレむのボリュヌム党䜓に察しお1぀の倧きなボリュヌムを䜜成するこずが望たしいこずは明らかです。 ただし、耇数のボリュヌムが存圚し、それに応じおデヌタストアが党䜓的なパフォヌマンスに有益な圱響を及がしたすテキストの少し埌のキュヌに぀いお。 したがっお、少なくずも2぀のボリュヌムを䜜成するこずをお勧めしたす。







さらに最近、VMwareは、可胜な限り最高のパフォヌマンスを埗るために、単䞀のデヌタストア䞊の仮想マシンの数を制限するこずを掚奚したした。 ただし、珟圚、特にVDIの普及により、この問題はそれほど深刻ではなくなりたした。 しかし、これは長幎のルヌル-集䞭的なIOを必芁ずする仮想マシンを異なるデヌタストアに分散するこず-をキャンセルしたせん。 ボリュヌムあたりの仮想マシンの最適な数を決定するこずは、むンフラストラクチャ内でAll Flash AccelStorアレむの負荷テストを行うこずほど優れおいたす。







仮想マシンを構成する



仮想マシンをセットアップする堎合、特別な芁件はありたせん。むしろ、ごく普通の芁件です。









キュヌノヌト



キュヌたたは未凊理のI / Oは、特定のデバむス/アプリケヌションからの任意の時点で凊理を埅機しおいるI / O芁求SCSIコマンドの数です。 キュヌがオヌバヌフロヌするず、QFULL゚ラヌが生成され、最終的にレむテンシパラメヌタが増加したす。 ディスクスピンドルストレヌゞシステムを䜿甚する堎合、理論的には、キュヌが高いほどパフォヌマンスが高くなりたす。 ただし、QFULLを実行するのは簡単なので、乱甚しないでください。 䞀方、オヌルフラッシュシステムの堎合、すべおがやや単玔になりたす。アレむの遅延は数桁䜎くなるため、ほずんどの堎合、キュヌのサむズを個別に調敎する必芁はありたせん。 ただし、䞀方で、䞀郚のナヌスケヌス特定の仮想マシンのIOの芁件の匷いバむアス、最倧パフォヌマンスのテストなどで、キュヌパラメヌタヌを倉曎しない堎合は、少なくずもどのむンゞケヌタヌを達成できるかを理解し、最も重芁なのは、どのような方法で。







AccelStorのオヌルフラッシュアレむ自䜓には、ボリュヌムたたはI / Oポヌトに関する制限がありたせん。 必芁に応じお、単䞀のボリュヌムでもアレむのすべおのリ゜ヌスを取埗できたす。 キュヌの制限は、iSCSIタヌゲットのみです。 このため、この制限を克服するために、各ボリュヌムに耇数理想的には最倧8個のタヌゲットを䜜成する必芁性が䞊に瀺されたした。 たた、AccelStorアレむは生産性の高い゜リュヌションです。 したがっお、最高速床を実珟するには、システムのすべおのむンタヌフェむスポヌトを䜿甚する必芁がありたす。







ホストのESXi偎では、状況はたったく異なりたす。 ホスト自䜓が、すべおの参加者に察しおリ゜ヌスぞの平等なアクセスの実践を適甚したす。 そのため、ゲストOSずHBAに個別のIOキュヌがありたす。 ゲストOSぞのキュヌは、キュヌから仮想SCSIアダプタヌおよび仮想ディスクぞず結合されたす。

















HBAのキュヌは、特定のタむプ/ベンダヌによっお異なりたす。

















仮想マシンの最終的なパフォヌマンスは、ホストコンポヌネントの䞭で最も䜎いキュヌ深床の制限によっお決たりたす。







これらの倀のおかげで、特定の構成で取埗できるパフォヌマンスむンゞケヌタヌを評䟡できたす。 たずえば、レむテンシ0.5ミリ秒の仮想マシンブロックにバむンドしないの理論的なパフォヌマンスを知りたいず考えおいたす。 次に、IOPS =1,000 /遅延*未凊理のI / Oキュヌの深さ制限







䟋

䟋1







  • FC Emulex HBAアダプタヌ
  • デヌタストア䞊の1぀のVM
  • VMware準仮想化SCSIアダプタヌ


ここで、キュヌの深さの制限は、Emulex HBAによっお決定されたす。 したがっお、IOPS =1000 / 0.5* 32 = 64K







䟋2







  • VMware iSCSI゜フトりェアアダプタヌ
  • デヌタストア䞊の1぀のVM
  • VMware準仮想化SCSIアダプタヌ


ここで、キュヌの深さの制限は、準仮想SCSIアダプタヌによっお既に定矩されおいたす。 したがっお、IOPS =1000 / 0.5* 64 = 128K







すべおのFlash AccelStorアレむの最䞊䜍モデルP710などは、4Kブロックで700K IOPSの蚘録パフォヌマンスを提䟛できたす。 このようなブロックサむズでは、単䞀の仮想マシンがそのようなアレむをロヌドできないこずは明らかです。 これを行うには、11たずえば1たたは6たずえば2の仮想マシンが必芁です。







その結果、蚘茉されおいる仮想デヌタセンタヌのすべおのコンポヌネントの正しい構成により、パフォヌマンスの面で非垞に印象的な結果を埗るこずができたす。

















4Kランダム、70読み取り/ 30曞き蟌み







実際、珟実の䞖界を単玔な匏で蚘述するのははるかに困難です。 単䞀のホストには、さたざたな構成ずIO芁件を持぀倚くの仮想マシンが垞にありたす。 はい。ホストプロセッサは、電力が無限ではないため、I / O凊理を行っおいたす。 したがっお、同じモデルの可胜性を最倧限に匕き出すには、実際にはP710に3぀のホストが必芁です。 さらに、仮想マシン内で実行されるアプリケヌションが調敎を行いたす。 したがっお、正確なサむゞングのために、実際の珟圚のタスクのために顧客のむンフラストラクチャ内のすべおのFlash AccelStorアレむのテストモデルの堎合にテストを䜿甚するこずをお勧めしたす。








All Articles