실패 관리 정보
Oracle Fusion Middleware(FMW) 확장된 클러스터 토폴로지는 개별 구성 요소에서 실패할 수 있습니다.
각 사이트는 Oracle FMW Enterprise Deployment 토폴로지에 설명된 고가용성 모범 사례를 따르며, 로컬 중복성이 구성요소 레벨(예: 로드 밸런서, Oracle HTTP Server 인스턴스, Oracle WebLogic Server 또는 데이터베이스 인스턴스)의 중단으로부터 보호되도록 합니다.
사이트 내의 전체 계층 실패 또는 전체 사이트 실패와 같은 시나리오를 해결하기 위한 고려 사항은 다음 절에서 설명합니다.
한 사이트의 모든 웹 서버 실패 관리
사이트 기본 설정에 관계없이 모든 클라이언트 요청은 다른 사이트로 경로 지정됩니다.
따라서 실패한 웹 서버가 있는 사이트의 Oracle WebLogic 서버는 새 요청을 수신하지 않습니다. Oracle SOA 조합 및 JMS(Java 메시지 서비스) 메시지 처리와 같은 일부 처리를 계속할 수 있습니다. 그러나 이러한 서버에서 내부적으로 생성된 HTTP 콜백은 웹 서버가 실패한 자체 사이트를 가리키므로 실패합니다.
다음 다이어그램은 한 사이트의 모든 웹 서버에서 실패를 보여줍니다.
Failure로부터 Recovery
Oracle Cloud Infrastructure(OCI) 트래픽 관리 조정 정책 또는 전역 로드 밸런서(GLBR) 덕분에 클라이언트가 다른 사이트로 자동으로 재지정됩니다.
손실된 웹 서버 인스턴스의 복원이 단기적으로 불가능한 경우 다음을 수행하여 실패한 웹 계층이 있는 사이트의 WebLogic 서버를 사용할 수 있습니다.
- 다른 사이트에서 Oracle HTTP Server(OHS) 인스턴스를 구성하여 실패한 사이트의 Oracle WebLogic Server 인스턴스로 요청 경로를 지정합니다.
- OHS 구성을 갱신하고
DynamicServerList파라미터를ON로 설정합니다. - 작동 중지 시간을 방지하기 위해 롤링 방식으로 OHS를 재시작하여 이 변경사항을 적용합니다.
- 또한 웹 서버에서 다른 사이트의 WebLogic 서버로 영역 간 통신이 허용되는지 확인합니다.
- OHS 구성을 갱신하고
- 사용할 수 없는 OHS 서버가 있는 사이트에서 시작된 HTTP(하이퍼텍스트 전송 프로토콜) 콜백의 오류를 방지하려면 WebLogic 서버 호스트의
/etc/hosts파일 또는 DNS(전용 도메인 이름 시스템)에서 프론트엔드 이름에 대한 항목을 업데이트하여 다른 사이트의 로드 밸런서를 가리킵니다.
- 실패한 사이트에서 OHS 프로세스를 시작합니다.
Oracle Cloud Infrastructure Health Checks가 다시 정상이 되자마자 트래픽 관리 조정 정책은 정의된 규칙에 따라 두 사이트 간의 클라이언트 요청 로드 밸런싱을 수행합니다.
- 다른 사이트에서
DynamicServerList를 다시OFF로 설정합니다. - WebLogic 서버의
/etc/hosts파일(또는 전용 DNS)에서 변경 사항을 복원하여 자체 사이트 로드 밸런서를 다시 가리키도록 합니다.
다음 이미지는 JMS(Java Message Service) 대기열 메시지 및 한 사이트의 모든 웹 서버 실패 중 클라이언트 실패 요청을 보여줍니다.
예상 복구 시간 목표
DNS 업데이트는 조정 정책 환경설정이 실패한 영역으로 설정된 클라이언트에 영향을 줍니다. TTL 값은 건전한 사이트를 가리키도록 업데이트하기 전에 이러한 클라이언트가 이전 항목을 계속 사용할 기간을 결정합니다. 추가 시간(약 1분)은 OCI 조정 정책에 구성된 건전성 검사의 빈도 및 시간 초과에 따라 달라집니다(상기 테스트에서 건전성 검사 간격 및 시간 초과 10초 동안 30초 사용됨).
GLBR(전역 로드 밸런서)을 사용하는 경우 중단 시간은 GLBR에 구성된 건전성 검사 빈도에 따라 달라집니다. GLBR이 풀을 비정상으로 표시하는 즉시 수신 요청이 다른 사이트로 재지정됩니다. GLBR에서는 DNS 업데이트가 없으므로 프론트 엔드 항목의 TTL 값은 관련이 없습니다.
한 사이트에서 모든 Oracle WebLogic 서버의 실패 관리
실패한 사이트의 로드 밸런서가 실패한 응답을 반환하므로 Oracle Cloud Infrastructure(OCI) 트래픽 조정 정책 및 건전성 검사를 기반으로 하는 프론트엔드 글로벌 밸런싱 기능이 사이트를 비정상으로 표시해야 합니다. 모든 클라이언트 요청은 환경 설정에 관계없이 다른 사이트로 경로 지정됩니다.
WebLogic JMS(Java Message Service) 및 JTA(Java Transaction API) 서비스는 JDBC(Java Database Connectivity) 영구 저장소와 함께 자동 서비스 이전을 사용할 때 다른 사이트의 서버로 자동으로 이전됩니다.
Oracle Fusion Middleware(FMW) SOA 사례에서 자동 복구 클러스터 마스터가 실패한 서버에서 호스트된 경우 사용 가능한 사이트에서 새 클러스터 마스터가 발생합니다. 이 서버는 다른 사이트에서 시작된 SOA 인스턴스의 자동 복구를 수행합니다.
다음 다이어그램은 한 사이트에 있는 모든 WebLogic 서버의 실패를 보여줍니다.
실패-all-weblogic-servers-one-site-oracle.zip
다음 이미지는 사이트에서 모든 WebLogic 서버가 실패할 경우 클라이언트 실패 요청 및 서버당 JMS 메시지를 보여줍니다.
JMS 메시지 그래프에는 각각 서버의 JMS 대기열을 나타내는 네 개의 행이 있습니다. 녹색 및 파란색 선(거의 겹침)은 강제 종료된 서버에 해당합니다. 운용중단이 시작된 후에는 해당 대기열에 대한 JMS 메시지 수가 증가하지 않습니다.
빨간색과 노란색 선은 영역 2에 남아 있는 서버를 나타냅니다. 모든 요청이 이 영역으로 재지정되면 나머지 각 서버는 총 로드 중 50%를 수신합니다. 그러나 대기열에 메시지가 누적되는 속도는 다릅니다. 이는 실패한 서버의 JMS 서버가 나머지 서버 중 하나로 이전되어 해당 서버의 메시지가 이제 세 개의 대기열로 처리되기 때문입니다. 결과적으로 노란색에서 경사면이 아래쪽에 나타납니다(모니터링 도구는 마이그레이션된 대기열의 메시지 수를 표시하지 않음).
Failure로부터 Recovery
실패한 서버를 다시 사용할 수 있게 되면 다음을 수행합니다.
- 실패한 사이트에서 관리 서버를 시작합니다.
- Oracle Cloud Infrastructure Health Checks가 다시 정상이 되자마자 트래픽 관리 조정 정책은 정의된 규칙에 따라 두 사이트 간의 클라이언트 요청 로드 밸런싱을 수행합니다.
예상 복구 시간 목표
이것은 한 사이트의 모든 웹 서버에 오류가 있는 시나리오와 유사합니다.
DNS 업데이트는 조정 정책 환경설정이 실패한 영역으로 설정된 클라이언트에 영향을 줍니다. TTL 값은 건전한 사이트를 가리키도록 업데이트하기 전에 이러한 클라이언트가 이전 항목을 계속 사용할 기간을 결정합니다. 추가 시간(약 1분)은 OCI 트래픽 관리 조정 정책에 구성된 건전성 검사의 빈도 및 시간 초과에 따라 달라집니다(상태 검사 간격에 대한 테스트에 30초가 사용되었고 시간 초과는 10초).
GLBR(전역 로드 밸런서)을 사용하는 경우 중단 시간은 GLBR에 구성된 건전성 검사 빈도에 따라 달라집니다. GLBR이 풀을 비정상으로 표시하는 즉시 수신 요청이 다른 사이트로 재지정됩니다. GLBR에서는 DNS 업데이트가 없으므로 프론트 엔드 항목의 TTL 값은 관련이 없습니다.
데이터베이스의 Failure 관리: Data Guard Switchover 및 Failover
앞에서 "Set Up WebLogic Data Sources"에 제공된 JDBC(Java Database Connectivity) URL 문자열 및 ONS(Oracle Notification Service) 구성은 새 primary database에 대해 자동으로 재연결되도록 보장합니다. 이러한 정확한 테스트(Oracle Fusion Middleware(FMW) SOA FOD 및 높은 작업 로드가 160회 동시 호출인 경우에도 사용)의 경우 데이터베이스 전환 또는 복구에 2분 미만이 걸립니다. 이 시간은 시스템 구성 및 환경에 따라 다를 수 있습니다. 잘 튜닝된 시스템에서는 전환 시간이 1-5분으로 일반적이지만 시스템 크기, 리소스, 작업 로드, 리두 로그 동기화 및 네트워크 성능과 같은 요인은 총 기간에 영향을 줄 수 있습니다. Oracle Data Guard 설명서 및 기타 리소스에 대한 링크는 [자세히 살펴보기] 섹션을 참조하십시오.
데이터베이스의 스위치오버 또는 페일오버 중에 응용 프로그램 오류가 발생합니다. 또한 서비스 마이그레이션을 사용하는 WebLogic 서버는 임대 테이블을 업데이트할 수 없는 경우 노드 관리자가 자동으로 종료하고 다시 시작할 수 있습니다. 기본 임대 매개변수의 예상 동작은 다음과 같습니다.
- 데이터베이스 운용중단이 매우 짧은 경우(1-2분 미만) WebLogic 서버 자동 재시작이 필요하지 않습니다.
- 데이터베이스 중단 시간이 2-10분인 경우 데이터베이스를 다시 시작할 때 "임대 손실"로 인해 WebLogic 서버가 자동 재시작될 수 있습니다.
"Configure Tuning WebLogic Database Leasing"의 앞부분에 설명된 대로 WebLogic의 데이터베이스 임대 재시도를 조정하여 하한을 늘릴 수 있습니다.
- 데이터베이스 운용중단이 훨씬 더 길면(10분 이상) 중요한 JDBC 저장소에 대한 액세스 손실과 같은 다른 실패로 인해 WebLogic 서버가 자동 재시작될 수 있습니다("JTA의 JDBC 저장소를 사용할 수 없음").
다음 다이어그램은 FMW 확장 클러스터 토폴로지의 데이터베이스 스위치오버를 보여줍니다.
stretched-clusters-db-switchover-oracle.zip
다음 이미지는 FMW 확장 클러스터에서 데이터베이스 전환 중 서버 대기열당 클라이언트 요청 성능 및 JMS(Java Message Service) 메시지를 보여줍니다.
Failure로부터 Recovery
실패한 서버를 다시 사용할 수 있게 되면 다음을 수행합니다.
- 데이터베이스 복구를 수행한 경우 실패한 데이터베이스를 복원합니다.
전환을 수행한 경우에는 이 작업이 필요하지 않습니다.
- 원래 사이트로 데이터베이스 스위치백을 수행합니다.
예상 복구 시간 목표
수행된 테스트의 경우 전환에 2분 미만이 걸립니다.
계획되지 않은 switchover 또는 failover의 경우 총 작동 중지 시간은 데이터베이스의 작동 중지 시간에 따라 다릅니다.
- 거의 즉시 데이터베이스 복구 또는 스위치오버를 수행하는 경우 총 복구 시간이 짧습니다. 이는 데이터베이스에 switchover 또는 failover가 필요한 시간에 따라 다릅니다. 수행된 테스트의 경우 switchover가 2분 미만이 되므로 예상되는 RTO(복구 시간 목표)는 다음과 같습니다.
RTO = DB DOWNTIME + SHORT TIME (1-2 min) - 데이터베이스 작동 중지 시간이 길면 Oracle WebLogic Server 자동 재시작과 같은 추가 오류가 발생하여 RTO가 증가할 수 있습니다. 이 경우 예상 RTO는 다음과 같습니다.
RTO = DB DOWNTIME + WEBLOGIC START TIME
WebLogic 관리 서버의 실패 관리
노드 관리자는 실패한 서버를 내부에서 자동으로 다시 시작합니다.
그러나 정전이 관리 서버가 실행되는 호스트에 완전히 영향을 주는 경우 관리 서버를 다른 노드로 페일오버해야 합니다.
기본적으로 관리 서버를 다른 노드에서 다시 시작하여 관리 서버 도메인 디렉토리가 포함된 위치를 가리키며 적절한 VIP(가상 IP)에 매핑되는 수신 주소를 사용하는지 확인하는 작업으로 구성됩니다.
이 관리 서버 도메인 디렉토리는 동일한 영역의 다른 노드에서 사용할 수 있는 공유 저장 영역 위치이거나, 다른 영역의 노드에서 사용할 수 있는 백업 또는 파일 시스템 복제에서 복원할 수 있습니다.
주:
확장된 클러스터 구성에 관계없이 Oracle WebLogic 도메인에 적합한 백업 절차가 마련되어 있어야 합니다.따라서 Oracle Fusion Middleware(FMW) 확장 클러스터 토폴로지에서는 관리 서버를 동일한 영역의 노드로 이전할 때와 관리 서버를 다른 영역의 노드로 이전할 때 다른 고려 사항이 적용됩니다.
다음 다이어그램은 FMW 확장 클러스터의 다른 사이트로 관리 서버 페일오버를 보여줍니다.
다른 영역으로 페일오버
WebLogic Remote Console 및 Oracle Enterprise Manager Fusion Middleware Control에 액세스하여 관리 서버가 제대로 작동 중인지 확인합니다.
동일한 영역으로 페일오버
따라서 페일오버 절차는 관리 서버의 수동 페일오버 확인의 관리 서버에 대한 엔터프라이즈 배치 설명서에 설명된 것과 동일합니다.
Oracle Cloud Infrastructure(OCI) 시스템에서 관리 서버 가상 IP(VIP)를 관리하려면 Oracle Cloud Infrastructure에서 가상 IP(VIP) 사용 블로그에 설명된 단계를 사용할 수 있습니다.
Primary Database를 호스팅하는 전체 영역의 Failure 관리
나머지 사이트의 Oracle WebLogic Server 인스턴스는 이전 섹션에서 설명한 권장 구성을 사용하는 경우 새 기본 데이터베이스에 자동으로 재접속됩니다.
실패한 사이트의 로드 밸런서가 실패한 응답을 반환하므로 프론트 엔드 글로벌 밸런싱 기능이 사이트를 비정상으로 표시해야 합니다. 모든 클라이언트 요청은 환경 설정에 관계없이 다른 사이트로 경로 지정됩니다.
WebLogic JMS 및 JTA 서비스는 JDBC 영구 저장소와 함께 자동 서비스 이전을 사용할 때 다른 사이트의 서버로 자동으로 이전됩니다. Oracle Fusion Middleware(FMW) Oracle SOA Suite의 경우 자동 복구 클러스터 마스터가 실패한 서버에서 호스트된 경우 사용 가능한 사이트에서 새 클러스터 마스터가 발생합니다. 새 클러스터 관리자는 다른 사이트에서 시작된 SOA 인스턴스의 자동 복구를 수행합니다.
다음 다이어그램은 FMW 확장 클러스터 토폴로지에서 전체 영역 1의 실패를 보여줍니다.
Failure로부터 Recovery
실패한 사이트가 복구되고 다시 사용 가능한 후:
- 실패한 호스트의 프로세스(Oracle HTTP 서버, WebLogic Administration Server 및 Managed Server)를 재시작합니다.
관리 서버 VIP(가상 IP)가 설정되었고 시작을 방지하는 고아 파일이 존재하지 않는지 확인하십시오.
- 데이터베이스 복구를 수행한 경우 실패한 데이터베이스를 복원합니다.
전환을 수행한 경우에는 이 작업이 필요하지 않습니다.
- 원래 사이트로 데이터베이스 전환을 수행합니다.
예상 복구 시간 목표
나머지 사이트의 서버는 데이터베이스가 나머지 사이트에서 다시 실행되는 즉시 요청을 계속 처리할 수 있으므로 작동 중지 시간은 데이터베이스를 전환하기 전에 사용된 시간에 따라 달라집니다.
- 거의 즉시 데이터베이스 복구 또는 스위치오버를 수행하는 경우 총 복구 시간이 짧습니다. 이는 데이터베이스에 switchover 또는 failover가 필요한 시간에 따라 다릅니다. 수행된 테스트의 경우 전환에 2분 미만이 걸리므로 예상되는 RTO는 다음과 같습니다.
RTO = DB DOWNTIME + SHORT TIME (1-2 min). - 데이터베이스 작동 중지 시간이 길면 Oracle WebLogic Server 자동 재시작과 같은 추가 오류가 발생하여 RTO가 증가할 수 있습니다. 예상되는 RTO는 다음과 같습니다.
RTO = DB DOWNTIME + WEBLOGIC START TIME
Standby Database를 호스팅하는 전체 영역의 Failure 관리
사이트 기본 설정에 관계없이 모든 클라이언트 요청은 영역 1로 경로 지정되어 요청을 계속 처리합니다. WebLogic JMS 및 JTA 서비스는 JDBC 영구 저장소와 함께 자동 서비스 이전을 사용할 때 사이트 1의 서버로 자동으로 이전됩니다.
Oracle Fusion Middleware(FMW)와 Oracle SOA Suite 사례에서 자동 복구 클러스터 마스터가 실패한 서버에서 호스트된 경우 사용 가능한 사이트에서 새 클러스터 마스터가 발생합니다. 이 서버는 다른 사이트에서 시작된 SOA 인스턴스의 자동 복구를 수행합니다.
운용중단이 기본 데이터베이스에 영향을 주지 않으므로 데이터베이스 전환을 수행할 필요가 없습니다.
다음 다이어그램은 FMW 확장 클러스터 토폴로지에서 전체 영역 2의 실패를 보여줍니다.
Failure로부터 Recovery
실패한 사이트를 다시 사용할 수 있게 되면 Oracle HTTP 서버 및 WebLogic 관리 서버에 대해 실패한 호스트의 프로세스를 재시작합니다.
WebLogic가 시작되지 않도록 하는 고아 파일이 존재하지 않는지 확인하십시오.
글로벌 로드 밸런서 기능(Oracle Cloud Infrastructure 트래픽 관리 조정 정책 또는 글로벌 로드 밸런서) 덕분에 클라이언트의 요청이 두 사이트 간에 다시 밸런싱됩니다.
예상 복구 시간 목표
DNS(도메인 이름 시스템) 업데이트는 지역 2가 지리적 위치 조정 정책의 환경 설정으로 설정된 클라이언트에 영향을 줍니다. DNS 업데이트는 조정 정책 환경설정이 실패한 영역으로 설정된 클라이언트에 영향을 줍니다. TTL 값은 건전한 사이트를 가리키도록 업데이트하기 전에 이러한 클라이언트가 이전 항목을 계속 사용할 기간을 결정합니다. 추가 시간(약 1분)은 OCI 트래픽 관리 조정 정책에 구성된 건전성 검사의 빈도 및 시간 초과에 따라 달라집니다(상기 테스트에서 건전성 검사 간격에 대해 30초가 사용되었고 시간 초과는 10초였습니다).
GLBR(전역 로드 밸런서)을 사용하는 경우 중단 시간은 GLBR에 구성된 건전성 검사 빈도에 따라 달라집니다. GLBR이 풀을 비정상으로 표시하는 즉시 수신 요청이 다른 사이트로 재지정됩니다. GLBR에서는 DNS 업데이트가 없으므로 프론트 엔드 항목의 TTL 값은 관련이 없습니다.