接続をデバッグする
移行元データベースと移行先データベースの間の接続を設定しましたが、接続されているかどうかを確認するにはどうすればよいでしょうか。それらの間の通信に失敗した場合、何がどこでうまくいかなかったのかをどのようにして見つけることができるでしょうか。
最も基本的なツールは ping と traceroute です。
Ping
Ping は、宛先（「リモートホスト」）が送信元から利用可能かどうかを判断するための基本的なテストを実行します。Ping は ICMP Echo Request パケットをリモートホストに送信し、ICMP Echo Reply が返されることを想定しています。ping が正常に通らない場合、送信元から宛先へのルートはありません。ただし、成功したからといって、パケットが通過できるとは限りません。一般的に、リモートホストに到達できることを意味するだけです。
ping によってホストが稼働中で応答することは確認できますが、信頼性は保証されません。一部のネットワーク プロバイダでは、セキュリティ保護のため ICMP をブロックしているため、接続のデバッグは難しい場合があります。
traceroute
Traceroute は、あるホストから別のホストへのネットワーク パケットの完全なルートをテストします。パケットが通過するすべてのステップ（「ホップ」）と、各ステップでの所要時間が表示されます。パケットが宛先まで到達できない場合、traceroute は完了せず、後ろには連続したアスタリスクが続きます。この場合、途中で正常に到達した最後の IP アドレスを確認します。ここが接続の途切れた場所になります。
Traceroute は、タイムアウトする場合があります。また、経路中のゲートウェイがパケットをネクストホップに渡すように正しく構成されておらず、完了しない場合もあります。
traceroute が完了しなかった場合、停止した場所を特定できる可能性があります。traceroute の出力に表示された最後の IP アドレスを見つけて、ブラウザで who owns [IP_ADDRESS] を検索します。結果にアドレスの所有者が表示されないこともありますが、試してみる価値はあります。
mtr
mtr ツールは traceroute の形式で、ローカル プロセスの top コマンドと同じように動作し続けて継続的に更新されます。
ローカル IP アドレスを確認する
ホストのローカル アドレスがわからない場合は、ip -br address show コマンドを実行します。Linux では、ネットワーク インターフェース、インターフェースのステータス、ローカル IP、MAC アドレスが表示されます。例: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64。
あるいは、ipconfig や ifconfig を実行して、ネットワーク インターフェースのステータスを確認することもできます。
送信 IP アドレスを確認する
ソース データベースと宛先データベースが相互に通信するために使用する IP アドレス（送信 IP アドレス）がわからない場合は、次の手順を完了します。
- Google Cloud コンソールの [クラスタ] ページに移動します。
- デバッグする移行ジョブに関連付けられている AlloyDB for PostgreSQL クラスタを見つけます。
- 両方のアウトバウンド パブリック IP アドレスが、クラスタのプライマリ インスタンスの詳細に表示されます。
開いているローカルポート
ホストがリッスンしていると思われるポートを確認するには、ss -tunlp4 コマンドを実行します。これにより、開いているポートとリッスンしているポートがわかります。
たとえば、動作している PostgreSQL データベースがある場合は、ポート 5432 が開いており、リッスンしています。SSH の場合は、ポート 22 が表示されます。
すべてのローカルポート アクティビティ
すべてのローカルポート アクティビティを表示するには、netstat コマンドを使用します。たとえば、netstat -lt を使用すると、現在アクティブなポートがすべて表示されます。
telnet を使用してリモートホストに接続する
TCP を使用してリモートホストに接続できることを確認するには、telnet コマンドを実行します。Telnet は、指定された IP アドレスとポートに接続しようとします。
たとえば、リモートホストで PostgreSQL データベースを実行している場合は、telnet 35.193.198.159 5432 と指定すると、ポート 5432 で telnet 接続できます。
成功すると、次のように表示されます。
Trying 35.193.198.159... Connected to 35.193.198.159.
失敗すると、試行を強制終了するまで telnet が応答を停止します。
Trying 35.193.198.159... ^C
クライアント認証
クライアント認証は、pg_hba.conf という名前の構成ファイルで制御されます（HBA はホストベースの認証を意味します）。
ソース データベース上の pg_hba.conf ファイルのレプリケーション接続セクションを更新して、AlloyDB for PostgreSQL VPC の IP アドレス範囲からの接続を受け入れるようにします。
Cloud Logging
Database Migration Service と AlloyDB for PostgreSQL は Cloud Logging を使用します。詳細については、Cloud Logging のドキュメントをご覧ください。
ログを表示
AlloyDB for PostgreSQL インスタンスと、Cloud VPN や Compute Engine インスタンスなどのその他の Google Cloudプロジェクトのログを表示できます。AlloyDB for PostgreSQL インスタンスのログエントリのログを表示するには:
コンソール
- ログ エクスプローラに移動
- ページの上部で AlloyDB for PostgreSQL プロジェクトを選択します。
- クエリビルダーに以下のクエリを追加します。
- リソース: [AlloyDB for PostgreSQL インスタンス] を選択します。ダイアログで、AlloyDB for PostgreSQL インスタンスを選択します。
- ログ名: AlloyDB for PostgreSQL セクションまでスクロールし、インスタンスに適したログファイルを選択します。次に例を示します。
alloydb.googleapis.com/postgres.log
- 重大度: ログレベルを選択します。
- 期間: プリセットを選択するか、カスタム範囲を作成します。
gcloud
gcloud logging コマンドを使用して、ログエントリを表示します。次の例では、PROJECT_ID を置き換えます。
limit フラグは、返されるエントリの最大数を示すオプションのパラメータです。
gcloud logging read "projects/PROJECT_ID/logs/alloydb.googleapis.com%2Fpostgres.log" --limit=10
プライベート IP アドレス
プライベート IP アドレスを使用した AlloyDB for PostgreSQL クラスタへの接続は、RFC 1918 アドレス範囲に対して承認されます。ネットワークで RFC 1918 以外のアドレス範囲を使用している場合は、ネットワーク ピアリングを更新して、RFC 1918 以外のルートをエクスポートする必要があります。例: gcloud compute networks peerings update servicenetworking-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
IP 範囲 172.17.0.0/16 は、Docker ブリッジ ネットワーク用に予約されています。プライベート IP アドレスを使用して、この範囲内の IP アドレスから AlloyDB for PostgreSQL クラスタに接続することもできません。
VPN のトラブルシューティング
Google Cloud Cloud VPN のトラブルシューティングのページをご覧ください。
TCP プロキシエラーのトラブルシューティング
TCP プロキシの設定方法によってもエラーが発生することがあります。TCP プロキシエラーのトラブルシューティングを行うには、次の問題の例と解決方法をご覧ください。
仮想マシン（VM）の起動に失敗する
Compute Engine で VM インスタンスを起動すると、次のメッセージが表示されます。
You do not currently have an active account selected.
おすすめの方法
次のいずれかのコマンドを実行して、アクティブなアカウントを構成します。
新しい認証情報を取得するには、次のコマンドを実行します。
gcloud auth loginすでに認証されているアカウントを選択するには、次のコマンドを実行します。
gcloud config set account <var>ACCOUNT</var>ACCOUNT は、構成するアカウントの名前に置き換えます。
ソース データベース インスタンスへの接続エラー
移行ジョブをテストすると、次のエラー メッセージが表示されます。
Failure connecting to the source database. Make sure the connectivity information on the connection profile is correct and the source database is reachable.
おすすめの方法
次の手順を繰り返して、問題の原因を特定します。
- TCP プロキシ コンテナをホストしている VM が実行されているかどうかを確認します。
- Google Cloud コンソールで、Compute Engine の [VM インスタンス] ページに移動します。
- プロキシの設定プロセスの一環として作成された VM を検索します。リストにない場合や実行されていない場合は、TCP プロキシを最初から構成し、移行ジョブのソース接続プロファイルの設定を正しい IP アドレスで更新します。
- VM が実行されている場合は、TCP プロキシ コンテナ イメージのダウンロード時にエラーが発生していないことを確認します。
- TCP プロキシの設定プロセスの一環として作成された VM を選択します。[ログ] で、[シリアルポート 1（コンソール）] をクリックします。
- ログに
Launching user container 'gcr.io/dms-images/tcp-proxy'エントリが表示されない場合は、インスタンスが Container Registry からイメージを pull できなかった可能性があります。この問題が発生しているかどうかを確認するには、VM に接続し、次のコマンドを使用して Container Registry からイメージを手動で pull してみます。docker pull gcr.io/dms-images/tcp-proxy
Error response from daemon: Get "https://gcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)というエラーが表示された場合は、VM が Container Registry に接続できなかったことを意味します。VM にプライベート IP アドレスしかない場合は、その IP アドレスが属するサブネットでプライベート Google アクセスを有効にする必要があります。有効にしないと、VM は Container Registry などの Google Enterprise API にアクセスできません。
- コンテナがソース インスタンスに接続できることを確認します。
- プロキシの設定プロセスの一環として作成された VM を選択します。[ログ] で [Cloud Logging] をクリックします。
- 「
Connection refused, please verify that the machine you are using to run the script can connect to the source database at」というメッセージが表示された場合は、TCP プロキシ コンテナがソース データベース インスタンスに接続できなかったことを意味します。これには、次のような理由が考えられます。- 移行元インスタンスの IP アドレスが正しくない。
- TCP プロキシから移行元インスタンスへの接続を拒否するファイアウォール ポリシーがある。
- ソース インスタンスが、TCP プロキシをホストする VM とは異なる Virtual Private Cloud（VPC）ネットワークにある。
Google Cloudの接続テストを使用して、TCP プロキシをホストする VM とソース データベース間の接続を確認することで、接続の問題をデバッグできます。
- Google Cloud コンソールで、[接続テスト] ページに移動します。
- [接続テストを作成] をクリックします。
- テスト名を入力します。
- プロトコルとして [TCP] を選択します。
- [送信元エンドポイント] リストから [IP アドレス] を選択します。ソース データベースにパブリック IP アドレスを使用してアクセスできる場合は、新しく作成した TCP プロキシのパブリック IP アドレスを入力します。それ以外の場合は、TCP プロキシのプライベート IP アドレスを入力します。
- [宛先エンドポイント] リストから [IP アドレス] を選択し、移行元データベースの IP アドレスを入力します。
- [宛先ポート] フィールドに、移行元データベースへの接続に使用するポート番号を入力します。
- [作成] をクリックします。
接続テストを実行し、発生した接続の問題に対処します。接続の問題を解決したら、TCP プロキシがソース インスタンスに接続できることを確認します。
- Compute Engine の [VM インスタンス] に移動します。
- プロキシの設定プロセスの一環として作成された VM を選択します。[ログ] で [Cloud Logging] をクリックします。
Connection to source DB verifiedログエントリが表示されている場合は、TCP プロキシがソース インスタンスに接続できることを意味します。
- 移行テストが接続の問題で失敗していないことを確認します。
宛先データベース クラスタへの接続に失敗する
TCP プロキシ コンテナが移行元インスタンスに接続できるにもかかわらず、接続の問題により移行テストが失敗する場合は、移行先の AlloyDB for PostgreSQL クラスタと TCP プロキシ コンテナをホストする VM 間の接続に問題がある可能性があります。
問題をデバッグする
この問題をデバッグするには、 Google Cloud 接続テストを使用して、宛先の AlloyDB for PostgreSQL クラスタと TCP プロキシをホストする VM 間の接続を確認します。
- Google Cloud コンソールで、[接続テスト] ページに移動します。
- [接続テストを作成] をクリックします。
- テストに次のパラメータを設定します。
- テスト名を入力します。
- プロトコルとして [TCP] を選択します。
- [送信元エンドポイント] リストから [IP アドレス] を選択し、新しく作成した AlloyDB for PostgreSQL クラスタの IP アドレスを入力します。
- [宛先エンドポイント] リストから [IP アドレス] を選択し、TCP プロキシのプライベート IP アドレスを入力します。
- [宛先ポート] フィールドに「
5432」と入力します。
- [作成] をクリックします。
- 接続テストを実行し、発生した接続の問題に対処します。
考えられる原因
宛先クラスタと TCP プロキシ VM 間の通信を拒否するファイアウォール ルールがある。
おすすめの方法
宛先クラスタがポート 5432 を使用して TCP プロキシと通信できるようにするファイアウォール ルールを追加します。
考えられる原因
宛先クラスタと、TCP プロキシ コンテナを実行している VM の間で VPC の不一致がある。
おすすめの方法
宛先クラスタに同じ VPC を選択します。
リバース SSH トンネルの問題のトラブルシューティング
SSH トンネリングは、SSH 接続を介して一部の通信を転送する方法です。リバース SSH トンネリングを使用すると、SSH トンネルを設定しながら、宛先ネットワークがトンネル接続を開始するように維持できます。これは、セキュリティ上の理由から、独自のネットワークでポートを開きたくない場合に便利です。
実現しようとしているのは、次の設定です。
AlloyDB for PostgreSQL cluster ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
次のことを前提としています。
AlloyDB for PostgreSQL cluster が Compute Engine VM bastion にアクセスできる（これは、AlloyDB for PostgreSQL ネットワークを Compute Engine VM ネットワークにピアリングすることで実現されます）。
source network bastion は source DB にアクセスできます。
次に、source network bastion から Compute Engine VM bastion への SSH トンネルを設定します。これにより、Compute Engine VM bastion のポートへの受信接続がトンネルを介して source DB にルーティングされます。
上記のシナリオの各リンクが不適切に設定されていると、フロー全体が機能しなくなる可能性があります。各リンクを 1 つずつトラブルシューティングします。
source network bastion ---> source DB
- SSH を使用して source network bastion に接続します。ローカルマシンの場合は、ターミナルから接続します。
- 次のいずれかの方法で、ソース DB への接続をテストします。
telnet [source_db_host_or_ip] [source_db_port]-Connected to x.x.x.xで終わる telnet 接続文字列が表示されます。psql -h [source_db_host_or_ip] -p [source_db_port] -U [username] -d [database_name]- パスワードの入力を求めるメッセージが表示されるか、アクセスが拒否されます。
この処理が失敗した場合は、この踏み台からソース DB へのアクセスが有効になっていることを確認する必要があります。
Compute Engine VM bastion ---> source DB
- Compute Engine VM bastion に SSH 接続します（
gcloud compute ssh VM_INSTANCE_NAMEを使用）。 - 次のいずれかの方法で、ソース DB への接続をテストします。
telnet 127.0.0.1 [tunnel_port]-Connected to x.x.x.xで終わる telnet 接続文字列が表示されます。psql -h 127.0.0.1 -p [tunnel_port] -U [username] -d [database_name]- パスワード プロンプトが表示されるか、アクセスが拒否されます。
この処理が失敗した場合は、トンネルが正常に稼働していることを確認する必要があります。sudo netstat -tupln を実行すると、この VM でリッスンしているすべてのプロセスが表示されます。sshd listening on the tunnel_port が表示されます。
AlloyDB for PostgreSQL cluster ---> source DB
これは、Database Migration Service の testing the migration job でテストするのが最適です。これが失敗した場合は、AlloyDB for PostgreSQL ネットワークと Compute Engine VM bastion ネットワーク間の VPC ピアリングまたはルーティングに問題があることを意味します。
ソース データベース サーバーのファイアウォールは、AlloyDB for PostgreSQL の宛先クラスタが使用する VPC ネットワークのプライベート サービス接続に割り振られた内部 IP 範囲全体を許可するように構成する必要があります。
Console で内部 IP 範囲を確認するには:
- Google Cloud コンソールの [VPC ネットワーク] ページに移動します。
- 使用する VPC ネットワークを選択します。
- [プライベート サービス アクセス] > [サービスに割り当てられた IP 範囲] を選択します。
- servicenetworking-googleapis-com によって作成された接続に関連付けられている内部 IP 範囲を見つけます。
AlloyDB for PostgreSQL クラスタと Compute Engine VM インスタンス間のトラフィックは、Cloud VPN gateway プロジェクトの Cloud Logging コンソールでも確認できます。Compute Engine VM のログで、AlloyDB for PostgreSQL クラスタからのトラフィックを探します。AlloyDB for PostgreSQL クラスタのログで、Compute Engine VM からのトラフィックを探します。