[출처] SQL Server의 고가용성 (1) ---- 고가용성에 대한 개요

SQL Server 2005 이후, 마이크로소프트는 다운타임을 줄이고 비즈니스 데이터 보호를 강화하기 위해 다양한 고가용성 기술을 제공해 왔으며, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012의 지속적인 출시와 함께 다양한 시나리오에 대응할 수 있는 다양한 고가용성 기술이 SQL Server에 탑재되었습니다.

    이 글을 시작하기 전에, 어떤 고가용성 기술을 사용할지 결정하는 요인에 대해 간략히 개요부터 시작하겠습니다.

    많은 기업들이 데이터 전부 또는 일부를 매우 쉽게 활용할 수 있어야 합니다. 예를 들어 온라인 쇼핑 웹사이트, 온라인 제품 데이터베이스는 24시간 온라인 상태로 유지되어야 합니다. 그렇지 않으면 경쟁이 치열한 시장 환경에서 다운타임이 고객 손실과 수익을 의미합니다. 예를 들어, SQL Server에 의존하는 콜센터에서는 데이터베이스가 다운되면 모든 전화자가 고객에게 "죄송합니다, 시스템 오류"라고 답할 수밖에 없는데, 이것도 용납할 수 없습니다.

    물론 이상적인 세상에서는 모든 중요한 데이터가 항상 온라인 상태여야 하지만, 현실에서는 재해의 시기와 형태를 예측할 수 없기 때문에 데이터베이스가 사용할 수 없는 여러 이유가 있을 것입니다. 그래서 다양한 비상 상황을 예방하기 위해 사전에 조치를 취해야 하기 때문입니다. 그래서 SQL Server는 다양한 고가용성 기술을 제공합니다. 이 기술들은 주로 클러스터링, 복제, 미러링, 로그 전달, AlwaysOn 가용성 그룹 및 파일 그룹 백업 및 복원 등을 포함합니다. 온라인 재구성 인덱스와 같은 단일 인스턴스 고가용성 기술. 고가용성 기술의 사용은 직접 사용할 익숙한 기술을 선택하는 것이 아니라, 비즈니스와 기술을 포괄적으로 고려하는 것입니다. 모든 기능을 모두 달성할 수 있는 단일 기술은 없기 때문입니다. 특정 비즈니스와 예산에 따라 이러한 기술을 어떻게 도입할지는 고가용성 전략(High availability strategy)이라고 알려져 있습니다.

고가용성 전략을 설계할 때는 먼저 다음 요소들을 고려해야 합니다:

• RTO(복구 시간 목표) - 즉, 복구 시간 목표는 허용되는 다운타임 양을 의미하며, 보통 몇 개의 9로 표현됩니다. 예를 들어, 99.999% 가용성은 연간 최대 5분 다운타임, 99.99% 가용성은 연간 최대 52.5분 다운타임, 99.9% 가용성은 연간 최대 8.75시간 다운타임을 의미합니다. RTO의 계산 방법은 시스템이 24시간 365일 운영되는지, 아니면 오전 6시부터 오후 9시까지인지도 고려한다는 점이 주목할 만합니다. 또한 유지보수 기간이 다운타임으로 인정되는지 주의해야 하며, 유지보수 기간 동안 데이터베이스 유지보수와 패치를 허용하면 더 높은 가용성을 달성하기 쉽습니다.
• RPO(복구 지점 목표) – 복구 지점 목표라고도 하며, 허용되는 데이터 손실의 양을 의미합니다. 보통 잘 백업만 하면 데이터 손실 없이 쉽게 달성할 수 있습니다. 하지만 재난이 발생하면, 데이터베이스 손상 정도에 따라 백업에서 데이터를 복원하는 데 걸리는 시간이 데이터베이스를 사용할 수 없게 되어 RTO 구현에 영향을 미칩니다. 초기이자 더 유명한 예로는 유럽과 미국의 은행 시스템이 있는데, RPO만 고려하면 시스템 내에 완전한 백업과 로그 백업만 있고, 3개월마다 완전 백업, 15분마다 로그 백업이 있습니다. 재난 발생 시 완전 백업과 로그 백업을 통해서만 데이터를 복구할 수 있습니다. 데이터 손실은 없지만 복구에 이틀이 걸려 은행 시스템이 2일 동안 사용 불가능해 많은 고객이 손실되었습니다. 또 다른 반대 예로는 국내 온라인 비디오 웹사이트가 있는데, SQL Server를 백엔드 관계형 데이터베이스로 사용하고, 프론트엔드는 No-SQL을 사용하며, 백업용으로 정기적으로 No-SQL 데이터를 관계형 데이터베이스로 가져오는 경우가 있습니다.
  

    예산 – RTO와 RPO는 통칭하여 SLA(서비스 수준 계약)라고 하며, 고가용성 전략을 설계할 때는 비즈니스 예산에 따라 SLA를 얼마나 잘 준수하는지, 그리고 실패 시 다양한 SLA의 비용을 측정해야 합니다. 일반적으로 제한된 예산으로 높은 SLA를 달성하는 것은 어렵고, 복잡한 아키텍처를 통해 높은 SLA를 달성하더라도 복잡한 아키텍처는 높은 운영 및 유지보수 비용을 의미하므로 SLA를 충족하기 위해 예산 내에서 적절한 기술을 선택하는 것이 필요합니다.

따라서 일반적으로 고가용성의 큰 프레임워크는 여러 주문 수용 질문으로 결정할 수 있습니다:

• 주주들이 기꺼이 수용하는 다운타임은 어느 정도인가요?
• 관리자에게 허용되는 휴식 시간은 어느 정도인가요?
• 고가용성 시나리오에 대해 제공되는 예산은 얼마인가요?
• 다운타임으로 인한 시간당 손실은 얼마나 되나요?
  

• 콜드 백업: 대기 서버는 기본 서버의 데이터를 받도록 설정되어 있으며, 실패할 경우 수동으로 데이터를 주 데이터베이스로 복원하거나 프로그램의 연결 문자열이나 권한을 재구성하여 백업 데이터베이스를 온라인으로 전환합니다.
• 웜 백업: 주 서버 데이터는 백업 서버에 로그를 지속적으로 전송하며(15분, 30분, 1분 등 불규칙한 간격으로), 이로 인해 주 서버와 백업 서버는 보통 비동기적으로 업데이트되므로 주 서버와 백업 서버의 데이터가 보장되지 않습니다. 또한, 이 방식은 일반적으로 자동 결함 모니터링 및 장애 전환을 구현하지 않습니다.
• 핫 백업: 주 서버의 데이터가 자동으로 백업 서버에 동기화되며, 대부분의 경우 자동 장애 모니터링과 장애 조치가 포함되어 주 서버와 백업 서버의 데이터 일관성을 보장할 수 있습니다.
  

    차가운 곳에서 따뜻한 곳, 더운 백업으로 비용이 급등합니다.

    SQL Server에서 지원하는 고가용성 기능은 버전과 밀접하게 관련되어 있으며, 엔터프라이즈 에디션은 다음을 포함한 모든 고가용성 기능을 지원합니다:

• 장애 전환 클러스터
• l 데이터베이스 이미지
• l 거래 기록 전송
• l 데이터베이스 스냅샷
• l 고가용성 업그레이드
• l 핫로드 메모리
• l 온라인 색인 작업
• l 데이터베이스 부분 온라인 (마스터 파일 그룹 또는 마스터 파일 그룹 및 추가 NDF 파일만 복원됨)
  

    고가용성 기능의 구체적인 버전은 다음을 참조하세요:http://msdn.microsoft.com/zh-cn/library/cc645993.aspx무료 Express 버전은 데이터베이스 미러링의 증인 서버 역할을 할 수 있어 비용 절감 효과가 있다는 점도 주목할 만합니다.

장애 전환 클러스터

    장애 시 클러스터는 SQL Server 인스턴스 전체에 대해 고가용성 지원을 제공하여, 클러스터 내 노드에 있는 SQL Server 인스턴스가 하드웨어 오류, 운영체제 오류 등으로 인해 클러스터 내 다른 노드로 페일오버됩니다. 고가용성은 여러 서버(노드)가 하나 이상의 디스크를 공유함으로써 달성되며, 장애 전환 클러스터는 단일 컴퓨터와 동일한 방식으로 네트워크에 나타나지만 고가용성 특성을 가집니다. 장애 전환 클러스터가 공유 디스크를 기반으로 하기 때문에 디스크 장애가 단일 지점에 존재하므로 SAN 복제와 같은 추가 보호 장치가 디스크 수준에서 배포되어야 한다는 점을 유념해야 합니다. 가장 일반적인 장애 전환 클러스터는 마스터와 슬레이브를 포함한 2노드 장애 지점 클러스터입니다.

트랜잭션 로그 전송

    트랜잭션 로그 전송은 데이터베이스 수준의 고가용성 보호를 제공합니다. 로깅은 해당 생산 데이터베이스('기본 데이터베이스'라고 부름)의 하나 이상의 대기 데이터베이스('보조 데이터베이스'라고 불림)를 유지하는 데 사용됩니다. 장애 조치가 발생하기 전에, 모든 복원되지 않은 로그 백업을 수동으로 적용하여 보조 데이터베이스를 완전히 업데이트해야 합니다. 로그 전달은 여러 대기 데이터베이스를 지원할 수 있는 유연성을 갖추고 있습니다. 여러 대체 데이터베이스가 필요할 경우, 로그 전달은 별도로 또는 데이터베이스 미러링의 보완으로 사용할 수 있습니다. 이 솔루션들이 함께 사용될 때, 현재 데이터베이스 미러링 구성의 주 데이터베이스가 현재 로그 전송 구성의 주 데이터베이스가 됩니다.

    트랜잭션 로그 전달은 콜드 백업과 웜 백업을 수행하는 데 사용할 수 있습니다.

데이터베이스 미러링

    데이터베이스 미러링은 사실 데이터베이스 수준의 보호를 제공하는 소프트웨어 솔루션으로, 데이터베이스 가용성을 개선하기 위해 거의 즉각적인 장애 조치(fail-over)를 제공합니다. 데이터베이스 미러는 해당 생산 데이터베이스('주 데이터베이스'라고 불림)를 위한 단일 대기 데이터베이스(또는 '미러 데이터베이스')를 유지하는 데 사용할 수 있습니다.
미러 데이터베이스는 항상 복원 상태이지만, 데이터베이스는 복원되지 않기 때문에 미러 데이터베이스에 직접 접근할 수 없습니다. 하지만 보고서와 같은 읽기 전용 로드의 경우, 미러된 데이터베이스의 데이터베이스 스냅샷을 생성하여 간접적으로 사용할 수 있습니다. 데이터베이스 스냅샷은 스냅샷이 생성될 때 클라이언트가 데이터베이스 내 데이터에 읽기 전용 접근을 제공합니다. 각 데이터베이스 미러링 구성에는 주된 데이터베이스를 포함하는 "주된 서버"와, 미러된 데이터베이스를 포함하는 미러 서버가 포함됩니다. 미러 서버는 메인 데이터베이스와 함께 미러 데이터베이스를 지속적으로 업데이트합니다.
    데이터베이스 미러링은 고보안 모드에서 동기식 동작으로, 고성능 모드에서 비동기식 동작으로 동작합니다. 고성능 모드에서는 트랜잭션이 미러 서버가 로그를 디스크에 쓰기를 기다릴 필요가 없어 성능을 극대화할 수 있습니다. 고보안 모드에서는 커밋된 트랜잭션이 양 파트너 모두가 커밋되지만, 트랜잭션 지연 시간이 길어집니다. 데이터베이스 미러링의 가장 단순한 구성은 주 서버와 미러 서버만 포함합니다. 이 구성에서는 메인 서버가 손실되면 미러 서버를 대기 서버로 사용할 수 있지만, 데이터 손실을 초래할 수 있습니다. 고보안 모드는 자동 장애 조치가 있는 대기 모드 고보안 구성을 지원합니다. 이 구성은 "증인 서버"라 불리는 제3자 서버 인스턴스를 포함하며, 이를 통해 미러 서버를 핫 백업 서버로 사용할 수 있게 합니다. 기본 데이터베이스에서 미러 데이터베이스로의 장애 조치는 보통 몇 초가 소요됩니다.

    데이터베이스 미러링은 웜 백업과 핫 백업 모두에 사용할 수 있습니다.

복사

    복제는 엄밀히 말해 고가용성을 위한 기능은 아니지만, 고가용성에 적용할 수 있습니다. 복제는 데이터베이스 객체 수준 보호를 제공합니다. 복제는 게시-구독 모델을 사용하며, 이는 주 서버인 출판사가 데이터를 하나 이상의 보조 또는 구독자에게 게시하는 방식입니다. 복제는 이들 서버 간에 실시간 가용성과 확장성을 제공합니다. 구독자에게 일부 데이터를 제공하는 필터링을 지원하며, 파티션 업데이트도 지원합니다. 가입자는 온라인 상태이며 쿼리 복구 없이 보고나 기타 기능에 사용할 수 있습니다. SQL Server는 네 가지 복제 유형을 제공합니다: 스냅샷 복제, 트랜잭션 복제, 피어 투 피어 복제, 병합 복제.

항상 온사용성 그룹

    AlwaysOn 가용성 그룹은 SQL Server 2012에서 도입된 새로운 기능입니다. 데이터베이스 수준의 보호도 제공됩니다. 또한 데이터베이스 미러링이 1:1로만 가능하다는 한계를 확장하여, 하나의 주 복제본이 최대 4개의 보조 복제본에 대응할 수 있습니다(SQL Server 2014에서는 이 제한이 8개로 확장됨), 이 중 2개의 보조 복제본은 실시간으로 핫 백업과 주 복제본으로 동기화할 수 있고, 나머지 두 개의 비동기 보조 복제본은 웜 백업으로 사용할 수 있습니다. 또한, 보조 복제본은 읽기 전용으로 구성할 수 있어 백업 부하를 감당하는 데 사용할 수 있습니다.

    이 때문에 SQL Server 2012에서는 데이터베이스 미러링이 "구식"으로 표시되어 있습니다.

    SQL Server에서 제공하는 고가용성의 기본 개념과 고가용성 기술을 이해한 후, 이제 고가용성 전략 설계를 살펴보겠습니다. 고가용성 전략 계획은 네 단계로 나눌 수 있습니다:

요구 사항 수집

    고가용성 전략을 결정하는 첫 번째 단계는 분명히 SLA를 설정하기 위한 비즈니스 요구사항을 수집하는 것입니다. RTO와 RPO는 가장 중요한 부분이며, 이를 바탕으로 현실적인 가용성 요구사항에 대한 기대치를 설정하고 이를 바탕으로 현실적인 고가용성 전략을 수립해야 합니다.

평가 한도

    평가 한계는 SQL Server의 다양한 고가용성 기술의 한계뿐만 아니라 비기술적인 기술에도 국한됩니다. 예산이 수만 위안밖에 안 되는데도 오프사이트 데이터 센터와 SAN 복제를 기반으로 한 고가용성 솔루션을 만들고 싶다면, 이는 분명 어리석은 꿈일 것입니다. 또 다른 비기술적 한계는 운영 인력의 수준이며, 복잡한 아키텍처는 종종 더 숙련된 운영 인력을 의미합니다. 기타 비기술적 제한으로는 데이터 센터 내 디스크 공간 가용성, 전원 공급 및 에어컨이 요구를 충족할 수 있는지, 가용성 전략 구현에 필요한 시간 등이 있습니다.

    기술적 한계로는 다양한 고가용성 기능과 제한, 서로 다른 SQL Server 버전에서 지원하는 기능, CPU 수, 메모리 크기 등이 있습니다. 고가용성 정책을 구현하기 전에 Microsoft MSDN 웹사이트의 다양한 SQL Server 버전과 기능의 한계를 먼저 참고하시길 강력히 권장합니다.

선택 기술

    요구사항을 수집하고 제약 조건을 평가한 후, 다음 단계는 이 글 앞서 설명한 기술 또는 기술 조합을 선택하여 SLA 요구사항을 충족하는 것입니다. 선택한 기술이 SLA를 충족하지 못할 경우, SLA를 충족하지 못하는 제한 사항을 쉽게 보고하여 누락된 자원을 요청하거나 SLA를 타협할 수 있습니다.

테스트, 검증, 문서화

    고가용성 정책은 처음부터 엄격한 테스트와 검증을 거쳐야 현재 가용성 정책이 SLA를 충족하는지 확인해야 합니다. 하지만 고가용성 전략이 시작될 때는 데이터 증가, 비즈니스 또는 요구사항 변화에도 불구하고 현재 정책이 여전히 SLA를 충족할 수 있는지 정기적으로 테스트하고 검증하는 것이 필요합니다. 동시에, 가용성 솔루션의 구성, 장애 조치 방법, 재해 복구 계획은 실패 발생 시 추적할 수 있도록 문서화되어야 합니다.

이 글에서는 고가용성의 기본 개념, SLA 개념, SQL Server에서 지원하는 다양한 고가용성 기능, 그리고 고가용성 전략을 설계하는 데 필요한 단계를 설명합니다. 이 글에서는 데이터베이스 수준의 고가용성만을 다루지만, 고가용성은 DBA만의 문제일 뿐만 아니라 시스템 운영 및 유지보수 인력, 네트워크 관리자, 개발자, 관리자 등 다양한 역할의 협력을 포함해 SLA를 더 잘 준수해야 한다는 점을 주목할 필요가 있습니다.