시작하기

Oracle WebLogic Server는 여러 온프레미스 사이트 또는 여러 Oracle Cloud Infrastructure(OCI) 리전에 배포할 수 있습니다.

이 플레이북의 구성에서는 두 사이트의 서버가 동일한 클러스터(확장된 클러스터라고 함)에 참여하고 Data Guard를 사용하여 데이터베이스에 대한 보호를 제공하는 단일 Oracle WebLogic Server 도메인을 사용합니다.

OCI에서는 트래픽 관리, 상태 검사, 로드 밸런서, DNS 전용 뷰 및 동적 라우팅 게이트웨이와 같은 기능이 이 설정을 지원하는 향상된 기능을 제공합니다. 온프레미스 환경의 경우 이러한 요구사항을 충족하기 위해 동등한 네트워킹 및 인프라 구성요소를 사용해야 합니다.

호출 지연으로 인한 성능 저하를 최소화하고 배치 및 런타임 중 불일치를 방지하려면 사이트 또는 지역 간의 네트워크 대기 시간이 충분히 낮아야 합니다. Oracle은 WebLogic 서버와 데이터베이스 간의 대기 시간이 10ms RTT(왕복 시간) 미만인 경우에만 이 토폴로지를 지원합니다.

최적의 성능 및 페일오버 동작을 달성하기 위해 Oracle은 WebLogic 확장 클러스터에서 실행되는 각 애플리케이션을 분석하고 이 플레이북에 설명된 다양한 매개변수(시간 초과, 세션 복제 구성, 서비스 마이그레이션 임대, JTA(Java Transaction API) 등)를 그에 따라 조정할 것을 권장합니다.

Oracle Fusion Middleware 확장된 클러스터에 대해 알아보기

Oracle 최대 가용성 아키텍처(MAA)를 제공하는 것은 모든 Oracle Fusion Middleware 엔터프라이즈 배포를 위한 주요 요구 사항 중 하나입니다.

Oracle Fusion Middleware에는 프로세스 종료 감지 및 재시작, 서버 클러스터링, 서비스 이전, GridLink, 로드 밸런싱, 복구, 백업 및 복구, 롤링 업그레이드, 롤링 구성 변경과 같은 광범위한 고가용성 기능이 포함되어 있어 계획되지 않은 작동 중지 시간으로부터 엔터프라이즈 배치를 보호하고 계획된 작동 중지 시간을 최소화합니다. 이러한 기능은 단일 데이터 센터 내에서 로컬 고가용성 솔루션을 제공합니다.

또한 애플리케이션은 전체 데이터 센터에 영향을 줄 수 있는 예기치 못한 재해, 자연스러운 재해 및 다운타임으로부터 보호해야 합니다. 대부분의 기존 재해 보호 시스템은 운용 사이트와 지리적으로 다른 위치에 대기 사이트를 설정하는 능동-수동 모델을 사용합니다. 이 모델은 일반적으로 사이트 간의 대기 시간이 높고 두 사이트에서 클러스터링을 허용하지 않는 경우에 채택됩니다. 이 접근 방식은 완벽한 최대 가용성 아키텍처(MAA) 보호를 제공합니다. 그러나 대기 미들웨어 시스템이 기본 시스템을 미러링하고 연속 복제가 필요하므로 추가적인 운영 및 관리 비용이 발생합니다. 이 모델은 Oracle Fusion Middleware Disaster Recovery Guide에 설명되어 있습니다.

이 플레이북에서는 Oracle Fusion Middleware 확장 클러스터 기반의 활성-활성 모델인 다른 모델에 대해 설명합니다. 이 모델은 여러 위치의 작동 중지 시간으로부터 Oracle Fusion Middleware 시스템을 보호하는 데 사용할 수 있습니다. 이 모델은 중간 계층에 대해 활성-활성 구성을 사용하며, 데이터베이스 계층은 Data Guard와 함께 활성-수동 구성을 사용합니다. 용량을 최적화하고 사이트 전체에 워크로드를 분산시킬 수 있도록 설계되었습니다. 대기 시스템을 유휴 상태로 두지 않고 사용 가능한 모든 리소스를 활용하여 능동-수동 모델보다 리소스를 더 효과적으로 활용합니다. 이 모델을 FMW 확장 클러스터 배포라고 합니다.

특히 이 플레이북은 Oracle Cloud Infrastructure(OCI) 리전 전반에서 이 모델을 구현하는 방법을 중점적으로 다룹니다. 권장 토폴로지를 설정하기 위한 구성 단계와 이 설정의 성능 및 페일오버 영향에 대한 지침을 제공합니다.

이 플레이북의 결과와 예는 엔터프라이즈 배포 가이드 아키텍처 다음에 나오는 Oracle SOA Suite 14.1.2 시스템을 기반으로 합니다. 이 예제는 표준 자카르타 구성 요소, HTTP 세션 복제, 데이터베이스 메타 데이터 지속성, Coherence 클러스터 및 JMS(Java Message Service)와 JTA(Java 트랜잭션 API) 영구 저장소와 같은 다양한 기능을 포함하기 때문에 확장된 클러스터에 대한 다른 관련 고려 사항 중에서도 중요한 예입니다. 따라서 설명된 토폴로지 및 권장 사항을 다른 Oracle Fusion Middleware 환경에도 적용할 수 있습니다.

용어

다음은 이 플레이북에 사용된 몇 가지 용어의 정의입니다.

  • 중간 계층(중간 계층 또는 미들웨어)

    미드티어는 사용자 인터페이스(프론트엔드)와 데이터 스토리지(백엔드) 사이에 위치한 다계층 애플리케이션 아키텍처 내의 계층을 의미합니다. 이 서비스는 유저와 데이터베이스 간의 다리 역할을 하는 업무 논리, 데이터 처리 및 보안을 처리합니다.

  • Oracle Fusion Middleware

    Oracle Fusion Middleware는 Oracle의 포괄적인 엔터프라이즈 미들웨어 제품군으로, 조직이 애플리케이션을 효율적이고 안전하게 구축, 배포 및 관리할 수 있도록 지원합니다. 여기에는 애플리케이션 서버, 통합, 비즈니스 프로세스 관리, 비즈니스 인텔리전스, 보안, ID 관리, 웹 서버 등을 위한 솔루션이 포함됩니다.

  • 재해

    사이트 또는 지리적 영역에서 용납할 수 없는 손상이나 손실을 야기하는 갑작스럽고 계획되지 않은 치명적인 이벤트입니다. 재해는 조직에서 용납할 수 없는 기간 동안 중요한 기능, 프로세스 또는 서비스를 제공할 수 있는 능력을 저해하고 조직에서 복구 계획을 호출하게 하는 이벤트입니다.

  • 장애 복구

    지리적으로 떨어진 대기 사이트로의 애플리케이션 및 데이터를 복구하는 전략을 실행하여 프로덕션 사이트에서 자연 정전 또는 예기치 않은 정전으로부터 보호할 수 있는 기능.

  • Oracle 최대 가용성 구조

    Oracle maximum availability architecture (Oracle MAA) is the best practice blueprint for data protection and availability of Oracle products (Oracle Database, Oracle Fusion Middleware, Applications). Oracle MAA 모범 사례를 구현하는 것은 모든 Oracle 배포에 필요한 주요 요구 사항 중 하나입니다. Oracle 시스템 설정 및 관리를 위한 권장 사항을 제공합니다. Oracle MAA에는 Oracle Fusion Middleware Enterprise Deployment Guide 권장 사항이 포함되어 있으며 재해 보호 모범 사례를 추가하여 전체 데이터 센터 또는 지역에 영향을 주는 중단에 대해 계획되거나 계획되지 않은 작동 중지 시간을 최소화합니다. 관련 설명서 및 기타 리소스에 대한 링크는 자세히 살펴보기 섹션을 참조하십시오.

  • 사이트(또는 데이터 센터)

    사이트는 애플리케이션 그룹을 실행하는 데 필요한 데이터 센터의 여러 구성 요소 집합입니다. 예를 들어, 사이트는 Oracle Fusion Middleware 인스턴스, 데이터베이스, 스토리지 등으로 구성될 수 있습니다.

  • 시스템

    시스템은 함께 작동하여 응용 프로그램을 호스트하는 대상 집합(호스트, 데이터베이스, 응용 프로그램 서버 등)입니다. 예를 들어, Oracle Enterprise Manager에서 응용 프로그램을 모니터하려면 먼저 데이터베이스, 리스너, 응용 프로그램 서버 및 응용 프로그램이 실행되는 호스트 대상으로 구성된 시스템을 만듭니다.

  • 확장된 클러스터

    확장된 클러스터는 단일 논리적 클러스터의 노드가 지리적으로 분리된 데이터 센터 또는 위치에 분산되는 클러스터 구조를 나타냅니다.

  • 전환

    Switchover는 production site와 standby site의 롤을 되돌리는 프로세스입니다. 스위치오버는 정기적 검증을 위해 수행되거나 현재 프로덕션 사이트에서 계획된 유지 관리를 수행하기 위해 수행된 계획된 작업입니다. switchover 중에 현재 standby site는 새 production site가 되고 현재 production site는 새 standby site가 됩니다. 또한 이 플레이북에서는 스위치오버라는 용어를 사용하여 사이트 스위치오버를 참조합니다.

  • 전환

    스위치백은 현재 운용 중인 사이트와 현재 대기 사이트를 원래 롤로 되돌리는 프로세스입니다. 스위치백은 스위치오버 작업이 완료된 후 계획된 작업입니다. 스위치백은 각 사이트의 원래 롤을 복원합니다. 즉, 현재 대기 사이트가 운용 사이트가 되고 현재 운용 사이트가 대기 사이트가 됩니다. 또한 이 플레이북에서는 switchback이라는 용어를 사용하여 사이트 스위치백을 참조합니다.

  • 복구

    Failover는 프로덕션 사이트의 재해 등으로 인해 프로덕션 사이트를 예기치 않게 사용할 수 없게 된 후 현재 대기 사이트를 새 프로덕션 사이트로 만드는 프로세스입니다. 또한 이 플레이북에서는 사이트 페일오버를 참조하기 위해 페일오버라는 용어를 사용합니다.

  • RPO(복구 지점 객관적)

    복구 지점 목표는 정전이 발생할 때 허용되는 데이터 손실량과 같이 시스템이 비즈니스 관점에서 허용할 수 있는 데이터 손실량입니다.

  • RTO(Recovery Time Objective)

    복구 시간 목표는 시스템이 허용할 수 있는 작동 중지 시간 또는 비즈니스 관점에서 중단이 발생할 때 응용 프로그램이나 서비스를 사용할 수 없는 상태로 유지할 수 있는 허용 가능한 시간입니다.

  • Oracle Cloud Infrastructure

    Oracle Cloud Infrastructure(OCI)는 고가용성의 호스트 환경에서 다양한 애플리케이션 및 서비스를 구축하고 실행할 수 있도록 해주는 보완적인 클라우드 서비스 집합입니다. OCI는 사용자의 온프레미스 그룹에서 안전하게 액세스할 수 있는 유연한 오버레이 가상 네트워크에서 고성능 컴퓨트 기능(물리적 하드웨어 인스턴스) 및 스토리지 용량을 제공한다.

  • OCI 리전

    OCI 리전은 가용성 도메인을 호스팅하는 데이터 센터가 하나 이상 포함된 지역화된 지리적 영역입니다. 지역은 다른 지역과 독립적이며, 광대한 거리는 (국가 또는 대륙에 걸쳐) 그들을 분리 할 수 있습니다.

    리전은 재해 복구 측면에서 사이트입니다.

  • 가용성 도메인

    가용성 도메인은 한 지역 내의 독립형 독립형 데이터 센터입니다. 각 가용성 도메인의 물리적 리소스는 내결함성을 제공하는 다른 가용성 도메인의 리소스와 격리됩니다. 가용성 도메인은 전원 또는 냉각과 같은 인프라나 내부 가용성 도메인 네트워크를 공유하지 않습니다. 따라서 한 가용성 도메인의 장애가 해당 지역의 다른 가용성 도메인에 영향을 미치지 않아야 합니다.

  • OCI 가상 클라우드 네트워크 및 서브넷

    VCN(가상 클라우드 네트워크)은 OCI 리전에 설정하는 커스터마이징 가능한 소프트웨어 정의 네트워크입니다. 기존 데이터 센터 네트워크와 마찬가지로 VCN을 사용하면 네트워크 환경을 제어할 수 있습니다. VCN에는 VCN을 생성한 후 변경할 수 있는 겹치지 않는 CIDR(클래스리스 도메인 간 경로 지정) 블록이 여러 개 있을 수 있습니다. VCN을 서브넷으로 분할할 수 있으며, 이 서브넷은 지역 또는 가용성 도메인으로 범위가 지정될 수 있습니다. 각 서브넷은 VCN의 다른 서브넷과 겹치지 않는 연속적인 주소 범위로 구성됩니다. 썸네일의 크기는 생성 이후 변경할 수 있습니다. 서브넷은 공용 또는 전용일 수 있습니다.

  • DRG(동적 경로 지정 게이트웨이)

    The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another OCI region, an on-premises network, or a network in another cloud provider.

  • OCI DNS

    Oracle Cloud Infrastructure DNS(Domain Name System) 서비스는 확장성이 뛰어난 글로벌 애니캐스트 DNS(Domain Name System) 네트워크로, 향상된 DNS 성능, 복원성 및 확장성을 제공하므로 최종 사용자가 어디에서나 인터넷 애플리케이션에 빠르게 연결할 수 있습니다.

  • OCI DNS 프라이빗 보기

    OCI DNS 프라이빗 뷰는 DNS 영역을 논리적으로 그룹화하고 해결 방법을 제어하는 데 사용되는 하나 이상의 OCI 프라이빗 DNS 영역 모음입니다. 뷰는 VCN(가상 클라우드 네트워크) 또는 커스터마이징 뷰의 기본 분석기일 수 있는 프라이빗 DNS 분석기에 연결됩니다. 이를 통해 VCN 내의 여러 환경 또는 애플리케이션에 대해 별도의 DNS 구성을 관리할 수 있습니다.

  • 가상 IP

    VIP(가상 IP) 주소는 특정 물리적 네트워크 인터페이스 또는 장치에 연결되지 않은 IP 주소를 나타냅니다. 대신 추상화되어 장치 간에 이동하거나 다양한 네트워크 기능에 사용할 수 있습니다.

  • OCI 트래픽 관리

    OCI 트래픽 관리는 고급 DNS 기반 정책(OCI 트래픽 조정 정책)을 사용하여 사용자 트래픽을 최적의 엔드포인트로 지능적으로 전달합니다. 이를 통해 조직은 DNS 쿼리의 해결 방법을 제어하고 클라이언트 요청의 라우팅을 최적화하여 OCI 또는 다른 곳에 배포된 애플리케이션 또는 서비스의 가용성, 성능 및 복원성을 향상시킬 수 있습니다.

  • 로드 밸런서

    로드 밸런서는 애플리케이션의 고가용성, 안정성 및 최적의 성능을 보장하기 위해 수신 네트워크 트래픽을 여러 서버에 분산하는 시스템 또는 서비스입니다.

  • OCI 로드 밸런서

    OCI 로드 밸런서는 완전 관리형 Oracle Cloud Infrastructure 서비스로, 수신 트래픽을 여러 백엔드 서버 또는 리소스에 자동으로 분산하여 애플리케이션의 고가용성, 향상된 성능 및 확장성을 보장합니다.

  • 블록 스토리지

    블록 스토리지는 정보가 고정 크기 블록에 저장되고 iSCSI 또는 광 섬유 채널과 같은 스토리지 프로토콜을 통해 서버 또는 애플리케이션에서 직접 액세스할 수 있는 데이터 스토리지 유형입니다.

  • OCI 블록 볼륨

    Oracle Cloud Infrastructure Block Volumes를 사용하면 스토리지 볼륨을 생성, 연결, 연결 및 이동하고 볼륨 성능을 변경하여 스토리지, 성능 및 애플리케이션 요구 사항을 충족할 수 있습니다. 볼륨을 인스턴스에 연결한 후 일반 하드 드라이브와 같은 볼륨을 사용할 수 있습니다. 또한 데이터 손실 없이 볼륨 연결을 해제하고 다른 인스턴스에 연결할 수 있습니다.

  • 공유 저장영역

    공유 스토리지는 IT 환경 내의 여러 서버, 컴퓨터 또는 애플리케이션에서 동시에 액세스할 수 있는 스토리지 시스템 또는 리소스를 의미합니다. 이 설정을 통해 모든 참여 시스템이 동일한 데이터 저장소에서 읽고 쓸 수 있으므로 데이터 일관성, 협업, 고가용성 및 확장성이 필요한 시나리오에 이상적입니다.

  • OCI File Storage

    Oracle Cloud Infrastructure File Storage는 지속성과 확장성이 뛰어나며, 안전한 엔터프라이즈급 네트워크 파일 시스템을 제공합니다. VCN의 베어메탈, 가상 머신 또는 컨테이너 인스턴스에서 OCI 파일 스토리지에 연결할 수 있습니다. 또한 Oracle Cloud Infrastructure FastConnect 및 IPSec VPN을 사용하여 VCN 외부에서 OCI File Storage에 접근할 수 있습니다.

  • OCI Database 서비스

    OCI 데이터베이스 서비스는 Oracle Cloud Infrastructure(OCI)에서 제공하는 관리형 데이터베이스 솔루션 포트폴리오를 의미합니다. 이러한 서비스는 Oracle Base Database Service 및 Oracle Exadata Database Service와 같은 다양한 워크로드, 성능 요구 사항 및 데이터 모델을 지원하는 Oracle Cloud의 다양한 데이터베이스 배포 및 관리 옵션을 제공합니다.

  • Oracle Data Guard

    Oracle Data Guard and Active Data Guard provide a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases and that enable production Oracle databases to remain available without interruption. Oracle Data Guard는 인메모리 복제를 사용하여 이러한 대기 데이터베이스를 운용 데이터베이스의 복사본으로 유지 관리합니다. 계획된 운용중단 또는 계획되지 않은 운용중단으로 인해 운용 데이터베이스를 사용할 수 없게 되면 Oracle Data Guard는 모든 대기 데이터베이스를 운용 롤로 전환하여 운용중단과 연관된 작동 중지 시간을 최소화할 수 있습니다. Oracle Active Data Guard는 대부분 읽기 워크로드를 대기 데이터베이스로 오프로드하는 추가 기능을 제공하며 고급 데이터 보호 기능도 제공합니다.

이 플레이북은 OCI를 Oracle Fusion Middleware 확장된 클러스터를 배치하기 위한 예제 인프라로 사용합니다. 이는 Oracle Fusion Middleware 확장 클러스터 설정에 필요한 기본 구성요소에 대한 온프레미스에서 OCI와 동일한 기능입니다.

온프레미스(또는 일반) OCI 상응
사이트(또는 데이터 센터) OCI 영역
공유 저장 영역(예: NFS) OCI File Storage
블록 스토리지 OCI 블록 볼륨
글로벌 로드 밸런서 OCI 트래픽 관리 및 조정 정책
로컬 로드 밸런서 OCI 로드 밸런서
네트워크 OCI 가상 클라우드 네트워크
방화벽/방화벽 규칙 OCI 네트워크 보안 규칙
내부 DNS OCI DNS 프라이빗 보기
물리적 서버/가상 시스템 OCI Compute 인스턴스
온프레미스 데이터 베이스 OCI 데이터베이스 서비스
사이트 간 온프레미스 연결 동적 라우팅 게이트웨이를 사용하는 OCI 원격 피어링

구조

이 섹션에서는 Oracle Fusion Middleware(FMW) 확장 클러스터 구조에 대한 토폴로지 및 고려 사항에 대해 설명합니다.

FMW 확장 클러스터 구조에 적용되는 고려 사항은 다음과 같습니다.

  • 영역

    이 토폴로지에는 두 개의 영역 또는 사이트가 있습니다. 이들 사이의 대기 시간은 10ms RTT(왕복 시간)보다 높지 않아야 합니다. 대역폭 요구 사항은 각 시스템에서 처리되는 페이로드 유형에 따라 다르지만 최소 1Gbps 또는 2Gbps가 권장됩니다.

  • 중간 층

    중간 계층은 단일 도메인과 함께 활성-활성 모델에서 작동합니다. 관리 서버의 절반은 한 사이트에 배치되고 나머지는 다른 사이트에 배치됩니다. 관리 서버는 한 사이트에서 실행되지만 필요한 경우 다른 사이트로 페일오버될 수 있습니다. 이 설정을 일반적으로 확장된 클러스터라고 합니다.

  • 데이터베이스 티어

    데이터베이스 계층은 Oracle Data Guard에서 지원하는 능동-수동 아키텍처를 사용합니다. 기본 데이터베이스는 한 사이트에 있고 대기 데이터베이스는 다른 사이트에 있습니다. 모든 middle-tier 서버는 해당 위치에 관계없이 현재 primary로 사용되는 데이터베이스에 연결되도록 구성됩니다. 각 사이트에 구성된 Oracle Database는 Oracle RAC(Oracle Real Application Clusters)입니다. Oracle RAC를 사용하면 Oracle 데이터베이스를 동일한 데이터 센터 내의 서버 클러스터에서 실행할 수 있습니다. 따라서 응용 프로그램을 변경하지 않고도 내결함성, 성능 및 확장성을 제공합니다.

  • 저장 영역

    공유 저장소는 각 사이트에 로컬입니다. 경합 및 보안상의 이유로 사이트 간 공유 저장소를 사용하지 않는 것이 좋습니다. site1에서 site2로 디스크 미러링 또는 복제를 수행하거나, 각 사이트에서 아티팩트의 복구 가능한 복사본을 제공하는 것이 좋습니다.

  • 영구 저장소

    The WebLogic Persistent Stores (Java Message Service (JMS) and Java Transaction API (JTA)) are configured as Java Database Connectivity (JDBC) stores within the database. 이렇게 하면 두 사이트에서 모두 연결할 수 있습니다. 이렇게 하면 두 사이트 간에 자동 서비스 이전 기능이 작동합니다.

  • 승인 요청

    각 사이트의 웹 서버는 동일한 사이트에 있는 Oracle WebLogic Server 인스턴스에만 요청을 전달합니다. 대기 시간과 영역 간 트래픽을 최소화하기 위해 웹 서버(Oracle HTTP Server 인스턴스)와 다른 사이트의 WebLogic 서버 간에 영역 간 통신이 이루어지지 않습니다.

  • 로드 밸런서

    각 사이트에는 해당 로컬 사이트 내의 웹 서버에만 요청을 전달하는 고유한 전용 로드 밸런서가 있습니다. 로드 밸런서와 다른 사이트에 있는 웹 서버 간에 영역 간 통신은 없습니다.

  • 프론트엔드 액세스

    시스템 앞에서 이 솔루션은 시스템에 대한 단일 프런트엔드 액세스를 제공합니다. 클라이언트는 지정된 사이트에 관계없이 동일하게 유지되는 단일 주소를 사용하여 연결됩니다. 이 방식은 모든 클라이언트가 액세스할 수 있는 DNS(도메인 이름 시스템) 이름을 제공하며, 미리 정의된 조건 및 규칙(예: 클라이언트의 지리적 위치)에 따라 요청의 경로를 사이트로 지정합니다.

다음 다이어그램은 Oracle Fusion Middleware 확장된 클러스터 토폴로지를 보여줍니다.


아래 stretched-cluster-topology.png에 대한 설명입니다.
stretched-cluster-topology.png 그림에 대한 설명

확장 클러스터 토폴로지-oracle.zip

다음 다이어그램은 Oracle Fusion Middleware 확장 클러스터 토폴로지의 WebLogic 도메인 및 클러스터를 보여줍니다.


다음은 stretched-cluster-topology-wls-domain.png에 대한 설명입니다.
그림 stretched-cluster-topology-wls-domain.png에 대한 설명

신축 클러스터 토폴로지-wls-도메인-oracle.zip

장점

전통적인 능동-수동 모델에서 Oracle Fusion Middleware(FMW) 확장 클러스터 모델을 사용할 때의 이점은 다음과 같습니다.
  • 간소화된 관리

    능동-수동 배치는 기본 사이트와 대기 사이트 간에 구성을 동기화할 수 있도록 추가 관리 오버헤드를 발생시킵니다. 대부분의 런타임 정보 및 메타데이터가 데이터베이스에 있지만 Oracle WebLogic Server 구성은 파일 시스템에 있습니다. 따라서 데이터베이스에 대한 Oracle Data Guard 복제 외에도 능동-수동 모델에는 다양한 방식으로 구현될 수 있는 연속 파일 시스템 복제(rsync, 스토리지 레벨 복제 등)가 필요합니다.

    그러나 FMW 확장 클러스터 모델에서는 Oracle WebLogic Server 기반구조가 동일한 도메인의 여러 노드에서 동기화된 구성을 유지합니다. 이 구성의 대부분은 대개 관리 서버의 도메인 디렉토리 아래에 있습니다. 관리 서버가 시작되거나 변경 사항이 구현될 때 이 구성은 동일한 도메인의 다른 노드에 자동으로 전파됩니다. 따라서 구성 변경 사항을 지속적으로 복제해야 하는 능동-수동 접근 방식에 비해 배치의 관리 오버헤드가 매우 작습니다.

  • 일부 페일오버 시나리오의 경우 가용성 향상 및 RTO 및 RPO 감소

    FMW 확장 클러스터 모델은 다음 시나리오에서 능동-수동 모델보다 더 나은 RPO(복구 지점 목표) 및 RTO(복구 시간 목표)를 제공합니다.

    • 단일 사이트 이벤트에서 Middle-tier Failure 완료

      한 위치의 모든 middle-tier 서버가 실패할 경우 시스템은 피어 사이트의 middle-tier 서버에서 즉시 요청을 계속 처리할 수 있습니다. 이 시나리오 유형에서는 RTO 및 RPO가 0입니다.

      이를 위해 대체 위치에 있는 중간 계층 서버는 두 위치의 결합된 워크로드를 유지할 수 있어야 합니다. 이러한 시나리오를 고려하려면 적절한 용량 계획을 수행해야 합니다. 설계에 따라 하나의 사이트만 활성화된 경우 최종 클라이언트의 요청을 제한해야 할 수 있습니다. 그렇지 않으면 사이트는 엄청난 용량으로 설계되어야 하며, 부분적으로는 일정하고 효율적인 용량 사용 목적을 물리쳐야 합니다.

    • 데이터베이스 계층 이벤트의 Failure

      데이터베이스의 스위치오버는 능동-수동 및 FMW 확장 클러스터 모델에서 동일한 RTO 및 RPO를 발생시킵니다. 그러나 중간 계층 서버가 보조 사이트에서 이미 활성 상태이므로 시스템의 전체 RTO가 확장된 클러스터 모델에서 낮습니다. 중간 계층을 재시작할 필요가 없습니다. GridLink 및 FAN(Fast Application Notification) 알림이 포함된 이중 연결 문자열을 사용하여 적절한 데이터 소스 구성을 사용하면 중간 계층에서 데이터베이스 연결의 페일오버를 자동화하여 시스템 RTO를 줄일 수 있습니다.

고려사항

Oracle Fusion Middleware(FMW) 확장 클러스터 모델을 구현할 때 다음 사항을 고려하십시오.
  • 능력 계획

    이 모델에는 두 사이트 간의 페일오버 시나리오를 고려하기 위한 용량 계획이 필요합니다. 전체 사이트가 중간 계층을 잃으면 다른 사이트도 전체 작업 로드를 유지할 수 있어야 합니다. 그렇지 않으면 오버헤드로 인해 사용 가능한 사이트가 응답하지 않을 수 있습니다. 즉, 정상 작동 중에는 페일오버 시나리오를 처리할 수 있는 충분한 용량을 확보하기 위해 중간 계층 노드를 활용하지 않아야 합니다. 웹 계층에도 동일한 규칙이 적용됩니다. 한 사이트에서 모든 웹 서버가 손실되는 경우 다른 사이트의 웹 서버는 모든 시스템 요청을 처리할 수 있어야 합니다.

  • 사이트 간 네트워크 처리량

    네트워크 처리량은 주로 사이트 위치와 네트워크가 신뢰성과 혼잡을 얼마나 잘 처리하는지에 따라 달라집니다. 서버나 소프트웨어의 속도에 관계없이 사이트 간에 데이터를 얼마나 빨리 이동할 수 있는지에 대한 제한이 있습니다. 이에 영향을 주는 두 가지 중요한 요소는 대기 시간과 지터입니다.

    • 대기 시간은 데이터가 한 사이트에서 다른 사이트로 네트워크를 이동하는 데 걸리는 시간입니다. 단방향(출처에서 목적지로) 또는 왕복(여기 및 뒤로)을 측정할 수 있습니다. 라운드 트립 시간(RTT)은 더 일반적이며 ping 명령을 사용하여 확인할 수 있습니다.

    • Jitter는 데이터 패킷이 도착하는 데 걸리는 시간의 차이입니다.

    지터는 일반적으로 대기 시간이 이미 매우 짧은 경우에만 중요하므로 현재 모델의 경우 대기 시간을 낮게 유지하는 것이 특히 중요합니다. 따라서 이러한 종류의 설정에서는 성능 향상을 위한 주요 우선 순위가 대기 시간 제어입니다. 거리는 일반적으로 대기 시간의 가장 관련성이 높은 원인입니다.

    수행된 테스트에 따르면 이 모델의 성능(클러스터의 일부 Oracle WebLogic Server 인스턴스가 데이터베이스와 다른 사이트에 있음)은 RTT(대기 시간)가 10밀리초를 초과할 때 상당히 저하됩니다.

    Oracle은 서로 다른 대기 시간의 영향을 받는 다양한 구성을 사용하여 여러 테스트를 수행했습니다. 이 플레이북에 표시된 참조 대기 시간은 다음과 같이 클러스터를 구분합니다.
    • 동일한 가용성 도메인의 모든 멤버
    • 서로 다른 가용성 도메인의 멤버
    • 주변에 있지만 서로 다른 두 OCI 리전의 멤버

    다음 이미지는 WebLogic 서버와 데이터베이스 간의 서로 다른 대기 시간에 대해 FOD(Fusion Order Demo)를 실행하는 Oracle Fusion Middleware SOA 시스템의 처리량(초당 트랜잭션)을 보여줍니다.


    다음 wls-server-throughput.png에 대한 설명입니다.
    그림 wls-server-throughput.png에 대한 설명

    다음 이미지는 사이트 간 대기 시간이 서로 다른 다른 다른 사이트의 데이터베이스를 사용하는 FOD(Fusion Order Demo)를 실행하는 Oracle Fusion Middleware SOA 시스템에 대한 JTA(Java Transaction API) 활성 시간을 보여줍니다.


    다음은 wls-average-jta-active-time.png에 대한 설명입니다.
    그림 wls-average-jta-active-time.png에 대한 설명

    다음 이미지는 사이트 간 서로 다른 대기 시간(두 사이트 모두 사이트 중 하나의 데이터베이스와 함께 작동)에 대해 초당 트랜잭션의 전체 시스템 처리량에서 관찰된 성능 저하를 보여줍니다.


    아래 system-throughput.png에 대한 설명입니다.
    그림 system-throughput.png에 대한 설명

    주:

    위의 모든 사항을 염두에 두고 여러 테스트에서 성능 저하가 관찰된 경우 Oracle은 사이트 간 10밀리초의 대기 시간(RTT)을 초과하는 Oracle Fusion Middleware 확장 클러스터를 지원하지 않습니다. 시스템은 문제 없이 작동할 수 있지만 트랜잭션 시간은 상당히 증가합니다. 10밀리초(RTT)를 초과하는 대기 시간도 배포 및 JTA, 웹 서비스 또는 애플리케이션 시간 초과에 사용되는 Oracle Coherence 클러스터의 문제를 야기합니다. 따라서 이 플레이북에 제시된 솔루션은 주로 사이트 간 대기 시간이 짧은 사이트 또는 지역에 적합합니다.

  • 지역 간 트래픽

    현재 모델에서는 사이트 간 트래픽을 최소화하여 시스템 처리량에 대한 대기 시간의 영향을 줄여야 합니다. 일반적인 FMW 시스템에서 여러 계층 또는 요소 간의 통신은 다음과 같습니다.

    • 메타데이터 액세스 및 기타 데이터베이스 읽기/쓰기 작업을 위해 Oracle WebLogic Server 인스턴스에서 데이터베이스에 액세스합니다.

    • 로드 밸런서(LBR) 또는 Oracle HTTP Server 인스턴스 및 HTTP 콜백에서 수신되는 HTTP 호출입니다.

    • JNDI(Java Naming and Directory Interface)/RMI(Remote Method Invocation) 및 Oracle WebLogic Server 인스턴스 간의 JMS(Java Message Service) 호출입니다.

    • Oracle Coherence는 시스템의 모든 서버 간에 통지합니다. 예를 들어, SOA는 Coherence를 사용하여 일관된 조합 및 메타 데이터 이미지를 제공합니다.

    • Oracle WebLogic Server 인스턴스 간의 HTTP 세션 복제입니다. 일부 구성 요소는 세션 복제에 의존하여 서버 간 세션의 투명한 페일오버를 가능하게 하는 Stateful 웹 응용 프로그램을 사용합니다. 사용 패턴 및 사용자 수에 따라 상당한 양의 복제 데이터가 생성될 수 있습니다.

    • LDAP(Lightweight Directory Access Protocol)/policy/identity 저장소 액세스는 권한 부여 및 인증을 위해 Oracle WebLogic Server 기반구조에 의해 수행됩니다. 이상적으로 각 사이트에는 한 사이트에서 다른 사이트로의 호출을 최소화하기 위해 정기적으로 동기화되는 독립적인 ID 및 정책 저장소가 있어야 합니다. 또는 두 사이트 모두 동일한 저장소를 공유할 수 있습니다. 점포 공유의 영향은 점포 유형 및 시스템 사용 패턴에 따라 달라집니다.

    가능하면 성능을 향상시키기 위해 위의 모든 사항이 사이트에 포함되어야 합니다. 예:

    • 한 사이트의 서버는 동일한 사이트의 Oracle HTTP Server 인스턴스에서 호출만 수신해야 합니다.

    • 한 사이트의 서버는 동일한 사이트의 서버에만 JMS, RMI 및 JNDI 호출을 생성해야 하며 동일한 사이트에서만 서버에 의해 생성된 콜백을 가져와야 합니다.

    • HTTP 세션 복제는 동일한 사이트의 다른 서버로만 제한되어야 합니다. 각 비즈니스 사례에 대해 복제 및 페일오버 요구 사항을 분석해야 하지만 이상적으로는 사이트 간 세션 복제 트래픽을 최대한 줄여야 합니다.

  • 공유 저장영역

    사이트 간 NFS(네트워크 파일 시스템) 쓰기의 대기 시간으로 인해 심각한 성능 저하가 발생할 수 있습니다. 서버는 해당 사이트에 로컬인 저장 장치를 사용하여 파일 시스템에 대한 읽기/쓰기 요청 경합을 제거해야 합니다. 공유 저장 영역은 각 사이트 내에 있는 것으로 제한되어야 합니다.

  • 기타 자료

    두 사이트는 LDAP, 외부 JMS 대상, 외부 웹 서비스 등과 같은 다른 외부 리소스를 공유할 수 있습니다. 이러한 리소스는 두 사이트에서 일관되게 사용할 수 있어야 합니다. 이러한 외부 리소스에 대한 구성 세부 정보는 이 플레이북의 범위를 벗어납니다.