Azure Files에 대한 재해 복구 및 장애 조치(failover)

Microsoft는 Azure 서비스를 항상 사용할 수 있도록 하기 위해 노력합니다. 그러나 계획되지 않은 서비스 중단이 발생할 수 있으며 지역 서비스 중단을 처리하기 위한 DR(재해 복구) 계획이 있어야 합니다. 재해 복구 계획의 중요한 부분은 기본 엔드포인트를 사용할 수 없는 경우 보조 엔드포인트로의 장애 조치(failover)를 준비하는 것입니다. 이 문서에서는 DR(재해 복구) 및 스토리지 계정 장애 조치(failover)와 관련된 개념 및 프로세스에 대해 설명합니다.

고객 관리 계획 장애 조치(failover)(미리 보기)

계획된 고객 관리 장애 조치(failover)는 또한 계획된 재해 복구 테스트, 대규모 재해에 대한 자동 관리 접근 또는 스토리지와 관련되지 않은 중단에서 복구하는 등 여러 가지 시나리오에서 활용할 수 있습니다.

계획된 장애 조치(failover) 프로세스 중에 주 및 보조 지역이 바뀝니다. 원래의 주 지역이 강등되고 새로운 보조 지역이 됩니다. 동시에 원래의 보조 지역이 승격되어 새 주 지역이 됩니다. 장애 조치(failover)가 완료되면 사용자는 새로운 주 지역의 데이터에 액세스할 수 있으며 관리자는 재해 복구 계획의 유효성을 검사할 수 있습니다. 계획된 장애 조치(failover)를 시작하려면 주 및 보조 지역 모두에서 스토리지 계정을 사용할 수 있어야 합니다.

주 및 보조 지역이 전체 프로세스에서 사용 가능한 한 계획된 장애 조치(failover) 및 장애 복구(failback) 프로세스 중에 데이터 손실은 예상되지 않습니다. 자세한 내용은 데이터 손실 및 불일치 예상 섹션을 참조하세요.

이러한 형식의 장애 조치(failover)가 사용자와 애플리케이션에 미치는 영향을 이해하려면 계획된 장애 조치(failover) 및 장애 복구(failback) 프로세스의 각 단계에서 어떤 일이 발생하는지 아는 것이 좋습니다. 이 프로세스가 작동하는 방식에 대한 자세한 내용은 고객 관리(계획됨) 장애 조치(failover) 작동 방식을 참조하세요.

복구 메트릭 및 비용

효과적인 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는 없습니다.

고가용성을 위한 디자인

처음부터 고가용성을 위해 애플리케이션을 디자인하는 것이 중요합니다. 애플리케이션을 디자인하고 재해 복구를 계획하기 위한 지침에 대해서는 다음 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)에 유지되지 않으므로 클라이언트는 파일 공유를 분리하고 다시 탑재해야 합니다.

데이터 손실 예상

데이터는 주 지역에서 보조 지역으로 비동기적으로 작성되기 때문에 주 지역을 사용할 수 없게 되면 가장 최근의 쓰기가 아직 보조 지역에 복사되지 않았을 수 있습니다.

장애 조치(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)가 완료될 때까지 스토리지 계정에 대한 쓰기 액세스 권한이 없습니다.

참고 항목

• Azure Files 중복성
• Azure Files 데이터 보호 개요
• 스토리지 계정 장애 조치(failover) 시작