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