다음 홉으로 사용되는 내부 패스 스루 네트워크 부하 분산기

내부 패스 스루 네트워크 부하 분산기는 내부 IP 주소 뒤에서 서비스를 실행 및 확장할 수 있게 해주는 리전 부하 분산기입니다. 내부 패스 스루 네트워크 부하 분산기를 패킷이 최종 목적지로 가는 경로를 따라 전달되는 다음 홉으로 사용할 수 있습니다. 이를 위해 부하 분산기를 정적 경로다음 홉으로 설정합니다.

이 페이지의 정보를 검토하기 전에 다음 개념을 숙지해야 합니다.

내부 패스 스루 네트워크 부하 분산기의 다음 홉은 다음 경우에 유용합니다.

  • 게이트웨이 또는 라우터 VM으로 작동하는 여러 VM 간에 트래픽을 부하 분산해야 하는 경우

  • 기본 경로에 대한 다음 홉으로 게이트웨이 가상 어플라이언스를 사용해야 하는 경우. 이 구성을 사용하면 Virtual Private Cloud(VPC) 네트워크의 가상 머신(VM) 인스턴스가 부하 분산된 가상 게이트웨이 VM 집합을 통해 인터넷에 트래픽을 전송합니다.

  • 백엔드와 동일한 다중 NIC 게이트웨이 또는 라우터 VM 집합을 사용하여 두 개 이상의 방향으로 여러 부하 분산기를 통해 트래픽을 전송해야 하는 경우. 이렇게 하려면 부하 분산기를 만들고 VPC 네트워크의 정적 경로에 대해 다음 홉으로 사용합니다. 각 내부 패스 스루 네트워크 부하 분산기는 단일 VPC 네트워크 내에서 작동하며, 해당 네트워크에서 백엔드 VM의 네트워크 인터페이스로 트래픽을 분산합니다.

아키텍처

다음 다이어그램에서 라우터 VM의 VM 인스턴스 그룹은 서로 다른 두 부하 분산기의 백엔드로 작동합니다. 첫 번째 내부 패스 스루 네트워크 부하 분산기는 백엔드 VM의 nic0에 패킷을 전송하고, 두 번째 내부 패스 스루 네트워크 부하 분산기는 동일한 백엔드의 nic1에 패킷을 전송합니다.

여러 NIC로 부하 분산
여러 NIC로 부하 분산(확대하려면 클릭)

내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 사용할 때의 이점

부하 분산기가 정적 경로의 다음 홉이면 경로가 정의된 VPC 네트워크에서 클라이언트 VM의 게스트 운영체제 내에 특별한 구성이 필요하지 않습니다. 클라이언트 VM은 bump-in-the-wire 방식으로 VPC 네트워크 라우팅을 통해 부하 분산기의 백엔드로 패킷을 전송합니다.

내부 패스 스루 네트워크 부하 분산기를 정적 경로의 다음 홉으로 사용하면 독립형 내부 패스 스루 네트워크 부하 분산기와 동일한 이점을 갖습니다. 부하 분산기의 상태 점검은 새 연결이 정상적인 백엔드 VM으로 라우팅되도록 보장합니다. 관리형 인스턴스 그룹을 백엔드로 사용하여 서비스 요구에 따라 VM 집합을 늘리거나 줄이도록 자동 확장을 구성할 수 있습니다.

사양

다음은 내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 사용하기 위한 사양입니다.

경로

정적 경로를 만들어 부하 분산기가 정적 경로의 다음 홉인 내부 패스 스루 네트워크 부하 분산기로 TCP, UDP, 기타 프로토콜 트래픽을 전달할 수 있습니다. 경로는 외부(공개적으로 라우팅 가능한) CIDR 프리픽스이거나 프리픽스가 서브넷 경로와 충돌하지 않는 경우 내부 CIDR 프리픽스일 수 있습니다. 예를 들어 기본 경로(0.0.0.0/0)를 패킷 처리를 위해 타사 백엔드 VM으로 트래픽을 보내는 경로로 바꿀 수 있습니다.

다음 홉 지정 옵션

다음 두 가지 방법 중 하나로 내부 패스 스루 네트워크 부하 분산기 다음 홉을 지정할 수 있습니다.

  • 전달 규칙의 이름 및 리전 사용
  • 전달 규칙의 IP 주소 사용

내부 패스 스루 네트워크 부하 분산기 다음 홉이 있을 수 있는 프로젝트 및 VPC 네트워크에 대한 자세한 내용은 다음 홉 및 기능을 참조하세요.

VPC 네트워크 피어링을 사용하여 정적 경로를 내부 패스 스루 네트워크 부하 분산기 다음 홉과 교환할 수 있습니다. 자세한 내용은 정적 경로 교환 옵션을 참조하세요.

클라이언트 IP 세션 어피니티

내부 패스 스루 네트워크 부하 분산기는 두 가지 비슷한 '클라이언트 IP 주소' 세션 어피니티 옵션을 제공합니다.

  • 클라이언트 IP(CLIENT_IP): 패킷의 소스 IP 주소 및 대상 IP 주소에 대한 2튜플 해시입니다. 내부 패스 스루 네트워크 부하 분산기가 경로의 다음 홉이 아니면 부하 분산기의 전달 규칙 IP 주소로 전송되는 패킷이 공통 대상 IP 주소(전달 규칙 IP 주소)를 공유합니다. 이 상황에서 2튜플 해시에 사용되는 주소 중 하나는 일정하게 유지됩니다. 따라서 구성된 정상 상태의 백엔드 수가 변경하지 않고 패킷에 포함된 소스 IP 주소가 동일하면 이 2튜플 세션 어피니티 옵션이 동일한 백엔드를 선택합니다.
  • 클라이언트 IP, 대상 없음(CLIENT_IP_NO_DESTINATION): 패킷의 소스 IP 주소의 1튜플 해시입니다. 내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 사용할 때는 대상 IP 주소가 경로의 대상 속성으로 지정되기 때문에 대상 IP 주소가 자주 변경됩니다. 이 경우 2튜플 해시 클라이언트 IP(CLIENT_IP) 세션 어피니티는 구성된 정상 백엔드 수가 변경되지 않고 패킷의 소스 IP 주소가 동일하더라도 동일한 백엔드를 선택할 수 없습니다. (이 규칙의 예외는 백엔드가 하나만 구성된 경우입니다.) 소스 IP 주소가 동일한 패킷을 동일한 백엔드로 라우팅해야 할 경우 클라이언트 IP, 대상 없음(CLIENT_IP_NO_DESTINATION) 세션 어피니티 옵션을 사용해야 합니다.

대상 범위

정적 경로의 대상 위치는 서브넷 경로와 일치하거나 그보다 구체적일 수 없습니다. 더 구체적인 경우 서브넷 마스크가 더 길다는 것을 의미합니다. 이 규칙은 다음 홉이 내부 패스 스루 네트워크 부하 분산기인 경우를 포함한 모든 정적 경로에 적용됩니다. 예를 들어 서브넷 경로가 10.140.0.0/20이라고 가정해 보겠습니다. 정적 경로의 대상 위치는 10.140.0.0/20과 같을 수 없으며 10.140.0.0/22와 같이 더 구체적일 수 없습니다.

동일한 VPC 네트워크 및 리전

내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 사용하는 정적 경로는 다음으로 제한됩니다.

  • 단일 VPC 네트워크. 부하 분산기와 정적 경로가 동일한 VPC 네트워크에 있어야 합니다.

  • 단일 리전 또는 모든 리전. 전역 액세스를 구성하지 않는 한 부하 분산기와 동일한 리전에 있는 리소스만 정적 경로를 사용할 수 있습니다. 이 리전 제한은 경로 자체가 전체 VPC 네트워크의 라우팅 테이블의 일부인 경우에도 적용됩니다. 전역 액세스를 사용 설정하면 모든 리전의 리소스가 정적 경로를 사용할 수 있습니다.

정적 경로 공지

정적 경로에 대해 프리픽스(목적지)를 공지하려면 Cloud Router 커스텀 공지 모드를 사용하세요. 경로 공지 범위는 다음과 같이 부하 분산기의 전역 액세스 설정에 따라 달라집니다.

  • 전역 액세스가 중지되어 있으면 내부 패스 스루 네트워크 부하 분산기가 부하 분산기와 동일한 리전에 있는 VM, Cloud VPN 터널, Cloud Interconnect 연결(VLAN)에만 제공됩니다. 따라서 정적 경로의 프리픽스에 대한 커스텀 경로 공지는 Cloud Router와 부하 분산기가 동일한 리전에 있는 경우에만 가능합니다.

  • 전역 액세스가 사용 설정되어 있으면 내부 패스 스루 네트워크 부하 분산기가 리전에 관계없이 모든 VM, Cloud VPN 터널, Cloud Interconnect 연결(VLAN)에 제공됩니다. 전역 동적 라우팅을 통해 온프레미스 시스템이 연결된 모든 리전의 정적 경로를 사용할 수 있습니다.

다음 표에서는 부하 분산기의 접근성을 요약해서 보여줍니다.

전역 액세스 VPC 네트워크 동적 라우팅 모드 부하 분산기 액세스
사용 중지됨 리전 동일한 리전에 있는 라우터에서 액세스 가능
사용 중지됨 전역 동일한 리전에 있는 라우터에서 액세스 가능
사용 설정됨 리전 모든 리전의 모든 라우터에서 액세스 가능
사용 설정됨 전역 모든 리전의 모든 라우터에서 액세스 가능

자세한 내용은 내부 패스 스루 네트워크 부하 분산기 및 연결된 네트워크를 참조하세요.

작업 순서

다음 홉으로 사용되는 정적 경로를 만들려면 먼저 내부 패스 스루 네트워크 부하 분산기를 만들어야 합니다. 경로를 만들려면 먼저 부하 분산기가 있어야 합니다. 존재하지 않는 부하 분산기를 참조하는 경로를 만들려고 시도하면 Google Cloud에서 오류가 반환됩니다.

전달 규칙의 이름 및 부하 분산기 리전을 사용하거나 전달 규칙과 연결된 내부 IP 주소를 사용하여 내부 패스 스루 네트워크 부하 분산기 다음 홉을 지정합니다.

내부 패스 스루 네트워크 부하 분산기를 참조하는 다음 홉이 포함된 경로를 만든 다음에는 경로를 먼저 삭제하지 않는 한, 부하 분산기를 삭제할 수 없습니다. 특히 이 부하 분산기를 다음 홉으로 사용하는 정적 경로가 없을 때까지 내부 전달 규칙을 삭제할 수 없습니다.

백엔드 요구사항

  • IP 전달 (--can-ip-forward = True)을 허용하도록 모든 내부 패스 스루 네트워크 부하 분산기의 백엔드 VM을 구성해야 합니다. 자세한 내용은 인스턴스 및 내부 패스 스루 네트워크 부하 분산기 다음 홉에 대한 일반적인 고려사항을 참고하세요.

  • 백엔드가 Google Kubernetes Engine(GKE) 노드인 내부 패스 스루 네트워크 부하 분산기는 정적 경로에 대해 다음 홉으로 사용할 수 없습니다. 해당 노드의 소프트웨어는 대상이 임의 대상이 아닌 클러스터에서 관리되는 IP 주소와 일치하는 경우에만 포드에 트래픽을 라우팅할 수 있습니다.

TCP, UDP, 기타 프로토콜 트래픽 처리

내부 패스 스루 네트워크 부하 분산기가 다음 홉으로 배포되면 Google Cloud는 다음 사항에 관계없이 모든 포트에서 모든 트래픽을 백엔드 VM으로 전달합니다.

  • 전달 규칙의 프로토콜 및 포트 구성
  • 백엔드 서비스의 프로토콜 구성

경로의 다음 홉인 내부 패스 스루 네트워크 부하 분산기는 Google Cloud VPC 네트워크(예: TCP, UDP, ICMP)에서 지원하는 프로토콜에 대한 모든 트래픽 전달을 원활하게 지원합니다.

추가 고려사항

  • 지원되는 전달 규칙. Google Cloud는 다음 홉 내부 패스 스루 네트워크 부하 분산기 전달 규칙만 지원합니다. Google Cloud는 다른 부하 분산기, 프로토콜 전달, Private Service Connect 엔드포인트에서 사용되는 다음 홉 전달 규칙을 지원하지 않습니다.

  • 사양 메서드 및 전달 규칙 네트워크 및 프로젝트. 다음 세 가지 방법 중 하나를 사용해서 다음 홉 전달 규칙을 지정할 수 있습니다. 사용하는 사양 메서드에 따라 전달 규칙의 네트워크가 경로의 네트워크와 일치해야 하는지 여부와 전달 규칙이 배치할 수 있는 프로젝트가 결정됩니다.

    다음 방법 중 하나를 선택하고 전달 규칙의 IP 버전이 만든 정적 경로의 IP 버전과 일치하는지 확인합니다.

    • 전달 규칙 이름(--next-hop-ilb) 및 리전(--next-hop-ilb-region): 이름 및 리전별로 다음 홉 전달 규칙을 지정할 때 전달 규칙의 네트워크는 경로의 VPC 네트워크와 일치해야 합니다. 전달 규칙은 전달 규칙의 네트워크가 포함된 동일한 프로젝트(독립형 프로젝트 또는 공유 VPC 호스트 프로젝트)에 있어야 합니다.

    • 전달 규칙 리소스 링크별: 전달 규칙의 리소스 링크는 /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME 형식을 사용합니다. PROJECT_ID는 전달 규칙을 포함하는 프로젝트의 프로젝트 ID, REGION은 전달 규칙의 리전, FORWARDING_RULE_NAME은 전달 규칙의 이름입니다. 해당 리소스 링크로 다음 홉 전달 규칙을 지정할 때는 전달 규칙의 네트워크가 경로의 VPC 네트워크와 일치해야 합니다. 전달 규칙은 전달 규칙의 네트워크가 포함된 프로젝트(독립형 프로젝트 또는 공유 VPC 호스트 프로젝트) 또는 공유 VPC 서비스 프로젝트 중 하나에 위치할 수 있습니다.

    • 전달 규칙 IP 주소 기준: IPv4 또는 IPv6(미리보기) 주소로 다음 홉 전달 규칙을 지정하는 경우 전달 규칙의 네트워크는 경로의 VPC 네트워크 또는 피어링된 VPC 네트워크 중 하나가 될 수 있습니다. 전달 규칙은 전달 규칙의 네트워크가 포함된 프로젝트(독립형 프로젝트 또는 공유 VPC 호스트 프로젝트) 또는 공유 VPC 서비스 프로젝트 중 하나에 위치할 수 있습니다.

  • 전역 액세스의 영향. 내부 패스 스루 네트워크 부하 분산기 다음 홉을 사용하는 커스텀 정적 경로는 모든 리전에서 프로그래밍됩니다. 다음 홉의 사용 가능 여부는 부하 분산기의 전역 액세스 설정에 따라 다릅니다. 전역 액세스를 사용 설정하면 VPC 네트워크의 모든 리전에서 부하 분산기 다음 홉에 액세스할 수 있습니다. 전역 액세스가 중지된 경우 부하 분산기와 동일한 리전에서만 부하 분산기 다음 홉에 액세스할 수 있습니다. 전역 액세스가 중지되면 다른 리전에서 내부 패스 스루 네트워크 부하 분산기 다음 홉을 사용하는 경로로 전송된 패킷이 삭제됩니다.

  • 모든 백엔드가 비정상일 경우. 내부 패스 스루 네트워크 부하 분산기의 모든 백엔드에서 상태 점검에 실패해도 이 부하 분산기 다음 홉을 사용하는 경로가 계속 적용됩니다. 경로를 통해 처리된 패킷은 트래픽 분산에 따라 다음 홉 부하 분산기의 백엔드 중 하나로 전송됩니다.

  • 공통 내부 IP 주소(--purpose=SHARED_LOADBALANCER_VIP)를 사용하는 전달 규칙은 지원되지 않음. 다음 홉 내부 패스 스루 네트워크 부하 분산기 및 공통 IP 주소를 사용하는 내부 패스 스루 네트워크 부하 분산기 전달 규칙은 상호 배타적인 기능입니다. 다음 홉 내부 패스 스루 네트워크 부하 분산기는 하나의 백엔드 서비스(하나의 부하 분산기)만 명확하게 참조되도록 부하 분산기의 전달 규칙에 고유한 IP 주소를 사용해야 합니다. 공통 내부 IP 주소를 사용하는 전달 규칙이 다양한 백엔드 서비스(다른 내부 패스 스루 네트워크 부하 분산기)를 참조할 수 있습니다.

  • 대상 및 우선순위가 동일하지만 다음 홉 내부 패스 스루 네트워크 부하 분산기가 다른 여러 경로. Google Cloud에서는 ECMP를 사용하여 2개 이상의 다음 홉 내부 패스 스루 네트워크 부하 분산기 간에 트래픽을 분산하지 않습니다. 대신 Google Cloud에서는 확정 내부 알고리즘을 사용하여 다음 홉 내부 패스 스루 네트워크 부하 분산기를 하나만 선택합니다. 이러한 모호함을 피하기 위해 각 경로에 고유한 네트워크 태그를 사용할 수 있습니다.

    내부 패스 스루 네트워크 부하 분산기 다음 홉이 다른 정적 경로의 우선순위와 대상이 동일할 경우 Google Cloud는 단일 다음 홉을 선택합니다.
  • 대상, 우선순위, 다음 홉 내부 패스 스루 네트워크 부하 분산기가 동일한 여러 경로 네트워크 태그를 사용하지 않으면 Google Cloud에서는 대상, 우선순위, 내부 패스 스루 네트워크 부하 분산기 다음 홉의 조합이 동일한 여러 정적 경로를 만들 수 없습니다. 네트워크 태그를 사용하면 대상, 우선순위, 내부 패스 스루 네트워크 부하 분산기 다음 홉의 조합이 동일한 여러 정적 경로를 만들 수 있습니다.

사용 사례

여러 개의 배포 및 토폴로지에서 내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 사용할 수 있습니다.

각 예시는 다음 가이드라인을 참조하세요.

  • 각 VM 인터페이스는 별도의 VPC 네트워크에 있어야 합니다.

  • 서브넷 경로를 재정의할 수 없으므로 백엔드 VM 또는 부하 분산기를 사용하여 동일한 VPC 네트워크의 서브넷 간 트래픽을 라우팅할 수 없습니다.

  • 내부 패스 스루 네트워크 부하 분산기는 소프트웨어 정의 패스 스루 부하 분산기입니다. 패킷은 소스 또는 대상 정보(주소 또는 주소 및 포트)에 대한 수정 없이 백엔드 VM으로 전달됩니다.

    라우팅, 패킷 필터링, 프록시, 주소 변환은 내부 패스 스루 네트워크 부하 분산기의 백엔드로 사용되는 가상 어플라이언스 VM에서 처리합니다.

내부 패스 스루 네트워크 부하 분산기를 NAT 게이트웨이에 대해 다음 홉으로 사용

이 사용 사례는 인터넷으로 트래픽을 라우팅하는 여러 NAT 게이트웨이 인스턴스로 내부 VM 트래픽의 부하를 분산합니다.

NAT 사용 사례
NAT 사용 사례(확대하려면 클릭)

허브 및 스포크: VPC 네트워크 피어링을 사용하여 다음 홉 경로 교환

서브넷 경로 교환 외에도 커스텀 정적 및 동적 경로를 내보내고 가져오도록 VPC 네트워크 피어링을 구성할 수 있습니다. 기본 인터넷 게이트웨이의 다음 홉을 갖는 정적 경로는 제외됩니다. 다음 홉 내부 패스 스루 네트워크 부하 분산기를 사용하는 커스텀 정적 경로는 포함됩니다.

다음을 수행하여 hub VPC 네트워크에 있는 다음 홉 방화벽 가상 어플라이언스를 사용하여 허브 및 스포크 토폴로지를 구성할 수 있습니다.

  • hub VPC 네트워크에서 백엔드로 방화벽 가상 어플라이언스를 사용하는 내부 패스 스루 네트워크 부하 분산기를 만듭니다.
  • hub VPC 네트워크에서 정적 경로를 만들고 다음 홉을 내부 패스 스루 네트워크 부하 분산기로 설정합니다.
  • VPC 네트워크 피어링을 사용하여 hub VPC 네트워크를 각 spoke VPC 네트워크에 연결합니다.
  • 각 피어링에 대해 해당 커스텀 경로를 내보내도록 hub 네트워크를 구성하고 커스텀 경로를 가져오도록 해당 spoke 네트워크를 구성합니다. 부하 분산기 다음 홉을 포함하는 경로는 hub 네트워크가 내보내는 경로 중 하나입니다.

hub VPC 네트워크의 다음 홉 방화벽 어플라이언스 부하 분산기는 라우팅 순서에 따라 스포크 네트워크에서 사용할 수 있습니다.

  • 전역 액세스가 사용 중지된 경우 부하 분산기와 동일한 리전의 클라이언트
  • 전역 액세스가 사용 설정된 경우 라우팅 순서에 따라 모든 리전의 클라이언트
허브 및 스포크
허브 및 스포크(확대하려면 클릭)

여러 NIC에 대한 부하 분산

다음 사용 사례에서 백엔드 VM은 여러 VPC 네트워크의 NIC가 포함된 가상 어플라이언스 인스턴스(예: 패킷 검사, 라우팅, 게이트웨이 VM)입니다. 이러한 가상 어플라이언스 인스턴스는 타사의 상용 솔루션 또는 직접 빌드하는 솔루션일 수 있습니다. 가상 어플라이언스는 여러 NIC가 포함된 Compute Engine VM입니다.

이 예시에서는 관리형 VM 인스턴스 그룹에 있는 백엔드 가상 어플라이언스의 단일 집합을 보여줍니다.

testing이라는 VPC 네트워크에서 내부 패스 스루 네트워크 부하 분산기에 fr-ilb1이라는 전달 규칙이 포함됩니다. 예시에서 이 부하 분산기는 nic0 인터페이스에 트래픽을 분산합니다.

production이라는 VPC 네트워크에서 다른 내부 패스 스루 네트워크 부하 분산기에는 fr-ilb2이라는 전달 규칙이 포함됩니다. 이 부하 분산기는 다른 인터페이스(이 예시에서는 nic1)에 트래픽을 분산합니다.

멀티 NIC 부하 분산이 포함된 트래픽
멀티 NIC 부하 분산이 포함된 트래픽(확대하려면 클릭)

자세한 구성 설정은 여러 백엔드 NIC로 부하 분산을 참조하세요.

대칭적 해싱

위 예시에서는 소스 네트워크 주소 변환(SNAT)이 사용되지 않습니다. Google Cloud에서 대칭적 해싱이 사용되기 때문에 SNAT가 필요하지 않습니다. 즉, 패킷이 동일 흐름에 속하는 경우 Google Cloud가 동일한 해시를 계산합니다. 다시 말해서, 소스 IP 주소:포트가 대상 IP 주소:포트로 바뀔 때 해시가 변경되지 않습니다.

참고:

  • 대칭적 해싱은 2021년 6월 22일부터 내부 패스 스루 네트워크 부하 분산기 전달 규칙을 만들 때 자동으로 사용 설정됩니다.

  • 기존 내부 패스 스루 네트워크 부하 분산기에서 대칭 해싱을 사용 설정하려면 대칭 해싱 사용 설정에 설명된 대로 전달 규칙과 다음 홉 경로를 다시 만들어야 합니다.

  • 대칭적 해싱은 내부 패스 스루 네트워크 부하 분산기에서만 지원됩니다.

  • 대칭적 해싱은 TCP 및 UDP 프로토콜에 대해 다음 세션 어피니티 유형에 지원됩니다.

    • 클라이언트 IP(CLIENT_IP)
    • 클라이언트 IP 및 프로토콜(CLIENT_IP_PROTO)
    • 클라이언트 IP, 프로토콜, 포트(CLIENT_IP_PORT_PROTO)

    이러한 설정에 관한 자세한 내용은 세션 어피니티 옵션을 참조하세요.

  • 특정한 이유로 사용 사례에 필요한 경우 선택적으로 SNAT를 사용할 수 있습니다.

다음 단계