기업용 분산 DBMS

CAP 정리는 분산 시스템 이론의 초석입니다. 물론 이에 대해서는 많은 논쟁이 있습니다. 정의가 정준적이지 않고, 엄격한 증명도 없습니다. 그럼에도 불구하고, 상식™의 관점을 고수하는 우리는 이 정리가 참임을 직관적으로 이해합니다.

유일하게 명확하지 않은 것은 "P" 문자의 의미입니다. 클러스터가 분할되면 쿼럼에 도달할 때까지 응답하지 않을지, 아니면 가지고 있는 데이터를 제공할지 결정합니다. 이 선택 결과에 따라 시스템은 CP 또는 AP로 분류됩니다. 예를 들어, Cassandra는 클러스터 설정에 따라가 아니라 각 요청의 매개변수에 따라 두 가지 방식으로 동작할 수 있습니다. 하지만 시스템이 "P"가 아닌데 분할된다면 어떻게 될까요?

이 질문에 대한 답은 다소 예상치 못한데, CA 클러스터는 분할될 수 없습니다.
분할될 수 없는 이 클러스터는 무엇입니까?

이러한 클러스터의 필수 속성 중 하나는 공유 데이터 스토리지 시스템입니다. 대다수의 경우 이는 SAN을 통한 연결을 의미하며, 이로 인해 CA 솔루션은 SAN 인프라를 유지 관리할 수 있는 대규모 기업에만 사용이 제한됩니다. 여러 가지 이유로 CA 솔루션은 대규모 기업에만 적합합니다. 서버 동일한 데이터를 사용하려면 클러스터 파일 시스템이 필요합니다. 이러한 파일 시스템은 HPE(CFS), Veritas(VxCFS) 및 IBM(GPFS)의 제품군에서 사용할 수 있습니다.

오라클 RAC

Real Application Cluster 옵션은 2001년 Oracle 9i 출시와 함께 처음 등장했습니다. 이러한 클러스터에서는 여러 인스턴스가 실행될 수 있습니다. 서버 동일한 데이터베이스를 사용합니다.
Oracle은 클러스터 파일 시스템과 자체 솔루션인 ASM(자동 스토리지 관리) 모두와 함께 작동할 수 있습니다.

각 인스턴스는 자체 로그를 유지합니다. 트랜잭션은 한 인스턴스에 의해 실행되고 커밋됩니다. 인스턴스에 장애가 발생하면, 살아남은 클러스터 노드(인스턴스) 중 하나가 해당 로그를 읽고 손실된 데이터를 복원하여 가용성을 보장합니다.

모든 인스턴스는 자체 캐시를 유지하며, 동일한 페이지(블록)가 여러 인스턴스의 캐시에 동시에 존재할 수 있습니다. 또한, 한 인스턴스에서 필요로 하는 페이지가 다른 인스턴스의 캐시에 있는 경우, 디스크에서 읽는 대신 캐시 퓨전 메커니즘을 사용하여 "이웃"에서 해당 페이지를 가져올 수 있습니다.

하지만 인스턴스 중 하나에서 데이터를 변경해야 하는 경우는 어떻게 되나요?

Oracle의 독특한 점은 전용 잠금 서비스가 없다는 것입니다. 서버가 행을 잠그려면 잠금 레코드가 잠긴 행이 있는 메모리 페이지에 직접 배치됩니다. 이러한 접근 방식 덕분에 Oracle은 모놀리식 데이터베이스 중 성능 면에서 최고 수준입니다. 잠금 서비스는 병목 현상을 일으키지 않습니다. 그러나 클러스터 구성에서는 이러한 아키텍처로 인해 네트워크 교환 및 상호 잠금이 집중적으로 발생할 수 있습니다.

레코드가 잠기면 인스턴스는 해당 레코드를 보관하는 페이지가 배타적으로 잠겼음을 다른 모든 인스턴스에게 알립니다. 다른 인스턴스가 같은 페이지의 레코드를 변경해야 하는 경우, 해당 페이지의 변경 사항이 커밋될 때까지, 즉 변경 사항이 디스크의 로그에 기록될 때까지 기다려야 합니다(트랜잭션은 계속 진행될 수 있음). 또한 여러 인스턴스가 연속적으로 페이지를 변경한 후, 해당 페이지가 디스크에 기록될 때 현재 페이지의 버전을 누가 보관하고 있는지 파악해야 하는 경우도 있습니다.

여러 RAC 노드에서 동일한 페이지를 무작위로 업데이트하면 데이터베이스 성능이 크게 저하되어 클러스터 성능이 단일 인스턴스보다 낮아질 수 있습니다.

Oracle RAC의 올바른 사용법은 데이터를 물리적으로 분할하고(예: 분할 테이블 메커니즘 사용) 전용 노드를 통해 각 파티션 세트에 액세스하는 것입니다. RAC의 주요 목적은 수평적 확장이 아닌, 내결함성으로 바뀌었습니다.

노드가 하트비트에 응답하지 않으면, 이를 처음 감지한 노드가 디스크에서 투표 절차를 시작합니다. 누락된 노드도 여기에 체크인하지 않은 경우, 노드 중 하나가 데이터 복원을 담당합니다.

• 누락된 노드의 캐시에 있던 모든 페이지를 "동결"합니다.
• 누락된 노드의 리두 로그를 읽고 이 로그에 기록된 변경 사항을 다시 적용하는 동시에 다른 노드에 수정 중인 페이지의 최신 버전이 있는지 확인합니다.
• 완료되지 않은 거래를 롤백합니다.

노드 간 전환을 간소화하기 위해 Oracle은 서비스, 즉 가상 인스턴스라는 개념을 사용합니다. 인스턴스는 여러 서비스를 제공할 수 있으며, 서비스는 노드 간에 이동할 수 있습니다. 데이터베이스의 특정 부분(예: 클라이언트 그룹)을 제공하는 애플리케이션 인스턴스는 하나의 서비스로 작동하며, 해당 데이터베이스 부분을 담당하는 서비스는 해당 노드에 장애가 발생하면 다른 노드로 이동합니다.

트랜잭션을 위한 IBM Pure Data Systems

DBMS용 클러스터 솔루션은 2009년 Blue Giant 포트폴리오에 처음 등장했습니다. 이념적으로는 "일반" 하드웨어를 기반으로 구축된 Parallel Sysplex 클러스터의 후속 제품입니다. 2009년에는 소프트웨어 제품군인 DB2 pureScale 제품이 출시되었고, 2012년에는 IBM이 Pure Data Systems for Transactions라는 하드웨어 및 소프트웨어 제품군(어플라이언스)을 출시했습니다. 이는 Netezza의 이름을 바꾼 Pure Data Systems for Analytics와 혼동해서는 안 됩니다.

pureScale 아키텍처는 언뜻 보기에 Oracle RAC와 유사합니다. 여러 노드가 공통 데이터 스토리지 시스템에 연결되고 각 노드는 자체 메모리 영역과 트랜잭션 로그를 사용하는 자체 DBMS 인스턴스를 실행합니다. 그러나 Oracle과 달리 DB2는 db2LLM* 프로세스 집합으로 표현되는 전용 잠금 서비스를 제공합니다. 클러스터 구성에서 이 서비스는 Parallel Sysplex에서는 커플링 기능(CF)이라고 하는 별도의 노드로 이동하고, Pure Data에서는 PowerHA라고 합니다.

PowerHA는 다음과 같은 서비스를 제공합니다.

• 블록 관리자;
• 글로벌 버퍼 캐시
• 프로세스 간 통신 영역.

원격 메모리 액세스는 PowerHA에서 DB 노드로 데이터를 전송하는 데 사용되므로 클러스터 상호 연결은 RDMA 프로토콜을 지원해야 합니다. PureScale은 Infiniband와 RDMA over Ethernet을 모두 사용할 수 있습니다.

노드에 페이지가 필요하지만 해당 페이지가 캐시에 없는 경우, 노드는 글로벌 캐시에서 페이지를 요청하고, 캐시에 없는 경우에만 디스크에서 해당 페이지를 읽습니다. Oracle과 달리, 요청은 PowerHA로만 전달되며 인접 노드로는 전달되지 않습니다.

인스턴스가 행을 수정하려는 경우, 해당 행은 배타 모드로 잠그고, 행이 있는 페이지는 공유 모드로 잠급니다. 모든 잠금은 전역 잠금 관리자에 등록됩니다. 트랜잭션이 커밋되면 노드는 잠금 관리자에게 메시지를 전송하고, 잠금 관리자는 수정된 페이지를 전역 캐시에 복사하고 잠금을 해제하며, 다른 노드의 캐시에서 수정된 페이지를 무효화합니다.

수정 중인 행이 포함된 페이지가 이미 잠겨 있는 경우, 잠금 관리자는 수정을 수행한 노드의 메모리에서 수정된 페이지를 읽고, 잠금을 해제하고, 다른 노드의 캐시에서 수정된 페이지를 무효화하고, 페이지 잠금을 요청한 노드로 반환합니다.

"더티" 즉 수정된 페이지는 일반 노드와 PowerHA(캐스트아웃) 모두에서 디스크에 기록될 수 있습니다.

pureScale 노드 중 하나에 장애가 발생하면 복구는 장애 발생 시점에 아직 완료되지 않은 트랜잭션으로만 제한됩니다. 완료된 트랜잭션에서 해당 노드가 수정한 페이지는 PowerHA의 글로벌 캐시에 저장됩니다. 해당 노드는 클러스터 서버 중 하나에서 간소화된 구성으로 재시작되고, 완료되지 않은 트랜잭션을 롤백하고 잠금을 해제합니다.

PowerHA는 두 대의 서버에서 실행되며, 기본 노드는 상태를 동기적으로 복제합니다. 기본 노드에 장애가 발생하더라도 PowerHA 클러스터는 백업 노드와 함께 계속 작동합니다.
물론 단일 노드를 통해 데이터 세트에 액세스하면 클러스터의 전반적인 성능이 향상됩니다. PureScale은 특정 데이터 영역이 단일 노드에 의해 처리되고 있음을 감지할 수 있으며, 해당 영역과 관련된 모든 잠금은 PowerHA와 통신하지 않고 해당 노드에서 로컬로 처리됩니다. 하지만 애플리케이션이 다른 노드를 통해 해당 데이터에 액세스하려고 시도하는 즉시 중앙 집중식 잠금 처리가 재개됩니다.

실제 운영 환경의 워크로드와 매우 유사한 90% 읽기/10% 쓰기 워크로드에 대한 IBM 내부 테스트 결과, 128개 노드까지 거의 선형적인 확장이 가능했습니다. 아쉽게도 테스트 조건은 공개되지 않았습니다.

HPE NonStop SQL

휴렛팩커드 엔터프라이즈(Hewlett-Packard Enterprise)도 자체 고가용성 플랫폼을 보유하고 있습니다. 바로 1976년 탠덤 컴퓨터(Tandem Computers)가 출시한 논스톱(NonStop) 플랫폼입니다. 1997년 컴팩(Compaq)에 인수되었고, 컴팩은 2002년 휴렛팩커드와 합병했습니다.

NonStop은 HLR이나 은행 카드 처리와 같은 중요한 애플리케이션을 구축하는 데 사용됩니다. 이 플랫폼은 컴퓨팅 노드, 데이터 저장 시스템, 통신 장비를 포함하는 하드웨어 및 소프트웨어 복합체(어플라이언스)로 제공됩니다. ServerNet 네트워크(현대 시스템에서는 Infiniband)는 노드 간 데이터 교환과 데이터 저장 시스템 접근을 모두 담당합니다.

시스템의 초기 버전은 서로 동기화되는 독점 프로세서를 사용했습니다. 모든 작업은 여러 프로세서에 의해 동기적으로 수행되었으며, 프로세서 중 하나에 오류가 발생하면 해당 프로세서가 꺼지고 다른 프로세서가 계속 작동했습니다. 이후 시스템은 기존 프로세서(먼저 MIPS, 그다음 Itanium, 마지막으로 x86)로 전환되었고, 동기화를 위해 다른 메커니즘이 사용되기 시작했습니다.

• 메시지: 각 시스템 프로세스에는 "섀도우" 트윈이 있으며, 활성 프로세스는 주기적으로 해당 트윈에 상태에 대한 메시지를 보냅니다. 메인 프로세스가 실패하면 섀도우 프로세스는 마지막 메시지에서 확인한 순간부터 작업을 시작합니다.
• 투표: 저장 시스템에는 여러 개의 동일한 요청을 수락하고 요청이 일치하는 경우에만 요청을 실행하는 특수한 하드웨어 구성 요소가 있습니다. 프로세서는 물리적으로 동기화되는 대신 비동기적으로 작동하고 작업 결과는 I/O 순간에만 비교됩니다.

NonStop 플랫폼은 1987년부터 관계형 DBMS(먼저 SQL/MP, 나중에는 SQL/MX)를 실행해 왔습니다.

전체 데이터베이스는 여러 부분으로 나뉘며, 각 부분은 자체적인 데이터 접근 관리자(DAM) 프로세스를 담당합니다. DAM은 데이터 기록, 캐싱 및 잠금 메커니즘을 제공합니다. 데이터 처리는 해당 데이터 관리자와 동일한 노드에서 실행되는 실행자 프로세스(실행자 서버 프로세스)에 의해 수행됩니다. SQL/MX 스케줄러는 실행자 간에 작업을 나누고 결과를 결합합니다. 일관된 변경 사항을 적용해야 하는 경우, TMF(Transaction Management Facility) 라이브러리에서 제공하는 2단계 커밋 프로토콜을 사용합니다.

NonStop SQL은 긴 분석 쿼리가 트랜잭션 실행을 방해하지 않도록 프로세스의 우선순위를 지정할 수 있습니다. 하지만 NonStop SQL의 목적은 분석이 아닌 짧은 트랜잭션을 처리하는 것입니다. 개발자는 NonStop 클러스터의 가용성을 5%(파이브 나인) 수준으로 보장합니다. 즉, 다운타임이 연간 XNUMX분에 불과합니다.

SAP-HANA

HANA DBMS(1.0)의 첫 번째 안정적인 릴리스는 2010년 2013월에 이루어졌고, SAP ERP 패키지는 XNUMX년 XNUMX월에 HANA로 전환되었습니다. 이 플랫폼은 TREX 검색 엔진(열형 저장소 검색), P*TIME DBMS 및 MAX DB와 같은 구매 기술을 기반으로 합니다.

"HANA"라는 단어 자체는 고성능 분석 어플라이언스(High performance ANalytical Appliance)의 약자입니다. 이 DBMS는 모든 x86 서버에서 실행 가능한 코드 형태로 제공되지만, 산업 시설은 인증된 장비에서만 허용됩니다. HP, 레노버, 시스코, 델, 후지쯔, 히타치, NEC 등의 솔루션이 있습니다. 일부 레노버 구성은 SAN 없이도 작동할 수 있습니다. 일반 스토리지 시스템의 역할은 로컬 디스크의 GPFS 클러스터가 담당합니다.

위에 나열된 플랫폼과 달리 HANA는 메모리 내 DBMS입니다. 즉, 기본 데이터 이미지는 RAM에 저장되고 재해 발생 시 복구를 위해 로그와 주기적 스냅샷만 디스크에 기록됩니다.

각 HANA 클러스터 노드는 자체 데이터 부분을 담당하며, 데이터 맵은 코디네이터 노드에 위치한 특수 구성 요소인 네임 서버에 저장됩니다. 데이터는 노드 간에 중복되지 않습니다. 잠금 관련 정보도 각 노드에 저장되지만, 시스템에는 전역 교착 상태 감지기가 있습니다.

클러스터에 연결할 때 HANA 클라이언트는 토폴로지를 다운로드한 후 필요한 데이터에 따라 모든 노드에 직접 액세스할 수 있습니다. 트랜잭션이 단일 노드의 데이터에 영향을 미치는 경우 해당 노드에서 로컬로 실행할 수 있지만, 여러 노드의 데이터가 변경되는 경우, 개시자 노드는 코디네이터 노드에 접속하여 분산 트랜잭션을 열고 조정한 후 최적화된 2단계 커밋 프로토콜을 사용하여 커밋합니다.

코디네이터 노드는 복제되므로 코디네이터에 장애가 발생하면 백업 노드가 즉시 작업을 수행합니다. 하지만 데이터 노드에 장애가 발생하면 해당 노드의 데이터에 액세스할 수 있는 유일한 방법은 노드를 재시작하는 것입니다. 일반적으로 HANA 클러스터에는 장애가 발생한 노드를 최대한 빨리 재시작할 수 있는 예비 서버가 있습니다.

출처 : habr.com