RPM 오케스트레이터를 사용하는 AlloyDB Omni 개요

문서 버전을 선택합니다.

AlloyDB Omni는 Kubernetes가 아닌 환경(예: Red Hat Package Manager(RPM) 패키지를 사용하는 Red Hat Enterprise Linux(RHEL) 및 호환 시스템)에 AlloyDB Omni를 배포하고 관리하는 조정 플랫폼을 제공합니다. RPM 오케스트레이터 배포 옵션은 클라우드와 유사한 유연성과 자동화를 온프레미스 및 가상 머신 (VM) 인프라로 확장합니다.

RPM 오케스트레이터를 사용하는 AlloyDB Omni를 사용하면 기업에서 표준 RPM 패키지를 사용하여 AlloyDB Omni 인스턴스를 설치, 구성, 관리할 수 있습니다. 이 접근 방식은 VM 인프라에 상당한 투자를 하고 Ansible과 같은 자동화 도구를 중심으로 구축된 운영 사례를 확립한 조직을 지원합니다. RPM 오케스트레이터 배포 옵션은 Docker와 같은 컨테이너화 레이어나 Kubernetes와 같은 오케스트레이션 시스템 없이 Linux VM 또는 베어메탈 서버에서 직접 실행됩니다.

사용 사례

RPM 오케스트레이터 배포 옵션은 다음 사용 사례를 지원합니다.

사용 사례 설명
VM 인프라를 사용하는 기업 Kubernetes가 표준이 아니거나 표준 VM 또는 베어메탈 배포를 선호하는 애플리케이션 종속 항목이 있는 컨테이너화된 환경을 지원합니다.
운영 간소화 Ansible과 같은 친숙한 도구를 사용하여 데이터베이스 배포, 구성, 수명 주기 관리를 자동화합니다.
고가용성 (HA) 및 재해 복구 (DR) 자동 장애 조치 및 복구 메커니즘을 사용하여 복원력이 있는 AlloyDB Omni 클러스터를 설정합니다.
하이브리드 환경 온프레미스 데이터 센터와 클라우드 VM 전반에서 일관된 데이터베이스 작업을 보장합니다.
레거시 시스템 통합 컨테이너화되지 않은 환경을 위해 설계된 기존 애플리케이션 및 시스템과 통합됩니다.

이점

RPM 오케스트레이터 배포 옵션의 이점은 다음과 같습니다.

  • 빠른 배포: 프로비저닝부터 검증까지 전체 수명 주기를 자동화하여 AlloyDB Omni 클러스터 설정에 필요한 시간과 복잡성을 크게 줄입니다.
  • 원활한 통합: 표준 Linux 패키지 관리(RPM) 및 인기 있는 자동화 프레임워크(예: Ansible)와 기본적으로 통합되므로 팀에서 기존 기술과 도구 통합을 사용할 수 있습니다.
  • 일관된 환경: 다양한 배포 모델에서 일관성을 제공하는 AlloyDB Omni Kubernetes 운영자와 유사한 관리 및 운영을 위한 사용자 환경과 특성 세트를 제공합니다.
  • 엔터프라이즈급 고가용성 (HA) 및 재해 복구 (DR): 비즈니스 연속성 요구사항을 충족하기 위해 고가용성 및 재해 복구를 위한 유연한 구성을 지원합니다.
  • 강력한 보안: 사용자 관리, 인증서(SSL)를 사용한 네트워크 보안, Microsoft Active Directory와 같은 시스템과의 통합 등 다각적인 보안 전략의 구현을 지원합니다.
  • 중앙 집중식 관리: AlloyDB Omni 서비스를 사용하여 VM에서 AlloyDB Omni를 관리하기 위한 통합 컨트롤 플레인을 제공합니다.
  • 관측 가능성 및 감사: 중앙 집중식 로그 관리, 모니터링, 감사를 위해 rsyslog를 사용하여 외부 로깅 서버(예: Elastic Stack)와의 통합을 지원합니다.
  • 데이터 보호: 간소화된 백업 및 복원 구성과 전략을 위한 기능이 포함됩니다.
  • 연결 풀링: 데이터베이스 연결을 최적화하고 성능을 개선하기 위해 PgBouncer 배포를 지원합니다.
  • Fleet 관리: 여러 AlloyDB Omni 클러스터를 대규모로 관리할 수 있습니다.

아키텍처

AlloyDB Omni는 유연성을 제공하는 구성요소의 계층 구조를 정의합니다. 이 유연성을 통해 데이터 가용성을 극대화하고 쿼리 성능과 처리량을 최적화할 수 있습니다. 이 방법을 사용하면 AlloyDB Omni 배포를 모니터링하고 워크로드에 맞게 규모와 크기를 조정할 수 있습니다.

다음 그림은 베어메탈 또는 VM 환경에서 AlloyDB Omni 배포의 분류를 보여줍니다.

AlloyDB Omni VM 배포 토폴로지입니다.

그림 1. AlloyDB Omni VM 배포 토폴로지

계층 구조의 최상위 리소스는 기본 클러스터와 하나 이상의 보조 클러스터가 있는 AlloyDB Omni 배포입니다. AlloyDB Omni 클러스터에는 하나 이상의 인스턴스가 있으며, 이는 사용자가 연결하는 컴퓨팅 리소스의 추상화입니다. 클러스터에는 기본 인스턴스 (읽기-쓰기)와 하나 이상의 선택적 읽기 풀 인스턴스(읽기 전용)가 포함됩니다. 각 인스턴스에는 자체 액세스 엔드포인트가 있습니다. 선택적으로 독립형 배포를 위한 단일 노드 또는 고가용성 배포를 위한 여러 노드를 사용하여 기본 인스턴스를 설정할 수 있습니다. 모든 노드에는 소프트웨어 패키지를 사용하여 AlloyDB Omni 및 기타 관련 구성요소가 배포되어 있습니다.

기본 인스턴스에는 트랜잭션 워크로드를 처리하도록 설계된 활성 (읽기-쓰기) 노드가 하나 포함되어 있습니다. 기본 테스트, 실험, 개발을 넘어선 데이터베이스 클러스터의 경우 추가 대기 노드를 사용하여 고가용성을 설정하세요. 읽기 및 쓰기 트랜잭션을 제공하는 기본 노드의 가용성이 손실되는 장애 발생 시 데이터 손실 (RPO=0)을 방지하려면 대기 노드의 동기화된 복제 모드를 구성하세요. RPO는 복구 지점 목표로 정의됩니다.

구성요소

RPM 오케스트레이터 배포 옵션에는 완전한 고가용성 AlloyDB Omni 배포를 위해 각각 RPM 또는 Debian 패키지로 설치되는 소프트웨어 구성요소 집합이 포함됩니다. 참조 아키텍처는 데이터베이스 작업을 위해 이러한 구성요소를 사용합니다.

구성요소 설명
조정자 AlloyDB Omni 오케스트레이션은 분산 환경에서 하나 이상의 AlloyDB Omni 클러스터를 배포하고 관리하는 데 도움이 되는 명령줄 및 Ansible 인터페이스를 제공합니다.
alloydbomni AlloyDB Omni 코어에는 성능을 개선하고 온라인 분석 처리 (OLAP), 생성형 AI와 같은 최신 워크로드를 지원하는 기능을 제공하는 PostgreSQL 및 Autopilot 기능이 포함되어 있습니다.
alloydbomni_monitor AlloyDB Omni 모니터를 사용하면 AlloyDB Omni에서 측정항목을 가져올 수 있습니다.
etcd etcd는 클러스터 관리자가 PostgreSQL 구성 및 상태 정보를 저장하는 데 사용하는 분산 구성 시스템을 제공합니다.
클러스터 관리자 중앙 컨트롤 플레인은 클러스터 전체 작업을 오케스트레이션합니다. 여기에는 클러스터 부트스트랩, HA 관리, 장애 조치 처리, 업그레이드 조정, 자동화 도구(예: Ansible 및 alloydbctl 명령줄 유틸리티)용 인터페이스 노출이 포함됩니다.
노드 관리자 AlloyDB Omni 클러스터의 각 노드에서 실행되는 에이전트입니다. 클러스터 관리자와 상호작용하여 노드에서 작업을 실행합니다(예: AlloyDB Omni 설치 및 구성, 데이터베이스 서비스 수명 주기 관리(시작 및 중지), 노드 상태 모니터링, 로그 및 측정항목 수집).
HAProxy HAProxy는 AlloyDB Omni 배포의 부하 분산기로 작동합니다. 읽기-쓰기 및 읽기 전용 엔드포인트를 노출합니다. 클러스터 관리자와 함께 작동하여 트래픽을 적절한 활성 노드로 리디렉션합니다.
keepalived keepalived는 유동 가상 IP 주소를 사용하여 참여 노드(예: HAProxy)에 HA를 제공할 수 있습니다.
PgBouncer PgBouncer는 PostgreSQL 데이터베이스용 경량 연결 풀러입니다.
pgBackRest pgBackRest는 PostgreSQL용으로 설계된 오픈소스 백업 및 복원 도구입니다.

이 아키텍처를 사용하면 기존 Linux VM 환경에서 AlloyDB Omni를 효율적으로 실행하고 운영하여 AlloyDB Omni를 확립된 운영 관행의 친숙함과 결합할 수 있습니다.

시스템 요구사항

AlloyDB Omni 배포 스택의 시스템 요구사항에는 다양한 구성요소를 실행하도록 미리 구성된 가상 머신 집합이 포함됩니다. 각 AlloyDB Omni 가상 머신에는 ext4/xfs 파일 시스템으로 구성된 데이터 디스크가 연결되어 있어야 합니다. 디스크 크기는 데이터 크기에서 추정됩니다. 스토리지의 성능 특성은 AlloyDB Omni의 성능에 영향을 미칩니다. 다음 표에는 VM의 최소 및 권장 CPU 및 메모리 구성이 나와 있습니다.

VM 유형 최소 하드웨어 및 운영체제 (OS) 권장 하드웨어 및 OS
컨트롤러 노드
  • OS: RHEL9
  • CPU: AVX2를 지원하는 x86-64 2 vCPU
  • RAM: 2GB
  • 디스크: 10GB
  • OS: RHEL9
  • CPU: AVX2를 지원하는 x86-64 8 vCPU
  • RAM: 8GB
  • 디스크: 20GB 이상
부하 분산기 노드
  • OS: RHEL9
  • CPU: AVX2를 지원하는 x86-64 2 vCPU
  • RAM: 2GB
  • 디스크: 10GB
  • OS: RHEL9
  • CPU: AVX2를 지원하는 x86-64 16 vCPU
  • RAM: 8GB
  • 디스크: 20GB 이상
AlloyDB Omni (독립형)
  • OS: RHEL9
  • CPU: AVX2를 지원하는 x86-64 2 vCPU
  • RAM: 16GB
  • 디스크: 20GB
  • 데이터 디스크: 데이터 크기의 2배
  • OS: RHEL9
  • CPU: AVX2를 지원하는 x86-64 64 vCPU
  • RAM: AlloyDB Omni의 경우 vCPU당 8GB
  • 디스크: 20GB
  • 데이터 디스크: 데이터 크기의 2배
AlloyDB Omni (고가용성)
  • OS: RHEL9
  • CPU: AVX2를 지원하는 x86-64 4 vCPU
  • RAM: 20GB
  • 디스크: 10GB
  • 데이터 디스크: 데이터 크기의 2배
  • OS: RHEL9
  • CPU: AVX2를 지원하는 x86-64 64 vCPU
  • RAM: AlloyDB Omni의 경우 vCPU당 8GB 이상
  • 디스크: 20GB
  • 데이터 디스크: 데이터 크기의 2배
백업 저장소 노드
  • OS: RHEL9
  • CPU: AVX2를 지원하는 x86-64 2 vCPU
  • RAM: 2GB
  • 디스크: 10GB
  • 백업 디스크: N일 * 데이터 크기
  • OS: RHEL9
  • CPU: AVX2를 지원하는 x86-64 8 vCPU
  • RAM: 8GB
  • 디스크: 20GB
  • 백업 디스크: N일 * 데이터 크기

HA 배포 참조 아키텍처

HA 아키텍처는 단일 노드 데이터베이스 설정보다 향상된 데이터 계층 다운타임 방지 기능을 제공합니다. 이 참조 아키텍처 구성은 한 노드를 기본 활성으로, 다른 노드를 동기 스트리밍 복제 대기 서버로 사용하는 3노드 설정을 사용하며, 별도의 영역에 배포됩니다. 기본 노드에 장애가 발생하면 대기 노드 중 하나가 기본 노드 역할을 인계받아 클라이언트 쿼리를 처리합니다.

소프트웨어 스택의 클러스터 관리자 구성요소가 클러스터 구성을 실행합니다. 클러스터 관리자는 AlloyDB Omni 서버도 모니터링하고 분산 구성 시스템(예: etcd)을 사용하여 새 기본 인스턴스를 선택합니다. 기업은 RPO와 RTO (복구 시간 목표)를 가용성의 주요 측정항목으로 사용합니다. HA 아키텍처 설정은 영역 수준 장애에 대해 거의 0에 가까운 RPO 및 RTO를 제공합니다.

추가 노드는 읽기 전용 워크로드용으로 구성된 추가 엔드포인트와 함께 HAProxy 기반 부하 분산기를 배포합니다. HAProxy는 클러스터 관리자와 함께 작동하여 현재 활성 노드를 모니터링하고 장애 조치가 발생하면 새 활성 노드로 전환합니다. 클라이언트는 HAProxy 노드에 연결하여 데이터베이스에서 작업을 실행합니다. 다음 이미지는 이 HA 배포 아키텍처를 보여줍니다.

AlloyDB Omni HA 배포 아키텍처

그림 2: HA 배포 아키텍처

RPM 조정자

RPM 조정자를 사용하는 AlloyDB Omni는 일련의 VM 또는 베어메탈 서버에 AlloyDB Omni 데이터베이스 클러스터를 설치, 설정, 관리하기 위한 자동화 플랫폼과 컨트롤 플레인을 제공합니다. 여기에는 독립형, 복원력 있는, 확장 가능한 고가용성 (HA)과 같은 다양한 참조 아키텍처 구성이 포함됩니다.

AlloyDB Omni 클러스터 관리자는 컨트롤 플레인을 제공합니다. 이 구성요소는 AlloyDB Omni 클러스터의 관리 및 고가용성을 자동화하여 AlloyDB Omni 클러스터의 엔드 투 엔드 수명 주기를 제어하는 데 도움이 되는 핵심 서비스입니다. 컨트롤 플레인 자체는 가용성이 높으며 다양한 장애 시나리오를 처리합니다.

RPM 오케스트레이터 배포 옵션은 AlloyDB Omni 클러스터 관리자 서비스와 통신하는 원격 인터페이스입니다. 오케스트레이터는 제어 노드라는 전용 노드에서 실행됩니다. 이 노드에서 보안 채널을 통해 하나 이상의 클러스터를 원격으로 관리할 수 있습니다. 환경과의 호환성을 위해 여러 AlloyDB Omni 오케스트레이터를 사용할 수 있습니다. 자동화 요구사항에 적합한 오케스트레이터를 선택합니다.

  • AlloyDB Omni 오케스트레이터 CLI (RPM으로 제공): 셸 스크립트를 사용하여 클러스터 배포 및 관리를 자동화하는 환경에 권장됩니다.
  • RPM 오케스트레이터 Ansible (Ansible 컬렉션으로 제공): 기본 제공 Ansible 기반 자동화를 사용하고 추가 Ansible 역할 호출로 이를 확장할 준비가 된 환경에 권장됩니다. 기존 Ansible 플레이북과의 간단한 통합을 지원하기 위해 Ansible 플레이북 예시가 제공됩니다.

AlloyDB Omni 오케스트레이터는 다음 AlloyDB Omni 클러스터 관련 작업을 지원합니다. Ansible 기반 오케스트레이터는 이러한 각 작업에 Ansible 역할을 제공합니다. 명령줄은 셸 프롬프트나 셸 스크립트를 사용하여 호출되는 명령어 집합을 제공합니다.

  • Installation: 각 노드에 다양한 클러스터 구성요소를 설치합니다.
  • Bootstrap: 사양에 따라 모든 구성요소를 구성하고 부트스트랩합니다.
  • Update: 최신 버전 또는 업데이트된 구성의 리소스를 업데이트합니다.
  • Status: 클러스터의 모든 구성요소 또는 서비스의 상태를 가져옵니다.
  • List: 클러스터에 배포된 사용 가능한 리소스 목록을 가져옵니다.
  • Delete: 클러스터 리소스를 삭제합니다.

오케스트레이터는 YAML 형식으로 사양 집합을 입력으로 사용합니다.

  • 배포 사양: VM 클러스터의 토폴로지를 정의하는 Ansible 인벤토리 형식과 동일합니다. 여기에는 다음과 같은 다양한 VM 그룹과 구성이 포함됩니다.
    • primary_instance_nodes: AlloyDB Omni 데이터베이스 서버 전용 노드입니다.
    • cluster_manager_nodes: 선택사항. AlloyDB Omni 클러스터 관리자 서버를 실행하는 노드입니다. 전용 클러스터 관리자 노드가 없는 경우 primary_instance_nodes에 클러스터 관리자를 배포할 수 있습니다.
    • etcd_nodes: 클러스터 관리자가 etcd에 메타데이터를 저장합니다. 명시적으로 지정하지 않으면 etcd가 클러스터 관리자 노드와 동일한 노드에서 실행될 수 있습니다.
    • load_balancer_nodes: HAProxy 기반 부하 분산기에 전용으로 사용되는 추가 노드입니다.
  • 리소스 사양: 클러스터는 배포 및 관리할 하나 이상의 클러스터 리소스(예: 데이터베이스 클러스터 및 연결 풀러)로 구성됩니다. 리소스 사양은 YAML 형식이며 클러스터에 배포할 리소스를 설명합니다.

제한사항

  • 미리보기 버전에서는 다음만 지원됩니다.
    • AlloyDB Omni PostgreSQL 18
    • RHEL 버전 9와 호환되는 소프트웨어 패키지
    • Intel x86 64비트 플랫폼
  • 메이저 버전 업그레이드는 지원되지 않습니다.
  • 재해 복구 및 읽기 풀 인스턴스 설정 안내는 포함되어 있지 않습니다.
  • AlloyDB Omni 모니터링은 SSL 연결을 지원하지 않습니다. AlloyDB Omni 노드와 동일한 비공개 네트워크에 모니터링 대시보드 서버를 배포해야 합니다.
  • AlloyDB Omni는 SELinux가 있는 경우 파일 시스템 액세스를 포함하여 허용되도록 호스트가 구성되어 있다고 가정합니다.

다음 단계