고가용성 SAP HANA 시스템 설치

SAP HANA 데이터베이스 수명 주기 관리자는 프로그램 인터페이스 중 하나에 매개변수 지정 방법을 조합하여 SAP HANA 다중 호스트 시스템을 설치하는 데 사용할 수 있습니다.

다중 호스트 시스템은 활성 작업 호스트 또는 유휴 대기 호스트로 구성될 수 있는 호스트가 여러 개인 시스템입니다. SAP HANA 소프트웨어는 분산 설치가 가능한 유연한 아키텍처를 위해 제작되었습니다. 즉, 서로 다른 호스트 간에 부하를 분산시킬 수 있습니다. SAP HANA 소프트웨어는 공유 파일 시스템 환경에 설치할 수 있습니다. 이 공유 파일 시스템은 시스템의 일부인 모든 호스트에서 마운트되어야 합니다.

다중 호스트 시스템은 여러 호스트에 신규 시스템으로 설치하거나 이미 설치된 단일 호스트 시스템에 하나 이상의 신규 호스트를 추가하여 설치할 수 있습니다. 기존 시스템에 호스트를 추가하려면 SAP HANA 내부 HDBLCM을 사용합니다.

다중 호스트 시스템을 설치하기 전에 호스트 그룹화 및 저장 옵션과 같은 다중 호스트 시스템 개념을 검토해야 합니다.

다중 호스트 시스템을 구성할 때 추가 호스트를 작업 호스트 또는 대기 호스트로 정의해야 합니다(기본값은 작업 호스트). 작업자 기계는 데이터를 처리합니다. 대기 기계는 어떠한 처리도 처리하지 않으며, 대신 작업자 시스템 장애 발생 시 프로세스를 인계받을 때까지 기다립니다.

인메모리 데이터베이스로서 SAP HANA는 장애 발생 시 데이터를 안정적으로 유지하는 것도 중요하게 생각하지만, 메모리에 다시 로드된 그러한 데이터를 대부분 사용해서 작업을 재개하는 것도 중요하게 생각합니다. 호스트 자동 장애 조치(Host auto-failover)는 시스템 복제에 대한 추가 또는 대체 조치로 사용할 수 있는 로컬 오류 복구 솔루션입니다. 하나의(또는 여러 개의) 대기 호스트가 SAP HANA 시스템에 추가되어 대기 모드에서 작동하도록 구성됩니다.

다중 호스트 시스템을 설치하기 전에 고가용성이 필요한지 여부와 선호하는 호스트 자동 장애 조치를 위해 호스트를 그룹화하는 방법을 고려해야 합니다. 호스트 자동 장애 조치에 성공하려면 활성(작업자) 호스트가 실패하면 실패한 호스트의 지속 데이터 및 로그 파일을 사용하여 데이터베이스 인스턴스를 시작하여 대기 호스트가 역할을 인계합니다. SAP HANA 인스턴스 중 하나의 이름 서버는 모든 호스트를 정기적으로 처리하는 클러스터 관리자의 역할을 합니다. 실패한 호스트가 발견되면 클러스터 관리자는 대기 호스트가 역할을 인계하고 실패 호스트가 더 이상 파일에 대한 쓰기 액세스("펜싱")를 허용하지 않도록 하여 데이터 손상을 방지합니다. 서비스는 일반적으로 hdbdaemon에 의해 재시작되기 때문에 단일 서비스의 크래시가 장애 조치를 트리거하지 않습니다.

호스트 그룹화는 작업자 호스트 간의 부하 분배에 영향을 미치지 않습니다. SAP HANA 시스템의 모든 작업자에게 부하가 분배됩니다. 시스템에 대기 호스트가 여러 개 있는 경우 호스트 그룹화를 고려해 보아야 합니다. 그 이유는 호스트 그룹화는 작업 머신에서 장애가 발생할 때 대기 리소스의 할당을 결정하기 때문입니다. 호스트 그룹을 별도로 지정하지 않으면 모든 호스트는 "default"라는 하나의 호스트 그룹에 소속됩니다. 하나의 호스트 그룹에 있는 대기 호스트가 많을수록 장애 조치 보안이 커집니다.

각 대기 호스트가 서로 다른 호스트 그룹에 있는 경우, 장애가 발생하는 작업 호스트와 동일한 그룹에 있는 대기 호스트가 더 선호됩니다. 동일한 호스트 그룹에서 대기 호스트를 사용할 수 없는 경우 시스템은 다른 호스트 그룹의 일부인 대기 호스트로 장애 조치를 시도합니다. 이 구성의 장점은 기계 리소스가 혼합된 SAP HANA 시스템에서는 유사한 크기의 컴퓨터를 함께 그룹화할 수 있다는 것입니다. 소규모 작업자 호스트가 실패하고 같은 그룹의 작은 대기가 인계되는 경우 프로세스는 리소스가 비슷한 컴퓨터로 이동하므로 최적의 리소스 할당을 통해 평소와 같이 처리를 계속할 수 있습니다.

SAP Business Warehouse를 사용하여 온도 기반 데이터 전략을 적용하는 경우 스케일별 SAP HANA 랜드스케이프의 한 노드를 웜 데이터에만 예약하여 메모리 및 하드웨어 리소스 사용을 크게 최적화할 수 있습니다. 정보 수명 주기 관리에서는 액세스 빈도에 따라 데이터가 핫, 웜 또는 콜드로 분류되는 다중 온도 전략이 종종 적용됩니다. 이 분류 및 데이터 사용에 따라 이 데이터는 다른 메모리 영역에 저장됩니다.

여러 가지 이유로 다중 온도 메모리 전략이 필요할 수 있습니다. 예를 들면 다음과 같습니다.

• 과거 데이터 저장

• 여러 해 동안의 웹 데이터 및 자세한 시스템 로그에 대한 클릭스트림 로그.

• 법적 이유로 최소 7년 동안 모든 데이터를 저장해야 하는 경우 등 회사 데이터를 저장하기 위한 가이드라인입니다.

표준 SAP HANA 사이징 가이드라인은 사용 가능한 RAM의 50%에 해당하는 데이터 사용 공간을 허용합니다. 따라서 모든 데이터를 항상 RAM에 보관할 수 있고 중간 결과 세트에 충분한 공간이 확보됩니다. 이러한 사이징 가이드라인은 확장 그룹에서 상당히 완화될 수 있습니다. 웜 데이터에 액세스하는 빈도는 낮고 성능 SLA가 감소하며 CPU 집약적인 프로세스가 줄어들고 부분적으로만 동시에 액세스할 수 있기 때문입니다.

다중 온도 메모리 전략을 구현하기 위해 호스트를 작업자 그룹에 지정할 수 있습니다. 그런 다음 핫 데이터와 웜 데이터가 호스트에 분배됩니다. 성능 및 메모리 사용을 늘리기 위해 작업자 노드가 별도의 확장 노드에 지정됩니다. 표준 노드(코디네이터 및 작업자)와 달리, 확장 노드는 다른 데이터(핫)와 같이 자주(웜) 액세스되지 않는 데이터에만 사용됩니다. 자세한 내용은 SAP Note 2453736을 참조하십시오.

단일 호스트 SAP HANA 시스템에서는 직접 연결된 내부 또는 외부 저장 장치(예: SCSI 하드 드라이브, SSD, SAN 스토리지 또는 NAS)에 있는 로컬 파일 시스템을 사용할 수 있습니다. 그러나 장애 조치 기능이 있는 다중 호스트 시스템을 빌드하는 것으로는 충분하지 않습니다. 디스크 펜싱이 가능한 SAP HANA 기능과 함께 선택한 파일 시스템 유형 또는 SAN 인프라에서 다음 사항을 확인해야 합니다.

• 대기 호스트는 실패한 호스트의 데이터 볼륨과 로그 볼륨에 대한 파일 액세스 권한을 갖습니다.

• 장애가 발생한 작업자 호스트는 더 이상 "펜싱"이라는 파일에 대한 쓰기 액세스 권한이 없습니다.

이러한 두 조건을 충족하는 두 가지 근본적으로 다른 저장소 구성이 있습니다. 바로 공유 저장 장치 또는 장애 조치 재할당이 있는 별도의 저장 장치입니다. 공유 저장소를 모든 호스트에서 공유해야 하는 설치 디렉토리 /hana/shared 와 혼동하지 마십시오.

NFS 또는 IBM의 GPFS와 같은 파일 시스템을 사용하여 액세스하는 공유 저장소 하위 시스템을 사용하면 대기 호스트가 시스템의 모든 활성 호스트 파일에 쉽게 액세스할 수 있습니다. 공유 저장 솔루션에서는 외부에 부착된 저장 시스템이 각 호스트의 동적 마운트 포인트가 될 수 있습니다.

공유 저장 하위 시스템이 펜싱(fencing)을 처리하는 방식이 다르기 때문에, 하드웨어 파트너와 저장 파트너는 해당 저장소 하위 시스템에 액세스하는 데 사용되는 파일 시스템에 고유한 손상 없이 장애 조치(failover) 솔루션을 개발할 책임이 있습니다. 하드웨어 파트너가 제공하는 스토리지 커넥터와 함께 NFSv3 스토리지 솔루션을 사용해야 합니다. NFSv4 및 GPFS 스토리지 솔루션은 스토리지 커넥터와 함께 선택적으로 사용할 수 있습니다. 공유 저장소 시스템은 다음 그림과 같이 구성할 수 있습니다. 그러나 마운트는 하드웨어 파트너와 그 구성에 따라 다를 수 있습니다.

공유 영역을 제외하고는 마운트되지 않은 모든 SAP HANA 호스트에 별도의 저장소를 지정할 수도 있습니다. SAN 스토리지는 SAP HANA가 스토리지 기술 공급업체에 제공하는 SAP Fiber Channel Storage Connector와 함께 사용해야 합니다. 장애 조치 중에 SAP HANA는 저장소 커넥터 API를 사용하여 저장 장치 드라이버에게 필요한 데이터 및 로그 볼륨을 대기 호스트에 다시 마운트하도록 지시하고 실패한 호스트로부터 같은 볼륨을 꺼냅니다.

비공유 환경에서는 저장소 커넥터 API와 함께 별도의 저장소가 사용됩니다. 스토리지 커넥터 API에 대한 자세한 내용은 SAP Note 1900823에서 제공되는 SAP Fiber Channel Storage Connector Admin Guide를 참조하십시오.

설치 매체에서 SAP HANA 데이터베이스 수명 주기 관리자(HDBLCM)를 사용하여 설치 중에 SAP HANA 시스템을 다중 호스트 시스템으로 구성할 수 있습니다. 내부 SAP HANA 데이터베이스 수명 주기 관리자를 사용하여 단일 호스트 또는 다중 호스트 SAP HANA 시스템을 설치한 후 호스트를 추가할 수도 있습니다.

SAP HANA 데이터베이스 수명 주기 관리자 그래픽 사용자 인터페이스, 명령어 라인 인터페이스 또는 SAP HANA 데이터베이스 수명 주기 관리자 웹 사용자 인터페이스를 사용하여 하나 이상의 호스트를 기존 SAP HANA 시스템에 추가합니다. 구성 옵션은 호스트가 추가되는 방식에 따라 달라집니다.

첫 번째 고려사항은 로그온한 호스트가 시스템에 통합되는지 여부입니다. 구성된 시스템 호스트에 로그온한 경우 통합 호스트에 있고 비통합 호스트를 시스템에 추가합니다.

단일 호스트 시스템에 호스트를 추가하는 경우 호스트 추가 중에 수신 인터페이스가 글로벌로 자동 구성됩니다. 시스템에 호스트를 추가한 후 내부 네트워크 주소를 정의하고 필요한 경우 서비스 간 통신을 다른 설정으로 재구성할 수 있습니다.

호스트를 SAP HANA 시스템에 추가하려면 다음 선행조건이 충족되어야 합니다.

• SAP HANA 시스템이 공유 파일 시스템에 서버 소프트웨어와 함께 설치되어 있어야 합니다(엑스포트 옵션 rw, no_root_squash).

• 호스트에서 설치 디렉토리 <sapmnt> 및 <sapmnt>/<SID>에 액세스할 수 있습니다.

• SAP HANA 시스템이 SAP HANA 데이터베이스 수명 주기 관리자와 함께 설치되어 있어야 합니다.

• SAP HANA 데이터베이스 서버가 가동 중이어야 합니다.

• 루트 사용자 또는 시스템 관리자 <sid>adm사용자로 로그온했습니다.

• 설치 호스트에 설정된 시스템 시간과 추가 호스트의 차이가 180초를 초과하지 않습니다.

• 운영 체제 관리자(<sid>adm)가 추가 호스트에 존재할 수 있습니다. 기존 <sid>adm 사용자의 비밀번호가 있고 사용자 특성 및 그룹 지정이 올바른지 확인하십시오. SAP HANA 데이터베이스 수명 주기 관리자 상주 프로그램은 기존 사용자나 그룹의 속성을 수정하지 않습니다.

• SAP Note: 1900823 - SAP HANA Storage Connector API

• SAP Note: 405827 - Linux: 권장되는 파일 시스템

• SAP Note: 2453736 - How-To: Configuring SAP HANA for SAP BW Extension Node in SAP HANA 2.0