Azure Storage 재해 복구 계획 및 장애 조치(failover)
Microsoft는 Azure 서비스를 항상 사용할 수 있도록 하기 위해 노력합니다. 그러나 예기치 못한 서비스 중단이 가끔 발생할 수 있습니다. 적절한 재해 복구 계획의 주요 구성 요소에는 다음을 위한 전략이 포함됩니다.
이 문서에서는 지역 중복 스토리지 계정에 사용할 수 있는 옵션을 설명하고 고가용성 애플리케이션을 개발하고 재해 복구 계획을 테스트하기 위한 권장 사항을 제공합니다.
적절한 중복 옵션 선택
Azure Storage는 장애가 발생하더라도 가용성 및 내구성 대상을 충족할 수 있도록 스토리지 계정의 여러 복사본을 유지 관리합니다. 데이터가 복제되는 방식에 따라 보호 수준이 다릅니다. 각 옵션은 고유한 이점을 제공하므로 애플리케이션에 필요한 복원력 정도에 따라 옵션을 선택합니다.
가장 비용이 저렴한 중복성 옵션인 LRS(로컬 중복 스토리지)는 단일 데이터 센터 내에서 스토리지 계정의 세 사본을 자동으로 저장하고 복제합니다. LRS는 서버 랙 및 드라이브 장애로부터 데이터를 보호하지만, 데이터 센터 내에서 발생하는 화재나 홍수와 같은 재해는 고려하지 않습니다. 이러한 재해가 발생하면 LRS를 사용하도록 구성된 스토리지 계정의 모든 복제본이 손실되거나 복구 불가능해질 수 있습니다.
이에 비해 ZRS(영역 중복 스토리지)는 스토리지 계정의 복사본을 보존하고 동일한 지역 내의 세 개의 별도 가용성 영역에 복제합니다. 가용성 영역에 대한 자세한 내용은 Azure 가용성 영역을 참조하세요.
지역 중복 스토리지 및 장애 조치(failover)
GRS(지역 중복 스토리지), GZRS(지역 영역 중복 스토리지) 및 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지)는 지리적으로 중복된 스토리지 옵션의 예입니다. 지역 중복 스토리지(GRS, GZRS 및 RA-GZRS)를 사용하도록 구성된 경우 Azure는 데이터를 보조 지리적 지역에 비동기적으로 복사합니다. 이러한 지역은 수백, 심지어 수천 마일 떨어져 있습니다. 이 수준의 중복성을 통해 주 지역 전체에서 중단이 발생하더라도 데이터를 복구할 수 있습니다.
LRS 및 ZRS와 달리 지역 중복 스토리지는 주 지역에 중단이 있는 경우 보조 지역에 대한 un계획된 장애조치 지원도 제공합니다. 장애 조치(failover) 프로세스 중에 스토리지 계정 서비스 엔드포인트에 대한 DNS(Domain Name System) 항목이 자동으로 업데이트되어 보조 지역의 엔드포인트가 새로운 기본 엔드포인트가 됩니다. 계획되지 않은 장애 조치(failover)가 완료되면 클라이언트는 새로운 기본 엔드포인트에 쓰기를 시작할 수 있습니다.
RA-GRS(읽기 액세스 지역 중복 스토리지) 및 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지)도 지역 중복 스토리지를 제공하지만 보조 엔드포인트에 대한 읽기 권한의 추가적인 이점을 제공합니다. 이러한 옵션은 고가용성 비즈니스에 중요한 애플리케이션을 위해 설계된 애플리케이션에 이상적입니다. 기본 엔드포인트에 중단이 발생하더라도 보조 지역에 대한 읽기 권한으로 구성된 애플리케이션은 계속 작동할 수 있습니다. 스토리지 계정의 최대 가용성 및 내구성을 위해 RA-GZRS를 권장합니다.
Azure Storage의 중복성에 대한 자세한 내용은 Azure Storage 중복성을 참조하세요.
장애 조치(failover) 계획
Azure Storage 계정은 세 가지 형식의 장애 조치(failover)를 지원합니다.
- 고객 관리 계획 장애 조치(failover)(미리 보기) - 고객은 재해 복구 계획을 테스트하기 위해 스토리지 계정 장애 조치(failover)를 관리할 수 있습니다.
- 고객 관리(계획되지 않음) - 예기치 않은 서비스 중단이 발생한 경우 고객은 스토리지 계정 장애 조치(failover)를 관리할 수 있습니다.
- Microsoft 관리 장애 조치(failover) - 주 지역에서 심각한 재해가 발생하여 Microsoft에서 시작될 가능성이 있습니다. 1,2
1 Microsoft 관리 장애 조치(failover)는 개별 스토리지 계정, 구독 또는 테넌트에 대해 시작할 수 없습니다. 자세한 내용은 Microsoft 관리형 장애 조치(failover)를 참조하세요.
2 고객 관리 장애 조치(failover) 옵션을 사용하여 재해 복구 계획을 개발, 테스트 및 구현합니다. 극단적인 상황에서만 사용되는 Microsoft 관리 장애 조치(failover)에 의존하지 마세요.
각 유형의 장애 조치(failover)에는 고유한 사용 사례 집합, 데이터 손실에 대한 해당 기대, 계층 구조 네임스페이스가 활성화된 계정에 대한 지원(Azure Data Lake Storage)이 있습니다. 이 표에서는 각 장애 조치(failover) 유형의 이러한 측면을 요약합니다.
| Type | 장애 조치(failover) 범위 | 사용 사례 | 예상 데이터 손실 | HNS(계층 구조 네임스페이스)가 지원됨 |
|---|---|---|---|---|
| 고객 관리 계획 장애 조치(failover)(미리 보기) | 스토리지 계정 | 주 및 보조 지역의 스토리지 서비스 엔드포인트를 사용할 수 있으며 재해 복구 테스트를 수행하려고 합니다. 주 지역의 스토리지 서비스 엔드포인트는 사용 가능하지만 다른 서비스로 인해 워크로드가 제대로 작동하지 않습니다. 지역에 영향을 줄 수 있는 허리케인과 같은 대규모 재해에 사전에 대비합니다. |
No | 예 (미리 보기) |
| 고객 관리(계획되지 않음) 장애 조치(failover) | 스토리지 계정 | 주 지역에 대한 스토리지 서비스 엔드포인트를 사용할 수 없게 되지만 보조 지역을 사용할 수 있습니다. 중단으로 인해 잠재적으로 영향을 받을 수 있는 스토리지 계정의 장애 조치(failover) 작업을 수행하도록 Microsoft에서 권고하는 Azure 권고를 받았습니다. |
예 | 예 (미리 보기) |
| Microsoft 관리 | 전체 지역 | 심각한 재해로 인해 주 지역을 사용할 수 없지만 보조 지역은 사용할 수 있습니다. | 예 | 예 |
다음 표는 각 형식의 장애 조치(failover) 후 스토리지 계정의 중복 상태를 비교합니다.
| 장애 조치(failover)의 결과... | 고객 관리 계획 장애 조치(failover)(미리 보기) | 고객 관리(계획되지 않음) 장애 조치(failover) |
|---|---|---|
| ...보조 지역 | 보조 지역이 새 주 지역이 됩니다. | 보조 지역이 새 주 지역이 됩니다. |
| ...원래의 주 지역 | 원래의 주 지역이 새로운 보조 지역이 됩니다. | 원래 주 지역에 있는 데이터의 복사본이 삭제됩니다. |
| ...계정 중복 구성 | 스토리지 계정이 GRS로 변환됩니다. | 스토리지 계정이 LRS로 변환됩니다. |
| ...지리적 중복성 구성 | 지리적 중복성이 보존됩니다. | 지역 중복이 손실됩니다. |
다음 표는 각 형식의 장애 조치(failover)에 대한 장애 조치(failover) 및 장애 복구(failback) 프로세스의 모든 단계에서 발생하는 중복성 구성을 요약한 것입니다.
| Original configuration |
이후 failover |
다시 사용하도록 설정한 후 지역 중복 |
이후 장애 복구 |
다시 사용하도록 설정한 후 지역 중복 |
|---|---|---|---|---|
| 고객 관리 계획 장애 조치(failover) | ||||
| GRS | GRS | 해당 없음 1 | GRS | 해당 없음 1 |
| GZRS | GRS | 해당 없음 1 | GZRS | 해당 없음 1 |
| 고객 관리(계획되지 않음) 장애 조치(failover) | ||||
| GRS | LRS | GRS | LRS | GRS |
| GZRS | LRS | GRS | ZRS | GZRS |
1 계획된 장애 조치(failover) 동안 지리적 중복성이 보존되므로 수동으로 다시 구성할 필요가 없습니다.
고객 관리 계획 장애 조치(failover)(미리 보기)
계획된 장애 조치(failover)는 계획된 재해 복구 테스트, 대규모 재해에 대한 사전 예방적 접근 방식 또는 비스토리지 관련 중단으로부터 복구하는 등의 여러 시나리오에서 활용할 수 있습니다.
계획된 장애 조치(failover) 프로세스 중에 주 및 보조 지역이 바뀝니다. 원래의 주 지역이 강등되고 새로운 보조 지역이 됩니다. 동시에 원래의 보조 지역이 승격되어 새 주 지역이 됩니다. 장애 조치(failover)가 완료되면 사용자는 새로운 주 지역의 데이터에 액세스할 수 있으며 관리자는 재해 복구 계획의 유효성을 검사할 수 있습니다. 계획된 장애 조치(failover)를 시작하려면 주 및 보조 지역 모두에서 스토리지 계정을 사용할 수 있어야 합니다.
주 및 보조 지역이 전체 프로세스에서 사용 가능한 한 계획된 장애 조치(failover) 및 장애 복구(failback) 프로세스 중에 데이터 손실은 예상되지 않습니다. 자세한 내용은 데이터 손실 및 불일치 예상 섹션을 참조하세요.
이러한 형식의 장애 조치(failover)가 사용자와 애플리케이션에 미치는 영향을 이해하려면 계획된 장애 조치(failover) 및 장애 복구(failback) 프로세스의 각 단계에서 어떤 일이 발생하는지 아는 것이 좋습니다. 이 프로세스가 작동하는 방식에 대한 자세한 내용은 고객 관리(계획됨) 장애 조치(failover) 작동 방식을 참조하세요.
Important
고객 관리 계획 장애 조치(failover)는 현재 미리 보기 상태이며 다음 지역으로 제한됩니다.
- 프랑스 중부
- 프랑스 남부
- 인도 중부
- 인도 서부
- 동아시아
- 동남아시아
베타, 미리 보기로 제공되거나 아직 일반 공급으로 릴리스되지 않은 Azure 기능에 적용되는 약관은 Microsoft Azure 미리 보기에 대한 추가 사용 약관을 참조하세요.
Important
계획된 장애 조치(failover) 후 Azure Files 데이터가 있으면 스토리지 계정의 LST(마지막 동기화 시간) 값이 오래되었거나 NULL로 보고될 수 있습니다.
일관된 복구 지점을 유지하기 위해 장애 조치(failover) 및 장애 복구(failback) 중에 사용되는 스토리지 계정의 보조 지역에 시스템 스냅샷이 주기적으로 만들어집니다. 고객 관리 계획 장애 조치(failover)를 시작하면 원래 주 지역이 새로운 보조 지역이 됩니다. 계획된 장애 조치(failover)가 완료된 후 새 보조 데이터베이스에 사용 가능한 시스템 스냅샷이 없는 경우가 있어 계정의 전체 LST 값이 오래되었거나 Null로 표시되는 경우가 있습니다.
개체 만들기, 수정 또는 삭제와 같은 사용자 작업으로 인해 스냅샷 만들기가 트리거될 수 있으므로 계획된 장애 조치(failover) 이후 이러한 작업이 발생하는 계정에는 추가적인 주의가 필요하지 않습니다. 그러나 스냅샷이나 사용자 작업이 없는 계정은 시스템 스냅샷 만들기가 트리거될 때까지 Null LST 값을 계속 표시할 수 있습니다.
필요한 경우 스토리지 계정 내의 각 공유에 대해 다음 작업 중 하나를 수행하여 스냅샷 만들기를 트리거합니다. 완료되면 30분 이내에 사용자의 계정에 유효한 LST 값이 표시됩니다.
- 공유를 탑재한 다음, 모든 파일을 읽기용으로 엽니다.
- 테스트 또는 샘플 파일을 공유에 업로드합니다.
고객 관리(계획되지 않음) 장애 조치(failover)
스토리지 계정의 스토리지 서비스에 대한 데이터 엔드포인트를 주 지역에서 사용할 수 없게 되면 보조 지역으로 계획되지 않은 장애 조치(failover)를 시작할 수 있습니다. 장애 조치(failover)가 완료되면 보조 지역이 새로운 주 지역이 되고 사용자는 해당 지역 내에서 데이터에 액세스할 수 있습니다.
이러한 형식의 장애 조치(failover)가 사용자와 애플리케이션에 미치는 영향을 이해하려면 계획되지 않은 장애 조치(failover) 및 장애 복구(failback) 프로세스의 각 단계에서 어떤 일이 발생하는지 아는 것이 좋습니다. 프로세스 작동 방식에 대한 자세한 내용은 고객 관리(계획되지 않음) 장애 조치(failover) 작동 방식을 참조하세요.
Microsoft에서 관리하는 장애 조치(failover)
Microsoft는 전체 지역에 영향을 주는 치명적인 재해와 같은 극단적인 상황에서 지역 장애 조치(failover)를 시작할 수 있습니다. 이런 이벤트가 일어나는 동안에는 사용자가 아무런 조치를 취할 필요가 없습니다. 스토리지 계정이 RA-GRS 또는 RA-GZRS로 구성된 경우 애플리케이션은 Microsoft에서 관리하는 장애 조치(failover) 중에 보조 지역에서 읽을 수 있습니다. 하지만 장애 조치(failover) 프로세스가 완료될 때까지는 스토리지 계정에 대한 쓰기 권한이 없습니다.
Important
고객 관리 장애 조치(failover) 옵션을 사용하여 재해 복구 계획을 개발, 테스트 및 구현합니다. 극단적인 상황에서만 사용될 수 있는 Microsoft 관리 장애 조치(failover)에 의존하지 마세요. Microsoft에서 관리하는 장애 조치(failover)는 지역이나 데이터 센터와 같은 전체 실제 단위에 대해 시작됩니다. 개별 스토리지 계정, 구독 또는 테넌트에 대해서는 시작할 수 없습니다. 개별 스토리지 계정을 선택적으로 장애 조치(failover)할 수 있는 기능이 필요한 경우 고객 관리 계획 장애 조치(failover)를 사용합니다.
데이터 손실 및 불일치 예상
주의
고객이 관리하는 계획되지 않은 장애 조치(failover)는 일반적으로 어느 정도의 데이터 손실을 수반하며, 잠재적으로 파일 및 데이터 불일치가 발생할 수도 있습니다. 재해 복구 계획에서 계정 장애 조치(failover)를 시작하기 전에 계정 장애 조치(failover)가 데이터에 미치는 영향을 고려하는 것이 중요합니다.
데이터는 비동기적으로 주 지역에서 보조 지역으로 기록되므로 주 지역에 대한 쓰기가 보조 지역으로 복사되기 전에 항상 지연이 발생합니다. 주 지역을 사용할 수 없게 되면 가장 최근의 쓰기가 보조 지역에 아직 복사되지 않았을 수 있습니다.
계획되지 않은 장애 조치(failover)가 발생하면 보조 지역이 새로운 주 지역이 되면서 주 지역의 모든 데이터가 손실됩니다. 장애 조치(failover)가 발생하면 이미 보조 지역에 복사된 모든 데이터가 유지됩니다. 그러나 보조 지역에 아직 존재하지 않는 주 지역에 쓰여진 모든 데이터는 영구적으로 손실됩니다.
새 주 지역은 장애 조치(failover) 후 로컬 중복(LRS)이 되도록 구성됩니다.
스토리지 계정에 다음 중 하나 이상을 사용하도록 설정한 경우 파일 또는 데이터 불일치가 발생할 수도 있습니다.
마지막 동기화 시간
마지막 동기화 시간 속성은 주 지역의 데이터가 보조 지역에 기록된 가장 최근 시간을 나타냅니다. 계층 구조 네임스페이스가 있는 계정의 경우 동일한 마지막 동기화 시간 속성이 ACL(액세스 제어 목록)을 포함하여 계층 구조 네임스페이스에서 관리하는 메타데이터에도 적용됩니다. 마지막 동기화 시간 전에 작성된 모든 데이터와 메타데이터는 보조 데이터베이스에서 사용할 수 있습니다. 반면, 마지막 동기화 시간 이후에 작성된 데이터와 메타데이터는 아직 보조 데이터베이스에 복사되지 않아 잠재적으로 손실될 수 있습니다. 중단 중에 이 속성을 사용하여 계정 장애 조치(failover)를 시작할 때 발생할 수 있는 데이터 손실량을 예상합니다.
모범 사례로, 마지막 동기화 시간을 사용하여 예상되는 데이터 손실을 예측할 수 있도록 애플리케이션을 디자인합니다. 예를 들어, 모든 쓰기 작업을 로깅하면 마지막 쓰기 작업 시간을 마지막 동기화 시간과 비교할 수 있습니다. 이 방법을 사용하면 아직 보조 데이터베이스에 동기화되지 않아 손실될 위험이 있는 쓰기 항목을 확인할 수 있습니다.
마지막 동기화 시간 속성을 확인하는 방법에 대한 자세한 내용은 스토리지 계정에 대한 마지막 동기화 시간 속성 확인을 참조하세요.
Azure Data Lake Storage에 대한 파일 일관성
계층 구조 네임스페이스를 사용하도록 설정된 스토리지 계정에 대한 복제(Azure Data Lake Storage) 는 파일 수준에서 발생합니다. 이 수준에서 복제가 발생하기 때문에 주 지역에서 중단이 발생하면 컨테이너나 디렉터리 내의 일부 파일이 보조 지역으로 성공적으로 복제되지 않을 수 있습니다. 스토리지 계정 장애 조치(failover) 후 컨테이너 또는 디렉터리 내의 모든 파일에 대한 일관성이 보장되지 않습니다.
변경 피드와 BLOB 데이터 불일치
변경 피드가 사용하도록 설정된 스토리지 계정의 고객 관리(계획되지 않음) 장애 조치(failover)로 인해 변경 피드 로그와 Blob 데이터 및/또는 메타데이터 간에 불일치가 발생할 수 있습니다. 이러한 불일치는 주 및 보조 지역 간의 변경 로그 업데이트와 데이터 복제의 비동기적 특성으로 인해 발생할 수 있습니다. 다음 예방 조치를 취하면 불일치를 피할 수 있습니다.
- 모든 로그 레코드가 로그 파일에 플러시되었는지 확인합니다.
- 모든 스토리지 데이터가 주 지역에서 보조 지역으로 복제되었는지 확인합니다.
변경 피드에 대한 자세한 내용은 변경 피드 작동 방식을 참조하세요.
다른 스토리지 계정 기능을 사용하려면 변경 피드를 사용하도록 설정해야 합니다. 이러한 기능에는 Azure Blob Storage의 운영 백업, 개체 복제 및 블록 Blob에 대한 특정 시점 복원이 포함됩니다.
특정 시점 복원 불일치
고객 관리 장애 조치(failover)는 블록 Blob을 포함하는 범용 v2 표준 계층 스토리지 계정에 대해 지원됩니다. 그러나, 스토리지 계정에서 고객 관리 장애 조치(failover)를 수행하면 해당 계정에 대해 가능한 가장 빠른 복원 지점이 다시 설정됩니다. 블록 Blob에 대한 특정 시점 복원에 대한 데이터는 장애 조치 완료 시간까지만 일치합니다. 따라서 장애 조치(failover) 완료 시간 이후의 특정 시점까지만 블록 Blob을 복원할 수 있습니다. Azure Portal의 스토리지 계정 중복 탭에서 장애 조치(failover) 완료 시간을 검사 수 있습니다.
장애 조치(failover)의 시간과 비용
고객 관리 장애 조치(failover)가 시작된 후 완료되는 데 걸리는 시간은 다를 수 있지만 일반적으로 1시간 미만이 소요됩니다.
계획된 고객 관리 장애 조치(failover)는 장애 조치(failover) 및 그에 따른 장애 복구(failback) 후에도 지리적 중복성을 잃지 않지만, 계획되지 않은 고객 관리 장애 조치(failover)는 지리적 중복성을 잃습니다.
고객 관리 예기치 못한 장애 조치(failover)를 시작하면 스토리지 계정이 새 주 지역 내의 LRS(로컬 중복 스토리지)로 자동 변환되고, 원래 주 지역의 스토리지 계정이 삭제됩니다.
계정에 대해 GRS(지역 중복 스토리지) 또는 RA-GRS(읽기 액세스 지역 중복 스토리지)를 다시 사용하도록 설정할 수 있지만, 새 보조 지역으로 데이터를 다시 복제하면 요금이 부과됩니다. 또한, 지리적 중복성을 위해 계정을 다시 구성하기 전에 보관된 모든 Blob을 온라인 계층으로 다시 리하이드레이션해야 합니다. 이러한 리하이드레이션에는 추가 요금이 발생합니다. 가격 책정에 대한 자세한 내용은 다음을 참조하세요.
스토리지 계정에 대해 GRS를 다시 사용하면 계정의 데이터가 새 보조 지역으로 복제되기 시작합니다. 복제가 완료되는 데 걸리는 시간은 여러 가지 요인에 따라 달라집니다. 이러한 요인에는 다음이 포함됩니다.
- 스토리지 계정의 개체 수 및 크기 많은 작은 개체를 복제하는 것이 더 적은 수의 더 큰 개체를 복제하는 것보다 더 오래 걸릴 수 있습니다.
- CPU, 메모리, 디스크 및 WAN 용량과 같은 백그라운드 복제에 사용할 수 있는 리소스입니다. 라이브 트래픽은 지역 복제보다 우선합니다.
- 해당되는 경우, Blob당 스냅샷 수입니다.
- 스토리지 계정에 테이블이 포함된 경우 데이터 분할 전략입니다. 복제 프로세스는 사용하는 파티션 키 수를 초과하여 확장할 수 없습니다.
지원되는 스토리지 계정 형식
모든 지역 중복 제품은 Microsoft 관리 장애 조치(failover)를 지원합니다. 또한 다음 표와 같이 일부 계정 유형은 고객 관리형 계정 장애 조치를 지원합니다.
| 장애 조치(failover) 유형 | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|
| 고객 관리 계획 장애 조치(failover)(미리 보기) | 범용 v2 계정 범용 v1 계정 레거시 Blob Storage 계정 |
범용 v2 계정 |
| 고객 관리(계획되지 않음) 장애 조치(failover) | 범용 v2 계정 범용 v1 계정 레거시 Blob Storage 계정 |
범용 v2 계정 |
| Microsoft에서 관리하는 장애 조치(failover) | 모든 계정 유형 | 범용 v2 계정 |
클래식 스토리지 계정
Important
고객 관리 장애 조치(failover)는 ARM(Azure Resource Manager) 배포 모델을 사용하여 배포된 스토리지 계정에만 지원됩니다. ASM(Azure Service Manager) 배포 모델(클래식 모델이라고도 함)은 지원되지 않습니다. 클래식 스토리지 계정이 고객 관리형 계정 장애 조치에 적합하도록 하려면 먼저 ARM 모델로 마이그레이션해야 합니다. 업그레이드를 수행하려면 스토리지 계정에 액세스할 수 있어야 하므로 주 지역은 현재 실패 상태일 수 없습니다.
주 지역에 영향을 미치는 재해가 발생하는 경우 Microsoft는 계층 클래식 스토리지 계정에 대한 장애 조치(failover)를 관리합니다. 자세한 내용은 Microsoft 관리형 장애 조치(failover)를 참조하세요.
HNS(계층 구조 네임스페이스)
Important
Azure Data Lake Storage Gen2를 사용하도록 설정한 계정에 대한 고객 관리(계획되지 않은) 장애 조치(failover)는 현재 미리 보기로 제공되며 모든 공용 GRS/GZRS 지역에서 지원됩니다.
베타, 미리 보기로 제공되거나 아직 일반 공급으로 릴리스되지 않은 Azure 기능에 적용되는 약관은 Microsoft Azure 미리 보기에 대한 추가 사용 약관을 참조하세요.
Important
SFTP(SSH 파일 전송 프로토콜)가 사용하도록 설정된 계정에 대한 고객 관리(계획되지 않은) 장애 조치(failover)는 현재 미리 보기로 제공되며 모든 공용 GRS/GZRS 지역에서 지원됩니다.
베타, 미리 보기로 제공되거나 아직 일반 공급으로 릴리스되지 않은 Azure 기능에 적용되는 약관은 Microsoft Azure 미리 보기에 대한 추가 사용 약관을 참조하세요.
지원되지 않는 기능 및 서비스
고객 관리 장애 조치(failover)에는 다음 기능과 서비스가 지원되지 않습니다.
- Azure 파일 동기화는 고객이 관리하는 계정 장애 조치(failover)를 지원하지 않습니다. Azure 파일 동기화의 클라우드 엔드포인트로 사용되는 스토리지 계정은 장애 조치(failover)되어서는 안 됩니다. 장애 조치(failover)로 인해 파일 동기화가 중단되고 새로 계층화된 파일의 예기치 못한 데이터 손실이 발생할 수 있습니다. 자세한 내용은 Azure 파일 동기화를 사용한 재해 복구 모범 사례를 참조하세요.
- 프리미엄 블록 Blob을 포함하는 스토리지 계정은 장애 조치(failover)할 수 없습니다. 프리미엄 블록 Blob을 지원하는 스토리지 계정은 현재 지역 중복을 지원하지 않습니다.
- 고객 관리 장애 조치(failover)는 개체 복제 정책의 원본 또는 대상 계정에 대해 지원되지 않습니다.
- NFS(Network File System) 3.0(NFSv3)은 스토리지 계정 장애 조치(failover)에 대해 지원되지 않습니다. NFSv3를 사용하도록 설정된 지역 중복성을 위해 구성된 스토리지 계정은 만들 수 없습니다.
다음 표는 기능 지원을 참조하는 데 사용할 수 있습니다.
| 계획된 장애 조치 | 계획되지 않은 장애 조치(Failover) | |
|---|---|---|
| Azure Data Lake Storage | 지원됨(미리 보기) | 지원됨(미리 보기) |
| 변경 피드 | 지원되지 않음 | 지원 여부 |
| 개체 복제 | 지원되지 않음 | 지원되지 않음 |
| SFTP | 지원됨(미리 보기) | 지원됨(미리 보기) |
| NFSv3 | GRS가 지원되지 않음 | GRS가 지원되지 않음 |
| 스토리지 작업 | 지원됨1 | 지원됨1 |
| PITR(특정 시점 복원) | 지원되지 않음 | 지원 여부 |
1 고객 관리형 계획 또는 계획된 장애조치 시작하는 경우 스토리지 작업은 원래 주 지역으로 장애 복구(fail back)될 때까지 계정에서 작동할 수 없습니다. 자세히 알아보기.
장애 조치(failover)는 계정 마이그레이션을 위한 것이 아닙니다.
스토리지 계정 장애 조치(failover)는 DR(재해 복구) 계획을 개발 및 테스트하거나 서비스 중단에서 복구하는 데 사용되는 임시 솔루션입니다. 장애 조치(failover)는 데이터 마이그레이션 전략의 일부로 사용되어서는 안 됩니다. 스토리지 계정을 마이그레이션하는 방법에 대한 자세한 내용은 Azure Storage 마이그레이션 개요를 참조하세요.
보관된 BLOB을 포함하는 스토리지 계정
보관된 BLOB을 포함하는 스토리지 계정은 계정 장애 조치(failover)를 지원합니다. 그러나 고객 관리 장애 조치(failover)가 완료된 후에는 계정이 지역 중복을 위해 구성되기 전에 보관된 모든 Blob을 온라인 계층으로 리하이드레이션해야 합니다.
스토리지 리소스 공급자
Microsoft는 Azure Storage 리소스로 작업하기 위한 두 가지 REST API를 제공합니다. 두 API는 Azure Storage에 대해 수행할 수 있는 모든 작업의 기초를 형성합니다. Azure Storage REST API를 사용하면 Blob, 큐, 파일, 테이블 데이터를 포함하여 스토리지 계정의 데이터로 작업할 수 있습니다. Azure Storage 리소스 공급자 REST API를 사용하면 스토리지 계정 및 관련 리소스를 관리할 수 있습니다.
장애 조치(failover)가 완료되면 클라이언트는 다시 한 번 새 주 지역에서 Azure Storage 데이터를 읽고 쓸 수 있습니다. 그러나 Azure Storage 리소스 공급자는 장애 조치(failover)되지 않으므로 리소스 관리 작업은 주 지역에서 계속 수행되어야 합니다. 주 지역을 사용할 수 없는 경우 스토리지 계정에서 관리 작업을 수행할 수 없습니다.
Azure Storage 리소스 공급자는 장애 조치(failover)를 수행하지 않으므로 장애 조치(failover)가 완료된 후 Location 속성은 원래 기본 위치를 반환합니다.
Azure 가상 머신
Azure VM(Virtual Machines)은 스토리지 계정 장애 조치(failover)의 일부로 장애 조치(failover)되지 않습니다. 중단에 응답하여 보조 지역으로 장애 조치(failover)된 모든 VM은 장애 조치(failover)가 완료된 후 다시 만들어야 합니다. 계정 장애 조치(failover)로 인해 VM(가상 머신)이 종료될 때 임시 디스크에 저장된 데이터가 손실될 가능성이 있습니다. Microsoft는 Azure의 가상 머신과 관련하여 다음과 같은 고가용성 및 재해 복구 지침을 권장합니다.
Azure 관리되지 않는 디스크
관리되지 않는 디스크는 Azure Storage에 페이지 Blob으로 저장됩니다. VM을 Azure에서 실행 중인 경우 VM에 연결된 모든 관리되지 않는 디스크가 임대됩니다. BLOB에 임대가 있으면 계정 장애 조치(failover)를 계속할 수 없습니다. Azure VM에 연결된 비관리 디스크가 있는 계정에서 장애 조치(failover)를 시작하려면 먼저 디스크를 종료해야 합니다. 이러한 이유로 Microsoft에서 권장하는 모범 사례에는 비관리 디스크를 관리 디스크로 변환하는 것이 포함됩니다.
비관리 디스크가 포함된 계정에서 장애 조치(failover)를 수행하려면 다음 단계를 따릅니다.
- 시작하기 전에 비관리 디스크, 해당 LUN(논리 단위 번호) 및 해당 디스크가 연결된 VM을 기록해 둡니다. 이렇게 하면 장애 조치(failover) 후에 디스크를 보다 쉽게 다시 연결할 수 있습니다.
- VM을 종료합니다.
- VM을 삭제하지만 비관리 디스크의 VHD(가상 하드 디스크) 파일은 보존합니다. VM을 삭제한 시간을 기록해 둡니다.
- 마지막 동기화 시간이 업데이트될 때까지 기다리고, 이 시간이 VM을 삭제한 시간보다 이후인지 확인합니다. 이 단계에서는 장애 조치(failover)가 발생할 때 보조 엔드포인트가 VHD 파일로 완전히 업데이트되었는지 확인하고, VM이 새 주 지역에서 제대로 작동하는지 확인합니다.
- 계정 장애 조치(failover)를 시작합니다.
- 계정 장애 조치(failover)가 완료되고 보조 지역이 새로운 주 지역이 될 때까지 기다립니다.
- 새 주 지역에서 VM을 만들고 VHD를 다시 연결합니다.
- 새 VM을 시작합니다.
VM이 종료되면 임시 디스크에 저장된 데이터가 손실됩니다.
장애 조치(failover) 대안으로 데이터 복사
이전에 설명한 대로, 보조 지역에 대한 읽기 권한이 구성된 스토리지 계정을 사용하도록 애플리케이션을 구성하여 고가용성을 유지할 수 있습니다. 그러나 주 지역 내에서 중단 중에 장애 조치(failover)를 수행하고 싶지 않으면 대안으로 데이터를 수동으로 복사할 수 있습니다. AzCopy 및 Azure PowerShell과 같은 도구를 사용하면 영향을 받는 지역의 스토리지 계정에서 영향을 받지 않은 지역의 다른 스토리지 계정으로 데이터를 복사할 수 있습니다. 복사 작업이 완료된 후에는 영향을 받지 않은 지역의 스토리지 계정을 사용하여 읽기 및 쓰기 가용성을 모두 확보하도록 애플리케이션을 다시 구성할 수 있습니다.
고가용성을 위한 디자인
처음부터 고가용성을 위해 애플리케이션을 디자인하는 것이 중요합니다. 애플리케이션을 디자인하고 재해 복구를 계획하기 위한 지침에 대해서는 다음 Azure 리소스를 참조하세요.
- Azure용 복원 애플리케이션 디자인: Azure에서 고가용성 애플리케이션을 설계하기 위한 주요 개념을 간략하게 설명합니다.
- 복원력 검사 목록: 애플리케이션이 고가용성을 위한 디자인 모범 사례를 구현하는지 확인하기 위한 검사 목록입니다.
- 지리적 중복성을 사용하여 고가용성 애플리케이션 설계: 지역 중복 스토리지를 활용하는 애플리케이션을 빌드하기 위한 설계 지침입니다.
- 자습서: Blob Storage로 고가용성 애플리케이션 빌드: 실패 및 복구를 시뮬레이션할 때 엔드포인트 간을 자동으로 전환하는 고가용성 애플리케이션을 빌드하는 방법을 보여주는 자습서입니다.
Azure Storage 데이터의 고가용성을 유지하려면 다음 모범 사례를 참조하세요.
- Disks: Azure Backup을 사용하여 Azure Virtual Machines에서 사용하는 VM 디스크를 백업합니다. 지역 재해로부터 VM을 보호하려면 Azure Site Recovery를 사용하는 것도 고려해보세요.
- 블록 Blob: 일시 삭제를 설정하여 개체 수준 삭제 및 덮어쓰기에 대해 보호하거나 AzCopy, Azure PowerShell 또는 Azure 데이터 이동 라이브러리를 사용하여 다른 지역에 있는 다른 스토리지 계정에 블록 Blob을 복사합니다.
- 파일: Azure Backup을 사용하여 파일 공유를 백업합니다. 또한 실수로 인한 파일 공유 삭제로부터 보호하기 위해 일시 삭제를 사용하도록 설정합니다. GRS를 사용할 수 없을 때 지역 중복을 위해 AzCopy 또는 Azure PowerShell을 사용하여 다른 지역의 다른 스토리지 계정에 파일을 복사합니다.
- 테이블: AzCopy를 사용하여 다른 지역에 있는 다른 스토리지 계정으로 테이블 데이터를 내보냅니다.
중단 추적
고객은 Azure Service Health 대시보드를 구독하여 Azure Storage 및 다른 Azure 서비스의 상태를 추적할 수 있습니다.
쓰기 오류의 가능성에 대비하도록 애플리케이션을 디자인하는 것이 좋습니다. 애플리케이션은 주 지역의 가동 중단 가능성을 경고하는 방식으로 쓰기 오류를 공개해야 합니다.