VM 간 내부 연결 문제 해결
이 문서에서는 동일한 Virtual Private Cloud(VPC) 네트워크(공유 VPC 또는 독립형) 또는 VPC 네트워크 피어링에 연결된 2개의 VPC 네트워크에 있는 Compute Engine VM 간의 연결 문제를 해결하는 단계를 설명합니다. 여기서는 VM이 해당 가상 네트워크 인터페이스 컨트롤러(vNIC)의 내부 IP 주소를 사용하여 통신한다고 가정합니다.
이 가이드의 단계는 Compute Engine VM과 Google Kubernetes Engine 노드 모두에 적용됩니다.
특정 문제 해결 시나리오를 추가로 살펴보려면 페이지 하단의 의견 보내기 링크를 클릭하여 알려 주세요.
이 가이드에는 다음 VM 및 VPC 구성이 적용됩니다.
- 단일 VPC 네트워크에서 내부 IP 주소를 사용하는 VM 간 연결
- 공유 VPC 네트워크 내에서 내부 IP 주소를 사용하는 VM 간 연결
- VPC 네트워크 피어링을 통해 피어링된 다른 VPC 네트워크의 내부 IP 주소를 사용하는 VM 간 연결
이 가이드에 사용된 명령어는 모든 Google 제공 OS 이미지에 사용할 수 있습니다. 자체 OS 이미지를 사용하는 경우 도구를 설치해야 할 수도 있습니다.
문제 정량화
- 전체 패킷이 손실됐다고 생각되면 전체 연결 실패 문제 해결을 참조하세요.
- 지연 시간, 부분 패킷 손실 또는 연결 중간에 시간 초과가 발생하는 경우 처리량 문제를 일으킨 네트워크 지연 시간 또는 손실 문제 해결을 참조하세요.
전체 연결 실패 문제 해결
다음 섹션에서는 VM 간의 완전한 내부 연결 실패 문제를 해결하는 단계를 설명합니다. 지연 시간 증가나 간헐적인 연결 시간 초과가 발생하는 경우 처리량 문제를 일으킨 네트워크 지연 시간 또는 손실 문제 해결로 건너뛰세요.
연결 값 결정
먼저 다음 정보를 수집합니다.
- VM 인스턴스 페이지에서 두 VM의 다음 정보를 수집합니다.
- VM 이름
- VM 영역
- 통신 중인 vNIC의 내부 IP 주소
대상 서버 소프트웨어 구성에서 다음 정보를 수집합니다.
- 레이어 4 프로토콜
- 대상 포트
예를 들어 대상이 HTTPS 서버이면 프로토콜은 TCP이고 포트는 일반적으로
443이지만 특정 구성은 다른 포트를 사용할 수 있습니다.
여러 VM에서 문제가 발생하면 문제가 있는 단일 소스 및 단일 대상 VM을 선택하고 해당 값을 사용하세요. 일반적으로 연결의 소스 포트는 필요하지 않습니다.
이 정보가 있으면 기본 Google 네트워크 관련 문제 조사로 진행하세요.
기본 Google 네트워크 관련 문제 조사
설정이 최근에 변경되지 않은 기존 설정인 경우 기본 Google 네트워크에 문제가 있을 수 있습니다. 성능 대시보드에서 VM 영역 간 패킷 손실을 확인합니다. 네트워크 시간 초과가 발생한 기간 동안 영역 간 패킷 손실이 증가하면 가상 네트워크의 기반이 되는 물리적 네트워크에 문제가 있을 수 있습니다. 지원 케이스를 제출하기 전에 Google Cloud 상태 대시보드에서 알려진 문제를 확인하세요.
기본 Google 네트워크에 문제가 없는 것 같으면 잘못 구성된 Google Cloud 방화벽 규칙 확인으로 진행하세요.
Google Cloud에서 잘못 구성된 방화벽 규칙 확인
연결 테스트는 두 VM 간의 VPC 네트워크 경로 구성을 분석하고 프로그래밍된 구성이 트래픽을 허용해야 하는지 여부를 보여줍니다. 트래픽이 허용되지 않으면 Google Cloud 이그레스 또는 인그레스 방화벽 규칙에서 트래픽을 차단하는지 또는 경로를 사용할 수 없는지 여부가 결과에 표시됩니다.
연결 테스트는 VM의 하이퍼바이저 간에 패킷을 전송하여 경로를 동적으로 테스트할 수도 있습니다. 이러한 테스트가 수행되면 테스트 결과가 표시됩니다.
연결 테스트는 VPC 네트워크의 구성만 검사합니다. 운영체제 방화벽 또는 운영체제 경로 또는 VM의 서버 소프트웨어는 테스트하지 않습니다.
다음 절차는 Google Cloud Console에서 연결 테스트를 실행합니다. 테스트를 실행하는 다른 방법은 연결 테스트 실행을 참조하세요.
다음 절차를 사용하여 테스트를 만들고 실행합니다.
Google Cloud 콘솔에서 연결 테스트 페이지로 이동합니다.
프로젝트 풀다운 메뉴에서 올바른 프로젝트에 있는지 확인하거나 올바른 프로젝트를 지정합니다.
연결 테스트 만들기를 클릭합니다.
테스트에 이름을 지정합니다.
다음 사항을 지정합니다.
- 프로토콜
- 소스 엔드포인트 IP 주소
- 소스 프로젝트 및 VPC 네트워크
- 대상 엔드포인트 IP 주소
- 대상 프로젝트 및 VPC 네트워크
- 대상 포트
만들기를 클릭합니다.
테스트가 즉시 실행됩니다. 결과 다이어그램을 보려면 결과 세부정보 열에서 보기를 클릭합니다.
- 결과에 Google Cloud 방화벽 규칙에 의해 연결이 끊겼다고 표시되면 원하는 보안 설정이 연결을 허용해야 하는지 확인합니다. 자세한 내용은 보안 또는 네트워크 관리자에게 문의해야 합니다. 트래픽을 허용해야 하는 경우 다음을 확인하세요.
- 항상 차단되는 트래픽 목록을 확인합니다. 항상 차단되는 트래픽 목록에 설명된 대로 Google Cloud에서 트래픽이 차단되면 기존 구성이 작동하지 않습니다.
- 방화벽 정책 페이지로 이동하고 방화벽 규칙을 검토합니다. 방화벽이 잘못 구성된 경우 연결을 허용하도록 방화벽 규칙을 만들거나 수정합니다. 이 규칙은 VPC 방화벽 규칙 또는 계층적 방화벽 정책 규칙일 수 있습니다.
- 이 트래픽을 차단하는 올바르게 구성된 방화벽 규칙이 있으면 보안 또는 네트워크 관리자에게 문의하세요. 조직의 보안 요구사항으로 인해 VM이 서로 도달하지 않아야 하는 경우 설정을 다시 설계해야 할 수 있습니다.
- 결과에 VPC 연결 경로에 문제가 없다고 표시되면 다음 중 하나가 문제일 수 있습니다.
- 방화벽 소프트웨어 문제와 같은 게스트 OS 구성 문제
- 애플리케이션이 동결됨 또는 잘못된 포트에서 리슨하도록 구성됨과 같은 클라이언트 또는 서버 애플리케이션 관련 문제
이후 단계에서는 이러한 각 가능성을 살펴봅니다. VM 내에서 TCP 연결 테스트를 진행합니다.
VM 내에서 TCP 연결 테스트
VM 간 연결 테스트에서 VPC 구성 문제를 감지하지 못한 경우 OS 간 연결 테스트를 시작합니다. 다음 단계를 통해 다음을 파악할 수 있습니다.
- TCP 서버가 표시된 포트에서 리슨하는 경우
- 서버 측 방화벽 소프트웨어가 클라이언트 VM에서 해당 포트로의 연결을 허용하는 경우
- 클라이언트 측 방화벽 소프트웨어가 서버의 해당 포트에 대한 연결을 허용하는 경우
- 서버 측 경로 테이블이 패킷을 전달하도록 올바르게 구성된 경우
- 클라이언트 측 경로 테이블이 패킷을 전달하도록 올바르게 구성된 경우
Linux 또는 Windows 2019에서 curl을 사용하거나 Windows PowerShell과 함께 New-Object System.Net.Sockets.TcpClient 명령어를 사용하여 TCP 핸드셰이크를 테스트할 수 있습니다. 이 섹션의 워크플로는 연결 성공, 연결 시간 초과, 연결 재설정 중 하나의 결과가 표시됩니다.
- 성공: TCP 핸드셰이크가 성공적으로 완료되면 OS 방화벽 규칙이 연결을 차단하지 않고, OS가 패킷을 올바르게 전달하며, 일종의 서버가 대상 포트에서 리슨합니다. 이 경우 애플리케이션 자체에 문제가 있을 수 있습니다. 자세한 내용은 서버 동작에 대한 자세한 내용은 서버 로깅 확인을 참조하세요.
- 시간 초과: 연결이 시간 초과되면 일반적으로 다음 중 하나를 의미합니다.
- 해당 IP 주소에 머신이 없습니다.
- 방화벽이 자동으로 패킷을 삭제하고 있습니다.
- OS 패킷 라우팅이 패킷을 처리할 수 없는 대상으로 패킷을 전송하거나, 비대칭 라우팅이 잘못된 경로로 반환 패킷을 전송하고 있습니다.
재설정: 연결이 재설정되는 경우 대상 IP가 패킷을 수신 중이지만 OS 또는 애플리케이션이 패킷을 거부하고 있음을 의미합니다. 이는 다음 중 하나를 의미할 수 있습니다.
- 패킷이 잘못된 머신에 도착하였고, 머신은 해당 포트에서 해당 프로토콜에 응답하도록 구성되지 않았습니다.
- 패킷이 올바른 머신에 도착하지만 해당 포트에서 리슨 중인 서버가 없습니다.
- 패킷이 올바른 머신 및 포트에 도착하지만 상위 수준 프로토콜(예: SSL)이 핸드셰이크를 완료하지 않음
- 방화벽이 연결을 재설정하고 있습니다. 이는 방화벽이 패킷을 자동으로 삭제하는 것보다는 가능성이 적지만 발생할 수 있습니다.
Linux
Google Cloud 콘솔에서 방화벽 정책 페이지로 이동합니다.
VM에 대해 IAP에서 SSH 연결을 허용하는 방화벽 규칙이 있는지 확인하거나 새 규칙을 만듭니다.
Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.
소스 VM을 찾습니다.
VM의 연결 열에서 SSH를 클릭합니다.
클라이언트 머신 명령줄에서 다음 명령어를 실행합니다. DEST_IP:DEST_PORT를 대상 IP 주소 및 포트로 바꿉니다.
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
Windows
Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.
소스 VM을 찾습니다.
Windows VM에 연결에 설명된 방법 중 하나를 사용하여 VM에 연결합니다.
클라이언트 머신 명령줄에서 다음을 실행합니다.
- Windows 2019:
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
- Windows 2012 또는 Windows 2016 Powershell:
PS C:> New-Object System.Net.Sockets.TcpClient('DEST_IP',DEST_PORT)`
- Windows 2019:
연결 성공
다음 결과는 성공적인 TCP 핸드셰이크를 나타냅니다. TCP 핸드셰이크가 성공적으로 완료된 경우 이 문제는 TCP 연결 시간 초과 또는 재설정과 관련이 없습니다. 대신 애플리케이션 레이어 내에서 시간 초과 문제가 발생합니다. 연결에 성공하면 서버 동작에 대한 자세한 내용은 서버 로깅 확인을 진행합니다.
Linux 및 Windows 2019
$ curl -vso /dev/null --connect-timeout 5 192.168.0.4:443
'연결 대상' 행은 성공적인 TCP 핸드셰이크를 나타냅니다.
Expire in 0 ms for 6 (transfer 0x558b3289ffb0) Expire in 5000 ms for 2 (transfer 0x558b3289ffb0) Trying 192.168.0.4... TCP_NODELAY set Expire in 200 ms for 4 (transfer 0x558b3289ffb0) Connected to 192.168.0.4 (192.168.0.4) port 443 (#0) > GET / HTTP/1.1 > Host: 192.168.0.4:443 > User-Agent: curl/7.64.0 > Accept: */* > Empty reply from server Connection #0 to host 192.168.0.4 left intact
Windows 2012 및 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
연결 성공 결과. '연결됨: 참' 행이 관련성이 있습니다.
Available : 0 Client : System.Net.Sockets.Socket Connected : True ExclusiveAddressUse : False ReceiveBufferSize : 131072 SendBufferSize : 131072 ReceiveTimeout : 0 SendTimeout : 0 LingerState : System.Net.Sockets.LingerOption NoDelay : False
연결 시간 초과
다음 결과는 연결 시간이 초과되었음을 나타냅니다. 연결 시간이 초과되면 서버 IP 주소 및 포트 확인으로 진행합니다.
Linux 및 Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
연결 시간 초과 결과:
Trying 192.168.0.4:443... Connection timed out after 5000 milliseconds Closing connection 0
Windows 2012 및 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
연결 시간 초과 결과:
New-Object: Exception calling ".ctor" with "2" argument(s): "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. 192.168.0.4:443"
연결 재설정
재설정은 기기가 RST 패킷을 클라이언트에 다시 보내 클라이언트에 연결이 종료되었음을 알리는 것입니다. 다음 이유 중 하나로 인해 연결이 재설정될 수 있습니다.
- 수신 서버가 해당 포트에서 해당 프로토콜에 대한 연결을 수락하도록 구성되지 않았습니다. 이는 패킷이 잘못된 서버 또는 잘못된 포트로 전송되었거나 서버 소프트웨어가 잘못 구성되었기 때문일 수 있습니다.
- 방화벽 소프트웨어가 연결 시도를 거부했습니다.
연결이 재설정되면 올바른 IP 주소 및 포트에 액세스하고 있는지 확인합니다.
Linux 및 Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
연결 재설정 결과:
Trying 192.168.0.4:443... connect to 192.168.0.4 port 443 failed: Connection refused Failed to connect to 192.168.0.4 port 443: Connection refused Closing connection 0
Windows 2012 및 2016
PS C:\> New-Object System.Net.Sockets.TcpClientt('DEST_IP_ADDRESS', PORT)
연결 재설정 결과:
New-Object: Exception calling ".ctor" with "2" argument(s): "No connection could be made because the target machine actively refused it. 192.168.0.4:443"
서버 IP 주소 및 포트 확인
서버에서 다음 명령어 중 하나를 실행합니다. 필요한 포트에서 리슨하는 서버가 있는지 여부를 나타냅니다.
Linux
$ sudo netstat -ltuvnp
출력에 TCP 서버가 포트 22에서 모든 대상 IP 주소(0.0.0.0)를 리슨하여 모든 소스 주소(0.0.0.0) 및 모든 소스 포트(*)의 연결을 허용하는 것이 표시됩니다. PID/프로그램 이름 열은 소켓에 바인딩된 실행 파일을 지정합니다.
Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 588/sshd tcp6 0 0 :::22 :::* LISTEN 588/sshd udp 0 0 0.0.0.0:68 0.0.0.0:* 334/dhclient udp 0 0 127.0.0.1:323 0.0.0.0:* 429/chronyd udp6 0 0 ::1:323 :::* 429/chronyd
Windows
PS C:\> Get-NetTcpConnection -State "LISTEN" -LocalPort DEST_PORT
출력에 DEST_PORT가 443으로 설정된 명령어 실행 결과가 표시됩니다.
출력에 TCP 서버가 포트 443에서 모든 대상 주소(0.0.0.0)를 리슨하여 모든 소스 주소(0.0.0.0) 및 모든 소스 포트(0)의 연결을 허용하는 것이 표시됩니다. OwningProcess 열은 소켓에 리슨하는 프로세스의 프로세스 ID를 나타냅니다.
LocalAddress LocalPort RemoteAddress RemotePort State AppliedSetting OwningProcess ------------ --------- ------------- ---------- ----- -------------- ------------- :: 443 :: 0 Listen 928 0.0.0.0 443 0.0.0.0 0 Listen 928
서버가 올바른 포트 또는 IP에 결합되어 있지 않거나 원격 프리픽스가 클라이언트와 일치하지 않는 경우 서버 문서 또는 공급업체를 참조하여 문제를 해결하세요. 서버는 특정 인터페이스의 IP 주소 또는 0.0.0.0에 결합되어야 하며, 올바른 클라이언트 IP 프리픽스 또는 0.0.0.0의 연결을 허용해야 합니다.
애플리케이션 서버가 올바른 IP 주소 및 포트에 결합된 경우 클라이언트가 잘못된 포트에 액세스하고 있거나 상위 프로토콜(주로 TLS)이 연결을 적극적으로 거부하고 있거나 연결을 거부하는 방화벽이 있을 수 있습니다.
클라이언트와 서버가 동일한 TLS 버전 및 암호화 형식을 사용하고 있는지 확인합니다.
클라이언트가 올바른 포트에 액세스하고 있는지 확인합니다.
위 단계를 수행해도 문제가 해결되지 않으면 클라이언트 및 서버의 방화벽으로 인해 패킷이 삭제되었는지 확인을 진행하세요.
클라이언트 및 서버의 방화벽으로 인해 패킷이 삭제되었는지 확인
클라이언트 VM에서 서버에 연결할 수 없지만 올바른 포트에서 리슨하는 경우 VM 중 하나가 연결과 관련한 패킷을 삭제하는 방화벽 소프트웨어를 실행 중일 수 있습니다. 다음 명령어를 사용하여 클라이언트 VM과 서버 VM의 방화벽을 확인합니다.
규칙이 트래픽을 차단하는 경우 트래픽을 허용하도록 방화벽 소프트웨어를 업데이트할 수 있습니다. 방화벽을 업데이트할 경우 잘못 구성된 방화벽이 예기치 않은 트래픽을 차단할 수 있으므로 명령어를 준비하고 실행할 때 주의해서 진행해야 합니다. 계속 진행하기 전에 VM 직렬 콘솔 액세스를 설정하는 것이 좋습니다.
Linux iptables
설치된 각 iptables 체인 및 규칙에 대해 처리된 패킷 수를 확인합니다. 소스, 대상 IP 주소, 포트를 iptables 규칙으로 지정된 프리픽스와 포트와 비교하여 일치하는 DROP 규칙을 확인합니다.
일치하는 규칙에서 연결이 시간 초과하는 증가하는 삭제를 표시하는 경우 iptables 문서를 참조하여 적절한 연결에 올바른 allow 규칙을 적용하세요.
$ sudo iptables -L -n -v -x
이 INPUT 체인 예시는 대상 TCP 포트 5000을 사용하는 임의의 IP 주소에서 임의의 IP 주소로의 패킷이 방화벽에서 삭제된다는 것을 보여줍니다.
pkts 열은 규칙이 10342개의 패킷을 삭제했음을 나타냅니다. 테스트로서, 이 규칙에 의해 삭제된 연결을 만들면 pkts 카운터가 증가하여 동작을 확인할 수 있습니다.
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 10342 2078513 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5000
다음 명령어를 사용하여 iptable에 인그레스 또는 이그레스 규칙을 추가할 수 있습니다.
인그레스 규칙:
$ sudo iptables -A INPUT -p tcp -s SOURCE_IP_PREFIX --dport SERVER_PORT -j ACCEPT
이그레스 규칙:
$ sudo iptables -A OUTPUT -p tcp -d DEST_IP_PREFIX --dport DEST_PORT -j ACCEPT
Windows 방화벽
Windows 방화벽에서 연결이 클라이언트에서 이그레스로, 인그레스에서 서버로 허용되는지 확인합니다. 규칙이 트래픽을 차단하는 경우 Windows 방화벽을 수정하여 연결을 허용합니다. Windows 방화벽 로깅을 사용 설정할 수도 있습니다.
Windows 방화벽의 기본 DENY 동작은 거부된 패킷을 자동으로 삭제하는 것으로, 시간 초과가 발생합니다.
이 명령어는 서버를 확인합니다. 클라이언트 VM에서 이그레스 규칙을 확인하려면 -match 값을 Outbound로 변경합니다.
PS C:\> Get-NetFirewallPortFilter | `
>> Where-Object LocalPort -match "PORT" | `
>> Get-NetFirewallRule | `
>> Where-Object {$_.Direction -match "Inbound" -and $_.Profile -match "Any"}
Name : {80D79988-C7A5-4391-902D-382369B4E4A3}
DisplayName : iperf3 udp
Description :
DisplayGroup :
Group :
Enabled : True
Profile : Any
Platform : {}
Direction : Inbound
Action : Allow
EdgeTraversalPolicy : Block
LooseSourceMapping : False
LocalOnlyMapping : False
Owner :
PrimaryStatus : OK
Status : The rule was parsed successfully from the store. (65536)
EnforcementStatus : NotApplicable
PolicyStoreSource : PersistentStore
PolicyStoreSourceType : Local
다음 명령어를 사용하여 Windows에 새 방화벽 규칙을 추가할 수 있습니다.
이그레스 규칙:
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=out action=allow protocol=TCP remoteport=DEST_PORT
인그레스 규칙:
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=in action=allow protocol=TCP localport=PORT
타사 소프트웨어
타사 애플리케이션 방화벽이나 바이러스 백신 소프트웨어가 연결을 끊거나 거부할 수도 있습니다. 공급업체가 제공하는 문서를 참조하세요.
방화벽 규칙에 문제가 있어 해결한 경우 연결을 다시 테스트합니다. 방화벽 규칙에 문제가 없는 것 같으면 OS 라우팅 구성 확인을 진행합니다.
OS 라우팅 구성 확인
운영체제 라우팅 문제는 다음 상황 중 하나에서 발생할 수 있습니다.
- 라우팅 문제는 배가된 라우팅 복잡성 때문에 다중 네트워크 인터페이스가 있는 VM에서 가장 흔하게 볼 수 있습니다.
- 단일 네트워크 인터페이스가 있는 Google Cloud에서 생성된 VM에서 라우팅 문제는 일반적으로 다른 사용자가 기본 라우팅 테이블을 수동으로 수정한 경우에만 발생합니다.
- 온프레미스에서 마이그레이션된 VM에서는 라우팅 또는 MTU 설정이 온프레미스에 필요했더라도 VPC 네트워크에서 문제를 일으키면 VM에서 이 설정을 넘길 수 있습니다.
여러 네트워크 인터페이스가 있는 VM을 사용하는 경우 올바른 vNIC 및 서브넷으로 이그레스하도록 경로를 구성해야 합니다. 예를 들어 VM에 경로가 구성되어 내부 서브넷을 대상으로 하는 트래픽이 하나의 vNIC로 전송될 수 있지만 기본 게이트웨이(대상 0.0.0.0/0)는 외부 IP 주소 또는 Cloud NAT에 대한 액세스 권한이 있는 다른 vNIC에서 구성됩니다.
개별 경로를 한 번에 하나씩 확인하거나 전체 VM 라우팅 테이블을 확인하여 경로를 검토할 수 있습니다. 두 가지 방법 모두 라우팅 테이블에서 문제가 발생하는 경우 필요한 경우 라우팅 테이블 업데이트의 안내를 참조하세요.
모든 경로 검토
모든 경로를 나열하여 VM에 이미 있는 경로를 파악합니다.
Linux
$ ip route show table all
default via 10.3.0.1 dev ens4 10.3.0.1 dev ens4 scope link local 10.3.0.19 dev ens4 table local proto kernel scope host src 10.3.0.19 broadcast 10.3.0.19 dev ens4 table local proto kernel scope link src 10.3.0.19 broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 ::1 dev lo proto kernel metric 256 pref medium fe80::/64 dev ens4 proto kernel metric 256 pref medium local ::1 dev lo table local proto kernel metric 0 pref medium local fe80::4001:aff:fe03:13 dev ens4 table local proto kernel metric 0 pref medium multicast ff00::/8 dev ens4 table local proto kernel metric 256 pref medium
Windows
PS C:\> Get-NetRoute
ifIndex DestinationPrefix NextHop RouteMetric ifMetric PolicyStore ------- ----------------- ------- ----------- -------- ----------- 4 255.255.255.255/32 0.0.0.0 256 5 ActiveStore 1 255.255.255.255/32 0.0.0.0 256 75 ActiveStore 4 224.0.0.0/4 0.0.0.0 256 5 ActiveStore 1 224.0.0.0/4 0.0.0.0 256 75 ActiveStore 4 169.254.169.254/32 0.0.0.0 1 5 ActiveStore 1 127.255.255.255/32 0.0.0.0 256 75 ActiveStore 1 127.0.0.1/32 0.0.0.0 256 75 ActiveStore 1 127.0.0.0/8 0.0.0.0 256 75 ActiveStore 4 10.3.0.255/32 0.0.0.0 256 5 ActiveStore 4 10.3.0.31/32 0.0.0.0 256 5 ActiveStore 4 10.3.0.1/32 0.0.0.0 1 5 ActiveStore 4 10.3.0.0/24 0.0.0.0 256 5 ActiveStore 4 0.0.0.0/0 10.3.0.1 0 5 ActiveStore 4 ff00::/8 :: 256 5 ActiveStore 1 ff00::/8 :: 256 75 ActiveStore 4 fe80::b991:6a71:ca62:f23f/128 :: 256 5 ActiveStore 4 fe80::/64 :: 256 5 ActiveStore 1 ::1/128 :: 256 75 ActiveStore
개별 경로 확인
특정 IP 프리픽스가 문제인 것처럼 보이면 클라이언트 및 서버 VM 내의 소스 및 대상 IP에 대해 적절한 경로가 있는지 확인합니다.
Linux
$ ip route get DEST_IP
좋음 결과:
유효한 경로가 표시됩니다. 이 경우 패킷이 ens4 인터페이스에서 이그레스됩니다.
10.3.0.34 via 10.3.0.1 dev ens4 src 10.3.0.26 uid 1000 cache
잘못됨 결과:
이 결과는 대상 네트워크에 대한 경로가 없기 때문에 패킷이 삭제되고 있음을 확인합니다. 경로 테이블에 올바른 이그레스 인터페이스 경로가 포함되어 있는지 확인합니다.
**RTNETLINK answers: Network is unreachable
Windows
PS C:\> Find-NetRoute -RemoteIpAddress "DEST_IP"
좋음 결과:
IPAddress : 192.168.0.2 InterfaceIndex : 4 InterfaceAlias : Ethernet AddressFamily : IPv4 Type : Unicast PrefixLength : 24 PrefixOrigin : Dhcp SuffixOrigin : Dhcp AddressState : Preferred ValidLifetime : 12:53:13 PreferredLifetime : 12:53:13 SkipAsSource : False PolicyStore : ActiveStore Caption : Description : ElementName : InstanceID : ;:8=8:8:9<>55>55:8:8:8:55; AdminDistance : DestinationAddress : IsStatic : RouteMetric : 256 TypeOfRoute : 3 AddressFamily : IPv4 CompartmentId : 1 DestinationPrefix : 192.168.0.0/24 InterfaceAlias : Ethernet InterfaceIndex : 4 InterfaceMetric : 5 NextHop : 0.0.0.0 PreferredLifetime : 10675199.02:48:05.4775807 Protocol : Local Publish : No State : Alive Store : ActiveStore ValidLifetime : 10675199.02:48:05.4775807 PSComputerName : ifIndex : 4
잘못됨 결과:
Find-NetRoute : The network location cannot be reached. For information about network troubleshooting, see Windows Help.
At line:1 char:1
+ Find-NetRoute -RemoteIpAddress "192.168.0.4"
+ ----------------------------------------
+ CategoryInfo : NotSpecified: (MSFT_NetRoute:ROOT/StandardCimv2/MSFT_NetRoute) [Find-NetRoute], CimException
+ FullyQualifiedErrorId : Windows System Error 1231,Find-NetRoute
이 명령어는 대상 IP 주소에 대한 경로가 없기 때문에 패킷이 삭제되고 있음을 확인합니다. 기본 게이트웨이가 있고 게이트웨이가 올바른 vNIC 및 네트워크에 적용되는지 확인합니다.
라우팅 테이블 업데이트
필요한 경우 운영체제의 경로 테이블에 경로를 추가할 수 있습니다. 라우팅 VM의 라우팅 테이블을 업데이트하는 명령어를 실행하기 전에 명령어를 숙지하고 발생 가능한 영향을 파악하는 것이 좋습니다. 경로 업데이트 명령어를 잘못 사용하면 예기치 않은 문제가 발생하거나 VM 연결이 끊어질 수 있습니다. 계속 진행하기 전에 VM 직렬 콘솔 액세스를 설정하는 것이 좋습니다.
경로 업데이트에 대한 안내는 운영체제 문서를 참조하세요.
경로에 문제가 있어 해결한 경우 연결을 다시 테스트합니다. 경로에 문제가 없는 것 같으면 인터페이스 MTU 확인을 진행합니다.
MTU 확인
VM의 인터페이스 MTU는 연결된 VPC 네트워크의 MTU와 일치해야 합니다. 이상적으로는 서로 통신하는 VM도 일치하는 MTU가 있습니다. 일치하지 않는 MTU는 일반적으로 TCP에서는 문제가 되지 않지만 UDP에서는 문제가 될 수 있습니다.
VPC의 MTU를 확인합니다. VM이 서로 다른 2개의 네트워크에 있다면 두 네트워크 모두 확인합니다.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
클라이언트 및 서버 네트워크 인터페이스의 MTU 구성을 확인합니다.
Linux
$ netstat -i
lo(루프백) 인터페이스는 항상 MTU가 65536이며 이 단계에서 무시해도 됩니다.
Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg ens4 1460 8720854 0 0 0 18270406 0 0 0 BMRU lo 65536 53 0 0 0 53 0 0 0 LRU
Windows
PS C:\> Get-NetIpInterface
루프백 유사 인터페이스는 항상 MTU가 4294967295이며 이 단계에서 무시해도 됩니다.
ifIndex InterfaceAlias Address NlMtu(Bytes) Interface Dhcp Connection PolicyStore
Family Metric State
------- -------------- ------- ------------ --------- ---- ---------- -----------
4 Ethernet IPv6 1500 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
4 Ethernet IPv4 1460 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected Active
인터페이스 및 네트워크 MTU가 일치하지 않으면 인터페이스 MTU를 다시 구성할 수 있습니다. 자세한 내용은 VM 및 MTU 설정을 참조하세요. 두 항목이 일치하고 지금까지 문제 해결 단계를 수행한 경우 서버 자체에 문제가 있을 가능성이 높습니다. 서버 문제 해결에 대한 지침은 서버 동작에 대한 자세한 내용은 서버 로깅 확인을 참조하세요.
서버 동작에 대한 자세한 내용은 서버 로깅 확인
위 단계를 수행해도 문제가 해결되지 않으면 애플리케이션에 시간 초과가 발생할 수 있습니다. 서버 및 애플리케이션 로그에서 현재 상태를 설명하는 동작을 확인합니다.
확인할 로그 소스:
- VM용 Cloud Logging
- VM 직렬 로그
- Linux syslog, kern.log 또는 Windows 이벤트 뷰어
문제가 계속 발생하는 경우
문제가 계속되면 다음 단계를 위한 지원 받기를 참조하세요. 위 문제 해결 단계의 결과를 다른 공동작업자와 공유하면 유용합니다.
처리량 문제를 일으킨 네트워크 지연 시간 또는 손실 문제 해결
네트워크 지연 시간 또는 손실 문제는 일반적으로 VM 또는 네트워크 경로 내의 리소스 소진 또는 병목 현상으로 인해 발생합니다. 가끔 네트워크 손실로 인해 간헐적인 연결 시간 초과가 발생할 수 있습니다. vCPU 소진 또는 vNIC 포화와 같은 원인으로 인해 지연 시간 및 패킷 손실이 증가하여 네트워크 성능이 저하됩니다.
다음 안내에서는 연결이 지속적으로 시간 초과되지 않고, 대신 용량 제한이나 성능의 문제가 발생한다고 가정합니다. 전체 패킷이 손실되면 전체 연결 실패 문제 해결을 참조하세요.
지연 시간이 몇 밀리초 단위로 변하는 등 지연 시간의 작은 변화는 정상입니다. 네트워크 부하 또는 VM 내부의 큐로 인해 지연 시간이 달라집니다.
연결 값 결정
먼저 다음 정보를 수집합니다.
- VM 인스턴스 페이지에서 두 VM의 다음 정보를 수집합니다.
- VM 이름
- VM 영역
- 통신 중인 vNIC의 내부 IP 주소
- 대상 서버 소프트웨어 구성에서 다음 정보를 수집합니다.
- 레이어 4 프로토콜
- 대상 포트
여러 VM에서 문제가 발생하면 문제가 있는 단일 소스 및 단일 대상 VM을 선택하고 해당 값을 사용하세요. 일반적으로 연결의 소스 포트는 필요하지 않습니다.
이 정보가 있으면 기본 Google 네트워크 관련 문제 조사로 진행하세요.
기본 Google 네트워크 관련 문제 조사
설정이 최근에 변경되지 않은 기존 설정인 경우 기본 Google 네트워크에 문제가 있을 수 있습니다. 성능 대시보드에서 VM 영역 간 패킷 손실을 확인합니다. 네트워크 시간 초과가 발생한 기간 동안 영역 간 패킷 손실이 증가하면 가상 네트워크의 기반이 되는 물리적 네트워크에 문제가 있을 수 있습니다. 지원 케이스를 제출하기 전에 Google Cloud 상태 대시보드에서 알려진 문제를 확인하세요.
기본 Google 네트워크에 문제가 없는 것 같으면 핸드셰이크 지연 시간 확인으로 진행하세요.
핸드셰이크 지연 시간 확인
모든 연결 기반 프로토콜은 연결 설정 핸드셰이크를 수행하는 동안 지연 시간이 발생합니다. 각 프로토콜 핸드셰이크가 오버헤드에 추가됩니다. SSL/TLS 연결의 경우, 예를 들어 SSL/TLS 핸드셰이크가 시작되려면 TCP 핸드셰이크가 완료된 다음 데이터가 전송되기 전에 TLS 핸드셰이크가 완료되어야 합니다.
동일한 Google Cloud 영역에서 핸드셰이크 지연 시간은 일반적으로 무시할 수 있지만 전역으로 멀리 떨어진 위치에 대한 핸드셰이크에서는 연결 초기화 시 지연이 더 많이 발생할 수 있습니다. 멀리 떨어진 리전에 리소스가 있는 경우 발생하는 지연 시간이 프로토콜 핸드셰이크로 인해 발생하는지 확인할 수 있습니다.
Linux 및 Windows 2019
$ curl -o /dev/null -Lvs -w 'tcp_handshake: %{time_connect}s, application_handshake: %{time_appconnect}s' DEST_IP:PORT
tcp_handshake: 0.035489s, application_handshake: 0.051321s
- tcp_handshake는 클라이언트가 초기 SYN 패킷을 전송한 시점부터 TCP 핸드셰이크의 ACK를 전송할 때까지의 기간입니다.
- application_handshake는 TCP 핸드셰이크의 첫 번째 SYN 패킷부터 TLS(일반적) 핸드셰이크 완료까지 걸리는 시간입니다.
- 추가 핸드셰이크 시간 = application_handshake - tcp_handshake
Windows 2012 및 2016
기본 OS 도구에서는 사용할 수 없습니다. 방화벽 규칙이 허용되는 경우 ICMP 왕복 시간을 참조로 사용할 수 있습니다.
지연 시간이 핸드셰이크가 고려하는 것보다 많은 경우 VM 유형의 최대 처리량 확인으로 진행하세요.
VM 유형의 최대 처리량 확인
VM 네트워크 이그레스 처리량은 VM CPU 아키텍처 및 vCPU 수에 따라 제한됩니다. 네트워크 대역폭 페이지를 참조하여 VM의 잠재적인 이그레스 대역폭을 결정합니다.
VM이 이그레스 요구사항을 충족할 수 없는 경우 용량이 더 큰 VM으로 업그레이드하는 것이 좋습니다. 자세한 내용은 인스턴스의 머신 유형 변경을 참조하세요.
머신 유형이 충분한 이그레스 대역폭을 허용해야 하는 경우 Persistent Disk 사용량이 네트워크 이그레스를 방해하는지 조사합니다. Persistent Disk 작업은 VM의 총 네트워크 처리량의 최대 60% 를 점유할 수 있습니다. Persistent Disk 작업이 네트워크 처리량을 방해할 수 있는지 확인하려면 Persistent Disk 성능 확인을 참조하세요.
VM에 대한 네트워크 인그레스는 VPC 네트워크 또는 VM 인스턴스 유형으로 제한되지 않습니다. 대신 VM 운영체제 또는 애플리케이션의 패킷 큐 및 처리 성능에 따라 결정됩니다. 이그레스 대역폭이 충분하지만 인그레스 문제가 발생하는 경우 서버 동작에 대한 자세한 내용은 서버 로깅 확인을 참조하세요.
인터페이스 MTU 확인
VPC 네트워크의 MTU는 구성 가능합니다. VM 인터페이스의 MTU는 연결된 VPC 네트워크의 MTU 값과 일치해야 합니다. VPC 네트워크 피어링 상황에서 서로 다른 네트워크의 VM은 MTU가 다를 수 있습니다. 이 시나리오가 발생하면 연결된 인터페이스에 더 작은 MTU 값을 적용합니다. MTU 불일치는 일반적으로 TCP에서는 문제가 되지 않지만 UDP에서는 문제가 될 수 있습니다.
VPC의 MTU를 확인합니다. VM이 서로 다른 2개의 네트워크에 있다면 두 네트워크 모두 확인합니다.
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
네트워크 인터페이스의 MTU 구성을 확인합니다.
Linux
lo(루프백) 인터페이스는 항상 MTU가 65536이며 이 단계에서 무시해도 됩니다.
$ netstat -i
Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg ens4 1460 8720854 0 0 0 18270406 0 0 0 BMRU lo 65536 53 0 0 0 53 0 0 0 LRU
Windows
PS C:\> Get-NetIpInterface
루프백 유사 인터페이스는 항상 MTU가 4294967295이며 이 단계에서 무시해도 됩니다.
ifIndex InterfaceAlias Address NlMtu(Bytes) Interface Dhcp Connection PolicyStore
Family Metric State
------- -------------- ------- ------------ --------- ---- ---------- -----------
4 Ethernet IPv6 1500 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
4 Ethernet IPv4 1460 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected Active
인터페이스 및 네트워크 MTU가 일치하지 않으면 인터페이스 MTU를 다시 구성할 수 있습니다. Windows VM의 MTU를 업데이트하는 방법은 VM 및 MTU 설정을 참조하세요. 두 항목이 일치하는 경우 서버 가용성 문제일 수 있습니다. 다음 단계는 로그에서 VM이 재부팅, 중지 또는 라이브 마이그레이션되었는지 확인하여 관련 시간 동안 VM에 어떤 일이 발생했는지 확인하는 것입니다.
로그에서 VM이 재부팅, 중지 또는 라이브 마이그레이션되었는지 확인
VM의 수명 주기 동안 VM은 사용자가 재부팅하거나, Google Cloud 유지보수를 위해 라이브 마이그레이션되거나, 드물게 VM이 포함된 물리적 호스트 내에서 장애가 발생한 경우 VM이 손실되었다가 다시 생성될 수 있습니다. 이러한 이벤트로 인해 지연 시간 또는 연결 시간 초과가 약간 증가할 수 있습니다. 이러한 상황이 VM에서 발생하면 이벤트가 로깅됩니다.
VM의 로그를 보려면 다음 안내를 따르세요.
Google Cloud 콘솔에서 Logging 페이지로 이동합니다.
지연 시간이 발생한 기간을 선택합니다.
다음 Logging 쿼리를 사용하여 지연 시간이 발생한 기간 근처에 VM 이벤트가 발생했는지 확인합니다.
resource.labels.instance_id:"INSTANCE_NAME" resource.type="gce_instance" ( protoPayload.methodName:"compute.instances.hostError" OR protoPayload.methodName:"compute.instances.OnHostMaintenance" OR protoPayload.methodName:"compute.instances.migrateOnHostMaintenance" OR protoPayload.methodName:"compute.instances.terminateOnHostMaintenance" OR protoPayload.methodName:"compute.instances.stop" OR protoPayload.methodName:"compute.instances.reset" OR protoPayload.methodName:"compute.instances.automaticRestart" OR protoPayload.methodName:"compute.instances.guestTerminate" OR protoPayload.methodName:"compute.instances.instanceManagerHaltForRestart" OR protoPayload.methodName:"compute.instances.preempted" )
관련 시간 동안 VM이 다시 시작되지 않거나 마이그레이션되지 않으면 리소스 소진 문제일 수 있습니다. 확인하려면 리소스 소진으로 인한 네트워크 및 OS 통계에서 패킷 삭제 확인을 참조하세요.
리소스 소진으로 인한 네트워크 및 OS 통계에서 패킷 삭제 확인
리소스 소진은 이그레스 대역폭과 같은 VM의 일부 리소스가 처리할 수 있는 것보다 더 많은 양을 처리해야 하는 경우를 의미하는 일반적인 용어입니다. 리소스가 소진되면 주기적으로 패킷이 삭제되어 연결 지연 시간 또는 시간 초과가 발생할 수 있습니다. 이러한 시간 초과는 클라이언트 또는 서버 시작 시 표시되지 않을 수 있지만 시스템이 리소스를 소진하면 표시될 수 있습니다.
다음은 패킷 카운터 및 통계를 표시하는 명령어 목록입니다. 이러한 명령어 중 일부는 다른 명령어의 결과를 복제합니다. 이러한 경우에는 더 적합한 명령어를 사용하면 됩니다. 명령어를 실행할 때의 결과를 더 잘 이해하려면 각 섹션 내의 참고 사항을 참조하세요. 명령어를 서로 다른 시간에 실행하여 삭제 또는 오류가 문제와 동시에 발생하는지 확인하는 것이 유용할 수 있습니다.
Linux
네트워크 통계를 보려면
netstat명령어를 사용합니다.$ netstat -sTcpExt: 341976 packets pruned from receive queue because of socket buffer overrun 6 ICMP packets dropped because they were out-of-window 45675 TCP sockets finished time wait in fast timer 3380 packets rejected in established connections because of timestamp 50065 delayed acks sent
netstat 명령어는 프로토콜에 의해 삭제된 패킷의 값이 포함된 네트워크 통계를 출력합니다. 삭제된 패킷은 애플리케이션 또는 네트워크 인터페이스의 리소스 소진 결과일 수 있습니다. 카운터가 증가한 이유를 나타내는 카운터 이유를 확인합니다.
kern.log에서
nf_conntrack: table full, dropping packet과 일치하는 로그를 확인합니다.Debian:
cat /var/log/kern.log | grep "dropping packet"CentOS:
sudo cat /var/log/dmesg | grep "dropping packet"이 로그는 VM의 연결 추적 테이블이 추적 가능한 최대 연결에 도달했음을 나타냅니다. 이 VM과의 추가 연결은 시간 초과될 수 있습니다. conntrack을 사용 설정한 경우 최대 연결 수는
sudo sysctl net.netfilter.nf_conntrack_max로 확인할 수 있습니다.최대 추적 연결 값을 늘리려면 sysctl
net.netfilter.nf_conntrack_max를 수정하거나 VM 워크로드를 여러 VM에 분산하여 부하를 줄이면 됩니다.
Windows UI
perfmon
- Windows 메뉴에서 'perfmon'을 검색하고 프로그램을 엽니다.
- 왼쪽 메뉴에서 성능 > 모니터링 도구 > 성능 모니터링을 선택합니다.
- 기본 뷰에서 녹색 더하기 '+'를 클릭하여 모니터링 그래프에 성능 카운터를 추가합니다. 다음은 관련된 카운터입니다.
- 네트워크 어댑터
- 출력 큐 길이
- 패킷 아웃바운드가 삭제됨
- 패킷 아웃바운드 오류
- 수신된 패킷이 삭제됨
- 수신된 패킷 오류
- 수신된 패킷을 알 수 없음
- 네트워크 인터페이스
- 출력 큐 길이
- 패킷 아웃바운드가 삭제됨
- 패킷 아웃바운드 오류
- 수신된 패킷이 삭제됨
- 수신된 패킷 오류
- 수신된 패킷을 알 수 없음
- 프로세서별 네트워크 인터페이스 카드 활동
- 낮은 리소스 수신 표시/초
- 낮은 리소스 수신 패킷/초
- 프로세서
- 중단 시간 비율
- 권한이 높은 시간 비율
- 프로세서 시간 비율
- 사용자 시간 비율
- 네트워크 어댑터
Pefmon을 사용하면 위의 카운터를 시계열 그래프에 표시할 수 있습니다. 이는 테스트가 진행 중이거나 서버가 영향을 받는 경우 관찰하는 데 유용할 수 있습니다. 중단 시간 및 권한이 높은 시간 등 CPU 관련 카운터가 급증하면 VM이 CPU 처리량 제한에 도달할 때 포화 문제를 나타낼 수 있습니다. 패킷 삭제 및 오류는 CPU가 포화 상태일 때 발생할 수 있으며, 이로 인해 패킷은 클라이언트 또는 서버 소켓에서 처리되기 전에 손실됩니다. 마지막으로, 처리를 위해 큐에 추가된 패킷이 많아지면 CPU 포화 상태 중에도 출력 큐 길이가 늘어납니다.
Windows Powershell
PS C:\> netstat -s
IPv4 Statistics Packets Received = 56183 Received Header Errors = 0 Received Address Errors = 0 Datagrams Forwarded = 0 Unknown Protocols Received = 0 Received Packets Discarded = 25 Received Packets Delivered = 56297 Output Requests = 47994 Routing Discards = 0 Discarded Output Packets = 0 Output Packet No Route = 0 Reassembly Required = 0 Reassembly Successful = 0 Reassembly Failures = 0 Datagrams Successfully Fragmented = 0 Datagrams Failing Fragmentation = 0 Fragments Created = 0
netstat 명령어는 프로토콜에 의해 삭제된 패킷의 값이 포함된 네트워크 통계를 출력합니다. 삭제된 패킷은 애플리케이션 또는 네트워크 인터페이스의 리소스 소진 결과일 수 있습니다.
리소스 소진이 확인된 경우 더 많은 인스턴스에 워크로드를 분산하거나, 리소스가 더 많은 VM으로 업그레이드하거나, 특정 성능 니즈에 맞게 OS 또는 애플리케이션을 조정하거나, 오류 메시지를 입력하여 검색엔진에 가능한 해결책을 찾거나, 여전히 문제가 발생한 경우에 설명된 방법 중 하나를 사용하여 도움을 요청하세요.
리소스 소진이 문제가 아닌 것 같다면 서버 소프트웨어 자체에 문제가 있을 수 있습니다. 서버 소프트웨어 문제 해결에 대한 안내는 서버 동작에 대한 자세한 내용은 서버 로깅 확인을 참조하세요.
서버 동작에 대한 자세한 내용은 서버 로깅 확인
위 단계에서 문제가 드러나지 않으면 vCPU 소진으로 인한 처리 중단과 같은 애플리케이션 동작으로 인해 시간 초과가 발생할 수 있습니다. 서버 및 애플리케이션 로그에서 현재 발생하는 동작의 징후를 확인합니다.
예를 들어 과부하 데이터베이스와 같은 업스트림 시스템으로 인해 지연 시간이 증가된 서버에서는 과도한 양의 요청이 큐에 추가되어 메모리 사용량 및 CPU 대기 시간을 증가시킬 수 있습니다. 이로 인해 연결이 실패하거나 소켓 버퍼가 초과될 수 있습니다.
TCP 연결은 패킷을 잃는 경우가 있지만 선택적 확인 및 패킷 재전송은 일반적으로 손실된 패킷을 복구하여 연결 시간 초과를 방지합니다. 대신 애플리케이션 서버가 실패하거나 재배포되어 시간 초과가 발생하여 연결이 잠시 실패했을 수 있습니다.
서버 애플리케이션이 데이터베이스 또는 다른 서비스에 대한 연결을 사용하는 경우 결합된 서비스가 제대로 작동하지 않는지 확인합니다. 애플리케이션은 이러한 측정항목을 추적할 수 있습니다.
문제가 계속 발생하는 경우
문제가 계속되면 다음 단계를 위한 지원 받기를 참조하세요. 문제 해결 단계의 결과를 다른 공동작업자와 공유하면 유용합니다.
다음 단계
- 문제가 계속되면 리소스 페이지를 참조하세요.