1.3. scale-Out 스토리지 구성
스케일 아웃 스토리지 구성을 사용하면 SAP HANA를 스케일 아웃 환경에서 유연하게 사용할 수 있으며 오류가 발생할 경우 노드의 기능을 동적으로 이동할 수 있습니다. 모든 노드에서 데이터를 사용할 수 있으므로 SAP 인스턴스는 실패한 구성 요소 프로세스를 인수할 수 있어야 합니다.
SAP HANA 스케일 아웃 환경에는 두 가지 다른 공유 스토리지 시나리오가 있습니다.
- 첫 번째 시나리오는 NFS 또는 IBM의 GPFS를 통해 모든 디렉토리의 파일 시스템을 제공하는 공유 파일 시스템입니다. 이 시나리오에서는 모든 노드에서 항상 데이터를 사용할 수 있습니다.
- 두 번째 시나리오는 비공유 스토리지이며, 필요한 경우 필요한 데이터를 독점적으로 통합하는 데 사용됩니다. 모든 데이터는 SAP HANA 스토리지 커넥터 API를 통해 관리되며 적절한 메커니즘(예: SCSI 3 예약)을 사용하여 노드에서 액세스를 제거합니다.
두 경우 모두 /hana/shared 디렉토리가 공유 파일 시스템으로 사용 가능한지 확인합니다. 이 디렉터리는 시나리오와 독립적으로 사용 가능하고 공유되어야 합니다.
이러한 공유 파일 시스템을 모니터링하려면 선택적으로 파일 시스템 리소스를 생성할 수 있습니다. /etc/fstab 의 항목을 제거해야 합니다. 마운트는 파일 시스템 리소스에서만 관리합니다.
1.3.2. 비공유 스토리지 링크 복사링크가 클립보드에 복사되었습니다!
비공유 스토리지 구성은 공유 스토리지 구성보다 더 복잡합니다. SAP HANA 설치 프로세스에서 지원되는 스토리지 구성 요소와 스토리지 커넥터의 개별 구성이 필요합니다. SAP HANA 데이터베이스는 여러 내부 변경(예: sudo 액세스, lvm 또는 다중 경로)으로 RHEL 시스템을 재구성합니다. 노드 정의가 변경될 때마다 SAP HANA는 SCSI3 예약을 통해 스토리지에 직접 액세스할 수 있습니다. 비공유 스토리지 구성은 스토리지 시스템에 직접 액세스할 수 있으므로 공유 스토리지 구성보다 최적화됩니다.
그림 4: 스토리지 커넥터와 함께 스케일 아웃 프로세스의 기능 및 작업 경로
