열악한 기업 환경에 "무료" PostgreSQL을 적용하는 방법

많은 사람들이 PostgreSQL DBMS에 익숙하며 소규모 설치를 통해 그 성능이 입증되었습니다. 그러나 대기업 및 엔터프라이즈 요구 사항에 있어서도 오픈 소스를 향한 추세는 점점 더 명확해지고 있습니다. 이 기사에서는 Postgres를 기업 환경에 통합하는 방법을 설명하고 Commvault 백업 시스템을 예로 사용하여 이 데이터베이스에 대한 백업 시스템(BSS)을 생성한 경험을 공유합니다.

PostgreSQL은 이미 그 가치가 입증되었습니다. DBMS는 훌륭하게 작동하고 Alibaba 및 TripAdvisor와 같은 최신 디지털 비즈니스에서 사용되며 라이센스 비용이 부족하여 MS SQL 또는 Oracle DB와 같은 괴물에 대한 매력적인 대안이 됩니다. 그러나 엔터프라이즈 환경에서 PostgreSQL에 대해 생각하기 시작하자마자 우리는 즉시 엄격한 요구 사항에 직면하게 됩니다. “구성 내결함성은 어떻습니까? 재해 저항? 종합 모니터링은 어디에 있나요? 자동 백업은 어떻습니까? 테이프 라이브러리를 직접 사용하거나 보조 스토리지에서 사용하는 것은 어떻습니까?”


한편, PostgreSQL에는 Oracle DB의 RMAN 또는 SAP 데이터베이스 백업과 같은 "성인" DBMS와 같은 내장 백업 도구가 없습니다. 반면, 기업 백업 시스템 공급업체(Veeam, Veritas, Commvault)는 PostgreSQL을 지원하지만 실제로는 특정(보통 독립 실행형) 구성과 다양한 제한 사항을 적용해서만 작업합니다.

Barman, Wal-g, pg_probackup과 같이 PostgreSQL용으로 특별히 설계된 백업 시스템은 PostgreSQL DBMS의 소규모 설치 또는 IT 환경의 다른 요소에 대한 대량 백업이 필요하지 않은 경우 매우 널리 사용됩니다. 예를 들어, 인프라에는 PostgreSQL 외에도 물리적 및 가상 서버, OpenShift, Oracle, MariaDB, Cassandra 등이 포함될 수 있습니다. 이 모든 것을 공통 도구로 백업하는 것이 좋습니다. PostgreSQL 전용 솔루션을 별도로 설치하는 것은 좋지 않은 생각입니다. 데이터가 디스크 어딘가에 복사된 다음 테이프로 제거해야 합니다. 이러한 이중 백업은 백업 시간을 늘리고, 더욱 중요하게는 복구 시간도 늘립니다.

엔터프라이즈 솔루션에서는 설치 백업이 전용 클러스터의 특정 수의 노드에서 발생합니다. 예를 들어 동시에 Commvault는 기본 및 보조가 특정 노드에 엄격하게 할당되는 XNUMX노드 클러스터에서만 작동할 수 있습니다. 보조 백업에는 제한이 있으므로 기본 백업에서만 백업하는 것이 좋습니다. DBMS의 특성상 Secondary에는 덤프가 생성되지 않아 파일 백업의 가능성만 남게 된다.

가동 중지 시간의 위험을 줄이기 위해 내결함성 시스템을 생성할 때 "라이브" 클러스터 구성이 생성되고 기본은 서로 다른 서버 간에 점진적으로 마이그레이션될 수 있습니다. 예를 들어 Patroni 소프트웨어 자체는 무작위로 선택된 클러스터 노드에서 기본을 시작합니다. IBS는 이를 기본적으로 추적할 방법이 없으며 구성이 변경되면 프로세스가 중단됩니다. 즉, 외부 제어를 도입하면 제어 서버가 어디에서 어떤 데이터를 복사해야 하는지 이해하지 못하기 때문에 ISR이 효과적으로 작동하지 못하게 됩니다.

또 다른 문제는 Postgres에서 백업을 구현하는 것입니다. 덤프를 통해 가능하며 소규모 데이터베이스에서 작동합니다. 그러나 대규모 데이터베이스에서는 덤프하는 데 시간이 오래 걸리고 많은 리소스가 필요하며 데이터베이스 인스턴스 오류로 이어질 수 있습니다.

파일 백업은 상황을 수정하지만 대규모 데이터베이스에서는 단일 스레드 모드에서 작동하기 때문에 속도가 느립니다. 또한 공급업체에는 여러 가지 추가 제한 사항이 있습니다. 파일 백업과 덤프 백업을 동시에 사용할 수 없거나 중복 제거가 지원되지 않습니다. 많은 문제가 있으며 대부분 Postgres 대신 비싸지만 검증된 DBMS를 선택하는 것이 더 쉽습니다.

후퇴할 곳이 없습니다! 모스크바 개발자가 뒤쳐졌습니다!

그러나 최근 우리 팀은 어려운 과제에 직면했습니다. IT 인프라를 구축한 AIS OSAGO 2.0 생성 프로젝트에서 개발자들은 새로운 시스템으로 PostgreSQL을 선택했습니다.

대규모 소프트웨어 개발자가 "트렌디한" 오픈 소스 솔루션을 사용하는 것이 훨씬 쉽습니다. 페이스북은 이 DBMS의 운영을 지원할 만큼 충분한 전문가를 보유하고 있습니다. 그리고 RSA의 경우 "둘째 날"의 모든 작업이 우리 어깨에 떨어졌습니다. 우리는 내결함성을 보장하고 클러스터를 조립하고 백업을 설정해야 했습니다. 행동 논리는 다음과 같습니다.

• 클러스터의 기본 노드에서 백업을 생성하도록 SRK를 교육합니다. 이를 위해서는 SRK가 이를 찾아야 합니다. 이는 하나 또는 다른 PostgreSQL 클러스터 관리 솔루션과의 통합이 필요함을 의미합니다. RSA의 경우 이를 위해 Patroni 소프트웨어가 사용되었습니다.
• 데이터 볼륨 및 복구 요구 사항에 따라 백업 유형을 결정합니다. 예를 들어, 페이지를 세부적으로 복원해야 하는 경우 덤프를 사용하고, 데이터베이스가 크고 세부적인 복원이 필요하지 않은 경우 파일 수준에서 작업하세요.
• 멀티스레드 모드에서 백업 복사본을 생성하려면 솔루션에 블록 백업 가능성을 추가하세요.

동시에 우리는 처음에는 추가 구성 요소를 엄청나게 많이 사용하지 않고 효과적이고 간단한 시스템을 만들기 시작했습니다. 목발 수가 적을수록 직원의 작업량이 줄어들고 IBS 실패 위험이 낮아집니다. 우리는 Veeam과 RMAN을 사용한 접근 방식을 즉시 제외했습니다. 왜냐하면 두 가지 솔루션 세트가 이미 시스템의 불안정성을 암시하고 있기 때문입니다.

기업을 위한 작은 마법

따라서 우리는 백업 데이터 센터에 미러링된 동일한 인프라를 사용하여 각각 10개의 노드로 구성된 3개의 클러스터에 대한 안정적인 백업을 보장해야 했습니다. PostgreSQL 측면에서 데이터 센터는 활성-수동 원칙에 따라 작동합니다. 총 데이터베이스 크기는 50TB였습니다. 모든 기업 수준의 제어 시스템은 이에 쉽게 대처할 수 있습니다. 그러나 주의할 점은 처음에는 Postgres가 백업 시스템과의 완전하고 심층적인 호환성에 대한 단서를 가지고 있지 않다는 것입니다. 따라서 초기에는 PostgreSQL과 연계하여 최대한의 기능을 갖춘 솔루션을 찾고 시스템을 개선해야 했습니다.

우리는 3번의 내부 "해커톤"을 개최했습니다. 우리는 XNUMX개 이상의 개발을 살펴보고, 테스트하고, 가설과 관련하여 변경하고, 다시 테스트했습니다. 사용 가능한 옵션을 검토한 후 Commvault를 선택했습니다. 기본적으로 이 제품은 가장 간단한 PostgreSQL 클러스터 설치와 함께 작동할 수 있으며 개방형 아키텍처는 성공적인 개발 및 통합에 대한 희망을 불러일으켰습니다. Commvault는 PostgreSQL 로그도 백업할 수 있습니다. 예를 들어 PostgreSQL 측면에서 Veritas NetBackup은 전체 백업만 수행할 수 있습니다.

건축에 대해 자세히 알아보세요. Commvault 관리 서버는 CommServ HA 구성의 두 데이터 센터 각각에 설치되었습니다. 시스템은 미러링되고 하나의 콘솔을 통해 관리되며 HA 관점에서 볼 때 모든 기업 요구 사항을 충족합니다.

또한 각 데이터 센터에 XNUMX개의 물리적 미디어 서버를 출시했으며, 여기에 파이버 채널을 통해 SAN을 통한 백업 전용 디스크 어레이와 테이프 라이브러리를 연결했습니다. 확장된 중복 제거 데이터베이스는 미디어 서버의 내결함성을 보장하고 각 서버를 각 CSV에 연결하여 구성 요소에 장애가 발생하더라도 지속적인 작동을 가능하게 했습니다. 시스템 아키텍처를 통해 데이터 센터 중 하나가 중단되더라도 백업을 계속할 수 있습니다.

Patroni는 각 클러스터의 기본 노드를 정의합니다. 데이터 센터의 모든 무료 노드가 될 수 있지만 대부분 그렇습니다. 백업에서 모든 노드는 보조 노드입니다.

Commvault는 어떤 클러스터 노드가 기본 노드인지 파악하기 위해 솔루션의 개방형 아키텍처 덕분에 시스템을 Postgres와 통합했습니다. 이를 위해 기본 노드의 현재 위치를 Commvault 관리 서버에 보고하는 스크립트가 생성되었습니다.

일반적으로 프로세스는 다음과 같습니다.

Patroni는 기본을 선택하고 → Keepalived는 IP 클러스터를 선택하고 스크립트를 실행합니다. → 선택한 클러스터 노드의 Commvault 에이전트는 이것이 기본이라는 알림을 받습니다. → Commvault는 유사 클라이언트 내에서 백업을 자동으로 재구성합니다.

이 접근 방식의 장점은 솔루션이 로그의 일관성, 정확성 또는 Postgres 인스턴스 복구에 영향을 미치지 않는다는 것입니다. 또한 더 이상 Commvault 기본 및 보조 노드를 수정할 필요가 없기 때문에 쉽게 확장할 수 있습니다. 시스템이 기본 위치를 이해하는 것만으로도 충분하며 노드 수를 거의 모든 값으로 늘릴 수 있습니다.

솔루션은 이상적인 척하지 않으며 고유한 뉘앙스가 있습니다. Commvault는 개별 데이터베이스가 아닌 전체 인스턴스만 백업할 수 있습니다. 따라서 각 데이터베이스에 대해 별도의 인스턴스가 생성되었습니다. 실제 클라이언트는 가상 의사 클라이언트로 결합됩니다. 각 Commvault 의사 클라이언트는 UNIX 클러스터입니다. Postgres용 Commvault 에이전트가 설치된 클러스터 노드가 여기에 추가됩니다. 결과적으로 의사 클라이언트의 모든 가상 노드가 하나의 인스턴스로 백업됩니다.

각 의사 클라이언트 내에는 클러스터의 활성 노드가 표시됩니다. 이것이 Commvault용 통합 솔루션이 정의하는 것입니다. 작동 원리는 매우 간단합니다. 노드에서 클러스터 IP가 발생하면 스크립트는 Commvault 에이전트 바이너리에 "활성 노드" 매개변수를 설정합니다. 실제로 스크립트는 메모리의 필수 부분에 "1"을 설정합니다. . 에이전트는 이 데이터를 CommServe로 전송하고 Commvault는 원하는 노드에서 백업을 만듭니다. 또한 구성의 정확성을 스크립트 수준에서 확인하여 백업 시작 시 오류를 방지하는 데 도움이 됩니다.

동시에 대규모 데이터베이스는 여러 스레드에 걸쳐 블록으로 백업되어 RPO 및 백업 창 요구 사항을 충족합니다. 시스템의 로드는 미미합니다. 전체 복사가 자주 발생하지 않으며, 다른 날에는 로그만 수집되고 로드가 낮은 기간에는 발생합니다.

그건 그렇고, 우리는 PostgreSQL 아카이브 로그 백업을 위해 별도의 정책을 적용했습니다. 이는 다른 규칙에 따라 저장되고 다른 일정에 따라 복사되며 이러한 로그에는 고유한 데이터가 포함되어 있으므로 중복 제거가 활성화되지 않습니다.

전체 IT 인프라의 일관성을 보장하기 위해 별도의 Commvault 파일 클라이언트가 각 클러스터 노드에 설치됩니다. 백업에서 Postgres 파일을 제외하며 OS 및 애플리케이션 백업에만 사용됩니다. 이 부분의 데이터에도 자체 정책과 보관 기간이 있습니다.

현재 IBS는 생산성 서비스에 영향을 미치지 않지만, 상황이 바뀌면 Commvault에서 부하 제한을 활성화할 수 있습니다.

좋은가요? 좋은!

따라서 우리는 실행 가능한 백업뿐만 아니라 PostgreSQL 클러스터 설치를 위한 완전히 자동화된 백업도 받았으며 이는 기업 호출에 대한 모든 요구 사항을 충족합니다.

1시간과 2시간의 RPO 및 RTO 매개변수에는 여유가 적용됩니다. 이는 저장된 데이터의 양이 크게 증가하더라도 시스템이 이를 준수함을 의미합니다. 많은 의심과는 달리 PostgreSQL과 엔터프라이즈 환경은 상당히 호환되는 것으로 나타났습니다. 이제 우리는 이러한 DBMS에 대한 백업이 다양한 구성에서 가능하다는 것을 경험을 통해 알고 있습니다.

물론 이 길을 따라 우리는 일곱 켤레의 쇠장화를 닳게 해야 했고, 수많은 난관을 극복하고, 여러 갈퀴를 밟고, 수많은 실수를 바로잡아야 했습니다. 그러나 이제 이 접근 방식은 이미 테스트되었으며 열악한 기업 환경에서 독점 DBMS 대신 오픈 소스를 구현하는 데 사용할 수 있습니다.

기업 환경에서 PostgreSQL을 사용해 보셨나요?

저자 :

Oleg Lavrenov, Jet Infosystems의 데이터 스토리지 시스템 설계 엔지니어

Jet Infosystems의 컴퓨터 시스템 설계 엔지니어인 Dmitry Erykin

출처 : habr.com