FMW 확장 클러스터 설정

지역 설정

Oracle Fusion Middleware(FMW) 확장된 클러스터 모델은 두 개의 별도 사이트에서 구성됩니다.

Oracle Cloud Infrastructure(OCI)에서는 OCI 리전 간에 짧은 대기 시간이 있는 리전을 통해 구현할 수 있습니다. 지원되는 최대 영역 간 대기 시간은 10ms RTT(왕복 시간)입니다. 네트워킹, 네트워크 명령 센터, 영역 간 대기 시간 순으로 선택하여 OCI 콘솔에서 영역 간 대기 시간을 확인할 수 있습니다.

대기 시간 값을 고려하면 6-7ms의 RTT가 있는 프랑크푸르트와 암스테르담과 같은 지역 간에 이 모델을 배포할 수 있습니다. 그러나 애슈번과 피닉스와 같은 위치 간에는 이 모델을 배포할 수 없습니다. 해당 지역 간의 대기 시간이 50ms RTT를 초과하기 때문입니다.

영역 간 대기 시간이 10ms RTT보다 낮은 영역 쌍의 예:

암스테르담(AMS) - 파리(CDG)
암스테르담(AMS) - 뉴포트(CWL)
암스테르담(AMS) - 프랑크푸르트(FRA)
암스테르담(AMS) - 런던(LHR)
파리(CDG) - 프랑크푸르트(FRA)
파리(CDG) - 런던(LHR)
파리(CDG) - 뉴포트(CWL)
마르세유(MRS) - 밀라노(LIN)
취리히(ZHR) - 프랑크푸르트(FRA)
취리히(ZHR) - 밀라노(LIN)
오사카(KIX) - 도쿄(NRT)
싱가포르(SIN) - 바탄(HSG)
상파울루(GRU) - 비녜두(VCP)
싱가포르(SIN) - 싱가포르 2(XSP)
바탄(HSG) - 싱가포르 2(XSP)
서울(ICN) - 춘천(YNY)
토론토(YYZ) - 몬트리올(YUL)

대역폭과 관련하여 OCI 지역 간 대역폭이 보장되지 않으며 OCI는 특정 OCI 대역폭 측정 도구를 제공하지 않습니다. 정확한 대역폭 측정을 위해서는 iPerf와 같은 도구를 사용하십시오. 프랑크푸르트와 암스테르담 사이의 테스트된 대역폭은 초당 약 2~2.5기가비트입니다(Gbps).

또한 동일한 리전에 있는 가용성 도메인(AD) 간에 이 모델을 구현할 수 있습니다. AD에 Oracle WebLogic Server 서버를 배치하는 것은 실제로 Oracle SOA Suite on Marketplace 및 Oracle WebLogic Server for OCI 스택과 같은 서비스형 플랫폼(PaaS) 서비스의 표준 동작입니다. 그러나 여러 지역이 아닌 AD 전반에서 이 모델을 구현하는 것은 전체 지역에 영향을 미치는 이벤트로부터 보호하지 않기 때문에 재해 방지 솔루션이 아닙니다.

참고:

각 사이트의 FMW 배치에 필요한 서브넷, 규칙, 컴퓨트 인스턴스, 공유 스토리지 및 로드 밸런서를 생성하려면 WLS-HYDR 프레임워크를 사용할 수 있습니다("인프라 생성" 절차 참조).

네트워크 설정

이 토폴로지를 배치하는 영역의 VCN(가상 클라우드 네트워크)은 클러스터의 모든 WebLogic 서버와 WebLogic 서버에서 데이터베이스로의 트래픽을 허용하도록 상호 연결되어야 합니다.

다음 네트워킹 기능이 설치에 필요합니다.

각 리전의 VCN 및 계층형 서브넷
DRG(동적 경로 지정 게이트웨이)를 사용하는 VCN 간 원격 피어링 접속입니다.
사이트 간 트래픽 경로를 지정하는 적절한 경로 규칙입니다. 리전 1에서 라우트 테이블은 동적 라우팅 게이트웨이를 통한 리전 2 VCN CIDR에 대한 라우트를 포함해야 합니다. 마찬가지로 리전 2 라우트 테이블에는 동적 라우팅 게이트웨이를 통과하는 리전 1 VCN CIDR에 대한 라우트가 포함되어야 합니다.
확장된 클러스터에 대해 다음 통신을 허용하는 네트워크 보안 규칙:
- 영역 1과 영역 2의 중간 계층 서브넷 사이에 있는 WebLogic 서버 및 노드 관리자 포트를 엽니다. Coherence가 사용되는 경우 Coherence 포트에 대한 TCP 및 UDP 트래픽도 허용합니다.
- 영역 1 및 영역 2의 중간 계층 서브넷에서 두 영역의 데이터베이스 리스너 및 Oracle Cloud Infrastructure Notifications(ONS) 포트에 대한 트래픽을 허용합니다.
- 기본적으로 OHS와 WebLogic 서버 간에 영역 간 통신이 필요하지 않습니다. 중간 계층 서브넷의 WebLogic Server 포트는 동일한 영역 내의 OHS 서버에서만 액세스할 수 있어야 합니다. 그러나 리전 간 통신은 리전의 모든 웹 서버가 실패하는 경우와 같이 예외적인 상황에서 필요할 수 있습니다. 자세한 내용은 Managing Failures 절을 참조하십시오.
시스템에서 사용하는 모든 호스트 이름(WebLogic 수신 주소, 기본 및 대기 데이터베이스 SCAN 및 VIP 주소)을 두 사이트에서 분석할 수 있어야 합니다. 기본적으로 OCI에서는 호스트 이름을 각 VCN 내에서만 확인할 수 있습니다. 영역 2에서 영역 1 이름을 분석할 수 있도록 하려면 영역 1 도메인에 대한 영역 2에서 프라이빗 DNS 뷰를 생성하고 관련 이름 및 IP 주소를 추가합니다. 영역 1에서 이 프로세스를 반복하여 영역 2에서 이름을 분석합니다.
각 사이트에서 시스템의 프론트엔드 이름(예: frontend.example.com)은 로컬 로드 밸런서의 IP 주소를 가리켜야 합니다. 이를 위해 각 영역의 전용 DNS 뷰 또는 중간 계층 호스트의 /etc/hosts 파일에 프론트엔드 이름을 추가합니다. 이렇게 하면 WebLogic 서버에서 프론트 엔드로의 콜백이 로컬 리전으로 지정됩니다.

데이터베이스 설정

영역 2의 대기 RAC 데이터베이스 시스템을 사용하여 영역 1에서 Oracle RAC(Oracle Real Application Clusters) 데이터베이스 시스템을 설정합니다.

로컬 고가용성이 핵심 요구 사항이므로 각 지역 내에서 RAC를 사용하는 것이 중요합니다. AD(가용성 도메인) 또는 지역 간 보호를 구성하는 것은 단일 지역 내 로컬 장애로부터 이미 안정적인 보호 기능이 있는 경우에만 효과적입니다. RAC에서 제공하는 것과 같은 로컬 고가용성이 구현되지 않은 경우 다중 AD 또는 영역에 보호를 추가해도 로컬 환경 내 Failure 위험이 해결되지 않습니다.

RAC 데이터베이스 노드 또는 인스턴스 실패 시 애플리케이션이 접속된 상태로 유지되고 Oracle Notification Service 통지를 받으려면 CRS(Cluster Ready Services) 데이터베이스 서비스를 사용하여 애플리케이션이 플러그인할 수 있는 데이터베이스(PDB)에 접속되었는지 확인하십시오. 동일한 CRS 서비스가 기본 및 대기 데이터베이스에 존재해야 합니다. PDB에 연결할 서비스를 생성하는 명령 예제:


srvctl add service -db $ORACLE_UNQNAME -service pdbservice.example.com -preferred ORCL1,ORCL2 -pdb pdb1 
srvctl modify service -db $ORACLE_UNQNAME -service pdbservice.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT

공유 저장소 설정

Oracle Cloud Infrastructure File Storage는 OCI에서 제공하는 확장 가능하고 안전한 완전 관리형 파일 시스템 서비스입니다. 공유 및 영구 파일 시스템이 필요한 엔터프라이즈 애플리케이션을 위한 고성능 파일 스토리지를 제공하도록 설계되었습니다.

여러 컴퓨팅 인스턴스가 네트워크 파일 시스템(NFS) 프로토콜을 통해 동일한 파일 시스템을 동시에 마운트하고 액세스할 수 있습니다.

OCI의 Oracle Fusion Middleware(FMW) 확장 클러스터 모델은 공유 파일 시스템(예: 공유 구성 또는 공유 런타임 데이터의 경우)에 대해 각 영역의 OCI File Storage 시스템을 사용합니다. OCI File Storage는 리전 내에서 고가용성을 제공합니다. 이 리전은 가용성 도메인 내 여러 장애 도메인 전반에 걸쳐 내부적으로 중복 스토리지를 사용합니다. 그러나 OCI File Storage는 여러 지역에서 액세스할 수 없습니다. 따라서 공유 스토리지는 해당 지역의 로컬 저장소입니다.

지역 간 로컬 백업 및 파일 시스템 복제본을 사용하여 아티팩트의 복구 가능한 복사본을 제공합니다.

Middle Tier 설정

중간 계층 컴퓨트 노드는 두 지역에 분산되어 있습니다.

중간 계층 컴퓨트 노드는 2개 영역에 분산되며, 노드의 절반은 영역 1에, 나머지 절반은 영역 2에 있습니다. 프로비저닝 및 설치 프로세스는 단일 WebLogic 도메인을 만들 때와 동일합니다. JMS(Java Message Service) 및 JTA(Java Transaction API) 서비스 이전과 같은 고가용성 기능을 구현하려면 Administration Server 페일오버, Node Manager를 사용한 자동 충돌 감지 등을 수행합니다. 자세히 살펴보기 섹션에서 참조된 FMW Enterprise Deployment Guides에 권장되는 최적의 방법을 사용합니다.

도메인을 생성하여 처음부터 모든 관리 서버로 구성할 수도 있고, 다른 영역에 노드를 추가하여 단일 영역에서 실행되는 기존 도메인을 스케일 아웃할 수도 있습니다.

주:

Oracle Fusion Middleware(FMW) 확장된 클러스터 모델은 Oracle WebLogic Server for OCI 및 Oracle SOA Suite on Marketplace 스택과 같은 서비스형 플랫폼(PaaS) 서비스를 사용하여 생성된 도메인에 적용할 수 있습니다. 이러한 PaaS 서비스의 프로비저닝 및 스케일 아웃 기능은 기본적으로 단일 리전만 지원하므로 클러스터를 수동으로 스케일 아웃하여 다른 리전에 노드를 추가해야 합니다. 이 작업을 수행하는 데 필요한 단계는 WLS 클러스터를 확장하는 절차를 참조하십시오. 이러한 PaaS 서비스는 웹 계층을 포함하지 않으며 관리 서버 페일오버와 같은 특정 고가용성 모범 사례를 구현하지 않습니다. 따라서 이 문서의 권장 사항 중 일부는 이러한 환경에 적용되지 않을 수 있습니다.

다음은 FMW 확장 클러스터 모델을 사용할 때 WebLogic 구성에서 구현할 가장 관련성이 높은 측면입니다.

데이터베이스 영구 저장소 사용
Oracle은 Oracle WebLogic Server 트랜잭션 로그 및 JMS에 대해 데이터베이스 영구 저장소를 사용하는 확장 클러스터를 지원합니다. 트랜잭션 로그 및 영구 데이터를 데이터베이스에 저장하면 Oracle RAC(Oracle Real Application Clusters) 및 Oracle Data Guard와 같은 데이터베이스의 내장 복제 및 고가용성 기능을 활용할 수 있습니다. Data Guard 보호 데이터베이스의 JMS, 트랜잭션 로그(TLOG) 및 메타 데이터를 사용하면 사이트 간 동기화가 간소화되고 응용 프로그램 레벨에서의 일관성이 보장됩니다. 이것은 또한 중간 계층이 관리 서버 페일오버, 배치 계획 및 파일 어댑터와 같은 일부 어댑터에 여전히 필요하지만 이러한 아티팩트에 대한 공유 저장소가 더 이상 필요하지 않음을 의미합니다.

그러나 데이터베이스에서 TLOG 및 JMS를 사용하면 시스템 성능에 위약금이 발생합니다. 중간 계층 중 하나가 다른 사이트의 데이터베이스와 상호 통신해야 하는 경우 이러한 위약금이 증가합니다. 성능 측면에서는 각 사이트에 로컬인 공유 스토리지의 성능이 향상되지만 복잡성과 제한이 발생하여 리전과 애플리케이션 일관성 간에 제로 데이터 손실을 보장합니다.
각 영역에 로컬로 공유된 파일 시스템 아티팩트
Oracle Fusion Middleware Enterprise Deployment Guides에 표시된 대로, 관리 서버 도메인 디렉토리(ASERVER_HOME)는 관리 서버의 도메인 폴더(MSERVER_HOME)와 구분된 공유 스토리지에 상주해야 합니다. 관리 서버 수신 주소에 가상 호스트 이름을 사용하면 관리 서버가 동일한 영역 또는 다른 영역 내의 다른 호스트로 페일오버할 수 있습니다.

공유 파일 시스템에 상주하는 다른 아티팩트는 Oracle 홈 설치(binaries), 배치 계획 및 파일 어댑터 디렉토리(runtime 폴더)입니다.

FMW 확장 클러스터 토폴로지에서 각 영역은 고유의 로컬 공유 저장 영역을 활용합니다. 따라서 두번째 영역은 공유 구성, 배치 계획, 런타임 파일 등을 위해 고유한 중복 바이너리(고가용성을 위해 사이트당 최소 두 개의 바이너리 설치 확인) 및 고유 공유 디렉토리를 유지 관리합니다. 이러한 모든 아티팩트는 일관성과 원활한 페일오버를 보장하기 위해 두 영역에서 동일한 경로를 사용해야 합니다.
WebLogic 클러스터에 대해 선호도 기반 알고리즘 사용
교차 사이트 트래픽을 최소화하려면 JNDI(Java Naming and Directory Interface) 컨텍스트 팩토리 분석에 로컬 유사성을 사용합니다. WebLogic 클러스터의 기본 로드 알고리즘을 선호도 기반 알고리즘으로 설정하려면 다음을 수행합니다.
1. WebLogic Remote Console의 Edit Tree로 이동합니다.
2. Environment(환경)로 이동하고 Clusters(클러스터)를 선택하고 클러스터를 선택합니다.
3. In the General tab, set the Default Load Algorithm of the WebLogic Cluster to round-robin affinity (the default is round-robin) or to any “affinity-based” algorithm.
클러스터에 있는 모든 서버의 명시적 목록과 함께 클러스터 주소를 설정할 필요는 없습니다. 비어 있으면 클러스터 주소 값이 자동으로 생성됩니다. 클러스터 주소를 자동으로 생성할 때 나열할 서버 수를 제한하는 Number of Servers In Cluster Address 등록 정보의 값이 클러스터의 모든 서버를 포함할 수 있을 만큼 높은지 확인하십시오.
자동 서비스 이전 구성 사용
Oracle은 엔터프라이즈 배치 토폴로지에 대해 JDBC(Java Database Connectivity) 영구 저장소와 함께 자동 서비스 이전을 구성할 것을 권장합니다. FMW 확장 클러스터 토폴로지에서는 두 사이트에서 JMS 및 TLOG 데이터에 액세스할 수 있는 한 영역 내 및 영역 간에 자동 서비스 이전이 가능합니다. JDBC 영구 저장소를 사용하는 경우 확장된 클러스터에서 ASM을 구성하는 데 특별한 고려 사항이 필요하지 않습니다.

사이트 간에 높은 대기 시간이 있을 경우 영역 1에서 영역 2로 서비스 이전 작업에 걸리는 시간이 늘어날 수 있습니다. 이 증가는 다른 지역의 데이터베이스에 있는 영구 저장소에서 읽혀지므로 다른 서버의 메시지를 복구하는 데 소요되는 시간에 의해 발생합니다. 이 대기 시간은 영구 저장소에서 보류 중인 메시지 수에 따라 증가합니다. 그러나 지연 시간이 매우 높거나 보류 중인 메시지가 많은 경우에만 페널티가 적용됩니다. 예상 동작에 대한 자세한 내용은 "성과 데이터 검토" 섹션을 참조하십시오.
프런트 엔드 호스트 이름 및 해상도
WebLogic 클러스터에 대한 프런트엔드 호스트를 구성할 때 표준 배치에서와 같이 클라이언트가 시스템에 액세스하는 데 사용하는 가상 호스트 이름을 지정합니다. 클라이언트는 이 가상 호스트 이름을 영역 1 및 영역 2의 OCI 로드 밸런서 인스턴스 간에 균형이 조정된 외부 주소로 분석해야 합니다. "전역 로드 밸런싱 정보"를 참조하십시오.

각 지역의 WebLogic 서버가 내부 호출의 경로를 해당 로컬 OCI 로드 밸런서로만 지정하도록 하려면 프론트 엔드 호스트 이름을 해당 지역 내 OCI 로드 밸런서의 IP 주소로 분석하도록 서버를 구성합니다. 이 작업은 각 WebLogic 서버 호스트의 /etc/hosts 파일에 항목을 추가하거나 각 영역의 DNS 전용 뷰에 추가하여 수행할 수 있습니다.

리전 1의 서버:
```
[IP address of Region 1 OCI Load Balancer] [frontend hostname]
```
리전 2의 서버:
```
[IP address of Region 2 OCI Load Balancer] [frontend hostname]
```
이 구성을 통해 WebLogic 서버의 내부 통신이 적절한 지역 로드 밸런서로 전달되어 라우팅 및 성능을 최적화할 수 있습니다.

WebLogic 데이터 소스 설정

모든 WebLogic 데이터 소스(Oracle Fusion Middleware(FMW) 메타데이터, 데이터베이스 영구 저장소, 임대 테이블, DB 어댑터 등)에서 이중 접속 문자열로 GridLink 데이터 소스를 사용하여 데이터베이스 복구를 자동화합니다. Oracle RAC(Oracle Real Application Clusters)의 노드 중 하나에 장애 또는 종료가 있을 때는 자동으로 재연결해야 하며, 데이터베이스를 다른 영역으로 완전히 전환하는 경우도 있습니다. 이를 위해 다음 권장 사항을 적용합니다.

GridLink 데이터 출처 사용
GridLink 데이터 소스는 Oracle Notification Service(ONS)를 활용하여 데이터베이스 노드 장애 또는 네트워크 중단을 신속하게 감지 및 대응함으로써 애플리케이션 가용성 및 복원력을 향상시킵니다. 실시간 작업 로드 정보를 기반으로 데이터베이스 연결을 자동으로 분산하여 모든 RAC 노드에서 성능 및 리소스 사용을 최적화합니다. RAC 노드 추가/제거와 같은 데이터베이스 토폴로지의 변경 사항은 자동으로 인식되고 처리되므로 관리 오버헤드가 줄어들고 작동 중지 시간이 최소화됩니다.

GridLink 데이터 소스 구성에서 ONS 호스트 및 포트를 수동으로 지정할 필요는 없습니다. ONS 리스트는 데이터베이스에서 드라이버에 자동으로 제공되며, 드라이버는 primary 및 standby database에 대한 ONS 정보를 검색하여 두 데이터베이스에 대한 연결을 용이하게 합니다.
TNS 별칭 사용
데이터 소스의 접속 문자열에서 기본 및 대기 SCAN 주소를 모두 포함하는 tnsnames.ora 파일의 항목을 가리키는 TNS 별칭을 사용합니다. 권장되는 연결 문자열 형식은 다음과 같습니다. RAC 데이터베이스당 하나의 설명과 두 개의 주소 목록이 있습니다.
```
PDB =
(DESCRIPTION=   
(CONNECT_TIMEOUT=15)(RETRY_COUNT=5)(RETRY_DELAY=5)(TRANSPORT_CONNECT_TIMEOUT=3)   
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
     (ADDRESS=(PROTOCOL=TCP)(HOST=primdb-scan.dbsubnet.region1vcn.oraclevcn.com)(PORT=1521))
 )
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stbydb-scan.dbsubnet.region2vcn.oraclevcn.com)(PORT=1521))    
)
(CONNECT_DATA=(SERVICE_NAME=pdbservice.example.com))
)
```
데이터 소스 및 FMW 구성 파일에서 TNS 별칭을 구성하는 방법에 대한 자세한 내용은 Oracle SOA Suite용 엔터프라이즈 배치 설명서의 연결 문자열에서 TNS 별칭 사용을 참조하십시오.
예약 시 접속 테스트 옵션 사용
모든 데이터 소스에 대해 예약 시 접속 테스트 옵션이 사용으로 설정되어 있는지 확인합니다. 영구 저장소는 WebLogic 서버의 전체 상태에서 중요하므로 영구 저장소에 액세스하는 데 사용되는 데이터 소스에는 특히 중요합니다. 이 플래그를 사용하면 WebLogic 서버가 접속을 응용 프로그램에 제공하기 전에 접속을 테스트할 수 있습니다.

테스트 테이블 이름의 경우 기본값인 SQL ISVALID를 사용합니다. 이것은 특정 물리적 테이블에 대한 액세스 없이도 데이터베이스 연결이 여전히 활성 상태인지 확인하기 위해 경량 검증을 수행하기 때문에 빠르고 효율적인 테스트입니다.
초기 용량 튜닝
WebLogic 서버가 시작되면 상당한 시간이 데이터 소스 풀에 대한 초기 연결을 만드는 데 사용됩니다. 데이터 소스의 초기 용량 설정에 따라 다른 지연이 예상됩니다. 기본적으로 대부분의 FMW 데이터 소스는 연결 풀에 대해 초기 용량이 0입니다. 그러나 일반 런타임 작업 중 시스템의 응답 시간을 줄이려면 초기 풀 용량을 늘리는 것이 좋습니다.
초기 용량은 데이터 소스(연결 풀) 레벨에서 구성되므로 이러한 설정은 클러스터 내의 모든 서버(데이터베이스에 로컬인 서버 및 원격 서버)에 대한 시작 시간에 영향을 줍니다. FMW 확장 클러스터에서 데이터베이스에서 원격으로 상주하는 서버는 더 높은 초기 풀 용량이 사용됨에 따라 시작 시 대기 시간이 증가합니다("검토 시작 시간" 참조). 따라서 정상 작동 중 응답 시간을 최적화하고 시작 시간을 최소화하여 이상적인 초기 용량 설정을 결정하는 사이에 균형 잡힌 결정이 필요합니다.
최대 용량 튜닝
활성 데이터 소스 연결 수가 늘어나고 대기 시간이 높아집니다. 수행된 테스트에서 원격 영역의 서버는 데이터베이스와 함께 배치된 서버보다 최대 2x의 활성 연결을 표시합니다("스트레스 테스트 검토" 참조). 응용 프로그램의 사용을 모니터하고 WebLogic 데이터 소스 및 데이터베이스 세션의 올바른 크기 조정을 위해 고려하십시오.

웹 서버 설정

시스템에서 Oracle HTTP Server 인스턴스가 있는 웹 계층을 사용하는 경우 각 영역에는 지역 내에서 고가용성을 제공하기 위해 서버가 두 개 이상 있어야 합니다.

영역 간 트래픽을 줄이려면 Oracle WebLogic Server 경로 지정 섹션에서 동적 서버 목록 구성을 사용하지 마십시오. 대신 서버의 정적 목록을 구성하고 DynamicServerList 매개변수를 OFF로 설정합니다. 이는 느린 실패 감지에 대한 주의가 있습니다. WebLogic 서버가 충돌할 경우 HTTP 서버는 동적 목록보다 실패를 감지하는 데 더 많은 시간이 걸립니다. 또한 새 서버가 추가된 경우 구성에 업데이트가 필요합니다. 그러나 시스템 성능은 향상됩니다.

Oracle HTTP Server에 있는 mod_wl_ohs.conf 파일의 다음 발췌 부분에서는 SOA 기반 구조 웹 응용 프로그램으로 경로 지정하기 위해 필요한 구성의 예를 제공합니다.

영역 1:

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region1_server1.example.com:7004,region1_server2.example.com:7004
    DynamicServerList OFF
</Location>

영역 2:

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region2_server1.example.com:7004,region2_server2.example.com:7004
    DynamicServerList OFF
</Location>

로드 밸런서 설정

각 영역에는 해당 사이트 내의 서버 간에 요청을 분산하기 위한 고유한 로드 밸런서가 있어야 합니다.

각 로드 밸런서에서 동일한 SSL 인증서를 사용하여 두 영역에서 리스너를 구성합니다. 영역 1의 로드 밸런서가 영역 1의 Oracle HTTP Server(OHS) 인스턴스를 포함하도록 백엔드 서버를 설정합니다. 시스템에서 웹 서버를 사용하지 않는 경우 지원되는 서버는 WebLogic입니다. 리전 1의 서버), 리전 2의 로드 밸런서에는 리전 2의 OHS 서버가 포함됩니다(시스템에서 웹 서버를 사용하지 않는 경우 리전 2의 WebLogic 서버는 백엔드 서버임).

애플리케이션의 상태를 정확하게 반영하는 URL을 사용하여 백엔드 서버의 가용성을 결정하는 건전성 검사를 구성합니다. 이렇게 하면 트래픽이 Oracle WebLogic Server가 실행 중인 서버로 경로 지정되는 것을 방지하지만 응용 프로그램 자체를 사용할 수 없습니다. 이는 건전성 검사가 루트 컨텍스트(/)만 대상으로 하는 경우에만 발생할 수 있습니다. 그러나 많은 검사가 백업된 서버를 오버로드할 수 있으므로 리소스 집약적인 건전성 검사를 사용하지 마십시오. 예를 들어, Oracle SOA의 경우 권장되는 건전성 검사 URL은 /soa-infra/services/isSoaServerReady 입니다.

Global 로드 밸런싱 정보

Oracle Fusion Middleware(FMW) 확장된 클러스터 모델에는 두 영역 간의 클라이언트 요청 균형을 맞추기 위해 각 데이터 센터의 로드 밸런서 위에 요소가 필요합니다.

온프레미스 구현에서는 일반적으로 원본의 IP 주소를 기반으로 하는 스마트 라우팅을 담당하는 글로벌 로드 밸런서를 통해 구현됩니다. 이 전역 로드 밸런서는 일반적으로 사이트 중 하나에 위치하며, 페일오버를 위해 다른 사이트에 백업이 있습니다.

Oracle Cloud Infrastructure(OCI)에는 전용 글로벌 로드 밸런서 서비스가 없습니다. 그러나 트래픽 관리 정책을 사용하여 전역 로드 균형 조정 기능을 수행할 수 있습니다.

OCI 트래픽 관리 조정 정책을 글로벌 로드 밸런서로 사용

Oracle Cloud Infrastructure(OCI) 트래픽 관리 조정 정책을 사용하여 두 사이트 간의 클라이언트 트래픽 로드 밸런싱을 수행합니다.

트래픽 관리 조정 정책은 DNS(도메인 이름 시스템) 질의에 대한 지능적인 응답을 제공합니다. 즉, 정책에 정의된 논리에 따라 질의에 대해 다른 응답이 제공될 수 있습니다. 다음과 같은 다양한 정책 유형이 있습니다.

로드 밸런서 정책
로드 밸런서 정책은 여러 끝점에 트래픽을 분산합니다. 끝점에 트래픽을 균등하게 분배하기 위해 동일한 가중치를 지정하거나 비율 로드 밸런싱을 위해 사용자정의 가중치를 지정할 수 있습니다. Oracle Cloud Infrastructure Health Checks 모니터 및 온디맨드 프로브는 엔드포인트의 상태를 평가하는 데 사용됩니다. 끝점이 비정상이면 DNS 트래픽이 다른 끝점에 자동으로 분산됩니다.
복구 정책
페일오버 정책을 사용하면 정책에서 답변이 제공되는 순서(예: 기본 및 보조)의 우선순위를 지정할 수 있습니다. OCI Health Checks 모니터 및 온디맨드 프로브는 정책 내 답변 상태를 평가하는 데 활용됩니다. 기본 응답이 비정상이면 DNS 트래픽이 자동으로 보조 응답으로 조정됩니다.
지리적 위치 조정 정책
지리적 위치 조정 정책은 최종 사용자의 위치에 따라 DNS 트래픽을 다른 엔드포인트로 분산시킵니다. 고객은 원래 대륙, 국가 또는 시/도(북미)로 구성된 지리적 지역을 정의하고 각 지역에 대해 별도의 끝점 또는 끝점 집합을 정의할 수 있습니다.
ASN 조정 정책
ASN 조정 정책을 사용하면 ASN(자율 시스템 번호)을 기반으로 DNS 트래픽을 조정할 수 있습니다. 특정 ASN 또는 일련의 ASN에서 시작된 DNS 질의를 지정된 끝점으로 조정할 수 있습니다.
IP 접두어 조종 정책
IP 접두사 조정 정책을 통해 고객은 원래의 질의의 IP 접두사에 따라 DNS 트래픽을 조정할 수 있음

귀하의 요구에 가장 적합한 정책을 선택하십시오. 확장된 클러스터 배치에 가장 적합한 옵션은 지리적 위치 조정 정책과 IP 접두어 조정 정책입니다. 페일오버 정책은 WebLogic Remote Console과 같이 사이트 중 하나에서만 실행되는 서비스에 적합합니다.

정책 유형에 관계없이 OCI 건전성 검사를 정의하여 사이트 가용성을 확인해야 합니다. 이렇게 하면 서버가 중지되거나 응용 프로그램을 사용할 수 없는 사이트에 도달하는 트래픽이 방지됩니다. 건전성 검사를 수행하는 유리한 위치에서 검사 중인 OCI 로드 밸런서 포트로의 수신 트래픽을 허용하는지 확인합니다.

다음 다이어그램은 OCI 트래픽 관리 조정 정책을 사용한 전역 로드 밸런싱을 보여줍니다.

아래 global-load-balancer-steering-policies.png에 대한 설명입니다.

그림 global-load-balancer-steering-policies.png에 대한 설명

글로벌 로드 밸런서 조정 정책-oracle.zip

OCI 트래픽 관리 조정 정책을 사용하여 전역 로드 밸런서를 에뮬레이트하는 경우:

복구 반응 시간
사이트 실패에 대한 응답 시간은 건전성 검사 간격(사이트를 사용할 수 없음으로 표시하는 속도를 결정함)과 DNS 레코드의 TTL(활성 시간 값)에 따라 달라집니다. 사이트가 사용 불가능으로 플래그 지정되고 트래픽이 다른 위치로 지정된 후에도 클라이언트는 이전 DNS TTL이 로컬 캐시에서 만료될 때까지 업데이트된 IP 주소를 수신하지 않습니다. 복구 지연을 최소화하려면 낮은 정책 TTL 값을 설정하는 것이 좋습니다.
세션 지속성 제한
이러한 정책을 사용한 로드 균형 조정은 DNS 응답 값을 사용하므로 세션 지속성을 위한 기본 제공 방식이 없습니다. 따라서 무작위 또는 단순 로드 밸런서 정책을 사용할 때 클라이언트에 제공된 DNS 응답이 언제든지 변경될 수 있으며, 잠재적으로 지속성이 필요한 애플리케이션 세션에 영향을 줄 수 있습니다. 애플리케이션에 영구 세션이 필요한 경우 가능한 모든 클라이언트 위치가 지리적 위치 기반 규칙 내에 명시적으로 정의되어 있는지 확인하고 무작위 또는 로드 밸런서 조정 알고리즘을 사용하지 않도록 하십시오.

다음은 프랑크푸르트 및 암스테르담 지역에 배치된 Oracle Fusion Middleware(FMW) 확장 클러스터 시스템에 대한 OCI 트래픽 관리 조정 정책의 예입니다. 프런트엔드는 Oracle SOA용이고, OSB용이며, 다른 프런트엔드는 WebLogic Remote Console용입니다. 프랑크푸르트에 있는 로드 밸런서(LBR)의 IP는 111.111.111.111이고 암스테르담에 있는 LBR의 IP는 222.222.222.222입니다. 이 예에서는 조정 정책이 다음 규칙을 정의합니다.

SOA 및 OSB 프런트엔드의 경우 독일, 유럽, 아시아 및 남아메리카 지역의 고객은 DNS에서 프랑크푸르트 로드 밸런서의 IP를 기본 답변으로 얻습니다.
SOA 및 OSB 프런트엔드의 경우 네덜란드, 아프리카, 오세아니아 및 북미 지역의 고객은 DNS에서 암스테르담 로드 밸런서의 IP를 기본 답변으로 얻습니다.
모든 지역이 지리적 위치 규칙에 포함되어 있으므로 다른 클라이언트의 경우 DNS는 기본 답변을 반환하여 프랑크푸르트로 리디렉션됩니다.
각 프런트엔드에 대해 OCI 건전성 검사가 정의되므로 기본이 사용 불가능으로 표시된 경우 트래픽이 대체 IP 레코드로 조정됩니다.
WebLogic Remote Console 프런트엔드는 페일오버 모델을 사용합니다. DNS는 모든 클라이언트에 대한 프랑크푸르트 로드 밸런서의 IP를 반환합니다. 프랑크푸르트에서 상태 검사가 실패하면 DNS는 암스테르담 로드 밸런서의 IP를 반환합니다.

다음은 정의된 OCI 트래픽 관리 조정 정책입니다.

SOA 프론트엔드에 액세스하기 위한 지리적 위치 조정 정책입니다.

구성 품목	예제 값
정책 이름	strecthed_cluster_steering_policy-SOA
템플리트	지리적 위치 조정
정책 TTL	60s
해답 Pool1(Frankfurt_Pool)	이름: Frankfurt_LBR_IP 유형: A RDATA: 111.111.111.111
답변 풀 2(Amsterdam_Pool)	이름: Amsterdam_LBR_IP 유형: A RDATA: 222.222.222.222
지리적 위치 조종 규칙 1	지리적 위치: 독일, 유럽, 아시아, 남아메리카 풀 우선순위 1: Frankfurt_Pool 풀 우선 순위 2: Amsterdam_Pool
지리적 위치 조정 규칙 2	지리적 위치: 네덜란드, 아프리카, 오세아니아, 북미 풀 우선순위 1: Amsterdam_Pool 풀 우선 순위 2: Frankfurt_Pool
전역 Catch-all	해답 Pool1(Frankfurt_Pool)
건전성 검사 연결	요청 유형: HTTP 상태 검사: `SOA_IS_ALIVE`(HTTPS)
연결된 도메인	soafrontend.example.com

OSB 프론트엔드에 액세스하기 위한 지리적 위치 조정 정책입니다.

구성 품목	예제 값
정책 이름	strecthed_cluster_steering_policy-OSB
템플리트	지리적 위치 조정
정책 TTL	60s
답변 풀 1(Frankfurt_Pool)	이름: Frankfurt_LBR_IP 유형: A RDATA: 111.111.111.111
답변 풀 2(Amsterdam_Pool)	이름: Amsterdam_LBR_IP 유형: A RDATA: 222.222.222.222
지리적 위치 조종 규칙 1	지리적 위치: 독일, 유럽, 아시아, 남아메리카 풀 우선순위 1: Frankfurt_Pool 풀 우선 순위 2: Amsterdam_Pool
지리적 위치 조정 규칙 2	지리적 위치: 네덜란드, 아프리카, 오세아니아, 북미 풀 우선순위 1: Amsterdam_Pool 풀 우선 순위 2: Frankfurt_Pool
전역 Catch-all	해답 Pool1(Frankfurt_Pool)
건전성 검사 연결	요청 유형: HTTP 상태 검사: `OSB_IS_ALIVE`(HTTPS)
연결된 도메인	osbfrontend.example.com

페일오버 정책은 WebLogic Remote Console에 액세스하는 데 사용됩니다. 정상 작동 중에 관리 서버는 사이트 중 하나에서만 실행됩니다(이 경우 프랑크푸르트). 사이트 Failure가 발생하는 경우에만 다른 사이트에서 시작됩니다. 따라서 WebLogic Remote Console 및 EM에 대한 액세스는 페일오버 정책에 의해 제어됩니다.

구성 품목	예제 값
정책 이름	strecthed_cluster_steering_policy-관리
템플리트	복구
정책 TTL	60s
해답 Pool1(Frankfurt_Pool)	이름: Frankfurt_LBR_IP 유형: A RDATA: 111.111.111.111
답변 풀 2(Amsterdam_Pool)	이름: Amsterdam_LBR_IP 유형: A RDATA: 222.222.222.222
풀 우선순위 1	Frankfurt_Pool
풀 우선순위 2	Amsterdam_Pool
건전성 검사 연결	요청 유형: HTTP 상태 검사: `EM_IS_ALIVE`(HTTPS)
연결된 도메인	admin.example.com

각 DNS 조정 정책에 사용되는 OCI 건전성 검사의 구성입니다.

SOA 프론트 엔드에 대한 건전성 검사입니다. SOA는 /soa-infra/services/isSoaServerReady 경로에서 SOA 상태를 확인하는 간단한 페이지를 제공합니다. 따라서 이 건전성 검사는 해당 경로에 대해 HTTPS로 HEAD 요청을 수행하여 SOA 응용 프로그램을 사용할 수 있는지 확인합니다. 웹 서버 및 로드 밸런서에서 명명된 가상 호스트를 사용할 때 테스트할 프론트 엔드 이름(이 예의 경우 soafrontend.example.com)을 지정하려면 host 헤더가 필요합니다.

구성 품목	예제 값
건전성 검사 이름	SOA_IS_ALIVE
대상	111.111.111.111(프랑크푸르트 LBR IP) 222.222.222.222(암스테르담 LBR IP)
유리한 위치	Microsoft Azure 북유럽 Google 미국 동부
유형	HTTP
프로토콜	HTTPS
포트	443
경로	`/soa-infra/services/isSoaServerReady`
헤더	주최: soafrontend.example.com:443
방법	HEAD
수집 간격	30초
시간 초과	10초

OSB 프론트 엔드에 대한 건전성 검사입니다. OSB는 해당 서비스에 대한 건전성 URL을 구현하지 않습니다. 일반적으로 OSB의 상태(예: /sbinspection.wsil)를 확인하는 데 사용되는 일부 URL에는 인증이 필요하며 OCI 건전성 검사는 authorization 헤더를 지원하지 않습니다. 따라서 OSB의 상태를 확인하려면 간단한 사용자 정의 REST 프록시 서비스를 배치합니다. 이 OCI 건전성 검사는 HTTPS를 통해 해당 끝점에 대한 HEAD 요청을 수행합니다. 웹 서버 및 로드 밸런서에서 명명된 가상 호스트를 사용할 때 테스트할 프론트 엔드 이름(이 예의 경우 osbfrontend.example.com)을 지정하려면 host 헤더가 필요합니다.

구성 품목	예제 값
건전성 검사 이름	OSB_IS_ALIVE
대상	111.111.111.111(프랑크푸르트 LBR IP) 222.222.222.222(암스테르담 LBR IP)
유리한 위치	Microsoft Azure 북유럽 Google 미국 동부
유형	HTTP
프로토콜	HTTPS
포트	443
경로	/`default/isOSBReadySample`
헤더	주최: osbfrontend.example.com:443
방법	HEAD
수집 간격	30초
시간 초과	10초

WebLogic Remote Console 프론트엔드 EM_IS_ALIVE에 대한 건전성 검사입니다.

OCI 건전성 검사는 HTTPS와 함께 /em/faces/targetauth/emasLogin 경로에 대한 HEAD 요청을 수행하여 FMW 콘트롤 콘솔의 상태를 확인합니다.

구성 품목	예제 값
건전성 검사 이름	SOA_IS_ALIVE
대상	111.111.111.111(프랑크푸르트 LBR IP) 222.222.222.222(암스테르담 LBR IP)
유리한 위치	Microsoft Azure 북유럽 Google 미국 동부
유형	HTTP
프로토콜	HTTPS
포트	443
경로	`/em/faces/targetauth/emasLogin`
헤더	주최: admin.example.com:445
방법	HEAD
수집 간격	30초
시간 초과	10초

타사 글로벌 로드 밸런서 사용

Oracle Cloud Infrastructure(OCI) 트래픽 관리 조정 정책의 대안으로 타사 전역 로드 밸런서(GLBR)를 사용할 수 있습니다.

로컬 로드 밸런서 간에 스마트한 요청 경로 지정을 수행합니다.

GLBR은 모든 사이트 및 외부 위치의 사용자가 주소로 액세스할 수 있도록 구성된 로드 밸런서입니다. 이 장치는 연결할 사이트에 관계없이 모든 클라이언트가 액세스할 수 있는 DNS(도메인 이름 시스템) 이름에 매핑된 가상 서버를 제공합니다.

GLBR은 구성된 조건 및 규칙을 기반으로 한 사이트로 트래픽을 전달합니다. 이러한 조건은 예를 들어 클라이언트의 IP를 기반으로 할 수 있습니다. 이는 GLBR이 초기 및 후속 요청 시 사용자를 동일한 사이트에 매핑할 수 있도록 하는 지속성 프로파일을 만드는 데 사용되어야 합니다. GLBR은 모든 로컬 로드 밸런서의 주소로 구성된 풀을 유지 관리합니다. 사이트 중 하나에 장애가 발생하면 사용자는 자동으로 작동 중인 활성 사이트로 재지정됩니다.

각 사이트에서 로컬 로드 밸런서는 GLBR로부터 요청을 수신하고 적절한 HTTP 서버로 요청을 보냅니다. 원치 않는 라우팅을 없애기 위해 GLBR은 콜백을 생성한 서버에 로컬인 LBR로만 라우팅하는 특정 규칙으로도 구성됩니다. 예를 들어, 이는 Oracle SOA 서비스의 내부 소비자에게 유용합니다. 다음과 같은 GLBR 규칙을 요약할 수 있습니다.

site1에서 요청을 보낸 경우(예: 사이트 1의 WebLogic 서버에서 시작된 요청) GLBR은 site1의 LBR로 경로 지정됩니다.
site2에서 요청을 보낸 경우(예: 사이트 2의 WebLogic 서버에서 시작된 요청) GLBR은 site2의 LBR로 경로 지정됩니다.
요청이 다른 주소(클라이언트 호출)에서 오는 경우 GLBR 로드가 두 LBR에 대한 연결의 균형을 조정합니다.
특정 클라이언트를 특정 사이트로 라우팅하기 위해 GLBR에 추가 라우팅 규칙을 정의할 수 있습니다. 예를 들어, 두 사이트는 각각의 경우에 하드웨어 리소스에 따라 서로 다른 응답 시간을 제공할 수 있습니다.

기타 자원 설정

두 영역은 LDAP, ID 저장소, 정책 저장소, 외부 JMS(Java 메시지 서비스) 대상, 외부 웹 서비스, Oracle Cloud Infrastructure Object Storage 등과 같은 외부 리소스를 사용할 수 있습니다.

이러한 외부 리소스에 대한 구성 세부정보가 이 문서의 범위를 벗어났습니다. 그러나 동일한 동작을 제공하기 위해서는 두 영역에서 이러한 리소스가 일관되어야 합니다.

예를 들어, Oracle SOA에서 비동기 콜백은 다른 영역에서 시작된 인스턴스를 리하이드레이션할 수 있습니다. 마찬가지로 자동 복구의 경우 Oracle WebLogic Server는 클러스터 마스터의 역할을 맡고 두 영역 중 하나에서 복구 작업을 수행할 수 있습니다. 이러한 프로세스가 원활하게 작동하고 일관된 동작을 제공하려면 두 영역에서 동일한 외부 리소스에 액세스할 수 있어야 합니다.