同じ Cloud Enterprise Network (CEN) インスタンスにアタッチされた複数の Virtual Private Cloud (VPC) が重複する vSwitch CIDR ブロックを持っている場合、それらの VPC 内の Elastic Compute Service (ECS) インスタンスは CEN を介して相互に通信できません。
症状
複数の VPC を CEN インスタンスにアタッチした後、VPC 間通信が失敗します。両方の VPC が同じ CEN インスタンスにアタッチされているにもかかわらず、ある VPC 内の ECS インスタンスが別の VPC 内の ECS インスタンスに到達できません。
原因
CEN はトランジットルーターを使用して、アタッチされた VPC 間でトラフィックを転送します。各 VPC は、その vSwitch CIDR ブロックをルートとしてトランジットルーターにアドバタイズします。2 つ以上の VPC に重複する CIDR ブロックを持つ vSwitch が含まれている場合、トランジットルーターは、特定のパケットの正しい宛先 VPC を判断できません。このルーティングの曖昧さにより、VPC 間通信が失敗します。
ソリューション
状況に最適なソリューションを選択してください。
| NAT ゲートウェイ | vSwitch の置き換え | |
|---|---|---|
| アプローチ | 重複する VPC 間でアドレスを変換するために NAT ゲートウェイを追加します。 | 重複する vSwitch を削除し、重複しない CIDR ブロックを持つ新しい vSwitch を作成します。 |
| ダウンタイム | ダウンタイムは不要です。 | 移行中に ECS インスタンスのシャットダウンが必要です。 |
| 継続的なコスト | NAT ゲートウェイインスタンスと CU 料金 | なし |
| 最適なシナリオ | ダウンタイムが許容されない本番環境 | メンテナンスウィンドウが利用可能な場合の永続的な修正 |
ソリューション 1: NAT ゲートウェイの使用
既存のネットワークトポロジーを変更することなく、重複する CIDR ブロックを持つ VPC 間で通信を可能にするために NAT ゲートウェイをデプロイします。NAT ゲートウェイは、送信元および宛先 IP アドレスを変換し、トラフィックがトランジットルーターを介して正しくルーティングされるようにします。
詳細な手順については、「NAT ゲートウェイを使用した重複 CIDR ブロックを持つ VPC 間のアクセス許可」をご参照ください。
ソリューション 2: vSwitch を重複しない CIDR ブロックに置き換える
重複する vSwitch を、一意の CIDR ブロックを使用する新しい vSwitch に置き換えます。これにより、ルーティングの競合が永続的に解決されますが、すべてのリソースの移行と ECS インスタンスの停止が必要です。
ステップ 1: 重複する vSwitch の特定
ステップ 2: 代替 vSwitch の作成
同じ VPC 内に新しい vSwitch を作成します。新しい vSwitch は次の要件を満たす必要があります。詳細な手順については、「vSwitch の作成と管理」をご参照ください。
削除する vSwitch と同じゾーンに配置されていること。
CEN インスタンス内のどの CIDR ブロックとも重複しない CIDR ブロックを使用していること。
説明将来の重複を避けるために、CIDR ブロックを慎重に計画してください。ガイダンスについては、「ネットワークの計画」をご参照ください。
削除する vSwitch と同じ構成を新しい vSwitch に適用します。
削除する vSwitch がカスタムルートテーブルに関連付けられている場合は、新しい vSwitch を同じカスタムルートテーブルに関連付けます。
ステップ 3: 新しい vSwitch へのリソース移行
ECS インスタンスの移行: プライベート IP アドレスを変更して、各 ECS インスタンスの vSwitch を変更します。手順については、「プライベート IP アドレスの変更」をご参照ください。
重要ECS インスタンスのプライベート IP アドレスは、ターゲット vSwitch が同じ VPC およびゾーンにある場合にのみ変更できます。変更前に ECS インスタンスを停止する必要があります。ECS インスタンスの VPC を変更するには、「ECS インスタンスの VPC の変更」をご参照ください。
データベースインスタンスの移行: ApsaraDB RDS インスタンスが vSwitch にデプロイされている場合は、その VPC と vSwitch を変更します。手順については、「ApsaraDB RDS for MySQL インスタンスの VPC と vSwitch の変更」をご参照ください。
vSwitch にデプロイされているその他のリソースをすべて新しい vSwitch に移行します。
ステップ 4: 古い vSwitch の削除
vSwitch を削除する前に、次の条件が満たされていることを確認してください。
すべてのリソースが削除されていること。ECS、Classic Load Balancer (CLB)、ApsaraDB RDS、ApsaraDB for MongoDB、PolarDB、Elasticsearch、時系列データベース (TSDB)、ApsaraDB for HBase、ApsaraDB for ClickHouse、Tablestore、Container Registry、Elastic High Performance Computing (E-HPC)、データディザスタリカバリ、File Storage NAS (NAS) など、vSwitch にデプロイされているすべてのリソースを削除または移行します。
すべての関連付けが削除されていること。該当する場合、SNAT エントリ、高可用性仮想 IP アドレス (HaVip)、カスタムルートテーブル、ネットワーク ACL など、vSwitch との関連付けを解除します。詳細については、「VPC ドキュメント」をご参照ください。
すべてのリソースと関連付けが削除されたら、VPC コンソールから vSwitch を削除します。
予防策
将来の CIDR ブロックの重複問題を回避するには:
VPC を CEN にアタッチする前に、ネットワークトポロジーを計画します。各 VPC および vSwitch に一意で重複しない CIDR ブロックを割り当てます。ガイダンスについては、「ネットワークの計画」をご参照ください。
構造化された IP アドレス割り当てスキームを使用します。ネットワークの成長に伴う偶発的な重複を防ぐために、各 VPC、リージョン、および環境 (本番環境、ステージング、開発環境) 用に個別の CIDR 範囲を予約します。
新しい vSwitch を作成する前に、CIDR の競合を確認してください。CEN コンソールのトランジットルーターにある [ネットワークルート] タブで、新しい CIDR ブロックが既存のルートと競合しないことを確認してください。
適用範囲
Cloud Enterprise Network (CEN)