자습서: 지역 중복성을 사용하여 Oracle WebLogic Server를 AKS(Azure Kubernetes Service)로 마이그레이션

아티클
04/29/2024

이 자습서에서는 AKS(Azure Kubernetes Service)에서 WLS(Oracle WebLogic Server)를 사용하여 Java에 대한 비즈니스 연속성 및 DR(재해 복구) 전략을 구현하는 간단하고 효과적인 방법을 보여 줍니다. 이 솔루션은 AKS에서 실행되는 간단한 데이터베이스 기반 Jakarta EE 애플리케이션을 사용하여 WLS 워크로드를 백업하고 복원하는 방법을 보여 줍니다. 지역 중복성은 많은 가능한 솔루션이 있는 복잡한 항목입니다. 최상의 솔루션은 고유한 요구 사항에 따라 달라집니다. 지역 중복성을 구현하는 다른 방법은 이 문서의 끝에 있는 리소스를 참조하세요.

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

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

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

Azure Traffic Manager는 지역 상태를 확인하고 그에 따라 트래픽을 애플리케이션 계층으로 라우팅합니다. 주 지역에는 WLS 클러스터의 전체 배포가 있습니다. 주 지역만 사용자의 네트워크 요청을 적극적으로 서비스합니다. 재해 또는 선언된 DR 이벤트가 있는 경우 보조 지역은 주 지역의 백업에서 WLS 클러스터를 복원합니다. 보조 지역은 주 지역에서 서비스 중단이 발생하는 경우에만 트래픽을 수신하도록 활성화됩니다.

Azure Traffic Manager는 Azure 애플리케이션 Gateway 및 WKO(WebLogic Kubernetes Operator)의 상태 검사 기능을 사용하여 이 조건부 라우팅을 구현합니다. WKO는 AKS 상태 검사와 긴밀하게 통합되어 Azure Traffic Manager가 Java 워크로드의 상태를 높은 수준으로 인식할 수 있도록 합니다. 주 WLS 클러스터가 실행 중이며 보조 클러스터가 종료됩니다.

애플리케이션 계층의 RTO(지역 장애 조치 복구 시간 목표)는 AKS를 시작하고 일반적으로 1시간 미만인 보조 WLS 클러스터를 실행하는 시간에 따라 달라집니다. 애플리케이션 데이터는 분 또는 시간의 RTO와 몇 분 또는 시간의 RPO(복구 지점 목표)를 사용하여 Azure SQL Database 장애 조치(failover) 그룹에 유지 및 복제됩니다. 이 아키텍처에서 Azure Backup에는 WLS 구성에 대한 자격 증명 모음 표준 백업이 매일 하나만 있습니다. 자세한 내용은 AKS(Azure Kubernetes Service) 백업이란?

데이터베이스 계층은 주 서버와 보조 서버가 있는 Azure SQL Database 장애 조치(failover) 그룹으로 구성됩니다. 주 서버는 활성 읽기/쓰기 모드이며 주 WLS 클러스터에 연결됩니다. 보조 서버는 수동 준비 전용 모드이며 보조 WLS 클러스터에 연결됩니다. 지역 장애 조치(failover)는 그룹의 모든 보조 데이터베이스를 주 역할로 전환합니다. Azure SQL Database의 지역 장애 조치(failover) RPO 및 RTO는 비즈니스 연속성 개요를 참조 하세요.

이 문서는 해당 서비스의 HA(고가용성) 기능을 사용하므로 Azure SQL Database 서비스를 사용하여 작성되었습니다. 다른 데이터베이스 선택도 가능하지만 선택한 데이터베이스의 HA 기능을 고려해야 합니다. 복제를 위해 데이터 원본의 구성을 최적화하는 방법에 대한 자세한 내용은 Oracle Fusion 미들웨어 활성-수동 배포에 대한 데이터 원본 구성을 참조하세요.

이 문서에서는 Azure Backup을 사용하여 AKS를 보호합니다. 지역 가용성, 지원되는 시나리오 및 제한 사항은 Azure Kubernetes Service 백업 지원 매트릭스를 참조 하세요. 현재 Azure Backup은 공개 미리 보기에서 사용할 수 있는 지역 간에 자격 증명 모음 계층 백업 및 복원을 지원합니다. 자세한 내용은 AKS에 대한 자격 증명 모음 계층 백업 사용 및 Azure Backup을 사용하여 지역 간 복원을 참조하세요.

참고 항목

이 문서에서는 다양한 리소스에 대한 고유 식별자를 자주 만들어야 합니다. 이 문서에서는 접두사로 규칙을 <initials><sequence-number> 사용합니다. 예를 들어 이름이 Emily Juanita Bernal인 경우 고유 식별자는 다음과 같습니다 ejb01. 모호성을 더하기 위해 오늘 날짜를 MMDD 다음과 같은 형식으로 ejb010307추가할 수 있습니다.

필수 구성 요소

Azure 구독 Azure 구독이 아직 없는 경우 시작하기 전에 체험 계정을 만듭니다.
구독에 Owner 역할 또는 Contributor 역할과 User Access Administrator 역할이 있는지 확인합니다. Azure Portal을 사용하여 Azure 역할 할당 나열의 단계에 따라 할당을 확인할 수 있습니다.
Windows, Linux 또는 macOS가 설치된 로컬 컴퓨터를 준비합니다.
Azure CLI 명령을 실행하려면 Azure CLI 버전 2.54.0 이상을 설치합니다.
kubectl을 설치하고 설정합니다.
Git을 설치하고 설정합니다.
Java SE 구현 버전 17 이상을 설치합니다(예: OpenJDK의 Microsoft 빌드).
Maven 버전 3.9.3 이상을 설치합니다.
Oracle SSO(Single Sign-On) 계정의 자격 증명이 있어야 합니다. 계정을 만들려면 Oracle 계정 만들기를 참조하세요.
다음 단계를 사용하여 WLS에 대한 사용 조건에 동의합니다.
1. Oracle Container Registry를 방문하여 로그인합니다.
2. 지원 자격이 있는 경우 미들웨어를 선택한 다음, weblogic_cpu를 검색하여 선택합니다.
3. Oracle 지원 자격이 없는 경우 미들웨어를 선택한 다음, weblogic을 검색하여 선택합니다.
4. 사용권 계약에 동의합니다.
AKS에서 WLS를 실행하려면 WLS 도메인을 이해해야 합니다. WLS 도메인에 대한 자세한 내용은 WebLogic Server 애플리케이션을 Azure Kubernetes Service 로 마이그레이션의 미리 빌드된 Azure Marketplace 제품 섹션을 사용할지 여부를 결정합니다. 이 문서에서는 외부 데이터베이스에 트랜잭션 로그 및 저장소가 있고 외부 스토리지가 없는 이미지 도메인 홈 소스 형식의 모델을 사용하여 AKS에서 WLS를 실행한다고 가정합니다.

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

이 섹션에서는 WLS 클러스터 및 앱과 함께 사용할 쌍을 이루는 지역에 Azure SQL Database 장애 조치(failover) 그룹을 만듭니다. 이후 섹션에서는 세션 데이터 및 TLOG(트랜잭션 로그) 데이터를 이 데이터베이스에 저장하도록 WLS를 구성합니다. 이 방법은 Oracle의 MAA(최대 가용성 아키텍처)와 일치합니다. 이 지침은 MAA에 대한 Azure 적응을 제공합니다. MAA에 대한 자세한 내용은 Oracle 최대 가용성 아키텍처를 참조 하세요.

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

단일 데이터베이스 만들기 섹션에 도달하면 다음 단계를 사용합니다.
1. 새 리소스 그룹을 만들기 위한 4단계에서 리소스 그룹 이름 값(예: myResourceGroup)을 따로 저장합니다.
2. 데이터베이스 이름에 대한 5단계에서 데이터베이스 이름 값(예: mySampleDatabase)을 따로 저장합니다.
3. 서버를 만들기 위한 6단계에서 다음 단계를 사용합니다.
  1. 고유한 서버 이름(예 : sqlserverprimary-ejb120623)을 따로 저장합니다.
  2. 위치의 경우 (미국) 미국 동부를 선택합니다.
  3. 인증 방법의 경우 SQL 인증 사용을 선택합니다.
  4. 서버 관리자 로그인 값(예: azureuser)을 따로 저장합니다.
  5. 암호 값을 따로 저장합니다.
4. 8단계에서 워크로드 환경의 경우 개발을 선택합니다. 설명을 살펴보고 워크로드에 대한 다른 옵션을 고려합니다.
5. 11단계에서 Backup 스토리지 중복성에 대해 로컬 중복 백업 스토리지를 선택합니다. 백업에 대한 다른 옵션을 고려합니다. 자세한 내용은 Azure SQL Database에서 자동화된 백업의 Backup 스토리지 중복성 섹션을 참조하세요.
6. 14단계의 방화벽 규칙 구성에서 Azure 서비스 및 리소스가 이 서버에 액세스하도록 허용하려면 [예]를 선택합니다.
데이터베이스 쿼리 섹션에 도달하면 다음 단계를 사용합니다.
1. 3단계에서 로그인할 SQL 인증 서버 관리자 로그인 정보를 입력합니다.
  
  참고 항목
  
  IP 주소가 'xx.xx.xx.xx.xx'인 클라이언트와 유사한 오류 메시지와 함께 로그인이 실패하면 오류 메시지 끝에 있는 서버<에서> 허용 목록 IP xx.xx.xx.xx.xx를 선택합니다. 서버 방화벽 규칙 업데이트가 완료될 때까지 기다린 다음 확인을 다시 선택합니다.
2. 5단계에서 샘플 쿼리를 실행한 후 편집기를 지우고 테이블을 만듭니다.

스키마를 만들려면 다음 쿼리를 입력합니다.

TLOG에 대한 스키마를 만들려면 다음 쿼리를 입력합니다.

create table TLOG_msp1_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp2_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp3_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp4_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp5_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table wl_servlet_sessions (wl_id VARCHAR(100) NOT NULL, wl_context_path VARCHAR(100) NOT NULL, wl_is_new CHAR(1), wl_create_time DECIMAL(20), wl_is_valid CHAR(1), wl_session_values VARBINARY(MAX), wl_access_time DECIMAL(20), wl_max_inactive_interval INTEGER, PRIMARY KEY (wl_id, wl_context_path));

성공적으로 실행되면 메시지가 Query succeeded: Affected rows: 0표시됩니다.

이러한 데이터베이스 테이블은 WLS 클러스터 및 앱에 대한 TLOG(트랜잭션 로그) 및 세션 데이터를 저장하는 데 사용됩니다. 자세한 내용은 JDBC TLOG 저장소 사용 및 영구 스토리지용 데이터베이스 사용(JDBC 지속성)을 참조하세요.

샘플 애플리케이션에 대한 스키마를 만들려면 다음 쿼리를 입력합니다.

CREATE TABLE COFFEE (ID NUMERIC(19) NOT NULL, NAME VARCHAR(255) NULL, PRICE FLOAT(32) NULL, PRIMARY KEY (ID));
CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT NUMERIC(28) NULL, PRIMARY KEY (SEQ_NAME));

성공적으로 실행되면 메시지가 Query succeeded: Affected rows: 0표시됩니다.

이제 "빠른 시작: 단일 데이터베이스 만들기 - Azure SQL Database" 문서를 완료했습니다.

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

장애 조치(failover) 그룹 만들기 섹션에 도달하면 다음 단계를 사용합니다.
1. 장애 조치(failover) 그룹을 만들기 위한 5단계에서 새 보조 서버를 만드는 옵션을 선택한 다음, 다음 단계를 사용합니다.
  1. 장애 조치(failover) 그룹 이름(예 : failovergroupname-ejb120623)을 입력하고 저장합니다.
  2. 고유한 서버 이름(예 : sqlserversecondary-ejb120623)을 입력하고 저장합니다.
  3. 주 서버와 동일한 서버 관리자 및 암호를 입력합니다.
  4. 위치의 경우 주 데이터베이스에 사용한 지역과 다른 지역을 선택합니다.
  5. Azure 서비스에서 서버에 액세스하도록 허용이 선택되어 있는지 확인합니다.
2. 그룹 내의 데이터베이스를 구성하기 위한 5단계에서 주 서버에서 만든 데이터베이스(예: mySampleDatabase)를 선택합니다.
테스트 계획된 장애조치 섹션의 모든 단계를 완료한 후 장애 조치(failover) 그룹 페이지를 열어 두고 나중에 WLS 클러스터의 장애 조치(failover) 테스트에 사용합니다.

장애 조치(failover) 그룹에 대한 JDBC 연결 문자열 및 데이터베이스 관리자 사용자 이름 가져오기

다음 단계에서는 장애 조치(failover) 그룹 내의 데이터베이스에 대한 JDBC 연결 문자열 및 데이터베이스 사용자 이름을 가져옵니다. 이러한 값은 주 데이터베이스의 해당 값과 다릅니다.

Azure Portal에서 주 데이터베이스를 배포한 리소스 그룹을 찾습니다.
리소스 목록에서 SQL 데이터베이스 형식 의 주 데이터베이스를 선택합니다.
설정에서 연결 문자열을 선택합니다.
JDBC를 선택합니다.
JDBC(SQL 인증) 아래의 텍스트 영역에서 복사 아이콘을 선택하여 JDBC 연결 문자열 값을 클립보드에 배치합니다.
텍스트 편집기에서 값을 붙여넣습니다. 다른 단계에서 편집합니다.
리소스 그룹으로 돌아갑니다.
이전 단계에서 방금 살펴본 데이터베이스가 포함된 SQL Server 유형의 리소스를 선택합니다.
데이터 관리에서 장애 조치(failover) 그룹을 선택합니다.
페이지 중간에 있는 테이블에서 장애 조치(failover) 그룹을 선택합니다.
읽기/쓰기 수신기 엔드포인트 아래의 텍스트 영역에서 복사 아이콘을 선택하여 JDBC 연결 문자열 값을 클립보드에 배치합니다.

텍스트 편집기에서 새 줄에 값을 붙여넣습니다. 이제 텍스트 편집기에서 다음 예제와 유사한 줄이 있어야 합니다.

jdbc:sqlserver://ejb010307db.database.windows.net:1433;database=ejb010307db;user=azureuser@ejb010307db;password={your_password_here};encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;
ejb010307failover.database.windows.net

다음 수정 사항을 사용하여 새 줄을 만듭니다.
1. 첫 번째 줄 전체를 복사합니다.
2. 읽기/쓰기 수신기 엔드포인트 줄에서 호스트 이름을 사용하도록 URL의 호스트 이름 부분을 변경합니다.
3. 에 대한 쌍 뒤의 name=value 모든 항목을 제거합니다 database. 즉, 바로 뒤database=ejb010307db를 ; 포함하여 모든 항목을 제거합니다.
  
  완료되면 문자열은 다음 예제와 유사하게 표시됩니다.
```
jdbc:sqlserver://ejb010307failover.database.windows.net:1433;database=ejb010307db
```
  이 값은 JDBC 연결 문자열.
동일한 텍스트 편집기에서 원래 JDBC 연결 문자열 매개 변수 값을 user 가져오고 데이터베이스 이름을 읽기/쓰기 수신기 엔드포인트 줄의 첫 번째 부분으로 바꿔 데이터베이스 사용자 이름을 파생합니다. 이전 예제를 계속 진행하면 값은 다음과 같습니다 azureuser@ejb010307failover. 이 값은 데이터베이스 관리자 사용자 이름입니다.

AKS에서 기본 WLS 클러스터 설정 및 구성

이 섹션에서는 AKS의 Oracle WebLogic Server 제품을 사용하여 AKS 에 WLS 클러스터를 만듭니다. 미국 동부의 클러스터는 주 클러스터이며 활성 클러스터로 구성됩니다.

참고 항목

AKS 제품의 Oracle WebLogic Server에 대한 자세한 내용은 다음 문서에서 확인할 수 있습니다.

샘플 앱 준비

이 섹션에서는 장애 조치(failover) 테스트를 위해 나중에 WLS 클러스터에서 배포하고 실행하는 샘플 CRUD Java/JakartaEE 애플리케이션을 빌드하고 패키지합니다.

앱은 WebLogic Server JDBC 세션 지속성을 사용하여 HTTP 세션 데이터를 저장합니다. 데이터 원본 jdbc/WebLogicCafeDB 은 세션 데이터를 저장하여 WebLogic 서버 클러스터에서 장애 조치(failover) 및 부하 분산을 사용하도록 설정합니다. 동일한 데이터 원본jdbc/WebLogicCafeDB에 애플리케이션 데이터를 coffee 유지하도록 지속성 스키마를 구성합니다.

다음 단계를 사용하여 샘플을 빌드하고 패키지합니다.

다음 명령을 사용하여 샘플 리포지토리를 복제하고 이 문서에 해당하는 태그를 확인합니다.
```
git clone https://github.com/Azure-Samples/azure-cafe.git
cd azure-cafe
git checkout 20231206
```
메시지가 Detached HEAD표시되면 무시해도 안전합니다.
다음 명령을 사용하여 샘플 디렉터리로 이동한 다음 샘플을 컴파일하고 패키지합니다.
```
cd weblogic-cafe
mvn clean package
```

패키지가 성공적으로 생성되면 부모 경로에서 local-clone>/azure-café/weblogic-café/target/weblogic-café.war에서 <찾을 수 있습니다. 이 패키지가 표시되지 않으면 문제를 해결한 후 계속 진행합니다.

샘플 애플리케이션을 저장할 스토리지 계정 및 스토리지 컨테이너 만들기

다음 단계를 사용하여 스토리지 계정 및 컨테이너를 만듭니다. 이러한 단계 중 일부는 다른 가이드와 연결됩니다. 단계를 완료한 후 WLS에 배포할 샘플 애플리케이션을 업로드할 수 있습니다.

Azure Portal에 로그인합니다.
스토리지 계정 만들기의 단계에 따라 스토리지 계정을 만듭니다. 문서의 값에 대해 다음 특수화를 사용합니다.
- 스토리지 계정에 대한 새 리소스 그룹을 만듭니다.
- 지역에 대해 미국 동부를 선택합니다.
- Storage 계정 이름의 경우 리소스 그룹 이름과 동일한 값을 사용합니다.
- 성능은 표준을 선택합니다.
- 중복성에 대해 LRS(로컬 중복 스토리지)를 선택합니다.
- 나머지 탭에는 특수화가 필요하지 않습니다.
계속해서 계정의 유효성을 검사하고 만든 다음, 이 문서로 돌아갑니다.
빠른 시작의 컨테이너 만들기 섹션인 Azure Portal을 사용하여 Blob 업로드, 다운로드 및 나열의 단계에 따라 계정 내에서 스토리지 컨테이너를 만듭니다.
동일한 문서를 사용하여 블록 Blob 업로드 섹션의 단계에 따라 이전에 빌드한 azure-café/weblogic-café/target/weblogic-café.war 패키지를 업로드합니다. 그런 다음 이 문서로 돌아갑니다.

AKS에 WLS 배포

AKS에 WLS를 배포하려면 다음 단계를 사용합니다.

브라우저에서 AKS 제품의 Oracle WebLogic Server를 열고 만들기를 선택합니다. 제품의 기본 창이 표시됩니다.
다음 단계를 사용하여 기본 사항 창을 작성 합니다 .
1. 구독에 대해 표시된 값이 필수 구성 요소 섹션에 나열된 역할이 있는 값과 동일한지 확인합니다.
2. 빈 리소스 그룹에 제품을 배포해야 합니다. 리소스 그룹 필드에서 새로 만들기를 선택하고 리소스 그룹에 대한 고유 값(예: wlsaks-eastus-20240109)을 입력합니다.
3. 인스턴스 세부 정보에서 지역에 대해 미국 동부를 선택합니다.
4. 자격 증명 WebLogic에서 각각 WebLogic 관리자 및 WebLogic 모델 암호화에 대한 암호를 제공합니다. WebLogic 관리자의 사용자 이름과 암호를 따로 저장합니다.
5. 선택적 기본 구성에서 선택적 구성에 대한 기본값 적용에 대해 아니요를 선택합니다. 선택적 구성이 표시됩니다.
6. 관리되는 서버에 대한 이름 접두사로 .를 입력합니다msp. 나중에 접두사를 TLOG_${serverName}_ 사용하여 WLS TLOG 테이블을 구성합니다. 이 문서에서는 이름이 TLOG_msp${index}_WLStore있는 TLOG 테이블을 만듭니다. 다른 관리되는 서버 이름 접두사를 원하는 경우 값이 Microsoft SQL Server 테이블 명명 규칙 및 실제 테이블 이름과 일치하는지 확인합니다.
7. 다른 필드의 기본값을 그대로 둡니다.
다음을 선택하여 AKS 창으로 이동합니다.
이미지 선택에서 다음 정보를 제공합니다.
- Oracle Single Sign-On 인증에 대한 사용자 이름의 경우 사전 조건의 Oracle SSO 사용자 이름을 입력합니다.
- Oracle Single Sign-On 인증에 대한 암호의 경우 사전 조건의 Oracle SSO 자격 증명을 입력합니다.
애플리케이션에서 다음 단계를 사용합니다.
1. 애플리케이션 섹션의 애플리케이션 배포? 옆에서 예를 선택합니다.
2. 애플리케이션 패키지(.war,.ear,.jar) 옆에서 찾아보기를 선택합니다.
3. 이전 섹션에서 스토리지 계정의 이름을 입력하기 시작합니다. 원하는 스토리지 계정이 나타나면 선택합니다.
4. 이전 섹션에서 스토리지 컨테이너를 선택합니다.
5. 이전 섹션에서 업로드한 weblogic-café.war 옆의 확인란을 선택합니다. 선택을 선택합니다.
6. 다른 필드의 기본값을 그대로 둡니다.
다음을 선택합니다.
TLS/SSL 구성 창에 기본값을 그대로 두고 다음을 선택하여 부하 분산 창으로 이동합니다.
부하 분산 창의 관리 콘솔에 대한 수신 만들기 옆에 있습니다. 경로 /console*이 있는 애플리케이션이 없는지 확인합니다. 그러면 관리 콘솔 경로와 충돌합니다. 예를 선택합니다.
다른 필드의 기본값을 그대로 두고 다음을 선택합니다 .
DNS 창에 기본값을 그대로 두고 다음을 선택하여 데이터베이스 창으로 이동합니다.
데이터베이스 창에 다음 값을 입력합니다.
- 데이터베이스에 연결하려면 [예]를 선택합니다.
- 데이터베이스 유형 선택에서 Microsoft SQL Server(암호 없는 연결 지원)를 선택합니다.
- JNDI 이름에 jdbc/WebLogicCafeDB를 입력합니다.
- DataSource 연결 문자열의 경우 JDBC 연결 문자열 대해 저장한 값을 JDBC 연결 문자열 가져오기 및 장애 조치(failover) 그룹 섹션의 데이터베이스 관리자 사용자 이름에 붙여넣습니다.
- 전역 트랜잭션 프로토콜의 경우 없음을 선택합니다.
- 데이터베이스 사용자 이름의 경우 데이터베이스 관리자 사용자 이름 에 대해 저장한 값을 JDBC 연결 문자열 가져오기 및 장애 조치(failover) 그룹 섹션의 데이터베이스 관리자 사용자 이름에 붙여넣습니다.
- 이전에 데이터베이스 암호에 저장한 데이터베이스 서버 관리자 로그인 암호를 입력합니다. 암호 확인에 대해 동일한 값을 입력합니다.
- 다른 필드의 기본값을 그대로 둡니다.
검토 + 만들기를 선택합니다.
최종 유효성 검사 실행이 완료될 때까지 기다린 다음 만들기를 선택합니다. 잠시 후 배포가 진행 중인 배포 페이지가 표시됩니다.

참고 항목

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

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

TLOG 데이터의 스토리지 구성

이 섹션에서는 WLS 이미지 모델을 ConfigMap재정의하여 TLOG 데이터의 스토리지를 구성합니다. 자세한 내용은 ConfigMapWebLogic 배포 도구 모델 ConfigMap을 참조하세요.

이 섹션에는 Azure CLI 및 kubectl이 설치된 Bash 터미널이 필요합니다. 다음 단계를 사용하여 TLOG 데이터의 스토리지를 구성하고 필요한 YAML을 파생합니다.

다음 단계를 사용하여 AKS 클러스터에 연결합니다.
1. Azure Portal을 열고 AKS의 WLS 배포 섹션에서 프로비전한 리소스 그룹으로 이동합니다.
2. 리소스 목록에서 AKS 클러스터를 선택한 다음, 연결을 선택하여 AKS 클러스터에 연결합니다.
3. Azure CLI를 선택하고 단계에 따라 로컬 터미널에서 AKS 클러스터에 연결합니다.
WLS 이미지 모델 YAML에서 항목을 가져오 topology: 려면 다음 단계를 사용합니다.
1. Azure Portal을 열고 AKS의 WLS 배포 섹션에서 프로비전한 리소스 그룹으로 이동합니다.
2. 설정>배포를 차례로 선택합니다. 이름이 oracle.20210620-wls-on-aks로 시작하는 첫 번째 배포를 선택합니다.
3. 출력을 선택합니다. shellCmdtoOutputWlsImageModelYaml 값을 클립보드에 복사합니다. 값은 모델 파일의 base64 문자열을 디코딩하고 model.yaml이라는 파일에 콘텐츠를 저장하는 셸 명령입니다.
4. 값을 Bash 터미널에 붙여넣고 명령을 실행하여 model.yaml 파일을 생성합니다.
5. 최상위 topology: 항목을 제외한 모든 콘텐츠를 제거하도록 파일을 편집합니다. 을 제외하고 topology:파일에 최상위 항목이 없어야 합니다.
6. 파일을 저장합니다.
WLS 도메인 모델 YAML에서 이름 및 네임스페이스 이름을 가져오 ConfigMap 려면 다음 단계를 사용합니다.
1. Azure Portal을 열고 AKS의 WLS 배포 섹션에서 프로비전된 리소스 그룹으로 이동합니다.
2. 설정>배포를 차례로 선택합니다. 이름이 oracle.20210620-wls-on-aks로 시작하는 첫 번째 배포를 선택합니다.
3. 출력을 선택합니다. shellCmdtoOutputWlsDomainYaml 값을 클립보드에 복사합니다. 값은 model 파일의 base64 문자열을 디코딩하고 model.yaml에 콘텐츠를 저장하는 셸 명령입니다.
4. 터미널에 값을 붙여넣으면 domain.yaml이라는 파일이 표시됩니다.
5. domain.yaml 다음 값을 확인합니다.
  - spec.configuration.model.configMap. 기본값을 수락한 경우 이 값은 .입니다 sample-domain1-wdt-config-map.
  - metadata.namespace. 기본값을 수락한 경우 이 값은 .입니다 sample-domain1-ns.
  편의를 위해 다음 명령을 사용하여 이러한 값을 셸 변수로 저장할 수 있습니다.
```
export CONFIG_MAP_NAME=sample-domain1-wdt-config-map
export WLS_NS=sample-domain1-ns
```

다음 명령을 사용하여 YAML을 ConfigMap 가져옵니다.

kubectl get configmap ${CONFIG_MAP_NAME} -n ${WLS_NS} -o yaml > configMap.yaml

다음 단계를 사용하여 tlog-db-model.yaml 파일을 만듭니다.
1. 텍스트 편집기에서 tlog-db-model.yaml이라는 빈 파일을 만듭니다.
2. model.yaml의 내용을 삽입하고 빈 줄을 추가한 다음 configMap.yaml 파일의 내용을 삽입합니다.

tlog-db-model.yaml 파일에서 줄 끝 ListenPort: 8001찾습니다. 다음 줄 TransactionLogJDBCStore 에 이 텍스트를 추가합니다. 다음 예제와 같이 정확히 아래에 ListenPort 있고 다음 코드 조각의 나머지 줄은 두 줄로 들여쓰기됩니다.

TransactionLogJDBCStore:
  Enabled: true
  DataSource: jdbc/WebLogicCafeDB
  PrefixName: TLOG_${serverName}_

완성된 tlog-db-model.yaml 은 다음 예제와 매우 가깝게 표시됩니다.

topology:
  Name: "@@ENV:CUSTOM_DOMAIN_NAME@@"
  ProductionModeEnabled: true
  AdminServerName: "admin-server"
  Cluster:
    "cluster-1":
      DynamicServers:
        ServerTemplate: "cluster-1-template"
        ServerNamePrefix: "@@ENV:MANAGED_SERVER_PREFIX@@"
        DynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
        MaxDynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
        MinDynamicClusterSize: "0"
        CalculatedListenPorts: false
  Server:
    "admin-server":
      ListenPort: 7001
  ServerTemplate:
    "cluster-1-template":
      Cluster: "cluster-1"
      ListenPort: 8001
      TransactionLogJDBCStore:
        Enabled: true
        DataSource: jdbc/WebLogicCafeDB
        PrefixName: TLOG_${serverName}_
  SecurityConfiguration:
    NodeManagerUsername: "@@SECRET:__weblogic-credentials__:username@@"
    NodeManagerPasswordEncrypted: "@@SECRET:__weblogic-credentials__:password@@"

resources:
  JDBCSystemResource:
    jdbc/WebLogicCafeDB:
      Target: 'cluster-1'
      JdbcResource:
        JDBCDataSourceParams:
          JNDIName: [
            jdbc/WebLogicCafeDB
          ]
          GlobalTransactionsProtocol: None
        JDBCDriverParams:
          DriverName: com.microsoft.sqlserver.jdbc.SQLServerDriver
          URL: '@@SECRET:ds-secret-sqlserver-1709938597:url@@'
          PasswordEncrypted: '@@SECRET:ds-secret-sqlserver-1709938597:password@@'
          Properties:
            user:
              Value: '@@SECRET:ds-secret-sqlserver-1709938597:user@@'
        JDBCConnectionPoolParams:
            TestTableName: SQL SELECT 1
            TestConnectionsOnReserve: true

를 사용하여 WLS 모델을 재정의합니다 ConfigMap. WLS 모델을 재정의하려면 기존 ConfigMap 모델을 새 모델로 바꿉다. 자세한 내용은 Oracle 설명서의 기존 모델 업데이트를 참조하세요. 다음 명령을 실행하여 다음을 다시 만듭니다 ConfigMap.

export CM_NAME_FOR_MODEL=sample-domain1-wdt-config-map
kubectl -n sample-domain1-ns delete configmap ${CM_NAME_FOR_MODEL}

# replace path of tlog-db-model.yaml
kubectl -n sample-domain1-ns create configmap ${CM_NAME_FOR_MODEL} \
  --from-file=tlog-db-model.yaml
kubectl -n sample-domain1-ns label configmap ${CM_NAME_FOR_MODEL} \
  weblogic.domainUID=sample-domain1

다음 명령을 사용하여 WLS 클러스터를 다시 시작합니다. 새 모델이 작동하려면 롤링 업데이트를 수행해야 합니다.

export RESTART_VERSION=$(kubectl -n sample-domain1-ns get domain sample-domain1 '-o=jsonpath={.spec.restartVersion}')
# increase restart version
export RESTART_VERSION=$((RESTART_VERSION + 1))

kubectl -n sample-domain1-ns patch domain sample-domain1 \
    --type=json \
    '-p=[{"op": "replace", "path": "/spec/restartVersion", "value": "'${RESTART_VERSION}'" }]'

계속 진행하기 전에 WLS Pod가 실행되고 있는지 확인합니다. 다음 명령을 사용하여 Pod의 상태를 볼 수 있습니다.

kubectl get pod -n sample-domain1-ns -w

참고 항목

이 문서에서 WLS 모델은 AKS 제품의 WLS에서 만든 애플리케이션 컨테이너 이미지에 포함됩니다. TLOG는 모델 파일을 포함하고 도메인 CRD configuration.model.configMap 필드를 사용하여 맵을 참조하는 WDT ConfigMap 를 사용하여 기존 모델을 재정의하여 구성됩니다. 프로덕션 시나리오 에서 보조 이미지는 Pod에 이미지 모델 파일, 애플리케이션 보관 파일 및 WebLogic 배포 도구 설치에 모델을 포함하는 데 가장 적합한 방법입니다. 이 기능은 에 지정된 domain.spec.image이미지에 이러한 파일을 제공할 필요가 없습니다.

Azure Backup을 사용하여 지역 중복 구성

이 섹션에서는 Azure Backup을 사용하여 클러스터에 설치해야 하는 Backup 확장을 사용하여 AKS 클러스터를 백업합니다.

다음 단계를 사용하여 지역 중복성을 구성합니다.

샘플 애플리케이션 섹션을 저장할 스토리지 계정 및 스토리지 컨테이너 만들기에서 만든 스토리지 계정에서 AKS 백업 확장에 대한 새 스토리지 컨테이너를 만듭니다.

다음 명령을 사용하여 AKS 백업 확장을 설치하고 클러스터에 대한 CSI 드라이버 및 스냅샷을 사용하도록 설정합니다.

#replace with your resource group name.
export RG_NAME=wlsaks-eastus-20240109
export AKS_NAME=$(az aks list \
    --resource-group ${RG_NAME} \
    --query "[0].name" \
    --output tsv)

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

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

AKS가 배포된 리소스 그룹을 엽니다. 리소스 목록에서 AKS 클러스터를 선택합니다.
AKS 방문 페이지에서 설치 확장 설정>백업을>선택합니다.
AKS Backup 확장 설치 페이지에서 다음을 선택합니다. 이전 단계에서 만든 스토리지 계정 및 Blob 컨테이너를 선택합니다. 다음, 만들기를 차례로 선택합니다. 이 단계를 완료하는 데 약 5분이 걸립니다.

Azure Portal을 열고 위쪽의 검색 창에서 Backup 자격 증명 모음을 검색합니다. 서비스 아래에 나열된 것이 표시됩니다. 이 폴더를 선택합니다.
AKS Backup을 사용하도록 설정하려면 Azure Backup을 사용하여 Azure Kubernetes Service 백업의 단계를 수행합니다. "AKS 백업 중에 후크 사용" 섹션은 포함하지 않습니다. 다음 단계에 표시된 조정을 수행합니다.
"Backup 자격 증명 모음 만들기" 섹션에 도달하면 다음을 조정합니다.
- 1단계의 경우 지역 아래에서 미국 동부를 선택합니다. 백업 스토리지 중복에서 전역 중복을 사용합니다.
- 2단계에서는 지역 간 복원을 사용하도록 설정합니다.
"백업 정책 만들기" 섹션에 도달하면 보존 정책을 만들라는 메시지가 표시되면 다음을 조정합니다.
1. Vault 표준이 선택된 보존 규칙을 추가합니다.
2. 추가를 선택합니다.
"백업 구성" 섹션에 도달하면 다음을 조정합니다. 1-5단계는 AKS 확장 설치를 위한 것입니다. 1-5단계를 건너뛰고 6단계에서 시작합니다.
- 7단계에서는 사용 권한 오류가 발생합니다. 계속 진행하려면 권한 부여를 선택합니다. 권한 배포가 완료된 후에도 오류가 계속 표시되면 유효성 재검사(Revalidate)를 선택하여 역할 할당을 새로 고칩니다.
- 10단계에서 백업할 리소스 선택을 찾아 다음을 조정합니다.
  - Backup 인스턴스 이름의 경우 고유한 이름을 입력합니다.
  - 네임스페이스의 경우 WebLogic 연산자 및 WebLogic Server에 대한 네임스페이스를 선택합니다. 이 문서에서는 weblogic-operator-ns 및 sample-domain1-ns를 선택합니다.
  - 기타 옵션의 경우 모든 옵션을 선택합니다. 비밀 포함이 선택되어 있는지 확인합니다.
- 11단계에서는 역할 할당 오류가 발생합니다. 목록에서 데이터 원본을 선택하고 누락된 역할 할당을 선택하여 오류를 완화합니다.

보조 지역에서 WLS 클러스터 복원 준비

이 섹션에서는 보조 지역에서 WLS 클러스터를 복원할 준비를 합니다. 여기서 보조 지역은 미국 서부입니다. 복원하기 전에 미국 서부 지역에 AKS Backup 확장이 설치된 AKS 클러스터가 있어야 합니다.

지역에서 복제를 위한 Azure Container Registry 구성

다음 단계를 사용하여 지역 복제를 위해 ACR(Azure Container Registry)을 구성합니다. 여기에는 AKS의 WLS 배포 섹션에서 만든 WLS 이미지가 포함되어 있습니다. ACR 복제를 사용하도록 설정하려면 프리미엄 가격 책정 계획으로 업그레이드해야 합니다. 자세한 내용은 Azure Container Registry의 지역에서 복제를 참조하세요.

AKS의 WLS 배포 섹션에서 프로비전한 리소스 그룹을 엽니다. 리소스 목록에서 이름이 wlsaksacr로 시작하는 ACR을 선택합니다.
ACR 방문 페이지에서 설정>속성을 선택합니다. 가격 책정 플랜의 경우 프리미엄을 선택한 다음 저장을 선택합니다.
탐색 창에서 서비스 지역 복제를> 선택합니다. 추가를 선택하여 페이지에서 복제 지역을 추가합니다.
복제 만들기 페이지의 위치에 대해 미국 서부를 선택한 다음 만들기를 선택합니다.

배포가 완료되면 지역 복제에 대해 ACR이 활성화됩니다.

보조 지역에 스토리지 계정 만들기

AKS Backup 확장을 사용하도록 설정하려면 스토리지 계정에 동일한 지역에 빈 컨테이너를 제공해야 합니다.

지역 간 백업을 복원하려면 백업 데이터가 수화되는 스테이징 위치를 제공해야 합니다. 이 스테이징 위치에는 복원을 위한 대상 클러스터와 동일한 지역 및 구독 내에 리소스 그룹 및 스토리지 계정이 포함됩니다.

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

Azure Portal에 로그인합니다.
스토리지 계정 만들기의 단계에 따라 스토리지 계정을 만듭니다. 문서의 모든 단계를 수행할 필요는 없습니다. 기본 창에 표시된 필드를 채웁니다 . 지역의 경우 미국 서부를 선택한 다음 검토 + 만들기를 선택하여 기본 옵션을 적용합니다. 계속해서 계정의 유효성을 검사하고 만든 다음, 이 문서로 돌아갑니다.
빠른 시작의 컨테이너 만들기 섹션인 Azure Portal을 사용하여 Blob 업로드, 다운로드 및 나열 섹션의 단계에 따라 AKS Backup 확장에 대한 스토리지 컨테이너를 만듭니다.
복원하는 동안 사용할 준비 위치로 스토리지 컨테이너를 만듭니다.

보조 지역에서 AKS 클러스터 준비

다음 섹션에서는 보조 지역에서 AKS 클러스터를 만드는 방법을 보여 줍니다.

새 AKS 클러스터 만들기

이 문서에서는 Application Gateway 수신 컨트롤러를 사용하여 WLS 애플리케이션을 노출합니다. 이 섹션에서는 미국 서부 지역에 새 AKS 클러스터를 만듭니다. 그런 다음 새 애플리케이션 게이트웨이 인스턴스에서 수신 컨트롤러 추가 기능을 사용하도록 설정합니다. 자세한 내용은 새 애플리케이션 게이트웨이 인스턴스를 사용하여 새 AKS 클러스터에 대한 수신 컨트롤러 추가 기능 사용을 참조 하세요.

AKS 클러스터를 만들려면 다음 단계를 사용합니다.

다음 명령을 사용하여 보조 지역에 리소스 그룹을 만듭니다.

export RG_NAME_WESTUS=wlsaks-westus-20240109

az group create --name ${RG_NAME_WESTUS} --location westus

다음 명령을 사용하여 추가 기능을 사용하도록 설정된 AKS 클러스터를 배포합니다.
```
export AKS_NAME_WESTUS=${RG_NAME_WESTUS}aks
export GATEWAY_NAME_WESTUS=${RG_NAME_WESTUS}gw

az aks create \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --network-plugin azure \
    --enable-managed-identity \
    --enable-addons ingress-appgw \
    --appgw-name ${GATEWAY_NAME_WESTUS} \
    --appgw-subnet-cidr "10.225.0.0/16" \
    --generate-ssh-keys
```
이 명령은 AKS 노드 리소스 그룹의 이름을 ${RG_NAME_WESTUS}gw 사용하여 Standard_v2 SKU 애플리케이션 게이트웨이 인스턴스를 자동으로 만듭니다. 노드 리소스 그룹의 이름은 기본적으로 지정 MC_resource-group-name_cluster-name_location 됩니다.

참고 항목

AKS의 WLS 배포 섹션에서 프로비전한 AKS 클러스터는 미국 동부 지역의 세 가지 가용성 영역에서 실행됩니다. 가용성 영역은 미국 서부 지역에서 지원되지 않습니다. 미국 서부의 AKS 클러스터는 영역 중복이 아닙니다. 프로덕션 환경에 영역 중복성이 필요한 경우 쌍을 이루는 지역이 가용성 영역을 지원하는지 확인합니다. 자세한 내용은 가용성 영역을 사용하는 AKS(Azure Kubernetes Service) 클러스터 만들기의 AKS 클러스터에 대한 가용성 영역 개요 섹션을 참조하세요.

다음 명령을 사용하여 애플리케이션 게이트웨이 인스턴스의 공용 IP 주소를 가져옵니다. 이 문서의 뒷부분에서 사용하는 IP 주소를 따로 저장합니다.

export APPGW_ID=$(az aks show \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS} \
    --query 'addonProfiles.ingressApplicationGateway.config.effectiveApplicationGatewayId' \
    --output tsv)
echo ${APPGW_ID}
export APPGW_IP_ID=$(az network application-gateway show \
    --id ${APPGW_ID} \
    --query frontendIPConfigurations\[0\].publicIPAddress.id \
    --output tsv)
echo ${APPGW_IP_ID}
export APPGW_IP_ADDRESS=$(az network public-ip show \
    --id ${APPGW_IP_ID} \
    --query ipAddress \
    --output tsv)
echo "App Gateway pubilc IP address: ${APPGW_IP_ADDRESS}"

다음 명령을 사용하여 DNS(도메인 이름 서비스) 이름 레이블을 공용 IP 주소 리소스에 연결합니다. 적절한 값(예ejb010316: .)으로 대체 <your-chosen-DNS-name> 합니다.
```
az network public-ip update --ids ${APPGW_IP_ID} --dns-name <your-chosen-DNS-name>
```
를 사용하여 공용 IP az network public-ip show의 FQDN(정규화된 도메인 이름)을 확인할 수 있습니다. 다음 예제에서는 DNS 레이블 ejb010316이 있는 FQDN을 보여줍니다.
```
az network public-ip show \
    --id ${APPGW_IP_ID} \
    --query dnsSettings.fqdn \
    --output tsv
```
이 명령은 다음 예제와 유사한 출력을 생성합니다.
```
ejb010316.westus.cloudapp.azure.com
```

참고 항목

기존 AKS 클러스터로 작업하는 경우 계속 진행하기 전에 다음 두 작업을 완료합니다.

기존 AKS 클러스터에 대한 애플리케이션 게이트웨이 수신 컨트롤러 추가 기능 사용의 단계에 따라 수신 컨트롤러 추가 기능을 사용하도록 설정합니다.
대상 네임스페이스에서 실행 중인 WLS가 있는 경우 충돌을 방지하려면 WebLogic Operator 네임스페이스 및 WebLogic Server 네임스페이스에서 WLS 리소스를 정리합니다. 이 문서에서 AKS의 WLS 제품은 네임스페이스의 WebLogic 연산자와 네임스페이 weblogic-operator-ns 스의 WebLogic Server를 프로비전했습니다 sample-domain1-ns. 실행 kubectl delete namespace weblogic-operator-ns sample-domain1-ns 하여 두 네임스페이스를 삭제합니다.

AKS 백업 확장 사용

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

다음 명령을 사용하여 미국 서부 지역의 AKS 클러스터에 연결합니다.

az aks get-credentials \
    --resource-group ${RG_NAME_WESTUS} \
    --name ${AKS_NAME_WESTUS}

다음 명령을 사용하여 클러스터에 대한 CSI 드라이버 및 스냅샷을 사용하도록 설정합니다.

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

AKS가 배포된 리소스 그룹을 엽니다. 리소스 목록에서 AKS 클러스터를 선택합니다.
AKS 방문 페이지에서 설치 확장 설정>백업을>선택합니다.
AKS Backup 확장 설치 페이지에서 다음을 선택합니다. 이전 단계에서 만든 스토리지 계정 및 Blob 컨테이너를 선택합니다. 다음, 만들기를 차례로 선택합니다. 이 단계를 완료하는 데 약 5분이 걸립니다.

참고 항목

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

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

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

주 클러스터 중지

기본 WLS 클러스터 및 보조 WLS 클러스터는 동일한 TLOG 데이터베이스로 구성됩니다. 하나의 클러스터만 동시에 데이터베이스를 소유할 수 있습니다. 보조 클러스터가 올바르게 작동하는지 확인하려면 주 WLS 클러스터를 중지합니다. 이 문서에서는 다음 단계를 사용하여 AKS 클러스터를 중지하여 WLS 클러스터를 사용하지 않도록 설정합니다.

Azure Portal을 열고 AKS의 WLS 배포 섹션에서 프로비전한 리소스 그룹으로 이동합니다.
리소스 그룹에 나열된 AKS 클러스터를 엽니다.
중지를 선택하여 AKS 클러스터를 중지합니다. 계속 진행하기 전에 배포가 완료되었는지 확인합니다.

WLS 클러스터 복원

AKS 백업은 운영 계층 및 자격 증명 모음 계층 백업을 모두 지원합니다. 자격 증명 모음 계층에 저장된 백업만 다른 지역(Azure 쌍으로 연결된 지역)의 클러스터로 복원하는 데 사용할 수 있습니다. 백업 정책에 설정된 보존 규칙에 따라 하루의 첫 번째 성공적인 백업이 Blob 컨테이너 교차 지역으로 이동됩니다. 자세한 내용은 AKS 백업이 지원하는 백업 스토리지 계층을 참조하세요. Azure Kubernetes Service 백업이란?

Azure Backup을 사용하여 지역 중복성 구성 섹션에서 지역 중복성을 구성한 후에는 자격 증명 모음 계층 백업을 복원하는 데 하루 이상이 걸립니다.

다음 단계를 사용하여 WLS 클러스터를 복원합니다.

Azure Portal을 열고 Backup 센터를 검색합니다. 서비스 아래에서 Backup 센터를 선택합니다.
관리에서 Backup 인스턴스를 선택합니다. 데이터 원본 형식 Kubernetes Services 를 필터링하여 이전 섹션에서 만든 백업 인스턴스를 찾습니다.
복원 지점 목록을 보려면 백업 인스턴스를 선택합니다. 이 문서에서 인스턴스 이름은 다음과 유사한 wlsonaks*\wlsaksinstance20240109문자열입니다.
최신 운영 및 자격 증명 모음 표준 백업을 선택한 다음, 추가 옵션을 선택합니다. 복원을 선택하여 복원 프로세스를 시작합니다.
복원 페이지에서 기본 창은 복원 지점입니다. [이전]을 선택하여 기본 창으로 변경합니다. 복원 지역의 경우 보조 지역을 선택한 다음, 다음: 복원 지점을 선택합니다.
복원 지점 창에서 복원할 계층을 선택하려면 자격 증명 모음 저장소를 선택한 다음, 다음:복원 매개 변수를 선택합니다.
복원 매개 변수 창에서 다음 단계를 사용합니다.
1. 대상 클러스터 선택에서 미국 서부 지역에서 만든 AKS 클러스터를 선택합니다. 다음 스크린샷과 같이 사용 권한 문제가 발생합니다. 권한을 부여하여 오류를 완화합니다.
2. 백업 준비 위치의 경우 미국 서부에서 만든 스토리지 계정을 선택합니다. 다음 스크린샷과 같이 사용 권한 문제가 발생합니다. 누락된 역할 할당을 선택하여 오류를 완화합니다.
3. 역할 할당이 완료된 후에도 오류가 계속 발생하는 경우 유효성 재검사(Revalidate)를 선택하여 권한을 새로 고칩니다.
4. 누락된 권한을 부여할 때 범위를 지정하라는 메시지가 표시되면 기본값을 적용합니다.
5. 유효성 확인을 선택합니다. 유효성 검사가 성공적으로 완료된 메시지가 표시됩니다. 그렇지 않으면 계속하기 전에 문제를 해결하고 해결합니다.
다음:검토 + 복원을 선택한 다음 복원을 선택합니다. WLS 클러스터를 복원하는 데 약 10분이 걸립니다.
다음 스크린샷과 같이 Backup 센터>모니터링 + 백업 보고>작업에서 복원 프로세스를 모니터링할 수 있습니다.
새로 고침을 선택하여 최신 진행률을 확인합니다.
프로세스가 오류 없이 완료되면 백업 AKS 클러스터를 중지합니다. 이렇게 하지 않으면 이후 단계에서 TLOG 데이터베이스에 액세스할 때 소유권 충돌이 발생합니다.
기본 클러스터를 시작합니다.

Azure Traffic Manager 설정

이 섹션에서는 전역 Azure 지역에 걸쳐 공용 애플리케이션에 트래픽을 배포하기 위한 Azure Traffic Manager를 만듭니다. 기본 엔드포인트는 주 WLS 클러스터의 Azure 애플리케이션 게이트웨이를 가리키고 보조 엔드포인트는 보조 WLS 클러스터의 Azure 애플리케이션 게이트웨이를 가리킵니다.

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

Traffic Manager 프로필 만들기 섹션에 도달하면 2단계에서 Traffic Manager 프로필 만들기에서 다음 단계를 사용합니다.
1. 이름에 대한 고유한 Traffic Manager 프로필 이름(예: tmprofile-ejb120623)을 따로 저장합니다.
2. 리소스 그룹의 새 리소스 그룹 이름(예: myResourceGroupTM1)을 따로 저장합니다.
Traffic Manager 엔드포인트 추가 섹션 에 도달하면 다음 단계를 사용합니다.
1. 단계 후 검색 결과에서 프로필을 선택하고 다음 단계를 사용합니다.
  1. 설정에서 구성을 선택합니다.
  2. DNS TTL(Time to Live)의 경우 10을 입력합니다.
  3. 엔드포인트 모니터 설정에서 경로에 대해 /weblogic/ready를 입력합니다.
  4. 빠른 엔드포인트 장애 조치(failover) 설정에서 다음 값을 사용합니다.
    - 내부 검색의 경우 10을 입력합니다.
    - 허용되는 오류 수의 경우 3을 입력합니다.
    - 프로브 시간 제한의 경우 5입니다.
  5. 저장을 선택합니다. 완료될 때까지 기다립니다.
2. 기본 엔드포인트 myPrimaryEndpoint를 추가하기 위한 4단계에서 다음 단계를 사용합니다.
  1. 대상 리소스 유형의 경우 공용 IP 주소를 선택합니다.
  2. 공용 IP 주소 선택 드롭다운을 선택하고 이전에 저장한 미국 동부 WLS 클러스터에 배포된 Application Gateway의 IP 주소를 입력합니다. 일치하는 항목이 하나 표시됩니다. 공용 IP 주소에 대해 선택합니다.
3. 장애 조치/보조 엔드포인트 myFailoverEndpoint를 추가하기 위한 6단계에서 다음 단계를 사용합니다.
  1. 대상 리소스 유형의 경우 공용 IP 주소를 선택합니다.
  2. 공용 IP 주소 선택 드롭다운을 선택하고 이전에 저장한 미국 서부 WLS 클러스터에 배포된 Application Gateway의 IP 주소를 입력합니다. 일치하는 항목이 하나 표시됩니다. 공용 IP 주소에 대해 선택합니다.
4. 잠시 기다립니다. 모니터 상태가 다음 상태에 도달할 때까지 새로 고침을 선택합니다.
  - 기본 엔드포인트는 Online입니다.
  - 장애 조치(failover) 엔드포인트가 저하되었습니다.
Test Traffic Manager 프로필 섹션에 도달하면 다음 단계를 사용합니다.
1. 하위 섹션에서 DNS 이름을 확인하고, 3단계에서 Traffic Manager 프로필의 DNS 이름을 따로 저장합니다(예: http://tmprofile-ejb120623.trafficmanager.net).
2. 하위 섹션에서 실행 중인 Traffic Manager 보기에서 다음 단계를 사용합니다.
  1. 1단계와 3단계에서는 웹 브라우저에서 Traffic Manager 프로필의 DNS 이름(예http://tmprofile-ejb120623.trafficmanager.net/weblogic/ready: )에 /weblogic/ready를 추가합니다. 오류 메시지 없이 빈 페이지가 표시됩니다.
  2. 4단계에서는 보조 클러스터가 중지되어 예상되는 /weblogic/ready에 액세스할 수 없습니다.
  3. 기본 엔드포인트를 다시 사용하도록 설정합니다.

이제 기본 엔드포인트에는 사용 및 온라인 상태가 있으며 장애 조치(failover) 엔드포인트에는 Traffic Manager 프로필에서 사용 및 성능 저하 상태가 있습니다. 나중에 엔드포인트 상태를 모니터링하기 위해 페이지를 열어 두세요.

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

장애 조치(failover)를 테스트하려면 이 섹션에서 주 데이터베이스 서버 및 WLS 클러스터를 보조 데이터베이스 서버 및 WLS 클러스터로 수동으로 장애 조치(failover)합니다.

주 클러스터는 실행 중이므로 활성 클러스터 역할을 하며 Traffic Manager 프로필에서 라우팅된 모든 사용자 요청을 처리합니다.

브라우저의 새 탭에서 Azure Traffic Manager 프로필의 DNS 이름을 열고 배포된 앱의 컨텍스트 루트 /weblogic-café 를 추가합니다. 예를 들면 다음과 같습니다 http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe. 이름 및 가격으로 새 커피를 만듭니다(예: 가격이 10인 커피 1). 이 항목은 데이터베이스의 애플리케이션 데이터 테이블과 세션 테이블 모두에 유지됩니다. 표시되는 UI는 다음 스크린샷과 유사해야 합니다.

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

페이지를 열어 두면 나중에 장애 조치(failover) 테스트에 사용할 수 있습니다.

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

다음 단계를 사용하여 기본에서 보조로 장애 조치(failover)합니다.

먼저 다음 단계를 사용하여 기본 AKS 클러스터를 중지합니다.

Azure Portal을 열고 AKS의 WLS 배포 섹션에서 프로비전된 리소스 그룹으로 이동합니다.
리소스 그룹에 나열된 AKS 클러스터를 엽니다.
중지를 선택하여 AKS 클러스터를 중지합니다. 계속 진행하기 전에 배포가 완료되었는지 확인합니다.

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

Azure SQL Database 장애 조치(failover) 그룹의 브라우저 탭으로 전환합니다.
장애 조치(Failover>)를 선택합니다.
완료될 때까지 기다립니다.

다음으로, 다음 단계를 사용하여 보조 클러스터를 시작합니다.

Azure Portal을 열고 보조 지역에 AKS 클러스터가 있는 리소스 그룹으로 이동합니다.
리소스 그룹에 나열된 AKS 클러스터를 엽니다.
시작을 선택하여 AKS 클러스터를 시작합니다. 계속 진행하기 전에 배포가 완료되었는지 확인합니다.

마지막으로 다음 단계를 사용하여 엔드포인트 myFailoverEndpoint 가 온라인 상태인 후 샘플 앱을 확인합니다.

Traffic Manager의 브라우저 탭으로 전환한 다음 엔드포인트 myFailoverEndpoint 의 모니터 상태 값이 온라인 상태로 전환될 때까지 페이지를 새로 고칩니다.
샘플 앱의 브라우저 탭으로 전환하고 페이지를 새로 고칩니다. 다음 스크린샷과 같이 애플리케이션 데이터 테이블과 UI에 표시되는 세션 테이블에 동일한 데이터가 유지됩니다.

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

참고 항목

프로덕션 준비 HA/DR 솔루션은 정기적으로 주 클러스터에서 보조 클러스터로 WLS 구성을 지속적으로 복사하는 것을 고려합니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 이 문서의 끝에 있는 Oracle 설명서에 대한 참조를 참조하세요.

장애 조치(failover)를 자동화하려면 Traffic Manager 메트릭 및 Azure Automation에 대한 경고를 사용하는 것이 좋습니다. 자세한 내용은 Traffic Manager 메트릭 및 경고의 Traffic Manager 메트릭에 대한 경고 섹션을 참조하고 경고를 사용하여 Azure Automation Runbook을 트리거합니다.

기본 사이트로 장애 복구

기본 사이트로 장애 복구하려면 두 클러스터에 미러 백업 구성이 있는지 확인해야 합니다. 다음 단계를 사용하여 이 상태를 달성할 수 있습니다.

4단계부터 Azure Backup을 사용하여 지역 중복 구성 섹션의 단계에 따라 미국 서부 지역에서 AKS 클러스터 백업을 사용하도록 설정합니다.
보조 지역 섹션에서 WLS 클러스터 복원 준비 섹션의 단계에 따라 미국 동부 지역의 클러스터에 최신 자격 증명 모음 계층 백업을 복원합니다. 이미 완료한 단계를 건너뜁니다.
보조 사이트 섹션에 대한 장애 조치(failover)의 유사한 단계를 사용하여 데이터베이스 서버 및 클러스터를 포함한 기본 사이트로 장애 복구합니다.

리소스 정리

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

Azure Portal 위쪽의 검색 상자에 Backup 자격 증명 모음을 입력하고 검색 결과에서 백업 자격 증명 모음을 선택합니다.
속성>관리>일시 삭제>업데이트를 선택합니다. 일시 삭제 사용 옆의 확인란 선택을 취소합니다.
Backup 인스턴스 관리를>선택합니다. 만든 인스턴스를 선택하고 삭제합니다.
Azure Portal 맨 위에 있는 검색 상자에 Azure SQL Database 서버의 리소스 그룹 이름(예 myResourceGroup: )을 입력하고 검색 결과에서 일치하는 리소스 그룹을 선택합니다.
리소스 그룹 삭제를 선택합니다.
리소스 그룹 이름을 입력하여 삭제를 확인하려면 리소스 그룹 이름을 입력합니다.
삭제를 선택합니다.
Traffic Manager의 리소스 그룹에 대해 4-7단계를 반복합니다(예: myResourceGroupTM1).
기본 WLS 클러스터의 리소스 그룹에 대해 4-7단계를 반복합니다(예 wls-aks-eastus-20240109: .).
보조 WLS 클러스터의 리소스 그룹에 대해 4-7단계를 반복합니다. 예를 들면 다음과 같습니다 wls-aks-westus-20240109.

다음 단계

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

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

Oracle Fusion 미들웨어 제품에 대한 재해 복구 솔루션

Azure 안정성 설명서

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

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

Azure VM의 Oracle WebLogic에 대해 자세히 알아보기

AKS의 Oracle WebLogic에 대해 자세히 알아보기