Azure Files에 대한 재해 복구 및 장애 조치(failover)
Microsoft는 Azure 서비스를 항상 사용할 수 있도록 하기 위해 노력합니다. 그러나 계획되지 않은 서비스 중단이 발생할 수 있으며 지역 서비스 중단을 처리하기 위한 DR(재해 복구) 계획이 있어야 합니다. 재해 복구 계획의 중요한 부분은 기본 엔드포인트를 사용할 수 없는 경우 보조 엔드포인트로의 장애 조치(failover)를 준비하는 것입니다. 이 문서에서는 DR(재해 복구) 및 스토리지 계정 장애 조치(failover)와 관련된 개념 및 프로세스에 대해 설명합니다.
Important
Azure 파일 동기화는 스토리지 동기화 서비스도 장애 조치(failover)된 경우에만 스토리지 계정 장애 조치(failover)를 지원합니다. 이는 Azure 파일 동기화를 위해서는 스토리지 계정과 스토리지 동기화 서비스가 동일한 Azure 지역에 있어야 하기 때문입니다. 스토리지 계정만 장애 조치(failover)되는 경우 스토리지 동기화 서비스가 보조 지역으로 장애 조치(failover)될 때까지 동기화 및 클라우드 계층화 작업이 실패합니다. Azure 파일 동기화에서 클라우드 엔드포인트로 사용되는 Azure 파일 공유가 포함된 스토리지 계정을 장애 조치(failover)하려면 Azure 파일 동기화 재해 복구 모범 사례 및 Azure 파일 동기화 서버 복구를 참조하세요.
고객 관리 계획 장애 조치(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 값이 표시됩니다.
- 공유를 탑재한 다음, 모든 파일을 읽기용으로 엽니다.
- 테스트 또는 샘플 파일을 공유에 업로드합니다.
복구 메트릭 및 비용
효과적인 DR 전략을 수립하기 위해서는 조직이 다음을 이해해야 합니다.
- 중단 시 유실될 수 있는 데이터 양(복구 지점 목표 또는 RPO)
- 비즈니스 기능 및 데이터를 복원할 수 있어야 하는 빈도(복구 시간 목표 또는 RTO)
DR의 비용은 일반적으로 RPO/RTO가 낮거나 0일 때 증가합니다. 재해 후 몇 초 내에 가동 및 실행해야 하며 데이터 손실을 감당할 수 없는 회사는 DR에 대해 더 많은 비용을 지불하지만, RPO/RTO 숫자가 높을수록 지불 비용이 줄어듭니다. Azure는 다양한 RPO 및 RTO 요구 사항에서 작동할 수 있는 솔루션을 제공합니다.
적절한 중복 옵션 선택
Azure Files는 일시적인 하드웨어 오류, 네트워크 및 정전에서 자연 재해에 이르기까지 계획되고 계획되지 않은 이벤트로부터 데이터를 보호하는 다양한 중복 옵션을 제공합니다. 모든 Azure 파일 공유는 LRS(로컬 중복 스토리지) 또는 ZRS(영역 중복 스토리지)를 사용할 수 있습니다. 자세한 내용은 Azure Files 중복도를 참조하세요.
Azure Files는 지역 가동 중단 방지를 위해 GRS(지역 중복 스토리지) 및 GZRS(지역 영역 중복 스토리지)로 구성된 표준 스토리지 계정에 대한 계정 장애 조치(failover)를 지원합니다. 계정 장애 조치(failover)의 경우 기본 엔드포인트를 사용할 수 없는 경우 스토리지 계정에 대해 장애 조치(failover) 프로세스를 시작할 수 있습니다. 장애 조치(failover)는 스토리지 계정의 기본 엔드포인트가 되도록 보조 엔드포인트를 업데이트합니다. 장애 조치(failover)가 완료되면 클라이언트는 새 기본 엔드포인트에 쓰기 시작할 수 있습니다.
데이터가 보조 지역에 비동기적으로 복사되기 때문에 GRS 및 GZRS는 여전히 데이터 손실의 위험을 수반합니다. 즉, 주 지역에 쓰기가 보조 지역에 복사되기까지 지연이 발생합니다. 중단이 발생할 경우 아직 보조 엔드포인트에 복사되지 않은 기본 엔드포인트에 대한 쓰기 작업은 손실됩니다. 즉, 주 지역을 복구할 수 없는 경우 주 지역에 영향을 미치는 오류가 발생하면 데이터가 손실될 수 있습니다. 주 지역에 최근 쓰기와 보조 지역에 마지막 쓰기 간 간격이 RPO(복구 지점 목표)입니다. Azure Files의 RPO는 일반적으로 15분 이하이지만 현재 보조 지역에 데이터를 복제하는 데 걸리는 시간에 대한 SLA는 없습니다.
Important
프리미엄 Azure 파일 공유에는 GRS/GZRS가 지원되지 않습니다. 하지만 두 개의 Azure 파일 공유 간에 동기화하여 지리적 중복성을 달성할 수 있습니다.
고가용성을 위한 디자인
처음부터 고가용성을 위해 애플리케이션을 디자인하는 것이 중요합니다. 애플리케이션을 디자인하고 재해 복구를 계획하기 위한 지침에 대해서는 다음 Azure 리소스를 참조하세요.
- Azure용 복원 애플리케이션 디자인: Azure에서 고가용성 애플리케이션을 설계하기 위한 주요 개념을 간략하게 설명합니다.
- 복원력 검사 목록: 애플리케이션이 고가용성을 위한 디자인 모범 사례를 구현하는지 확인하기 위한 검사 목록입니다.
- 지역 중복성을 사용하여 고가용성 애플리케이션 디자인: SMB 파일 공유를 위한 지역 중복 스토리지를 활용하는 애플리케이션 빌드를 위한 디자인 지침입니다.
또한 쓰기 오류의 가능성에 대비하도록 애플리케이션을 디자인하는 것이 좋습니다. 애플리케이션은 주 지역의 가동 중단 가능성을 경고하는 방식으로 쓰기 오류를 공개해야 합니다.
모범 사례로, 마지막 동기화 시간 속성을 확인하여 예상되는 데이터 손실을 예측하는 애플리케이션을 디자인합니다. 예를 들어, 모든 쓰기 작업을 기록하는 경우 마지막 쓰기 작업의 시간을 마지막 동기화 시간과 비교하여 보조 지역과 동기화되지 않은 쓰기를 확인할 수 있습니다.
중단 추적
Azure Service Health 대시보드를 구독하여 Azure Files 및 다른 Azure 서비스의 상태를 추적할 수 있습니다.
계정 장애 조치(failover) 프로세스 이해
고객이 관리하는 계정 장애 조치(failover)를 사용하면 어떤 이유로든 주 지역을 사용할 수 없게 될 경우 전체 스토리지 계정을 보조 지역으로 장애 조치(failover)할 수 있습니다. 강제로 보조 지역으로 장애 조치(failover)하는 경우 클라이언트는 장애 조치(failover)가 완료된 후에 보조 엔드포인트에 데이터를 쓰기 시작할 수 있습니다. 장애 조치(failover)에는 일반적으로 약 1시간이 걸립니다. 계정 장애 조치(failover)를 시작하기 전에 워크로드를 최대한 많이 일시 중단하는 것이 좋습니다.
계정 장애 조치(failover)를 시작하는 방법을 알아보려면 계정 장애 조치(failover) 시작을 참조하세요.
계정 장애 조치(failover)가 작동하는 방식
정상적인 상황에서 클라이언트는 주 지역의 스토리지 계정에 데이터를 쓰며, 해당 데이터는 보조 지역에 비동기적으로 복사됩니다. 다음 그림은 주 지역을 사용할 수 있는 경우의 시나리오를 보여 줍니다.
어떤 이유로든 기본 엔드포인트를 사용할 수 없는 경우 클라이언트는 스토리지 계정에 더 이상 쓸 수 없습니다. 다음 그림은 기본 엔드포인트를 사용할 수 없지만 복구가 아직 발생하지 않은 시나리오를 보여 줍니다.
고객은 보조 엔드포인트에 대한 계정 장애 조치(failover)를 시작합니다. 장애 조치(failover) 프로세스는 Azure Storage에서 제공하는 DNS 항목을 업데이트하므로 다음 그림에 나와 있는 것처럼 보조 엔드포인트가 스토리지 계정의 새 기본 엔드포인트가 됩니다.
DNS 항목이 업데이트되면 지역 중복 계정의 쓰기 액세스 권한이 복원되고 요청이 새 기본 엔드포인트로 전달됩니다. 기존 스토리지 서비스 엔드포인트는 장애 조치(failover) 후에도 동일하게 유지됩니다. 파일 핸들 및 임대는 장애 조치(failover)에 유지되지 않으므로 클라이언트는 파일 공유를 분리하고 다시 탑재해야 합니다.
Important
장애 조치(failover)를 완료한 후 스토리지 계정은 새 기본 엔드포인트/지역에서 로컬로 중복되도록 구성됩니다. 새 보조 엔드포인트로의 복제를 재개하려면 지리적 중복성에 대한 계정을 다시 구성합니다.
지역 중복을 사용하도록 로컬 중복 스토리지 계정을 변환하려면 비용과 시간이 필요합니다. 자세한 내용은 장애 조치(failover)의 시간과 비용을 참조하세요.
데이터 손실 예상
주의
계정 장애 조치(Failover)를 수행하면 일반적으로 데이터가 일부 손실됩니다. 계정 장애 조치(failover)를 시작할 때 진행되는 과정을 이해하는 것이 중요합니다.
데이터는 주 지역에서 보조 지역으로 비동기적으로 작성되기 때문에 주 지역을 사용할 수 없게 되면 가장 최근의 쓰기가 아직 보조 지역에 복사되지 않았을 수 있습니다.
장애 조치(failover)를 강제로 적용하면 보조 지역이 새 주 지역이 되기 때문에 주 지역의 모든 데이터가 손실됩니다. 새 주 지역은 장애 조치(failover) 후 로컬 중복이 되도록 구성됩니다.
장애 조치(failover)가 발생하면 보조 지역으로 이미 복사된 모든 데이터가 유지됩니다. 그러나 보조 지역으로 아직 복사되지 않은 주 지역에 쓴 데이터는 영구히 손실됩니다.
마지막 동기화 시간 속성 확인
마지막 동기화 시간(LST) 속성은 주 지역의 데이터가 보조 지역에 기록될 것으로 보장되는 가장 최근 시간을 나타냅니다. 마지막 동기화 시간 전에 기록된 모든 데이터는 보조 지역에서 사용할 수 있지만, 마지막 동기화 시간 이후에 기록된 데이터는 보조 지역에 기록되지 않았을 수 있으므로 손실되었을 수 있습니다. 작동 중단 시 이 속성을 사용하여 계정 장애 조치(failover) 시작으로 인해 발생할 수 있는 데이터 손실 크기를 예상합니다.
장애 조치(failover)가 발생할 때 파일 공유가 일관된 상태인지 확인하기 위해 시스템 스냅샷은 15분마다 주 지역에 만들어지고 보조 지역에 복제됩니다. 보조 지역으로 장애 조치(failover)가 발생하면 공유 상태는 보조 지역의 최신 시스템 스냅샷을 기반으로 합니다. 주 지역에서 오류가 발생하는 경우 주 지역에 대한 모든 쓰기가 아직 보조 지역에 복제되지 않았기 때문에 보조 지역이 주 지역 뒤에 있을 가능성이 높습니다. 지역 지연 또는 기타 문제로 인해 보조 지역의 최신 시스템 스냅샷이 15분 이상 오래되었을 수 있습니다.
LST 이전에 주 지역에 기록된 모든 쓰기 작업이 보조 지역에 성공적으로 복제되었으므로 보조 지역에서 읽을 수 있습니다. 마지막 동기화 시간 이후에 주 지역에 기록된 쓰기 작업은 보조 지역에 복제되었을 수도 있고 그렇지 않을 수도 있습니다. 즉, 읽기 작업에 사용하지 못할 수 있습니다.
Azure PowerShell, Azure CLI 또는 클라이언트 라이브러리를 사용하여 마지막 동기화 시간 속성의 값을 쿼리할 수 있습니다. 마지막 동기화 시간 속성은 GMT 날짜/시간 값입니다. 자세한 내용은 저장소 계정에 대한 마지막 동기화 시간 속성 확인을 참조하세요.
원래 주 지역으로 장애 복구(Failback)할 때 주의
앞서 언급했듯이, 주 지역에서 보조 지역으로 장애 조치(failover)하면 스토리지 계정이 새 주 지역에서 로컬로 중복되도록 구성됩니다. 그런 다음 지역 중복을 위해 새 주 지역에서 계정을 구성할 수 있습니다. 계정이 장애 조치(failover) 후 지역 중복을 위해 구성되면 새 주 지역은 원래 장애 조치(failover) 이전에 주 지역이었던 새 보조 지역으로 데이터를 즉시 복사하기 시작합니다. 그러나 새 주 지역의 기존 데이터가 새 보조 지역에 완전히 복사되기까지 다소 시간이 걸릴 수 있습니다.
스토리지 계정이 지역 중복을 위해 다시 구성되면 새 주 지역에서 새 보조 지역으로의 장애 복구(failback)를 시작할 수 있습니다. 이 경우 장애 조치(failover) 이전의 원래 주 지역은 다시 주 지역이 되며 원래 기본 구성이 GRS였는지 GZRS였는지에 따라 로컬 중복 또는 영역 중복이 되도록 구성됩니다. 장애 조치(failover) 이후 주 지역(원래 보조 지역)의 모든 데이터는 장애 복구(failback) 중에 손실됩니다. 스토리지 계정의 데이터 대부분이 장애 복구(failback) 전에 새 보조 지역에 복사되지 않으면 주요 데이터가 손실될 수 있습니다.
주요 데이터 손실을 방지하려면 장애 복구(failback) 전에 마지막 동기화 시간 속성 값을 확인합니다. 마지막 동기화 시간을 데이터를 새 주 지역에 마지막으로 기록한 시간과 비교하여 데이터 손실을 예측합니다.
장애 복구(failback) 작업 후에는 새 주 지역이 지역 중복이 되도록 다시 구성할 수 있습니다. 원래 주 지역이 LRS에 대해 구성된 경우에는 GRS가 되도록 구성할 수 있습니다. 원래 주 지역이 ZRS에 대해 구성된 경우에는 GZRS가 되도록 구성할 수 있습니다. 추가 옵션은 스토리지 계정 복제 방법 변경을 참조하세요.
계정 장애 조치(failover) 시작
Azure Portal, PowerShell, Azure CLI 또는 Azure Storage 리소스 공급자 API에서 계정 장애 조치(failover)를 시작할 수 있습니다. 장애 조치(failover)를 시작하는 방법에 대한 자세한 내용은 계정 장애 조치(failover) 시작을 참조하세요.
Microsoft에서 관리하는 장애 조치(failover)
중대한 재해로 인해 지역이 손실되는 극단적인 경우 Microsoft는 지역 장애 조치(failover)를 시작할 수 있습니다. 이 경우 사용자가 취해야 하는 조치는 없습니다. Microsoft에서 관리하는 장애 조치(failover)가 완료될 때까지 스토리지 계정에 대한 쓰기 액세스 권한이 없습니다.