다음을 통해 공유

로컬 및 영역 중복을 통한 가용성 - Azure SQL Managed Instance

  • 아티클

적용 대상:Azure SQL Managed Instance

이 문서에서는 영역 중복을 통한 고가용성 및 로컬 중복을 통한 가용성을 지원하는 Azure SQL Managed Instance의 아키텍처를 설명합니다.

Important

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

개요

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

기본값으로 Azure SQL Managed Instance는 로컬 중복을 통한 가용성을 지원하여 다음 기간에 인스턴스를 사용할 수 있도록 합니다.

  • 짧은 가동 중지 시간을 초래하는 고객이 시작한 관리 작업
  • 서비스 유지 관리 작업
  • 다음과 관련된 문제 및 데이터 센터 중단:
    • 서비스에 전원을 공급하는 컴퓨터가 실행 중인 랙
    • SQL 데이터베이스 엔진을 실행하는 VM을 호스트하는 물리적 컴퓨터
    • SQL 데이터베이스 엔진을 실행하는 가상 머신
  • SQL 데이터베이스 엔진 관련 기타 문제
  • 계획되지 않은 다른 잠재적인 로컬 중단

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

그러나 전체 영역에 중단이 발생할 경우 데이터에 미치는 영향을 최소화하기 위해 영역 중복을 사용하도록 설정하여 고가용성을 지원할 수 있습니다. 영역 중복을 사용하지 않으면 장애 조치(failover)가 동일한 데이터 센터 내에서 로컬로 수행되므로 중단이 해결될 때까지 인스턴스를 사용할 수 없습니다. 복구하는 유일한 방법은 장애 조치(failover) 그룹 또는 지역 중복 백업의 지역 복원을 통한 재해 복구 솔루션을 사용하는 것입니다. 자세한 내용은 비즈니스 연속성 개요를 검토하세요.

고가용성을 지원하면 다음과 같은 영향을 받지 않도록 보호하여 서비스의 안정성을 높입니다.

  • 데이터 센터를 구성하는 가용성 영역

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

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

다른 서비스 계층의 특정 SLA에 대한 자세한 내용은 Azure SQL Managed Instance용 SLA를 검토하세요.

로컬 중복을 통한 가용성

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

범용 서비스 계층

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

컴퓨팅 및 저장소 분리를 보여 주는 다이어그램.

원격 저장소 가용성 모델에는 다음 2개의 계층이 포함됩니다:

  • 데이터베이스 엔진 프로세스를 실행하고 연결된 SSD의 tempdb 및 model와 같은 데이터베이스와 같이 일시적이고 캐시된 데이터만 포함하는 상태 비저장 컴퓨팅 계층이고, 메모리의 계획 캐시, 버퍼 풀 및 열 저장소 풀을 포함합니다. 이 상태 비저장 노드는 데이터베이스 엔진을 초기화하고, 노드 상태를 제어하며, 필요한 경우 다른 노드로 장애 조치(failover)를 수행하는 Azure Service Fabric을 통해 작동합니다.
  • Azure Blob 저장소에 저장된 데이터베이스 파일(.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)을 배치할 수 있습니다. 단일 실패 지점을 제거하기 위해 제어 링도 여러 영역에서 복제됩니다. 그런 다음, 컨트롤 플레인 트래픽은 여러 가용성 영역에도 배포된 부하 분산 장치로 라우팅됩니다. 컨트롤 플레인에서 부하 분산 장치로의 트래픽 라우팅은 ATM(Azure Traffic Manager)에서 제어합니다.

영역 중복 구성을 선택하면 애플리케이션 로직을 변경하지 않고도, 심각한 데이터 센터 중단을 비롯한 다양한 대규모 장애에 대비하여 중요 비즈니스용 또는 범용 인스턴스의 복원력을 지원할 수 있습니다. 기존 중요 비즈니스용 또는 범용 인스턴스를 영역 중복 구성으로 변환할 수도 있습니다.

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

SQL Managed Instance에 대한 영역 중복을 시작하려면 영역 중복 구성을 검토하세요.

범용 서비스 계층

범용 서비스 계층에서 영역 중복은 상태 비저장 컴퓨팅 노드를 다른 가용성 영역에 배치하는 방식으로 지원되며, 현재 활성 SQL 데이터베이스 엔진 프로세스를 포함하는 노드에 연결된 상태 저장 ZRS(영역 중복 스토리지)에 의존합니다. 중단이 발생하면 SQL 데이터베이스 엔진 프로세스는 상태 비저장 노드 중 하나에서 활성화되고, 상태 저장 스토리지의 데이터에 액세스합니다.

다음 다이어그램에서는 범용 서비스 계층의 영역 중복 아키텍처를 보여줍니다.

범용 서비스 계층의 영역 중복 아키텍처 다이어그램.

참고 항목

영역 중복은 현재 범용 서비스 계층에 대해 미리 보기로 제공됩니다.

중요 비즈니스 서비스 계층

중요 비즈니스용 서비스 계층에서는 컴퓨팅 및 스토리지 복제본을 다른 가용성 영역에 배치한 다음, 기본 Always On 가용성 그룹 기술을 사용해 주 인스턴스의 데이터 변경 내용을 다른 가용성 영역의 대기 복제본으로 복제하여 영역 중복을 지원합니다. 중단이 발생하면 대기 복제본 중 하나를 주 복제본으로 원활하게 전환하는 자동 장애 조치(failover) 기능이 적용됩니다.

다음 다이어그램은 중요 비즈니스용 서비스 계층의 영역 중복 아키텍처를 보여줍니다.

중요 비즈니스용 서비스 계층의 영역 중복 아키텍처 다이어그램.

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

가용성은 데이터베이스 애플리케이션에 대해 투명하게 작동하는 SQL Managed Instance 플랫폼의 기본 부분입니다. 그러나 애플리케이션을 프로덕션 환경에 배포하기 전에 계획되거나 계획되지 않은 이벤트 중에 시작된 자동 장애 조치(failover) 작업이 애플리케이션에 어떤 영향을 미치는지 테스트해보고 싶을 수 있습니다. 특수 API를 호출하여 관리형 인스턴스를 다시 시작하면 장애 조치(failover)를 수동으로 트리거할 수 있습니다. 다시 시작 작업은 방해가 되고 많은 수의 이러한 작업으로 인해 플랫폼에서 부다을 줄 수 있으므로 각 관리형 인스턴스에 대해 15분마다 하나의 장애 조치(failover) 호출만 허용됩니다.

실제 장애 조치(failover) 중에 SQL 서비스가 다른 노드에서 주 항목이 되는 동안 해당 인스턴스에 대한 연결이 실패합니다. 장애 조치(failover)를 시뮬레이션하려면 SQL 프로세스를 다시 시작하는 명령을 호출하여 장애 조치(failover)가 발생한 것처럼 서비스 시작을 시뮬레이션합니다. 그러나 시뮬레이션된 장애 조치(failover)와 비교했을 때 장기간 연결이 실패할 수 있습니다. 실제 장애 조치(failover) 중에는 SQL 프로세스가 클러스터 내 다른 가상 머신(로컬로 또는 영역 중복을 사용하는 경우 다른 영역에서)에서 주 항목이 되고, 시뮬레이션된 장애 조치(failover) 중에는 SQL 프로세스가 기존 가상 머신에서 다시 시작되기 때문입니다.

이 섹션의 수동 장애 조치(failover) 명령은 로컬 중복 및 영역 중복 구성 모두에서 동일한 방식으로 작동합니다. 단, SQL 프로세스를 로컬로 다시 시작하고 다른 노드로의 장애 조치(failover)를 시작하지 않습니다. 이 로컬 장애 조치(failover)는 장애 조치(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를 지원할 수 있습니다.

다음 단계