- SQL Server의 고가용성 및 재해 복구를 위한 비즈니스 연속성 필요
- 비즈니스 연속성의 목표는 중단을 최소화하거나 중단 없이 비즈니스를 계속 운영하는 것
- 가용성 기능을 사용할 수 있는 주요 방법
1) 고가용성(HA)
2) 재해 복구
3) 마이그레이션 및 업그레이드
4) 하나 이상의 데이터베이스에서 읽을 수 있는 복사본 확장 - SQL Server 복제는 가용성 기능으로 공식 지정되지는 않았지만 특정 시나리오에서 데이터 중복을 위해 종종 사용됨
[고가용성]
- 클라우드 지역의 데이터 센터 또는 단일 지역에 국한된 문제가 발생하는 경우 SQL Server 인스턴스 또는 데이터베이스를 사용할 수 있도록 하는 것
- Always On 가용성 그룹
- 데이터베이스의 각 트랜잭션을 "Replica"라고 하는 다른 인스턴스로 보내 데이터베이스 수준의 보호를 제공함
- SE 또는 EE 버전에서 배포할 수 있으며, 인스턴스는 독립 실행형이거나 Always On FCI 일 수 있음
- 트랜잭션이 발생하면 replica로 전송되기 때문에 복구 지점 및 복구 시간 목표를 낮추기 위한 요구 사항이 있는 경우 가용성 그룹(AG)을 사용하는 것이 좋음
- replica 간의 데이터 이동은 동기식/비동기식이며, EE에서는 동기식으로 최대 3개의 replica가 허용됨
- AG에는 primary replica에 있는 데이터베이스의 전체 읽기/쓰기 복사본이 하나 있고, 모든 secondary replica는 최종 사용자/애플리케이션에서 직접 트랜잭션을 수신할 수 없음
- 인스턴스 수준이 아닌 데이터베이스 수준의 보호만 제공됨 - (예시)인스턴스 수준의 로그인, 연결된 서버 및 SQL Server 에이전트 작업은 수동으로 동기화해야 함
- AG에는 Listener라는 구성요소가 있어서 primary replica를 호스팅하는 인스턴스를 몰라도 연결이 가능함
- AG는 자동/수동 장애 조치, 즉 Failover를 제공함 - 자동 failover는 동기화된 데이터 이동이 구성되어 있고 primary replica와 secondary replica의 데이터베이스가 동기화된 상태이면 발생할 수 있음
Always On 가용성 그룹 클러스터 유형
- WSFC(Windows Server Failover Cluster)
- EXTERNAL
- NONE
- Always On FCI
- FCI = Failover Cluster Instance
- SQL Server 전체 설치에 대해 가용성을 제공하는 방법/인스턴스
- 기본 서버에 문제가 발생할 경우 데이터베이스, SQL Server 에이전트 작업, 연결된 서버 등 인스턴스 내부의 모든 항목이 다른 서버로 이동
- 공유 스토리지 필요(FCI와 물리적으로 분리된 스토리지 사용 필요) - FCI의 리소스는 주어진 시간에 한 노드에서만 실행하고 소유 가능
- FCI에서는 데이터 손실이 거의 없지만 데이터 복사본이 하나라는 주의사항이 존재함 - 데이터베이스 복사본을 확보하기 위한 AG 및 log shipping과 같은 다른 가용성 방법과도 결합됨
- FCI가 다른 노드로 failover하게 되면 노드를 중지하고 다른 노드에서 시작하게 됨 - 정상 복구 프로세스를 거치게 되며 롤포워드가 필요한 트랜잭션은 롤포워드가 수행되며 불완전한 트랜잭션은 롤백됨
- 데이터베이스는 복구가 완료된 후에만 사용할 수 있으며 일반적으로 AG의 failover 보다 더 많은 시간이 소요됨
- FCI는 primary/secondary replica를 호스트하는 인스턴스 중 하나로 AG에 참여 가능
- 로그 전달(Log shipping)
- 복구 시점 및 복구 목표가 유연하거나 해당 데이터베이스가 업무상 덜 중요하다면 log shipping을 사용함
- log shipping 프로세스: Primary 트랜잭션 로그 백업 자동 생성 -> (하나 이상의) Warm Standby 인스턴스에 트랜잭션 로그 백업 복사 -> 해당 트랜잭션 로그 백업을 대기 항목으로 자동 적용
- log shipping은 SQL Server 에이전트 작업을 사용하여 트랜잭션 로그 백업/복사/적용하는 프로세스를 자동화함
- 트랜잭션 로그 적용은 지연될 수 있음 - WHERE절 없는 UPDATE와 같은 명령을 보내면 standby에 변경사항이 전달되지 않아 primary시스템을 복구하는 동안 전환될 수 있음
- log shipping은 구성하기 쉽지만 primary에서 warm standby로 역할 변경하는 것은 항상 수동
- 단일 AG에는 여러 데이터베이스가 포함될 수 있지만 log shipping은 데이터베이스별로 구성 필요
[재해 복구]
- Primary 가용성 위치에 지진이나 홍수와 같은 치명적인 재해가 발생하는 경우, 자사 시스템이 다른 곳에서 온라인 상태가 되도록 준비 필요
- Always On 가용성 그룹
- 고가용성을 위해 하나의 데이터센터에 로컬인 replica를 확보하고 재해 복구를 위해 다른 데이터센터에 원격 replica를 확보하는 것으로 primary replica는 모든 secondary replica를 동기화된 상태로 유지 필요
- secondary replica는 읽기 전용 쿼리에서 사용될 수 있음(EE에서만 제공하는 기능) - 단, secondary replica는 순수 복사본이기에 데이터 조작 및 인덱스 적용 등이 필요하다면 primary replica에서 수행해야 함
- Always On FCI
- FCI 공유 스토리지(디스크) 관련 추가 고려가 필요함
- primary 및 secondary에서 동일한 공유 디스크를 사용할 수 있어야 하기 때문에 FCI에서 사용하는 디스크가 다른 곳에 있도록 하려면 하드웨어 계층에서 스토리지 공급업체가 제공하는 기능 또는 Windows Server의 스토리지 복제본 사용과 같은 외적인 방법이 필요
- 로그 전달(Log shipping)
- log shipping은 가장 오래된 재해 복구 방법으로 AG 및 FCI와 함께 사용되면 비용 측면에서 효율적이며 상대적으로 간단한 재해 복구 방법을 제공함
[마이그레이션 및 업그레이드]
- 신규 인스턴스를 배포하거나 기존 인스턴스를 업그레이드할 때 업무가 오래 중단되는 상태는 지양되도록 가용성 기능을 사용하여 계획된 아키텍처 변경, 서버 전환, 플랫폼 변경, 패치 적용 등으로 인한 가동 중지 시간을 최소화하는 방법 필요
- Always On 가용성 그룹
- 전제: (하나 이상의) AG에 속하는 기존 인스턴스를 SQL Server 최신 버전으로 업그레이드 한다면!
- 신규 서버로 마이그레이션하면서 구성(운영체제/SQL Server 버전 등)은 변경하지 않는다면 해당 서버를 기존 기본 클러스터에 노드로 추가하고 AG에 추가 후 replica(s)가 정상 상태가 되면 신규 서버에 수동 failover를 수행할 수 있으며 이전 서버는 AG에서 제거하고 최종적으로 서비스를 해제할 수 있음
- 클러스터 유형이 'NONE'인 AG를 마이그레이션 및 업그레이드가 가능한데 AG 구성에서 클러스터 유형을 짜맞출 수 없으므로 모든 replica는 클러스터 유형이 'NONE'이어야만 함
- 분산형 AG를 사용하여 서로 다른 클러스터 유형으로 구성된 AG를 확장할 수 있음
- Always On FCI
- FCI는 자체적으로 기존 마이그레이션 또는 업그레이드를 지원할 수 없음
- 로그 전달(Log shipping)
- log shipping은 마이그레이션 및 업그레이드 수행 시 많이 사용되는 옵션
- 서버 전환 시 원본에서 모든 트래픽이 중단되면 최종 트랜잭션 로그를 가져와 복사하고 새 구성에 적용(백업/복원 기반) - 해당 시점에서 데이터베이스를 Online 상태로 만들 수 있음
- log shipping은 다른 가용성 작업 보다 전환 시간이 좀 더 소요될 수는 있으나 분 단위 정도의 차이로 측정됨
data