피어링 연결 정보

이 페이지에서는 VPC 네트워크 피어링 연결 관리에 대해 간략하게 설명합니다.

피어링 연결

피어링 연결 은 두 개의 가상 프라이빗 클라우드 (VPC) 네트워크를 연결합니다. 피어링 연결을 설정하려면 각 측에서 다른 네트워크를 참조하는 피어링 구성 을 별도로 만듭니다.

피어링 구성을 만들어 다른 VPC 네트워크에 연결하는 요청을 시작합니다. 내 네트워크와 피어링할 상응하는 구성이 다른 네트워크에 있으면 피어링 연결이 설정되고 피어링 상태가 두 네트워크 모두에서 ACTIVE로 변경됩니다. 다른 네트워크에 일치하는 피어링 구성이 없으면 피어링 상태가 INACTIVE로 유지됩니다. 이는 내 네트워크와 다른 네트워크가 연결되지 않는다는 것을 나타냅니다.

피어링 연결을 만들어도 다른 VPC 네트워크에 대해 Identity and Access Management 역할이 부여되지 않습니다. 예를 들어 하나의 네트워크에 대해 Compute 네트워크 관리자 역할(roles/compute.networkAdmin) 또는 Compute 보안 관리자 역할(roles/compute.securityAdmin)이 있어도 다른 네트워크에 대해서는 네트워크 관리자 또는 보안 관리자가 되지 않습니다.

피어링 연결이 설정되면 두 VPC 네트워크는 항상 비공개 IPv4 주소 범위를 사용하는 IPv4 서브넷 경로를 교환합니다. 경로 교환 옵션에 대한 자세한 내용은 다음을 참조하세요.

연결 모드

연결 모드 는 피어링 연결을 관리하는 방법을 결정합니다. VPC 네트워크 피어링은 두 가지 연결 모드를 지원합니다.

표준 배포의 경우 일반적으로 독립 모드가 선호됩니다. 하지만 피어링 연결을 실수로 삭제하면 서비스 중단이 발생하는 중요 서비스를 지원하는 배포의 경우 합의 모드를 사용하는 것이 좋습니다. 이 모드에서는 두 네트워크의 동의가 필요하며 피어링 연결의 유효 상태에 대한 일방적인 변경을 방지합니다.

피어링 연결을 만들 때 두 피어링 구성 모두 동일한 연결 모드(독립 또는 합의)를 지정해야 합니다.

기존 연결의 피어링 모드를 독립에서 합의로 변경하려면 두 피어링 구성을 모두 업데이트해야 합니다. 연결 모드를 합의에서 독립으로 변경하는 것은 지원되지 않습니다.

독립 모드

피어링 연결이 독립 모드 (기본값)에 있으면 어느 네트워크에서든 언제든지 연결을 업데이트하거나 삭제할 수 있습니다. 연결 모드를 합의로 업데이트하여 이 동작을 선택적으로 제한할 수 있습니다.

합의 모드

합의 모드는 네트워크 동작에 대한 실수로 인한 일방적인 변경을 방지합니다. 피어링 연결이 합의 모드에 있으면 피어링 연결을 업데이트하거나 삭제하는 모든 요청에 두 네트워크의 동의가 필요합니다.

연결의 합의 모드 구성

update_strategy 매개변수를 설정하여 합의 모드를 사용하도록 새 피어링 연결 또는 기존 피어링 연결을 구성할 수 있습니다.

  • 새 연결. 두 네트워크 모두 업데이트 전략을 CONSENSUS로 설정해야 합니다. 업데이트 전략이 지정되지 않으면 연결이 독립 모드로 생성됩니다.

  • 기존 연결. 두 네트워크 모두 업데이트 전략을 CONSENSUS로 변경해야 합니다. 두 값이 일치할 때까지 유효한 업데이트 전략은 INDEPENDENT로 유지되며 일방적인 업데이트 및 삭제 요청이 허용됩니다.

    연결 모드를 업데이트하는 보류 중인 요청은 다운타임을 유발하지 않으며 요청이 진행되는 동안 연결이 활성 상태로 유지됩니다.

또한 연결의 합의 모드를 구성하려면 구성의 각 경로 교환 옵션이 피어 구성의 보완 플래그와 동일한 값을 가져야 합니다. 다음 플래그의 값이 일치하지 않으면 연결을 만들거나 업데이트하는 요청이 거부됩니다.

로컬 플래그 보완 피어 플래그
import_custom_route export_custom_route
export_custom_route import_custom_route
import_subnet_routes_with_public_ip export_subnet_routes_with_public_ip
export_subnet_routes_with_public_ip import_subnet_routes_with_public_ip
stack_type stack_type

예를 들어 네트워크가 커스텀 경로를 가져오는 경우 피어 네트워크는 커스텀 경로를 내보내야 합니다. 기존 연결에 대해 이러한 값이 일치하지 않으면 연결 모드를 변경하기 전이나 변경할 때 어느 네트워크에서든 이러한 값을 업데이트할 수 있습니다.

기존 연결의 합의 모드를 구성하는 보류 중인 요청을 취소하려면 요청 네트워크에서 업데이트 전략을 INDEPENDENT로 재설정해야 합니다.

자세한 내용은 합의 모드로 피어링 연결 만들기 및 합의
모드로 연결 업데이트를 참조하세요.

합의 모드로 연결 업데이트

피어링 연결의 어느 한쪽에서 업데이트 요청을 제출할 수 있습니다. 보류 중인 업데이트 요청은 다운타임을 유발하지 않으며 연결이 활성 상태로 유지됩니다. 삭제 요청이 진행 중이면 보류 중인 업데이트 요청 수락 또는 취소를 포함한 모든 업데이트 요청이 거부됩니다.

합의 모드로 구성된 피어링 연결을 업데이트하려면 로컬 네트워크 관리자가 먼저 로컬 구성을 업데이트합니다. 그런 다음 피어 네트워크 관리자가 피어 구성에 보완 업데이트를 적용해야 합니다. 예를 들어 --export-custom-routes 플래그를 true로 업데이트하면 피어 네트워크에서 --import-custom-routes 플래그를 true로 설정해야 합니다. 피어 네트워크에서 상응하는 구성을 업데이트할 때까지 피어링 연결의 유효 상태는 변경되지 않습니다.

로컬 피어링 구성이 업데이트된 후 초기 업데이트가 수락되거나 취소될 때까지 연결의 어느 한쪽에서도 추가 업데이트 요청을 제출할 수 없습니다. 부분 업데이트는 지원되지 않습니다. 요청에서 여러 매개변수를 업데이트하는 경우 모든 매개변수를 수락하거나 취소해야 합니다. 업데이트를 취소하려면 요청 네트워크에서 수정된 각 매개변수를 이전 값으로 재설정합니다.

다음 다이어그램은 업데이트 요청이 제출될 때 피어링 연결의 상태가 변경되는 방식을 보여줍니다.

합의 모드에서 피어링 연결 업데이트
합의 모드로 피어링 연결 업데이트 (확대하려면 클릭)

위 다이어그램에서 네트워크 A가 업데이트 요청을 제출하면 연결의 업데이트 상태가 로컬 구성에서 IN_SYNC에서 PENDING_PEER_ACKNOWLEDGMENT로, 피어 구성에서 PENDING_LOCAL_ACKNOWLEDGMENT로 변경됩니다.

IN_SYNC 상태로 돌아가려면 네트워크 B에서 보완 변경을 적용하거나 네트워크 A에서 요청을 취소해야 합니다. 이러한 연결 상태에 대한 자세한 내용은 연결 상태를 참조하세요.

피어링 연결을 업데이트하려면 연결 업데이트 (합의 모드)를 참조하세요.

합의 모드로 연결 삭제

합의 모드로 피어링 연결을 삭제하려면 연결의 양쪽에서 삭제 요청을 제출해야 합니다. 피어 네트워크에서 삭제 요청을 수락하기 전이나 후에 취소할 수 있습니다.

삭제 요청에는 다음 조건이 적용됩니다.

  • 업데이트 요청이 보류 중인 경우에도 피어링 연결을 삭제할 수 있습니다.
  • 삭제 요청이 보류 중이면 보류 중인 업데이트 수락 또는 취소를 포함한 모든 업데이트 요청이 거부됩니다. 보류 중인 업데이트를 완료하려면 먼저 삭제 요청을 취소해야 합니다.

자세한 내용은 연결 삭제 (합의 모드)를 참조하세요.

연결 상태

gcloud compute networks describe 명령어 는 피어링 연결의 유효 상태와 로컬 피어링 구성을 모두 보여줍니다.

peerings.connectionStatus 필드를 검사하여 유효한 연결 상태를 볼 수 있습니다. 다음 표에서는 사용 가능한 구성 상태를 설명합니다. 체크표시는 필드를 사용할 수 있음을 나타냅니다.

필드 독립 모드 합의 모드 설명
trafficConfiguration 피어링 연결의 유효한 경로 교환 옵션 을 보여줍니다.
updateStrategy 유효한 연결 모드(INDEPENDENT 또는 CONSENSUS)를 보여줍니다.
consensusState.deleteStatus
  • UNSPECIFIED: 이 피어링 연결에 대해 보류 중인 requestRemovePeering 요청이 없습니다. 상태가 UNSPECIFIED이면 deleteStatus 필드가 출력에 표시되지 않습니다.
  • LOCAL_DELETE_REQUESTED: 이 피어링의 소유자가 피어링 연결 삭제를 요청했습니다.
  • PEER_DELETE_REQUESTED: 일치하는 피어링의 소유자가 피어링 연결 삭제를 요청했습니다.
  • DELETE_ACKNOWLEDGED: 이 연결의 두 피어링 소유자가 피어링 연결 삭제를 요청했습니다. 이후 removePeering 요청은 어느 피어링에서든 성공합니다.
  • LOCAL_CANCEL_REQUESTED: 피어링 연결이 DELETE_ACKNOWLEDGED 상태였지만 로컬 네트워크에서 삭제를 취소했습니다.
  • PEER_CANCEL_REQUESTED: 피어링 연결이 DELETE_ACKNOWLEDGED 상태였지만 피어 네트워크에서 삭제를 취소했습니다.
consensusState.updateStatus
  • IN_SYNC: 피어링 소유자 모두 보류 중인 업데이트가 없습니다.
  • PENDING_PEER_ACKNOWLEDGMENT: 로컬 피어링 소유자가 변경했지만 일치하는 피어링 소유자가 피어링에 상응하는 변경사항을 적용하지 않았습니다.
  • PENDING_LOCAL_ACKNOWLEDGMENT: 일치하는 피어링 소유자가 변경했지만 로컬 피어링 소유자가 이 피어링에 상응하는 변경사항을 적용하지 않았습니다.

프로젝트의 모든 피어링 구성을 나열하려면 피어링 연결 나열을 참조하세요. Google Cloud

다음 단계