Azure Private 5G Core에 대한 안정성
이 문서에서는 Azure Private 5G Core의 안정성 지원에 대해 설명합니다. 가용성 영역의 지역 복원력과 지역 간 재해 복구 및 비즈니스 연속성을 모두 다룹니다. Azure의 안정성에 대한 개요는 Azure 안정성을 참조하세요.
ASE(Azure Stack Edge) 디바이스 쌍에 HA(고가용성) 서비스로 Azure Private 5G Core를 배포할 수도 있습니다. 자세한 내용은 프라이빗 모바일 네트워크를 배포하기 위한 필수 구성 요소 작업 완료를 참조하세요.
가용성 영역 지원
Azure 가용성 영역은 각 Azure 지역 내에서 물리적으로 분리된 세 개 이상의 데이터 센터 그룹입니다. 각 영역 내의 데이터 센터에는 독립적인 전원, 냉각, 네트워킹 인프라가 장착되어 있습니다. 가용성 영역은 로컬 영역이 실패한 경우에 한 영역이 영향을 받는 경우 나머지 두 영역에서 지역 서비스, 용량 및 고가용성을 지원하도록 설계되었습니다.
오류는 소프트웨어 및 하드웨어 오류에서 지진, 홍수 및 화재와 같은 이벤트에 이르기까지 다양합니다. Azure 서비스의 중복성과 논리적 격리로 인해 오류 허용성에 도달합니다. Azure의 가용성 영역에 대한 자세한 내용은 지역 및 가용성 영역을 참조하세요.
Azure 가용성 영역 지원 서비스는 적절한 수준의 복원력과 유연성을 제공하도록 설계되었습니다. 두 가지 방법으로 구성할 수 있습니다. 영역 간 자동 복제를 사용하는 영역 중복 또는 특정 영역에 고정된 인스턴스를 사용하는 영역일 수 있습니다. 이러한 방식을 결합할 수도 있습니다. 영역 및 영역 중복 아키텍처에 대한 자세한 내용은 가용성 영역 및 지역 사용에 대한 권장 사항을 참조하세요.
Azure Private 5G Core 서비스는 가용성 영역 서비스 및 지역 지원에 나열된 대로 가용성 영역을 지원하는 Azure 지역에서 영역 중복으로 자동으로 배포됩니다. 지역에서 가용성 영역을 지원하는 경우 지역에서 만든 모든 Azure Private 5G Core 리소스를 가용성 영역에서 관리할 수 있습니다.
가용성 영역을 구성하거나 관리하는 데 추가 작업이 필요하지 않습니다. 가용성 영역 간의 장애 조치(failover)는 자동으로 수행됩니다.
필수 조건
Azure Private 5G Core를 사용할 수 있는 Azure 지역에 대해서는 지역별 사용할 수 있는 제품을 참조하세요.
영역 다운 환경
영역 전체 중단 시나리오에서는 서비스가 정상 영역을 자동으로 활용하기 위해 이동하므로 사용자에게 영향을 주지 않아야 합니다. 영역 전체 중단이 시작될 때 진행 중인 ARM 요청이 시간 초과되거나 실패하는 것을 확인할 수 있습니다. 새 요청은 사용자에게 영향을 주지 않는 정상 노드로 전달되며 실패한 작업은 다시 시도해야 합니다. 가동 중단 시 새 리소스를 만들고 기존 리소스를 업데이트, 모니터링 및 관리할 수 있습니다.
안전한 배포 기술
애플리케이션은 모든 클라우드 상태가 지역의 가용성 영역 간에 복제되어 모든 관리 작업이 중단 없이 계속되도록 합니다. 패킷 코어는 Edge에서 실행 중이며 영역 오류의 영향을 받지 않으므로 계속해서 사용자에게 서비스를 제공합니다.
지역 간 재해 복구 및 비즈니스 연속성
DR(재해 복구)은 가동 중지 시간 및 데이터 손실을 초래하는 자연 재해 또는 실패한 배포와 같은 영향이 큰 이벤트로부터 복구하는 것입니다. 원인에 관계없이 최상의 재해 해결책은 잘 정의되고 테스트된 DR 계획과 DR을 적극적으로 지원하는 애플리케이션 디자인입니다. 재해 복구 계획을 만들기 전에 재해 복구 전략을 디자인하기 위한 권장 사항을 참조하세요.
DR과 관련하여 Microsoft는 공유 책임 모델을 사용합니다. 공유 책임 모델에서 Microsoft는 기준 인프라 및 플랫폼 서비스를 사용할 수 있도록 보장합니다. 동시에 많은 Azure 서비스는 데이터를 자동으로 복제하거나 실패한 지역에서 대체하여 사용하도록 설정된 다른 지역으로 교차 복제하지 않습니다. 이러한 서비스의 경우 자신의 워크로드에 적합한 재해 복구 계획을 설정할 책임이 있습니다. Azure PaaS(Platform as a Service) 제품에서 실행되는 대부분의 서비스는 DR을 지원하는 기능과 지침을 제공하며, 서비스별 기능을 사용하여 빠른 복구를 지원하여 DR 계획을 개발하는 데 도움이 될 수 있습니다.
Azure Private 5G Core는 다중 지역(3+N) 지리적 영역에서만 사용할 수 있습니다. 서비스는 동일한 지역의 백업 지역에 SIM 자격 증명을 자동으로 복제합니다. 즉, 지역 오류가 발생할 경우에도 데이터가 손실되지 않습니다. 오류가 발생하고 4시간 이내에 실패한 지역의 모든 리소스를 Azure Portal 및 ARM 도구를 통해 볼 수 있지만 실패한 지역이 복구될 때까지는 읽기 전용입니다. Edge에서 실행되는 패킷 코어는 중단 없이 계속 작동하며 네트워크 연결은 유지됩니다.
Microsoft는 Azure Private 5G Core 서비스의 Azure 클라우드 측면에 대한 중단 검색, 알림 및 지원을 수행합니다.
중단 검색, 알림 및 관리
Microsoft는 기본 리소스를 모니터링하고 각 지역에서 Azure Private 5G Core 서비스를 제공합니다. 이러한 리소스가 단일 가용성 영역으로 제한되지 않는 오류 또는 상태 모니터링 경고를 표시하기 시작하면 Microsoft는 서비스를 동일한 지리적 영역의 지원되는 다른 지역으로 이동합니다. 이것은 활성-활성 패턴입니다. 특정 지역의 서비스 상태는 Azure Service Health에서 찾을 수 있습니다(Azure Private 5G Core는 네트워킹 섹션에 나열됨). 일반 Azure 통신 채널을 통해 지역 오류에 대한 알림을 받게 됩니다.
서비스는 Cosmos DB 다중 지역 쓰기를 사용하여 서비스가 소유한 SIM 자격 증명을 백업 지역에 자동으로 복제하므로 지역 오류가 발생할 경우에도 데이터가 손실되지 않습니다.
실패한 지역에 배포된 Azure Private 5G Core 리소스는 읽기 전용이 되지만 다른 모든 지역의 리소스는 영향을 받지 않고 계속 작동합니다. 항상 리소스를 작성할 수 있어야 하는 경우 재해 복구 및 중단 검색 설정의 지침에 따라 고유한 재해 복구 작업을 수행하고 다른 지역에서 서비스를 설정합니다.
Edge에서 실행되는 패킷 코어는 중단 없이 계속 작동하며 네트워크 연결은 유지됩니다.
재해 복구 및 중단 검색 설정
이 섹션에서는 지역 오류가 발생할 경우 Azure Private 5G Core 서비스에 대한 완전 활성 관리 평면이 있는지 확인하기 위해 수행할 수 있는 작업에 대해 설명합니다. 지역 오류가 발생할 경우 리소스를 수정하려면 이 작업이 필요합니다.
이로 인해 패킷 코어 서비스가 중단되고 최대 8시간 동안 ES에 대한 네트워크 연결이 중단되므로 Azure 지역이 다운된 동안 업무 차원에서 리소스를 관리해야 할 중요한 이유가 있는 경우에만 이 절차를 사용하는 것이 좋습니다.
재해 복구 이벤트에 앞서 Azure Private 5G Core를 지원하는 다른 지역에 리소스 구성을 백업해야 합니다. 지역 오류가 발생하면 백업 지역의 리소스를 사용하여 패킷 코어를 다시 배포할 수 있습니다.
준비
재해 복구를 위해 백업해야 하는 Azure Private 5G Core 구성 데이터에는 모바일 네트워크 구성 및 SIM 자격 증명의 두 가지 유형이 있습니다. 다음을 수행하는 것이 좋습니다.
- 주 지역에 새 SIM을 추가할 때마다 백업 지역에서 SIM 자격 증명 업데이트
- 모바일 네트워크 구성을 일주일에 한 번 이상 백업하거나 새 사이트 만들기와 같이 구성을 자주 또는 크게 변경하는 경우 더 자주 백업합니다.
모바일 네트워크 구성
리소스를 다른 지역으로 이동의 지침에 따라 Azure Private 5G Core 리소스 구성을 내보내고 새 지역에 업로드합니다. 백업 구성에 새 리소스 그룹을 사용하여 활성 구성과 명확하게 구분하는 것이 좋습니다. 주 지역의 리소스와 구분하기 위해 리소스에 새 이름을 지정해야 합니다. 이 새 지역은 수동 백업이므로 충돌을 방지하려면 패킷 코어 구성을 아직 에지 하드웨어에 연결해서는 안 됩니다. 대신 복구 절차를 수행할 사람이 액세스할 수 있는 안전한 위치에 있는 모든 패킷 코어에 대한 packetCoreControlPlanes.platform 필드의 값을 저장합니다(예: 내부 설명서에서 참조하는 스토리지 계정).
SIM 데이터
보안상의 이유로 Azure Private 5G Core는 SIM 만들기의 일부로 서비스에 제공되는 SIM 자격 증명을 반환하지 않습니다. 따라서 다른 Azure 리소스와 동일한 방식으로 SIM 구성을 내보낼 수 없습니다. 새 SIM을 주 서비스에 추가할 때마다 백업 모바일 네트워크에 대한 새 SIM 프로비전 프로세스를 반복하여 동일한 SIM도 백업 서비스에 추가하는 것이 좋습니다.
기타 리소스
Azure Private 5G Core 배포는 로컬 모니터링을 위해 SIM 암호화 키 또는 HTTPS 인증서를 저장하기 위해 Azure Key Vault를 사용할 수 있습니다. Azure Key Vault 설명서에 따라 백업 지역에서 키와 인증서를 사용할 수 있는지 확인해야 합니다.
복구
지역 오류가 발생하는 경우 먼저 Azure Portal 또는 API를 통해 구성을 쿼리하여 백업 지역의 모든 리소스가 있는지 확인합니다(다른 지역으로 리소스를 이동 참조). 일부 리소스만 있는 경우 여기서 중지하고 이 절차의 나머지 부분은 진행하지 마세요. 리소스 구성 없이는 에지 사이트에서 서비스를 복구하지 못할 수 있습니다.
복구 프로세스는 각 패킷 코어에 대해 다음 세 단계로 분할됩니다.
- 재설정을 수행하여 실패한 지역에서 Azure Stack Edge 디바이스 연결 끊기
- Azure Stack Edge 디바이스를 백업 지역에 연결
- 다시 설치하고 설치의 유효성을 검사합니다.
모바일 네트워크의 모든 패킷 코어에 대해 이 프로세스를 반복해야 합니다.
주의
복구 절차를 수행하면 패킷 코어 서비스가 중단되고 각 패킷 코어에 대해 최대 8시간 동안 ES에 대한 네트워크 연결이 중단됩니다. 지역 오류 발생 시 업무 차원에서 Azure를 통해 Azure Private 5G Core 배포를 관리해야 하는 경우에만 이 절차를 수행하는 것이 좋습니다.
실패한 지역에서 Azure Stack Edge 디바이스 연결 끊기
Azure Stack Edge 디바이스는 현재 패킷 코어 소프트웨어를 실행하고 있으며 실패한 지역에서 제어됩니다. 실패한 지역에서 Azure Stack Edge 디바이스의 연결을 끊고 실행 중인 패킷 코어를 제거하려면 Azure Stack Edge 디바이스 재설정 및 다시 활성화의 재설정 및 다시 활성화 지침을 따라야 합니다. 이렇게 하면 패킷 코어 소프트웨어뿐만 아니라 현재 Azure Stack Edge 디바이스에서 실행 중인 모든 소프트웨어가 제거되므로 디바이스에 다른 소프트웨어를 다시 설치할 수 있는 기능이 있는지 확인합니다. 그러면 이 Azure Stack Edge 디바이스의 패킷 코어에 연결된 모든 디바이스에 대한 네트워크 중단이 시작됩니다.
Azure Stack Edge 디바이스를 새 지역에 연결
AKS 클러스터 커미션의 지침에 따라 Azure Stack Edge 디바이스에서 Azure Kubernetes Service 클러스터를 다시 배포합니다. 실패한 지역이 복구될 때 충돌을 방지하려면 이 새 설치에 다른 이름을 사용해야 합니다. 이 프로세스의 일부로 클러스터에 대한 새 사용자 지정 위치 ID를 얻게 됩니다. 이 ID는 적어 두어야 합니다.
다시 설치 및 유효성 검사
준비에 저장한 packetCoreControlPlanes.platform 값을 복사하고 packetCoreControlPlane.platform.customLocation 필드를 위에서 언급한 사용자 지정 위치 ID로 업데이트합니다. packetCoreControlPlane.platform.azureStackEdgeDevice가 패킷 코어를 설치하려는 Azure Stack Edge 디바이스의 ID와 일치하는지 확인합니다. 이제 패킷 코어 수정에 따라 백업 패킷 코어를 플랫폼 값으로 업데이트합니다. 그러면 Azure Stack Edge 디바이스에서 패킷 코어 배포가 트리거됩니다.
UE 연결이 복원되고 모든 네트워크 기능이 작동 중인지 확인하려면 새 사이트 설치의 유효성을 검사하는 일반적인 프로세스를 따라야 합니다. 특히 Azure Portal의 사이트 대시보드에 UE 등록이 표시되고 데이터가 데이터 평면을 통해 흐르는지 확인해야 합니다.
실패한 지역이 복원됨
실패한 지역이 복구되면 준비의 단계에 따라 활성 백업 지역에서 복구된 주 지역으로 백업을 수행하여 두 지역의 구성이 동기화되었는지 확인해야 합니다.
또한 이전 단계에서 제거되지 않은 복구된 지역의 리소스를 확인하고 제거해야 합니다.
- (복구의 단계에 따라) 백업 지역으로 이동한 각 Azure Stack Edge 디바이스에 대해 이전 ARC 클러스터 리소스를 찾아 삭제해야 합니다. 이 리소스의 ID는 준비에서 백업한 값의 packetCoreControlPlane.platform.customLocation 필드에 있습니다. 해당 Kubernetes 클러스터가 복구 프로세스의 일부로 삭제되었으므로 이 리소스의 상태는 연결이 끊어집니다.
- (복구의 단계에 따라) 백업 지역으로 이동한 각 패킷 코어에 대해 복구된 지역에서 NFM 개체를 찾아 삭제해야 합니다. 이러한 리소스는 패킷 코어 컨트롤 플레인 리소스와 동일한 리소스 그룹에 나열되고 지역 값이 복구된 지역과 일치합니다.
그러면 진행 중인 관리에 대해 다음 두 가지 항목 중 하나를 선택할 수 있습니다.
- 운영 백업 지역을 새로운 주 지역으로 사용하고 복구된 지역을 백업 지역으로 사용합니다. 추가적인 조치가 필요하지 않습니다.
- 리소스를 다른 지역으로 이동의 지침에 따라 복구된 지역으로 다시 전환하여 복구된 지역을 새 활성 주 지역으로 만듭니다.
테스팅
재해 복구 계획을 테스트하려는 경우 언제든지 단일 패킷 코어에 대한 복구 절차를 따를 수 있습니다. 이로 인해 패킷 코어 서비스가 중단되고 최대 4시간 동안 ES에 대한 네트워크 연결이 중단되므로 비프로덕션 패킷 코어 배포 또는 중단이 비즈니스에 부정적인 영향을 주지 않는 경우에만 이 작업을 수행하는 것이 좋습니다.