타사 어플라이언스에 대한 내부 패스 스루 네트워크 부하 분산기 설정

Google Cloud에서는 가용성이 높은 수평 확장된 방식으로 타사 어플라이언스를 통합할 수 있습니다. 이렇게 하려면 커스텀 정적 경로를 구성하고 Google Cloud 내부 패스 스루 네트워크 부하 분산기를 경로 구성의 다음 홉으로 지정합니다. 이렇게 하면 부하 분산기가 대상 프리픽스의 트래픽을 상태 점검된 타사 VM 어플라이언스 풀로 부하 분산할 수 있습니다.

이 가이드에서는 예시를 사용해서 내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 구성하는 방법을 보여줍니다. 이 가이드를 진행하기 전에 다음 사항을 숙지하세요.

권한

이 가이드를 수행하려면 프로젝트에서 인스턴스를 만들고 네트워크를 수정해야합니다. 이렇게 하려면 프로젝트 소유자 또는 편집자이거나 다음 Compute Engine IAM 역할을 모두 보유해야 합니다.

작업 필요한 역할
네트워크, 서브넷, 부하 분산기 구성요소 만들기 네트워크 관리자
방화벽 규칙 추가 및 삭제 보안 관리자
인스턴스 만들기 Compute 인스턴스 관리자

자세한 내용은 다음 가이드를 참조하세요.

내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 사용해서 일반적인 백엔드 구성

이 가이드에서는 수평 확장된 가상 어플라이언스를 통합하기 위해 내부 패스 스루 네트워크 부하 분산기를 커스텀 정적 경로의 다음 홉으로 사용하는 방법을 설명합니다.

이 가이드에서 설명하는 솔루션은 Debian Linux를 실행하는 어플라이언스 VM을 만듭니다. 예시 VM은 패킷 필터링을 수행하지 않지만, 이 예시의 네트워크 구성을 수정하거나 다른 패킷 필터링 또는 라우팅 소프트웨어를 사용하여 이 기능을 추가할 수 있습니다.

이 섹션의 단계에서는 다음 리소스를 구성하는 방법을 설명합니다.

  • 샘플 VPC 네트워크 및 커스텀 서브넷
  • 백엔드 어플라이언스 가상 머신(VM)에 대한 수신 연결을 허용하는 Google Cloud 방화벽 규칙
  • 커스텀 정적 경로
  • 연결 테스트를 위한 2개의 클라이언트 VM
  • 다음 내부 패스 스루 네트워크 부하 분산기 구성요소:
    • 관리형 인스턴스 그룹(MIG)의 백엔드 VM
    • 백엔드 VM의 상태 점검
    • 백엔드 VM 간의 연결 분산을 관리하기 위한 us-west1 리전의 내부 백엔드 서비스
    • 부하 분산기의 프런트엔드에 대한 내부 전달 규칙 및 내부 IP 주소

이 예시에서는 여러 NIC로 부하 분산에 설명된 대로 여러 백엔드 NIC로 부하 분산을 보여줍니다.

토폴로지는 다음과 같습니다.

내부 패스 스루 네트워크 부하 분산기의 다음 홉 멀티 NIC 상세 예시
내부 패스 스루 네트워크 부하 분산기의 다음 홉 멀티 NIC 상세 예시(확대하려면 클릭)

다이어그램은 예시에서 만드는 몇 가지 리소스를 보여줍니다.

  • 내부 패스 스루 네트워크 부하 분산기 뒤의 애플리케이션 인스턴스(이 예시에서는 fr-ilb1). 애플리케이션 인스턴스에는 내부 IP 주소만 있습니다.
  • 각 애플리케이션 인스턴스에는 can-ip-forward 플래그가 사용 설정되어 있습니다. 이 플래그가 없으면 Compute Engine VM에서는 패킷의 소스 IP 주소가 VM의 내부 IP 주소, 별칭 IP 범위의 IP 주소 또는 VM으로 확인되는 전달 규칙의 IP 주소와 일치하는 경우에만 패킷을 전송할 수 있습니다. VM이 모든 소스 IP 주소로 패킷을 전송할 수 있도록 can-ip-forward 플래그가 이 동작을 변경합니다.
  • 대상 10.50.1.0/24 및 다음 홉이 부하 분산기의 전달 규칙 fr-ilb1로 설정된 커스텀 정적 경로

다이어그램은 트래픽 흐름도 보여줍니다.

  • testing VPC 네트워크에는 10.50.1.0/24 서브넷으로 향하는 트래픽에 대한 커스텀 정적 경로가 지정되어 있습니다. 이 경로는 부하 분산기로 트래픽을 전달합니다.
  • 부하 분산기는 구성된 세션 어피니티에 따라 애플리케이션 인스턴스 중 하나로 트래픽을 전달합니다. 세션 어피니티는 TCP 트래픽에만 영향을 줍니다.

추가 사용 사례는 다음 홉으로 사용되는 내부 TCP/UDP 부하 분산기를 참조하세요.

네트워크, 리전, 서브넷 구성

이 예시에서는 다음 VPC 네트워크, 리전, 서브넷을 사용합니다.

  • 네트워크: 이 예시에서는 각각 하나 이상의 서브넷이 있는 두 개의 네트워크가 필요합니다. 각 백엔드 타사 어플라이언스 VM에는 각 VPC 네트워크에 하나씩 둘 이상의 네트워크 인터페이스가 있어야 합니다. 이 예시의 네트워크는 이름이 testing 및 production인 커스텀 모드 VPC 네트워크입니다. 이 예시의 testing 네트워크에는 클라이언트와 부하 분산기가 포함됩니다. production 네트워크에는 대상 VM이 포함됩니다.

  • 리전: 서브넷은 us-west1 리전에 있습니다. VM 인스턴스는 영역 리소스이므로 서브넷은 동일한 리전에 있어야 합니다.

  • 서브넷: testing-subnet 및 production-subnet 서브넷은 각각 10.30.1.0/24 및 10.50.1.0/24 기본 IP 주소 범위를 사용합니다.

예시 네트워크 및 서브넷을 만들려면 다음 단계를 따르세요.

콘솔

다음과 같이 testing 네트워크와 testing-subnet을 만듭니다.

  1. Google Cloud 콘솔에서 VPC 네트워크 페이지로 이동합니다.

    VPC 네트워크로 이동

  2. VPC 네트워크 만들기를 클릭합니다.

  3. testing의 이름을 입력합니다.

  4. 서브넷 섹션에서 다음을 수행합니다.

    • 서브넷 생성 모드를 커스텀으로 설정합니다.
    • 새 서브넷 섹션에 다음 정보를 입력합니다.
      • 이름: testing-subnet
      • 리전: us-west1
      • IP 주소 범위: 10.30.1.0/24
      • 완료를 클릭합니다.

  5. 만들기를 클릭합니다.

다음과 같이 production 네트워크와 production-subnet을 만듭니다.

  1. Google Cloud 콘솔에서 VPC 네트워크 페이지로 이동합니다.

    VPC 네트워크로 이동

  2. VPC 네트워크 만들기를 클릭합니다.

  3. production의 이름을 입력합니다.

  4. 서브넷 섹션에서 다음을 수행합니다.

    • 서브넷 생성 모드를 커스텀으로 설정합니다.
    • 새 서브넷 섹션에 다음 정보를 입력합니다.
      • 이름: production-subnet
      • 리전: us-west1
      • IP 주소 범위: 10.50.1.0/24
      • 완료를 클릭합니다.

  5. 만들기를 클릭합니다.

gcloud

  1. 커스텀 VPC 네트워크를 만듭니다.

    gcloud compute networks create testing --subnet-mode=custom

    gcloud compute networks create production --subnet-mode=custom

  2. us-west1 리전의 testing 및 production 네트워크에 서브넷을 만듭니다.

    gcloud compute networks subnets create testing-subnet \
    --network=testing \
    --range=10.30.1.0/24 \
    --region=us-west1

    gcloud compute networks subnets create production-subnet \
    --network=production \
    --range=10.50.1.0/24 \
    --region=us-west1

방화벽 규칙 구성

이 예시에서는 다음과 같은 방화벽 규칙을 사용합니다.

  • fw-allow-testing-from-both: testing 네트워크의 모든 대상에 적용 가능한 인그레스 규칙. 이 규칙은 10.30.1.0/24 및 10.50.1.0/24 IP 주소 범위 모두에 있는 소스의 트래픽을 허용합니다. 이러한 두 범위는 두 네트워크 모두에 있는 VM의 기본 내부 IP 주소를 포함합니다.

  • fw-allow-production-from-both: production 네트워크의 모든 대상에 적용 가능한 인그레스 규칙. 이 규칙은 10.30.1.0/24 및 10.50.1.0/24 IP 주소 범위 모두에 있는 소스의 트래픽을 허용합니다. 이러한 두 범위는 두 네트워크 모두에 있는 VM의 기본 내부 IP 주소를 포함합니다.

  • fw-allow-testing-ssh: testing VPC 네트워크에서 VM 인스턴스에 적용되는 인그레스 규칙입니다. 이 규칙은 TCP 포트 22를 사용하여 모든 주소로부터 수신되는 SSH 연결을 허용합니다. 이 규칙에 더 제한적인 소스 IP 범위를 선택할 수 있습니다. 예를 들어 SSH 세션을 시작하려는 시스템의 IP 범위를 지정할 수 있습니다. 이 예시에서는 allow-ssh 대상 태그를 사용하여 방화벽 규칙이 적용되는 VM을 식별합니다.

  • fw-allow-production-ssh: production VPC 네트워크에서 VM 인스턴스에 적용되는 인그레스 규칙입니다. 이 규칙은 TCP 포트 22를 사용하여 모든 주소로부터 수신되는 SSH 연결을 허용합니다. fw-allow-testing-ssh 규칙과 같이 이 규칙에 더 제한적인 소스 IP 범위를 선택할 수 있습니다.

  • fw-allow-health-check: 부하 분산되는 타사 어플라이언스 VM의 인그레스 규칙입니다. 이 규칙은 Google Cloud 상태 점검 시스템(130.211.0.0/22 및 35.191.0.0/16)의 트래픽을 허용합니다. 이 예시에서는 allow-health-check 대상 태그를 사용하여 적용해야 할 인스턴스를 식별합니다.

  • fw-allow-production-health-check: 부하 분산되는 타사 어플라이언스 VM의 인그레스 규칙입니다. 이 규칙은 Google Cloud 상태 점검 시스템(130.211.0.0/22 및 35.191.0.0/16)의 트래픽을 허용합니다. 이 예시에서는 allow-health-check 대상 태그를 사용하여 적용해야 할 인스턴스를 식별합니다.

이러한 방화벽 규칙이 없으면 기본 거부 인그레스 규칙은 백엔드 인스턴스로 들어오는 트래픽을 차단합니다. Google Cloud 프로브 시스템의 IP 범위에서 상태 점검을 허용하려면 방화벽 규칙을 만들어야 합니다. 자세한 내용은 프로브 IP 범위를 참조하세요.

콘솔

  1. Google Cloud 콘솔에서 방화벽 정책 페이지로 이동합니다.

    방화벽 정책으로 이동

  2. 방화벽 규칙 만들기를 클릭하고 다음 정보를 입력하여 테스트 VM이 테스트 및 프로덕션 서브넷에서 패킷을 수신하도록 허용하는 규칙을 만듭니다.

    • 이름: fw-allow-testing-from-both
    • 네트워크: testing
    • 우선순위: 1000
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 네트워크의 모든 인스턴스
    • 소스 필터: IPv4 범위
    • 소스 IPv4 범위: 10.30.1.0/24, 10.50.1.0/24
    • 프로토콜 및 포트: 모두 허용

  3. 만들기를 클릭합니다.

  4. 방화벽 규칙 만들기를 클릭하고 다음 정보를 입력하여 프로덕션 VM이 테스트 및 프로덕션 서브넷에서 패킷을 수신하도록 허용하는 규칙을 만듭니다.

    • 이름: fw-allow-production-from-both
    • 네트워크: production
    • 우선순위: 1000
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 네트워크의 모든 인스턴스
    • 소스 필터: IPv4 범위
    • 소스 IPv4 범위: 10.30.1.0/24, 10.50.1.0/24
    • 프로토콜 및 포트: 모두 허용

  5. 만들기를 클릭합니다.

  6. 방화벽 규칙 만들기를 클릭하여 테스트 환경에서 수신되는 SSH 연결을 허용하는 규칙을 만듭니다.

    • 이름: fw-allow-testing-ssh
    • 네트워크: testing
    • 우선순위: 1000
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 지정된 대상 태그
    • 대상 태그: allow-ssh
    • 소스 필터: IPv4 범위
    • 소스 IPv4 범위: 0.0.0.0/0
    • 프로토콜 및 포트: 지정된 프로토콜 및 포트를 선택하고 tcp:22를 입력합니다.

  7. 만들기를 클릭합니다.

  8. 방화벽 규칙 만들기를 클릭하여 프로덕션 환경에서 수신되는 SSH 연결을 허용하는 규칙을 만듭니다.

    • 이름: fw-allow-production-ssh
    • 네트워크: production
    • 우선순위: 1000
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 지정된 대상 태그
    • 대상 태그: allow-ssh
    • 소스 필터: IPv4 범위
    • 소스 IPv4 범위: 0.0.0.0/0
    • 프로토콜 및 포트: 지정된 프로토콜 및 포트를 선택하고 tcp:22를 입력합니다.

  9. 만들기를 클릭합니다.

  10. 방화벽 규칙 만들기를 클릭하여 테스트 환경에서 Google Cloud 상태 점검을 허용하는 규칙을 만듭니다.

    • 이름: fw-allow-health-check
    • 네트워크: testing
    • 우선순위: 1000
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 지정된 대상 태그
    • 대상 태그: allow-health-check
    • 소스 필터: IPv4 범위
    • 소스 IPv4 범위: 130.211.0.0/22 및 35.191.0.0/16
    • 프로토콜 및 포트: tcp

  11. 만들기를 클릭합니다.

  12. 방화벽 규칙 만들기를 클릭하여 프로덕션 환경에서 Google Cloud 상태 점검을 허용하는 규칙을 만듭니다.

    • 이름: fw-allow-production-health-check
    • 네트워크: production
    • 우선순위: 1000
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 지정된 대상 태그
    • 대상 태그: allow-health-check
    • 소스 필터: IPv4 범위
    • 소스 IPv4 범위: 130.211.0.0/22 및 35.191.0.0/16
    • 프로토콜 및 포트: tcp

  13. 만들기를 클릭합니다.

gcloud

  1. 테스트 VM이 testing 및 production 서브넷에서 패킷을 수신하도록 허용하는 fw-allow-testing-subnet 방화벽 규칙을 만듭니다.

    gcloud compute firewall-rules create fw-allow-testing-from-both \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24,10.50.1.0/24 \
    --rules=all

  2. 프로덕션 VM이 testing 및 production 서브넷에서 패킷을 수신하도록 허용하는 fw-allow-production-subnet 방화벽 규칙을 만듭니다.

    gcloud compute firewall-rules create fw-allow-production-from-both \
    --network=production \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24,10.50.1.0/24 \
    --rules=all

  3. allow-ssh 네트워크 태그를 사용해 VM으로 가는 SSH 연결을 허용하는 fw-allow-testing-ssh 방화벽 규칙을 만듭니다. source-ranges를 생략하면 Google Cloud는 모든 소스를 의미하는 것으로 규칙을 해석합니다.

    gcloud compute firewall-rules create fw-allow-testing-ssh \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  4. allow-ssh 네트워크 태그를 사용해 VM으로 가는 SSH 연결을 허용하는 fw-allow-production-ssh 방화벽 규칙을 만듭니다.

    gcloud compute firewall-rules create fw-allow-production-ssh \
    --network=production \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  5. fw-allow-health-check 규칙을 만들어 testing 네트워크의 타사 어플라이언스 VM에 Google Cloud 상태 점검을 허용합니다.

    gcloud compute firewall-rules create fw-allow-testing-health-check \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp

  6. fw-allow-production-health-check 방화벽 규칙을 만들어 production 네트워크의 타사 어플라이언스 VM에 Google Cloud 상태 점검을 허용합니다.

    gcloud compute firewall-rules create fw-allow-production-health-check \
    --network=production \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp

타사 가상 어플라이언스 만들기

다음 단계에서는 네트워크 인터페이스가 2개 이상인 관리형 리전 인스턴스 그룹과 인스턴스 템플릿을 만드는 방법을 설명합니다. 이 인스턴스 그룹은 이 예시에서 타사 가상 어플라이언스로 사용됩니다.

콘솔

네트워크 인스턴스가 한 개를 초과하는 인스턴스 템플릿을 만들어야 하므로 이 단계에서 gcloud를 사용해야 합니다. 현재 Google Cloud 콘솔에서는 네트워크 인터페이스가 한 개를 초과하는 인스턴스 템플릿을 만들 수 없습니다.

gcloud

  1. config.sh라는 로컬 파일을 만들고 다음 콘텐츠를 삽입합니다.

    #!/bin/bash
# Enable IP forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf
# Read VM network configuration:
md_vm="http://metadata.google.internal/computeMetadata/v1/instance/"
md_net="$md_vm/network-interfaces"
nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google" )"
nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")"
nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")"
nic0_id="$(ip addr show | grep $nic0_addr | awk '{print $NF}')"
nic1_gw="$(curl $md_net/1/gateway -H "Metadata-Flavor:Google")"
nic1_mask="$(curl $md_net/1/subnetmask -H "Metadata-Flavor:Google")"
nic1_addr="$(curl $md_net/1/ip -H "Metadata-Flavor:Google")"
nic1_id="$(ip addr show | grep $nic1_addr | awk '{print $NF}')"
# Source based policy routing for nic1
echo "100 rt-nic1" >> /etc/iproute2/rt_tables
sudo ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1
sleep 1
sudo ip route add 35.191.0.0/16 via $nic1_gw dev $nic1_id table rt-nic1
sudo ip route add 130.211.0.0/22 via $nic1_gw dev $nic1_id table rt-nic1
# Use a web server to pass the health check for this example.
# You should use a more complete test in production.
sudo apt-get update
sudo apt-get install apache2 -y
sudo a2ensite default-ssl
sudo a2enmod ssl
echo "Example web page to pass health check" | \
tee /var/www/html/index.html
sudo systemctl restart apache2

  2. 타사 가상 어플라이언스의 인스턴스 템플릿을 만듭니다. 템플릿에서 생성된 VM 인스턴스가 testing 및 production 네트워크의 다른 인스턴스에서 패킷을 전달할 수 있도록 인스턴스 템플릿에는 --can-ip-forward 플래그가 포함되어 있어야 합니다.

    gcloud compute instance-templates create third-party-template-multinic \
    --region=us-west1 \
    --network-interface subnet=testing-subnet,address="" \
    --network-interface subnet=production-subnet \
    --tags=allow-ssh,allow-health-check,my-network-tag \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --can-ip-forward \
    --metadata=startup-script="$(< config.sh)"

  3. 타사 가상 어플라이언스의 관리형 인스턴스 그룹을 만듭니다. 다음 명령어는 us-west1에서 리전 관리형 인스턴스 그룹을 만들고 자동 확장할 수 있습니다.

    gcloud compute instance-groups managed create third-party-instance-group \
    --region=us-west1 \
    --template=third-party-template-multinic \
    --size=3

부하 분산 리소스 만들기

이러한 단계를 통해 상태 점검 및 백엔드 서비스부터 프런트엔드 구성에 이르기까지 모든 내부 패스 스루 네트워크 부하 분산기 구성요소를 구성합니다.

  • 상태 점검: 이 예시에서 HTTP 상태 점검은 HTTP 200(OK) 응답을 확인합니다. 자세한 내용은 내부 패스 스루 네트워크 부하 분산기 개요의 상태 점검 섹션을 참조하세요.

  • 백엔드 서비스: 이 예시의 백엔드 서비스는 TCP 프로토콜을 지정하더라도 부하 분산기가 경로의 다음 홉인 경우 Google Cloud는 모든 프로토콜(TCP, UDP, ICMP)에 대해 트래픽을 전달합니다.

  • 전달 규칙: 이 예시의 전달 규칙이 TCP 포트 80을 지정하더라도 부하 분산기가 경로의 다음 홉인 경우에는 TCP 또는 UDP 포트의 트래픽이 부하 분산기의 백엔드로 전송됩니다.

  • 내부 IP 주소: 이 예시에서는 전달 규칙에 내부 IP 주소인 10.30.1.99를 지정합니다.

콘솔

구성 시작

  1. Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.

    부하 분산으로 이동

  2. 부하 분산기 만들기를 클릭합니다.
  3. 부하 분산기 유형에 네트워크 부하 분산기(TCP/UDP/SSL)를 선택하고 다음을 클릭합니다.
  4. 프록시 또는 패스 스루에서 패스 스루 부하 분산기를 선택하고 다음을 클릭합니다.
  5. 공개 또는 내부에서 내부를 선택하고 다음을 클릭합니다.
  6. 구성을 클릭합니다.

첫 번째 부하 분산기 만들기

  1. 이름을 ilb1로 설정합니다.
  2. 리전을 us-west1로 설정합니다.
  3. 네트워크를 testing로 설정합니다.
  4. 백엔드 구성을 클릭하고 다음과 같이 변경합니다.
    1. 백엔드의 새 항목 섹션에서 third-party-instance-group 인스턴스 그룹을 선택하고 완료를 클릭합니다.
    2. 상태 점검에서 다른 상태 점검 생성을 선택하고 다음 정보를 입력한 다음 저장 후 계속을 클릭합니다.
      • 이름: hc-http-80
      • 프로토콜: HTTP
      • 포트: 80
      • 프록시 프로토콜: NONE
      • 요청 경로: / Google Cloud 콘솔을 사용하여 부하 분산기를 만들면 상태 확인이 전역으로 수행됩니다. 리전 상태 점검을 만들려면 gcloud 또는 API를 사용합니다.
    3. 세션 어피니티에서 클라이언트 IP를 선택합니다.
    4. 계속하기 전에 백엔드 구성 옆에 파란색 체크표시가 있는지 확인합니다. 그렇지 않은 경우 이 단계를 검토합니다.
  5. 프런트엔드 구성을 클릭합니다. 새 프런트엔드 IP 및 포트 섹션에서 다음과 같이 변경합니다.
    1. 이름: fr-ilb1
    2. 서브네트워크: testing-subnet
    3. 내부 IP에서 고정 내부 IP 주소 예약을 선택하고 다음 정보를 입력한 다음 예약을 클릭합니다.
      • 이름: ip-ilb
      • 고정 IP 주소: 직접 선택
      • 커스텀 IP 주소: 10.30.1.99
    4. 포트: 단일을 선택하고 포트 번호에 80을 입력합니다. 부하 분산기에 선택한 프로토콜 및 포트는 부하 분산기가 경로의 다음 홉일 때 사용되는 프로토콜 및 포트를 제한하지 않습니다.
    5. 계속하기 전에 프런트엔드 구성 옆에 파란색 체크표시가 있는지 확인합니다. 그렇지 않은 경우 이 단계를 검토합니다.
  6. 검토 및 완료를 클릭합니다. 설정한 내용을 다시 한 번 확인합니다.
  7. 만들기를 클릭합니다.

구성 시작

  1. Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.

    부하 분산으로 이동

  2. 부하 분산기 만들기를 클릭합니다.
  3. 부하 분산기 유형에 네트워크 부하 분산기(TCP/UDP/SSL)를 선택하고 다음을 클릭합니다.
  4. 프록시 또는 패스 스루에서 패스 스루 부하 분산기를 선택하고 다음을 클릭합니다.
  5. 공개 또는 내부에서 내부를 선택하고 다음을 클릭합니다.
  6. 구성을 클릭합니다.

두 번째 부하 분산기 만들기

  1. 이름을 ilb2로 설정합니다.
  2. 리전을 us-west1로 설정합니다.
  3. 네트워크를 production로 설정합니다.
  4. 백엔드 구성을 클릭하고 다음과 같이 변경합니다.
    1. 백엔드의 새 항목 섹션에서 third-party-instance-group 인스턴스 그룹을 선택하고 완료를 클릭합니다.
    2. 상태 점검에서 hc-http-80를 선택합니다.
    3. 세션 어피니티에서 클라이언트 IP를 선택합니다.
    4. 계속하기 전에 백엔드 구성 옆에 파란색 체크표시가 있는지 확인합니다. 그렇지 않은 경우 이 단계를 검토합니다.
  5. 프런트엔드 구성을 클릭합니다. 새 프런트엔드 IP 및 포트 섹션에서 다음과 같이 변경합니다.
    1. 이름: fr-ilb2
    2. 서브네트워크: production-subnet
    3. 내부 IP에서 고정 내부 IP 주소 예약을 선택하고 다음 정보를 입력한 다음 예약을 클릭합니다.
      • 이름: ip-ilb2
      • 고정 IP 주소: 직접 선택
      • 커스텀 IP 주소: 10.50.1.99
    4. 포트: 단일을 선택하고 포트 번호에 80을 입력합니다. 부하 분산기에 선택한 프로토콜 및 포트는 부하 분산기가 경로의 다음 홉일 때 사용되는 프로토콜 및 포트를 제한하지 않습니다.
    5. 계속하기 전에 프런트엔드 구성 옆에 파란색 체크표시가 있는지 확인합니다. 그렇지 않은 경우 이 단계를 검토합니다.
  6. 검토 및 완료를 클릭합니다. 설정한 내용을 다시 한 번 확인합니다.

  7. 만들기를 클릭합니다.

  8. production VPC 네트워크의 부하 분산기 리소스를 구성합니다.

gcloud

  1. 새 HTTP 상태 점검을 만들어 80에서 VM에 대한 TCP 연결을 테스트합니다.

    gcloud compute health-checks create http hc-http-80 \
    --region=us-west1 \
    --port=80

  2. us-west1 리전에서 2개의 내부 백엔드 서비스를 만듭니다.

    gcloud compute backend-services create ilb1 \
    --load-balancing-scheme=internal \
    --health-checks-region=us-west1 \
    --health-checks=hc-http-80 \
    --region=us-west1 \
    --network=testing \
    --session-affinity=CLIENT_IP

    gcloud compute backend-services create ilb2 \
    --load-balancing-scheme=internal \
    --health-checks-region=us-west1 \
    --health-checks=hc-http-80 \
    --region=us-west1 \
    --network=production \
    --session-affinity=CLIENT_IP

  3. 타사 가상 어플라이언스가 포함된 인스턴스 그룹을 백엔드 서비스의 백엔드로 추가합니다.

    gcloud compute backend-services add-backend ilb1 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

    gcloud compute backend-services add-backend ilb2 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

  4. 내부 전달 규칙을 만들고 이를 백엔드 서비스에 연결하여 부하 분산기 구성을 완료합니다. 부하 분산기의 프로토콜(TCP) 및 포트(80)는 부하 분산기가 경로의 다음 홉으로 사용될 때 백엔드 인스턴스(타사 가상 어플라이언스)에 전달되는 포트 및 프로토콜을 제한하지 않습니다.

    gcloud compute forwarding-rules create fr-ilb1 \
    --load-balancing-scheme=internal \
    --ports=80 \
    --network=testing \
    --subnet=testing-subnet \
    --region=us-west1 \
    --backend-service=ilb1 \
    --address=10.30.1.99

    gcloud compute forwarding-rules create fr-ilb2 \
    --load-balancing-scheme=internal \
    --ports=80 \
    --network=production \
    --subnet=production-subnet \
    --region=us-west1 \
    --backend-service=ilb2 \
    --address=10.50.1.99

부하 분산기를 다음 홉으로 정의하는 정적 경로 만들기

next-hop-ilb로 표시된 2개의 커스텀 정적 경로를 만듭니다.

콘솔

첫 번째 경로 만들기

  1. Google Cloud 콘솔에서 경로 페이지로 이동합니다.

    경로로 이동

  2. 경로 만들기를 클릭합니다.

  3. 경로 이름에 ilb-nhop-dest-10-50-1을 입력합니다.

  4. testing 네트워크를 선택합니다.

  5. 대상 IP 범위에 10.50.1.0/24를 입력합니다.

  6. 인스턴스 태그에 my-network-tag를 입력합니다.

  7. 경로의 다음 홉에 대해 내부 TCP/UDP 부하 분산기의 전달 규칙 지정을 선택합니다.

    부하 분산기의 IP 주소를 다음 홉으로 지정하려면 gcloud CLI 또는 API를 사용합니다.

  8. 전달 규칙 이름을 지정합니다. 전달 규칙 이름으로 fr-ilb1을 선택합니다.

  9. 만들기를 클릭합니다.

두 번째 경로 만들기

  1. 경로 만들기를 클릭합니다.
  2. 경로 이름에 ilb-nhop-dest-10-30-1을 입력합니다.
  3. testing 네트워크를 선택합니다.
  4. 대상 IP 범위에 10.30.1.0/24를 입력합니다.

  5. 경로의 다음 홉에 대해 내부 TCP/UDP 부하 분산기의 전달 규칙 지정을 선택합니다.

    부하 분산기의 IP 주소를 다음 홉으로 지정하려면 gcloud CLI 또는 API를 사용합니다.

  6. 전달 규칙 이름으로 fr-ilb2을 선택합니다.

  7. 만들기를 클릭합니다.

gcloud

각 부하 분산기의 전달 규칙에 설정된 다음 홉으로 고급 경로를 만들고 그에 따라 각 대상 범위를 설정합니다.

--next-hop-ilb 플래그의 경우 전달 규칙 이름 또는 IP 주소를 지정할 수 있습니다. IP 주소를 지정하면 커스텀 경로를 내보낼 필요 없이 피어 간에 이 IP 주소가 학습될 수 있습니다. 이 예시에서 첫 번째 경로는 IP 주소 10.30.1.99를 사용하고 두 번째 경로는 전달 규칙 이름 fr-ilb12를 사용합니다.

원하는 경우 경로의 인스턴스 태그를 하나 이상 지정할 수 있습니다. 경로에 네트워크 태그를 지정하면 경로가 특정 VM에 적용될 수 있습니다. 네트워크 태그를 지정하지 않으면 VPC 네트워크의 모든 VM에 경로가 적용됩니다. 이 예시에서는 경로의 네트워크 태그로 my-network-tag가 경로에 사용됩니다.

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=10.30.1.99 \
    --tags=my-network-tag

gcloud compute routes create ilb-nhop-dest-10-30-1 \
    --network=production \
    --destination-range=10.30.1.0/24 \
    --next-hop-ilb=fr-ilb2 \
    --next-hop-ilb-region=us-west1

testing VM 인스턴스 만들기

이 예시에서는 testing VPC 네트워크의 testing-subnet(10.30.1.0/24)에 IP 주소가 10.30.1.100인 VM 인스턴스를 만듭니다.

gcloud

  1. 다음 명령어를 실행하여 testing-vm을 만듭니다.

    gcloud compute instances create testing-vm \
    --zone=us-west1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --tags=allow-ssh,my-network-tag \
    --subnet=testing-subnet \
    --private-network-ip 10.30.1.100 \
    --metadata=startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://metadata.google.internal/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2'

production VM 인스턴스 만들기

이 예시에서는 production VPC 네트워크의 production-subnet(10.50.1.0/24)에 IP 주소가 10.50.1.100인 VM 인스턴스를 만듭니다.

gcloud

production-vm은 부하 분산기와 동일한 리전의 어떤 영역에든 위치할 수 있으며 그 리전의 어떤 서브넷이든 사용할 수 있습니다. 이 예시에서 production-vm은 us-west1-a 영역에 있습니다.

  1. 다음 명령어를 실행하여 production-vm을 만듭니다.

    gcloud compute instances create production-vm \
    --zone=us-west1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=production-subnet \
    --private-network-ip 10.50.1.100 \
    --metadata=startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://metadata.google.internal/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2'

다중 NIC 배포로 부하 분산 테스트

  1. 부하 분산기 백엔드의 상태를 확인합니다.

    gcloud compute backend-services get-health ilb1 --region us-west1

    gcloud compute backend-services get-health ilb2 --region us-west1

  2. testing VM에서 연결을 테스트합니다.

    gcloud compute ssh testing-vm --zone=us-west1-a

    curl http://10.50.1.99

    exit

  3. production VM에서 연결을 테스트합니다.

    gcloud compute ssh production-vm --zone=us-west1-a

    curl http://10.30.1.99

    exit

대칭 해싱 사용 설정

백엔드 인스턴스에 매핑된 해시를 계산할 때 Google Cloud는 IP 주소 및 포트의 방향을 무시합니다. TCP/UDP 패킷의 계산된 일관된 해시 값은 패킷이 시작된 방향에 관계없이 동일합니다. 이것을 대칭적 해싱이라고 합니다.

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

자세한 내용은 대칭적 해싱을 참조하세요.

전달 규칙 삭제 및 다시 만들기

콘솔

전달 규칙 삭제 및 새 규칙 만들기

  1. Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.

    부하 분산으로 이동

  2. be-ilb 부하 분산기를 클릭하고 수정을 클릭합니다.

  3. 프런트엔드 구성을 클릭합니다.

  4. 전달 규칙 위로 포인터를 가져간 후 삭제를 눌러 삭제합니다.

  5. 프런트엔드 IP 및 포트 추가를 클릭합니다.

  6. 새 프런트엔드 IP 및 포트 섹션에서 다음과 같이 변경합니다.

    1. 이름: FORWARDING_RULE_NAME
    2. 서브네트워크: SUBNET_NAME
    3. 내부 IP에서 IP_ADDRESS를 선택합니다.
    4. 포트: PORT_NUMBER 또는 ALL
    5. 완료를 클릭합니다.
    6. 계속하기 전에 프런트엔드 구성 옆에 파란색 체크표시가 있는지 확인합니다. 그렇지 않은 경우 이 단계를 검토합니다.

  7. 검토 및 완료를 클릭합니다. 설정한 내용을 다시 한 번 확인합니다.

  8. 만들기를 클릭합니다.

gcloud

  1. 기존 전달 규칙을 삭제합니다.

    gcloud compute forwarding-rules delete FORWARDING_RULE_NAME \
    --region=REGION

  2. 동일한 이름을 사용하여 대체 전달 규칙을 만듭니다.

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --load-balancing-scheme=internal \
    --ports=PORT_NUMBER or `ALL` \
    --network=NETWORK_NAME \
    --subnet=SUBNET_NAME \
    --region=REGION \
    --backend-service=BACKEND_SERVICE_NAME \
    --address=IP_ADDRESS

SNAT가 필요하지 않은 경우

이전 예시에 설명된 것처럼 다음 조건이 모두 해당하는 경우에는 소스 네트워크 주소 변환(SNAT)이 필요하지 않습니다.

  • 내부 패스 스루 네트워크 부하 분산기에 대한 전달 규칙은 2021년 6월 22일 이후에 생성되었습니다.
  • 전달 규칙을 참조하는 커스텀 정적 경로가 2021년 6월 22일 또는 그 이후에 생성되었습니다.
  • 내부 패스 스루 네트워크 부하 분산기의 백엔드 서비스에는 NONE 세션 어피니티 설정이 사용되지 않습니다.

다음 단계에 따라 대칭적 해싱을 사용하도록 기존 다음 홉 내부 패스 스루 네트워크 부하 분산기 경로를 전환할 수 있습니다.

  • 내부 패스 스루 네트워크 부하 분산기의 백엔드 서비스에 NONE 세션 어피니티 설정이 사용되지 않는지 확인합니다.

  • 동일한 백엔드 서비스를 참조하는 대체 전달 규칙을 만듭니다. 대체 전달 규칙에는 다른 IP 주소가 사용됩니다.

  • 새 전달 규칙을 참조하는 대체 커스텀 정적 경로를 만듭니다. 이 대체 경로가 기존 경로보다 높은 우선순위를 갖는지 확인합니다.

  • 우선순위가 낮은 기존 경로(이전 전달 규칙 참조)를 삭제한 다음 이전 전달 규칙을 삭제합니다.

삭제

  1. 부하 분산기 구성에서 백엔드 서비스의 백엔드를 삭제합니다.

    gcloud compute backend-services remove-backend ilb1 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

    gcloud compute backend-services remove-backend ilb2 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

  2. 경로를 삭제합니다.

    gcloud compute routes delete ilb-nhop-dest-10-50-1

    gcloud compute routes delete ilb-nhop-dest-10-30-1

  3. 부하 분산기 구성에서 전달 규칙을 삭제합니다.

    gcloud compute forwarding-rules delete fr-ilb1 \
    --region=us-west1

    gcloud compute forwarding-rules delete fr-ilb2 \
    --region=us-west1

  4. 부하 분산기 구성에서 백엔드 서비스를 삭제합니다.

    gcloud compute backend-services delete ilb1 \
    --region=us-west1

    gcloud compute backend-services delete ilb2 \
    --region=us-west1

  5. 부하 분산기 구성에서 상태 확인을 삭제합니다.

    gcloud compute health-checks delete hc-http-80 \
    --region=us-west1

    Google Cloud 콘솔을 사용한 경우 상태 확인은 전역입니다. 따라서 명령어는 다음과 같습니다.

    gcloud compute health-checks delete hc-http-80 \
     --global

  6. 관리형 인스턴스 그룹을 삭제합니다.

    gcloud compute instance-groups managed delete third-party-instance-group \
    --region=us-west1

  7. 인스턴스 템플릿을 삭제합니다.

    gcloud compute instance-templates delete third-party-template

    gcloud compute instance-templates delete third-party-template-multinic

  8. 테스트 및 프로덕션 인스턴스를 삭제합니다.

    gcloud compute instances delete testing-vm \
    --zone=us-west1-a

    gcloud compute instances delete production-vm \
    --zone=us-west1-a

다음 단계