이 주제에서는 Microsoft® Azure Kubernetes Service(AKS)에서 Apigee Hybrid의 멀티 리전 배포를 설정하는 방법을 설명합니다.
멀티 리전 배포를 위한 토폴로지는 다음과 같습니다.
- 활성-활성: 애플리케이션이 여러 지리적 위치에 배포되고 배포에 대한 지연 시간이 짧은 API 응답이 필요한 경우. 클라이언트와 가장 가까운 여러 지리적 위치에 하이브리드를 배포할 수 있는 옵션이 있습니다. 예를 들면 미국 서부 해안, 미국 동부 해안, 유럽, APAC이 있습니다.
- 활성-수동: 기본 리전과 장애 조치 또는 재해 복구 리전이 있는 경우.
다음 이미지와 같이 멀티 리전 하이브리드 배포의 리전은 Cassandra를 통해 통신합니다.
기본 요건
여러 지역에 하이브리드를 구성하기 전에 다음 기본 요건을 만족해야 합니다.
- 클러스터 설정 단계로 이동하기 전에 GCP 및 조직 구성과 같은 기본 요건을 충족을 위해 하이브리드 설치 가이드를 따르세요.
자세한 내용은 Kubernetes 문서를 참조하세요.
각 리전에 가상 네트워크 만들기
멀티 리전 배포를 위한 가상 네트워크를 만듭니다. 예를 들어 다음 예시 명령어는 미국 중부 및 미국 동부 리전에 네트워크를 만듭니다.
다음 명령어를 실행하여 미국 동부 리전에 이름이 my-hybrid-rg-vnet인 가상 네트워크를 만듭니다.
az network vnet create \ --name my-hybrid-rg-vnet \ --location eastus \ --resource-group my-hybrid-rg \ --address-prefixes 120.38.1.0/24 \ --subnet-name my-hybrid-rg-vnet-subnet \ --subnet-prefix 120.38.1.0/26
다음 명령어를 실행하여 미국 중부 리전에 이름이 my-hybrid-rg-vnet-ext01인 가상 네트워크를 만듭니다.
az network vnet create \ --name my-hybrid-rg-vnet-ext01 \ --location centralus \ --resource-group my-hybrid-rg \ --address-prefixes 192.138.0.0/24 \ --subnet-name my-hybrid-rg-vnet-ext01-subnet \ --subnet-prefix 192.138.0.0/26
네트워크 피어링 만들기
가상 네트워크 간에 네트워크 피어링을 만듭니다.
가상 네트워크 ID 가져오기
피어링은 가상 네트워크 ID 간에 설정됩니다. az network vnet show 명령어로 각 가상 네트워크의 ID를 가져오고 변수에 이 ID를 저장합니다.
이름이 my-hybrid-rg-vnet인 첫 번째 가상 네트워크의 ID를 가져옵니다.
vNet1Id=$(az network vnet show \ --resource-group my-hybrid-rg \ --name my-hybrid-rg-vnet \ --query id --out tsv)
이름이 my-hybrid-rg-vnet-ext01인 두 번째 가상 네트워크의 ID를 가져옵니다.
vNet2Id=$(az network vnet show \ --resource-group my-hybrid-rg \ --name my-hybrid-rg-vnet-ext01 \ --query id \ --out tsv)
첫 번째 가상 네트워크에서 두 번째 가상 네트워크로 피어링 만들기
가상 네트워크 ID를 사용하면 다음 예시와 같이 첫 번째 가상 네트워크(my-hybrid-rg-vnet)에서 두 번째 가상 네트워크(my-hybrid-rg-vnet-ext01)로 피어링을 만들 수 있습니다.
az network vnet peering create \ --name my-hybrid-rg-vnet1-peering \ # The name of the virtual network peering. --resource-group my-hybrid-rg \ --vnet-name my-hybrid-rg-vnet \ # The virtual network name. --remote-vnet $vNet2Id \ # Resource ID of the remote virtual network. --allow-vnet-access
명령어 출력에서 peeringState가 Initiated임에 유의하세요.
두 번째 가상 네트워크에서 첫 번째 가상 네트워크로 피어링을 만들 때까지 피어링은 Initiated 상태로 유지됩니다.
{
...
"peeringState": "Initiated",
...
}
두 번째 가상 네트워크에서 첫 번째 가상 네트워크로 피어링 만들기
명령어 예시:
az network vnet peering create \ --name my-hybrid-rg-vnet2-peering \ # The name of the virtual network peering. --resource-group my-hybrid-rg \ --vnet-name my-hybrid-rg-vnet-ext01 \ # The virtual network name. --remote-vnet $vNet1Id \ # Resource ID of the remote virtual network. --allow-vnet-access
명령어 출력에서 peeringState가 Connected임에 유의하세요. 또한 Azure는 첫 번째에서 두 번째 가상 네트워크 피어링의 피어링 상태를 Connected로 변경합니다.
{
...
"peeringState": "Connected",
...
}
my-hybrid-rg-vnet1-peering에서 my-hybrid-rg-vnet2-peering로의 피어링 상태도 확인할 수 있습니다. 피어링이 다음 명령어로 Connected로 변경되었습니다.
az network vnet peering show \ --name my-hybrid-rg-vnet1-peering \ --resource-group my-hybrid-rg \ --vnet-name my-hybrid-rg-vnet \ --query peeringState
예상 출력:
Connected
다중 리전 클러스터 만들기
여러 가지 CIDR 블록을 사용하여 여러 리전에 Kubernetes 클러스터를 설정합니다. 1단계: 클러스터 만들기도 참조하세요. 앞에서 만든 위치 및 가상 네트워크 이름을 사용합니다.
모든 리전의 Kubernetes 클러스터 간에 Cassandra 포트 7000과 7001을 엽니다(7000은 문제 해결 중에 백업 옵션으로 사용할 수 있음).
멀티 리전 시드 호스트 구성
이 섹션에서는 기존 Cassandra 클러스터를 새 리전으로 확장하는 방법을 설명합니다. 이 설정을 사용하면 새 리전에서 클러스터를 부트스트랩하고 기존 데이터 센터에 연결할 수 있습니다. 이 구성이 없으면 멀티 리전 Kubernetes 클러스터가 서로를 알지 못합니다.
- kubectl 컨텍스트를 원래 클러스터로 설정한 후에 시드 이름을 검색합니다.
kubectl config use-context original-cluster-name
다음
kubectl명령어를 실행하여 현재 리전의 Cassandra의 시드 호스트 주소를 식별합니다.시드 호스트 주소를 사용하면 새 리전 인스턴스가 첫 번째 시작할 때 원래의 클러스터를 찾아 클러스터의 토폴로지를 학습할 수 있습니다. 시드 호스트 주소는 클러스터의 연락 지점으로 지정됩니다.
kubectl get pods -o wide -n apigee | grep apigee-cassandra apigee-cassandra-default-0 1/1 Running 0 4d17h 120.38.1.9 aks-agentpool-21207753-vmss000000
- 이전 명령어에서 반환된 IP 중 멀티 리전 시드 호스트가 될 IP를 결정합니다. 단일 노드 Cassandra 클러스터만 실행 중인 이 예시의 경우 시드 호스트는
120.38.1.9입니다. - 데이터 센터 2에서 클러스터 이름이 포함된 새 파일에 재정의 파일을 복사합니다. 예를 들면
overrides_your_cluster_name.yaml입니다. - 데이터 센터 2에서
overrides_your_cluster_name.yaml의cassandra.multiRegionSeedHost및cassandra.datacenter를 구성합니다. 여기서multiRegionSeedHost는 이전 명령어에서 반환한 IP 중 하나입니다.cassandra: multiRegionSeedHost: seed_host_IP datacenter: data_center_name rack: rack_name
예를 들면 다음과 같습니다.
cassandra: multiRegionSeedHost: 120.38.1.9 datacenter: "centralus" rack: "ra-1"
- 새 데이터 센터/리전에서 하이브리드를 설치하기 전에 첫 번째 리전에서 설정한 것과 동일하게 TLS 인증서 및 사용자 인증 정보를
overrides_your_cluster_name.yaml에 설정합니다.
새 리전 설정
시드 호스트를 구성한 후에 새 리전을 설정할 수 있습니다.
새 리전을 설정 절차:
- 기존 클러스터에서 새 클러스터로 인증서를 복사합니다. 새 CA 루트는 Cassandra 및 mTLS용 기타 하이브리드 구성요소에서 사용됩니다. 따라서 클러스터 간에 일관된 인증서가 있어야 합니다.
- 컨텍스트를 원래 네임스페이스로 설정합니다.
kubectl config use-context original-cluster-name
- 현재 네임스페이스 구성을 파일로 내보냅니다.
$ kubectl get namespace namespace -o yaml > apigee-namespace.yaml
apigee-ca보안 비밀을 파일로 내보냅니다.kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
- 컨텍스트를 새 리전의 클러스터 이름으로 설정합니다.
kubectl config use-context new-cluster-name
- 네임스페이스 구성을 새 클러스터로 가져옵니다.
새 리전에서 다른 네임스페이스를 사용하는 경우 파일의 '네임스페이스'를 업데이트해야 합니다.
kubectl apply -f apigee-namespace.yaml
보안 비밀을 새 클러스터로 가져옵니다.
kubectl -n cert-manager apply -f apigee-ca.yaml
- 컨텍스트를 원래 네임스페이스로 설정합니다.
- 새 리전에 하이브리드를 설치합니다. 이전 섹션에 설명된 대로
overrides_your_cluster_name.yaml파일에 첫 번째 리전에서 구성된 동일한 TLS 인증서가 포함되어 있는지 확인합니다.다음 두 명령어를 실행하여 새 리전에 하이브리드를 설치합니다.
apigeectl init -f overrides_your_cluster_name.yaml
apigeectl apply -f overrides_your_cluster_name.yaml
- 새 데이터 센터의 모든 노드에서
nodetool rebuild를 순차적으로 실행합니다. 데이터 크기에 따라 몇 분에서 몇 시간 정도 걸릴 수 있습니다.kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool -u JMX_user -pw JMX_password rebuild -- dc-1
여기서 JMX_user 및 JMX_password는 Cassandra JMX 사용자의 사용자 이름과 비밀번호입니다.
- 로그에서 재빌드 프로세스를 확인합니다. 또한
nodetool status명령어를 사용하여 데이터 크기를 확인합니다.kubectl logs apigee-cassandra-default-0 -f -n apigee
kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool -u JMX_user -pw JMX_password status
다음 예시는 로그 항목의 예시를 보여줍니다.
INFO 01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens) INFO 01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild INFO 01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB) INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36 INFO 01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22 INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB) INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22 INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB) INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete INFO 01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed
- 시드 호스트를 업데이트합니다.
overrides-DC_name.yaml에서multiRegionSeedHost: 10.0.0.11을 삭제하고 다시 적용합니다.apigeectl apply -f overrides-DC_name.yaml