SQL Serverを使用する複数のPVSCSI
SQL Serverの仮想化に関して、ログデバイスからデータデバイスを別の準仮想SCSI（PVSCSI）アダプターに分離することでパフォーマンスにプラスの影響があるかどうかを確認するために、行われていることと同様に ここ としています。
クライアントで、PVSCSIが追加され、ログデバイスが新しいPVSCSIに分離されたシナリオがあり、パフォーマンスが大幅に向上しています。しかし、それがこの分離によるものなのか、単に追加のPVSCSIが現在存在するという事実によるものなのか、疑問は残ります。
知られているように、ログディスクは通常、順次に書き込まれますが、データディスクはr/wでよりランダムなパターンに従い、これら2つの異なる種類のファイルを別々のディスクに配置することでパフォーマンス上の利点があります。
しかし、コントローラはどうですか？これらの異なるパターンを別々のPVSCSIコントローラーに保持することにも利点はありますか？
誰かこれについて何か洞察がありますか？
前もって感謝します
私は2つの部分で回答します。最初に、「シーケンシャルとランダムの分離に関する従来の回答が適用されない理由」です。
次に、Windowsの物理ディスクでファイルを分離し、vHBAを追加してそれらの間で物理ディスクを分散することの潜在的な利点について説明します。
ランダムディスクとシーケンシャルディスクを分離することで得られるメリットを期待IO Windows物理ディスクレベルでは、通常、データストレージ用のHDDデバイスを想定しています。また、Windows物理ディスクを個別化すると、個別のHDDデバイスを意味すると想定しています。 HDDのセットは主にシーケンシャルディスクIOを処理し、非常に限られたディスクヘッドの動き（たとえば、単一のビジーtxlog *をホストするHDD）を持っています）ながら、別のHDDのセットはランダムディスクIOを処理しています。
これらの仮定が今日、特にVMで当てはまることはほとんどありません。まず、VMのWindows物理ディスクがRDMでない限り、複数が単一のデータストアに存在する可能性があります-または、単一のESXiホストLUNに複数のデータストアが存在する可能性があります。したがって、ゲストで分離されているものは、ESXiホストレベルで混合できます。
しかし、RDMが使用されている、または各ゲスト物理ディスクが独自のESXi LUN上の独自のデータストアにあるとしましょう。それでも、ESXiホストに提供されるLUNがディスクデバイスの同じ単一のプールからのものである可能性があるため、ゲストでランダムioとは別のシーケンシャルがアレイで混合されることがよくあります。現在、ほぼすべてのストレージアレイが、これを独占的に、またはオプションとして、管理を容易にし、アレイの効率/リソース使用率を向上させるためにこれを実行しています。
最後に、今日のストレージの多くは、オールフラッシュまたはハイブリッドフラッシュ+ HDDです。頭の動きを気にする必要がないので、フラッシュはランダムとシーケンシャルの分離を気にしません…IOウィービングを気にしません。
ですから…シーケンシャルをランダムから分離することのすべてがそれほど有益ではないかもしれません。次に、物理ディスク全体にファイルを分散したり、vHBA全体に物理ディスクを分散したりしても、パフォーマンスが向上するのはなぜですか。
*このHDDの例では、1つのトランザクションログについて意図的に言及しました。複数の個別のシーケンシャルディスクIOストリーム（たとえば、8つのビジートランザクションログ）が同じHDDで発生している場合-何らかの理由でほとんどすべてのアクティビティがSANキャッシュ-順次IOトラック間でヘッドが一定の動きをすると、IOウィービングにつながります。これは、ディスクレイテンシの原因となる特定の種類のディスクヘッドのスラッシングです。 RAID5はRAID5とRAID10で発生しますが、RAID10はこの点でRAID5よりも多少の変動を許容できますが、大幅に低下します。
さて、ランダムからシーケンシャルを分離することがいかに役立たないかもしれないという話が長引いたとしても、物理ディスク間でファイルを分散することで、いまだに役立つでしょうか？ vHBA間で物理ディスクを分散するとどのように役立ちますか？
それはすべてディスクIOキューに関するものです。
すべてのWindows物理ディスクまたはLogicalDiskは、perfmonによって「現在のディスクキュー」として報告される、一度に最大255個の未処理のディスクIOを持つことができます。 physicaldiskキュー内の未処理のディスクIOから、storportはミニドライバーに最大254を渡すことができます。ただし、ミニドライバーには、サービスキュー（次に低いレベルに渡される）と待機キューの両方がある場合もあります。そしてstorportはそれが渡す数を254から下げるように言うことができます。
VMware Windowsゲストでは、pvscsiドライバーのデフォルトの「デバイス」キュー深度は64で、デバイスは物理ディスクです。したがって、perfmonは単一の物理ディスクの「現在のディスクキューの長さ」で最大255のディスクIOを表示できますが、一度に次のレベルに渡されるのは最大64のみです（デフォルトが変更されない限り）。
一度に1つビジーなトランザクションログに対して未処理のディスクIOはいくつありますか？トランザクションログの書き込みのサイズは最大60kbです。大規模なETLでは、txlogへのすべての書き込みが60kbで行われることがよくあります。 txlogライターでは、一度に1つのtxlogに対して最大32の60kbの書き込みを処理できます。では、デフォルトのVMware設定で、ビジーステージングtxlogとビジーdw txlogが同じ物理ディスク上にある場合はどうなりますか？両方のtxlogがそれぞれ32の未処理の60kb書き込みで最大になっている場合、その物理ディスクはキューの深さ64にあります。さて、物理ディスクにETLソースとしてフラットファイルもある場合はどうなるでしょうか。まあ...フラットファイルへの読み取りとtxlog書き込みの間では、一度に64しか取得できないため、待機キューを使用する必要があります。物理サーバーであろうと仮想であろうと、このようなビジーなtxlogがあるデータベースでは、txlogを物理ディスク上に置くことをお勧めします。これにより、そのレベルでのキューイングが防止され、複数のファイルのインターリーブの内容に関する懸念もなくなります（最近の懸念ははるかに少なくなっています）。
一度にいくつのディスクIOが行ファイルに対して未処理である可能性がありますか（SQL Serverの観点から、必ずしもより低いレベルに送信されるとは限りません）？ SQL Server自体に制限はありません（とにかく私が見つけたものです）。しかし、ファイルが単一のWindows物理ディスク上にあると仮定すると（SQL Serverにストライプダイナミックディスクを使用することはお勧めしません。これは別のトピックのトピックです）、そこにis制限。前に言った255です。
SQL Serverの先読みと非同期IOの魔法により、4つの同時クエリがそれぞれシリアルドライブで実行され、合計 "現在のディスクキューの長さ"が1200を超えています。 255の制限があるため、単一の物理ディスク上のすべての行ファイルの内容では、これは不可能です。それは、それぞれが独自の物理ディスク上にある、8つのファイルを持つプライマリファイルグループに対するものでした。
したがって、先読み読み取りは非常に積極的で、IOキューにストレスをかける可能性があります。他の行ファイルの読み取りと書き込みが最終的に待機状態になる可能性があります。トランザクションログが行ファイルと同じ物理ディスク上にある場合、先読み読み取りとtxlog書き込みを同時に行うと、待機するのが非常に簡単になります。その待機が「現在のディスクキューの長さ」レベルでなくても、デバイスキュー（デフォルトではpvscsiで64）で待機している可能性があります。
特にバックアップスループットを最大化するためにバッファー数が調整されている場合は、行ファイルに対するバックアップ読み取りも積極的です。
Txlogの分離を検討する際に注意する必要があるSQL Serverのioタイプがもう1つあります。tempdbへのクエリ流出です。クエリのスピルが発生すると、スピルが機能するたびにtempdbに書き込みます。多くの並列ワーカーがすべて同時にこぼれますか？それはかなりの書き込み負荷になる可能性があります。忙しいtxlogと重要な行ファイルをそれから遠ざけることは本当に役に立ちます:-)
これで、pvscsiドライバーのデフォルトのデバイスキューの深さを変更できます。デフォルトは64で、最大Storportが渡される254まで設定できます。ただし、これを変更する場合は注意してください。ゲストデバイスのキューの深さを、基盤となるESXiホストLUNのキューの深さに合わせることを常にお勧めします。また、アレイごとのESXiホストLUNキューの深さのベストプラクティスを設定します。 EMC VNXを使用していますか？ホストLUNキューの深さは32である必要があります。ゲストはRDMを使用しますか？すごい。ゲストのpvscsiデバイスのキューの深さを32に設定して、ESXiホストLUNのキューの深さに合わせます。 EMC VMAX？通常、ESXiホストレベルでは64、ゲストでは64。 Pure/Xtremio/IBM FlashSystem？ホストLUNキューの深さが256に設定される場合があります。次に、pvscsiデバイスキューの深さを254（最大可能）に設定します。
手順が記載されたリンクです。 https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
リンクは、requestringpages-WhatAreThose ??についても話します。それらは、pvscsiアダプター自体のキューの深さを決定します。各ページは、アダプターキューの深さで32スロットを提供します。デフォルトでは、アダプタキューの深さが256の場合、requestringpagesは8です。1024のアダプタキューの深さのスロットでは、32まで設定できます。
すべてがデフォルトであるとしましょう。行ファイルを含む8つの物理ディスクがあり、SQL Serverは少しビジーです。 8の平均で「現在のディスクキューの長さ」は32であり、64以下である（すべてがさまざまなデバイスサービスキューに収まる）。素晴らしい-それは256 OIOを与えます。これは、デバイスサービスキューに適合し、アダプターサービスキューに適合しているため、256個すべてがゲストからESXホストレベルのキューに移動します。
しかし、少し忙しくなると、物理ディスクのキューが128に達する平均64になります。64を超える未処理のデバイスの場合、超過は待機キューにあります。 256を超えるものが8つの物理ディスクのデバイスのサービスキューにある場合、アダプタサービスキューのスロットが開くまで、待機キューに超過があります。
その場合、別のpvscsi vHBAを追加し、それらの間に物理ディスクを分散すると、アダプターキューの合計深度が512に倍増します。同時に、ゲストからホストにさらにioを渡すことができます。
1つのpvscsiアダプターにとどまり、requestringpagesを増やすことによって、同様のことが実現できます。 16に移動すると512スロット、32は1024スロットになります。
可能な場合は、深く（アダプターキューの深さを増やす）前に、幅を広く（アダプターを追加）することをお勧めします。しかし...最もビジーなシステムの多くでは、両方を実行する必要があります。ゲストに4つのvHBAを配置し、requestringpagesを32に増やします。
他にも多くの考慮事項があります。 vmdksが使用されている場合のsiocおよび適応キュー深度の調整、マルチパスの構成、LUNキュー深度を超えるESXiアダプターの構成など。
しかし、私は私の歓迎を無期限に過ごしたくありません:-)
ロニー・ニーダーシュタット@sqL_handLe