Azure SQL Managed Instance의 고가용성

적용 대상:Azure SQL Managed Instance

이 문서에서는 Azure SQL Managed Instance 고가용성을 설명합니다.

Important

영역 중복 구성의 경우 범용 서비스 계층에서는 공개 미리 보기로 제공되며 중요 비즈니스용 서비스 계층에서는 일반 공급으로 제공됩니다.

개요

Azure SQL Managed Instance에서 고가용성 아키텍처의 목표는 짧은 가동 중지 시간, 서비스 유지 관리 작업 및 계획되지 않은 가동 중단으로 인해 발생하는 고객이 시작한 관리 작업이 고객 워크로드에 미치는 영향을 최소화하는 것입니다. 다른 서비스 계층의 특정 SLA에 대한 자세한 내용은 Azure SQL Managed Instance를 검토하세요.

고가용성을 통해 다음 사항에 미치는 영향으로부터 보호할 수 있습니다.

  • 데이터 센터를 구성하는 가용성 영역(다중 영역 리전인 경우).
  • 서비스에 전원을 공급하는 노드가 실행되는 랙
  • 노드 자체
  • 애플리케이션 레이어

지역 가동 중단 또는 더 큰 규모의 가동 중단인 경우 영향을 최소화하기 위해 비즈니스 연속성 개요에서 루는 사용 가능한 기술 중 하나를 사용할 수 있습니다.

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

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

서비스 계층에 따라 두 가지 고가용성 아키텍처 모델이 있습니다.

  • 원격 저장소 모델원격 스토리지의 고가용성 및 안정성과 Azure Service Fabric에서 관리하는 컴퓨팅 클러스터의 고가용성에 의존하는 범용 서비스 계층차세대 범용 서비스 계층의 컴퓨팅 및 스토리지 분리에 기반합니다. 이 고가용성 모델은 유지 관리 작업 중에 일부 성능 저하를 허용할 수 있는 예산 중심 비즈니스 애플리케이션을 대상으로 합니다.
  • 로컬 스토리지 모델은 로컬 스토리지가 있는 중요 비즈니스용 서비스 계층에서 사용 가능한 데이터베이스 엔진 노드의 쿼럼에 의존하는 데이터베이스 엔진 프로세스의 클러스터에 기반합니다. 이 로컬 스토리지 모델은 트랜잭션 속도가 높고 높은 IO 성능을 요구하는 중요 업무용 애플리케이션을 대상으로 합니다. 고가용성 아키텍처는 유지 관리 활동 중에 워크로드에 미치는 영향을 최소화하도록 보장합니다.

로컬 중복 가용성

로컬 중복 가용성은 주 지역의 단일 데이터 센터 내 컴퓨팅 노드 및 데이터를 저장하는 방식에 기반하며, 소규모 네트워크 또는 정전 장애와 같은 로컬 장애 발생 시 데이터를 보호합니다. 지역 내에서 화재나 홍수와 같은 대규모 재해가 발생하는 경우 컴퓨팅 노드의 스토리지 계정이나 데이터의 모든 복제본(replica)이 손실되거나 복구할 수 없게 될 수 있습니다. 따라서 로컬 중복 가용성 옵션을 사용할 때 데이터 보호를 더 강화하려면 데이터베이스 백업에 복원력이 더 뛰어난 스토리지 옵션을 사용하는 것이 좋습니다.

범용 서비스 계층

범용 서비스 계층은 원격 저장소 가용성 아키텍처를 사용합니다. 다음 그림에서는 컴퓨팅 레이어와 스토리지 레이어가 분리된 서로 다른 4개의 노드를 보여줍니다.

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

원격 저장소 가용성 모델에는 다음 두 개의 레이어가 포함됩니다.

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

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

차세대 범용 서비스 계층

참고 항목

차세대 범용 서비스 계층 업그레이드는 현재 미리 보기로 제공됩니다.

차세대 범용은 페이지 Blob 대신 관리 디스크에 인스턴스 데이터 및 로그 파일을 저장하는 업그레이드된 원격 저장소 레이어를 사용하는 기존 범용 서비스 계층으로 아키텍처 업그레이드입니다.

중요 비즈니스 서비스 계층

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

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

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

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

영역 중복 가용성

영역 중복 가용성은 주 지역의 세 Azure 가용성 영역에 컴퓨팅 노드 및 스토리지 복제본(replica)을 배치하는 방식에 기반합니다. 각 가용성 영역은 독립적인 전원, 냉각 및 네트워킹을 갖춘 별도의 물리적 위치입니다.

기본값으로 로컬 스토리지 가용성 모델에 대한 노드 클러스터는 동일한 데이터 센터에서 생성됩니다. Azure 가용성 영역을 도입하면서 SQL Managed Instance는 중요 비즈니스용 인스턴스의 서로 다른 복제본(replica)을 동일한 지역의 다른 가용성 영역에 배치할 수 있습니다. 마찬가지로, 범용 서비스 계층의 상태 비저장 컴퓨팅 노드는 다른 가용성 영역에 배치되는 반면, 상태 저장 스토리지는 ZRS(영역 중복 스토리지) 구성을 사용합니다.

단일 실패 지점을 제거하기 위해 제어 링은 세 개의 GW(게이트웨이 링)로 여러 영역에 걸쳐 복제됩니다. 특정 게이트웨이 링에 대한 라우팅은 ATM(Azure Traffic Manager)에서 제어됩니다. 영역 중복 구성을 선택하면 애플리케이션 로직을 변경하지 않고도 프리미엄 또는 중요 비즈니스용 데이터베이스를 더 큰 오류 집합(심각한 데이터 센터 중단 포함)으로 복원할 수 있습니다. 기존 프리미엄 또는 중요 비즈니스용 데이터베이스 또는 풀을 영역 중복 구성으로 변환할 수도 있습니다.

영역 중복 인스턴스에는 복제본이 서로 약간 떨어져 있는 서로 다른 데이터 센터에 있으므로 네트워크 대기 시간이 증가하면 트랜잭션 커밋 시간이 증가하고, 이에 따라 일부 OLTP 워크로드의 성능에 영향을 줄 수 있습니다. 언제든지 영역 중복 설정을 사용하지 않도록 설정하여 단일 영역 구성으로 돌아갈 수 있습니다. 이 프로세스는 일반 서비스 계층 목표 업그레이드와 비슷한 온라인 작업입니다. 프로세스가 완료되면 인스턴스가 영역 중복 링에서 단일 영역 링으로 또는 그 반대로 마이그레이션됩니다.

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

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

영역 중복을 사용하는 경우 다음을 고려합니다.

  • 차세대 범용 서비스 계층에는 영역 중복을 사용할 수 없습니다.
  • 영역 중복 구성을 지원하는 지역에 대한 최신 정보는 지역별 서비스 지원을 참조하세요.
  • 영역 중복 가용성의 경우 기본값 이외의 유지 관리 기간을 선택하는 것은 현재 일부 지역에서 사용할 수 있습니다.

중요 비즈니스용 인스턴스에 대해 지원되는 지역

중요 비즈니스용 SQL Managed Instance의 영역 중복은 다음 지역에서 지원됩니다.

아메리카 유럽 중동 아프리카 아시아 태평양
브라질 남부 프랑스 중부 카타르 중부 남아프리카 공화국 북부 오스트레일리아 동부
캐나다 중부 이탈리아 북부 이스라엘 중부 인도 중부
미국 중부 독일 중서부 일본 동부
미국 동부 노르웨이 동부 한국 중부
미국 동부 2 북유럽 동남 아시아
미국 중남부 영국 남부 동아시아
미국 서부 2 스웨덴 중부
미국 서부 3 스위스 북부
폴란드 중부

범용 인스턴스에 대해 지원되는 지역

참고 항목

영역 중복 구성은 공개 미리 보기의 범용 서비스 계층에서 제공됩니다.

아메리카 유럽 중동 아프리카 아시아 태평양
브라질 남부 프랑스 중부 카타르 중부 남아프리카 공화국 북부 오스트레일리아 동부
미국 동부 이탈리아 북부 이스라엘 중부 인도 중부
미국 동부 2 독일 중서부 일본 동부
미국 중남부 노르웨이 동부 한국 중부
미국 서부 2 북유럽 동남아시아
미국 서부 3 영국 남부 동아시아
스웨덴 중부
스위스 북부
폴란드 중부

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

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

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

PowerShell REST API Azure CLI
Invoke-AzSqlInstanceFailover SQL Managed Instance - 장애 조치(failover) az sql mi failover를 사용하여 Azure CLI에서 REST API 호출을 불러올 수 있습니다.

결론

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

다음 단계