Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space ML1 and version 5.3
Sv translation
languageen

This document details best practices to maximize uptime for applications running on Xpand. This covers a wide range of topics, from environmental requirements to change management procedures, all of which ultimately impact the availability of your application. Many of these are standard best practices or concepts with which you are likely already familiar.

Designing for high availability minimizes risk with the following strategies:

  • Careful control of environment and application changes
  • Elimination of single points of failure
  • Provisioning of sufficient additional resources to allow for continued operation in the event of failure
  • Regularly scheduled and tested backup and recovery plan

The following best practices maximize high availability on Xpand:

Table of Contents

Use Multiple Operation Environments

An operationally mature organization may have as many as four different environments:

  1. Production
  2. Disaster Recovery
  3. Staging
  4. Development

For highest availability, a production environment may contain a pair of identical clusters which replicate in a Master-Master configuration. Only one cluster should actively take writes, with the other available for immediate failover (active/passive); alternatively, if there are distinct applications or databases, these may be configured such that one cluster is active for a set of applications, while the other cluster is active for another. Having both clusters take writes (active/active) is possible but presents a number of operational challenges (see Master-Master Replication). Managing cut-over of application load from one cluster to the other can be handled through the use of an external load balancer, or by reconfiguration of application servers.

A disaster recovery environment is typically at a geographically distinct location and includes a cluster which replicates from the production environment, along with application servers that are able to provide site functionality (possibly with degraded performance) in case of site-wide failure of the production environment.

A staging environment will typically be a (scaled down) facsimile of the production environment, including comparable application servers and datasets. It is used to validate changes to the application software as well as upgrades to the Xpand software. A crucial part of the staging environment is a test automation framework which allows for the exercise of the application and database with a load approximating peak load in the production environment.

A development environment allows for more ad hoc development, where the risk of developers interfering with each other's work is inconsequential.

To achieve optimum uptime goals Xpand highly recommends the use of multiple clusters, which can provide the following:

  • Isolation of application development from the production database
  • Isolation of analytic workload from time-critical transactional workload
  • Disaster recovery/business continuance failover for site-wide outages
  • Pre-production validation of application changes and Xpand software upgrades 

Highly Available Production Environment

To take full advantage of Xpand's fault tolerant architecture, the following environmental and provisioning requirements should be met:

  • Each node's power supply should be connected to a separate power circuit
  • Each production cluster should have two backend network switches
  • Each backend network switch should be connected to a separate power circuit
  • Each node should connect to the production network via two Ethernet ports (interfaces are bonded), to two separate Ethernet switches
  • Cluster nodes should be provisioned to accommodate storage and concurrency requirements in the event of node failure. Zones should be configured to isolate faults. 

Change Management

The vast majority of software failures arise from changes in application behavior, whether due to a bug in the application itself, or exposure of a bug in an underlying layer such as the database. Accordingly, the best practice is to first thoroughly validate such changes in non-production environment(s), and then carefully roll out into production, with roll back plans in place to undo changes in case of surprises.

Application Change Management

The existence of development and staging environments allows an organization to roll out new applications and application changes in a safe manner.

  • New application development is restricted to the development environment where malformed queries and other abuse of the database can only impact other development work.
  • Once the code has stabilized, it can be incorporated into the staging environment, where it is tested at load, and in conjunction with the existing production workload. (The XpandGUI Administration UI can provide helpful comparative information.)
  • After validating proper functionality and performance in the staging environment, the changes can be rolled into production.

Xpand Upgrade Best Practices

Upgrading the software on your Xpand cluster can be treated in much the same way as application code changes. While Xpand software releases are thoroughly tested in-house, changes such as new compiler optimizations can have an unanticipated impact on customer workloads; validation of the new release on a staging cluster running a simulated workload allows discovery of such issues prior to production rollout.

In an ideal operational environment, customers can participate in the beta program, obtaining early release candidates for use in their development cluster. Once a qualified release is available, they can test in their staging environment to eliminate problems evident under heavy workloads. When upgrading production, if a pair of clusters is available, one cluster should be upgraded first; the cluster can then undergo a full day or week of load before upgrading the second cluster, providing for failback to the second cluster running the prior, stable release.

Application Configuration for High Availability

While eliminating single points of failure in your application stack is beyond the scope of this document, the following guidelines pertain specifically to how your application interacts with the Xpand database layer:

  • Application servers should connect through a load balancer
  • Application software should have retry logic for database transaction or connection failures
    • Initial retry timing should be aggressive as cluster typically handles component failures in a few seconds
    • Retry frequency and iterations should also accommodate possible longer duration recovery

Backup and Recovery

Xpand parallel fast backup provides for rapid backup which allows for near-constant backup time as your cluster grows, as the work is split across the nodes. When planning your backup strategy, consider the following:

  • The FTP server typically becomes the bottleneck during backup
    • It should be provisioned with 10Gb or several bonded 1Gb Ethernet interfaces
    • It should have fast enough disk I/O to synchronize parallel writes from all nodes in the cluster 
    • It should have sufficient disk capacity to handle two or more full backups of the cluster (1/2 of total used capacity, as Xpand backs up only one replica from each slice) 
  • Off-site archival of backups
  • Regular tests of the ability to restore from backup
    • Xpand parallel restore supports restoring subsets of a backup, as well as restoring to alternate locations (different database names), allowing for regular "spot checks" where a sufficiently large cluster for full restore is unavailable
  • (Off-site) archival of binlogs using the repclient utility to support point-in-time restoration
    • This also requires the use of repserver to replay binlogs
    • The full process for point in time restoration is described in Point in Time Restoration
Sv translation
languageko

이 문서에서는 ClustrixDB를 기반으로 구축된 응용 프로그램의 서비스 지속성을 극대화하기 위한 모범 사례를 자세히 설명합니다. 여기에는 환경 요구 사항에서 변경 관리 절차에 이르는 광범위한 주제가 포함되며, 이것들은 궁극적으로 응용 프로그램의 가용성에 영향을 미치게 됩니다. 제시된 사례들은 대부분은 표준 모범 사례이거나 이미 여러분에게 잘 알려진 개념입니다.

다음과 같은 전략으로 고가용성 설계를 하면 리스크가 줄어듭니다.

  • 환경 및 응용 프로그램 변경의 신중한 관리
  • 단일 장애 지점 제거
  • 장애 발생 시 지속적인 운영이 가능하도록 충분한 추가 자원 제공
  • 주기적 백업 및 복구 일정 계획

다음 모범 사례는 ClustrixDB에서 고가용성을 극대화합니다.

Table of Contents

다양한 운영 환경 사용

운영상 성숙한 조직에는 다음과 같이 4개의 개별 환경이 있습니다.

  1. 프로덕션
  2. 재해 복구
  3. 스테이징
  4. 개발

고가용성을 위한 프로덕션 환경에서는 동일한 클러스터 한 쌍을 마스터-마스터 설정으로 복제하는 경우가 있습니다. 이 경우 하나의 클러스터는 쓰기 요청을 처리하고 나머지 클러스터는 즉각적인 장애 복구를 위해 대기(active/pass 구성)하게 됩니다. 또는 개별 애플리케이션 또는 데이터베이스가 있는 경우 하나의 클러스터가 일부 애플리케이션을 처리하고 나머지 클러스터가 다른 애플리케이션을 처리하도록 구성할 수도 있습니다. 두 클러스터 모두 쓰기를 처리하도록 active/active 모드로 구성하는 것은 가능하지만 몇 가지 운영상의 어려운 점이 있습니다 (Master-Master Replication 참조). 클러스터에서 다른 클러스터로 응용 프로그램 부하를 전환하도록 관리하려면 외부 로드 밸런서를 사용하거나 응용 프로그램 서버를 재구성해야 합니다.

재해 복구 환경은 일반적으로 지리적으로 다른 위치에 있고 프로덕션 환경 사이트 전체에 장애가 발생할 경우에 대비하여 비록 성능 저하는 있더라도 사이트가 정상 동작할 수 있도록 애플리케이션 서버와 프로덕션 환경에서 복제되는 클러스터가 여기에 포함됩니다.

스테이징(staging) 환경은 일반적으로 유사한 응용 프로그램 서버 및 데이터 세트를 포함한 프로덕션 축소 복사판입니다. ClustrixDB 소프트웨어 업그레이드뿐만 아니라 애플리케이션 소프트웨어에 대한 변경을 검증하는 데 사용합니다. 스테이징 환경의 가장 중요한 역할은 프로덕션 환경에 근접한 부하로 애플리케이션과 데이터베이스를 실행할 수 있는 테스트 자동화 프레임워크입니다.

개발 환경은 더 많은 ad-hoc 개발을 가능하게 하며, 개발자가 서로의 작업을 방해할 위험이 아주 적은 경우입니다.

최적의 가동 시간 목표를 달성하기 위해서 다중 클러스터를 사용하기를 권장합니다. 다중 클러스터는 다음과 같은 이점을 제공합니다.

  • 프로덕션 데이터베이스에서 응용 프로그램 개발 분리
  • 시간 임계적 처리 워크로드로부터 분석적 워크로드의 분리
  • 사이트 전체 장애에 대비한 재해 복구 및 비즈니스 연속성 장애 극복
  • 애플리케이션 변경 및 ClustrixDB 소프트웨어 업그레이드 사전 프로덕션 검증

고가용성 프로덕션 환경

ClustrixDB의 내결함성 아키텍처를 최대한 활용하려면 다음과 같은 환경 및 프로비저닝 관련 필수사항을 충족해야 합니다.

  • 각 노드의 전원 공급 장치는 별도의 전원에 연결해야 합니다.
  • 각 프로덕션 클러스터에는 2개의 백엔드 네트워크 스위치가 있어야 합니다.
  • 각 백엔드 네트워크(InfiniBand 또는 Ethernet) 스위치는 별도의 전원에 연결해야 합니다.
  • 각 노드는 2개의 인터페이스 본딩된 Ethernet 포트를 통하여 프로덕션 네트워크에 연결하거나 두 개의 별도의 Ethernet 스위치에 연결해야 합니다.
  • 노드 장애 시 스토리지 및 동시 실행 요구 사항을 충족하려면 클러스터에 여분의 노드를 추가로 구성해야 합니다 (오버프로비져닝).

변경 관리

대부분의 소프트웨어 장애는 응용 프로그램 자체의 버그 또는 데이터베이스와 같은 기본 계층의 버그 노출로 인해 애플리케이션 동작이 변경되어 발생합니다. 따라서 비 프로덕션환경에서 먼저 이러한 변경 사항을 철저하게 검증하고 문제 발생 시 변경을 취소할 롤백 계획도 함께 세워 신중하게 프로덕션 단계로 내놓는 것이 가장 좋은 방법입니다.

애플리케이션 변경 관리

개발 및 스테이징 환경의 존재로 인해 조직은 새로운 응용 프로그램 및 응용 프로그램의 변경 사항을 안전하게 배포할 수 있습니다.

  • 새로운 애플리케이션 개발은 잘못 작성한 쿼리나 기타 데이터베이스의 오용이 다른 개발 작업에만 영향을 주는 개발 환경으로 국한합니다.
  • 일단 코드가 안정화되면 스테이징 환경에 통합할 수 있습니다. 스테이징 환경에서는 로드 시 기존 프로덕션 워크로드와 함께 테스트할 수 있습니다. (Xpand Administration UI는 유용한 비교 정보를 제공할 수 있습니다.)
  • 스테이징 환경에서 적절한 기능과 성능을 검증한 후 변경 사항을 프로덕션 환경에 적용할 수 있습니다.

ClustrixDB 업그레이드 모범 사례

ClustrixDB 소프트웨어 업그레이드는 응용 프로그램 코드의 변경과 거의 동일한 방식으로 처리할 수 있습니다. ClustrixDB 소프트웨어 릴리스는 Clustrix 내부에서 철저하게 테스트 되지만 컴파일러 최적화 등의 변경 사항은 고객 워크로드에 예상치 못한 영향을 줄 수 있습니다. 시뮬레이션 된 워크로드를 실행하는 스테이징 클러스터에서 새 릴리스를 검증하면 프로덕션 출시 이전에 이러한 문제를 발견할 수 있습니다.

이상적인 운영 환경을 갖춘 고객이라면 ClustrixDB 베타 프로그램에 참여하여 고객의 개발 클러스터에 사용할 RC(release candidate) 버전을 받을 수 있습니다. 이후 검증된 릴리스가 출시되면 스테이징 환경에서 테스트하여 과도한 워크로드에서 발생하는 문제를 제거할 수 있습니다. 프로덕션을 업그레이드하는 경우 한 쌍의 클러스터(2개의 클러스터)를 사용할 수 있으면 먼저 하나의 클러스터를 업그레이드해야 합니다. 두 번째 클러스터를 업그레이드하기 전에 클러스터는 하루 또는 일주일 동안 워크로드를 처리하게 되고, 장애 발생 시 이전의 안정적인 릴리스를 실행하는 두 번째 클러스터로 되돌릴 수 있습니다. 이 기간 동안에 장애가 발생하면 이전의 안정된 릴리스에 실행되는 두 번째 클러스터에서 서비스 원상복귀(failback)를 제공하게 됩니다.

고가용성을 위한 응용 프로그램 구성

애플리케이션 스택의 SPOF(single point of failure) 제거는 이 문서의 범위를 벗어나므로 아래 지침은 응용 프로그램이 ClustrixDB 데이터베이스 레이어와 어떻게 상호 작용하는지 대한 설명만 다루고 있습니다.

  • 응용 프로그램 서버는 로드 밸런서를 통해서 연결해야 합니다.
  • 응용 프로그램은 데이터베이스 트랜잭션 또는 연결 실패에 대한 재시도 로직을 가지고 있어야 합니다.
    • 일반적으로 클러스터는 단 몇 초 안에 구성 요소의 장애를 처리하기 때문에 초기 재시도 타이밍은 매우 짧아야 합니다.
    • 재시도 주기 및 반복 횟수는 가능한 긴 복구 시간에 맞게 조정해야 합니다.

백업 및 복구

ClustrixDB의 빠른 병렬 백업은 노드 전체에 작업이 분산되기 때문에 클러스터가 커짐에 따라 거의 일정한 시간의 빠른 백업을 제공합니다. 백업 전략 계획 시 다음 사항을 고려하십시오.

  • 일반적으로 백업 시 FTP 서버에서 병목이 발생됩니다.
    • 10GB 또는 다수의 본딩된 1GB Ethernet 인터페이스를 제공해야 합니다.
    • 클러스터의 모든 노드에서 병렬 쓰기를 동기화하려면 충분한 디스크 I/O가 필요합니다.
    • 두 번 이상의 클러스터 전체 풀 백업을 처리할 수 있는 충분한 디스크 공간이 필요합니다 (전체 사용 용량의 ½, 각 슬라이스에서 하나의 복제본만 백업합니다).
  • 백업의 원격지 아카이빙
  • 백업에서 복구하는 기능에 대한 정기적인 테스트
    • ClustrixDB의 병렬 복구는 대체 위치(다른 데이터베이스 이름) 복구뿐만 아니라 백업 하위 집합 복구도 지원합니다. 이를 통해 전체 복구를 위한 충분히 큰 클러스터를 사용할 수 없는 경우 "spot check"가 가능합니다. 전체 복원에 필요한 충분한 크기의 클러스터가 없을 경우에는 정기적인 “spot check" 도 가능합니다.
  • 시점 복원(point-in-time restoration)을 지원하는 repclient 유틸리티를 사용하여 원격지(off-site) binlogs 아카이빙
    • binlog 재생을 위해서는 repserver 유틸리티를 사용해야 합니다.
    • 포인트인타임 복원의 전체 프로세스는 Point in Time Restoration을 참조하십시오.