DDR オーガニゼーションの作成

1. [Get Started with Datadog] (Datadog を始める) に移動します。場合によっては、このページにアクセスするには、現在のセッションからログアウトするか、シークレットモードを使用する必要があります。
2. プライマリとは異なる Datadog サイトを選択します (例: US1 を使用している場合は EU または US5 を選択します)。オプションについては、Datadog サイトのリストを参照してください。すべての Datadog サイトは地理的に分離されています。
3. プロンプトに従ってアカウントを作成します。

Datadog との DDR オーガニゼーション情報の共有

新しいオーガニゼーション名を カスタマーサクセスマネージャー にメールでご連絡ください。その後、カスタマーサクセスマネージャーがこの新しいオーガニゼーションを DDR オーガニゼーションとして設定します。

Datadog が DDR オーガニゼーションを指定した後、DDR オーガニゼーションをプライマリオーガニゼーションにリンクします。

1. List your managed organizations エンドポイントを使用して、プライマリオーガニゼーションと DDR オーガニゼーションのパブリック ID を取得します。

2. プライマリオーガニゼーションのアプリケーションキーに disaster_recovery_status_write スコープを追加します。

3. プレースホルダーを適切な値に置き換えて、以下のコマンドを実行します。

   export PRIMARY_DD_API_KEY=<PRIMARY_ORG_API_KEY>
   export PRIMARY_DD_APP_KEY=<PRIMARY_ORG_APP_KEY>
   export PRIMARY_DD_API_URL=<PRIMARY_ORG_API_SITE>
   
   export DDR_ORG_ID=<DDR_ORG_PUBLIC_ID>
   export PRIMARY_ORG_ID=<PRIMARY_ORG_PUBLIC_ID>
   export USER_EMAIL=<USER_EMAIL>
   export CONNECTION='{"data":{"id":"'${PRIMARY_ORG_ID}'","type":"hamr_org_connections","attributes":{"TargetOrgUuid":"'${DDR_ORG_ID}'","HamrStatus":1,"ModifiedBy":"'${USER_EMAIL}'", "IsPrimary":true}}}'
   
   curl -v -H "Content-Type: application/json" -H \
   "dd-api-key:${PRIMARY_DD_API_KEY}" -H \
   "dd-application-key:${PRIMARY_DD_APP_KEY}" --data "${CONNECTION}" --request POST ${PRIMARY_DD_API_URL}/api/v2/hamr
   

オーガニゼーションをリンクすると、フェイルオーバーオーガニゼーションにこのバナーが表示されます。

障害発生時にすべてのユーザーが DDR オーガニゼーションにログインできるようにするため、Datadog はシングルサインオン (SSO) を使用することを推奨しています。

DDR オーガニゼーションの Organization Settings に移動して、ユーザー向けに SAML または Google Login を構成します。

マネージド同期により、プライマリオーガニゼーションから DDR オーガニゼーションにユーザーアカウントが複製されます。Datadog では SAML を使用したジャストインタイムプロビジョニング を構成することを推奨しています。これにより、ユーザーはフェイルオーバー中にパスワードをリセットすることなく DDR オーガニゼーションにアクセスできます。

セットアップ手順については、AWS、Azure、および Google Cloud のインテグレーションを参照してください。

プライマリオーガニゼーションと DDR オーガニゼーションの両方でクラウドインテグレーションを構成する必要がありますが、クラウドインテグレーションは一度にいずれか 1 つのオーガニゼーションでのみ実行されます。デフォルトではプライマリオーガニゼーションで実行され、フェイルオーバー中は DDR オーガニゼーションで実行されます。

詳細については、クラウドインテグレーションのフェイルオーバーのセクションを参照してください。

Datadog はオープンソースの datadog-sync-cli ツールを使用して、お客様に代わってリソース同期を管理します。このツールをお客様自身で実行または運用する必要はありません。

マネージド同期により、定期的なスケジュールでプライマリオーガニゼーションから DDR オーガニゼーションにリソースが複製されます。複製されるリソースには、ダッシュボード、モニター、ユーザー、ノートブック、および 34 種類以上のその他のリソース が含まれます。複製はこのスケジュールで実行されます。これにより、障害発生までに DDR オーガニゼーションが最新の状態に保たれます。

**ユーザーは各 Datadog サイトにスコープ設定されます。**マネージド同期により、ユーザーアカウントが DDR オーガニゼーションに複製されます。ただし、ユーザーが DDR オーガニゼーションに初めてログインするときに、パスワードのリセットが必要になる場合があります。Datadog では、SAML を使用したジャストインタイムプロビジョニング を構成することを推奨しています。これにより、手動でのパスワードリセットなしでユーザーが DDR オーガニゼーションにアクセスできるようになります。

**マネージド同期は、Datadog の サービスアカウント を使用します。**プライマリオーガニゼーションからリソースを読み取って複製するために、オンボーディング中に DDR オーガニゼーションでサービスアカウントを作成します。マネージド同期によって同期されたリソースは、可能な場合には元のオーナーにマッピングされたユーザーによってプロビジョニングされます。

Remote Configuration (RC) では、インフラストラクチャーにデプロイされた Datadog Agent の構成とその動作の変更をリモートで行うことができます。

Remote Configuration は新しいオーガニゼーションに対してデフォルトで有効になっています。作成する新しい API キーに対し、Agent で使用するために Remote Configuration が有効になります。。詳細については、Remote Configuration のドキュメント を参照してください。

Datadog では、より優れたフェイルオーバー制御のために Remote Configuration を使用することを強く推奨しています。Remote Configuration の代替手段として、Datadog Agent を手動で構成するか、Puppet、Ansible、Chef などの構成管理ツールを使用できます。

デュアルシッピングを有効にするには、大規模な管理のために Fleet Automation を使用することが推奨されます。または、datadog.yaml ファイルを編集して手動で構成することもできます。

パフォーマンスと目標復旧時間 (RTO) を測定するフェイルオーバーテストのための専用時間枠をスケジュールするには、Datadog カスタマーサクセスマネージャーまでご連絡ください。

DDR オーガニゼーションの Fleet Automation > Configure Agents に移動してフェイルオーバーポリシーを作成するか、既存のポリシーを再利用し、Agent のフリートに適用します。ポリシーが有効になるとすぐに、Agent はプライマリと DDR (フェイルオーバー) の両方の監視可能性サイトへのテレメトリのデュアルシッピングを開始します。

フェイルオーバーポリシーを作成するには、Create Failover Policy をクリックします。

次に、プロンプトに従ってフェイルオーバーする必要があるホストとテレメトリ (メトリクス、ログ、トレース) のスコープを設定します。

Cloud Integrations は、プライマリ Datadog サイトまたは DDR Datadog サイトのいずれか 1 つでのみ実行できますが、両方で同時に実行することはできません。そのためフェイルオーバーすると、プライマリサイトで Cloud Integrations データが停止します。インテグレーションのフェイルオーバー中には、インテグレーションは DDR データセンターでのみ実行されます。フェイルオーバーでなくなった場合は、フェイルオーバーポリシーを無効にして、インテグレーションデータ収集をプライマリオーガニゼーションに戻します。

フェイルオーバー中またはフェイルオーバー演習中は、以下の例に示すように Datadog Agent の datadog.yaml 構成ファイルを更新し、Agent を再起動します。

• enabled: trueでは、Agent が metadataAgent とインフラストラクチャーホストに関するデータ。例: host name、host tags、Agent version。 を DDR Datadog サイトに送信できるようになり、DDR オーガニゼーションで Agent とインフラストラクチャーホストを確認できます。これにより、フェイルオーバーオーガニゼーションで Agent とインフラストラクチャーホストを確認できるようになります。

• failover_metrics、failover_logs、およびfailover_apm はデフォルトで false です。これらを true に設定すると、Agent が DDR オーガニゼーションへの telemetryDatadog プラットフォームに送信されるデータ。例:logs、metrics、traces。 の送信を開始します。

multi_region_failover:
  enabled: true
  failover_metrics: false
  failover_logs: false
  failover_apm: false
  site: <DDR_SITE>  # For example, "site: us5.datadoghq.com" for a US5 site
  api_key: <DDR_SITE_API_KEY>

DNS ベースのフェイルオーバーは、Agent ベースのフェイルオーバーを補完するアプローチです。Agent にセカンダリサイトのエンドポイントを構成する代わりに、すべてのデータソースが Datadog 提供の単一カスタムインテイク URL にテレメトリを送信するように構成します。フェイルオーバーイベントの発生中は、Datadog がその URL の DNS レコードを更新し、トラフィックをプライマリサイトから DDR サイトへリダイレクトします。

カスタム DNS エンドポイントの受信

DNS ベースのフェイルオーバーを使用することを選択した場合、Datadog はオーガニゼーションのカスタムインテイク URL (例: <your-org>.intake.datadoghq.com) をプロビジョニングします。すべてのデータソース (Agent、ログシッパー、カスタムインスツルメンテーションなど) が、デフォルトの Datadog インテイク URL ではなく、このエンドポイントにテレメトリを送信するように構成します。これは一度限りの構成変更です。

DNS フェイルオーバーのトリガー

DNS フェイルオーバーを開始するには、カスタマーサクセスマネージャーまたは Datadog サポートにお問い合わせください。Datadog はトラフィックをプライマリサイトから DDR サイトにリダイレクトするため、DNS レコードを更新します。目標復旧時間 (RTO) は、フェイルオーバー開始時点から 2 時間です。

Agent のフェイルオーバーをトリガーするには、DDR オーガニゼーションの Fleet Automation にあるポリシーの 1 つをクリックし、Enable をクリックします。フェイルオーバーが発生すると、各ホストのステータスが更新されます。

ご使用の環境に該当する手順を使用して、DDR フェイルオーバーを有効にしてテストします。

agent config set multi_region_failover.failover_metrics true
agent config set multi_region_failover.failover_logs true
agent config set multi_region_failover.failover_apm true

kubectl exec <POD_NAME> -c agent -- agent config set multi_region_failover.failover_metrics true
kubectl exec <POD_NAME> -c agent -- agent config set multi_region_failover.failover_logs true
kubectl exec <POD_NAME> -c agent -- agent config set multi_region_failover.failover_apm true

multi_region_failover:
  enabled: true
  failover_metrics: true
  failover_logs: true
  failover_apm: true
  site: NEW_ORG_SITE
  api_key: NEW_SITE_API_KEY

DD_MULTI_REGION_FAILOVER_ENABLED=true
DD_MULTI_REGION_FAILOVER_FAILOVER_METRICS=true
DD_MULTI_REGION_FAILOVER_FAILOVER_LOGS=true
DD_MULTI_REGION_FAILOVER_FAILOVER_APM=true
DD_MULTI_REGION_FAILOVER_SITE=ADD_NEW_ORG_SITE
DD_MULTI_REGION_FAILOVER_API_KEY=ADD_NEW_SITE_API_KEY

DDR オーガニゼーションのランディングページから、クラウドインテグレーションのフェイルオーバーをテストできます。

フェイルオーバーのランディングページで、DDR オーガニゼーションのステータスを確認するか、[Fail over your integrations] (インテグレーションをフェイルオーバー) をクリックしてクラウドインテグレーションのフェイルオーバーをテストします。

フェイルオーバーでなくなった場合は、DDR オーガニゼーションでフェイルオーバーポリシーを無効にして、インテグレーションデータ収集をプライマリオーガニゼーションに戻します。

テスト中、インテグレーションテレメトリは両方のオーガニゼーションに分散されますフェイルオーバーテストをキャンセルすると、インテグレーションは再びプライマリデータセンターで実行されます。