타사 어플라이언스의 내부 TCP/UDP 부하 분산 설정

이 가이드에서는 예시를 사용하여 Google Cloud 내부 TCP/UDP 부하 분산기를 다음 홉으로 구성하는 방법을 설명합니다. 이 가이드를 수행하기 전에 다음 사항을 숙지하세요.

권한

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

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

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

단일 백엔드 NIC에 대한 부하 분산

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

이 가이드에서 설명하는 솔루션은 가상 어플라이언스를 통합하여 각 가상 어플라이언스로 트래픽을 전송하도록 클라이언트를 명시적으로 재구성할 필요가 없습니다. 이 설정 가이드의 예시에서는 부하 분산된 방화벽 가상 어플라이언스를 통해 모든 트래픽을 전송합니다.

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

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

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

내부 TCP/UDP 부하 분산을 위한 다음 홉 단일 NIC 예시(확대하려면 클릭)
내부 TCP/UDP 부하 분산을 위한 다음 홉 단일 NIC 예시(확대하려면 클릭)

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

  • 내부 TCP/UDP 부하 분산기(이 예시에서는 fr-ilb1) 뒤에 있는 애플리케이션 인스턴스(이 경우 방화벽 어플라이언스 소프트웨어를 실행하는 VM). 애플리케이션 인스턴스에는 내부 IP 주소만 있습니다.
  • 각 애플리케이션 인스턴스에는 can-ip-forward 플래그가 사용 설정되어 있습니다. 이 플래그가 없으면 Compute Engine VM에서는 패킷의 소스 IP 주소가 VM의 IP 주소 중 하나와 일치하는 경우에만 패킷을 전송할 수 있습니다. VM이 모든 소스 IP 주소로 패킷을 전송할 수 있도록 can-ip-forward 플래그가 이 동작을 변경합니다.
  • 대상 10.50.1.0/24 및 다음 홉이 부하 분산기의 전달 규칙 fr-ilb1로 설정된 커스텀 정적 경로

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

  • testing VPC 네트워크에는 10.50.1.0/24 서브넷으로 향하는 트래픽에 대한 커스텀 정적 경로가 지정되어 있습니다. 이 경로는 부하 분산기로 트래픽을 전달합니다.
  • 부하 분산기는 구성된 세션 어피니티에 따라 애플리케이션 인스턴스 중 하나로 트래픽을 전달합니다. 세션 어피니티는 TCP 트래픽에만 영향을 줍니다.
  • 애플리케이션 인스턴스는 production VPC 네트워크의 인스턴스 그룹에 패킷을 전달하기 위해 소스 네트워크 주소 변환(SNAT)을 수행합니다. 반환 트래픽의 경우 testing VPC 네트워크의 클라이언트 인스턴스로 패킷을 전달하기 위해 대상 네트워크 주소 변환(DNAT)을 수행합니다.

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

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

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

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

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

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

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

Console

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

  1. Google Cloud Console에서 VPC 네트워크 페이지로 이동합니다.
    VPC 네트워크 페이지로 이동
  2. VPC 네트워크 만들기를 클릭합니다.
  3. testing이름을 입력합니다.
  4. 서브넷 섹션에서 다음을 수행합니다.
    • 서브넷 생성 모드커스텀으로 설정합니다.
    • 새 서브넷 섹션에 다음 정보를 입력합니다.
      • 이름: testing-subnet
      • 리전: us-west1
      • IP 주소 범위: 10.30.1.0/24
      • 완료를 클릭합니다.
  5. 만들기를 클릭합니다.

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

  1. Google Cloud Console에서 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 리전의 testingproduction 네트워크에 서브넷을 만듭니다.

    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-subnet: testing 네트워크의 모든 대상에 적용되는 인그레스 규칙으로, 10.30.1.0/24 범위의 소스에서 오는 트래픽을 허용합니다. 이 규칙을 사용하면 testing-subnet의 타사 VM 어플라이언스와 VM 인스턴스가 통신할 수 있습니다.

  • fw-allow-production-subnet: production 네트워크의 모든 대상에 적용되는 인그레스 규칙으로, 10.50.1.0/24 범위의 소스에서 오는 트래픽을 허용합니다. 이 규칙을 사용하면 production-subnet의 타사 VM 어플라이언스와 VM 인스턴스가 통신할 수 있습니다.

  • 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/2235.191.0.0/16)의 트래픽을 허용합니다. 이 예시에서는 allow-health-check 대상 태그를 사용하여 적용해야 할 인스턴스를 식별합니다.

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

Console

  1. Google Cloud Console의 방화벽 페이지로 이동합니다.
    방화벽 페이지로 이동
  2. 방화벽 규칙 만들기를 클릭하고 다음 정보를 입력하여 서브넷 트래픽을 허용하는 규칙을 만듭니다.
    • 이름: fw-allow-testing-subnet
    • 네트워크: testing
    • 우선순위: 1000
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 네트워크의 모든 인스턴스
    • 소스 필터: IP ranges
    • 소스 IP 범위: 10.30.1.0/24
    • 프로토콜 및 포트: 모두 허용
  3. 만들기를 클릭합니다.
  4. 방화벽 규칙 만들기를 클릭하고 다음 정보를 입력하여 서브넷 트래픽을 허용하는 규칙을 만듭니다.
    • 이름: fw-allow-production-subnet
    • 네트워크: production
    • 우선순위: 1000
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 네트워크의 모든 인스턴스
    • 소스 필터: IP ranges
    • 소스 IP 범위: 10.50.1.0/24
    • 프로토콜 및 포트: 모두 허용
  5. 만들기를 클릭합니다.
  6. 방화벽 규칙 만들기를 다시 클릭하여 수신 SSH 연결을 허용하는 규칙을 만듭니다.
    • 이름: fw-allow-testing-ssh
    • 네트워크: testing
    • 우선순위: 1000
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 지정된 대상 태그
    • 대상 태그: allow-ssh
    • 소스 필터: IP ranges
    • 소스 IP 범위: 0.0.0.0/0
    • 프로토콜 및 포트: 지정된 프로토콜 및 포트를 선택하고 tcp:22를 입력합니다.
  7. 만들기를 클릭합니다.
  8. 방화벽 규칙 만들기를 다시 클릭하여 수신 SSH 연결을 허용하는 규칙을 만듭니다.
    • 이름: fw-allow-production-ssh
    • 네트워크: production
    • 우선순위: 1000
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 지정된 대상 태그
    • 대상 태그: allow-ssh
    • 소스 필터: IP ranges
    • 소스 IP 범위: 0.0.0.0/0
    • 프로토콜 및 포트: 지정된 프로토콜 및 포트를 선택하고 tcp:22를 입력합니다.
  9. 만들기를 클릭합니다.
  10. 방화벽 규칙 만들기를 세 번째로 클릭하여 Google Cloud 상태 확인을 허용하는 규칙을 만듭니다.
    • 이름: fw-allow-health-check
    • 네트워크: testing
    • 우선순위: 1000
    • 트래픽 방향: 인그레스
    • 일치 시 작업: 허용
    • 대상: 지정된 대상 태그
    • 대상 태그: allow-health-check
    • 소스 필터: IP ranges
    • 소스 IP 범위: 130.211.0.0/2235.191.0.0/16
    • 프로토콜 및 포트: 모두 허용
  11. 만들기를 클릭합니다.

gcloud

  1. fw-allow-testing-subnet 방화벽 규칙을 만들어 서브넷과의 통신을 허용합니다.

    gcloud compute firewall-rules create fw-allow-testing-subnet \
        --network=testing \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.30.1.0/24 \
        --rules=tcp,udp,icmp
    
  2. fw-allow-production-subnet 방화벽 규칙을 만들어 서브넷과의 통신을 허용합니다.

    gcloud compute firewall-rules create fw-allow-production-subnet \
        --network=production \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.50.1.0/24 \
        --rules=tcp,udp,icmp
    
  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,udp,icmp
    

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

다음 단계는 iptables 소프트웨어를 타사 가상 어플라이언스로 사용하여 인스턴스 템플릿 및 관리형 리전 인스턴스 그룹을 만드는 방법을 보여줍니다.

Console

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

gcloud

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

    gcloud compute instance-templates create third-party-template \
        --region=us-west1 \
        --network-interface subnet=testing-subnet,address="" \
        --network-interface subnet=production-subnet \
        --tags=allow-ssh,allow-health-check \
        --image-family=debian-9 \
        --image-project=debian-cloud \
        --can-ip-forward \
        --metadata=startup-script='#! /bin/bash
        # Enable IP forwarding:
        echo 1 > /proc/sys/net/ipv4/ip_forward
        echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
        # Read VM network configuration:
        md_vm="http://169.254.169.254/computeMetadata/v1/instance/"
        md_net="$md_vm/network-interfaces"
        nic0_gw="$(curl -H "Metadata-Flavor:Google" $md_net/0/gateway)"
        nic0_mask="$(curl -H "Metadata-Flavor:Google" $md_net/0/subnetmask)"
        nic1_gw="$(curl -H "Metadata-Flavor:Google" $md_net/1/gateway)"
        nic1_mask="$(curl -H "Metadata-Flavor:Google" $md_net/1/subnetmask)"
        nic1_addr="$(curl -H "Metadata-Flavor:Google" $md_net/1/ip)"
        # Start iptables:
        /sbin/iptables -t nat -F
        /sbin/iptables -t nat -A POSTROUTING \
        -s "$nic0_gw/$nic0_mask" \
        -d "$nic1_gw/$nic1_mask" \
        -o eth1 \
        -j SNAT \
        --to-source "$nic1_addr"
        /sbin/iptables-save
        # Use a web server to pass the health check for this example.
        # You should use a more complete test in production.
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        echo "Example web page to pass health check" | \
        tee /var/www/html/index.html
        systemctl restart apache2'
    
  2. 타사 가상 어플라이언스의 관리형 인스턴스 그룹을 만듭니다. 다음 명령어는 us-west1에서 리전 관리형 인스턴스 그룹을 만들고 자동 확장할 수 있습니다.

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

부하 분산 리소스 만들기

이러한 단계를 통해 상태 확인 및 백엔드 서비스부터 프런트엔드 구성요소에 이르기까지 모든 내부 TCP/UDP 부하 분산기 구성요소를 구성합니다.

  • 상태 확인: 이 예시에서 HTTP 상태 확인은 HTTP 200(OK) 응답을 확인합니다. 자세한 내용은 내부 TCP/UDP 부하 분산 개요의 상태 확인 섹션을 참조하세요.

  • 백엔드 서비스: 이 예시의 백엔드 서비스가 TCP 프로토콜을 지정하더라도 부하 분산기가 경로의 다음 홉인 경우에는 TCP 및 UDP 트래픽이 모두 부하 분산기의 백엔드로 전송됩니다.

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

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

Console

부하 분산기 생성 및 백엔드 서비스 구성

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

gcloud

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

    gcloud compute health-checks create http hc-http-80 \
        --region=us-west1 \
        --port=80
    
  2. us-west1 리전에서 내부 백엔드 서비스를 만듭니다.

    gcloud compute backend-services create ilb1 \
        --health-checks-region=us-west1 \
        --load-balancing-scheme=internal \
        --region=us-west1 \
        --health-checks=hc-http-80
    
  3. 타사 가상 어플라이언스가 포함된 인스턴스 그룹을 백엔드 서비스의 백엔드로 추가합니다.

    gcloud compute backend-services add-backend ilb1 \
        --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
    

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

정적 경로를 만들 때 next-hop-address를 사용하여 부하 분산기 전달 규칙의 IP 주소를 가리킬 수 없습니다. Google Cloud는 next-hop-address 사용 시 해당 IP 주소에 할당된 VM 인스턴스로 트래픽을 전달하며, 부하 분산기는 VM 인스턴스가 아니기 때문입니다. 대신 다음 예시에서와 같이 부하 분산기를 다음 홉으로 지정하려면 next-hop-ilb 플래그를 사용해야 합니다.

Console

  1. Google Cloud Console의 경로 페이지로 이동합니다.
    경로 페이지로 이동
  2. 경로 만들기를 클릭합니다.
  3. 경로 이름에 `ilb-nhop-dest-10-50-1을 입력합니다.
  4. testing 네트워크를 선택합니다.
  5. 대상 IP 범위10.50.1.0/24를 입력합니다.
  6. 이 기능에서는 현재 태그가 지원되지 않으므로 태그가 지정되지 않도록 확인합니다.
  7. 경로의 다음 홉에 대해 내부 TCP/UDP 부하 분산기의 전달 규칙 지정을 선택합니다.
  8. 다음 홉 리전으로 us-west1을 선택합니다.
  9. 전달 규칙 이름으로 fr-ilb1을 선택합니다.
  10. 만들기를 클릭합니다.

gcloud

다음 홉이 부하 분산기의 전달 규칙으로 설정되고 대상 범위가 경로 10.50.1.0/24로 설정된 고급 경로를 만듭니다.

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=fr-ilb1 \
    --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-9 \
        --image-project=debian-cloud \
        --tags=allow-ssh \
        --subnet=testing-subnet \
        --private-network-ip 10.30.1.100 \
        --metadata=startup-script='#! /bin/bash
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        vm_hostname="$(curl -H "Metadata-Flavor:Google" \
        http://169.254.169.254/computeMetadata/v1/instance/name)"
        echo "Page served from: $vm_hostname" | \
        tee /var/www/html/index.html
        systemctl restart apache2'
    

production VM 인스턴스 만들기

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

gcloud

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

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

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

단일 NIC 배포로 부하 분산 테스트

이 테스트에서는 production VPC 네트워크의 대상 VM 예시를 testing VPC 네트워크의 클라이언트 VM과 연결합니다. 부하 분산기는 패킷을 부하 분산기의 IP 주소로 보내는 대신 부하 분산기를 통해 대상 10.50.1.100으로 패킷을 라우팅하므로 다음 홉으로 사용됩니다.

이 예시에서 부하 분산기의 정상적인 백엔드 어플라이언스 VM의 iptables 소프트웨어는 패킷의 NAT를 처리합니다.

  1. 클라이언트 VM 인스턴스에 연결합니다.

    gcloud compute ssh testing-vm --zone=us-west1-a
    
  2. curl을 사용하여 대상 인스턴스의 웹 서버 소프트웨어에 대한 웹 요청을 만듭니다. 예상되는 출력은 대상 인스턴스(Page served from: destination-instance)의 색인 페이지 내용입니다.

    curl http://10.50.1.100
    

일반적인 백엔드가 있는 다음 홉으로 내부 TCP/UDP 부하 분산기 설정

여러 NIC에 대한 부하 분산에 설명된 대로 여러 백엔드 NIC로 부하 분산하면 이 예시를 확장할 수 있습니다.

내부 TCP/UDP 부하 분산을 위한 다음 홉 다중 NIC 세부 예시(확대하려면 클릭)
내부 TCP/UDP 부하 분산을 위한 다음 홉 다중 NIC 세부 예시(확대하려면 클릭)
  1. 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,udp,icmp
    
  2. 새 인스턴스 템플릿을 만듭니다.

    이 설정이 상태 확인을 통해 원활하게 작동하려면 이그레스 상태 확인 응답 패킷이 올바른 인터페이스를 통과하도록 정책 기반 라우팅을 구성해야 합니다. 상태 확인은 외부 IP 주소를 상태 확인 프로브의 소스로 사용합니다. 게스트 운영체제는 대상 IP 주소를 기반으로 발신 NIC를 선택합니다. 대상 IP 주소가 서브넷 범위에 있지 않은 경우 발신 NIC의 기본값은 nic0입니다. 이러한 경우, 정책 기반 라우팅을 사용하여 각 네트워크 인터페이스에 별도의 라우팅 테이블을 구성해야 합니다.

    소스 기반 정책 라우팅은 Windows 또는 Mac 운영체제에서 작동하지 않습니다.

    백엔드 VM 템플릿에 다음 정책 라우팅을 추가합니다. 여기서 10.50.1.0/24는 부하 분산기가 있는 서브넷이고 다중 NIC VM의 eth1입니다. 기본 게이트웨이는 10.50.1.1입니다.

    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 \
        --image-family=debian-9 \
        --image-project=debian-cloud \
        --can-ip-forward \
        --metadata=startup-script='#! /bin/bash
        # Enable IP forwarding:
        echo 1 > /proc/sys/net/ipv4/ip_forward
        echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
        # Read VM network configuration:
        md_vm="http://169.254.169.254/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")"
        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")"
        # Source based policy routing for nic1
        echo "100 rt-nic1" >> /etc/iproute2/rt_tables
        ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1
        sleep 1
        ip route add 35.191.0.0/16 via $nic1_gw dev eth1 table rt-nic1
        ip route add 130.211.0.0/22 via $nic1_gw dev eth1 table rt-nic1
        # Start iptables:
        iptables -t nat -F
        iptables -t nat -A POSTROUTING \
        -s $nic0_gw/$nic0_mask \
        -d $nic1_gw/$nic1_mask \
        -o eth1 \
        -j SNAT \
        --to-source $nic1_addr
        iptables -t nat -A POSTROUTING \
        -s $nic1_gw/$nic1_mask \
        -d $nic0_gw/$nic0_mask \
        -o eth0 \
        -j SNAT \
        --to-source $nic0_addr
        iptables-save
        # Use a web server to pass the health check for this example.
        # You should use a more complete test in production.
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        echo "Example web page to pass health check" | \
        tee /var/www/html/index.html
        systemctl restart apache2'
    
  3. 인스턴스 그룹을 업데이트합니다.

    gcloud compute instance-groups managed set-instance-template \
        third-party-instance-group \
        --region us-west1 \
        --template=third-party-template-multinic
    
  4. third-party-template-multinic 템플릿을 사용하여 관리형 인스턴스 그룹을 다시 만듭니다.

    gcloud compute instance-groups managed rolling-action replace \
        third-party-instance-group \
        --region us-west1
    

    인스턴스가 준비될 때까지 몇 분 정도 기다립니다. list-instances 명령어를 실행하여 진행 상황을 확인할 수 있습니다.

    gcloud compute instance-groups managed list-instances \
        third-party-instance-group \
        --region us-west1
    

    출력은 다음과 같습니다.

    NAME                             ZONE        STATUS   ACTION  INSTANCE_TEMPLATE              VERSION_NAME                        LAST_ERROR
    third-party-instance-group-5768  us-west1-a  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
    third-party-instance-group-4zf4  us-west1-b  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
    third-party-instance-group-f6lm  us-west1-c  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
    
  5. production VPC 네트워크의 부하 분산기 리소스를 구성합니다.

    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
    
    gcloud compute backend-services add-backend ilb2 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
    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
    
    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
    

다중 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.100
    
    exit
    
  3. production VM에서 연결을 테스트합니다.

    gcloud compute ssh production-vm --zone=us-west1-a
    
    curl http://10.30.1.100
    

삭제

  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
    

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

    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
    

다음 단계