비즈니스 예시
SAP HANA 데이터베이스 관리자로서 회사의 고가용성 스케일 아웃(scale-out) SAP HANA 시스템을 설치하고 관리해야 합니다. SAP HANA 스케일 아웃(scale-out) 기술의 기본 개념을 이해해야 합니다.
SAP HANA 확장
데이터 스케일링
데이터 증가 계획을 해결할 수 있는 한 가지 기술적 방법은 물리적 RAM을 처음에 필요한 것보다 더 많이 구입하고 필요에 맞게 할당 한도를 설정한 후 시간이 지남에 따라 데이터에 맞춰 한도를 늘리는 것입니다. 단일 서버의 물리적 한도에 도달하면 여러 컴퓨터를 통해 스케일 아웃해서 하나의 분산 SAP HANA 시스템을 구축할 수 있습니다. 이렇게 하려면 여러 스키마 및 테이블을 다른 서버에 분배할 수 있습니다(전체 데이터 및 사용자 분리). 하지만 이 방법이 항상 가능하지는 않습니다. 예를 들면 단일 팩트 테이블이 서버의 RAM 크기보다 크면 가능하지 않습니다.
데이터 확장에 가장 중요한 전략은 데이터 분할입니다. 분할하면 테이블이 서로 다른 시스템에 배치할 수 있는 작은 청크로 나눠지기 때문에 아주 큰 테이블을 만들 수 있습니다. 분할은 대부분의 SQL 쿼리와 다른 데이터 조작에 투명하게 진행됩니다.
스케일링 성능
SAP HANA의 성능은 효율적인 병렬 접근법에서 파생됩니다. 계산 시 SAP HANA 서버의 코어가 많을수록 전체 시스템 성능이 향상됩니다.
성능 확장을 위해서는 작업 부하와 성능 기대치를 더 자세히 이해해야 합니다. 일반적인 쿼리 작업 부하의 시뮬레이션과 추정치를 사용하여 일반적인 SAP HANA 설치에서 편안하게 관리할 수 있는 예상 부하를 확인할 수 있습니다. 작업 부하 레벨에서는 작업 부하가 실행되는 동안 평균 CPU 사용률을 측정하여 확장성에 대한 대략적인 예측을 설정할 수 있습니다. 예를 들어 평균 CPU 사용률이 45%이면 개별 쿼리 응답 시간이 크게 단축되기 전에 시스템을 2X로 로드할 수 있음을 나타낼 수 있습니다.
응용 프로그램 배율
분할은 계산을 여러 호스트에 분산하여 증가하는 동시 세션 및 복합 분석 쿼리를 지원하므로 어플리케이션을 확장하는 데 사용할 수 있습니다. 특히 대부분의 쿼리가 분할 프루닝 규칙과 일치하도록 데이터를 배포하는 데 주의를 기울여야 합니다. 이를 통해 서로 다른 사용자를 서로 다른 호스트(부하 분산)로 안내하고 호스트의 잦은 데이터 조인과 관련된 네트워크 오버헤드를 방지하는 두 가지 목표를 달성할 수 있습니다.
스케일링 하드웨어
SAP HANA는 여러 가지 방식으로 제공되는데, 이는 온프레미스 어플라이언스의 형태로, 인증된 하드웨어 파트너가 제공하는 다양한 구성과 "크기"로 제공되거나 맞춤형 데이터 센터 통합 모델을 사용하여 클라우드 기반 서비스의 일부로 제공됩니다. 이 때문에 스케일 업/스케일 아웃 변형과 관련한 시스템 설계 옵션이 다릅니다. 성능과 처리량을 극대화하려면, 스케일 아웃(데이터 볼륨 요구사항이 훨씬 더 늘어난 배포를 대상으로 함)하기 전에 가능한 한 스케일 업(어플리케이션 작업 부하에 사양이 가장 좋은 프로세서와 메모리를 사용하는 구성 확보)하는 것이 좋습니다.
노트
SAP HANA 시스템의 고가용성 소개
'스케일 업 vs 스케일 아웃' 그림에서는 SAP HANA 시스템의 크기가 1TB에서 12TB로만 늘어났습니다. 스케일 업(scale-up)과 스케일 아웃(scale-out)과 같은 두 가지 시나리오에서는 고가용성이 도입되지 않습니다. 대기 노드가 포함된 확장 설정에서만 고가용성을 도입할 수 있습니다. 고가용성을 지원하는 스케일 아웃 구성이 그림 고가용성 및 스케일 아웃에 나와 있습니다. 하나 이상의 SAP HANA 노드를 대기 노드로 구성할 수 있습니다. 대기 노드는 SAP HANA의 호스트 자동 장애 조치 기능을 사용하여 실패한 호스트의 작업을 자동으로 인계합니다.
SAP HANA 확장 구성에 대기 노드를 도입하는 즉시 오류 발생 시 리소스를 예약합니다. 활성 시스템에서는 이러한 리소스를 사용할 수 없습니다. 고가용성 및 스케일 아웃 그림에는 하나의 호스트가 대기 노드로 정의되어 있습니다. 즉, 현재 시스템에 11개의 노드 활성 노드만 있고 총 데이터베이스 크기가 12TB에서 11TB로 감소했습니다.
스케일 업(scale-up) 구성은 기본적으로 고가용성 기능이 없습니다. 이는 스케일 업(scale-up) 시스템이 하나의 서버로 구성되어 있기 때문입니다. 스케일 업(scale-up) 시스템은 SAP HANA 시스템에 대기 호스트를 추가하거나 저장소 복제나 시스템 복제를 사용하여 구성을 설정하여 고가용성을 달성할 수 있습니다.
다중 호스트(분산) 시스템
SAP HANA 시스템은 여러 개의 분리된 데이터베이스로 구성될 수 있으며 여러 호스트의 클러스터로 구성될 수 있습니다. 이를 다중 호스트, 분산 시스템 또는 스케일 아웃 시스템이라고 하며 확장성과 가용성을 지원합니다.
SAP HANA 시스템은 단일 시스템 ID(SID)로 식별되며 하나 이상의 테넌트 데이터베이스와 하나의 시스템 데이터베이스를 포함합니다. 데이터베이스는 SID와 데이터베이스 이름으로 식별됩니다. 관리 관점에서는 시스템 레벨에서 수행되는 태스크와 데이터베이스 레벨에서 수행되는 태스크가 구분됩니다. SAP HANA 콕피트 등의 데이터베이스 클라이언트는 특정 데이터베이스에 연결됩니다.
호스트는 SAP HANA 시스템의 일부를 실행하는 컴퓨터입니다. 이 기계는 CPU, 메모리, 스토리지, 네트워크 및 운영 체제로 구성됩니다.
SAP HANA 인스턴스란 호스트에 설치된 분산 시스템 컴포넌트의 집합을 의미합니다. 그림 고가용성 확장 시스템 에는 4개의 호스트에서 실행되는 분산 시스템이 나와 있습니다. 이 예에서 각 인스턴스에는 인덱스 서버와 이름 서버가 있습니다.
대기 모드에서 작동하도록 하나 이상의 호스트를 구성하여 활성 호스트가 실패하면 대기 호스트가 자동으로 실행되도록 할 수 있습니다. 대기 호스트의 인덱스 서버는 데이터를 포함하지 않으며 요청을 수신하지 않습니다.
인덱스 서버에는 데이터베이스와 처리 컴포넌트가 모두 들어 있습니다. 각 인덱스 서버는 별도의 운영 체제 프로세스이며 자체 디스크 볼륨도 가지고 있다. 데이터베이스 작업을 처리할 때 인덱스 서버는 일부 작업의 실행을 작업과 관련된 데이터를 소유한 다른 서버로 전달해야 할 수 있습니다.
각 SAP HANA 시스템에는 하나의 기본 인덱스 서버가 있습니다. 메타 데이터를 저장하고, 여러 인덱스 서버와 관련된 분산 트랜잭션을 조정하는 트랜잭션 관리자를 포함합니다.
데이터베이스 클라이언트는 모든 인덱스 서버로 요청을 보낼 수 있습니다. 연결된 인덱스 서버가 관련된 모든 데이터를 소유하지 않으면 일부 작업의 실행을 다른 인덱스 서버에 위임하고 결과를 수집하여 데이터베이스 클라이언트에 반환합니다.
분산 시스템에는 토폴로지를 인식하고 데이터 분산 방식을 아는 중앙 컴포넌트가 필요합니다. 이 컴포넌트가 이름 서버입니다. 이름 서버는 어떤 테이블이나 테이블 복제가 혹은 테이블의 파티션이 어떤 인덱스 서버에 있는지 압니다.
인덱스 서버가 쿼리를 실행할 때 관련 데이터의 위치를 이름 서버에 묻습니다. 성능에 부정적인 영향을 주지 않도록 토폴로지와 분산 정보는 복제되어 각 호스트 캐시됩니다. 각 SAP HANA 시스템에는 토폴로지 및 분산 데이터를 소유한 하나의 기본 이름 서버가 있습니다. 이 데이터는 보조 이름 서버라고 하는 다른 모든 이름 서버에 복제됩니다. 보조 이름 서버는 동일한 인스턴스의 인덱스 서버가 이 데이터를 읽을 수 있는 공유 메모리의 캐시에 복제된 데이터를 작성합니다.
기본 이름 서버에는 이름 서버 데이터(토폴로지 및 분배 데이터)가 저장되는 자체 지속성이 있습니다. 보조 이름 서버는 복제된 데이터만 보유하고 있으므로 지속성이 없습니다.