このドキュメントでは、ワークロードと組織をグローバル DNS からゾーン DNS に移行するメリットと推奨されるアプローチについて説明します。
ゾーン DNS は、複数リージョンにまたがる障害のリスクを軽減し、Compute Engine のプロジェクトの全体的な信頼性を向上させます。
ゾーン DNS 名を使用するメリット
Google Cloud には、ゾーンとグローバルの 2 種類の内部 DNS 名があります。
- ゾーン DNS
ゾーン DNS 名には、Compute Engine インスタンスの名前、インスタンスが配置されているゾーン、インスタンスを所有するプロジェクトが含まれます。これらの名前は特定のゾーン内で解決されます。結果として、
my-vm.zone1.google.com
はzone1
に固有であり、my-vm.zone2.google.com
とは異なるインスタンスを表します。この分離には、次のようなメリットがあります。- 可用性の向上: 1 つのゾーンが停止しても、他のゾーンの DNS 解決には影響しないため、アプリケーションの可用性が向上します。
2018 年 9 月 6 日以降に作成された組織のデフォルトの内部 DNS 解決方法はゾーン DNS です。
- グローバル DNS
グローバル DNS 名には、インスタンスが配置されているゾーンは含まれません。つまり、各インスタンスには、プロジェクト内のすべてのゾーンで一意の DNS 名が必要です。このアプローチには大きな欠点があります。
- 単一障害点: グローバル DNS サービスで問題が発生すると、インスタンスが配置されているゾーンに関係なく、すべてのインスタンスに影響が及ぶ可能性があります。これにより、次のような問題が発生する可能性があります。
- 新しいインスタンスを作成できない: コントロール プレーンの障害が発生しているリージョンでは、新しいインスタンスを作成できなくなります。
- サービスの中断: マネージド インスタンス グループ(MIG)の自動スケーリングや自動修復など、重要な Compute Engine サービスが正しく機能しない可能性があります。
- 単一障害点: グローバル DNS サービスで問題が発生すると、インスタンスが配置されているゾーンに関係なく、すべてのインスタンスに影響が及ぶ可能性があります。これにより、次のような問題が発生する可能性があります。
2018 年 9 月 6 日より前に Google Cloud にオンボーディングされた組織は、新しいプロジェクトでデフォルトでグローバル DNS を使用するように構成されています。信頼性を高め、前述のようなサービスの中断を防ぐため、これらのプロジェクトをゾーン DNS に移行することを強くおすすめします。また、組織内で作成されるすべての新しいプロジェクトでゾーン DNS の使用を適用するように組織のポリシーを更新する必要があります。
グローバル DNS からゾーン DNS に移行する推奨アプローチ
通常、グローバル DNS からゾーン DNS への移行プロセスには次の 2 つのステップがあります。
- デフォルトでゾーン DNS を使用するように新しいプロジェクトを構成します。
- 内部 DNS メタデータ設定を変更して、既存のプロジェクトをグローバル DNS からゾーン DNS に移行します。
プロジェクトによっては、ゾーン DNS と互換性がない場合があります。このようなプロジェクトでは、ゾーン DNS に移行する前に分析とトラブルシューティングが必要です。
移行の制限事項
Compute Engine が提供する準備状況の評価は、過去 30 日間の内部 DNS クエリ履歴に基づいています。ただし、ゾーン DNS に正常に移行できるかどうかには、他の要因も影響する可能性があります。
glibc のバージョン
ゾーン DNS に移行すると、検索パスに新しいドメインが追加されます。Linux または Unix OS を実行し、glibc
バージョン 2.25 以前を使用する Compute インスタンスには、検索ドメインの数が 6 個に制限されています。この上限を超えると、問題が発生する可能性があります。
- 影響を受けるインスタンス: この制限は、古い Linux ディストリビューションまたは Unix ディストリビューションを使用する VM に適用されます。
- 影響を受けないインスタンス: 次のオペレーティング システムのインスタンスは影響を受けません。
- Windows
- Container-Optimized OS
- Debian 10 以降
- Fedora CoreOS(バージョン 27 以降)
- RHEL 8 以降
- Ubuntu 18.04 以降
glibc
バージョン 2.26 以降を使用するカスタム イメージ
インスタンスで使用されている glibc のバージョンを確認するには、次の操作を行います。
- Linux VM に接続します。
ldd --version
コマンドを実行します。
インスタンスで glibc
バージョン 2.25 以前を使用している場合は、検索ドメインを確認します。
- Linux VM に接続します。
cat /etc/resolv.conf
コマンドを実行します。
OS バージョン
Windows Server 2003 以前など、一部のオペレーティング システムでは、コンピューティング インスタンス名の長さが 15 文字に制限されています。ゾーン DNS は、内部 DNS の完全修飾ドメイン名(FQDN)にゾーン修飾子を追加します。
Windows での命名制限は、以前のバージョンの OS で使用されていた NetBIOS 命名規則によるものです。新しいバージョンの Windows では、この制限がなくなり、より長いインスタンス名を使用できます。
以前の Windows システムを使用している場合は、ゾーン DNS に移行するときに、この命名制限に注意してください。長いゾーン DNS 名は名前の長さの上限を超える可能性があります。
共有 VPC ネットワーク
共有 VPC を使用するサービス プロジェクト内のインスタンスの DNS 名を解決するには、ゾーンを含む完全修飾ドメイン名(FQDN)を使用する必要があります。
次のステップ
- Google Cloud リソース階層で、組織、フォルダ、プロジェクト間の関係について確認する。
- Compute Engine の内部 DNS について詳しく学ぶ。