Share via


Azure SQL Database에 대한 장애 조치(failover) 그룹 구성

적용 대상:Azure SQL Database

이 문서에서는 Azure Portal, Azure PowerShell 및 Azure CLI를 사용하여 Azure SQL Database의 단일 및 풀링된 데이터베이스에 대해 장애 조치 그룹을 구성하는 방법을 설명합니다.

엔드 투 엔드 스크립트의 경우 Azure PowerShell 또는 Azure CLI를 사용하여 장애 조치 그룹에 단일 데이터베이스를 추가하는 방법을 검토합니다.

필수 조건

단일 데이터베이스에 대한 장애 조치(failover) 그룹을 만들려면 다음 사전 요구 사항을 고려합니다.

  • 주 데이터베이스가 이미 생성되어 있어야 합니다. 시작할 단일 데이터베이스를 생성합니다.
  • 보조 서버가 주 서버와 다른 지역에 이미 있는 경우 서버 로그인 및 방화벽 설정이 주 서버의 설정과 일치해야 합니다.

장애 조치 그룹 만들기

Azure Portal, PowerShell 및 Azure CLI를 사용하여 장애 조치(failover) 그룹을 만들고 단일 데이터베이스를 추가합니다.

Important

장애 조치(failover) 그룹에 추가된 후 보조 데이터베이스를 삭제해야 하는 경우, 데이터베이스를 삭제하기 전에 장애 조치(failover) 그룹에서 제거합니다. 보조 데이터베이스를 장애 조치(failover) 그룹에서 제거하기 전에 삭제하면 예기치 않은 동작이 발생할 수 있습니다.

Azure Portal을 사용하여 장애 조치(failover) 그룹을 만들고 해당 그룹에 단일 데이터베이스를 추가하려면 다음 단계를 수행합니다.

  1. 데이터베이스를 호스트하는 논리 서버를 알고 있는 경우 Azure Portal에서 직접 이동합니다. 서버를 찾아야 하는 경우 다음 단계를 수행합니다.

    1. 서비스 메뉴에서 Azure SQL을 선택합니다. Azure SQL이 목록에 없는 경우 모든 서비스를 선택한 후 검색 상자에 Azure SQL을 입력합니다. (선택 사항) Azure SQL 옆의 별표를 선택하여 즐겨찾기에 추가하고 서비스 메뉴에 항목으로 추가합니다.
    2. Azure SQL 페이지에서 장애 조치(failover) 그룹에 추가할 데이터베이스를 찾아 선택하여 SQL 데이터베이스 창을 엽니다.
    3. SQL Database개요 창의 서버 이름에서 서버 이름을 선택하여 SQL Server 창을 엽니다.

    Azure Portal에서 단일 데이터베이스에 대한 서버를 여는 스크린샷

  2. SQL Server 리소스 메뉴의 데이터 관리에서 장애 조치(failover) 그룹을 선택합니다. + 그룹 추가를 선택하여 새 장애 조치(failover) 그룹을 만들 수 있는 장애 조치(failover) 그룹 페이지를 엽니다.

    Azure Portal의 장애 조치(failover) 그룹 페이지에서 새 장애 조치(failover) 그룹 추가 옵션을 강조 표시하는 스크린샷

  3. 장애 조치(failover) 그룹 페이지에서 다음을 수행합니다.

    1. 장애 조치(failover) 그룹 이름을 입력합니다.
    2. 기존 보조 서버를 선택하거나 서버에서 새로 만들기를 선택하여 새 서버를 만듭니다. 장애 조치 그룹의 보조 서버는 주 서버와는 다른 지역에 있어야 합니다.
    3. 데이터베이스 구성을 선택하여 장애 조치(failover) 그룹 데이터베이스 페이지를 엽니다.

    Azure Portal의 장애 조치(failover) 그룹 창 스크린샷

  4. 장애 조치(failover) 그룹 데이터베이스 페이지에서 다음을 수행합니다.

    1. 장애 조치(failover) 그룹에 추가하려는 데이터베이스를 선택합니다(스크린샷의 #1).
    2. (선택 사항) 이러한 데이터베이스를 재해 복구에만 사용할 대기 복제본(replica)으로 지정하려는 경우 를 선택합니다(스크린샷의 #2). 확인란을 선택하여 복제본(replica)을 대기로 사용할지 확인합니다.
    3. 선택을 사용하여 데이터베이스 선택을 저장하고 장애 조치(failover) 그룹 페이지로 돌아갑니다(스크린샷에 표시되지 않음).

    Azure Portal의 장애 조치(failover) 그룹 데이터베이스 창 스크린샷

  5. 장애 조치(failover) 그룹 페이지에서 만들기를 사용하여 장애 조치(failover) 그룹을 만듭니다.

계획된 장애 조치 테스트

Azure Portal 또는 PowerShell을 사용하여 데이터 손실 없이 장애 조치 그룹의 장애 조치를 테스트합니다.

Azure Portal을 사용하여 장애 조치(failover) 그룹의 장애 조치(failover)를 테스트하려면 다음을 수행합니다.

  1. 데이터베이스를 호스트하는 논리 서버를 알고 있는 경우 Azure Portal에서 직접 이동합니다. 서버를 찾아야 하는 경우 다음 단계를 수행합니다.

    1. 서비스 메뉴에서 Azure SQL을 선택합니다. Azure SQL이 목록에 없는 경우 모든 서비스를 선택한 후 검색 상자에 Azure SQL을 입력합니다. (선택 사항) Azure SQL 옆의 별표를 선택하여 즐겨찾기에 추가하고 서비스 메뉴에 항목으로 추가합니다.
    2. Azure SQL 페이지에서 장애 조치(failover)를 테스트할 데이터베이스를 찾아 선택하여 SQL 데이터베이스 창을 엽니다.
    3. SQL Database개요 창의 서버 이름에서 서버 이름을 선택하여 SQL Server 창을 엽니다.

    Azure Portal에서 단일 데이터베이스에 대한 서버를 여는 스크린샷

  2. SQL Server 리소스 메뉴의 데이터 관리에서 장애 조치(Failover) 그룹을 선택한 후 기존 장애 조치(failover) 그룹을 선택하여 장애 조치(failover) 그룹 페이지를 엽니다.

    SQL Server에 대한 장애 조치(failover) 그룹을 선택할 수 있는 장애 조치(failover) 그룹을 보여주는 스크린샷

  3. 장애 조치(failover) 그룹 페이지에서 다음을 수행합니다.

    1. 어떤 서버가 주 서버이고 보조 서버인지 검토합니다.
    2. 명령 모음에서 장애 조치(failover)를 선택하여 데이터베이스가 포함된 장애 조치(failover) 그룹을 장애 조치(failover)합니다.
    3. TDS 세션의 연결이 해제됨을 알려주는 경고에서 를 선택합니다.

    Azure Portal에서 장애 조치(failover) 그룹을 장애 조치(failover)하는 스크린샷

  4. 이제 어떤 서버가 주 서버이고 어떤 서버가 보조 서버인지 검토합니다. 장애 조치(failover)가 성공하면 이전 주 서버가 보조 서버가 되도록 두 서버가 역할을 교환합니다.

  5. (선택 사항) 장애 조치(failover)를 다시 선택하여 서버를 원래 역할로 장애 조치(Failover) 합니다.

엔드 투 엔드 스크립트의 경우 Azure PowerShell 또는 Azure CLI를 사용하여 장애 조치 그룹에 탄력적 풀을 추가하는 방법을 검토합니다.

필수 조건

풀링된 데이터베이스에 대한 장애 조치(failover) 그룹을 만들려면 다음 사전 요구 사항을 고려합니다.

  • 주 Elastic Pool이 이미 존재해야 합니다. 시작하려면 Elastic Pool을 생성합니다.
  • 보조 서버가 이미 존재하는 경우 서버 로그인 및 방화벽 설정은 주 서버와 일치해야 합니다.

장애 조치 그룹 만들기

Azure Portal, PowerShell 또는 Azure CLI를 사용하여 Elastic Pool에 대한 장애 조치(failover) 그룹을 만듭니다.

Important

장애 조치(failover) 그룹에 추가된 후 보조 데이터베이스를 삭제해야 하는 경우, 데이터베이스를 삭제하기 전에 장애 조치(failover) 그룹에서 제거합니다. 보조 데이터베이스를 장애 조치(failover) 그룹에서 제거하기 전에 삭제하면 예기치 않은 동작이 발생할 수 있습니다.

Azure Portal을 사용하여 장애 조치(failover) 그룹을 만들고 해당 그룹에 Elastic Pool을 추가하려면 다음 단계를 수행합니다.

  1. Azure Portal에서 SQL Elastic Pool 생성 페이지로 이동합니다. Elastic Pool을 생성합니다.

    • 이 풀은 주 서버의 Elastic Pool과 이름이 같습니다.
    • 장애 조치(failover) 그룹에 사용하려는 보조 서버를 사용합니다. 보조 서버는 주 서버와 다른 지역에 있어야 하며 서버 로그인 및 방화벽 설정은 주 서버와 일치해야 합니다. 보조 서버가 아직 없는 경우 새 서버를 만듭니다.
  2. 주 Elastic Pool을 호스트하는 논리 서버를 알고 있는 경우 Azure Portal에서 직접 이동합니다. 서버를 찾아야 하는 경우 다음 단계를 수행합니다.

    1. 서비스 메뉴에서 Azure SQL을 선택합니다. Azure SQL이 목록에 없는 경우 모든 서비스를 선택한 후 검색 상자에 Azure SQL을 입력합니다. (선택 사항) Azure SQL 옆의 별표를 선택하여 즐겨찾기에 추가하고 서비스 메뉴에 항목으로 추가합니다.
    2. Azure SQL 페이지에서 장애 조치(failover) 그룹에 추가할 Elastic Pool을 찾아 선택하여 SQL Elastic Pool 창을 엽니다.
    3. SQLElastic Pool개요 창의 서버 이름에서 서버 이름을 선택하여 SQL Server 창을 엽니다.

    Azure Portal에서 Elastic Pool의 서버를 선택하는 스크린샷

  3. SQL Server 리소스 메뉴의 데이터 관리에서 장애 조치(failover) 그룹을 선택합니다. + 그룹 추가를 선택하여 새 장애 조치(failover) 그룹을 만들 수 있는 장애 조치(failover) 그룹 페이지를 엽니다.

    Azure Portal의 장애 조치(failover) 그룹 페이지 스크린샷

  4. 장애 조치(failover) 그룹 페이지에서 다음을 수행합니다.

    1. 장애 조치(failover) 그룹 이름을 입력합니다.
    2. 기존 보조 서버를 선택합니다. 장애 조치(failover) 그룹의 보조 서버는 주 서버와 다른 지역에 있어야 하며 주 서버와 동일한 이름의 Elastic Pool을 포함해야 합니다.
    3. 데이터베이스 구성을 선택하여 장애 조치(failover) 그룹 데이터베이스 페이지를 엽니다.

    Azure Portal에서 장애 조치(failover) 그룹에 Elastic Pool을 추가하는 스크린샷

  5. 장애 조치(failover) 그룹 데이터베이스 페이지에서 장애 조치(failover) 그룹에 추가할 풀링된 데이터베이스를 선택합니다. 선택을 사용하여 데이터베이스 선택을 저장하고 장애 조치(failover) 그룹 페이지로 돌아갑니다.

    Azure Portal의 장애 조치(failover) 그룹 데이터베이스 창 스크린샷

  6. 장애 조치(failover) 그룹 페이지에서 만들기를 선택하여 장애 조치(failover) 그룹을 만듭니다. 장애 조치(failover) 그룹에 Elastic Pool을 추가하면 지역에서 복제 프로세스가 자동으로 시작됩니다.

계획된 장애 조치 테스트

Azure Portal, PowerShell 또는 Azure CLI를 사용하여 Elastic Pool의 데이터 손실 없이 장애 조치(failover)를 테스트합니다.

장애 조치 그룹을 보조 서버로 장애 조치한 다음, Azure Portal을 사용하여 장애 복구합니다.

  1. 주 Elastic Pool을 호스트하는 논리 서버를 알고 있는 경우 Azure Portal에서 직접 이동합니다. 서버를 찾아야 하는 경우 다음 단계를 수행합니다.

    1. 서비스 메뉴에서 Azure SQL을 선택합니다. Azure SQL이 목록에 없는 경우 모든 서비스를 선택한 후 검색 상자에 Azure SQL을 입력합니다. (선택 사항) Azure SQL 옆의 별표를 선택하여 즐겨찾기에 추가하고 서비스 메뉴에 항목으로 추가합니다.
    2. Azure SQL 페이지에서 장애 조치(failover) 그룹에 추가할 Elastic Pool을 찾아 선택하여 SQL Elastic Pool 창을 엽니다.
    3. SQLElastic Pool개요 창의 서버 이름에서 서버 이름을 선택하여 SQL Server 창을 엽니다.

    Azure Portal에서 Elastic Pool의 서버를 선택하는 스크린샷

  2. SQL Server 리소스 메뉴의 데이터 관리에서 장애 조치(Failover) 그룹을 선택한 후 기존 장애 조치(failover) 그룹을 선택하여 장애 조치(failover) 그룹 페이지를 엽니다.

    SQL Server에 대한 장애 조치(failover) 그룹을 선택할 수 있는 장애 조치(failover) 그룹을 보여주는 스크린샷

  3. 장애 조치(failover) 그룹 페이지에서 다음을 수행합니다.

    1. 어떤 서버가 주 서버이고 보조 서버인지 검토합니다.
    2. 명령 모음에서 장애 조치(failover)를 선택하여 데이터베이스가 포함된 장애 조치(failover) 그룹을 장애 조치(failover)합니다.
    3. TDS 세션의 연결이 해제됨을 알려주는 경고에서 를 선택합니다.

    Azure Portal의 장애 조치(failover) 그룹 페이지에서 장애 조치(failover)를 선택하는 스크린샷

  4. 이제 어떤 서버가 주 서버이고 어떤 서버가 보조 서버인지 검토합니다. 장애 조치(failover)가 성공하면 이전 주 서버가 보조 서버가 되도록 두 서버가 역할을 교환합니다.

  5. (선택 사항) 장애 조치(failover)를 다시 선택하여 서버를 원래 역할로 장애 조치(Failover) 합니다.

기존 장애 조치(failover) 그룹 수정

기존 장애 조치(failover) 그룹에서 데이터베이스를 추가 또는 제거하거나 Azure Portal, PowerShell 및 Azure CLI를 사용하여 장애 조치(failover) 그룹 구성 설정을 편집할 수 있습니다.

Azure Portal을 사용하여 기존 장애 조치(failover) 그룹을 변경하려면 다음 단계를 수행합니다.

  1. 데이터베이스 또는 Elastic Pool을 호스트하는 논리 서버를 알고 있는 경우 Azure Portal에서 직접 이동합니다. 서버를 찾아야 하는 경우 다음 단계를 수행합니다.

    1. 서비스 메뉴에서 Azure SQL을 선택합니다. Azure SQL이 목록에 없는 경우 모든 서비스를 선택한 후 검색 상자에 Azure SQL을 입력합니다. (선택 사항) Azure SQL 옆의 별표를 선택하여 즐겨찾기에 추가하고 서비스 메뉴에 항목으로 추가합니다.
    2. Azure SQL 페이지에서 수정할 데이터베이스 또는 Elastic Pool을 찾아 선택하여 SQL 데이터베이스 또는 SQL Elastic Pool 창을 엽니다.
    3. SQL 데이터베이스 또는 SQL Elastic Pool에 대한 개요 창의 서버 이름에서 서버 이름을 선택하여 SQL 서버 창을 엽니다.
  2. SQL Server 리소스 메뉴의 데이터 관리에서 장애 조치(Failover) 그룹을 선택한 후 기존 장애 조치(failover) 그룹을 선택하여 장애 조치(failover) 그룹 페이지를 엽니다.

    SQL Server에 대한 장애 조치(failover) 그룹을 선택할 수 있는 장애 조치(failover) 그룹을 보여주는 스크린샷

  3. 장애 조치(failover) 그룹 페이지에서 명령 모음을 사용합니다.

    1. 데이터베이스를 추가하려면 데이터베이스 추가를 선택하여 장애 조치(failover) 그룹에 데이터베이스 추가 창을 연 후 #Databases를 확장하여 주 서버에 데이터베이스 목록을 표시합니다. 장애 조치(failover) 그룹에 추가할 데이터베이스 옆의 확인란을 선택한 후 선택을 사용하여 변경 내용을 저장하고 데이터베이스를 추가합니다.
    2. 데이터베이스를 제거하려면 데이터베이스 제거를 선택하여 장애 조치(failover) 그룹에서 데이터베이스 제거 창을 연 후 #Databases를 확장하여 장애 조치(failover) 그룹의 데이터베이스를 나열합니다. 장애 조치(failover) 그룹에서 제거할 데이터베이스 옆의 확인란을 선택한 후 선택을 사용하여 변경 내용을 저장하고 데이터베이스를 제거합니다.
    3. 장애 조치(failover) 정책을 편집하거나 유예 기간을 구성하려면 구성 편집을 선택하여 장애 조치(failover) 그룹 구성 편집 창을 열고 설정을 수정합니다. 선택을 사용하여 변경 내용을 저장합니다.

    명령 모음이 강조 표시된 Azure Portal의 장애 조치(failover) 그룹 페이지 스크린샷

프라이빗 링크를 사용하면 가상 네트워크 및 서브넷 내의 특정 개인 IP 주소에 논리 서버를 연결할 수 있습니다.

장애 조치 그룹에서 프라이빗 링크를 사용하려면 다음을 수행합니다.

  1. 주 서버와 보조 서버가 쌍을 이루는 지역에 있는지 확인합니다.
  2. 겹치지 않는 IP 주소 공간을 갖도록 주 서버와 보조 서버에 대한 프라이빗 엔드포인트를 호스팅하기 위해 각 지역에 가상 네트워크 및 서브넷을 만듭니다. 예를 들어 10.0.0.0/16의 주 가상 네트워크 주소 범위와 10.0.0.1/16의 보조 가상 네트워크 주소 범위가 겹칩니다. 가상 네트워크 주소 범위에 대한 자세한 내용은 designing Azure virtual networks(Azure Virtual Network 디자인) 블로그를 참조하세요.
  3. 주 서버에 대한 프라이빗 엔드포인트 및 Azure 프라이빗 DNS 영역을 만듭니다.
  4. 보조 서버에 대한 프라이빗 엔드포인트도 만듭니다. 하지만 이번에는 주 서버에 대해 만들어진 것과 동일한 프라이빗 DNS 영역을 다시 사용하도록 선택합니다.
  5. 프라이빗 링크를 설정한 다음에는 이 문서의 앞부분에서 간략하게 설명한 단계에 따라 장애 조치 그룹을 만들 수 있습니다.

수신기 엔드포인트 찾기

장애 조치 그룹을 구성한 후 애플리케이션에 대한 연결 문자열을 수신기 엔드포인트로 업데이트합니다. 이렇게 하면 애플리케이션이 주 데이터베이스 또는 탄력적 풀이 아닌 장애 조치 그룹 수신기에 연결된 상태로 유지됩니다. 이렇게 하면 데이터베이스 엔터티가 장애 조치될 때마다 연결 문자열을 수동으로 업데이트할 필요가 없으며, 트래픽은 현재 주가 되는 모든 엔터티로 라우팅됩니다.

수신기 엔드포인트는 fog-name.database.windows.net 형식이며, 장애 조치 그룹을 볼 때 Azure Portal에 표시됩니다.

Azure Portal의 장애 조치(failover) 그룹 페이지에서 장애 조치(failover) 그룹 연결 문자열 보여 주는 스크린샷

장애 조치 그룹에서 데이터베이스 크기 조정

지역 보조 데이터베이스와의 연결을 끊지 않고도 주 데이터베이스를 다른 컴퓨팅 크기(동일한 서비스 계층 내)로 확장 또는 축소할 수 있습니다. 스케일 업할 때에는 지역 보조 데이터베이스부터 스케일 업한 다음, 주 데이터베이스를 스케일 업하는 것이 좋습니다. 스케일 다운할 때에는 역순으로 합니다. 주 데이터베이스부터 스케일 다운한 다음, 보조 데이터베이스를 스케일 다운합니다. 데이터베이스를 다른 서비스 계층으로 스케일링할 때에는 이 권장 사항이 강제 적용됩니다.

이 시퀀스는 더 낮은 SKU의 지역 보조 데이터베이스가 오버로드되어 업그레이드 또는 다운그레이드 프로세스 중에 다시 시딩해야 하는 문제를 방지하기 위해 특히 권장됩니다. 주 서버에 대한 모든 읽기/쓰기 워크로드의 영향을 희생하여 주 서버를 읽기 전용으로 설정해 문제를 방지할 수도 있습니다.

참고 항목

장애 조치(failover) 그룹 구성의 일부로 지역 보조 데이터베이스를 만든 경우 지역 보조 데이터베이스를 스케일 다운하는 것이 좋습니다. 이렇게 하면 지역 장애 조치(failover) 후 데이터 계층에 일반 워크로드를 처리할 수 있을 만큼 충분한 용량이 생깁니다. 중단으로 인해 이전 지역 주 데이터베이스를 사용할 수 없는 경우 계획하지 않은 장애 조치 후 지역 보조 데이터베이스의 크기를 조정할 수 없을 수 있습니다. 이것은 알려진 제한 사항입니다.

중요한 데이터 손실 방지

광역 네트워크의 높은 대기 시간으로 인해 지역 복제에는 비동기 복제 메커니즘이 사용됩니다. 비동기 복제를 사용하면 주 데이터베이스에서 오류가 발생할 때 데이터가 손실될 가능성이 있습니다. 중요한 트랜잭션을 데이터 손실로부터 보호하려면 애플리케이션 개발자는 트랜잭션을 커밋한 후 즉시 sp_wait_for_database_copy_sync 시스템 프로시저를 호출하면 됩니다. sp_wait_for_database_copy_sync를 호출하면 마지막으로 커밋된 트랜잭션이 보조 데이터베이스의 트랜잭션 로그로 전송되어 강화될 때까지 호출 스레드가 차단됩니다. 그러나 전송된 트랜잭션이 보조 데이터베이스에서 재생(다시 실행)될 때까지 기다리지는 않습니다. sp_wait_for_database_copy_sync의 범위는 특정 지역 복제 링크로 한정됩니다. 주 데이터베이스에 대한 연결 권한이 있는 모든 사용자는 이 프로시저를 호출할 수 있습니다.

참고

sp_wait_for_database_copy_sync는 특정 트랜잭션의 지역 장애 조치(failover) 후 데이터 손실을 방지하지만, 읽기 액세스에 대한 전체 동기화를 보장하지는 않습니다. sp_wait_for_database_copy_sync 프로시저를 호출하면 상당한 지연이 발생할 수 있으며, 호출 당시 주 데이터베이스에서 아직 전송되지 않은 트랜잭션 로그의 크기에 따라 지연 시간이 달라집니다.

보조 지역 변경

변경 시퀀스를 설명하기 위해 서버 A는 주 서버, 서버 B는 기존 보조 서버, 서버 C는 세 번째 지역의 새로운 보조 서버라고 가정합니다. 전환을 수행하려면 다음 단계를 수행합니다.

  1. 활성 지역 복제를 사용하여 서버 A에서 서버 C까지 각 데이터베이스의 추가 보조 데이터베이스를 만듭니다. 서버 A의 각 데이터베이스에는 서버 B와 서버 C에 하나씩 2개의 보조 데이터베이스가 있습니다. 따라서 전환 중에 주 데이터베이스를 보호된 상태로 유지합니다.
  2. 장애 조치 그룹을 삭제합니다. 이 시점에서 장애 조치 그룹 엔드포인트를 사용하는 로그인 시도는 실패합니다.
  3. 서버 A와 C 간에 동일한 이름으로 장애 조치(failover) 그룹을 다시 만듭니다.
  4. 서버 A의 모든 주 데이터베이스를 새 장애 조치 그룹에 추가합니다. 이 시점에는 로그인 시도가 더 이상 실패하지 않습니다.
  5. 서버 B를 삭제합니다. B의 모든 데이터베이스가 자동으로 삭제됩니다.

주 지역 변경

변경 시퀀스를 설명하기 위해 서버 A는 주 서버, 서버 B는 기존 보조 서버, 서버 C는 세 번째 지역의 새로운 주 서버라고 가정합니다. 전환을 수행하려면 다음 단계를 수행합니다.

  1. 계획된 지역 장애 조치를 수행하여 주 서버를 B로 전환합니다. 서버 A가 새 보조 서버가 됩니다. 장애 조치로 인해 가동 중지 시간이 몇 분 동안 발생할 수 있습니다. 실제 시간은 장애 조치 그룹의 크기에 따라 달라집니다.
  2. 활성 지역 복제를 사용하여 서버 B에서 서버 C까지 각 데이터베이스의 추가 보조 데이터베이스를 만듭니다. 서버 B의 각 데이터베이스에는 서버 A와 서버 C에 하나씩 2개의 보조 데이터베이스가 있습니다. 따라서 전환 중에 주 데이터베이스를 보호된 상태로 유지합니다.
  3. 장애 조치 그룹을 삭제합니다. 이 시점에서 장애 조치 그룹 엔드포인트를 사용하는 로그인 시도는 실패합니다.
  4. 서버 B와 C 간에 동일한 이름으로 장애 조치(failover) 그룹을 다시 만듭니다.
  5. B의 모든 주 데이터베이스를 새 장애 조치 그룹에 추가합니다. 이 시점에는 로그인 시도가 실패하지 않습니다.
  6. 장애 조치 그룹의 계획된 지역 장애 조치를 수행하여 B와 C를 전환합니다. 이제 서버 C가 주 서버가 되고 B가 보조 서버가 됩니다. 서버 A의 모든 보조 데이터베이스는 C의 주 데이터베이스에 자동으로 연결됩니다. 1단계에서와 같이 장애 조치로 인해 가동 중지 시간이 몇 분 동안 발생할 수 있습니다.
  7. 서버 A를 삭제합니다. A의 모든 데이터베이스가 자동으로 삭제됩니다.

Important

장애 조치 그룹을 삭제하면 수신기 엔드포인트의 DNS 레코드도 삭제됩니다. 이 시점에는 다른 사람이 같은 이름을 사용하는 장애 조치(failover) 그룹 또는 서버 DNS 별칭을 만들 가능성이 있습니다. 장애 조치(failover) 그룹 이름 및 DNS 별칭은 전역적으로 고유해야 하기 때문에 동일한 이름을 다시 사용할 수 없습니다. 이 위험을 최소화하려면 일반 장애 조치(failover) 그룹 이름을 사용하지 마세요.

장애 조치 그룹 및 네트워크 보안

일부 애플리케이션의 경우 보안 규칙에 따라 데이터 계층에 대한 네트워크 액세스가 VM, 웹 서비스 등과 같은 구성 요소나 특정 구성 요소로 제한되어야 합니다. 이 요구 사항 때문에 비즈니스 연속성 디자인과 장애 조치(failover) 그룹 사용에 관한 몇 가지 문제가 발생합니다. 이러한 제한된 액세스를 구현하는 경우 다음 옵션을 고려합니다.

장애 조치(failover) 그룹 및 가상 네트워크 서비스 엔드포인트 사용

Virtual Network 서비스 엔드포인트 및 규칙을 사용하여 데이터베이스에 대한 액세스를 제한하는 경우 각 가상 네트워크 서비스 엔드포인트를 하나의 Azure 지역에만 적용합니다. 엔드포인트를 사용하여 다른 지역이 서브넷에서 보낸 통신을 수락하도록 할 수는 없습니다. 따라서 동일한 지역에 배포된 클라이언트 애플리케이션만 주 데이터베이스에 연결할 수 있습니다. 지역 장애 조치는 SQL Database 클라이언트 세션이 다른 (보조) 지역의 서버로 다시 라우팅되는 결과를 가져오므로, 해당 지역 외부의 클라이언트에서 시작하는 세션은 실패할 수 있습니다. 이런 이유로 참여하는 서버가 Virtual Network 규칙에 포함된 경우 Microsoft에서 관리하는 장애 조치 정책을 사용할 수 없습니다. 수동 장애 조치 정책을 지원하려면 다음 단계를 수행합니다.

  1. 보조 지역에서 애플리케이션(웹 서비스, 가상 컴퓨터 등) 프런트 엔드 구성 요소의 중복 복사본을 프로비전합니다.
  2. 기본 및 보조 서버에 대한 가상 네트워크 규칙을 개별적으로 구성합니다.
  3. 트래픽 관리자 구성을 사용하여 프런트 엔드 장애 조치를 사용하도록 설정합니다.
  4. 중단을 감지하면 수동 지역 장애 조치를 시작합니다. 이 옵션은 프런트 엔드와 데이터 계층 간에 일관된 대기 시간을 필요로 하는 애플리케이션에 최적화되어 있으며 프런트 엔드, 데이터 계층 또는 모두가 중단의 영향을 받는 경우 복구를 지원합니다.

참고 항목

읽기 전용 수신기를 사용하여 읽기 전용 워크로드의 부하를 분산하는 경우 이 워크로드를 보조 데이터베이스에 연결할 수 있도록 보조 지역의 VM 또는 다른 리소스에서 실행했는지 확인합니다.

장애 조치 그룹 및 방화벽 규칙 사용

비즈니스 연속성 계획에 장애 조치 그룹을 사용하는 장애 조치가 필요한 경우 공용 IP 방화벽 규칙을 사용하여 SQL Database에 대한 액세스를 제한할 수 있습니다. 이 구성은 지역 장애 조치가 프런트 엔드 구성 요소의 연결을 차단하지 않으며, 애플리케이션이 프런트 엔드와 데이터 계층 간의 긴 대기 시간을 허용할 수 있다고 가정합니다.

장애 조치 그룹의 장애 조치를 지원하려면 다음 단계를 수행합니다.

  1. 공용 IP 만들기.
  2. 공용 부하 분산 장치를 만들고 여기에 공용 IP를 할당합니다.
  3. 프런트 엔드 구성 요소에 대한 가상 네트워크 및 가상 머신을 만듭니다.
  4. 네트워크 보안 그룹을 만들고 인바운드 연결을 구성합니다.
  5. Sql.<Region>서비스 태그를 사용하여 아웃바운드 연결이 지역의 Azure SQL Database에 대해 열려 있는지 확인합니다.
  6. SQL 데이터베이스 방화벽 규칙을 만들어서 1단계에서 만든 공용 IP 주소에서 인바운드 트래픽을 허용합니다.

아웃바운드 액세스를 구성하는 방법 및 방화벽 규칙에서 사용할 IP에 대한 자세한 내용은 부하 분산 장치 아웃바운드 연결을 참조하세요.

Important

지역 중단이 발생하는 동안 비즈니스 연속성을 보장하려면 프런트 엔드 구성 요소와 데이터베이스 모두에 대한 지리적 중복성을 확인해야 합니다.

사용 권한

장애 조치 그룹의 사용 권한은 Azure RBAC(Azure 역할 기반 액세스 제어)를 통해 관리합니다.

장애 조치(failover) 그룹을 만들고 관리하려면 Azure RBAC 쓰기 권한이 필요합니다. SQL Server Contributor 역할에는 장애 조치 그룹을 관리하는 데 필요한 모든 사용 권한이 있습니다.

다음 표에는 Azure SQL Database에 대한 특정 권한 범위가 나와 있습니다.

작업 사용 권한 범위
장애 조치 그룹 만들기 Azure RBAC 쓰기 권한 주 서버
보조 서버
장애 조치(failover) 그룹의 모든 데이터베이스
장애 조치(failover) 그룹 업데이트 Azure RBAC 쓰기 권한 장애 조치 그룹
현재 주 서버의 모든 데이터베이스
장애 조치(failover) 그룹의 장애 조치(failover) Azure RBAC 쓰기 권한 새 서버의 장애 조치(failover) 그룹

제한 사항

다음과 같은 제한 사항을 고려해야 합니다.

  • 동일한 Azure 지역의 두 서버 간에 장애 조치 그룹을 만들 수 없습니다.
  • 장애 조치 그룹은 그룹의 모든 데이터베이스를 다른 지역에 있는 하나의 보조 논리 서버로만 지역 복제할 수 있도록 지원합니다.
  • 장애 조치 그룹의 이름을 바꿀 수 없습니다. 그룹을 삭제하고 다른 이름으로 다시 만들어야 합니다.
  • 장애 조치 그룹의 데이터베이스에는 데이터베이스 이름 바꾸기를 지원하지 않습니다. 데이터베이스 이름을 변경하거나 장애 조치 그룹에서 데이터베이스를 제거하려면 장애 조치 그룹을 일시적으로 삭제해야 합니다.
  • 단일 또는 풀링된 데이터베이스에 대한 장애 조치(failover) 그룹을 제거해도 복제가 중지되지 않으며 복제된 데이터베이스도 삭제되지 않습니다. 단일 또는 풀링된 데이터베이스를 제거한 후 장애 조치 그룹에 다시 추가하려면 지역 복제를 수동으로 중지하고 보조 서버에서 데이터베이스를 삭제해야 합니다. 그러지 않으면 장애 조치 그룹에 데이터베이스를 추가하려고 할 때 The operation cannot be performed due to multiple errors와 유사한 오류가 발생할 수 있습니다.
  • 장애 조치 그룹 이름에는 명명 제한이 적용됩니다.
  • 새 장애 조치(failover) 그룹을 만들거나 기존 장애 조치(failover) 그룹에 데이터베이스를 추가할 때 Azure Portal을 사용하는 경우에만 데이터베이스를 대기 복제본(replica)으로 지정할 수 있습니다. Azure PowerShell 및 Azure CLI는 현재 사용할 수 없습니다.

프로그래밍 방식으로 장애 조치(failover) 그룹 관리

Azure PowerShell, Azure CLI 및 REST API를 사용하여 프로그래밍 방식으로 장애 조치(failover) 그룹을 관리할 수도 있습니다. 다음 표는 사용 가능한 명령의 집합을 보여줍니다. 장애 조치 그룹은 관리를 위해 Azure SQL Database REST APIAzure PowerShell cmdlet을 비롯한 Azure Resource Manager API 집합을 포함합니다. 이러한 API는 리소스 그룹을 사용해야 하며 Azure RBAC(Azure 역할 기반 액세스 제어)를 지원합니다. 액세스 역할을 구현하는 방법에 관한 자세한 내용은 Azure RBAC(Azure 역할 기반 액세스 제어)를 참조하세요.

Cmdlet 설명
New-AzSqlDatabaseFailoverGroup 장애 조치 그룹을 만들고 주 및 보조 서버 모두에 등록합니다
Add-AzSqlDatabaseToFailoverGroup 장애 조치 그룹에 하나 이상의 데이터베이스 추가
Remove-AzSqlDatabaseFromFailoverGroup 장애 조치(failover) 그룹에서 하나 이상의 데이터베이스 제거
Remove-AzSqlDatabaseFailoverGroup 서버에서 장애 조치 그룹 제거
Get-AzSqlDatabaseFailoverGroup 장애 조치 그룹의 구성 검색
Set-AzSqlDatabaseFailoverGroup 장애 조치 그룹의 구성 수정
Switch-AzSqlDatabaseFailoverGroup 장애 조치 그룹을 보조 서버로 장애 조치하도록 트리거

참고 항목

Az.SQL 3.11.0부터 Azure Powershell의 -PartnerSubscriptionId 매개 변수를 사용하여 구독 간에 장애 조치 그룹을 배포할 수 있습니다. 자세한 내용은 다음 예제를 검토하세요.