Azure SQL 데이터베이스의 고가용성

  • 아티클

적용 대상:Azure SQL Database

이 문서에서는 Azure SQL 데이터베이스의 고가용성 아키텍처에 대해 설명합니다.

개요

Azure SQL 데이터베이스의 고가용성 아키텍처의 목표는 서비스 기본 테넌트 작업 및 중단으로 인한 고객 워크로드에 미치는 영향을 최소화하는 것입니다. 다른 서비스 계층에 대한 특정 SLA에 대한 자세한 내용은 Azure SQL 데이터베이스용 SLA를 참조하세요.

SQL Database는 적용 가능한 모든 패치가 있는 Windows 운영 체제에서 안정적인 최신 버전의 SQL Server 데이터베이스 엔진 실행됩니다. SQL Database는 패치, 백업, Windows 및 SQL 엔진 업그레이드와 같은 중요한 서비스 작업과 기본 하드웨어, 소프트웨어 또는 네트워크 오류와 같은 계획되지 않은 이벤트를 자동으로 처리합니다. SQL Database 내 Elastic Pool 또는 데이터베이스가 패치되거나 장애 조치(failover)되면 앱에서 빈 재시도 논리를 사용하는 경우 가동 중지 시간은 일반적으로 크지 않습니다. SQL Database는 가장 심각한 상황에서도 신속한 복구가 가능하기 때문에 데이터를 항상 사용할 수 있습니다. 대부분의 사용자는 업그레이드가 지속적으로 수행된다는 사실을 알지 못합니다.

고가용성 솔루션은 커밋된 데이터가 오류로 인해 손실되지 않고, 유지 관리 작업이 워크로드에 영향을 주지 않으며, 데이터베이스가 소프트웨어 아키텍처에서 단일 실패 지점이 되지 않도록 설계되었습니다.

고가용성 아키텍처 모델 세 가지가 있습니다.

  • 원격 저장소 모델 - 컴퓨팅과 스토리지의 분리가 기반입니다. 원격 스토리지 계층의 고가용성 및 안정성을 기반으로 합니다. 이 아키텍처는 유지 관리 작업 중에 일부 성능 저하를 허용할 수 있는 예산 중심 비즈니스 애플리케이션을 대상으로 합니다.
  • 로컬 저장소 모델 - 데이터베이스 엔진 프로세스 클러스터가 기반입니다. 항상 사용 가능한 데이터베이스 엔진 노드의 쿼럼이 있다는 사실을 기반으로 합니다. 이 아키텍처는 높은 IO 성능, 높은 트랜잭션 속도를 갖춘 중요 업무용 애플리케이션을 대상으로 하며, 유지 관리 작업 중에 워크로드에 미치는 성능 영향을 최소화합니다.
  • 컴퓨팅 노드, 페이지 서버, 로그 서비스 및 영구 스토리지와 같은 고가용성 구성 요소의 분산 시스템을 사용하는 하이퍼스케일 모델 입니다. 하이퍼스케일 데이터베이스를 지원하는 각 구성 요소는 오류에 대한 자체 중복성 및 복원력을 제공합니다. 컴퓨팅 노드, 페이지 서버 및 로그 서비스는 각 구성 요소의 상태를 제어하고 필요에 따라 사용 가능한 정상 노드로 장애 조치를 수행하는 Azure Service Fabric에서 실행됩니다. 영구 스토리지는 네이티브 고가용성 및 중복 기능과 함께 Azure Storage를 사용합니다. 자세한 내용은 하이퍼스케일 아키텍처를 참조하세요.

세 가지 가용성 모델 내에서 SQL Database는 로컬 중복 및 영역 중복 옵션을 지원합니다. 로컬 중복성은 데이터 센터 내에서 복원력을 제공하는 반면 영역 중복은 지역 내 가용성 영역의 중단으로부터 보호하여 복원력을 더욱 향상시킵니다.

다음 표에서는 서비스 계층을 기반으로 하는 가용성 옵션을 보여 줍니다.

서비스 계층 고가용성 모드 로컬 중복 가용성 영역 중복 가용성
일반 용도 (vCore) 원격 스토리지 예 예
중요 비즈니스용 (vCore) 로컬 저장소 예 예
하이퍼스케일 (vCore) 하이퍼스케일 예 예
기본(DTU) 원격 스토리지 예 아니요
표준(DTU) 원격 스토리지 예 아니요
프리미엄(DTU) 로컬 저장소 예 예

로컬 중복 가용성

로컬 중복 가용성은 주 지역의 단일 데이터 센터 내에서 데이터를 세 번 복사하고 소규모 네트워크 또는 정전과 같은 로컬 오류 발생 시 데이터를 보호하는 LRS(로컬 중복 스토리지)에 데이터베이스를 저장하는 것을 기반으로 합니다. LRS는 가장 저렴한 중복성 옵션이며 다른 옵션에 비해 내구성이 가장 낮습니다. 지역 내에서 화재나 홍수와 같은 대규모 재해가 발생하면 LRS를 사용하는 스토리지 계정의 모든 복제본이 손실되거나 복구가 불가능할 수 있습니다. 따라서 로컬 중복 가용성 옵션을 사용할 때 데이터 보호를 더 강화하려면 데이터베이스 백업에 복원력이 더 뛰어난 스토리지 옵션을 사용하는 것이 좋습니다. 데이터 파일과 백업 모두에 동일한 스토리지가 사용되는 하이퍼스케일 데이터베이스에는 적용되지 않습니다.

로컬 중복 가용성은 데이터 손실의 양이 0임을 나타내는 모든 서비스 계층 및 RPO(복구 지점 목표)의 모든 데이터베이스에서 사용할 수 있습니다.

기본, 표준 및 범용 서비스 계층

기본, 표준 및 범용 서비스 계층은 원격 저장소 가용성 모델을 서버리스 컴퓨팅과 프로비전된 컴퓨팅 모두에 사용합니다. 다음 그림에서는 컴퓨팅 레이어와 스토리지 레이어가 분리된 서로 다른 4개의 노드를 보여 줍니다.

컴퓨팅 및 스토리지 분리를 보여 주는 다이어그램

원격 스토리지 가용성 모델에는 다음 두 개의 레이어가 포함됩니다.

  • 상태 비저장 컴퓨팅 레이어. 이 레이어는 데이터베이스 엔진 프로세스를 실행하고, 일시적이고 캐시된 데이터만 포함합니다(예: 연결된 SSD의 tempdb 및 model 데이터베이스, 메모리의 계획 캐시, 버퍼 풀 및 columnstore 풀). 이 상태 비저장 노드는 데이터베이스 엔진을 초기화하고, 노드 상태를 제어하며, 필요한 경우 다른 노드로 장애 조치(failover)를 수행하는 Azure Service Fabric을 통해 작동합니다.
  • 상태 저장 데이터 레이어 - Azure Blob Storage에 저장된 데이터베이스 파일(.mdf 및 .ldf)을 포함합니다. Azure Blob Storage에는 기본 제공되는 데이터 가용성 및 중복성 기능이 있습니다. 데이터베이스 엔진 프로세스 작동이 중단되더라도 로그 파일 또는 데이터 파일의 모든 레코드가 유지되도록 합니다.

데이터베이스 엔진 또는 운영 체제가 업그레이드되거나 오류가 검색될 때마다 Azure Service Fabric에서 상태 비저장 데이터베이스 엔진 프로세스를 사용 가능한 용량이 충분한 다른 상태 비저장 컴퓨팅 노드로 이동합니다. Azure Blob Storage의 데이터는 이동의 영향을 받지 않으며, 데이터/로그 파일은 새로 초기화된 데이터베이스 엔진 프로세스에 연결됩니다. 이 프로세스는 고가용성을 보장하지만 새 데이터베이스 엔진 프로세스가 콜드 캐시로 시작되므로 전환 중에 과도한 워크로드로 인해 성능이 약간 저하될 수 있습니다.

프리미엄 및 중요 비즈니스용 서비스 계층

프리미엄 및 중요 비즈니스용 서비스 계층은 단일 노드에서 컴퓨팅 리소스(프로세스)와 스토리지(로컬로 연결된 SSD)를 통합하는 프리미엄 가용성 모델을 사용합니다. 고가용성은 컴퓨팅과 스토리지를 모두 추가 노드에 복제하여 달성됩니다.

데이터베이스 엔진 노드 클러스터 다이어그램.

기본 데이터베이스 파일(.mdf/.ldf)은 연결된 SSD 스토리지에 배치되어 매우 짧은 대기 시간 IO를 워크로드에 제공합니다. 고가용성은 SQL Server Always On 가용성 그룹과 비슷한 기술을 사용하여 구현됩니다. 클러스터에는 읽기/쓰기 고객 워크로드에 액세스할 수 있는 단일 주 복제본 및 데이터 복사본을 포함하는 최대 3개의 보조 복제본(컴퓨팅 및 스토리지)이 포함됩니다. 주 복제본은 변경 내용을 순서대로 보조 복제본에 계속 푸시하여 각 트랜잭션을 커밋하기 전에 데이터가 충분한 수의 보조 복제본에서 지속되도록 보장합니다. 이 프로세스는 어떤 이유로든 주 복제본 또는 읽기 가능한 보조 복제본이 망가지면 항상 완전히 동기화된 복제본(replica)으로의 장애 조치(failover)를 보장합니다. 장애 조치(failover)는 Azure Service Fabric에서 시작됩니다. 보조 복제본이 새 주 복제본이 되면 클러스터에 쿼럼을 유지 관리하는 데 충분한 수의 복제본(replica)이 존재하도록 다른 보조 복제본이 생성됩니다. 장애 조치가 완료되면 Azure SQL 연결은 자동으로 새 기본 복제본 또는 읽기 가능한 보조 복제본으로 리디렉션됩니다.

추가 혜택으로 로컬 스토리지 가용성 모델에는 읽기 전용 Azure SQL 연결을 보조 복제본 중 하나로 리디렉션하는 기능이 포함됩니다. 이 기능을 읽기 스케일 아웃이라고 합니다. 주 복제본에서 분석 워크로드와 같은 읽기 전용 작업을 오프로드하기 위해 추가 비용 없이 100% 추가 컴퓨팅 용량을 제공합니다.

하이퍼스케일 서비스 계층

하이퍼스케일 서비스 계층 아키텍처는 분산 기능 아키텍처에 설명되어 있습니다.

하이퍼스케일 기능 아키텍처를 보여 주는 다이어그램.

하이퍼스케일의 가용성 모델에는 다음 4개의 레이어가 포함됩니다.

  • 데이터베이스 엔진 프로세스를 실행하는 상태 비저장 컴퓨팅 계층으로, 연결된 SSD에 비커버링 RBPEX 캐시, tempdb 및 model 데이터베이스 등 일시적이고 캐시된 데이터만 포함하며 메모리에 캐시, 버퍼 풀, 컬럼스토어 풀 등을 계획합니다. 이 상태 비저장 레이어에는 주 컴퓨팅 복제본 및 장애 조치(failover) 대상으로 사용할 수 있는 여러 선택적 보조 컴퓨팅 복제본이 포함됩니다.
  • 페이지 서버에서 구성된 상태 비저장 스토리지 레이어 - 이 계층은 컴퓨팅 복제본에서 실행되는 데이터베이스 엔진 프로세스를 위한 분산 스토리지 엔진입니다. 각 페이지 서버에는 연결된 SSD의 포함 RBPEX 캐시 및 메모리에 캐시된 데이터 페이지와 같은 일시적이고 캐시된 데이터만 포함됩니다. 각 페이지 서버에는 부하 분산, 중복성 및 고가용성을 제공하기 위해 활성-활성 구성으로 쌍을 이루는 페이지 서버가 있습니다.
  • 상태 저장 트랜잭션 로그 스토리지 레이어 - 로그 서비스 프로세스를 실행하는 컴퓨팅 노드, 트랜잭션 로그 랜딩 존 및 트랜잭션 로그 장기 스토리지로 구성됩니다. 랜딩 존 및 장기 스토리지는 트랜잭션 로그에 대한 가용성과 중복도를 제공하는 Azure Storage를 사용하여 커밋된 트랜잭션에 대한 데이터 내구성을 보장합니다.
  • 상태 저장 데이터 스토리지 레이어 - Azure Storage에 저장되고 페이지 서버에서 업데이트되는 데이터베이스 파일(.mdf/.ndf)을 포함합니다. 이 레이어는 Azure Storage의 데이터 가용성 및 중복성 기능을 사용합니다. 이는 하이퍼스케일 아키텍처의 다른 레이어에 있는 프로세스가 중단되거나 컴퓨팅 노드가 실패하는 경우에도 데이터 파일의 모든 페이지가 유지되도록 보장합니다.

모든 하이퍼스케일 레이어의 컴퓨팅 노드는 각 노드의 상태를 제어하고 필요에 따라 사용 가능한 정상 노드에 대한 장애 조치(failover)를 수행하는 Azure Service Fabric에서 실행됩니다.

하이퍼스케일의 고가용성에 대한 자세한 내용은 하이퍼스케일의 데이터베이스 고가용성을 참조하세요.

영역 중복 가용성

영역 중복 가용성은 데이터가 주 지역의 세 Azure 가용성 영역에 분산되도록 합니다. 각 가용성 영역은 독립적인 전원, 냉각 및 네트워킹을 갖춘 별도의 물리적 위치입니다.

영역 중복 가용성은 DTU 기반 구매 모델의 기본 및 표준 서비스 계층이 아니라 vCore 구매 모델의 프리미엄, 중요 비즈니스용, 범용 및 하이퍼스케일 서비스 계층의 데이터베이스에서 사용할 수 있습니다. 각 서비스 계층은 영역 중복 가용성을 다르게 구현합니다. 다음 섹션에서 각 서비스 계층에 대한 세부 정보를 참조하세요. 모든 구현은 장애 조치(failover) 시 커밋된 데이터 손실이 없는 RPO(복구 지점 목표)를 보장합니다.

범용 서비스 계층

범용 서비스 계층에 대한 영역 중복 구성은 vCore 구매 모델의 데이터베이스에 대한 서버리스 및 프로비저닝된 컴퓨팅 모두에 제공됩니다. 이 구성은 Azure 가용성 영역을 활용하여 Azure 지역 내의 여러 물리적 위치에서 데이터베이스를 복제합니다. 영역 중복도를 선택하면 애플리케이션 로직을 변경하지 않고도 신규 및 기존 서버리스 및 프로비전된 단일 범용 데이터베이스 및 탄력적 풀을 훨씬 더 큰 오류 집합(심각한 데이터 센터 중단 포함)으로 복원할 수 있습니다.

범용 계층에 대한 영역 중복 구성에는 다음 두 개의 레이어가 있습니다.

  • ZRS(영역 중복 스토리지)에 저장된 데이터베이스 파일(.mdf/.ldf)을 포함한 상태 저장 데이터 레이어. ZRS를 사용하면 데이터 및 로그 파일이 물리적으로 격리된 세 개의 Azure 가용성 영역에 동기적으로 복사됩니다.
  • 상태 비저장 컴퓨팅 레이어 - sqlservr.exe 프로세스를 실행하고, 일시적이고 캐시된 데이터만 포함합니다(예: 연결된 SSD의 tempdb 및 model 데이터베이스, 메모리의 계획 캐시, 버퍼 풀 및 columnstore 풀). 이 상태 비저장 노드는 sqlservr.exe를 초기화하고, 노드 상태를 제어하며, 필요한 경우 다른 노드로 장애 조치(failover)를 수행하는 Azure Service Fabric을 통해 작동합니다. 영역 중복 서버리스 및 프로비저닝된 범용 데이터베이스의 경우 장애 조치(failover)를 위해 여유 용량이 있는 노드를 다른 가용성 영역에서 쉽게 사용할 수 있습니다.

다음 다이어그램에서는 범용 서비스 계층에 대한 고가용성 아키텍처의 영역 중복 버전을 보여 줍니다.

범용 서비스 계층에 대한 영역 중복 구성

영역 중복을 사용하여 범용 데이터베이스를 구성할 때 다음을 고려합니다.

  • 범용 계층의 경우 영역 중복 구성은 일반적으로 다음 지역에서 사용할 수 있습니다:
    • (아프리카) 남아프리카 북부
    • (아시아 태평양) 오스트레일리아 동부
    • (아시아 태평양) 동아시아
    • (아시아 태평양) 일본 동부
    • (아시아 태평양) 한국 중부
    • (아시아 태평양) 동남 아시아
    • (아시아 태평양) 인도 중부
    • (아시아 태평양) 중국 북부 3
    • (아시아 태평양) 아랍에미리트 북부
    • (유럽) 프랑스 중부
    • (유럽) 독일 중서부
    • (유럽) 이탈리아 북부
    • (유럽) 북유럽
    • (유럽) 노르웨이 동부
    • (유럽) 폴란드 중부
    • (유럽) 서유럽
    • (유럽) 영국 남부
    • (유럽) 스위스 북부
    • (유럽) 스웨덴 중부
    • (중동) 이스라엘 중부
    • (중동) 카타르 중부
    • (북아메리카) 캐나다 중부
    • (북아메리카) 미국 동부
    • (북아메리카) 미국 동부 2
    • (북아메리카) 미국 중남부
    • (북아메리카) 미국 서부 2
    • (북아메리카) 미국 서부 3
    • (남미) 브라질 남부
  • 영역 중복 가용성의 경우 기본값 이외의 유지 관리 기간을 선택하는 것은 현재 일부 지역에서 사용할 수 있습니다.
  • 영역 중복 구성은 표준 시리즈(Gen5) 하드웨어를 선택한 경우에만 SQL 데이터베이스에서 사용할 수 있습니다.
  • DTU 구매 모델 중 기본 및 표준 서비스 계층에서는 영역 중복을 사용할 수 없습니다.

프리미엄 및 중요 비즈니스용 서비스 계층

프리미엄 또는 중요 비즈니스용 서비스 계층에 대해 영역 중복성을 사용하도록 설정하면 복제본(replica)이 동일한 지역의 서로 다른 여러 가용성 영역에 배치됩니다. 단일 실패 지점을 제거하기 위해 제어 링은 세 개의 GW(게이트웨이 링)로 여러 영역에 걸쳐 복제됩니다. 특정 게이트웨이 링에 대한 라우팅은 Azure Traffic Manager에서 제어됩니다. 프리미엄 또는 중요 비즈니스용 서비스 계층의 영역 중복 구성은 기존 복제본(replica)을 사용하여 다양한 가용성 영역에 배치하므로 추가 비용 없이 사용할 수 있습니다. 영역 중복 구성을 선택하면 애플리케이션 로직을 변경하지 않고도 치명적인 데이터센터 중단을 비롯한 훨씬 더 큰 규모의 장애에도 프리미엄 또는 중요 비즈닛스용 데이터베이스와 Elastic Pool을 탄력적으로 복구할 수 있습니다. 기존 프리미엄 또는 중요 비즈니스용 데이터베이스 또는 Elastic Pool을 영역 중복 구성으로 변환할 수도 있습니다.

다음 다이어그램에서는 고가용성 아키텍처의 영역 중복 버전을 보여줍니다.

영역 중복 고가용성 아키텍처 다이어그램.

영역 중복성을 사용하여 프리미엄 또는 중요 비즈니스용 데이터베이스를 구성할 때 다음을 고려합니다.

하이퍼스케일 서비스 계층

하이퍼스케일 서비스 계층의 데이터베이스에 대한 영역 중복성을 구성할 수 있습니다. 자세히 알아보려면 영역 중복 하이퍼스케일 데이터베이스 만들기를 참조하세요.

이 구성을 사용하도록 설정하면 모든 하이퍼스케일 계층에 대한 가용성 영역 간 복제를 통해 영역 수준의 복원력이 보장됩니다. 영역 중복성을 선택하면 애플리케이션 로직을 변경하지 않고도 치명적인 데이터 센터 중단을 포함하여 훨씬 더 큰 오류 집합에 대해 하이퍼스케일 데이터베이스를 복원할 수 있습니다. 가용성 영역이 있는 모든 Azure 지역은 영역 중복 하이퍼스케일 데이터베이스를 지원합니다.

영역 중복 가용성은 하이퍼스케일 독립 실행형 데이터베이스와 하이퍼스케일 Elastic Pool 모두에서 지원됩니다. 자세한 내용은 하이퍼스케일 Elastic Pool을 참조하세요.

다음 다이어그램에서는 영역 중복 하이퍼스케일 데이터베이스의 기본 아키텍처를 보여 줍니다.

영역 중복 하이퍼스케일 데이터베이스의 기본 아키텍처를 보여주는 다이어그램

다음 제한 사항을 고려하세요.

  • 영역 중복 구성은 데이터베이스 만들기 중에만 지정할 수 있습니다. 리소스가 프로비전되면 이 설정을 수정할 수 없습니다. 데이터베이스 복사, 특정 시점 복원을 사용하거나 지역 복제본을 만들어 기존 하이퍼스케일 데이터베이스의 영역 중복 구성을 업데이트합니다. 이러한 업데이트 옵션 중 하나를 사용할 때 대상 데이터베이스가 원본과 다른 지역에 있거나 대상의 데이터베이스 백업 스토리지 중복성이 원본 데이터베이스와 다른 경우 복사 작업은 데이터 작업의 크기가 됩니다.

  • 영역 중복 가용성의 경우 기본값 이외의 유지 관리 기간을 선택하는 것은 현재 일부 지역에서 사용할 수 있습니다.

  • 현재 Azure Portal을 사용하여 데이터베이스를 하이퍼스케일로 마이그레이션할 때 영역 중복성을 지정하는 옵션은 없습니다. 그러나 다른 Azure SQL 데이터베이스 서비스 티어에서 하이퍼스케일로 기존 데이터베이스를 마이그레이션할 때 Azure PowerShell, Azure CLI 또는 REST API를 사용하여 영역 중복성을 지정할 수 있습니다. 다음은 Azure CLI 사용 예입니다.

    az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true

  • 하이퍼스케일에 대한 영역 중복 구성을 사용하도록 설정하려면 하나 이상의 고가용성 컴퓨팅 복제본과 영역 중복 또는 지역 영역 중복 백업 스토리지를 사용해야 합니다.

데이터베이스 영역 중복 가용성

Azure SQL Database에서 서버는 데이터베이스 컬렉션에 대한 중앙 관리 지점 역할을 하는 논리적 구문입니다. 서버 수준에서 로그인, 인증 방법, 방화벽 규칙, 감사 규칙, 위협 탐지 정책 및 장애 조치(failover) 그룹을 관리할 수 있습니다. 로그인 및 방화벽 규칙과 같은 이러한 기능 중 일부와 관련된 데이터는 master 데이터베이스에 저장됩니다. 마찬가지로 일부 DMV의 데이터(예: sys.resource_stats)도 master 데이터베이스에 저장됩니다.

영역 중복 구성이 있는 데이터베이스가 논리 서버에 만들어지면 서버와 연결된 master 데이터베이스도 자동으로 영역 중복으로 만들어집니다. 이렇게 하면 영역 중단 시 로그인 및 방화벽 규칙과 같은 master 데이터베이스에 종속된 기능을 계속 사용할 수 있기 때문에 데이터베이스를 사용하는 애플리케이션은 영향을 받지 않습니다. master 데이터베이스 영역 중복을 만드는 것은 비동기 프로세스이며 백그라운드에서 완료하는 데 다소 시간이 걸립니다.

서버의 데이터베이스 중 어떤 것도 영역 중복이 아니거나 빈 서버를 만든 경우 서버와 연결된 master 데이터베이스가 영역 중복이 아닙니다.

Azure PowerShell, Azure CLI 또는 REST API를 사용하여 master 데이터베이스에 대한 ZoneRedundant 속성을 확인할 수 있습니다.

다음 예제 명령을 사용하여 master 데이터베이스에 대한 “ZoneRedundant” 속성 값을 확인합니다.

Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"

애플리케이션 오류 복원력 테스트

고가용성은 데이터베이스 애플리케이션에 대해 투명하게 작동하는 SQL Database 플랫폼의 기본 부분입니다. 그러나 애플리케이션을 프로덕션 환경에 배포하기 전에 계획되거나 계획되지 않은 이벤트 중에 시작된 자동 장애 조치(failover) 작업이 애플리케이션에 어떤 영향을 미치는지 테스트해보고 싶을 수 있습니다. 특수 API를 호출하여 데이터베이스 또는 Elastic Pool을 다시 시작하여 수동으로 장애 조치(failover)를 트리거할 수 있습니다. 영역 중복 서버리스 또는 프로비전된 범용 데이터베이스 또는 탄력적 풀의 경우 API 호출로 인해 클라이언트 연결이 이전 주 데이터베이스의 가용성 영역과 다른 가용성 영역의 새 주 데이터베이스로 리디렉션됩니다. 따라서 장애 조치(failover)에서 기존 데이터베이스 세션에 미치는 영향을 테스트하는 것 외에도 네트워크 대기 시간의 변경으로 인해 엔드투엔드 성능이 변경되는지도 확인할 수 있습니다. 재시작 작업은 방해가 되고 많은 수의 작업이 플랫폼에 스트레스를 줄 수 있으므로 각 데이터베이스 또는 탄력적 풀에 대해 15분마다 장애 조치(failover) 호출을 한 번만 허용합니다.

Azure SQL 데이터베이스 고가용성 및 재해 복구에 대한 자세한 내용은 HA/DR 체크리스트를 검토토하세요.

장애 조치(failover)는 PowerShell, REST API 또는 Azure CLI를 사용하여 시작할 수 있습니다.

배포 유형 PowerShell REST API Azure CLI
데이터베이스 Invoke-AzSqlDatabaseFailover 데이터베이스 장애 조치(failover) az rest를 사용하여 Azure CLI에서 REST API 호출이 가능합니다
탄력적 풀 Invoke-AzSqlElasticPoolFailover 탄력적 풀 장애 조치(failover) az rest를 사용하여 Azure CLI에서 REST API 호출이 가능합니다

Important

장애 조치(failover) 명령은 하이퍼스케일 데이터베이스의 읽기 가능한 보조 복제본에 사용할 수 없습니다.

결론

Azure SQL 데이터베이스는 Azure 플랫폼과 긴밀하게 통합되는 기본 제공 고가용성 솔루션을 제공합니다. 장애 감지 및 복구를 위한 Service Fabric, 데이터 보호를 위한 Azure Blob 스토리지, 더 높은 내결함성을 위한 가용성 영역에 의존합니다. 또한 SQL Database는 데이터 동기화 및 장애 조치(failover)를 위해 SQL Server의 Always On 가용성 그룹 기술을 사용합니다. 이러한 기술의 조합을 통해 애플리케이션에서 혼합 스토리지 모델의 이점을 완전히 실현하고 요구 사항이 가장 많은 SLA를 지원할 수 있습니다.

관련 콘텐츠