翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Outpost のメンテナンス
責任共有モデル
警告
インスタンスストアボリュームのデータは、基盤となるディスクドライブが故障した場合、またはインスタンスが 停止、休止状態、または終了した場合に失われます。データ損失を防ぐため、インスタンスストアボリュームの長期データを、Amazon S3 バケット、Amazon EBSボリューム、オンプレミスネットワーク内のネットワークストレージデバイスなどの永続的ストレージにバックアップすることをお勧めします。
内容
ハードウェアメンテナンス
がサーバーのプロビジョニングプロセス中、または Outpost で実行されている Amazon EC2インスタンスをホスト中にハードウェアで回復不可能な問題 AWS を検出した場合、影響を受けたインスタンスのリタイアが予定されていることを Outpost の所有者とインスタンスの所有者に通知します。詳細については、「Amazon ユーザーガイド」の「インスタンスの廃止」を参照してください。 EC2
Outpost の所有者とインスタンスの所有者は、共に問題を解決することができます。インスタンスの所有者は、影響を受けるインスタンスを停止してから再起動し、利用可能な容量に移行させることができます。インスタンスの所有者は、自分たちにとって便利なタイミングで影響を受けるインスタンスを停止および再起動できます。それ以外の場合、 はインスタンスの廃止日に影響を受けるインスタンス AWS を停止して起動します。Outpost に追加の容量がない場合、インスタンスは停止した状態のままとなります。Outpost の所有者は、使用済みの容量を解放するか、Outpost に追加の容量をリクエストして移行を完了させることができます。
ハードウェアのメンテナンスが必要な場合は、Outpost サイトのマネージャー AWS に連絡して、 AWS インストールチームが訪問する日時を確認します。訪問は、サイトのマネージャーが AWS チームと話し合ってから最短で 2 営業日以内にスケジュールできます。
AWS インストールチームが現場に到着すると、異常なホスト、スイッチ、またはラック要素を置き換え、新しい容量をオンラインにします。オンサイトでハードウェアの診断や修理を行うことはありません。ホストを置き換えると、 NIST準拠の物理セキュリティキーを削除して破棄し、ハードウェアに残っている可能性のあるデータを効果的にシュレッダー処理します。これにより、データがサイトから流出することがなくなります。Outpost ネットワーク デバイスを交換する場合、デバイスがサイトから削除されたときにネットワーク構成情報がデバイス上に存在する可能性があります。この情報には IP アドレスが含まれ、ローカルネットワークまたはリージョンへのパスを設定するための仮想インターフェイスを確立するASNsために使用されます。
ファームウェアの更新
通常、Outpost ファームウェアを更新しても、Outpost 上のインスタンスには影響しません。まれに、アップデートをインストールするために Outpost 機器の再起動が必要になる場合があり、その容量で実行されているインスタンスについてインスタンスの廃止通知が届きます。
ネットワーク機器のメンテナンス
Outpost ネットワークデバイス (OND) のメンテナンスは、通常の Outpost オペレーションやトラフィックに影響を与えずに実行されます。メンテナンスが必要な場合、トラフィックは から遠ざけられますOND。AS-Path の付加などのBGPアドバタイズの一時的な変更や、Outpost アップリンクのトラフィックパターンの対応する変更に気付く場合があります。OND ファームウェアの更新では、BGPフラッピングが発生することがあります。
BGP 属性を変更せずに Outposts からBGPアドバタイズを受信するようにお客様のネットワーク機器を設定し、BGPマルチパス/ロードバランシングを有効にして、最適なインバウンドトラフィックフローを実現することをお勧めします。AS-Path プレフィックスは、メンテナンスONDsが必要な場合にトラフィックを から遠ざけるために、ローカルゲートウェイプレフィックスに使用されます。お客様のネットワークは、4 の AS-Path length のルートよりも、1 の AS-Path length の Outposts からのルートを優先する必要があります。
カスタマーネットワークは、同じ属性を持つ同じBGPプレフィックスをすべての にアドバタイズする必要がありますONDs。デフォルトでは、Outpost ネットワークロードバランスはすべてのアップリンク間でアウトバウンドトラフィックの負荷分散を行います。ルーティングポリシーは、メンテナンスONDが必要な場合にトラフィックを から遠ざけるために Outpost 側で使用されます。このトラフィックシフトでは、すべての で顧客側から同じBGPプレフィックスが必要ですONDs。お客様のネットワークでメンテナンスが必要な場合は、AS-Path への付加を使用して、特定のアップリンクからのトラフィックを一時的に移行することをお勧めします。
AWS Outposts 電力イベントとネットワークイベントのベストプラクティス
AWS Outposts お客様向けのAWS サービス条件
電力イベント
完全な停電では、 AWS Outposts リソースが自動的にサービスに戻らないという固有のリスクがあります。冗長電源およびバックアップ電源ソリューションの導入に加えて、最悪のシナリオの影響を軽減するために、事前に次のことを実行することをお勧めします。
-
DNSベースまたはラック外の負荷分散の変更を使用して、制御された方法でサービスとアプリケーションを Outposts 機器から移動します。
-
コンテナ、インスタンス、データベースを順序立てて停止し、それらを復元する際には逆の順序を使用してください。
-
サービスの移動または停止を制御するためのテスト計画。
-
重要なデータと構成をバックアップし、Outpost の外部に保存します。
-
電源のダウンタイムを最小限に抑えます。
-
メンテナンス中に電源 (off-on-off-on) を繰り返し切り替えないようにしてください。
-
予期せぬ事態に対処するために、メンテナンス期間内に余分な時間を確保してください。
-
通常必要とされるよりも広いメンテナンス時間枠を伝えることで、ユーザーや顧客の期待に応えます。
ネットワーク接続イベント
Outpost と AWS リージョンまたは Outposts ホームリージョン間のサービスリンク接続は、通常、ネットワークメンテナンスが完了すると、アップストリームの企業ネットワークデバイスまたはサードパーティーの接続プロバイダーのネットワークで発生する可能性のあるネットワークの中断や問題から自動的に復旧します。サービス リンク接続がダウンしている間、Outposts の操作はローカル ネットワーク アクティビティに限定されます。
詳細については、AWS Outposts ラックFAQs
オンサイトの電源の問題またはネットワーク接続の喪失によりサービスリンクがダウンした場合、 は Outposts を所有するアカウントに通知 AWS Health Dashboard を送信します。中断が予想される場合でも、ユーザーも もサービスリンクの中断の通知を抑制する AWS ことはできません。詳細については、「AWS Health ユーザーガイド」の「AWS Health Dashboardの開始方法」を参照してください。
ネットワーク接続に影響を与える計画的なサービス メンテナンスの場合は、次の予防的な手順を実行して、潜在的な問題のあるシナリオの影響を制限してください。
-
Outposts ラックがインターネットまたはパブリック Direct Connect を介して親 AWS リージョンに接続する場合は、計画的なメンテナンスの前にトレースルートをキャプチャします。動作中の (pre-network-maintenance) ネットワークパスと問題のある (post-network-maintenance) ネットワークパスを使用して違いを特定すると、トラブルシューティングに役立ちます。メンテナンス後の問題を AWS または にエスカレーションする場合はISP、この情報を含めることができます。
以下の間のトレース ルートをキャプチャします。
-
Outposts の場所のパブリック IP アドレスと、
outposts.によって返された IP アドレス。置換region.amazonaws.comregion親 AWS リージョンの名前。 -
パブリック インターネット接続と Outposts の場所のパブリック IP アドレスを持つ親リージョン内のインスタンス。
-
-
ネットワークのメンテナンスを管理している場合は、サービス リンクのダウンタイムの期間を制限します。メンテナンスプロセスに、ネットワークが回復したことを確認するステップを含めます。
-
発表されたメンテナンス期間の終了時にサービス リンクがバックアップされていない場合、ネットワーク メンテナンスを管理できない場合は、発表されたメンテナンス期間に関してサービス リンクのダウンタイムを監視し、計画されたネットワーク メンテナンスの担当者に早めにエスカレーションしてください。
リソース
計画的または計画外の電力イベントやネットワーク イベントの後、Outpost が正常に動作していることを保証できる監視関連リソースをいくつか紹介します。
-
AWS ブログ「 のベストプラクティスのモニタリング AWS Outposts
」では、Outposts に固有のオブザーバビリティとイベント管理のベストプラクティスについて説明しています。 -
AWS ブログ「Amazon からのネットワーク接続用のデバッグツールVPC
」では、AWSSupport-S etupIPMonitoringFromVPC ツールについて説明しています。このツールは、ユーザーが指定したサブネットに Amazon EC2 Monitor インスタンスを作成し、ターゲット IP アドレスをモニタリングする AWS Systems Manager ドキュメント (SSM ドキュメント) です。このドキュメントでは、pingMTR、、TCPトレースルート、トレースパスの診断テストを実行し、結果を Amazon CloudWatch Logs に保存します。その結果は CloudWatch ダッシュボードで視覚化できます (レイテンシー、パケットロスなど）。Outposts モニタリングの場合、モニターインスタンスは親 AWS リージョンの 1 つのサブネットにあり、プライベート IP (複数可) を使用して 1 つ以上の Outpost インスタンスをモニタリングするように設定する必要があります。これにより、 AWS Outposts と親 AWS リージョン間のパケット損失グラフとレイテンシーが提供されます。 -
AWS ブログ「 AWS Outposts を使用するための自動 Amazon CloudWatch ダッシュボードのデプロイ AWS CDK
」では、自動ダッシュボードのデプロイに関連する手順について説明しています。 -
質問がある場合、または詳細情報が必要な場合は、「AWS サポートユーザー ガイド」の「サポート ケースの作成」を参照してください。
