연결 디버그
소스 데이터베이스와 대상 데이터베이스 간의 연결을 설정했지만 연결되었는지 어떻게 알 수 있을까요? 이들 간의 통신이 실패할 때 무엇이 어디에서 잘못되었는지 어떻게 알 수 있을까요?
가장 기본적인 도구는 ping과 traceroute입니다.
핑
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 콘솔에서 클러스터 페이지로 이동합니다.
- 디버깅 중인 마이그레이션 작업과 연결된 PostgreSQL용 AlloyDB 클러스터를 찾습니다.
- 두 아웃바운드 공개 IP 주소는 클러스터의 기본 인스턴스 세부정보에 표시됩니다.
로컬 포트 열기
호스트가 어떤 포트에서 리슨 중인지 확인하려면 ss -tunlp4 명령어를 실행합니다. 그러면 어느 포트가 개방되어 수신 대기 중인지 확인할 수 있습니다.
예를 들어 PostgreSQL 데이터베이스가 실행 중인 경우 포트 5432가 작동하고 리슨 중이어야 합니다. SSH의 경우 포트 22가 표시됩니다.
모든 로컬 포트 활동
netstat 명령어를 사용하여 모든 로컬 포트 활동을 확인합니다. 예를 들어 netstat -lt은 현재 활성 포트를 모두 표시합니다.
telnet을 사용하여 원격 호스트에 연결
TCP를 사용하여 원격 호스트에 연결할 수 있는지 확인하려면 telnet 명령어를 실행합니다. Telnet은 제공된 IP 주소와 포트로 연결을 시도합니다.
예를 들어 원격 호스트가 PostgreSQL 데이터베이스를 실행하는 경우 포트 5432에서 텔넷을 사용할 수 있어야 합니다.
telnet 35.193.198.159 5432
성공하면 다음이 표시됩니다.
Trying 35.193.198.159... Connected to 35.193.198.159.
실패하면 연결 시도를 강제 종료할 때까지 telnet이 응답을 중지합니다.
Trying 35.193.198.159... ^C
클라이언트 인증
클라이언트 인증은 pg_hba.conf라는 구성 파일로 제어됩니다(HBA는 호스트 기반 인증(host-based authentication)을 의미함).
소스 데이터베이스에 있는 pg_hba.conf 파일의 복제 연결 섹션이 PostgreSQL용 AlloyDB VPC의 IP 주소 범위로부터 연결을 수락하도록 업데이트되어야 합니다.
Cloud Logging
Database Migration Service 및 PostgreSQL용 AlloyDB는 Cloud Logging을 사용합니다. 자세한 내용은 Cloud Logging 문서를 참조하세요.
로그 보기
PostgreSQL용 AlloyDB 인스턴스와 Cloud VPN 또는 Compute Engine 인스턴스와 같은 다른 Google Cloud프로젝트의 로그를 볼 수 있습니다. PostgreSQL용 AlloyDB 인스턴스 로그 항목의 로그를 보려면 다음 안내를 따르세요.
콘솔
- 로그 탐색기로 이동
- 페이지 상단에서 PostgreSQL용 AlloyDB 프로젝트를 선택합니다.
- 쿼리 빌더에서 다음을 추가합니다.
- Resource: PostgreSQL용 AlloyDB 인스턴스를 선택합니다. 대화상자에서 PostgreSQL용 AlloyDB 인스턴스를 선택합니다.
- 로그 이름: PostgreSQL용 AlloyDB 섹션으로 스크롤하고 인스턴스에 적합한 로그 파일을 선택합니다. 예를 들면 다음과 같습니다.
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 주소를 사용하는 PostgreSQL용 AlloyDB 클러스터에 대한 연결은 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 주소를 사용하는 PostgreSQL용 AlloyDB 클러스터에 연결할 수 없습니다.
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에서 이미지를 가져올 수 없는 것이 문제일 수 있습니다. 이 경우에 해당하는지 확인하려면 VM에 연결하고 다음 명령어를 사용하여 Container Registry에서 이미지를 수동으로 가져옵니다.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과 다른 가상 프라이빗 클라우드 (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 프록시 컨테이너가 소스 인스턴스에 연결할 수 있지만 연결 문제로 인해 마이그레이션 테스트가 계속 실패하는 경우 대상 PostgreSQL용 AlloyDB 클러스터와 TCP 프록시 컨테이너를 호스팅하는 VM 간의 연결이 문제일 수 있습니다.
문제 디버그
문제를 디버그하려면 Google Cloud 연결 테스트를 사용하여 대상 PostgreSQL용 AlloyDB 클러스터와 TCP 프록시를 호스팅하는 VM 간에 연결이 있는지 확인합니다.
- Google Cloud 콘솔에서 연결 테스트 페이지로 이동합니다.
- 연결 테스트 만들기를 클릭합니다.
- 테스트에 다음 매개변수를 설정합니다.
- 테스트 이름을 입력합니다.
- 프로토콜로 TCP를 선택합니다.
- 소스 엔드포인트 목록에서 IP 주소를 선택하고 새로 만든 PostgreSQL용 AlloyDB 클러스터의 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에 액세스할 수 있습니다(PostgreSQL용 AlloyDB 네트워크를 Compute Engine VM 네트워크에 피어링하여 수행).
source network bastion는 source DB에 액세스할 수 있습니다.
그런 다음 source network bastion에서 Compute Engine VM bastion로 SSH 터널을 설정합니다. 이 터널은 Compute Engine VM bastion의 일부 포트로 들어오는 모든 연결을 터널을 통해 source DB로 라우팅합니다.
위 시나리오의 각 링크가 잘못 설정되어 전체 흐름이 작동하지 않을 수 있습니다. 각 링크를 하나씩 문제 해결합니다.
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로 끝나는 텔넷 연결 문자열이 표시됩니다.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로 끝나는 텔넷 연결 문자열이 표시됩니다.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로 테스트하는 것이 가장 좋습니다.
이 작업이 실패하면 PostgreSQL용 AlloyDB 네트워크와 Compute Engine VM bastion 네트워크 간의 VPC 피어링 또는 라우팅에 문제가 있는 것입니다.
PostgreSQL용 AlloyDB 대상 클러스터에서 사용하는 VPC 네트워크의 비공개 서비스 연결에 할당된 전체 내부 IP 범위를 허용하도록 소스 데이터베이스 서버의 방화벽을 구성해야 합니다.
콘솔에서 내부 IP 범위를 찾으려면 다음 안내를 따르세요.
- Google Cloud 콘솔에서 VPC 네트워크 페이지로 이동합니다.
- 사용할 VPC 네트워크를 선택합니다.
- 비공개 서비스 액세스 > 서비스에 할당된 IP 범위를 선택합니다.
- servicenetworking-googleapis-com에서 만든 연결과 연결된 내부 IP 범위를 찾습니다.
Cloud VPN gateway 프로젝트의 Cloud Logging 콘솔에서 PostgreSQL용 AlloyDB 클러스터와 Compute Engine VM 인스턴스 간의 트래픽을 볼 수도 있습니다. Compute Engine VM 로그에서 PostgreSQL용 AlloyDB 클러스터에서 들어오는 트래픽을 찾습니다. PostgreSQL용 AlloyDB 클러스터 로그에서 Compute Engine VM의 트래픽을 찾습니다.