다음을 통해 공유

자습서: 고가용성 및 재해 복구를 사용하여 WebSphere Liberty/Open Liberty를 AKS(Azure Kubernetes Service)로 마이그레이션

  • 아티클

이 자습서에서는 AKS(Azure Kubernetes Service)에서 WebSphere Liberty/Open Liberty를 사용하여 Java용 HA/DR(고가용성 및 재해 복구)을 구현하는 간단하고 효과적인 방법을 보여 줍니다. 이 솔루션은 WebSphere Liberty/Open Liberty에서 실행되는 간단한 데이터베이스 기반 Jakarta EE 애플리케이션을 사용하여 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)를 달성하는 방법을 보여 줍니다.

HA/DR은 여러 가지 가능한 솔루션을 갖춘 복잡한 주제입니다. 최상의 솔루션은 고유한 요구 사항에 따라 달라집니다. HA/DR을 구현하는 다른 방법은 이 문서의 끝에 있는 리소스를 참조하세요.

이 자습서에서는 다음을 하는 방법을 알아볼 수 있습니다.

  • Azure 최적화 모범 사례를 사용하여 고가용성 및 재해 복구를 달성합니다.
  • 쌍을 이루는 지역에서 Microsoft Azure SQL Database 장애 조치(failover) 그룹을 설정합니다.
  • AKS에서 기본 WebSphere Liberty/Open Liberty 클러스터를 설정합니다.
  • Azure Backup을 사용하여 클러스터에 대한 재해 복구를 설정합니다.
  • 보조 AKS 클러스터를 설정합니다.
  • Azure Traffic Manager를 설정합니다.
  • 기본에서 보조로 장애 조치(failover)를 테스트합니다.

다음 다이어그램에서는 빌드하는 아키텍처를 보여 줍니다.

고가용성 및 재해 복구를 사용하는 AKS의 WebSphere Liberty/Open Liberty 솔루션 아키텍처 다이어그램

Azure Traffic Manager는 지역 상태를 확인하고 그에 따라 트래픽을 애플리케이션 계층으로 라우팅합니다. 주 지역과 보조 지역 모두 Liberty 클러스터의 전체 배포가 있습니다. 그러나 주 지역만 사용자의 네트워크 요청을 적극적으로 서비스합니다. 보조 지역은 수동이며 주 지역에서 서비스 중단이 발생하는 경우에만 트래픽을 수신하도록 활성화됩니다. Azure Traffic Manager는 Azure 애플리케이션 Gateway의 상태 검사 기능을 사용하여 이 조건부 라우팅을 구현합니다. 주 클러스터가 실행되고 보조 클러스터가 종료됩니다. 애플리케이션 계층의 지역 장애 조치 RTO는 VM(가상 머신)을 시작하고 보조 클러스터를 실행하는 시간에 따라 달라집니다. 데이터가 Azure SQL Database 장애 조치(failover) 그룹에 유지되고 복제되기 때문에 RPO는 Azure SQL Database에 따라 달라집니다.

데이터베이스 계층은 주 서버와 보조 서버가 있는 Azure SQL Database 장애 조치(failover) 그룹으로 구성됩니다. 읽기/쓰기 수신기 엔드포인트는 항상 주 서버를 가리키며 각 지역의 WebSphere Liberty/Open Liberty 클러스터에 연결됩니다. 지역 장애 조치(failover)는 그룹의 모든 보조 데이터베이스를 주 역할로 전환합니다. Azure SQL Database의 지역 장애 조치(failover) RPO 및 RTO는 Azure SQL Database를 사용한 비즈니스 연속성 개요를 참조하세요.

이 자습서는 이러한 서비스의 HA 기능을 사용하므로 Azure Backup 및 Azure SQL Database 서비스를 사용하여 작성되었습니다. 다른 데이터베이스 선택도 가능하지만 선택한 데이터베이스의 HA 기능을 고려해야 합니다.

필수 구성 요소

  • Azure 구독 Azure 구독이 아직 없는 경우 시작하기 전에 체험 계정을 만듭니다.
  • 구독에서 Owner 역할이나 Contributor 및 User Access Administrator 역할이 할당되어 있는지 확인합니다. Azure Portal을 사용하여 Azure 역할 할당 나열의 단계에 따라 할당을 확인할 수 있습니다.
  • Windows, Linux 또는 macOS가 설치된 로컬 컴퓨터를 준비합니다.
  • Azure CLI 2.62.0 이상을 설치하여 Azure CLI 명령을 실행합니다.
    • az login 명령을 사용하여 Azure CLI로 로그인합니다. 인증 프로세스를 완료하려면 터미널에 표시되는 단계를 수행합니다. 다른 로그인 옵션은 Azure CLI사용하여 Azure에 로그인을 참조하세요.
    • 메시지가 표시되면 처음 사용할 때 Azure CLI 확장을 설치합니다. 확장에 대한 자세한 내용은 Azure CLI사용하여 확장 사용 및 관리를 참조하세요.
    • az version 실행하여 설치된 버전 및 종속 라이브러리를 찾아보세요. 최신 버전으로 업그레이드하려면 az upgrade실행합니다.
  • Git을 설치하고 설정합니다.
  • Java SE 구현 버전 17 이상을 설치합니다(예: OpenJDK의 Microsoft 빌드).
  • Maven 버전 3.9.3 이상을 설치합니다.

쌍을 이루는 지역에서 Azure SQL Database 장애 조치(failover) 그룹 설정

이 섹션에서는 WebSphere Liberty/Open Liberty 클러스터 및 앱과 함께 사용할 쌍을 이루는 지역에 Azure SQL Database 장애 조치(failover) 그룹을 만듭니다. 이후 섹션에서는 세션 데이터를 이 데이터베이스에 저장하도록 WebSphere Liberty/Open Liberty를 구성합니다. 이 연습에서는 세션 지속성을 위한 테이블 만들기를 참조합니다.

먼저 빠른 시작: 단일 데이터베이스 만들기 - Azure SQL Database의 Azure Portal 단계에 따라 기본 Azure SQL Database를 만듭니다. "리소스 정리" 섹션을 포함하지만 포함하지 않는 단계를 수행합니다. 문서를 진행할 때 다음 지침을 사용한 다음, Azure SQL Database를 만들고 구성한 후 이 문서로 돌아갑니다.

단일 데이터베이스 만들기 섹션에 도달하면 다음 단계를 사용합니다.

  1. 새 리소스 그룹을 만들기 위한 4단계에서 리소스 그룹 이름myResourceGroup따로 저장합니다.
  2. 데이터베이스 이름에 대한 5단계에서 데이터베이스 이름mySampleDatabase따로 저장합니다.
  3. 서버를 만들기 위한 6단계에서 다음 단계를 사용합니다.
    1. 고유한 서버 이름(예: sqlserverprimary-mjg032524.)을 입력합니다.
    2. 위치의 경우 (미국) 미국 동부를 선택합니다.
    3. 인증 방법의 경우 SQL 인증 사용을 선택합니다.
    4. 서버 관리자 로그인azureuser따로 저장합니다.
    5. 암호 값을 따로 저장합니다.
  4. 8단계에서 워크로드 환경의 경우 개발을 선택합니다. 설명을 살펴보고 워크로드에 대한 다른 옵션을 고려합니다.
  5. 11단계에서 Backup 스토리지 중복성에 대해 로컬 중복 백업 스토리지를 선택합니다. 백업에 대한 다른 옵션을 고려합니다. 자세한 내용은 Azure SQL Database에서 자동화된 백업의 Backup 스토리지 중복성 섹션을 참조하세요.
  6. 14단계의 방화벽 규칙 구성에서 Azure 서비스 및 리소스가 이 서버에 액세스하도록 허용하려면 [예]를 선택합니다.

그런 다음, Azure SQL Database에 대한 장애 조치(failover) 그룹 구성의 Azure Portal 단계에 따라 Azure SQL Database 장애 조치(failover) 그룹을 만듭니다. 장애 조치(failover) 그룹 만들기 및 테스트 계획된 장애조치 섹션만 있으면 됩니다. 문서를 진행하면서 다음 단계를 수행한 다음, Azure SQL Database 장애 조치(failover) 그룹을 만들고 구성한 후 이 문서로 돌아갑니다.

  1. 장애 조치(failover) 그룹 만들기 섹션에 도달하면 다음 단계를 사용합니다.

    1. 장애 조치(failover) 그룹을 만들기 위한 5단계에서 고유한 장애 조치(failover) 그룹 이름(예 failovergroup-mjg032524: )을 입력하고 저장합니다.
    2. 서버를 구성하기 위한 5단계에서 새 보조 서버를 만드는 옵션을 선택한 다음, 다음 단계를 사용합니다.
      1. 고유한 서버 이름(예: .) sqlserversecondary-mjg032524을 입력합니다.
      2. 주 서버와 동일한 서버 관리자 및 암호를 입력합니다.
      3. 위치의 경우 (미국) 미국 서부를 선택합니다.
      4. Azure 서비스에서 서버에 액세스하도록 허용이 선택되어 있는지 확인합니다.
    3. 그룹 내의 데이터베이스를 구성하기 위한 5단계에서 주 서버에서 만든 데이터베이스(예: mySampleDatabase)를 선택합니다.

  2. 테스트 계획된 장애조치 섹션의 모든 단계를 완료한 후 장애 조치(failover) 그룹 페이지를 열어 두고 나중에 WebSphere Liberty/Open Liberty 클러스터의 장애 조치(failover) 테스트에 사용합니다.

참고 항목

이 문서에서는 이 문서에 중점을 둔 HA/DR 설정이 이미 매우 복잡하기 때문에 단순성을 위해 SQL 인증을 사용하여 Azure SQL Database 단일 데이터베이스를 만드는 방법을 안내합니다. 더 안전한 방법은 데이터베이스 서버 연결을 인증하기 위해 Azure SQL Microsoft Entra 인증을 사용하는 것입니다. Microsoft Entra 인증을 사용하여 데이터베이스 연결을 구성하는 방법에 대한 자세한 내용은 AKS(Azure Kubernetes Service) 클러스터Open Liberty 또는 WebSphere Liberty를 사용하여 Java 애플리케이션 배포를 참조하세요.

AKS에서 기본 WebSphere Liberty/Open Liberty 클러스터 설정

이 섹션에서는 IBM WebSphere Liberty 및 Open Liberty on Azure Kubernetes Service 제품을 사용하여 AKS에서 기본 WebSphere Liberty/Open Liberty 클러스터를 만듭니다. 보조 클러스터는 나중에 Azure Backup을 사용하여 장애 조치(failover) 중에 주 클러스터에서 복원됩니다.

기본 WebSphere Liberty/Open Liberty 클러스터 배포

다음 단계를 사용하여 주 클러스터를 배포합니다.

  1. 브라우저에서 IBM WebSphere Liberty and Open Liberty on Azure Kubernetes Service 제품을 열고 만들기를 선택합니다. 제품의 기본 창이 표시됩니다.

  2. 다음 단계를 사용하여 기본 사항 창을 작성 합니다 .

    1. 구독에 대해 표시된 값이 필수 구성 요소 섹션에 나열된 역할이 있는 값과 동일한지 확인합니다.
    2. 빈 리소스 그룹에 제품을 배포해야 합니다. 리소스 그룹 필드에서 새로liberty-aks-eastus-mjg032524).
    3. 인스턴스 세부 정보에서 지역에 대해 미국 동부를 선택합니다.
    4. 다음을 선택하여 AKS 창으로 이동합니다.

    Azure Kubernetes Service Basics 창에서 IBM WebSphere Liberty 및 Open Liberty를 보여 주는 Azure Portal의 스크린샷

  3. 잠시 기다립니다. AKS 창에 기본값으로 미리 채워진 모든 필드가 표시됩니다. 다음을 선택하여 부하 분산 창으로 이동합니다.

    Azure Kubernetes Service AKS 창에서 IBM WebSphere Liberty 및 Open Liberty를 보여 주는 Azure Portal의 스크린샷.

  4. 다음 단계를 사용하여 부하 분산 창을 작성합니다.

    1. Azure 애플리케이션 게이트웨이에 연결하려면 [예]를 선택합니다.
    2. 다른 필드의 기본값을 그대로 둡니다.
    3. [다음]을 선택하여 연산자 및 애플리케이션 창으로 이동합니다.

    Azure Kubernetes Service 부하 분산 창에서 IBM WebSphere Liberty 및 Open Liberty를 보여 주는 Azure Portal의 스크린샷.

  5. 다음 단계를 사용하여 운영자 및 애플리케이션 창을 작성합니다.

    1. 모든 필드에 대한 기본값을 그대로 둡니다.

      참고 항목

      이 자습서에서는 기본값을 사용하여 Open Liberty Operator를 배포합니다. 필요에 따라 지원되는 IBM에 대해 예를 선택하여 WebSphere Liberty Operator를 배포할 수 있습니다.

    2. 검토 + 만들기를 선택합니다.

    3. 최종 유효성 검사 실행이 완료될 때까지 기다린 다음 만들기를 선택합니다.

    Azure Kubernetes Service 운영자 및 애플리케이션 창에서 IBM WebSphere Liberty 및 Open Liberty를 보여 주는 Azure Portal의 스크린샷.

잠시 후 배포가 진행 중인 배포 페이지가 표시됩니다.

참고 항목

최종 유효성 검사를 실행하는 동안 문제가 표시되는 경우 문제를 해결한 후 다시 시도하세요.

선택한 지역의 네트워크 조건 및 기타 활동에 따라 배포를 완료하는 데 최대 30분이 걸릴 수 있습니다. 그런 다음 배포가 완료됨이라는 텍스트가 배포 페이지에 표시됩니다.

클러스터 배포 확인

AKS 클러스터, ACR(Azure Container Registry) 인스턴스 및 주 지역에 Azure 애플리케이션 게이트웨이를 배포했습니다. AKS 클러스터는 앱이 배포되고 실행되는 대상 컴퓨팅 플랫폼입니다. ACR 인스턴스는 앱 배포 중에 AKS가 가져오는 애플리케이션 이미지를 저장합니다. Azure 애플리케이션 게이트웨이는 AKS 클러스터에 배포된 애플리케이션에 대한 부하 분산 장치 역할을 합니다.

다음 단계로 이동하기 전에 다음 단계를 사용하여 이러한 주요 구성 요소를 확인합니다.

  1. 배포 페이지로 돌아가서 출력을 선택합니다.

  2. cmdToConnectToCluster 속성 값을 복사합니다. 터미널을 열고 복사한 명령을 붙여넣은 다음 Enter 키를 눌러 실행합니다. 출력에 포함된 다음 예제와 유사한 메시지가 표시됩니다.

    Merged "cluster3984d1-admin" as current context in <your-user>\.kube\config

  3. 나중에 클러스터에 연결하는 데 사용할 수 있도록 명령을 따로 저장합니다.

  4. 터미널에서 실행 kubectl get pod --all-namespaces 하여 AKS 클러스터에서 실행되는 모든 Pod를 나열합니다. 다음 예제와 비슷한 내용이 출력됩니다.

    NAMESPACE      NAME                                        READY   STATUS    RESTARTS      AGE
cert-manager   cert-manager-66bc9756fd-255pk               1/1     Running   0             8m55s
cert-manager   cert-manager-cainjector-669c9fb694-k4q88    1/1     Running   0             8m55s
cert-manager   cert-manager-webhook-84967d556d-vj4lp       1/1     Running   0             8m55s
kube-system    azure-ip-masq-agent-dgzkt                   1/1     Running   0             29m
kube-system    cloud-node-manager-6x7bp                    1/1     Running   0             29m
kube-system    coredns-789789675-6b7dh                     1/1     Running   0             28m
kube-system    coredns-789789675-n68wt                     1/1     Running   0             29m
kube-system    coredns-autoscaler-649b947bbd-zhdbn         1/1     Running   0             29m
kube-system    csi-azuredisk-node-h9p7m                    3/3     Running   0             29m
kube-system    csi-azurefile-node-jnllw                    3/3     Running   0             29m
kube-system    ingress-appgw-deployment-69944d8fb9-v9btr   1/1     Running   5 (12m ago)   17m
kube-system    konnectivity-agent-94878f88c-hfqng          1/1     Running   0             29m
kube-system    konnectivity-agent-94878f88c-ln2vp          1/1     Running   0             29m
kube-system    kube-proxy-28lkg                            1/1     Running   0             29m
kube-system    metrics-server-5fffcb8954-549xl             2/2     Running   0             28m
kube-system    metrics-server-5fffcb8954-fn56g             2/2     Running   0             28m
open-liberty   olo-controller-manager-7954d76cf8-qhmxw     1/1     Running   0             8m40s

  5. 터미널에서 실행 kubectl get secret 하여 AKS 클러스터에 설치된 모든 비밀을 나열합니다. 다음 예제와 같이 출력에 하나의 비밀이 표시됩니다.

    NAME           TYPE                DATA   AGE
secret3984d1   kubernetes.io/tls   2      24m

    이 비밀은 TLS 트래픽에 대한 인증서 및 키 데이터를 포함하는 TLS 비밀입니다. 비밀의 이름을 복사하여 저장합니다. 예를 들어 secret3984d1나중에 앱 배포에서 사용합니다.

  6. 출력 페이지로 다시 전환합니다 . cmdToLoginInRegistry 속성 값을 복사합니다. 복사한 명령을 터미널에 붙여넣고 Enter 키를 눌러 실행합니다. 출력에 로그인 성공이 표시됩니다. 터미널을 열어 두고 나중에 WebSphere Liberty/Open Liberty 클러스터의 추가 구성에 사용합니다.

다음 단계를 사용하여 Azure 애플리케이션 Gateway의 공용 IP 주소 이름 및 DNS 이름을 가져옵니다. 나중에 앱 배포 및 Azure Traffic Manager 설정에 사용합니다.

  1. Azure Portal의 검색 상자에 리소스 그룹을 입력하고 검색 결과에서 리소스 그룹을 선택합니다.
  2. 주 지역의 리소스 그룹 이름(예 liberty-aks-eastus-mjg032524: .)을 선택합니다.
  3. 접두사로 gwip 리소스를 찾은 다음 해당 이름을 복사하여 저장합니다.
  4. 공용 IP 주소 리소스를 olgw3984d1.eastus.cloudapp.azure.com).

ACR 인스턴스에 대한 지역에서 복제 사용

ACR 인스턴스는 주 클러스터와 보조 클러스터 모두에 대한 애플리케이션 이미지를 저장하도록 설계되었습니다. ACR 인스턴스에 대해 지역 복제를 사용하도록 설정하려면 다음 단계를 사용합니다.

  1. Azure Portal의 검색 상자에 리소스 그룹을 입력하고 검색 결과에서 리소스 그룹을 선택합니다.

  2. 주 지역의 리소스 그룹 이름(예 liberty-aks-eastus-mjg032524: .)을 선택합니다.

  3. 접두사로 추가된 Container Registry 리소스를 찾은 acr다음 선택하여 엽니다.

  4. 속성을 선택합니다. 가격 책정 플랜의 경우 프리미엄을 선택한 다음 저장을 선택합니다. 완료될 때까지 기다립니다.

  5. 지역에서 복제를 선택한 다음, 추가를 선택합니다. 위치의 경우 미국 서부를 선택한 다음 만들기를 선택합니다. 완료될 때까지 기다립니다.

  6. 잠시 기다렸다가 새로 고침을 선택합니다. 두 위치가 나열되고 상태가준비됨이 표시될 때까지 작업을 반복합니다.

    쌍 지역에서 지역에서 지역에서 복제를 사용하도록 설정된 ACR 인스턴스를 보여 주는 Azure Portal의 스크린샷

다음 단계를 사용하여 ACR 로그인 자격 증명을 가져옵니다. 나중에 앱 배포에 사용합니다.

  1. 액세스 키를 선택합니다.

  2. 레지스트리 이름과 로그인 서버의 값을 각각 복사하여 따로 저장합니다.

    참고 항목

    이 문서에서는 az acr build 명령을 사용하여 Container Registry의 username 및 password 사용하지 않고 Docker 이미지를 빌드하고 Container Registry에 푸시합니다. docker login과 docker push으로 여전히 사용자 이름과 비밀번호를 사용할 수 있습니다. 사용자 이름 및 암호를 사용하는 것은 암호 없는 인증보다 안전하지 않습니다.

샘플 앱 배포

다음 단계를 사용하여 나중에 재해 복구 장애 조치(failover) 테스트를 위해 WebSphere Liberty/Open Liberty 클러스터에서 샘플 CRUD Java/Jakarta EE 애플리케이션을 배포하고 실행합니다.

  1. 다음 명령을 사용하여 샘플을 다운로드합니다.

    git clone https://github.com/Azure-Samples/open-liberty-on-aks.git
cd open-liberty-on-aks
export BASE_DIR=$PWD
git checkout 20240325

    애플리케이션은 이전에 배포한 Azure SQL Database에 연결하는 데이터 원본 jdbc/JavaEECafeDB 를 구성합니다. 데이터 원본은 HTTP 세션 데이터를 저장하는 데 사용되며, 이를 통해 WebSphere Liberty/Open Liberty 서버 클러스터에서 장애 조치(failover) 및 부하 분산이 가능합니다. 또한 샘플 앱은 동일한 데이터 원본에 애플리케이션 데이터를 유지하도록 지속성 스키마coffee합니다. 샘플의 컨텍스트 루트는 server.xml/와 같이 구성됩니다.

  2. 다음 명령을 사용하여 이전에 저장한 값으로 환경 변수를 정의합니다.

    export DB_SERVER_NAME=<failover-group-name>.database.windows.net
export DB_NAME=mySampleDatabase
export DB_USER=azureuser@<failover-group-name>
export DB_PASSWORD='<SQL-Server-admin-login-password>'
export REGISTRY_NAME=<ACR-registry-name>
export LOGIN_SERVER=<ACR-login-server>
export INGRESS_TLS_SECRET=<TLS-secret-name>

  3. 다음 예제와 같이 az acr build 명령을 사용하여 Docker 이미지를 빌드하고 Container Registry에 푸시합니다.

    cd $BASE_DIR/java-app
mvn clean install

cd $BASE_DIR/java-app/target
# If you deployed WebSphere Liberty Operator previously, use "Dockerfile-wlp" instead of "Dockerfile"
az acr build \
    --registry ${REGISTRY_NAME} \
    --image javaee-cafe:v1 \
    --file Dockerfile \
    .

  4. 다음 명령을 사용하여 샘플 앱을 AKS 클러스터에 배포합니다.

    cd $BASE_DIR/java-app/target
kubectl apply -f db-secret.yaml

# If you deployed WebSphere Liberty Operator previously, use "webspherelibertyapplication-agic.yaml" instead of "openlibertyapplication-agic.yaml"
kubectl apply -f openlibertyapplication-agic.yaml

  5. 다음 명령을 실행하여 배포한 샘플 앱을 가져옵니다.

    # If you deployed WebSphere Liberty Operator previously, use "WebSphereLibertyApplication" instead of "OpenLibertyApplication"
kubectl get OpenLibertyApplication

    출력에 READY 애플리케이션이 하나 표시됩니다.

    NAME                       IMAGE                                 EXPOSED   RECONCILED   RESOURCESREADY   READY   AGE
javaee-cafe-cluster-agic   acr3984d1.azurecr.io/javaee-cafe:v1             True         True             True    45s

  6. 다음 명령을 실행하여 배포 중에 만든 Pod의 상태를 가져옵니다.

    kubectl get pods

    다음 예제에서는 모든 Pod가 실행 중임을 나타냅니다. 비슷한 출력이 표시되지 않으면 잠시 기다렸다가 작업을 반복합니다.

    NAME                                        READY   STATUS    RESTARTS   AGE
javaee-cafe-cluster-agic-6bbb8d6f5c-2xjc4   1/1     Running   0          1m
javaee-cafe-cluster-agic-6bbb8d6f5c-4f449   1/1     Running   0          1m
javaee-cafe-cluster-agic-6bbb8d6f5c-m2wg6   1/1     Running   0          1m

  7. 다음 단계를 사용하여 앱이 예상대로 실행되고 있는지 확인합니다.

    1. 새 브라우저 탭에서 이전에 저장한 Azure 애플리케이션 게이트웨이의 공용 IP 주소의 DNS 이름을 엽니다. 프로토콜을 https 사용합니다(예: .) https://olgw3984d1.eastus.cloudapp.azure.com. 샘플 앱의 시작 페이지가 표시됩니다.

    2. 이름 및 가격으로 새 커피를 만듭니다(예: 가격 10의 Coffee 1). 이 커피는 애플리케이션 데이터 테이블과 데이터베이스의 세션 테이블 모두에 유지됩니다. 표시되는 UI는 다음 스크린샷과 유사해야 합니다.

      샘플 애플리케이션 UI의 스크린샷.

    UI가 비슷하지 않으면 계속하기 전에 문제를 해결하고 해결합니다.

Azure Backup을 사용하여 클러스터에 대한 재해 복구 설정

이 섹션에서는 Azure Backup을 사용하여 주 지역의 AKS 클러스터에 대한 재해 복구를 설정합니다.

저장소 계정 만들기

AKS 백업은 Blob 컨테이너를 사용하여 AKS 클러스터 리소스를 보유합니다. 지역 간 복원 중에 사용할 스테이징 위치로 다른 Blob 컨테이너를 만듭니다.

다음 단계를 사용하여 스토리지 계정과 두 개의 컨테이너를 만듭니다. 이러한 단계 중 일부는 다른 가이드와 연결됩니다.

  1. Azure Portal에 로그인합니다.
  2. 스토리지 계정 만들기의 단계에 따라 스토리지 계정을 만듭니다. 문서의 모든 단계를 수행할 필요는 없습니다. 다음 단계를 사용하여 기본 창에 표시된 대로 필드를 채웁니다.
    1. 리소스 그룹의 경우 기본 클러스터가 배포되는 기존 리소스 그룹을 선택합니다(예: liberty-aks-eastus-mjg032524).
    2. Storage 계정 이름의 경우 고유한 이름(예: storageeastusmjg032524.)을 입력합니다.
    3. 지역에 대해 미국 동부를 선택합니다.
    4. 검토 + 만들기를 선택하여 기본 옵션을 적용합니다.
    5. 계속해서 계정의 유효성을 검사하고 만든 다음, 이 문서로 돌아갑니다.
  3. 스토리지 컨테이너 만들기의 단계에 따라 AKS Backup 확장에 대한 스토리지 컨테이너를 만듭니다. 이 가이드에서는 컨테이너 이름으로 사용합니다 aks-backup-ext .
  4. 복원하는 동안 사용할 스테이징 위치로 다른 스토리지 컨테이너를 만듭니다. 이 가이드에서는 컨테이너 이름으로 사용합니다 staging .

AKS 백업 확장 사용

계속하기 전에 다음 단계를 사용하여 주 지역의 클러스터에 AKS 백업 확장을 설치합니다.

  1. 클러스터에 대한 CSI 드라이버 및 스냅샷을 사용하도록 설정합니다. 다음 az aks update 명령의 경우 Bash 변수 RG_NAME 값을 리소스 그룹 이름(예 liberty-aks-eastus-mjg032524 : )으로 업데이트하고 로컬 Bash 터미널에서 실행합니다.

    export RG_NAME=<your-aks-cluster-resource-group>
export AKS_NAME=$(az aks list \
    --resource-group ${RG_NAME} \
    --query "[0].name" \
    --output tsv | tr -d '\r')

az aks update \
    --resource-group ${RG_NAME} \
    --name ${AKS_NAME} \
    --enable-disk-driver \
    --enable-file-driver \
    --enable-blob-driver \
    --enable-snapshot-controller --yes

    드라이버를 사용하도록 설정하는 데 약 5분이 걸립니다. 계속하기 전에 명령이 오류 없이 완료되었는지 확인합니다.

  2. AKS가 배포된 리소스 그룹을 엽니다(예: liberty-aks-eastus-mjg032524.). 리소스 목록에서 AKS 클러스터를 선택합니다.

  3. AKS 방문 페이지의 설정에서 백업을 선택한 다음, 확장 설치를 선택합니다.

  4. AKS Backup 확장 설치 페이지에서 다음을 선택합니다. 동일한 리소스 그룹에서 만든 스토리지 계정 storageeastusmjg032524 및 Blob 컨테이너 aks-backup-ext 를 선택합니다. 다음을 선택한 다음 만들기를 선택합니다. 이 단계를 완료하는 데 약 5분이 걸립니다.

AKS 클러스터 백업

AKS 클러스터를 백업하려면 다음 단계를 사용합니다.

  1. Azure Portal의 검색 상자에서 Backup 자격 증명 모음을 검색합니다. 서비스 아래에 나열된 것을 볼 수 있습니다. 이 폴더를 선택합니다.

  2. Azure Backup을 사용하여 주 클러스터에 AKS Backup 을 사용하도록 설정하여 Azure Kubernetes Service 백업의 단계를 따릅니다. AKS 백업 섹션에서 후크 사용 섹션을 포함하지만 포함하지 않는 단계를 실행하고 이 섹션의 나머지 단계를 사용하여 진행하면서 조정합니다.

  3. Backup 자격 증명 모음 만들기 섹션에 도달하면 다음 단계를 사용합니다.

    1. 1단계의 경우 리소스 그룹의 경우 주 클러스터가 배포된 기존 리소스 그룹을 선택합니다(예: liberty-aks-eastus-mjg032524).

    2. Backup 자격 증명 모음 이름의 경우 고유한 값(예: aks-backup-vault-eastus-mjg032524.)을 입력합니다.

    3. 지역에 대해 미국 동부를 선택합니다.

    4. 백업 스토리지 중복성의 경우 전역 중복을 선택합니다.

      Backup Vault 기본 창을 보여 주는 Azure Portal의 스크린샷.

    5. 2단계의 경우 지역 간 복원에 대해 [사용]을 선택합니다.

  4. 백업 정책 만들기 섹션에 도달하면 다음 단계를 사용합니다.

    1. 3단계의 경우 백업 정책의 이름(예: aksbackuppolicy.)을 입력합니다.

    2. 같은 리소스 그룹에서 만든 Backup 자격 증명 모음(예: aks-backup-vault-eastus-mjg032524)을 선택합니다.

    3. 4단계의 경우 Vault 표준이 선택된 보존 규칙을 추가합니다.

      보존 추가 창이 열려 있고 Vault 표준 옵션이 강조 표시된 백업 정책 만들기 페이지를 보여 주는 Azure Portal의 스크린샷

    4. 추가를 선택합니다.

  5. 백업 구성 섹션에서 다음 단계를 사용합니다.

    1. AKS 확장 설치를 위한 1-5단계를 건너뜁니다. 주 지역의 AKS 클러스터에 대한 6단계부터 시작합니다.

    2. 7단계의 경우 자격 증명 모음의 경우 동일한 리소스 그룹에서 만든 백업 자격 증명 모음(예: aks-backup-vault-eastus-mjg032524)을 선택합니다. 사용 권한 오류가 발생하면 계속 진행하려면 사용 권한 부여를 선택합니다. 권한 배포가 완료된 후에도 오류가 계속 표시되면 유효성 재검사(Revalidate)를 선택하여 역할 할당을 새로 고칩니다.

      권한 오류와 권한 부여 링크가 강조 표시된 Backup 기본 사항 구성 창을 보여 주는 Azure Portal의 스크린샷.

    3. 10단계에서 백업할 리소스 선택을 찾 습니다. Backup 인스턴스 이름의 경우 고유한 이름(예akseastusmjg032524: .)을 입력합니다. 기타 옵션의 경우 모든 옵션을 선택합니다. 비밀 포함이 선택되어 있는지 확인합니다.

      비밀 포함 옵션이 강조 표시된 백업할 리소스 선택 창을 보여 주는 Azure Portal의 스크린샷.

    4. 11단계에서는 역할 할당 오류가 발생합니다. 12-14단계에 따라 오류를 완화합니다.

      누락된 권한 부여 대화 상자가 열려 있는 백업 구성 창을 보여 주는 Azure Portal의 스크린샷.

    5. 15단계에서 백업 구성을 선택한 후 백업 페이지로 돌아갑니다. 잠시 기다린 다음 새로 고침을 선택합니다. 백업 인스턴스가 나열되고 보호 상태가 보호가 구성될 때까지 작업을 반복합니다.

      AKS 백업 인스턴스 보호가 구성된 것을 보여 주는 Azure Portal의 스크린샷.

자격 증명 모음 표준 백업이 수행되기를 기다립니다.

AKS에서 자격 증명 모음 표준 계층은 지역 중복 및지역 간 복원을 지원하는 유일한 계층입니다. AKS 백업은 어떤 백업 스토리지 계층에서 지원하나요?에 설명된 대로 "하루에 예약된 복구 지점이 하나만 자격 증명 모음 계층으로 이동됩니다." 자격 증명 모음 표준 백업이 발생할 때까지 기다려야 합니다. 좋은 하한은 복원하기 전에 이전 단계를 완료한 후 최대 24시간 동안 기다리는 것입니다.

다음 단계를 사용하여 자격 증명 모음 표준 백업을 사용할 수 있는지 확인합니다.

  1. 기본 AKS 클러스터의 백업 페이지에서 백업 인스턴스를 선택합니다.

  2. 잠시 기다렸다가 새로 고침을 선택합니다. RESTORE POINTS 섹션에 하나 이상의 운영 및 자격 증명 모음 표준 복원 지점이 나열될 때까지 작업을 반복합니다.

    운영 및 자격 증명 모음 표준 복원 지점이 강조 표시된 복원 지점 섹션을 보여 주는 Azure Portal의 스크린샷

보조 AKS 클러스터 설정

주 AKS 클러스터에 대한 자격 증명 모음 표준 백업이 발생할 때까지 기다리는 동안 나중에 복원할 보조 AKS 클러스터를 설정합니다.

다음 차이점을 제외하고 주 WebSphere Liberty/Open Liberty 클러스터 배포 섹션에서 동일한 단계를 사용하여 보조 지역에 보조 AKS 클러스터를 설정합니다.

  1. 기본 창에서 다음 단계를 사용합니다.

    1. 리소스 그룹 필드에서 새로liberty-aks-westus-mjg032524).
    2. 인스턴스 세부 정보에서 지역에 대해 미국 서부를 선택합니다.

  2. AKS 창에서 다음 단계를 사용합니다.

    1. ACR(Azure Container Registry)에서 ACR 인스턴스 선택에서 아니요를 선택합니다.

    2. 지역에서 복제를 사용하도록 설정된 주 지역에서 기존 ACR 인스턴스를 선택합니다.

      ACR 인스턴스가 강조 표시된 Azure Kubernetes Service에서 IBM WebSphere Liberty 및 Open Liberty 만들기 Azure Portal의 스크린샷.

다음 차이점을 제외하고 보조 지역에서 배포를 확인하려면 클러스터 배포 확인 섹션의 동일한 단계를 사용합니다.

  1. TLS 비밀의 이름을 복사하고 따로 저장할 필요가 없습니다. TLS 비밀은 기본 AKS 클러스터의 백업에서 복원됩니다.
  2. 보조 클러스터의 리소스 그룹(예 liberty-aks-westus-mjg032524 : 보조 지역에 배포된 Azure 애플리케이션 게이트웨이의 공용 IP 주소 이름 및 DNS 이름을 조회할 때)을 사용합니다.

다음 차이점을 제외하고 보조 지역에 스토리지 계정을 만들려면 스토리지 계정 만들기 섹션의 동일한 단계를 사용합니다.

  1. 리소스 그룹 필드의 경우 보조 클러스터가 배포되는 기존 리소스 그룹을 선택합니다(예: liberty-aks-westus-mjg032524).
  2. Storage 계정 이름의 경우 고유한 이름(예: storagewestusmjg032524.)을 입력합니다.
  3. 지역으로 미국 서부를 선택합니다.

다음 차이점을 제외하고 AKS Backup 확장을 사용하도록 설정 섹션에서 동일한 단계를 사용하여 보조 지역에 클러스터에 대한 AKS 백업 확장을 설치합니다.

  1. 보조 클러스터에 대한 CSI 드라이버 및 스냅샷을 사용하도록 설정하는 1단계에서 Bash 변수 RG_NAME 값을 보조 지역의 리소스 그룹(예: liberty-aks-westus-mjg032524/>)으로 업데이트합니다.
  2. 2단계에서는 보조 지역의 리소스 그룹에서 AKS 클러스터를 선택합니다(예: liberty-aks-westus-mjg032524).
  3. 보조 클러스터에 대한 AKS Backup 확장을 설치하기 위한 4단계에서 보조 지역의 동일한 리소스 그룹에서 만든 스토리지 계정을 선택합니다(예: storagewestusmjg032524).

비용을 절감하려면 AKS(Azure Kubernetes Service) 클러스터 중지 및 시작의 단계에 따라 보조 지역에서 AKS 클러스터를 중지합니다. 나중에 클러스터를 복원하기 전에 먼저 시작해야 합니다.

Azure Traffic Manager 설정

자격 증명 모음 표준 백업은 자격 증명 모음 표준 백업이 수행될 때까지 기다리는 섹션에서 언급되었습니다. 자격 증명 모음 표준 백업을 사용할 수 있음을 확인하면 전역 Azure 지역에 걸쳐 공용 연결 애플리케이션에 트래픽을 배포하기 위한 Azure Traffic Manager를 만들 수 있습니다. 기본 엔드포인트는 주 지역에 있는 Azure 애플리케이션 게이트웨이의 공용 IP 주소를 가리킵니다. 보조 엔드포인트는 보조 지역에 있는 Azure 애플리케이션 게이트웨이의 공용 IP 주소를 가리킵니다.

빠른 시작의 단계에 따라 Azure Traffic Manager 프로필을 만듭니다. Azure Portal을 사용하여 Traffic Manager 프로필을 만듭니다. Traffic Manager 프로필을만들고 Traffic Manager 엔드포인트를 추가하기만 하면 됩니다. 다음 단계를 사용하여 이러한 섹션을 진행한 다음, Azure Traffic Manager를 만들고 구성한 후 이 문서로 돌아갑니다.

  1. Traffic Manager 프로필 만들기 섹션에 도달하면 2단계에서 Traffic Manager 프로필 만들기에 대해 다음 단계를 사용합니다.

    1. 이름에 대해 고유한 Traffic Manager 프로필 이름(예: .)tmprofile-mjg032524을 입력합니다.
    2. 라우팅 방법의 경우 우선 순위를 선택합니다.
    3. 리소스 그룹의 경우 새 리소스 그룹 이름(예 myResourceGroupTM1: )을 입력하고 저장합니다.

  2. Traffic Manager 엔드포인트 추가 섹션 에 도달하면 다음 단계를 사용합니다.

    1. 2 단계에서 Traffic Manager 프로필을 연 후 구성 페이지에서 다음 단계를 사용합니다.
      1. DNS TTL(Time to Live)의 경우 10을 입력합니다.
      2. 엔드포인트 모니터 설정에서 프로토콜에 대해 https를 선택하고 포트에 443을 입력합니다.
      3. 빠른 엔드포인트 장애 조치(failover) 설정에서 다음 값을 사용합니다.
        • 내부 검색의 경우 10을 선택합니다.
        • 허용되는 오류 수의 경우 3을 입력합니다.
        • 프로브 시간 제한의 경우 5를 입력합니다.
      4. 저장을 선택합니다. 완료될 때까지 기다립니다.
    2. 기본 엔드포인트 myPrimaryEndpoint를 추가하기 위한 4단계에서 다음 단계를 사용합니다.
      1. 대상 리소스 유형의 경우 공용 IP 주소를 선택합니다.
      2. 공용 IP 주소 선택 드롭다운을 선택하고 이전에 저장한 미국 동부 지역의 Azure 애플리케이션 게이트웨이의 공용 IP 주소 이름을 입력합니다. 일치하는 항목이 하나 표시됩니다. 공용 IP 주소에 대해 선택합니다.
    3. 장애 조치/보조 엔드포인트 myFailoverEndpoint를 추가하기 위한 6단계에서 다음 단계를 사용합니다.
      1. 대상 리소스 유형의 경우 공용 IP 주소를 선택합니다.
      2. 공용 IP 주소 선택 드롭다운을 선택하고 이전에 저장한 미국 서부 지역의 Azure 애플리케이션 게이트웨이의 공용 IP 주소 이름을 입력합니다. 일치하는 항목이 하나 표시됩니다. 공용 IP 주소에 대해 선택합니다.
    4. 잠시 기다립니다. 엔드포인트의 모니터 상태가 온라인myPrimaryEndpoint 저하myFailoverEndpoint때까지 새로 고침을 선택합니다.

다음으로, 다음 단계를 사용하여 기본 클러스터에 배포된 샘플 앱이 Traffic Manager 프로필에서 액세스할 수 있는지 확인합니다.

  1. 만든 Traffic Manager 프로필의 개요를 선택합니다.

  2. Traffic Manager 프로필의 DNS 이름을 확인하고 복사하여 프로토콜 httphttps을 .로 바꿔 줍니다. 예들 들어 https://tmprofile-mjg032524.trafficmanager.net입니다.

  3. 새 브라우저 탭에서 URL을 엽니다. 이전에 만든 커피가 페이지에 나열되어 있는 것을 볼 수 있습니다.

  4. 다른 이름 및 가격(예: 가격 20의 Coffee 2)을 사용하여 다른 커피를 만듭니다. 이 커피는 애플리케이션 데이터 테이블과 데이터베이스의 세션 테이블 모두에 유지됩니다. 표시되는 UI는 다음 스크린샷과 유사해야 합니다.

    두 번째 커피가 있는 샘플 애플리케이션 UI의 스크린샷.

UI가 비슷하지 않으면 계속하기 전에 문제를 해결하고 해결합니다. 콘솔을 열어 두고 나중에 장애 조치(failover) 테스트에 사용합니다.

Traffic Manager 프로필 설정을 완료했습니다. 페이지를 열어 두고 나중에 장애 조치(failover) 이벤트의 엔드포인트 상태 변경을 모니터링하는 데 사용합니다.

기본에서 보조로 장애 조치(failover) 테스트

이 섹션에서는 장애 조치(failover)를 테스트하기 위해 Azure SQL Database 서버를 수동으로 장애 조치(failover)하고 AKS 클러스터의 백업을 복원한 다음 Azure Portal을 사용하여 장애 복구(failback)합니다.

보조 사이트로 장애 조치(failover)

주 지역의 중단을 시뮬레이션하려면 AKS(Azure Kubernetes Service) 클러스터 중지 및 시작의 단계에 따라 기본 AKS 클러스터를 중지합니다.

다음으로, 주 클러스터의 백업에서 복원할 수 있도록 보조 AKS 클러스터를 시작합니다.

참고 항목

복원 대상 클러스터에서 실행 중인 WebSphere Liberty/Open Liberty 애플리케이션이 있는 경우 충돌을 방지하려면 다음 단계를 사용하여 WebSphere Liberty/Open Liberty 애플리케이션을 정리합니다.

  • 이전에 저장한 명령을 실행하여 대상 클러스터에 cmdToConnectToCluster 연결합니다.

  • Open Liberty 애플리케이션의 경우 다음 명령을 실행합니다.

    kubectl delete OpenLibertyApplication --all --all-namespaces

  • WebSphere Liberty 애플리케이션의 경우 다음 명령을 실행합니다.

    kubectl delete WebSphereLibertyApplication --all --all-namespaces

그런 다음 Traffic Manager 프로필의 브라우저 탭으로 전환하고 두 엔드포인트의 모니터 상태가 저하되었는지 확인myFailoverEndpoint.

이제 다음 단계를 사용하여 주 서버에서 보조 서버로 Azure SQL Database를 장애 조치합니다.

  1. 예를 들어 failovergroup-mjg032524Azure SQL Database 장애 조치(failover) 그룹의 브라우저 탭으로 전환합니다.
  2. 장애 조치(failover)를 선택한 다음, 예를 선택합니다.
  3. 완료될 때까지 기다립니다.

다음으로, 다음 단계를 사용하여 주 AKS 클러스터의 백업을 보조 AKS 클러스터로 복원합니다.

  1. Azure Portal의 검색 상자에 Backup 센터를 입력하고 검색 결과에서 Backup 센터를 선택합니다.

  2. 관리에서 Backup 인스턴스를 선택합니다. 데이터 원본 형식 Kubernetes Services를 필터링합니다. 이전 섹션에서 만든 백업 인스턴스(예: <aks-cluster-name>\akseastusmjg032524.)를 찾습니다.

  3. 백업 인스턴스를 선택합니다.

  4. 복원을 선택합니다.

  5. 복원 페이지에서 기본 창은 복원 지점입니다. [이전]을 선택하여 기본 창으로 변경합니다. 복원 지역의 경우 보조 지역을 선택한 다음, 다음: 복원 지점을 선택합니다.

    기본 복원 창을 보여 주는 Azure Portal의 스크린샷.

  6. 복원 지점 창에서 최신 운영 및 자격 증명 모음 표준 복원 지점이 선택됩니다. 기본값을 유지하고 다음: 복원 매개 변수를 선택합니다.

    복원 지점 창을 보여 주는 Azure Portal의 스크린샷.

  7. 복원 매개 변수 창에서 다음 단계를 사용합니다.

    1. 대상 클러스터 선택의 경우 미국 서부 지역에서 만든 보조 AKS 클러스터를 선택합니다. 다음 스크린샷과 같이 사용 권한 문제가 발생합니다. 권한을 부여하여 오류를 완화합니다.

    2. 백업 준비 위치의 경우 미국 서부 지역에서 만든 스토리지 계정을 선택합니다. 다음 스크린샷과 같이 사용 권한 문제가 발생합니다. 누락된 역할 할당을 선택하여 오류를 완화합니다.

      복원 매개 변수 창을 보여 주는 Azure Portal의 스크린샷.

    3. 역할 할당이 완료된 후에도 오류가 계속 발생하는 경우 유효성 재검사(Revalidate)를 선택하여 권한을 새로 고칩니다.

    4. 누락된 권한을 부여할 때 범위를 지정하라는 메시지가 표시되면 기본값을 적용합니다.

    5. 유효성 확인을 선택합니다. Validation completed successfully 메시지가 표시됩니다. 그렇지 않으면 계속하기 전에 문제를 해결하고 해결합니다.

  8. 다음: 검토 + 복원을 선택합니다. 그런 다음 복원을 선택합니다. 클러스터를 복원하는 데 약 10분이 걸립니다.

  9. 다음 스크린샷과 같이 Backup 센터>>에서 복원 프로세스를 모니터링할 수 있습니다.

    진행 중인 CrossRegionRestore를 보여 주는 Azure Portal의 스크린샷

  10. 잠시 기다린 다음 새로 고침을 선택합니다. 상태가 완료된 것으로 표시될 때까지 작업을 반복합니다.

그런 다음, 다음 단계를 사용하여 복원이 예상대로 작동하는지 확인합니다.

  1. 보조 AKS 클러스터에 연결된 터미널로 전환합니다.

  2. 다음 명령을 실행하여 백업에서 샘플 앱을 복원합니다.

    kubectl get OpenLibertyApplication

    출력에 READY 애플리케이션이 하나 표시됩니다.

    NAME                       IMAGE                                 EXPOSED   RECONCILED   RESOURCESREADY   READY   AGE
javaee-cafe-cluster-agic   acr3984d1.azurecr.io/javaee-cafe:v1             True         True             True    3m

  3. 다음 명령을 실행하여 배포 중에 만든 Pod의 상태를 가져옵니다.

    kubectl get pods

    출력에 세 개의 실행 중인 Pod가 표시됩니다.

    NAME                                        READY   STATUS    RESTARTS   AGE
javaee-cafe-cluster-agic-7bb57dd945-6ljll   1/1     Running   0          3m
javaee-cafe-cluster-agic-7bb57dd945-h2xdf   1/1     Running   0          3m
javaee-cafe-cluster-agic-7bb57dd945-k744w   1/1     Running   0          3m

  4. Traffic Manager 프로필의 브라우저 탭으로 전환한 다음 엔드포인트의 모니터 상태가 온라인 상태이고 엔드포인트 myFailoverEndpoint 의 모니터 상태가 저하됨myPrimaryEndpoint표시될 때까지 페이지를 새로 고칩니다.

  5. Traffic Manager 프로필의 DNS 이름을 사용하여 브라우저 탭으로 전환합니다(예: https://tmprofile-mjg032524.trafficmanager.net.). 페이지를 새로 고치면 애플리케이션 데이터 테이블에 동일한 데이터가 유지되고 세션 테이블이 표시됩니다. 표시되는 UI는 다음 스크린샷과 유사해야 합니다.

    장애 조치(failover) 후 샘플 애플리케이션 UI의 스크린샷.

    이 동작을 관찰하지 않으면 Traffic Manager가 장애 조치(failover) 사이트를 가리키도록 DNS를 업데이트하는 데 시간이 걸리기 때문일 수 있습니다. 문제는 브라우저가 실패한 사이트를 가리키는 DNS 이름 확인 결과를 캐시한 것일 수도 있습니다. 잠시 기다렸다가 페이지를 다시 새로 고칩니다.

    참고 항목

    앱은 세션 시간 제한을 1시간으로 구성합니다. 장애 조치(failover)에 걸린 시간에 따라 이전에 1시간 이상 만료된 경우 샘플 앱 UI의 새 커피 섹션에 세션 데이터가 표시되지 않을 수 있습니다.

장애 조치(failover) 사이트 다시 보호

이제 보조 지역이 장애 조치(failover) 사이트이고 활성 상태이므로 Azure Backup을 사용하여 다시 보호해야 합니다.

먼저 다음 차이점을 제외하고 AKS 클러스터 백업 섹션에서 동일한 단계를 사용하여 보조 AKS 클러스터를 백업합니다.

  1. Backup 자격 증명 모음 만들기의 경우 다음 단계를 사용합니다.
    1. 리소스 그룹의 경우 보조 지역에 배포된 기존 리소스 그룹(예: liberty-aks-westus-mjg032524)을 선택합니다.
    2. Backup 자격 증명 모음 이름의 경우 고유한 값(예: aks-backup-vault-westus-mjg032524.)을 입력합니다.
    3. 지역으로 미국 서부를 선택합니다.
  2. 백업 정책 만들기의 경우 다음 단계를 사용합니다.
    1. 보조 지역에서 만든 Backup 자격 증명 모음(예: aks-backup-vault-westus-mjg032524)을 선택합니다.
  3. 백업 구성의 경우 다음 단계를 사용합니다.
    1. 보조 지역에서 만든 Backup 자격 증명 모음(예: aks-backup-vault-westus-mjg032524)을 선택합니다.
    2. Backup 인스턴스 이름의 경우 고유한 이름(예akswestusmjg032524: .)을 입력합니다.

그런 다음 보조 AKS 클러스터의 백업 페이지에서 백업 인스턴스 를 선택하는 것을 제외하고 보조 AKS 클러스터의 자격 증명 모음 표준 백업을 사용할 수 있게 될 때까지 자격 증명 모음 표준 백업이 대기하는 섹션의 동일한 단계를 사용합니다.

기본 사이트로 장애 복구

다음 차이점을 제외하고 보조 사이트 섹션에 대한 장애 조치(failover)의 동일한 단계를 사용하여 데이터베이스 서버 및 AKS 클러스터를 포함한 기본 사이트로 장애 복구합니다.

  1. 장애 복구(failback)를 준비할 때 다음 단계를 사용합니다.

    1. 보조 AKS 클러스터를 중지하여 보조 지역의 중단을 시뮬레이션합니다.
    2. 기본 AKS 클러스터를 시작합니다.
    3. 기본 AKS 클러스터에 연결하고 WebSphere Liberty/Open Liberty 애플리케이션을 정리합니다.

  2. 보조 AKS 클러스터의 백업을 기본 AKS 클러스터로 복원하는 경우 다음 단계를 사용합니다.

    1. 보조 지역에서 백업 인스턴스를 선택합니다(예: <aks-cluster-name>\akswestusmjg032524.).
    2. 복원 매개 변수 창에서 다음 단계를 사용합니다.
      1. 대상 클러스터 선택에서 미국 동부 지역에서 만든 기본 AKS 클러스터를 선택합니다.
      2. 백업 준비 위치의 경우 미국 동부 지역에서 만든 스토리지 계정을 선택합니다.

  3. 복원이 예상대로 작동하는지 확인하면 다음 단계를 사용합니다.

    1. 기본 AKS 클러스터에 연결된 터미널로 전환하고 앱이 성공적으로 복원되었는지 확인합니다.
    2. Traffic Manager 프로필의 브라우저 탭으로 전환한 다음 엔드포인트의 모니터 상태가 온라인 상태이고 엔드포인트 myPrimaryEndpoint 의 모니터 상태가 저하됨myFailoverEndpoint표시될 때까지 페이지를 새로 고칩니다.

리소스 정리

WebSphere Liberty/Open Liberty 클러스터 및 기타 구성 요소를 계속 사용하지 않려면 다음 단계를 사용하여 리소스 그룹을 삭제하여 이 자습서에 사용된 리소스를 정리합니다.

  1. Azure Portal의 검색 상자에 Azure SQL Database 서버의 리소스 그룹 이름(예 myResourceGroup : )을 입력하고 검색 결과에서 일치하는 리소스 그룹을 선택합니다.
  2. 리소스 그룹 삭제를 선택합니다.
  3. 리소스 그룹 이름을 입력하여 삭제를 확인하려면 리소스 그룹 이름을 입력합니다.
  4. 삭제를 선택합니다.
  5. Traffic Manager의 리소스 그룹에 대해 1-4단계를 반복합니다(예: myResourceGroupTM1).
  6. Azure Portal의 검색 상자에 Backup 자격 증명 모음을 입력하고 검색 결과에서 Backup 자격 증명 모음을 선택합니다. 예를 들어 aks-backup-vault-eastus-mjg032524aks-backup-vault-westus-mjg032524두 개의 Backup 자격 증명 모음이 나열됩니다. 각 단계에 대해 다음 단계를 사용합니다.
    1. Backup 자격 증명 모음을 열려면 선택합니다.
    2. 속성>> 선택합니다. 일시 삭제 사용 옆의 확인란 선택을 취소한 다음 업데이트를 선택합니다.
    3. Backup 인스턴스 관리를>선택합니다. 데이터 원본 형식 Kubernetes Services를 필터링합니다. 만든 인스턴스를 선택한 다음 삭제합니다.
  7. 두 Backup 인스턴스가 삭제될 때까지 기다립니다.
  8. 주 클러스터의 리소스 그룹에 대해 1-4단계를 반복합니다(예: liberty-aks-eastus-mjg032524).
  9. 보조 클러스터의 리소스 그룹에 대해 1-4단계를 반복합니다(예: liberty-aks-westus-mjg032524).

다음 단계

이 자습서에서는 활성-수동 데이터베이스 계층이 있는 활성-수동 애플리케이션 인프라 계층으로 구성되고 두 계층이 지리적으로 다른 두 사이트에 걸쳐 있는 WebSphere Liberty/Open Liberty HA/DR 솔루션을 설정합니다. 첫 번째 사이트에서는 애플리케이션 인프라 계층과 데이터베이스 계층이 모두 활성화됩니다. 두 번째 사이트에서 보조 도메인은 Azure Backup을 사용하여 복원되고 보조 데이터베이스는 대기 상태입니다.

HA/DR 솔루션을 빌드하고 Azure에서 WebSphere를 실행하는 추가 옵션에 대한 다음 참조를 계속 살펴봅니다.

Azure 안정성 설명서

고가용성을 위한 솔루션 빌드

Azure Traffic Manager를 사용한 자동 장애 조치(failover)

Azure의 WebSphere에 대해 자세히 알아보기