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

  • 아티클

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

Important

Azure 파일 동기화는 스토리지 동기화 서비스도 장애 조치(failover)된 경우에만 스토리지 계정 장애 조치(failover)를 지원합니다. 이는 Azure 파일 동기화를 위해서는 스토리지 계정과 스토리지 동기화 서비스가 동일한 Azure 지역에 있어야 하기 때문입니다. 스토리지 계정만 장애 조치(failover)되는 경우 스토리지 동기화 서비스가 보조 지역으로 장애 조치(failover)될 때까지 동기화 및 클라우드 계층화 작업이 실패합니다. Azure 파일 동기화에서 클라우드 엔드포인트로 사용되는 Azure 파일 공유가 포함된 스토리지 계정을 장애 조치(failover)하려면 Azure 파일 동기화 재해 복구 모범 사례 및 Azure 파일 동기화 서버 복구를 참조하세요.

복구 메트릭 및 비용

효과적인 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 Service Health 대시보드를 구독하여 Azure Files 및 다른 Azure 서비스의 상태를 추적할 수 있습니다.

계정 장애 조치(failover) 프로세스 이해

고객이 관리하는 계정 장애 조치(failover)를 사용하면 어떤 이유로든 주 지역을 사용할 수 없게 될 경우 전체 스토리지 계정을 보조 지역으로 장애 조치(failover)할 수 있습니다. 강제로 보조 지역으로 장애 조치(failover)하는 경우 클라이언트는 장애 조치(failover)가 완료된 후에 보조 엔드포인트에 데이터를 쓰기 시작할 수 있습니다. 장애 조치(failover)에는 일반적으로 약 1시간이 걸립니다. 계정 장애 조치(failover)를 시작하기 전에 워크로드를 최대한 많이 일시 중단하는 것이 좋습니다.

계정 장애 조치(failover)를 시작하는 방법을 알아보려면 계정 장애 조치(failover) 시작을 참조하세요.

계정 장애 조치(failover)가 작동하는 방식

정상적인 상황에서 클라이언트는 주 지역의 스토리지 계정에 데이터를 쓰며, 해당 데이터는 보조 지역에 비동기적으로 복사됩니다. 다음 그림은 주 지역을 사용할 수 있는 경우의 시나리오를 보여 줍니다.

클라이언트가 주 지역의 스토리지 계정에 데이터를 기록하는 방법을 보여 주는 다이어그램.

어떤 이유로든 기본 엔드포인트를 사용할 수 없는 경우 클라이언트는 스토리지 계정에 더 이상 쓸 수 없습니다. 다음 그림은 기본 엔드포인트를 사용할 수 없지만 복구가 아직 발생하지 않은 시나리오를 보여 줍니다.

기본 엔드포인트를 사용할 수 없으므로 클라이언트가 데이터를 쓸 수 없음을 보여 주는 다이어그램.

고객은 보조 엔드포인트에 대한 계정 장애 조치(failover)를 시작합니다. 장애 조치(failover) 프로세스는 Azure Storage에서 제공하는 DNS 항목을 업데이트하므로 다음 그림에 나와 있는 것처럼 보조 엔드포인트가 스토리지 계정의 새 기본 엔드포인트가 됩니다.

고객은 보조 엔드포인트로 계정 장애 조치(failover)를 시작함을 보여 주는 다이어그램.

DNS 항목이 업데이트되면 지역 중복 계정의 쓰기 액세스 권한이 복원되고 요청이 새 기본 엔드포인트로 전달됩니다. 기존 스토리지 서비스 엔드포인트는 장애 조치(failover) 후에도 동일하게 유지됩니다. 파일 핸들 및 임대는 장애 조치(failover)에 유지되지 않으므로 클라이언트는 파일 공유를 분리하고 다시 탑재해야 합니다.

Important

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

참고 항목