最適なパフォーマンスを得るには、以下の推奨事項に従う必要があります。これには、Windows オペレーティングシステムとAWSクラウドの両方の構成に固有の考慮事項が含まれています。SIOS DataKeeper の主要コンポーネントは、上位のフィルターボリュームドライバーです。このドライバーは、ソースボリュームに送信されるすべてのリクエストを追跡および処理するため、すべてのボリューム操作でオーバーヘッドが発生します。適切に設定すればこのオーバーヘッドは2%になりますが、通常クラウド環境ではこの数値は実現できません。一般的なお客様の場合、クラウドでの運用時のオーバーヘッドは10〜20%になります。

  • インスタンスのサイズ - レプリケーションのパフォーマンスは、いくつかの要因に依存しています。CPU の使用量は最小限ですが、RAM 使用率は、ネットワークのパフォーマンス、ピーク時のアクティブなワークロード、ボリューム読み取り/書き込みのレイテンシ、および負荷がかかっている状態での同時ミラーの数に完全に依存します。これらの考慮事項により、最低でも中程度のネットワークパフォーマンスを持つインスタンスサイズを使用し、デフォルトでEBS最適化を有効にし、EBS 専用ではないインスタンスストレージボリュームを少なくとも1つ使用することを推奨します。r3.xlarge インスタンスサイズは、パフォーマンスが問題になる場合の最小推奨インスタンスサイズです。SIOS DataKeeper は、現在利用可能なあらゆるサイズのインスタンスにインストールできます。サポートされているすべてのサイズのリストは、「サポートされているインスタンスサイズ」を参照してください。
  • 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 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

RTO および RPOSIOS DataKeeperによって、一般的なクラスタの単一サーバー停止フェールオーバーRTOが大幅に増加するようなことはありません。適切なインスタンスサイズが使用され、リソース競合の問題がなく、SIOS DataKeeper は適切に構成され、ミラーリング状態にあり、アプリケーションの復旧時間がわずかであると仮定すると、1分未満の RTO を実現できます。しかし、保護対象のアプリケーション(MSSQL、SAP など)の回復時間が異常に長い場合を除き、現実的には RTO は2〜5分程度になると予想されます。

同じ条件を想定すると、RPOは、ソースノードとターゲットノーの間の現在のネットワーク書き込みレイテンシよりも数ミリ秒だけ大きくなります。RPO は、パフォーマンスモニタカウンタ で測定できます。

多くの場合、RPO はミリ秒単位で測定されますが、ネットワークの輻輳、異常に多いディスク書き込み、ターゲットサーバーでの書き込みパフォーマンスの低下などは、RPO に大きな影響を与える可能性があります。SIOS DataKeeper は EBS スナップショットと競合せず、ソースシステムでこれらと組み合わせて使用できます。ただし、スナップショットからソースボリュームを復元することは容易ではなく、上記の RPO ガイドラインを再度適用する前に、該当するミラーによって保護されているすべてのデータを完全に再同期する必要があります。

フィードバック

お役に立ちましたか?

はい いいえ
お役に立ちましたか
理由をお聞かせください
フィードバックありがとうございました

このトピックへフィードバック

送信