Hybrid Subnets를 사용하여 Google Cloud 로 이전하는 방법
Hybrid Subnets는 IP 주소를 변경하지 않고도 워크로드를 다른 소스 네트워크에서 가상 프라이빗 클라우드(VPC) 서브넷으로 마이그레이션하는 데 도움이 됩니다. 소스 네트워크의 서브넷을 VPC 서브넷과 결합하면 개별 워크로드와 가상 머신 (VM) 인스턴스를 시간 경과에 따라 마이그레이션할 수 있는 단일 논리 서브넷을 만듭니다. 모든 워크로드와 VM이 마이그레이션된 후 소스 서브넷을 사용 중단할 수 있습니다.
Hybrid Subnets는 Google Cloud에서 온프레미스 네트워크로 또는 두 VPC 네트워크 간에 VM을 마이그레이션하는 것도 지원합니다.
사양
하이브리드 서브넷의 사양은 다음과 같습니다.
- 속성:
- 하이브리드 서브넷은 소스 네트워크의 세그먼트를 VPC 네트워크의 서브넷과 결합한 단일 논리 서브넷입니다.
- 내부 연결이 하이브리드 서브넷의 모든 VM과 워크로드 간에 유지됩니다.
- 소스 네트워크는 온프레미스 네트워크 또는 다른 VPC 네트워크일 수 있습니다. 세그먼트는 전체 서브넷이거나 서브넷의 일부일 수 있습니다.
- 하이브리드 서브넷의 두 부분은 Cloud VPN 또는 Cloud Interconnect와 같은 네트워크 연결 제품으로 연결되어야 합니다.
- VPC 서브넷의 기본 IPv4 주소 범위는 하이브리드 서브넷에서 사용하는 소스 네트워크의 세그먼트 범위와 일치해야 합니다.
- VPC 네트워크 구성:
- VPC 서브넷을 하이브리드 서브넷의 일부로 구성하려면 하이브리드 서브넷 라우팅을 사용 설정해야 합니다. 하이브리드 서브넷 라우팅이 사용 설정되면 커스텀 경로가 서브넷의 기본 및 보조 IPv4 주소 범위와 충돌(중복)할 수 있습니다.
- Cloud Router 커스텀 공지 경로를 사용하여 VM을 VPC 서브넷으로 마이그레이션할 때 VM IP 주소를 선택적으로 공지합니다. 프록시 ARP 및 최장 프리픽스 일치를 지원하려면 이러한 경로가 하이브리드 서브넷의 IP 주소 범위보다 더 구체적(서브넷 마스크가 더 김)이어야 합니다.
개별 VM에
/32경로를 사용할 수 있습니다.
- 소스 네트워크 구성:
- 소스 네트워크에서 프록시 ARP를 구성해야 합니다.
- 하이브리드 서브넷의 IP 주소 범위를 공지하도록 소스 네트워크를 구성해야 합니다.
하이브리드 서브넷 라우팅
하이브리드 서브넷은 소스 네트워크의 서브넷을 VPC 서브넷과 결합하여 단일 논리 서브넷을 만듭니다. 하이브리드 서브넷의 두 부분에 있는 워크로드는 내부 연결을 유지합니다. 워크로드는 대상의 위치와 관계없이 하이브리드 서브넷의 어느 부분에 있는 대상으로든 로컬인 것처럼 트래픽을 보낼 수 있습니다.
VPC 네트워크 라우팅
VPC 라우팅 모델의 서브넷 경로 일치 단계에서 패킷의 목적지가 로컬 또는 피어링 서브넷 경로와 일치하는 경우 Google Cloud 는 일치하는 서브넷 경로를 사용하여 패킷을 전송하려고 시도합니다. 일반 서브넷에서 목적지가 실행 중인 VM 또는 내부 전달 규칙과 연결되어 있지 않으면 패킷이 삭제되고 다른 모든 경로가 무시됩니다.
하지만 서브넷에 하이브리드 서브넷 라우팅이 사용 설정된 경우 서브넷 경로는 하이브리드 서브넷 경로가 되고 라우팅 동작은 다음과 같이 달라집니다.
- 패킷이 VPC 서브넷에서 실행 중인 VM 인스턴스 또는 내부 전달 규칙과 연결된 경우 Google Cloud는 로컬 하이브리드 서브넷 경로에 따라 패킷을 전달합니다.
- 패킷이 VPC 서브넷의 실행 중인 VM 또는 내부 전달 규칙과 연결되지 않은 경우 Google Cloud 는 일치하지 않는 리소스에 대한 특수 라우팅 프로세스를 사용합니다. 이 프로세스에는 하이브리드 서브넷의 범위와 중복되는 맞춤 동적 경로 및 정적 경로가 있는지 확인하는 작업이 포함됩니다. 올바르게 구성된 하이브리드 서브넷에서 패킷은 Cloud Router가 소스 서브넷에 대해 학습한 로컬 동적 경로를 사용하여 소스 네트워크로 라우팅됩니다.
예를 들어 그림 3에서 패킷 A는 로컬 하이브리드 서브넷 경로를 사용하여 하이브리드 서브넷의 VPC 부분에 있는 VM으로 라우팅됩니다. 패킷 B의 목적지가 하이브리드 서브넷의 VPC 부분에 있는 실행 중인 VM 또는 내부 전달 규칙과 연결되어 있지 않으므로 Google Cloud 충돌하는 커스텀 경로를 확인합니다. 일치하는 항목이 발견되고 Google Cloud 는 중복되는 맞춤 동적 경로를 사용하여 패킷 B를 소스 네트워크로 전송합니다.
소스 네트워크 라우팅
소스 네트워크의 워크로드가 하이브리드 서브넷의 IP 주소 범위에 있는 대상으로 패킷을 전송하면 소스 네트워크의 라우터 또는 첫 번째 홉 기기에서 라우팅 테이블 조회를 실행합니다.
대상과 소스 네트워크의 워크로드가 연결되어 있으면 라우터가 프록시 ARP를 방해하지 않습니다. 대상은 ARP 요청을 수신하고 자체 MAC 주소로 응답하며 패킷은 로컬로 전송됩니다.
목적지가 하이브리드 서브넷의 VPC 부분에 있고 라우터가 로컬 서브넷 경로보다 더 구체적인 목적지의 동적 경로를 학습한 경우 라우터는 최장 프리픽스 일치를 사용하여 동적 경로를 선택합니다. 이렇게 하면 라우터의 프록시 ARP 기능이 트리거됩니다. 라우터는 자체 MAC 주소로 응답하고 패킷을 VPC 네트워크의 Cloud Router로 라우팅합니다.
제한사항
Hybrid Subnets에는 다음과 같은 제한사항이 있습니다.
리소스 제한사항:
- VPC 네트워크당 하이브리드 서브넷을 25개 이상 구성하지 마세요.
Instances per VPC network130개를 초과하지 마세요.Internal passthrough Network Load Balancer forwarding rules per VPC network25개를 초과하지 마세요.- 하이브리드 서브넷이 있는 VPC 네트워크가 VPC 네트워크 피어링을 사용하여 다른 VPC 네트워크에 연결된 경우
Dynamic routes per region per peering group50개를 초과하지 마세요. - VPC 네트워크당 300개가 넘는 커스텀 경로(정적 및 동적)를 구성하지 마세요.
이러한 리소스 제한은 Google Cloud 한도 또는 할당량에 의해 적용되지 않습니다. 이러한 한도를 초과하면 연결 및 안정성 문제가 발생할 수 있습니다.
지원되지 않는 교통 및 경로:
- 충돌하는 경로의 다음 홉이 하이브리드 서브넷과 다른 리전에 있는 경우 패킷이 삭제됩니다.
- 다음 경로 유형은 충돌하는 경로로 지원되지 않습니다.
- 시스템 생성 기본 경로
- 정책 기반 경로
- 네트워크 태그가 있는 정적 경로
- 목적지가 하이브리드 서브넷 경로를 포함하거나 이보다 넓은 경로
- Network Connectivity Center는 Hybrid Subnets에서 완전히 지원되지 않습니다. 하이브리드 서브넷을 포함하는 VPC 네트워크를 Network Connectivity Center 허브의 스포크로 구성할 수 있습니다. 하지만 연결된 스포크에서 하이브리드 서브넷의 IP 주소 범위로 전송되는 트래픽의 라우팅 동작은 예측할 수 없습니다.
- 하이브리드 NAT는 Hybrid Subnets에서 지원되지 않습니다. 하이브리드 NAT를 사용하도록 하이브리드 서브넷을 구성할 수는 있지만 이 기능은 하이브리드 서브넷 라우팅의 영향을 받는 트래픽에는 적용되지 않습니다.
- 하이브리드 서브넷 라우팅은 IPv6 트래픽에 적용되지 않습니다.
- 하이브리드 서브넷 내의 브로드캐스트 및 멀티캐스트 트래픽은 지원되지 않습니다.
- Hybrid Subnets로
/32경로를 공지할 수 없는 Layer 3 Partner Interconnect 연결은 사용할 수 없습니다. - 하이브리드 서브넷의 Cloud Router는 BGP 세션당 최대 커스텀 공지 경로 수를 초과할 수 없습니다.
- 소스 네트워크의 워크로드는 비공개 Google 액세스를 사용하여 Google API 및 서비스에 도달할 수 없습니다.
- 소스 네트워크의 워크로드는 Google API용 Private Service Connect 엔드포인트에 도달할 수 없습니다.
지원되지 않는 마이그레이션 시나리오:
- Hybrid Subnets는 다른 클라우드 서비스 제공업체의 워크로드 마이그레이션을 지원하지 않습니다.
- Hybrid Subnets는 Azure 또는 AWS 소스에서 VM을 마이그레이션하는 것을 지원하지 않습니다.
- Hybrid Subnets는 사이트 간 데이터 전송을 지원하지 않습니다.
- Hybrid Subnets는 Google Cloud VMware Engine을 마이그레이션 대상으로 지원하지 않습니다. VMware Engine이 마이그레이션 대상인 경우 VMware HCX를 사용하여 VMware VM을 마이그레이션하는 것이 좋습니다.
기타 제한사항:
- Hybrid Subnets는 하이브리드 서브넷의 소스 네트워크와 VPC 부분 간에 IP 주소 충돌을 감지하지 않습니다. 각 IP 주소 (기본 게이트웨이 제외)가 한 번만 사용되어야 합니다.
- Hybrid Subnets는 IPv4 서브넷의 예약된 IP 주소에서 워크로드를 호스팅할 수 없습니다.
- 소스 네트워크의 워크로드는 중앙 집중식 상태 점검을 사용하는 하이브리드 연결 네트워크 엔드포인트 그룹의 엔드포인트가 될 수 없습니다.
- Cloud DNS 인바운드 전달은 소스 네트워크의 워크로드에서 전송된 DNS 요청에 응답하지 않습니다.
이전 옵션
Google에서는 Hybrid Subnets와 함께 Migrate to Virtual Machines를 사용하여 VMware 소스 또는 Google Cloud VMware Engine 소스에서 VM을 마이그레이션하는 프로세스를 자동화하는 것이 좋습니다.
또는 이 문서에 설명된 Hybrid Subnets의 요구사항이 충족되는 한 Hybrid Subnets와 함께 서드 파티 마이그레이션 도구를 사용할 수 있습니다.
Migrate to Virtual Machines를 사용한 마이그레이션을 계획하는 방법은 Migrate to VMs를 사용한 마이그레이션 여정을 참고하세요.
마이그레이션 옵션에 대한 자세한 내용은 마이그레이션 리소스를 참조하세요.
Hybrid Subnets를 사용하여 Google Cloud 로의 마이그레이션을 계획하는 데 도움이 필요하면 지원 케이스를 제출하세요.
Hybrid Subnets 사용 시 고려사항
다음 섹션에서는 Hybrid Subnets를 사용할 때의 고려사항을 설명합니다.
프록시 ARP 및 Hybrid Subnets
Hybrid Subnets를 사용하려면 소스 네트워크의 라우터 또는 첫 번째 홉 기기 (호스트가 로컬 네트워크 외부의 대상을 갖는 트래픽을 처음 전송하는 지점)에 프록시 ARP를 구성해야 합니다.
첫 번째 홉 기기는 라우터, 가상 어플라이언스, 방화벽 또는 choparp와 같은 소프트웨어 솔루션을 실행하는 VM일 수 있습니다.
소스 네트워크에서 프록시 ARP를 사용할 때는 다음을 수행하는 것이 좋습니다.
- 프록시 ARP 사용 설정 및 네트워크 환경 보호와 관련된 권장사항은 소스 네트워크 패브릭 공급업체에 문의하세요.
- Google Cloud로 마이그레이션을 완료하면 프록시 ARP를 중지합니다.
지역 제한
하이브리드 서브넷이 올바르게 작동하려면 충돌하는 경로(하이브리드 서브넷의 주소 범위와 겹치는 커스텀 경로)의 다음 홉이 모두 하이브리드 서브넷과 동일한 리전에 있어야 합니다.
충돌하는 경로의 다음 홉이 다른 리전에 있는 경우:
- 경로에 로컬 및 원격 다음 홉이 혼합되어 있는 경우 ECMP가 원격 리전의 다음 홉을 선택할 때마다 트래픽이 삭제됩니다. 이 패킷 삭제는 패킷이 동일한 리전에 다음 홉이 있는 덜 구체적인 경로와 일치하는 경우에도 발생합니다.
- 경로에 하이브리드 서브넷과 동일한 리전의 다음 홉이 없으면 패킷이 삭제됩니다.
다음 리소스가 동일한 리전에 있는지 확인합니다.
- 하이브리드 서브넷으로 구성된 VPC 서브넷
- 소스 네트워크로의 경로를 학습하는 Cloud Router
- 하이브리드 연결을 제공하는 HA VPN 터널 또는 VLAN 연결
예를 들어 IP 주소 범위가 192.0.2.0/24인 하이브리드 서브넷이 있다고 가정해 보겠습니다. VPC 서브넷은 us-central1 리전에 있습니다.
Cloud Router가 충돌하는 두 경로를 학습했습니다.
- 대상 범위가
192.0.2.0/25이고 다음 홉이us-central1리전에 있는 커스텀 경로 - 대상 범위가
192.0.2.0/30이고us-west1리전에 다음 홉이 있는 커스텀 경로
패킷이 대상 192.0.2.2로 전송됩니다. 이 IP 주소는 VPC 서브넷의 실행 중인 VM 또는 내부 전달 규칙과 연결되어 있지 않으므로 경로 선택 모델은 가장 구체적인 대상(192.0.2.0/30)이 있는 맞춤 경로를 선택합니다. 이 경로에는 하이브리드 서브넷의 리전에 다음 홉이 없으므로 패킷이 삭제됩니다.
자세한 내용은 하이브리드 서브넷의 일치하지 않는 리소스를 참고하세요.
VPC 네트워크 피어링
VPC 네트워크 피어링을 사용하여 하이브리드 서브넷을 피어 VPC 네트워크에 연결할 수 있습니다. 하이브리드 서브넷의 VPC 네트워크는 서브넷 및 커스텀 경로를 내보내도록 구성되어야 하고 피어링된 VPC 네트워크는 이를 가져오도록 구성되어야 합니다.
피어링된 VPC 네트워크에서 경로를 프로그래밍하면 Google Cloud 또는 소스 네트워크에 있는지 여부와 관계없이 하이브리드 서브넷의 IP 주소 범위 내 대상에 도달할 수 있습니다.
다음과 같은 경우 피어링된 네트워크에 경로가 프로그래밍되지 않습니다.
- 피어링된 네트워크의 로컬 서브넷 경로의 대상 범위가 가져온 경로의 대상 범위와 동일합니다.
- 피어링 그룹당 리전별 동적 경로 할당량이 초과되었습니다.
- 두 VPC 네트워크가 직접 피어링되지 않습니다. VPC 네트워크 피어링은 비전환성입니다.
이러한 조건 중 하나라도 참이면 피어링된 VPC 네트워크 관점에서 하이브리드 서브넷이 올바르게 작동하지 않습니다.
네트워크 성능
Hybrid Subnets는 OSI 모델의 레이어 3을 사용하여 하이브리드 서브넷의 소스 네트워크와 VPC 부분 간에 패킷을 라우팅합니다. 이 접근 방식은 일부 워크로드가 소스 네트워크에 있지만 다른 워크로드가 클라우드로 마이그레이션되었을 때 마이그레이션 중에 발생할 수 있는 지연 시간, 지터, 처리량과 관련된 문제를 Hybrid Subnets에서 방지하는 데 도움이 됩니다.
특히 Layer 2 터널링을 방지하면 추가 Layer 2 오버레이의 캡슐화 및 암호화와 관련된 성능 저하를 방지할 수 있습니다. 또한 레이어 3 라우팅을 사용하면 Hybrid Subnets가 트래픽의 출발지와 가까울 수 있는 대상에 도달하기 전에 트래픽이 중앙 노드로 전송되는 레이어 2 터널링의 일반적인 문제를 방지할 수 있습니다. 이 문제를 네트워크 트롬보닝이라고도 합니다.
Hybrid Subnets의 라우팅 접근 방식은 Hybrid Subnets를 사용하지 않는 네트워크와 유사하거나 동일한 하이브리드 서브넷에서 성능을 기대할 수 있음을 의미합니다.
방화벽 및 Hybrid Subnets
Hybrid Subnets는 레이어 2 오버레이에 캡슐화된 트래픽에 방화벽을 사용하는 것과 관련된 문제를 방지합니다. 레이어 2 트래픽의 경우 오버레이 트래픽의 투명 복호화 또는 심층 검사와 같은 특정 조치를 취하지 않는 한 방화벽에서 오버레이 엔드포인트 또는 그 밖의 패킷만 검사할 수 있습니다.
Hybrid Subnets에 기존 방화벽 및 방화벽 규칙을 사용할 때는 특별한 고려사항이 없습니다. 하지만 Google Cloud VM이 소스 네트워크의 워크로드와 통신할 수 있도록 방화벽 규칙을 구성해야 할 수 있습니다.
가격 책정
Hybrid Subnets 사용에 대한 추가 요금은 발생하지 않습니다. 하지만 하이브리드 서브넷의 VPC 부분에 있는 리소스와 네트워크 트래픽에 대한 요금은 청구됩니다.
자세한 내용은 Virtual Private Cloud 가격 책정을 참조하세요.
다음 단계
- Hybrid Subnets 연결을 위해 VPC 네트워크를 준비하려면 Hybrid Subnets 연결 준비를 참고하세요.