接続のデバッグ

MySQL   |  PostgreSQL   |  PostgreSQL to AlloyDB

接続をデバッグする

移行元データベースと移行先データベース間の接続を設定しましたが、接続されていることを確認するにはどうすればよいですか？これらの間で通信が失敗した場合、何が問題でどこで問題が発生しているかをどのように確認できますか？

最も基本的なツールは 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 アドレス）がわからない場合は、次の手順を完了します。

1. Google Cloud コンソールで AlloyDB クラスタのページに移動します。

   [AlloyDB clusters] ページに移動

2. デバッグする移行ジョブに関連付けられているクラスタを見つけます。

3. 送信 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 VPC の IP アドレス範囲からの接続を受け入れるようにします。

Cloud Logging

Database Migration Service と AlloyDB は Cloud Logging を使用します。詳細については、Cloud Logging のドキュメントをご覧ください。また、Cloud SQL のサンプルクエリもご覧ください。

ログを表示

AlloyDB インスタンスと、Cloud VPN や Compute Engine インスタンスなどの他の Google Cloudプロジェクトのログを表示できます。AlloyDB インスタンスのログエントリのログを表示するには:

コンソール

1. [ログ エクスプローラ] に移動
2. ページの上部で、既存の AlloyDB プロジェクトを選択します。
3. クエリビルダーに以下のクエリを追加します。
• リソース: [AlloyDB データベース] を選択します。ダイアログで、AlloyDB インスタンスを選択します。
• ログ名: AlloyDB セクションまでスクロールし、インスタンスに適したログファイルを選択します。次に例を示します。
  • alloydb.googlapis.com/postgres.log
• 重大度: ログレベルを選択します。
• 時間範囲: プリセットを選択するか、カスタム範囲を作成します。

gcloud

gcloud logging コマンドを使用して、ログエントリを表示します。次の例では、PROJECT_ID を置き換えます。 limit フラグは、返されるエントリの最大数を示すオプションのパラメータです。

gcloud logging read "projects/[PROJECT_ID]/logs/alloydb.googleapis.com/postgres.log" --limit=10

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 ACCOUNT
  

  ACCOUNT は、構成するアカウントの名前に置き換えます。

ソース データベース インスタンスへの接続エラー

移行ジョブをテストすると、次のエラー メッセージが表示される

Failure connecting to the source database. Make sure the connectivity information on the connection profile is correct and the source database is reachable.

試す方法

次の手順を繰り返して、問題の原因を特定します。

1. TCP プロキシ コンテナをホストしている VM が実行されているかどうかを確認します。

   1. コンソールで、Compute Engine の [VM インスタンス] ページに移動します。

      [VM インスタンス] に移動

   2. プロキシ設定プロセスの一部として作成された VM を検索します。リストにない場合や実行されていない場合は、TCP プロキシを最初から構成し、移行ジョブのソース インスタンス設定を正しい IP アドレスで更新します。

2. VM が実行されている場合は、TCP プロキシ コンテナ イメージのダウンロード時にエラーが発生していないことを確認します。

   1. TCP プロキシの設定プロセスの一部として作成された VM を選択します。[ログ] で、[シリアルポート 1（コンソール）] をクリックします。

   2. ログに 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 にアクセスできません。

3. コンテナがソース インスタンスに接続できることを確認します。

   1. プロキシの設定プロセスの一部として作成された VM を選択します。[ログ] で [Cloud Logging] をクリックします。

   2. 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 の間に接続があることを確認できます。

   1. コンソールで、[接続テスト] ページに移動します。

      [接続テスト] に移動

   2. [接続テストを作成] をクリックします。

   3. テスト名を入力します。

   4. プロトコルとして TCP を選択します。

   5. [送信元エンドポイント] リストから [IP アドレス] を選択します。ソース データベースにパブリック IP アドレスを使用してアクセスできる場合は、新しく作成された TCP プロキシのパブリック IP アドレスを入力します。それ以外の場合は、TCP プロキシのプライベート IP アドレスを入力します。

   6. [宛先エンドポイント] リストから [IP アドレス] を選択し、ソース データベースの IP アドレスを入力します。

   7. [宛先ポート] フィールドに、ソース データベースへの接続に使用するポート番号を入力します。

   8. [作成] をクリックします。

   接続テストを実行し、発生した接続の問題に対処します。接続の問題を修正したら、TCP プロキシがソース インスタンスに接続できることを確認します。

   1. Compute Engine の [VM インスタンス] に移動します。

      [VM インスタンス] に移動

   2. プロキシの設定プロセスの一部として作成された VM を選択します。[ログ] で [Cloud Logging] をクリックします。

   3. Connection to source DB verified ログエントリが表示された場合は、TCP プロキシがソース インスタンスに接続できるようになったことを意味します。

4. 移行テストが接続の問題で失敗していないことを確認します。

宛先データベース インスタンスへの接続エラー

TCP プロキシ コンテナがソース インスタンスに接続できるにもかかわらず、接続の問題が原因で移行テストが失敗する場合は、宛先インスタンスと TCP プロキシ コンテナをホストする VM 間の接続に問題がある可能性があります。

問題をデバッグする

問題をデバッグするには、 Google Cloudの接続テストを使用して、宛先データベースと TCP プロキシをホストする VM の間に接続があることを確認します。

1. コンソールで、[接続テスト] ページに移動します。

   [接続テスト] に移動

2. [接続テストを作成] をクリックします。

3. テストに次のパラメータを設定します。

   1. テスト名を入力します。
   2. プロトコルとして TCP を選択します。
   3. [送信元エンドポイント] リストから [IP アドレス] を選択し、新しく作成した AlloyDB クラスタの IP アドレスを入力します。
   4. [宛先エンドポイント] リストから [IP アドレス] を選択し、TCP プロキシのプライベート IP アドレスを入力します。
   5. [宛先ポート] フィールドに 5432 と入力します。

4. [作成] をクリックします。

5. 接続テストを実行し、発生した接続の問題に対処します。

考えられる原因

宛先インスタンスと TCP プロキシ VM 間の通信を拒否するファイアウォール ルールがあります。

試す方法

宛先インスタンスがポート 5432 を使用して TCP プロキシと通信できるようにするファイアウォール ルールを追加します。

考えられる原因

宛先インスタンスと TCP プロキシ コンテナを実行している VM の VPC が一致していません。

試す方法

宛先インスタンスと同じ VPC を選択します。

リバース SSH トンネルの問題のトラブルシューティング

SSH トンネリングは、SSH 接続上で通信を転送する方法です。リバース SSH トンネリングでは、SSH トンネルを設定できますが、トンネル接続を開始するのは宛先ネットワークです。これは、セキュリティ上の理由から独自のネットワークでポートを開きたくない場合に便利です。

設定しようとしているのは次のとおりです。 AlloyDB DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Database Migration Service はソースから移行先にデータを移行しますが、移行先からソースへの接続を有効にする必要があります。

次のことを前提としています。

• AlloyDB destination は Compute Engine VM bastion にアクセスできます。

• source network bastion は source DB にアクセスできます（これは、AlloyDB ネットワークを Compute Engine VM ネットワークにピアリングすることで実現されます）。

次に、source network bastion から Compute Engine VM bastion への SSH トンネルを設定します。これにより、受信接続が Compute Engine VM bastion のポートからトンネルを経由して source DB に転送されます。

上記のシナリオの各リンクが正しく設定されていないと、フロー全体が機能しなくなる可能性があります。各リンクを 1 つずつトラブルシューティングします。

source network bastion ---> source DB

1. SSH を使用して source network bastion に接続します。ローカルマシンの場合は、ターミナルから接続します。
2. 次のいずれかの方法で、ソース DB への接続をテストします。
   • telnet [source_db_host_or_ip] [source_db_port] - Connected to x.x.x.x で終わる telnet 接続文字列が表示されます。
   • [db_client] -h[source_db_host_or_ip] -P[source_db_port] - アクセスが拒否されることを想定

失敗した場合は、この踏み台からソース DB へのアクセスを有効にしたことを確認する必要があります。

Compute Engine VM bastion ---> source DB

1. Compute Engine VM bastion に SSH 接続する（gcloud compute ssh VM_INSTANCE_NAME を使用）
2. 次のいずれかの方法で、ソース DB への接続をテストします。
   • telnet 127.0.0.1 [tunnel_port] - Connected to x.x.x.x で終わる telnet 接続文字列が表示されます。
   • [db_client] -h127.0.0.1 -P[tunnel_port] - アクセスが拒否されることを想定

失敗した場合は、トンネルが正しく稼働していることを確認する必要があります。sudo netstat -tupln を実行すると、この VM 上のすべてのリッスン プロセスが表示され、sshd listening on the tunnel_port が表示されます。

AlloyDB DB ---> source DB

これは、Database Migration Service の testing the migration job でテストするのが最適です。失敗した場合は、AlloyDB ネットワークと Compute Engine VM bastion ネットワーク間の VPC ピアリングまたはルーティングに問題があることを意味します。

ソース データベース サーバーのファイアウォールは、AlloyDB の宛先インスタンスが ipConfiguration 設定の privateNetwork フィールドとして使用する VPC ネットワークのプライベート サービス接続に割り振られた内部 IP 範囲全体を許可するように構成する必要があります。

Console で内部 IP 範囲を確認するには:

1. Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。

2. 使用する VPC ネットワークを選択します。

3. [プライベート サービス接続] タブを選択します。

AlloyDB インスタンスと Compute Engine VM インスタンス間のトラフィックは、Cloud VPN gateway プロジェクトの Cloud Logging コンソールで確認することもできます。Compute Engine VM ログで、AlloyDB インスタンスからのトラフィックを探します。AlloyDB インスタンスのログで、Compute Engine VM からのトラフィックを探します。