最適なパフォーマンスを得るには、以下の推奨事項に従う必要があります。これには、Windows オペレーティングシステムとAWSクラウドの両方の構成に固有の考慮事項が含まれています。SIOS DataKeeper の主要コンポーネントは、上位のフィルターボリュームドライバーです。このドライバーは、ソースボリュームに送信されるすべてのリクエストを追跡および処理するため、すべてのボリューム操作でオーバーヘッドが発生します。適切に設定すればこのオーバーヘッドは2％になりますが、通常クラウド環境ではこの数値は実現できません。一般的なお客様の場合、クラウドでの運用時のオーバーヘッドは10～20％になります。
- インスタンスのサイズ - レプリケーションのパフォーマンスは、いくつかの要因に依存しています。CPU の使用量は最小限ですが、RAM 使用率は、ネットワークのパフォーマンス、ピーク時のアクティブなワークロード、ボリューム読み取り/書き込みのレイテンシ、および負荷がかかっている状態での同時ミラーの数に完全に依存します。これらの考慮事項により、最低でも中程度のネットワークパフォーマンスを持つインスタンスサイズを使用し、デフォルトでEBS最適化を有効にし、EBS 専用ではないインスタンスストレージボリュームを少なくとも1つ使用することを推奨します。r3.xlarge インスタンスサイズは、パフォーマンスが問題になる場合の最小推奨インスタンスサイズです。SIOS DataKeeper は、現在利用可能なあらゆるサイズのインスタンスにインストールできます。サポートされているすべてのサイズのリストは、「サポートされているインスタンスサイズ」を参照してください。
- インスタンスストレージの自動初期化 -ビットマップ用にインスタンスストレージを使用している場合は、Amazon EC2Launch のディスクの初期化スクリプトが、インスタンスストレージディスクを自動的に初期化するよう設定されていることを確認してください。 Powershell スクリプト “get-scheduledtasks”を実行して 、システムの起動時に “InitializeDisks.ps1” スクリプトが自動的に実行されるように設定されているかを確認することができます。EC2Launch V2 サービスを使用している場合は、ボリュームの初期化タブを参照し、ボリュームが起動時に初期化されるよう設定されていることを確認してください。
これら Amazon の初期化スクリプトはインスタンスストレージディスクを初期化し、それらのディスク上にボリュームを作成します。(降順でドライブレターを割り当てます。Z: がデフォルトで、Z: が使用中の場合は Y: を使用します。) Amazon スクリプトがビットマップドライブに正しいドライブレターを割り当てるよう設定してください。
- EBS の最適化 - AWSでDKを使用する際に優れたパフォーマンスを実現するには、この機能を有効/Trueにする必要があります。以下のコマンドを使用していることを確認してください。
aws ec2 describe-instances —instance-ids instance_id —region region —query “Reservations[].Instances[].EbsOptimized”
- ENAサポート（拡張ネットワーク） – AWSでDKを使用する際に優れたパフォーマンスを実現するには、この機能を有効/Trueにする必要があります。以下のコマンドを使用していることを確認してください。
aws ec2 describe-instances —instance-ids instance_id —region region —query “Reservations[].Instances[].EnaSupport”
- インスタンスストレージ - SIOS DataKeeper のいくつかの機能は、非常に低いレイテンシのボリュームアクセスに依存しています。ビットマップストレージは、非EBSのみのインスタンスストレージボリュームに常駐するように構成する必要があります。ワークロードに書き込みが多く、必要なオーバーヘッドが最小限である場合、SIOSは、DataKeeperビットマップをEBSのみではないインスタンスストレージボリュームに配置することをお勧めします。汎用SIOS DataKeeper AMI のいずれかを使用する場合、これは自動的に構成されるはずですが、SIOS DataKeeper を手動でインストールするノードでは、手動で構成する必要があります。（インテントログの再配置 を参照してください。）。Windows AMI 上で SIOS DataKeeper for SAP ASCS/ERS を使用する場合も、この設定は構成されていないので手動構成が必要です。ビットマップファイルを、ストライプ化された複数のディスクで構成されるストレージプールボリュームまたは低レイテンシの io1 ボリュームに配置することもできます。本番環境でこれらの方法のいずれかを使用する前に、コストパフォーマンスが低下するかどうかを評価し、パフォーマンステストを行う必要があります。ただし、インスタンスストレージボリュームの使用は非常に低コストであり、不要な構成を必要とせずに同等のパフォーマンスを提供します。
- ボリュームのプロパティ - 適切なミラー操作に必要なのはシンプルボリュームのみですが、より高度な手法を使用して読み取り/書き込みのレイテンシを最小限に抑えることができます。SIOS では、ソースシステムとターゲットシステムの両方でミラーボリュームをサポートするために、同一のストレージプールを作成することを推奨します。この QuickStart は、デプロイ中にストレージプールを構成しません。Storage Spaces Direct は SIOS DataKeeper と互換性がないため、使用しないでください。 https://techcommunity.microsoft.com/t5/Storage-at-Microsoft/Using-the-Storage-Pools-page-in-Server-Manager-to-create-storage/ba-p/424656
- システムのスナップショットをロールバックする – スナップショットを取得すると、その時点のシステムの状態を知ることができます。AWS / Azure を使用する場合 – システムが、全システムのスナップショットを使用してリストアした場合、リストア完了後に 両システム のデータを同一のものにするため 、全てのミラー ( ソースシステムもしくはターゲットシステム に関係なく) に対して 全同期を強制的に行う 必要があります。
RTO and RPO
RTO (Recovery Time Objective)
RTO および RPO – SIOS DataKeeperによって、一般的なクラスタの単一サーバー停止フェールオーバーRTOが大幅に増加するようなことはありません。適切なインスタンスサイズが使用され、リソース競合の問題がなく、SIOS DataKeeper は適切に構成され、ミラーリング状態にあり、アプリケーションの復旧時間がわずかであると仮定すると、1分未満の RTO を実現できます。しかし、保護対象のアプリケーション（MSSQL、SAP など）の回復時間が異常に長い場合を除き、現実的には RTO は2～5分程度になると予想されます。
RPO (Recovery Point Objective)
同じ条件を想定すると、RPOは、ソースノードとターゲットノーの間の現在のネットワーク書き込みレイテンシよりも数ミリ秒だけ大きくなります。RPO は、パフォーマンスモニタカウンタ で測定できます。
多くの場合、RPO はミリ秒単位で測定されますが、ネットワークの輻輳、異常に多いディスク書き込み、ターゲットサーバーでの書き込みパフォーマンスの低下などは、RPO に大きな影響を与える可能性があります。SIOS DataKeeper は EBS スナップショットと競合せず、ソースシステムでこれらと組み合わせて使用できます。ただし、スナップショットからソースボリュームを復元することは容易ではなく、上記の RPO ガイドラインを再度適用する前に、該当するミラーによって保護されているすべてのデータを完全に再同期する必要があります。
このトピックへフィードバック