ログ ボリュームのベスト プラクティスについて教えてください。
ログの最適なサイズは、環境とワークロードによって大きく異なり、ワークロードが実行する書き込み IO の量によって決まります。
ログの大きさは、処理速度には影響を与えません
ログのサイズ、またデータ ボリュームが、たとえば、10 GB か 10 TB かは、パフォーマンスに影響を及ぼしません
サイズの大きいログは、単純に、一杯になるまでに多くの書き込み IO を収集して保持できます。これにより、ログのソースと保存先コンピューターの間での、長時間にわたるサービス中断に対処できます (ネットワークの切断や保存先コンピューターのオフラインなど)。 ログが 10 時間分の書き込みを保持できる場合、ネットワークが 2 時間ダウンしても、ネットワークの復旧時にソース側から保存先に対して同期されていない変更の差分を素早く同期すれば、短時間で保護された状態に回復します。 しかし保持されるログが 10 時間分である場合に、ネットワークが 2 日間ダウンすると、ソース側はビットマップと呼ばれる別のログから再生する必要があるため、同期状態への回復に時間がかかります。同期された後は、元どおりログを使用できます。
記憶域レプリカのすべての書き込みパフォーマンスはログに依存します。 ログのパフォーマンスは、レプリケーションのパフォーマンスにとって重要です。 ログ ボリュームには、ログではすべての書き込み IO がシリアル化、シーケンス化されるため、ログ ボリュームはデータ ボリュームよりも高速に動作するデバイスを使用する必要があります。 ログ ボリュームでは、常に SSD などのフラッシュ メディアを使う必要があります。 ログ ボリューム上では、他のワークロードの実行を絶対に許可しないでください。同様に、SQL データベースのログ ボリューム上で他のワークロードの実行を許可しないでください。
繰り返しますが、ログ ストレージには、データ ストレージよりも高速に動作するデバイスを使用することをお勧めします。またログ ボリュームは、絶対に他のワークロードに使用しないでください
Test-SRTopology ツールを実行することにより、ログ サイズに関する推奨事項を取得できます。 または、既存のサーバーでパフォーマンス カウンターを使用して、ログ サイズを判断することもできます。 式は簡単です。ワークロードの下でデータ ディスクのスループット (平均書き込みバイト数/秒) を監視し、それを使用して、さまざまなサイズのログがいっぱいになるまでの時間を計算します。 たとえば、データ ディスクのスループットが 50 MB/秒の場合、120 GB のログは 120 GB/50 MB 秒つまり 2,400 秒つまり 40 分でいっぱいになります。 そのため、ログがいっぱいになる前に、レプリケーション先サーバーに到達できないでいられる時間は 40 分です。 ログがいっぱいになっても、レプリケーション先が再び到達可能になった場合、ソースはメイン ログではなくビット マップ ログを介してブロックを再生します。 ログのサイズはパフォーマンスに影響しません。
ソース クラスターのデータ ディスクのみをバックアップする必要があります。 記憶域レプリカ ログのディスクは、バックアップが記憶域レプリカの操作と競合する可能性があるため、バックアップすることはできません。