코어 그룹 스케일링 고려사항

고가용성 관리자가 이용하는 CPU와 메모리 같은 시스템 자원의 양은 코어 그룹 크기가 증가함에 따라 일정하게 증가하지 않습니다. 예를 들어, 고가용성 관리자가 사용하는 보기 동기화 프로토콜에는 코어 그룹 멤버에 대한 강력한 결합을 유지보수하기 위해 많은 양의 자원이 필요합니다. 따라서 큰 코어 그룹에서 이용하는 자원의 양이 중요합니다.

보기 동기화 프로토콜 자원 요구사항은 동일한 크기의 여러 코어 그룹마다 상당히 다를 수 있습니다. 보기 동기화 프로토콜이 코어 그룹에 사용하는 자원 양은 다음과 같은 항목을 통해 판별됩니다.
  • 실행 중인 애플리케이션의 수
  • 실행 중인 애플리케이션의 유형
  • 사용되는 고가용성 관리자 서비스

코어 그룹 확장성 설정 시 다음을 확인해야 합니다.

시스템이 올바로 작동 중인 경우에도 다음음 확장성 기술 중 하나 이상을 구현하여 대형 셀에서 고가용성 관리자의 스케일을 조정하십시오. 가장 기본적인 두 가지 기술은 다음과 같습니다.

코어 그룹의 크기 조정

코어 그룹 크기는 자원 사용량에 영향을 주는 고가용성 관리자 처리의 세 가지 측면에 직접 영향을 미칩니다.
  • 가장 중요한 첫 번째 측면은 활성 코어 그룹 멤버 세트에 대한 보기 동기화 프로토콜의 설정입니다. 이 활동을 보통 보기 변경이라고 합니다.
  • 두 번째 측면은 고가용성 관리자가 백그라운드에서 실행하는 일정하게 스케줄된 감지 태스크와 장애 발견 태스크입니다.
  • 세 번째 측면은 기타 제품 컴포넌트에서 고가용성 관리자가 제공하는 서비스를 사용하는 경우 발생하는 자원 사용량입니다.
보기 변경

보기 동기화 프로토콜은 활성 상태의 코어 그룹 멤버에 변경사항이 있음을 발견할 때마다 새 보기를 작성합니다. 보기 변경은 일반적으로 코어 그룹 멤버가 시작되거나 중지될 때 발생합니다. 코어 그룹 멤버가 시작될 때 실행 중인 기타 모든 코어 그룹 멤버에 대한 연결을 엽니다. 코어 그룹 멤버가 중지되는 경우 기타 코어 그룹 멤버는 중지된 멤버에 대해 열린 연결이 닫히는 것을 발견합니다. 어느 경우든지 보기 동기화 프로토콜에서 이 변경을 고려해야 합니다. 새로 시작되는 멤버의 경우 보기 동기화 프로토콜에서 새 멤버를 포함하는 보기를 설정해야 합니다. 중지되는 멤버의 경우 보기 동기화 프로토콜에서 중지된 멤버를 제외한 남아 있는 코어 그룹 멤버의 새 보기를 설정해야 합니다.

새 보기를 설정하는 것은 중요한 활동이지만 시스템 자원을 많이 사용합니다(특히 대형 코어 그룹의 경우).
  • 실행 중인 각 코어 그룹 멤버는 현재 보기에서 전송하거나 수신한 메시지에 대한 정보를 비롯하여 현재 상태에 대해 다른 코어 그룹 멤버와 통신해야 합니다.
  • 새 보기를 설치하기 전에 지정된 보기에서 전송된 모든 메시지를 모든 수신자가 수신하고 수신확인해야 합니다. 일반적인 작동 조건에서는 이와 같은 메시지의 수신확인이 느리게 이루어집니다. 제 시간에 보기 변경 경계에서 메시지를 완료하려면 적극적으로 수신확인하고 재전송해야 합니다.
  • 모든 코어 그룹 멤버가 현재 상태와 관련된 데이터(예: 활발하게 통신할 수 있는 다른 코어 그룹 멤버 세트)를 전송해야 합니다.

활성 멤버 수가 증가함에 따라 새 보기를 설치하면 고가용성 관리자 CPU 사용량이 보다 많이 일시적으로 비선형으로 증가합니다. 20개의 다른 멤버가 존재할 때 하나의 멤버를 추가하거나 제거하는 경우보다 50개의 다른 코어 그룹 멤버가 존재할 때 하나의 멤버를 추가하거나 제거하는 경우가 휠씬 더 많은 자원을 소비합니다.

또한 새 보기를 설치하면 고가용성 관리자를 사용하는 제품 컴포넌트의 상태 변경이 트리거됩니다. 예를 들면, 시작된 멤버 또는 중지된 멤버를 반영하도록 라우팅 테이블을 업데이트하거나 새 멤버에 대해 싱글톤 서비스를 다시 시작해야 할 수 있습니다.

최종 결과는 새 보기를 설치하면 CPU 사용량이 일시적으로 상당히 급상승한다는 것입니다. 코어 그룹 크기가 너무 커지면 보기 변경 경계에서 악화된 네트워크 타이밍 조건이 발생합니다. 이와 같은 조건은 일반적으로 보기를 설치하는 중에 장애를 일으킵니다. 이러한 장애를 복구하는 데에도 CPU가 집중적으로 사용됩니다. 사용 가능한 CPU가 충분하지 않은 경우 또는 페이징이 발생하는 경우에는 장애 수가 빠르게 증가할 수 있습니다.

백그라운드 태스크

고가용성 관리자는 관리 중인 고가용 싱글톤 서비스의 성능 상태 검사와 같은 여러 백그라운드 태스크를 정기적으로 실행합니다. 대부분의 백그라운드 태스크에서는 적은 양의 CPU를 이용합니다. 정기적으로 스케줄된 감지 프로토콜과 장애 발견 프로토콜은 예외입니다.

감지 프로토콜은 실행 중이지 않은 프로세스를 포함하여 현재 연결되어 있지 않은 코어 그룹 멤버 간에 통신을 설정하려고 합니다. N개의 코어 그룹 멤버가 포함되어 있으며 이 중에서 M개가 현재 실행 중인 특정 코어 그룹의 경우에는 감지 기간마다 대략 M x (N – M)개의 감지 메시지가 생성됩니다. 따라서 시작되지 않는 대량의 프로세스를 작성하면 감지 프로토콜 CPU 사용량에 좋지 않은 영향을 미칩니다.

마찬가지로 장애 발견 프로토콜이 실행되는 경우 각 코어 그룹 멤버는 다른 코어 그룹 멤버에 대해 설정된 모든 연결에 하트비트를 전송합니다. M개의 활성 멤버의 경우 M x (M-1)개의 하트비트 메시지가 전송됩니다. 적극적인 장애 발견이 필요한 경우 코어 그룹 크기는 코어 그룹 멤버 간 하트비팅에 이용되는 CPU 사용량에 좋지 않은 영향을 미칠 수 있습니다.

코어 그룹 수가 적으면 두 프로토콜에서 이용하는 CPU 사용량에 긍정적인 영향을 미칩니다. 예를 들어, 코어 그룹에 100개의 활성 멤버가 있는 경우 모든 장애 발견 기간 동안 9900개의 하트비트 메시지가 전송됩니다. 100개의 멤버가 있는 코어 그룹을 20개의 멤버가 있는 다섯 개의 작은 코어 그룹으로 분할하면 메시지 수가 1900개로 상당히 줄어듭니다.

외부 사용
On-Demand 구성과 워크로드 관리(WLM) 같은 기타 제품 컴포넌트에서는 고가용성 관리자가 제공하는 서비스(예: 활성 서버 상태 교환)를 사용하여 라우팅 정보를 유지보수합니다. 해당 컴포넌트에서 이용하는 CPU 사용량은 코어 그룹 크기와 관련이 있습니다. 예를 들어, 고가용 라우팅 정보를 빌드하기 위한 활성 서버 상태 교환의 사용량은 코어 그룹의 크기와 관련이 있습니다.

여러 코어 그룹에 프로세스 분배

두 가지 기본 기술을 사용하여 보기 동기화와 관련 프로토콜에서 이용하는 자원의 양을 최소화할 수 있습니다.
  • 고가용성 관리자가 제공하는 서비스를 사용하지 않는 프로세스에서 고가용성 관리자를 사용하지 않도록 설정할 수 있습니다.
  • 코어 그룹 크기를 작게 유지할 수 있습니다.

고가용성 관리자 CPU 사용량을 제한하는 방법의 핵심은 코어 그룹의 크기를 제한하는 것입니다. 여러 개의 작은 코어 그룹이 하나의 큰 코어 그룹보다 낫습니다. 큰 셀이 있는 경우 여러 개의 코어 그룹을 작성하십시오.

제품을 실행 중인 하드웨어도 사용자의 환경에 적절한 코어 그룹 크기를 판별하는 요소입니다.

큰 코어 그룹을 여러 개의 작은 코어 그룹으로 분할하십시오. 결과 코어 그룹이 라우팅 정보를 공유해야 하는 경우 코어 그룹 브릿지를 사용하여 코어 그룹을 브릿지로 연결할 수 있습니다.

코어 그룹 크기

처음에 다음과 같은 튜닝 활동을 수행하는 경우 합리적으로 코어 그룹 크기를 판별할 수 있습니다.
  • IBM_CS_WIRE_FORMAT_VERSION 코어 그룹 사용자 정의 특성 설정을 6.1.0 값으로 설정하면 코어 그룹 내부 프로토콜을 개선할 수 있습니다. 이와 같은 개선은 버전 6.1 이상에서만 가능합니다.
  • IBM_CS_HAM_PROTOCOL_VERSION 코어 그룹 사용자 정의 특성 설정을 6.0.2.31 값으로 설정하면 코어 그룹 브릿지의 메모리 사용률과 장애 조치(failover) 특성이 상당히 개선됩니다.
  • 전송 메모리 설정을 조정할 수 있습니다. 코어 그룹 전송과 연관된 두 개의 메모리 또는 버퍼 크기 설정이 있습니다. 이 설정의 기본값은 멤버 수가 50 이하인 작은 코어 그룹에 충분합니다. 멤버 수가 50을 초과하는 코어 그룹의 경우 이 설정을 기본값에서 늘려야 합니다.
    참고: 이러한 전송 메모리 설정의 값을 늘려도 고가용성 관리자의 장기 메모리 사용량 또는 보다 정적으로 할당된 메모리로 바로 변환되지는 않습니다.
WebSphere Application Server 네트워크 배치가 상대적으로 최신인 하드웨어에 배치되고 CPU와 메모리가 제한되지 않으며 애플리케이션이 잘 작동하고 네트워크가 안정적이며 코어 그룹 안정성에 영향을 주는 요소(예: 네트워크와 메모리 문제)가 해결된 경우 다음과 같은 코어 그룹 크기를 고려할 수 있습니다.
  • 최대 100개의 멤버가 있는 코어 그룹이 문제 없이 작동해야 합니다.
  • 100개를 초과하는 멤버가 포함된 코어 그룹은 여러 토폴로지에서 문제 없이 작동해야 합니다. 멤버 수가 200을 초과하는 코어 그룹은 권장되지 않습니다.

사용되는 애플리케이션 혼합과 서비스를 기반으로 개별 코어 그룹 조정

코어 그룹 멤버가 사용하는 애플리케이션 혼합과 고가용성 서비스를 기초로 개별 코어 그룹을 추가로 조정해야 할 수도 있습니다.

  • 기본 설정이 적절하지 않은 경우 기본 감지 프로토콜과 기본 장애 발견 프로토콜이 실행되는 빈도를 조정하십시오.
  • 특정 프로세스 또는 프로세스 세트에서 실행할 코어 그룹 조정자를 구성하십시오.
  • 조정자 프로세스의 자원 이용량이 눈에 띄게 많은 경우 여러 인스턴스에 조정자를 파티셔닝하십시오.
  • 정체가 발견되는 경우 네트워크 메시지를 전송하는 데 사용할 분배 및 일관성 서비스(DCS)와 신뢰할 수 있는 멀티캐스트 메시징(RMM) 컴포넌트에서 사용할 수 있는 메모리의 양을 구성하십시오. 메모리 대 메모리 복제를 사용하지 않아도 특정 조건에서 정체가 발생할 수 있습니다.

임시 포트 범위 조정

코어 그룹에서 사용하는 소켓 수는 일반적으로 주요 관심사항이 아닙니다. 각 코어 그룹 멤버는 해당 코어 그룹의 다른 모든 멤버와의 연결을 설정해야 합니다. 따라서 연결마다 연결의 각 끝에 하나씩 두 개의 소켓이 필요하므로 연결 수는 급격히(n 제곱) 증가합니다. 일반적으로 여러 개의 시스템이 관련되므로 대부분의 경우에는 코어 그룹에서 사용하는 소켓 수에 대해 염려하지 않아도 됩니다. 그러나 단일 시스템에서 실행 중인 코어 그룹 멤버 수가 비정상적으로 많은 경우에는 임시 포트 범위와 관련된 운영 체제 매개변수를 조정해야 할 수도 있습니다. 대부분의 운영 체제에서는 임시 포트 범위의 기본 동작이 서로 다릅니다.

우수 사례 우수 사례: 임시 포트 범위에서 포트를 사용하지 마십시오. 잘못된 구성은 아니지만 이 범위에서 포트를 정의하는 경우 코어 그룹 내 멤버간 통신에 예기치 못한 동작이 발생할 수 있습니다. bprac

주제 유형을 표시하는 아이콘 개념 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_ha_cgscale
파일 이름:crun_ha_cgscale.html