메시 게이트웨이를 통한 WAN 페더레이션 활성화

메시 게이트웨이를 통한 WAN 페더레이션 활성화 (Meshed WAN federation)

메시 게이트웨이를 통해 WAN 페더레이션을 활성화하는 방법을 설명하는 문서예요. 서로 다른 데이터센터의 Consul 서버들이 메시 게이트웨이만으로 페더레이션되도록 할 수 있어요.

출처: 문서

본문

참고 1.8.0+: 이 기능은 Consul 버전 1.8.0 이상에서 사용할 수 있어요.

참고 이 주제는 메시 게이트웨이에 대한 이해가 필요해요.

메시 게이트웨이를 통한 WAN 페더레이션은 서로 다른 데이터센터의 Consul 서버가 메시 게이트웨이를 통해서만 페더레이션되도록 해줘요.

멀티 데이터센터 Consul 클러스터를 설정할 때 운영자는 모든 데이터센터의 모든 Consul 서버가 서로의 WAN 광고 네트워크 주소로 직접 연결 가능해야 한다는 점을 보장해야 해요.

이미지: WAN 페더레이션 연결성(전통적 방식)

이를 위해서는 서버를 호스팅하는 가상 머신이나 컨테이너를 설정하는 운영자가 서버들이 WAN을 통해 서로 통신할 수 있도록 필요한 라우팅 및 방화벽 규칙을 마련하기 위한 추가 단계를 수행해야 해요.

때로는 이 사전 요구 사항을 충족하기 어렵거나 바람직하지 않을 수 있어요:

어려운 경우: 데이터센터가 여러 Kubernetes 클러스터에 존재하면서 파드 IP 서브넷이 겹치거나, 서로 다른 클라우드 제공자 VPC에 존재하면서 서브넷이 겹칠 수 있어요.
바람직하지 않은 경우: 네트워크 보안 팀이 많은 방화벽 규칙을 승인하지 않을 수 있어요. 플랫폼 자동 확장을 사용할 때 규칙을 최신 상태로 유지하는 것이 불가능해져요.

WAN 배포를 단순화하고 노출된 보안 표면을 최소화하려는 운영자는 메시 게이트웨이를 사용해 이 데이터센터들을 함께 조인하도록 선택할 수 있어요.

이미지: WAN 페더레이션 연결성(메시 게이트웨이)

아키텍처 (Architecture)

서로 다른 Consul 데이터센터 사이의 경계를 가로지르는 WAN 링크를 통해 발생하는 통신에는 두 가지 주요 종류가 있어요:

WAN gossip: 우리는 serf와 memberlist 라이브러리를 활용해 각 데이터센터의 Consul 서버에 대한 장애 감지 정보를 가십(gossip)으로 전파해요. 기본적으로 이는 서버 간에 8302/udp로 점대점(point to point) 동작하며, 8302/tcp로 폴백돼요(네트워크가 잘못 구성되었음을 알리는 경고를 로그에 남김).
교차 데이터센터 RPC: Consul 서버는 8300/tcp에 특수한 다중화(multiplexed) 포트를 노출해요. 이 포트에서는 다른 데이터센터의 서버에서 전달된 RPC 요청과 같은 몇 가지 서로 다른 종류의 메시지를 받을 수 있어요.

이 네트워크 토폴로지에서 한 데이터센터의 LAN에 있는 개별 Consul 클라이언트 에이전트는 다른 데이터센터의 서버에 직접 다이얼할 필요가 없어요. 즉 보안 격리를 위해 10.0.0.0/24가 10.1.2.0/24로 어떤 트래픽도 보내지 못하게 하는 일련의 방화벽 규칙을 도입할 수 있다는 뜻이에요.

이미 메시 게이트웨이를 구성해 Consul 클라이언트 에이전트를 호스팅하는 노드의 측면(lateral) 연결성과 관계없이 서비스 메시의 서비스가 데이터센터 간에 자유롭게 연결되도록 했을 수도 있어요.

메시 게이트웨이를 통한 WAN 페더레이션을 활성화하면 서버들도 직접 연결이 가능하지 않더라도 기존 메시 게이트웨이를 사용해 서로에게 도달할 수 있어요.

구성 (Configuration)

TLS

모든 데이터센터의 모든 Consul 서버는 다음 SAN 필드가 포함된 인증서로 TLS가 구성되어야 해요:

server.<this_datacenter>.<domain>              (normal)
<node_name>.server.<this_datacenter>.<domain>  (needed for wan federation)

이는 -node 플래그가 있는 consul tls cert create를 포함한 다양한 도구로 달성할 수 있어요.

메시 게이트웨이 (Mesh Gateways)

구성에서 서버 노출에 옵트인하도록 구성된 메시 게이트웨이가 최소 하나 있어야 해요. consul connect envoy CLI를 사용할 때는 -expose-servers 플래그로 이 작업을 수행해요. 이는 {"consul-wan-federation":"1"}이라는 서비스 메타데이터를 추가로 포함해 메시 게이트웨이를 카탈로그에 등록할 뿐이에요. 메시 게이트웨이를 대역 외(out of band)로 카탈로그에 등록한다면 기존 등록 페이로드에 이것을 추가하면 돼요.

참고 기존 클러스터에서 이 기능을 활성화하기 전에 각 데이터센터에 등록된 서버를 노출할 준비가 된 메시 게이트웨이가 최소 하나 있는지 확인해야 해요. 그렇지 않으면 WAN이 부분적으로만 연결되게 돼요.

Consul 서버 옵션 (Consul Server Options)

멀티 데이터센터 Consul 클러스터를 구축하는 데 필요한 것 외에 몇 가지 필요한 추가 구성이 있어요.

기본(primary) 데이터센터의 Consul 서버는 구성 파일에 이 스니펫을 추가해야 해요:

connect {
  enabled = true
  enable_mesh_gateway_wan_federation = true
}

모든 보조(secondary) 데이터센터의 Consul 서버는 구성 파일에 이 스니펫을 추가해야 해요:

primary_gateways = [ "<primary-mesh-gateway-ip>:<primary-mesh-gateway-port>", ... ]
connect {
  enabled = true
  enable_mesh_gateway_wan_federation = true
}

retry_join_wan 주소는 전통적인 페더레이션 프로세스에만 사용돼요. 게이트웨이를 통해 Consul 서버를 페더레이션할 때는 생략해야 해요.

참고 primary_gateways 구성은 retry_join_wan처럼 go-discover 구문도 사용할 수 있어요.

부트스트래핑 (Bootstrapping)

디버깅을 쉽게 하기 위해(예: 오해의 소지가 있는 오류 메시지가 쏟아지는 것을 피하려고) 메시 게이트웨이를 통한 WAN 페더레이션을 활성화하려 할 때는 다음 일반 절차를 따르는 것이 좋아요:

새 보조 데이터센터 (New secondary)

모든 서버, 클라이언트, CLI에 대해 원하는 버전의 consul 바이너리로 업그레이드한다.
기본 데이터센터에서 새 버전의 모든 consul 서버와 클라이언트를 시작한다.
기본 데이터센터에 서비스 메타데이터 키 {"consul-wan-federation":"1"}가 설정된 실행 중이며 등록된 메시 게이트웨이가 최소 하나 있는지 확인한다.
모든 보조 데이터센터에서 해당 메시 게이트웨이를 시작할 준비가 되어 있는지 확인한다. ACL이 활성화되면 실제로 이를 등록하려면 카탈로그 등록을 승인하기 위해 기본 데이터센터에 대한 업스트림 연결이 필요하다.
기본 데이터센터의 모든 서버가 업데이트된 구성을 갖고 있는지 확인하고 재시작한다.
보조 데이터센터의 모든 서버가 업데이트된 구성을 갖고 있는지 확인한다.
보조 데이터센터에서 새 버전의 모든 consul 서버와 클라이언트를 시작한다.
ACL이 활성화되면 잠시 후 보조 데이터센터에서 ACL 토큰을 해석할 수 있게 되어야 하며, 그때 보조 데이터센터에서 메시 게이트웨이를 시작할 수 있어야 한다.

기존 보조 데이터센터 (Existing secondary)

모든 서버, 클라이언트, CLI에 대해 원하는 버전의 consul 바이너리로 업그레이드한다.
새 버전으로 모든 consul 서버와 클라이언트를 재시작한다.
각 데이터센터에 서비스 메타데이터 키 {"consul-wan-federation":"1"}가 설정된 실행 중이며 등록된 메시 게이트웨이가 최소 하나 있는지 확인한다.
기본 데이터센터의 모든 서버가 업데이트된 구성을 갖고 있는지 확인하고 재시작한다.
보조 데이터센터의 모든 서버가 업데이트된 구성을 갖고 있는지 확인하고 재시작한다.

확인 (Verification)

함께 조인된 임의의 두 데이터센터에서 다음이 예상 결과를 주는지 이중으로 확인해요:

consul members -wan이 모든 데이터센터의 모든 서버를 로컬 IP 주소로 나열하고 alive로 표시하는지 확인한다.
/v1/catalog/services?dc=<OTHER_DATACENTER_NAME>과 같이 데이터센터 요청 전달을 활성화하는 모든 API 요청이 성공하는지 확인한다.

기본 게이트웨이 업그레이드 (Upgrading the primary gateways)

페더레이션이 수립되면 보조 데이터센터는 기본 데이터센터에서 업데이트된 메시 게이트웨이 주소를 지속적으로 요청해요. Consul은 요청을 기본 데이터센터의 메시 게이트웨이를 통해 라우팅해요. 보조 데이터센터는 기본 데이터센터의 Consul 서버에 직접 다이얼할 수 없기 때문이에요. 기본 게이트웨이가 업그레이드되고, 업데이트가 전파되기 전에 이전 인스턴스가 해제되면 기본 데이터센터에 연결할 수 없게 돼요.

기본 게이트웨이를 안전하게 업그레이드하려면 다음 정책 중 하나를 적용할 것을 권장해요:

기본 게이트웨이 IP 주소를 해제하지 않는 것. 보조 서버에 구성된 primary_gateways 주소가 기본 데이터센터와의 연결을 재수립하는 폴백 메커니즘 역할을 하기 때문이에요.
기본의 기존 메시 게이트웨이를 해제하기 전에 기본의 새 메시 게이트웨이 주소가 보조 데이터센터에 전파되었는지 확인한다.

메시 게이트웨이를 통한 WAN 페더레이션 활성화