SAP HANA 고가용성 기능 이해

SAP HANA 데이터베이스 플랫폼은 고가용성과 재해 허용 한도를 염두에 두고 설계되었습니다. SAP HANA는 간단한 소프트웨어 오류나 하드웨어 오류부터 전체 사이트를 탈취하는 재해에 이르기까지 광범위한 복구 시나리오를 지원합니다.

가용성은 일반적으로 1년 동안 측정된 시스템 운영 가동 시간의 백분율로 표시됩니다. 예를 들어, 시스템이 99.99%("네 개의 Nines"라고도 함)를 사용할 수 있도록 설계된 경우 연간 다운타임은 0.01% 또는 52분 56초 미만이어야 합니다.

이는 연간 1시간 미만의 다운타임을 의미합니다. 이는 매우 어려운 대상이 될 수 있습니다. 이러한 도전적인 목표를 달성하기 위해 고가용성 및 재해 허용은 아키텍처 설계, 즉 인프라의 모든 계층에서 구현되어야 합니다.

다운타임은 중단의 결과로서 다운타임이 계획되거나(예: 시스템 업그레이드 또는 하드웨어 대체) 계획되지 않은 다운타임(예: 소프트웨어 또는 하드웨어 장애)으로 인해 발생할 수 있습니다. 계획되지 않은 다운타임은 장비 오작동, 소프트웨어 또는 네트워크 장애, 화재, 지진, 지역 전력 손실 또는 전체 데이터 센터를 해체할 수 있는 건설 사고와 같은 중대한 재해에 의해 트리거될 수 있습니다.

고가용성은 비즈니스 연속성을 위한 기술, 엔지니어링 관행 및 설계 원칙의 집합입니다. 이는 단일 장애 지점(내결함성)을 없애고, 시스템 중단 후 비즈니스 손실(결함 복원력)을 최소화하면서 운영을 신속하게 재개할 수 있는 기능을 제공함으로써 달성됩니다.

과실 복구는 오류로 인한 정전 후 정상 운영을 복구하고 재개하는 과정이다.

재해 복구(Disaster Recovery)는 장기간 데이터 센터 또는 사이트 고장으로 인한 중단 후 작업을 복구하는 프로세스입니다. 재난에 대비하기 위해 멀리 퍼져 있는 데이터를 백업해야 할 수 있기 때문에 복잡하고 비용이 많이 들 수 있습니다.

고객은 일반적으로 중단 후 시스템의 복구 매개변수인 RPO(Recovery Point Objective)와 RTO(Recovery Time Objective)를 지정하는 데 두 가지 주요 지표를 사용합니다. 시스템의 RPO와 RTO가 'RPO 및 RTO' 그림에 나와 있습니다.

• RPO는 복구 기능 없이 운영 데이터가 손실될 수 있는 최대 허용 시간입니다. 마지막 백업(데이터 또는 로그)과 충돌 사이의 시간입니다. 비즈니스 데이터의 손실이 허용되지 않기 때문에 거의 모든 고객이 0의 RPO를 달성하려고 합니다.

• RTO는 일반 작업을 다시 시작할 수 있도록 시스템을 복구하는 데 걸리는 최대 허용 시간입니다. 많은 기업들이 RTO(Near-zero RTO)를 목표로 하고 있는데, 이는 RTO 기간 동안 정상적인 비즈니스가 중단되기 때문이다. 비즈니스가 중단되면 수익 손실이 발생하므로 가급적 피해야 합니다.

내결함성을 달성하는 열쇠는 중복성을 도입하여 단일 실패 지점을 제거하는 것입니다. SAP HANA 하드웨어 공급업체는 컴포넌트 오류로 인한 중단을 방지하기 위해 몇 가지 수준의 중복을 제공합니다.

일반적으로 이러한 기법은 SAP HANA의 작동에 투명합니다. 그럼에도 불구하고, 이들은 피할 수 있는 시스템 중단에 대한 중요한 방어선을 형성하며, 따라서 비즈니스 연속성에 크게 기여한다.

하드웨어 중복

SAP HANA 하드웨어 공급업체는 하드웨어 컴포넌트와 하위 시스템에서 여러 계층의 중복성을 설계합니다. 여기에는 중복 및 핫스왑 가능 전원 공급 장치(PSU), 팬, 네트워크 인터페이스 카드 및 오류 수정 코드 메모리가 포함됩니다.

이러한 하위 시스템은 중복 구성 요소가 다른 구성 요소가 고장날 때에도 시스템의 작동을 유지할 수 있도록 설계되었습니다.

저장 시스템은 특히 중요합니다. 엔터프라이즈급 스토리지 시스템은 여러 물리적 드라이브를 논리 단위로 결합하며, 중복성 및 오류 복구를 위한 표준 RAID(Redundant Array of Independent Disk) 기술이 내장되어 있습니다. 여기에는 미러링(동일한 데이터를 병렬로 두 개의 서로 다른 드라이브에 쓰는 것)과 패리티(오류의 감지 및 자동 수정을 허용하기 위해 여분의 비트의 작성)가 포함됩니다.

네트워크 중복

중복 네트워크, 네트워크 장비 및 네트워크 연결은 시스템 가용성에 영향을 미치는 네트워크 장애를 방지해야 합니다. 이는 일반적으로 루프를 피하기 위해 스패닝 트리 프로토콜(Spanning Tree Protocol, STP)을 사용하여 완전히 중복되는 스위치 토폴로지를 배포함으로써 이루어진다.

자동 장애 조치를 위해 HSRP(Hot Standby Router Protocol)를 사용하여 라우터를 구성할 수 있습니다. BGP(Border Gateway Protocol)는 일반적으로 이중 WAN 연결을 관리하는 데 사용됩니다.

데이터 센터 중복

SAP HANA 솔루션을 호스팅하는 데이터 센터에는 UPS(Untracted Power Supply) 장치 및 백업 발전기, 중복 냉각 시스템, 네트워크 연결 및 전기 다중 공급 공급업체가 장착되어 있습니다. 이는 개별 고장 발생 시 운영 가용성을 달성하고 비즈니스 중단에 영향을 미칠 확률을 크게 줄이기 위한 것입니다. 일부 기업은 완전히 중복된 데이터 센터를 운영하여 높은 수준의 재해 허용 한도를 제공합니다.

인메모리 데이터베이스인 SAP HANA는 장애 발생 시 데이터의 신뢰성을 유지하는 데에만 집중해서는 안 됩니다. 대부분의 데이터가 메모리에 다시 로드되므로 가능한 한 빨리 작업을 재개하는 것도 고려해야 합니다.

그림 ‘SAP HANA RPO 및 RTO 지원’에는 SAP HANA 고가용성 지원의 단계가 나와 있습니다.

준비 단계

이 첫 번째 단계는 재난에 대비한다는 것을 의미합니다. 이 시간 동안 데이터베이스는 정기적으로 백업됩니다(데이터 및 로그 백업). 로컬 또는 원격 대기 시스템이 작동 중이어서 인계할 준비가 되었습니다.

모든 항목이 정의된 매개변수 내에서 작동하기 때문에 이 단계는 일반적으로 허가된 것으로 간주됩니다. 이 완화된 태도로 인해 일부 점검 절차를 건너뛸 수 있습니다. 이것은 일어나기를 기다리는 재앙이다. 점검이 있는지 확인합니다.

감지 단계

인계를 시작하려면 먼저 오류를 감지해야 합니다. 이 오류 감지는 자동 또는 수동으로 수행할 수 있습니다. 두 경우 모두 잘못된 긍정(positive)을 피해야 하므로 실패를 재검사해야 한다.

감지 단계를 가능한 한 짧게 유지하여 시스템이 중단되는 동안 수익 손실을 방지하십시오.

단계 복구

실제 실패가 발견되면 인계가 트리거됩니다. 오류에 따라 다른 복구 프로세스가 트리거될 수 있습니다. 복구 프로세스마다 복구 런타임이 다릅니다. 런타임은 사용 가능한 하드웨어 리소스에도 크게 종속됩니다.

램프업 단계

복구가 완료되면 시스템이 램프업 상태로 제공됩니다. 이는 일부 데이터가 메모리에 아직 로드되지 않고 외부 인터페이스가 여전히 초기화될 수 있기 때문입니다.

이 단계를 최적화하기 위해 이 데이터를 먼저 로드하기 위해 가장 필요한 데이터를 조사할 수 있습니다.

장애 조치 단계

다른 단계가 모두 완료되면 오류를 수리해야 합니다. 이는 하드웨어 수리 또는 소프트웨어 업데이트일 수 있습니다. 둘 다 시간이 걸리고 운영 시스템에 적용하기 전에 추가 테스트가 필요할 수 있습니다.

이러한 수리가 완료되면 시스템에서 원래 데이터 센터와 하드웨어로 다시 페백해야 할 수 있습니다. 즉시 트리거하거나 다음 데이터 센터 유지보수 기간에 트리거할 수 있습니다. 이 장애 조치가 고객에게 해당되는 경우, 이는 서드 파티 공급업체와의 계약 및 서비스 레벨 계약에 따라 달라지며 추가 비용이 발생할 수 있기 때문입니다.

다른 RPO 및 RTO 값은 다른 종류의 결함과 연관될 수 있습니다. 비즈니스 크리티컬 시스템은 로컬 결함의 경우 데이터 손실이 0인 RPO와 함께 작동할 것으로 예상되며 종종 재해의 경우에도 마찬가지입니다.

재해 복구 과제는 총 재해에 비해 로컬로 복구 가능한 오류에 대해 다릅니다. 총 재해에서 RPO가 0개이고 RTO가 낮으면 데이터가 장기간에 걸쳐 동기적으로 복제되어야 하며, 이로 인해 정기적인 시스템 성능이 저하되고 더 비싼 대기 및 장애 조치 솔루션이 필요할 수 있습니다.

이 모든 것은 결함 복구 기능, 비용 및 복잡성의 특성에 대한 절충안을 결정합니다. SAP는 3단계의 재해 복구 지원과 세 가지 수준의 자동 오류 복구 지원을 포함한 보완적인 설계 옵션을 제공합니다. 이러한 기능이 'SAP HANA 복구 기능' 그림에 요약되어 있습니다. 오류 복구 및 재해 복구에 대한 자세한 내용은 이 과정의 다음 단원에서 확인할 수 있습니다.

하드웨어 및 소프트웨어 오류와 같은 로컬 오류를 동일한 데이터 센터 및 하드웨어에서 처리할 수 있습니다. 오류를 복구할 수 있는 해결 방법은 동일한 서버에서 실패한 서비스를 다시 시작하거나 동일한 데이터 센터에서 새 호스트로 전환하는 것입니다. 이러한 솔루션은 종종 하드웨어 공급업체가 제공하는 소프트웨어 및 하드웨어 솔루션의 기본 부분이므로 추가 비용 없이 구현할 수 있습니다.

서비스 자동 재시작

구성된 SAP HANA 서비스(인덱스 서버, 이름 서버 등) 중 하나에 소프트웨어 오류가 발생하면 실패한 서비스가 SAP HANA 서비스 자동 재시작 watchdog 함수에 의해 재시작됩니다.

이 워치독 기능은 SAP HANA 데몬 프로세스에서 제공되며, 이 기능을 통해 오류가 자동으로 감지되고 중지된 서비스 프로세스가 다시 시작됩니다. 서비스를 다시 시작하면 데이터가 메모리에 로드되고 기능이 다시 시작됩니다. 모든 데이터가 안전하지만 서비스 복구에는 시간이 걸립니다.

SAP HANA 자동 재시작

SAP HANA 데이터베이스 시스템은 자동 재시작 모드에서 구성할 수 있습니다. 이는 정전 후에 유용할 수 있습니다. 전원이 돌아가고 Linux 운영 체제가 성공적으로 시작되면 SAP HANA 데이터베이스 시스템에서 자동으로 시작 및 복구를 수행합니다. SAP HANA 데이터베이스 시스템은 시작 및 복구가 완료되는 즉시 정상 작동에 다시 사용할 수 있습니다.

호스트 자동 장애 조치

이는 시스템 복제 외에 사용하거나 시스템 복제에 대한 대체 수단으로 사용할 수 있는 로컬 오류 복구 솔루션입니다. 하나 이상의 호스트가 SAP HANA 데이터베이스 시스템에 추가됩니다. 이러한 추가 호스트는 대기 모드에서 작동하도록 구성됩니다.

대기 호스트가 대기 모드에 있는 한, 그 호스트의 데이터베이스는 어떤 데이터도 포함하지 않으며 요청이나 쿼리도 받지 않습니다. 즉, 이러한 추가 대기 호스트는 품질 또는 테스트 시스템 등의 다른 용도로 사용할 수 없습니다.

재해는 자연과 인간으로 나눌 수 있다. 자연 재해는 지진, 화산, 허리케인, 홍수 및 화재입니다. 데이터 파일이나 테이블 데이터의 우발적 삭제, 논리적 사용자 오류, 정전 또는 기본 데이터 센터의 인터넷 연결 손실과 같은 수동 재난.

이러한 사람이 만든 재해의 복구는 더 복잡하고 시간이 많이 걸립니다. 여전히 온전한 보조 데이터 센터로의 전환은 비즈니스 연속성을 최대한 빠르게 복원하기 위한 가장 빠른 솔루션입니다.

백업

SAP HANA는 인메모리 데이터베이스이지만 모든 데이터가 디스크에도 보관됩니다. 데이터는 일반 저장점을 통해 디스크에 저장됩니다. 이러한 저장점은 기본적으로 5분마다 수행됩니다. 이러한 저장점 사이에는 모든 변경사항이 트랜잭션 재실행 로그에 기록됩니다.

SAP HANA가 하드웨어 오류에서 복구될 수 있도록, 정기적인 데이터 백업과 로그 백업을 수행해야 합니다. 이러한 데이터 및 로그 백업은 시스템이 총 재해에서 복구될 수 있도록 보조 사이트로 전송되어야 합니다.

저장소 복제

모든 지속 데이터와 로그 정보를 보조 사이트에 지속적으로 복제하는 메소드입니다. 여러 SAP HANA 하드웨어 파트너들이 저장소 레벨의 복제 솔루션을 제공하는데, 이 복제 솔루션은 볼륨 또는 파일 시스템의 백업을 네트워크로 연결된 원격 스토리지 시스템에 제공합니다.

시스템 복제

이는 보조 사이트에 연속적으로 복제된 SAP HANA 시스템을 제공하는 네이티브 SAP HANA 고가용성 솔루션입니다. 데이터가 메모리에 이미 로드되어 있으므로 백업 및 저장소 복제 솔루션에 비해 인수 시간이 짧습니다.

시스템 복제 활성/활성

보조 시스템에서 데이터를 읽을 수 있는 두 번째 네이티브 SAP HANA 시스템 복제 솔루션입니다. 이 설정에서는 보조 시스템을 사용하여 기본 시스템을 중단하지 않고도 보고서 작성 작업 부하를 처리할 수 있습니다.

데이터 미리 로드 없이 시스템 복제

이는 세 번째 네이티브 SAP HANA 시나리오입니다. 이 솔루션에서는 보조 시스템에서 데이터를 미리 로드하지 않으므로 메모리가 거의 사용되지 않습니다. 따라서 보조 시스템의 호스트가 이중 용도로 사용할 수 있습니다. 예를 들어 개발, 단위 테스트 또는 별도의 저장소가 있는 QA가 있습니다. 인계 전에 이러한 액티비티는 당연히 해제되어야 합니다. 이 시나리오의 트레이드오프(trade-off)는 장애 조치(failover)의 경우 더 긴 RTO입니다.