FMW 확장 클러스터에 대한 추가 최적화 구성
이 토폴로지의 경우 모두 필수는 아니지만 성능이 향상되고 특정 기능 및 시나리오의 동작이 향상됩니다.
Oracle WebLogic Server(WLS)에서 시간 초과 구성
데이터베이스의 트랜잭션, 트랜잭션 분기, EJB(Enterprise JavaBean) 메소드 호출, 웹 서비스 등에 대해 지정된 시간 초과 제한이 있습니다. Oracle Fusion Middleware 확장된 클러스터 배치는 여러 작업이 다른 위치에 있는 데이터베이스에 액세스해야 하므로 시간 초과 설정에 특히 민감합니다. 시간 초과를 구성하여 다음을 수행합니다.
- 시스템에서 대기 시간을 고려합니다.
관련 대기 시간으로 인해 이러한 유형의 시스템에서 시간 초과를 늘려야 할 수 있습니다. 확장된 클러스터 모델에서 도메인 설정은 두 사이트에 대해 공유되므로 최악의 시나리오에 해당하는 시간 초과를 사용해야 합니다.
- 서로 다른 계층에 걸친 호출 체인에서 올바르게 만료됩니다.
적절한 포용 계층이 제대로 작동하도록 시스템의 여러 계층에서 시간 초과를 구성해야 합니다. 예를 들어, 데이터베이스 시간 초과가 전역 WLS 시간 초과보다 낮은 값으로 설정된 경우 다른 분기에 대한 작업이 완료되기 전에 데이터베이스에서 트랜잭션 ID가 "제거"될 수 있습니다.
다음은 여러 계층의 주 시간 초과 매개변수입니다.
- 전역적 트랜잭션 시간 초과
Oracle WebLogic Server 전역 트랜잭션 시간 초과는 분산 트랜잭션(전역 트랜잭션)이 Oracle WebLogic Server에 의해 자동으로 롤백되기 전에 활성 상태로 유지될 수 있는 최대 기간(초)을 결정합니다. 트리 편집의 서비스 섹션에서 JTA(Java Transaction API)를 선택하고 시간 초과 초를 지정하여 WebLogic 원격 콘솔에서 전역 트랜잭션 시간 초과를 구성합니다.
- XA 트랜잭션 시간초과
XA 데이터 소스의 XA 트랜잭션 시간 초과는 Oracle WebLogic Server에서 데이터 소스에 대한 트랜잭션 분기 시간 초과를 설정하는 데 사용됩니다. 기본적으로 이 값은 0으로 설정되어 있으므로 WebLogic 전역 트랜잭션 시간 초과를 사용합니다. 그러나 XA 리소스에서 기본 시간초과 값을 초과한 장기 실행 트랜잭션이 있을 경우 트랜잭션 시간 초과를 설정하고자 할 수도 있습니다. 이 값은 트랜잭션 탭의 각 XA 데이터 소스에 대해 구성됩니다.
- 분산 잠금 시간 초과
데이터베이스의 분산 잠금 시간 초과는 분산 트랜잭션이 잠긴 리소스를 기다리는 시간(초)을 지정합니다. 해당
SQL ALTER문을 사용하여 매개변수(distributed_lock_timeout)를 수정할 수 있습니다.
사이트 간의 네트워크 지연을 고려하여 가장 느린 트랜잭션에 대해 데이터베이스의 분산 잠금 시간 초과를 충분히 설정합니다. 그런 후 다음 규칙을 사용하여 XA 데이터 소스 및 전역 트랜잭션 시간 초과 값을 더 낮게 설정합니다.
distributed_lock_timeout >= XA DS Timeout >= Global Transaction Timeout응용 프로그램은 추가 시간 초과 매개변수를 사용할 수 있습니다. 예를 들어, Oracle SOA 및 BPEL에는 고려해야 할 추가 시간 초과 매개변수가 있습니다.
- syncMaxWaitTime
syncMaxWaitTime는 동기 클라이언트가 응답을 기다리는 최대 시간입니다. 이 설정은 요청 및 응답 작업이 시간 초과되기까지 걸리는 시간을 정의합니다. BPEL 프로세스가 이 시간 내에 응답을 받지 못하면 작업이 실패합니다. Oracle Enterprise Manager Fusion Middleware Control에서 이 값을 변경하려면 다음과 같이 하십시오.
- SOA-infra를 마우스 오른쪽 버튼으로 누르고 SOA 관리를 선택합니다.
- BPEL Properties를 선택합니다.
- 더 많은 BPEL 구성 속성을 선택합니다.
- syncMaxWaitTime 값(초)을 업데이트합니다.
- EJB 시간 초과
BPEL EJB 메소드가 포함된 경우 트랜잭션 시간 초과(초)를 지정합니다(기본값은 모든 BPEL EJB의 경우 300). 시간 초과를 다음과 같이 수정합니다.
- WebLogic 원격 콘솔 모니터링 트리에서 배치를 선택한 다음 애플리케이션 관리를 선택합니다.
- soa_infra 애플리케이션을 확장한 다음 구성 및 하위 배치를 확장합니다.
- 모듈을 확장하고 특정 BPEL EJB를 선택합니다.
Global Transaction Timeout > BPEL EJB's transaction timeout > syncMaxWaitTime - 웹 서비스 클라이언트의 시간 초과
웹 서비스 클라이언트는 최악의 대기 시간으로 충분히 허용되는 시간 초과로 구성되어야 합니다. 예를 들어, 호출이 사이트 1에서 3초가 걸리지만 사이트 2에서 10초가 걸리는 경우 느린 사이트를 처리하려면 시간 초과를 최소 10초로 설정해야 합니다.
- BPEL 프로세스 시간 초과
BPEL 프로세스에서 특정 요청 회신(동기) 및 전용 수신(비동기) 시간 초과를 사용하는 경우 최악의 시나리오(데이터베이스 대기 시간이 가장 높은 사이트에 대한 호출이 진행되는 경우)에 따라 이를 정의해야 합니다. 이러한 시간 초과 설정은 BPEL 프로세스 내에서 정의되며 각 사이트에 대해 다르게 설정할 수 없습니다. BPEL 프로세스에서 이벤트 및 시간 초과 구성에 대한 자세한 내용은 Oracle SOA Suite용 Oracle Fusion Middleware Developer's Guide를 참조하십시오. 자세히 살펴보기 섹션을 참조하십시오.
세션 복제 구성
일부 응용 프로그램(웹 응용 프로그램, Oracle SOA 편집기, BPM 편집기, BPM 작업 영역 등의 콘솔)에서는 HTTP 세션 객체를 많이 사용합니다.
Oracle Fusion Middleware(FMW) 확장 클러스터 배치의 장점 중 하나는 사이트 간에 원활한 복구를 제공하는 기능입니다. 그러나 영역 간 세션 복제로 인해 시스템의 성능이 저하될 수 있습니다. Oracle은 두 사이트에서 복제를 최소화하기 위해 두 개의 서로 다른 복제 그룹(영역마다 하나씩)을 정의할 것을 권장합니다.
세션 복제 그룹을 구성하려면
- WebLogic 원격 콘솔 트리 편집에서 환경, 서버 순으로 선택합니다.
- 서버 이름을 선택한 다음 클러스터 탭을 선택합니다.
- 영역 1의 각 서버에 대해 동일한 복제 그룹 이름(예: Region1RepGroup)을 입력합니다.
- 영역 1에 사용된 것과는 다르지만 모두 공통 이름을 사용하여 영역 2의 서버에 대해 단계를 반복합니다(예: Region2RepGroup).
복제 그룹을 사용하는 것은 동일한 사이트의 서버에만 상태를 복제하는 것이 가장 좋지만 결정적인 방법은 아닙니다. 한 사이트에서 하나의 단일 서버를 사용할 수 있고 다른 사이트에서 다른 서버를 사용할 수 있는 경우 리전에서 복제가 수행되고 동일한 사이트에서 서버가 다시 온라인으로 전환되더라도 해당 세션에 대해 복제가 계속됩니다.
JMS에 대한 내부 재시작 구성
영구 저장소는 Oracle WebLogic Server(WLS) 서버의 올바른 작동에 중요합니다. 내부 재시작 시 영구 저장소에서 오류가 발생하면 JMS 서비스가 다른 서버로 이전하기 전에 동일한 서버에서 재시작을 시도합니다. 이 방법은 전체 JMS 서비스를 다른 서버로 이전하는 것보다 빠르며 문제를 신속하게 해결할 수 있습니다.
JMS 영구 저장소에 대해 내부 재시작을 구성하려면 관련 JMS 서버 및 영구 저장소를 이전 가능한 대상으로 지정해야 합니다. 이 마이그레이션 가능한 대상은 기본적으로 사용으로 설정되지 않은 실패 시 재시작을 사용해야 합니다. 이 등록 정보를 구성하려면 다음 단계를 수행합니다.
- WebLogic Remote Console에 연결합니다.
- 트리 편집에서 환경, 이전 가능한 대상 순으로 선택합니다.
- 이전 가능한 대상을 선택하고 실패 시 재시작을 사용으로 설정합니다.
- 저장을 선택하고 변경사항을 커밋합니다.
Oracle FMW SOA Suite JMS 어댑터 구성
Oracle은 구성을 단순화하기 위해 클러스터 구문(예: cluster:t3s://cluster_name)을 사용할 것을 권장합니다. 이 접근 방식은 어댑터가 클러스터 내의 현재 활성 서버 목록을 동적으로 검색하여 효율적인 JNDI 컨텍스트 검색을 보장함으로써 구성을 단순화합니다.
시스템에서 대규모 페이로드를 사용하여 JMS 어댑터를 집중적으로 사용하는 경우 각 영역 내의 로컬 서버만 포함하도록 JNDI URL을 구성하는 것이 좋습니다. 즉, 영역 1의 구성에 대해 영역 1의 서버를 지정하고 영역 2의 구성에 대해 영역 2의 서버를 지정합니다. 이 설정은 사이트 컨텍스트 유사성을 보장하여 성능을 최적화하고 대기 시간을 줄입니다.
Oracle FMW SOA Suite 파일 어댑터 구성
이 방식을 사용하면 동일한 파일이 한 번에 하나의 서버에서만 처리되고 두 어댑터 인스턴스가 동시에 동일한 파일에 기록되지 않습니다.
Oracle Fusion Middleware(FMW) 확장 클러스터 토폴로지에서 각 사이트는 독립적으로 작동하여 고유의 전용 공유 스토리지를 사용하여 파일을 처리합니다. 그러나 기본적으로 두 사이트 모두 파일 잠금 및 상호 배제 메커니즘에 대해 동일한 데이터 소스, 스키마 및 테이블을 사용합니다.
아웃바운드 작업에서는 동시 쓰기 작업에서 파일을 겹쳐쓰지 못하도록 고유 시퀀스가 상호 배제로 사용되기 때문에 공유 데이터베이스 테이블을 사용하는 것이 좋습니다.
그러나 인바운드 작업에 대해 "처리 중" 시나리오가 발생할 수 있습니다. 한 사이트의 파일 어댑터 인스턴스는 파일을 "차단됨"으로 표시할 수 있습니다. 두 사이트에 동일한 파일 이름이 존재할 경우 이 방식은 두 위치 모두에서 해당 처리를 차단할 수 있지만 파일은 그 중 하나에서만 사용됩니다. 이러한 상황을 방지하기 위해 다음과 같은 여러 가지 대안이 있습니다.
- 사이트별 파일 이름 지정 규칙을 구현합니다. 사이트에 기반한 파일 이름에 고유 식별자를 사용하여 이름 충돌 및 이후 차단 가능성을 줄입니다.
- 파일 어댑터 잠금 및 상호 배제 테이블의 각 영역에 대해 별도의 스키마를 구성하여 파일 잠금 및 상호 배제 메커니즘이 독립적으로 작동하여 사이트 간 차단을 방지합니다.
- 파일 어댑터 잠금 및 상호 배제 테이블에 대해 별도의 데이터베이스를 사용하여 파일 처리 메타 데이터가 별도로 관리되도록 합니다.
각 영역에서 서로 다른 데이터베이스 또는 별도의 스키마를 사용하도록 파일 어댑터를 구성하려면 적절한 스키마 소유자 및 테이블을 생성하고 새 데이터 소스를 설정해야 합니다. 영역 1의 서버는 원래 데이터 소스를 계속 사용하고, 영역 2의 배치 계획만 새 데이터 소스를 사용하도록 수정됩니다.
영역 1의 서버는 원래 데이터 소스를 사용하고 영역 2의 서버는 새 데이터 소스를 사용합니다.
Oracle Fusion Middleware Oracle SOA Suite In-Memory SOA 구성
이렇게 하면 캐시에서 읽기 및 쓰기 작업이 수행되므로 이러한 비즈니스 프로세스의 성능과 확장성이 향상됩니다.
BPEL 상태 정보는 Oracle Coherence 캐시에 저장되고 캐시에서 가져옵니다. 프로세스 상태는 결함이 있는 경우에만 데이터베이스에 기록되며, 나중에 쓰기 스레드를 사용하여 정기적으로 기록됩니다.
인메모리 SOA는 Oracle Fusion Middleware 확장된 클러스터 토폴로지에서 지원되지 않습니다. 여기서 Coherence 캐시 사용은 지연에 매우 민감하므로 최소여야 합니다.
WebLogic 데이터베이스 리스 튜닝 구성
데이터베이스 임대는 자동 서비스 이전을 지원하는 데 사용되는 핵심 메커니즘으로, 특히 JMS 서버 또는 JTA 트랜잭션 복구 서비스와 같은 클러스터화된 싱글톤 서비스에 사용됩니다. 클러스터의 여러 서버에서 이러한 싱글톤 서비스의 소유권을 관리하고 조정하는 데 사용됩니다. 이 메커니즘은 데이터베이스를 중앙 지점으로 사용하여 클러스터의 어느 서버를 "소유"하거나 특정 싱글톤 서비스를 특정 시간에 관리할지 안정적으로 추적하고 제어합니다. 이렇게 하려면 소유 서버에 의해 주기적으로 업데이트(갱신)되는 릴리스 레코드를 데이터베이스에 저장합니다. Oracle WebLogic Server용 클러스터 관리의 마이그레이션 가능 서비스에 대한 임대를 참조하십시오.
이 설명서의 앞부분에 제공된 GridLink 데이터 소스에 대한 구성은 데이터베이스 페일오버 또는 스위치오버가 발생할 때 자동 재연결을 보장합니다. 그러나 데이터베이스 임대 또는 JDBC 영구 저장소로 구성된 모든 서버는 데이터베이스 운용중단, 전환 또는 복구 중 종료될 수 있습니다. JTA 서비스와 같은 중요한 부속 시스템이 실패하면 서버가 FAILED 상태로 설정되고 노드 관리자가 자동으로 다시 시작됩니다.
FAILED 상태로 이동하는 데 걸리는 시간은 다양합니다. 관련 검사가 트리거되는 시기에 따라 달라지며 다음과 같은 다양한 이유로 발생할 수 있습니다.
- 서버가 총 재시도 횟수 이후에 임대 테이블을 갱신할 수 없는 경우
- 다양한 재시도 및 내부 재시작 후 서버에서 JTA JDBC 영구 저장소에 액세스할 수 없는 경우
데이터베이스 switchover는 몇 분 정도 걸릴 수 있습니다. JTA JDBC 영구 저장소에 대한 액세스 손실로 인해 WLS 서버를 자동으로 재시작하는 데는 약 8-9분 정도 걸리므로 일반적인 데이터베이스 스위치오버 또는 페일오버 중에 트리거되지 않습니다. 그러나 기본 임대 구성을 사용하여 임대가 2분 이내에 손실되어 서버가 FAILED 상태로 전환될 수 있습니다. 따라서 Oracle WebLogic Server 재시작은 WebLogic 서버가 데이터베이스 임대를 사용 중인 경우 Oracle Data Guard 전환 또는 복구 중 자동으로 트리거될 수 있습니다.
데이터베이스 임대를 사용하는 서버의 데이터베이스 운용중단에 대한 복원력을 향상시키는 두 가지 매개변수가 있습니다. 이러한 매개변수는 database-leasing-basis-connection-retry-count(기본적으로 1회 재시도) 및 database-leasing-basis-connection-retry-delay(기본적으로 1초)입니다. 이러한 매개변수를 늘리면 손실된 임대 오류가 발생하기 전의 시간이 길어집니다. 이를 통해 WebLogic 서버는 자동으로 다시 시작하지 않고도 더 긴 데이터베이스 중단을 허용할 수 있습니다. 다시 사용할 수 있게 되면 데이터베이스에 다시 연결하기만 하면 됩니다. 데이터베이스가 작동 중지된 동안에는 연결 시도가 실패하지만 WebLogic 서버는 다시 시작되지 않습니다.
따라서 확장된 클러스터에서는 데이터베이스 운용중단에 대해 WebLogic 서버의 탄력성을 높이기 위해 Database Leasing Connection Retry Count and Timeout의 값을 늘리는 것이 좋습니다. 이러한 등록 정보를 변경하려면 WLST 명령을 사용합니다. 예:
$ORACLE_COMMON_HOME/common/bin/wlst.sh
connect('weblogic','password','t3s://ADMINVHN:9002')
edit()
startEdit()
cd('/Clusters/' + 'My_Cluster')
cmo.setDatabaseLeasingBasisConnectionRetryCount(10)
cmo.setDatabaseLeasingBasisConnectionRetryDelay(10000L)
save()
activate()
disconnect()
exit()참고:
서버가 FAILED 상태가 되면 노드 관리자가 기본적으로 서버에 대해 두 번의 다시 시작을 시도합니다. 서버를 올바르게 시작할 수 없는 경우 FAILED_NOT_RESTARTABLE로 표시됩니다. 서버의 Health 탭에서 다시 시작 횟수를 조정할 수 있습니다. 간격 내 최대 재시작 매개변수를 사용하여 노드 관리자가 재시작 간격에 지정된 간격 내에서 서버를 재시작할 수 있는 횟수를 정의합니다.Coherence 구성
예를 들어, Oracle SOA Suite는 Oracle Coherence를 사용하여 클러스터에 복합 배포 및 메타데이터(MDS) 업데이트를 전달합니다.
Oracle Coherence는 클러스터 멤버 검색 및 메시징을 위한 멀티캐스트 및 유니캐스트 통신을 모두 지원합니다. 유니캐스트는 여러 데이터 센터 또는 클라우드 리전과 같이 멀티캐스트를 사용할 수 없거나 지원되지 않는 환경에서 특히 적합합니다. 잘 알려진 주소(WKA) 기능을 사용하여 클러스터 멤버는 멀티캐스트에 의존하지 않고도 클러스터를 검색하고 연결할 수 있습니다. WKA가 구성된 경우 모든 멀티캐스트 통신이 사용 안함으로 설정됩니다. 기본적으로 Oracle Fusion Middleware 제품은 Coherence에 대해 미리 정의된 WKA 목록과 함께 유니캐스트를 활용합니다.
Oracle Coherence는 클러스터 구성 중 지연 및 클러스터 멤버의 하트비트 응답에 민감합니다. 그러나 최근 버전은 allowable variance와 같은 기능을 통해 통신 지연에 대한 허용 한도를 높였습니다. allowable variance는 Coherence 클러스터 내의 네트워크 통신에서 허용 가능한 타이밍 변동을 정의합니다. 이 구성 가능한 매개변수(maximum-time-variance)는 기본값이 16ms로 설정되며 RTT(왕복 시간) UDP 통신에 대해 허용되는 최대 대기 시간을 설정합니다. Coherence는 관찰된 네트워크 대기 시간 또는 불일치에 대응하여 이 값을 동적으로 조정하여 예상 타이밍에 더 큰 편차를 수용함으로써 클러스터 안정성과 성능을 유지합니다. 메시지 Increasing allowable variance to XX는 이러한 조정을 나타냅니다. Oracle Coherence를 사용한 애플리케이션 개발의 운영 구성 요소를 참조하십시오.
이러한 Oracle Coherence 개선으로 인해 대기 시간이 FMW 확장 클러스터 토폴로지(<10ms RTT)에 대한 권장 제한 내에 남아 있는 경우 클러스터 형성에 오류가 보고되지 않습니다. 그러나 클러스터 하트비트에서 긴 지연으로 인해 배포 경합이 발생하고 중단에 대한 반응 시간이 잘못될 수 있습니다.
Coherence 클러스터 구성 또는 작업에서 오류가 발생하는 경우 다음 Coherence 네트워킹 시간 초과 매개변수를 조정할 수 있습니다.
<multicast-listener><join-timeout-milliseconds>. 원래 멀티캐스트 구성을 위해 설계되었음에도 불구하고 유니캐스트의 조인 시간 초과 영향도 마찬가지입니다. 초기 노드가 클러스터를 구성하는 데 걸리는 시간을 결정하고, 그 후에 각 노드가 클러스터를 찾는 데 걸리는 시간을 결정합니다(WKA 목록에 있는 경우). 기본값은 3000입니다. 신뢰할 수 없는 네트워크에서 새 클러스터를 시작하기 전에 클러스터를 찾기 위해 더 오랜 시간 동안 이 값을 늘려야 할 수 있습니다.<packet-publisher><packet-delivery><resend-milliseconds>. 패킷 재전송 간격은 패킷을 재전송하기 전에 패킷 게시자가 해당 ACK 패킷을 기다리는 최소 시간(밀리초)을 지정합니다. 이것은 RTT의 몇 배가되어야하며 10x은 괜찮습니다. 기본값은 200입니다.<packet-publisher><packet-delivery><timeout-milliseconds>. 확인이 필요한 패킷의 경우 패킷이 재전송되는 최대 시간(밀리초)을 지정합니다. 이 시간 초과가 만료된 후 Coherence는 수신자가 종료된 것으로 간주될지 여부를 결정합니다. 기본값인 5분이면 충분하지만 클러스터에 조인할 때 시간 초과가 발생하지 않도록 늘릴 수 있습니다.<packet-publisher><packet-delivery><heartbeat-milliseconds>이 매개변수는 tcp-ring 종료 감지에 대한 하트비트 간격입니다. 기본 하트비트 값은 1초입니다. 네트워크 트래픽을 완화하기 위해 값을 늘릴 수 있지만, 이렇게 하면 실패한 멤버의 감지가 길어집니다.<tcp-ring-listener><ip-timeout>및<ip-attempts>클러스터 구성원을 호스팅하는 컴퓨터에 연결할 수 없게 되었는지 확인하기 전의 시간과 시도 횟수입니다. IP 시간 초과는 RTT 이상의 10x 영역에 있어야 하며 최소값은 5s입니다.<cluster-config><tcp-ring-listener><enabled>. 네트워크 트래픽을 완화하기 위해 tcp-ring 종료 감지를 사용 안함으로 설정할 수도 있지만 실패한 멤버를 감지하는 데 시간이 더 오래 걸립니다. 사망 감지를 사용 안함으로 설정하려면 false로 설정합니다. 사용 안함으로 설정된 경우 클러스터 멤버는 패킷 게시자의 재전송 시간 초과 간격을 사용하여 다른 멤버가 UDP 패킷에 대한 응답을 중지했는지 확인합니다(기본적으로 5분으로 설정됨).
기본 구성 설정을 수정하려면 Coherence 우선 적용 파일을 사용합니다. custom-coherence-override-<name>.xml라는 파일을 생성하고 클러스터 내의 모든 서버에서 일관되고 액세스할 수 있는지 확인합니다. 이 파일을 java 속성 tangosol.coherence.override에 지정합니다. setUserOverrides.sh 파일의 EXTRA_JAVA_PROPERTIES java 속성에서 설정할 수 있습니다. 예:
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dtangosol.coherence.override=/u01/oracle/config/coherence_custom/custom-coherence-override.xml"매개변수를 조정하기 위한 Coherence 우선 적용 파일의 예:
<?xml version='1.0'?>
<!--
This is a custom operational configuration override
-->
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd"
>
<cluster-config>
<multicast-listener>
<join-timeout-milliseconds>5000</join-timeout-milliseconds>
</multicast-listener>
<tcp-ring-listener>
<ip-timeout>20s</ip-timeout>
<ip-attempts>3</ip-attempts>
</tcp-ring-listener>
<packet-publisher>
<packet-delivery>
<resend-milliseconds>200</resend-milliseconds>
<timeout-milliseconds>650000</timeout-milliseconds>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>
tcp-ring 간격을 튜닝하기 위한 coherence 우선 적용 파일의 예제:
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<packet-delivery>
<heartbeat-milliseconds>5000</heartbeat-milliseconds>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>tcp-ring death-detection을 사용 안함으로 설정하는 coherence 우선 적용 파일의 예:
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<tcp-ring-listener>
<enabled>false</enabled>
</tcp-ring-listener>
</cluster-config>
</coherence>
Net Service 성능 구성
일부 운영 체제 기본 구성은 최적화되지 않을 수 있으며 데이터 전송의 효율성을 높이기 위해 일부 매개변수를 조정하는 것이 매우 중요합니다. 이러한 조정은 JDBC 클라이언트와 서버 간에 높은 대기 시간이 있을 때 특히 중요합니다. 데이터베이스 액세스 대기 시간이 가장 높은 서버는 성능 최적화를 위해 네트워크 버퍼 및 Oracle Net Services 설정의 구성을 안내해야 합니다.
최적의 구성을 결정하는 주요 지표 중 하나는 대역폭 지연 제품(BDP)입니다. 특정 시간에 네트워크에서 전송될 수 있는 최대 데이터 양을 나타냅니다. 네트워크 링크의 용량(대역폭)에 왕복 지연 시간(대기 시간)을 곱하여 계산됩니다.
BDP = Bandwidth × Round-Trip Time (RTT)- RTT: OCI에서는 OCI 콘솔의 영역 간 대기 시간 페이지에서 리전 간 평균 RTT를 얻을 수 있습니다. 또는 몇 분 동안 한 호스트에서 다른 호스트로 ping하는 것과 같은 명령을 사용하여 RTT(왕복 시간)를 확인하고 반환된 응답 시간을 사용할 수 있습니다.
- 대역폭: OCI 리전 간에는 대역폭이 보장되지 않으며, OCI는 특정 OCI 대역폭 측정 도구를 제공하지 않습니다. 정확한 대역폭 측정을 위해 iPerf와 같은 도구를 사용하여 테스트를 수행할 수 있습니다. 프랑크푸르트와 암스테르담 사이의 테스트된 대역폭은 약 2~2.5Gbps입니다.
TCP 소켓 버퍼 설정은 네트워크를 통해 한 번에 전송되는 패킷 수를 제어합니다. 최적의 처리량을 얻으려면 소켓 버퍼 크기를 최소한 BDP로 설정하는 것이 좋습니다. 대부분의 경우 BDP의 버퍼 크기를 두 배로 설정하면 특히 대기 시간이 긴 네트워크에서 성능을 더욱 향상시킬 수 있습니다. 하지만 버퍼가 지나치게 크면 메모리 사용량이 늘어날 수 있습니다. 따라서 BDP 범위 내의 버퍼 크기를 BDP의 3배로 설정하는 것이 좋습니다.
BDP ≤ Socket Buffer Size ≤ 3 × BDP데이터베이스에서 IO 버퍼 크기 구성
SEND_BUF_SIZE 매개변수를 설정하면 충분합니다.
데이터베이스 서버가 큰 요청을 수신하는 경우 RECV_BUF_SIZE 매개변수도 설정합니다. SSH 등의 일반 TCP 세션에서 추가 메모리를 사용하지 않도록 운영 체제 레벨 대신 데이터베이스의 Oracle Net Services 레벨에서 이러한 세션을 튜닝하는 것이 좋습니다.
데이터베이스 서버에 대해 이러한 매개변수를 구성하려면 listener.ora 또는 sqlnet.ora 파일에서 버퍼 공간 크기를 설정합니다.
-
listener.ora파일에서 특정 프로토콜 주소 또는 설명에 대한 버퍼 공간 매개변수를 지정합니다. 다음은 Oracle Cloud Infrastructure(OCI)의 Base Database System에 있는 일반적인 Oracle RAC 리스너 구성에 대한 설정의 예입니다.LISTENER_SCAN2=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN2)))) LISTENER_SCAN1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))) LISTENER_SCAN3=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN3)))) (…) LISTENER=(DESCRIPTION=(SDU=65535)(SEND_BUF_SIZE=10485760)(RECV_BUF_SIZE=10485760)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))) -
매개변수가
sqlnet.ora에 설정된 경우 모든 리스너에 전역적으로 적용됩니다. 다음은sqlnet.ora파일의 설정 예입니다.RECV_BUF_SIZE=10485760 SEND_BUF_SIZE=10485760
중간 계층 노드에서 IO 버퍼 크기 구성
Linux 운영 체제는 수신 및 발신자 버퍼 모두에 대해 자동 튜닝을 사용합니다.
수신 버퍼의 경우 자동 튜닝은 /proc/sys/net/ipv4/tcp_moderate_rcvbuf 파라미터에 의해 결정됩니다. 파라미터의 값이 1이면 자동 튜닝이 활성화됩니다. 자동 튜닝을 사용하면 최대 버퍼 크기가 4MB인 각 연결에 대해 수신기 버퍼 크기(및 TCP 윈도우 크기)가 동적으로 갱신됩니다.
발신자 버퍼의 경우 자동 튜닝도 기본적으로 활성화됩니다. 수신 버퍼 자동 튜닝은 tcp_moderate_rcvbuf 파라미터를 통해 제어할 수 있지만 전송 버퍼 자동 튜닝에는 직접 토글이 없습니다. 고정 버퍼 크기만 설정하면 전송 버퍼 자동 튜닝이 비활성화됩니다.
이러한 자동 튜닝 프로세스는 데이터 전송 및 수신을 위해 메모리 할당을 관리하는 여러 커널 파라미터에 의해 제어됩니다.
- 접속 버퍼 크기당
각 TCP 연결에 대한 메모리 할당은 다음 두 매개변수로 정의됩니다.
/proc/sys/net/ipv4/tcp_rmem- TCP 수신 버퍼용으로 예약된 메모리를 지정합니다./proc/sys/net/ipv4/tcp_wmem- TCP 전송 버퍼용으로 예약된 메모리를 지정합니다.
두 파라미터 모두 세 가지 값을 받아들입니다.
- 최소 버퍼 크기: TCP 소켓에 대해 할당된 최소 버퍼 크기입니다.
- Default Buffer Size: 생성 시 TCP 소켓에 지정된 초기 버퍼 크기입니다.
- Maximum Buffer Size: TCP 소켓에 대해 자동으로 할당될 수 있는 가장 큰 버퍼 크기입니다.
이러한 설정은 자동 튜닝 메커니즘의 경계를 설정하고 메모리 사용량(특히 메모리 스트레스 기간)의 균형을 맞추는 데 도움이 됩니다.
- 응용 프로그램별 버퍼 크기
응용 프로그램에서 특정 버퍼 크기를 요청할 수 있지만 이러한 요청은 다음 파라미터에 의해 정의된 제한을 받습니다.
/proc/sys/net/core/rmem_max는 응용 프로그램이 요청할 수 있는 수신 버퍼 크기에 대한 상한을 설정하는 최대 수신 창입니다./proc/sys/net/core/wmem_max는 애플리케이션이 요청할 수 있는 전송 버퍼 크기에 대한 상한을 설정하는 최대 전송 창입니다.
IO 버퍼 크기를 조정하려면 다음과 같이 하십시오.
TCP 자동 튜닝은 네트워크의 대역폭 지연 제품에 맞게 크기가 조정된 경계를 사용하여 사용으로 설정된 상태로 유지되므로 시스템 메모리 사용량의 크기를 초과하지 않고도 처리량이 향상됩니다.
세션 데이터 장치 크기 구성
Oracle Net Services는 이러한 장치가 네트워크를 통해 전송되기 전에 채워질 때까지 기다립니다. 이러한 버퍼는 각각 SDU(세션 데이터 장치)입니다. Oracle Net Services에 제공된 데이터 양으로 SDU의 크기를 조정하면 Oracle Fusion Middleware 확장된 클러스터에서 5밀리초 RTT보다 높은 대기 시간으로 성능, 네트워크 사용률 및 메모리 소비를 향상시킬 수 있습니다.
SDU 크기는 512바이트에서 2MB로 설정할 수 있습니다. Oracle Database 23ai에서 기본 SDU 크기는 64KB(65,536바이트)입니다. 이전 데이터베이스 릴리스에서는 기본 SDU 크기를 8KB로 설정했습니다.
사용된 실제 SDU 크기는 연결 시 클라이언트와 서버 간에 협상되며 두 값 중 더 작습니다. 기본값과 다른 SDU 크기를 구성하려면 클라이언트 및 서버 컴퓨터 모두에서 SDU를 구성해야 합니다. Oracle은 SDU를 가능한 최대값(64k)으로 설정할 것을 권장합니다.
클라이언트와 서버는 연결 시 SDU를 협상합니다. 양쪽을 구성하면 의도한 SDU가 사용됩니다.