Fiabilidad de Azure Private 5G Core
En este artículo se describe la compatibilidad con la fiabilidad de Azure Private 5G Core. Además, se describe la resistencia regional con zonas de disponibilidad y la recuperación ante desastres entre regiones y la continuidad empresarial. Para obtener información general sobre la fiabilidad de Azure, consulte Fiabilidad de Azure.
También puede implementar Azure Private 5G Core como un servicio de alta disponibilidad (HA) en un par de dispositivos de Azure Stack Edge (ASE). Para más información, consulte Finalización de las tareas previas necesarias para implementar una red móvil privada.
Compatibilidad de zonas de disponibilidad
Las zonas de disponibilidad de Azure son al menos tres grupos de centros de datos físicamente independientes dentro de cada región de Azure. Los centros de datos de cada zona están equipados con infraestructura de alimentación, refrigeración y red independientes. En el caso de un error en la zona local, las zonas de disponibilidad están diseñadas de manera que, si se ve afectada una zona, los servicios, la capacidad y la alta disponibilidad regionales serán proporcionadas por las dos zonas restantes.
Estos errores pueden abarcar desde errores de software y hardware hasta eventos como terremotos, inundaciones e incendios. La tolerancia a los errores se logra con la redundancia y el aislamiento lógico de los servicios de Azure. Para más información sobre las zonas de disponibilidad en Azure, consulte Regiones y zonas de disponibilidad.
Los servicios habilitados para zonas de disponibilidad de Azure están diseñados para proporcionar el nivel adecuado de confiabilidad y flexibilidad. Se pueden configurar de dos maneras. Pueden tener redundancia de zona, con una replicación automática entre zonas o ser zonales, con instancias ancladas a una zona específica. También puede combinar ambos enfoques. Para más información sobre la arquitectura zonal frente a la arquitectura con redundancia de zona, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.
El servicio Azure Private 5G Core se implementa automáticamente con redundancia de zona en las regiones de Azure que admiten zonas de disponibilidad, como se muestra en Servicio de zona de disponibilidad y compatibilidad regional. Si una región admite zonas de disponibilidad, todos los recursos de Azure Private 5G Core creados en una región se pueden administrar desde cualquiera de las zonas de disponibilidad.
No se requiere ninguna operación adicional para configurar o administrar zonas de disponibilidad. La conmutación por error entre zonas de disponibilidad es automática.
Requisitos previos
Consulte Productos disponibles por región para obtener las regiones de Azure donde Azure Private 5G Core está disponible.
Experiencia a nivel de zona
En un escenario de interrupción en toda la zona, los usuarios no deberían verse afectados porque el servicio se desplazará para aprovechar automáticamente la zona en buen estado. Al principio de una interrupción en toda la zona, es posible que se agote el tiempo de espera o se produzca un error en las solicitudes de ARM en curso. Las nuevas solicitudes se dirigirán a nodos correctos sin que ello afecte a los usuarios y todas las operaciones con errores deberán reintentarse. Todavía podrá crear nuevos recursos y actualizar, supervisar y administrar los recursos existentes durante la interrupción.
Técnicas de implementación segura
La aplicación garantiza que todo el estado de la nube se replique entre las zonas de disponibilidad de la región para que todas las operaciones de administración continúen sin interrupciones. La red troncal de paquetes se ejecuta en el borde y no le afecta el error de la zona, por lo que seguirá ofreciendo servicio a los usuarios.
Recuperación ante desastres entre regiones y continuidad empresarial
La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.
En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, usted es el responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.
Azure Private 5G Core solo está disponible en zonas geográficas de varias regiones (3+N). El servicio replica automáticamente las credenciales de SIM en una región de copia de seguridad de la misma geografía. Esto significa que no se produce una pérdida de datos en caso de error en la región. En un plazo de cuatro horas después del error, todos los recursos de la región con errores están disponibles para consultarse a través de Azure Portal y las herramientas de ARM, pero estarán en modo de solo lectura hasta que se recupere la región con errores. La red troncal de paquetes que se ejecuta en el borde sigue funcionando sin interrupción y se mantendrá la conectividad de red.
Microsoft es responsable de la detección de interrupciones, la notificación y la compatibilidad con los aspectos de la nube de Azure del servicio Azure Private 5G Core.
Detección, notificación y administración de interrupciones
Microsoft supervisa los recursos subyacentes que proporcionan el servicio Azure Private 5G Core en cada región. Si esos recursos empiezan a mostrar errores o alertas de seguimiento de estado que no se limitan a una zona de disponibilidad, Microsoft moverá el servicio a otra región admitida de la misma geografía. Se trata de un modelo de tipo activo/activo. El estado del servicio de una región determinada se puede encontrar en Azure Service Health (Azure Private 5G Core se muestra en la sección Redes). Recibirá una notificación de los errores de cualquier región a través de los canales de comunicación habituales de Azure.
El servicio replica automáticamente las credenciales de SIM que pertenecen al servicio en la región de copia de seguridad mediante escrituras en varias regiones de Cosmos DB, por lo que no se pierden datos en caso de error en la región.
Los recursos de Azure Private 5G Core implementados en la región con errores se mostrarán en modo de solo lectura, pero los recursos de las demás regiones seguirán funcionando sin problemas. Si necesita poder escribir recursos en todo momento, siga las instrucciones que se indican en Configuración de la recuperación ante desastres y la detección de interrupciones para llevar a cabo su propia operación de recuperación ante desastres y configurar el servicio en otra región.
La red troncal de paquetes que se ejecuta en el borde sigue funcionando sin interrupción y se mantendrá la conectividad de red.
Configuración de la recuperación ante desastres y la detección de interrupciones
En esta sección se describe qué acción puede realizar para asegurarse de tener un plano de administración totalmente activo para el servicio Azure Private 5G Core si se produce un error en una región. Esto es necesario si quiere poder modificar los recursos en caso de que se produzca un error en una región.
Tenga en cuenta que esto provocará una interrupción en el servicio de red troncal de paquetes e interrumpirá la conectividad de red a los equipos de usuario durante un máximo de ocho horas. Por esta razón, se recomienda que use este procedimiento solo si tiene una razón crítica para la empresa que justifique administrar los recursos mientras la región de Azure está inactiva.
Antes de un evento de recuperación ante desastres, debe realizar una copia de seguridad de la configuración de los recursos en otra región que admita Azure Private 5G Core. Cuando se produce un error en la región, puede volver a implementar la red troncal de paquetes mediante los recursos de la región de copia de seguridad.
Preparación
Hay dos tipos de datos de configuración de Azure Private 5G Core de los que deben realizarse copias de seguridad para la recuperación ante desastres: la configuración de la red móvil y las credenciales de SIM. Se recomienda que:
- Actualice las credenciales de SIM en la región de copia de seguridad cada vez que agregue SIM nuevas a la región primaria.
- Realice una copia de seguridad de la configuración de la red móvil al menos una vez a la semana o más a menudo si realiza cambios frecuentes o grandes en la configuración, como la creación de un sitio.
Configuración de la red móvil
Siga las instrucciones de Traslado de recursos a otra región para exportar la configuración de los recursos de Azure Private 5G Core y cargarla en la nueva región. Se recomienda usar un nuevo grupo de recursos para la configuración de la copia de seguridad, con el fin de separarlo claramente de la configuración activa. Debe asignar nombres nuevos a los recursos para distinguirlos de los recursos de la región primaria. Esta nueva región es una copia de seguridad pasiva. Así pues, para evitar conflictos, aún no debe vincular la configuración de la red troncal de paquetes al hardware perimetral. En su lugar, almacene los valores del campo packetCoreControlPlanes.platform para cada red troncal de paquetes en una ubicación segura a la que pueda acceder la persona que realice el procedimiento de recuperación (por ejemplo, en una cuenta de almacenamiento a la que hace referencia la documentación interna).
Datos de SIM
Por motivos de seguridad, Azure Private 5G Core nunca devolverá las credenciales de SIM que se proporcionen al servicio como parte de la creación de SIM. Por lo tanto, no es posible exportar la configuración de SIM de la misma manera que otros recursos de Azure. Se recomienda que cada vez que se agreguen SIM nuevas al servicio principal, se agreguen también al servicio de copia de seguridad repitiendo el proceso de Aprovisionamiento de nuevas SIM para la red móvil de copia de seguridad.
Otros recursos
La implementación de Azure Private 5G Core podría usar instancias de Azure Key Vault para almacenar claves de cifrado de SIM o certificados HTTPS para la supervisión local. Debe seguir la documentación de Azure Key Vault para asegurarse de que las claves y los certificados estarán disponibles en la región de copia de seguridad.
Recuperación
En caso de que se produzca un error en una región, compruebe primero que todos los recursos de la región de copia de seguridad estén presentes. Para ello, consulte la configuración a través de Azure Portal o la API (vea Traslado de recursos a otra región). Si no están presentes todos los recursos, deténgase aquí y no siga el resto del procedimiento. Es posible que no pueda recuperar el servicio en el sitio perimetral sin la configuración de los recursos.
El proceso de recuperación se divide en tres fases para cada red troncal de paquetes:
- Desconexión del dispositivo Azure Stack Edge de la región con errores mediante un restablecimiento
- Conexión del dispositivo Azure Stack Edge a la región de copia de seguridad
- Vuelva a instalar y valide la instalación.
Debe repetir este proceso para cada red troncal de paquetes de la red móvil.
Precaución
El procedimiento de recuperación provocará una interrupción del servicio de red troncal de paquetes e interrumpirá la conectividad de red a los equipos de usuario durante un máximo de ocho horas para cada red troncal de paquetes. Se recomienda que solo realice este procedimiento si tiene una necesidad crítica para la empresa que justifique administrar la implementación de Azure Private 5G Core en Azure durante el error en la región.
Desconexión del dispositivo Azure Stack Edge de la región con errores
El dispositivo Azure Stack Edge está ejecutando actualmente el software de la red troncal de paquetes y se controla desde la región con errores. Para desconectar de la región con errores el dispositivo Azure Stack Edge y quitar la red troncal de paquetes en ejecución, debe seguir las instrucciones de restablecimiento y reactivación que se encuentran en Restablecimiento y reactivación del dispositivo Azure Stack Edge. Tenga en cuenta que esto quitará todo el software que se ejecuta actualmente en el dispositivo Azure Stack Edge, no solo el software de la red troncal de paquetes, por lo que debe asegurarse de que tiene la capacidad de reinstalar cualquier otro software en el dispositivo. Esto iniciará una interrupción de red para todos los dispositivos conectados a la red troncal de paquetes en este dispositivo Azure Stack Edge.
Conexión del dispositivo Azure Stack Edge a la nueva región
Siga las instrucciones que se indican en Puesta en marcha del clúster de AKS para volver a implementar el clúster de Azure Kubernetes Service en el dispositivo Azure Stack Edge. Asegúrese de usar otro nombre para esta nueva instalación para evitar conflictos cuando se recupere la región con errores. Como parte de este proceso, obtendrá un nuevo identificador de ubicación personalizado para el clúster, que debe anotar.
Reinstalación y validación
Realice una copia de los valores de packetCoreControlPlanes.platform que almacenó en Preparación y actualice el campo packetCoreControlPlane.platform.customLocation con el identificador de ubicación personalizado que anotó anteriormente. Asegúrese de que packetCoreControlPlane.platform.azureStackEdgeDevice coincide con el identificador del dispositivo Azure Stack Edge en el que quiere instalar la red troncal de paquetes. Ahora siga las instrucciones incluidas en Modificación de la red troncal de paquetes para actualizar la red troncal de paquetes de copia de seguridad con los valores de la plataforma. Esto desencadenará una implementación de la red troncal de paquetes en el dispositivo Azure Stack Edge.
Debe seguir el proceso normal para validar una nueva instalación de sitio para confirmar que se ha restaurado la conectividad de los equipos de usuario y que toda la funcionalidad de red está operativa. En concreto, debe confirmar que los paneles de los sitios de Azure Portal muestran registros de equipos de usuario y que los datos fluyen a través del plano de datos.
Región con errores restaurada
Cuando se recupera la región con errores, debe asegurarse de que la configuración de las dos regiones está sincronizada. Para ello, realice una copia de seguridad desde la región de copia de seguridad activa en la región primaria recuperada según los pasos que se describen en Preparación.
También debe comprobar los recursos de la región recuperada y quitar los que no se hayan destruido como resultado de los pasos anteriores:
- Para cada dispositivo Azure Stack Edge que haya movido a la región de copia de seguridad (según los pasos que se describen en Recuperación), debe buscar y eliminar el recurso de clúster de ARC anterior. El identificador de este recurso se encuentra en el campo packetCoreControlPlane.platform.customLocation de los valores de los que haya realizado una copia de seguridad en Preparación. El estado de este recurso será desconectado porque el clúster de Kubernetes correspondiente se eliminó como parte del proceso de recuperación.
- Para cada red troncal de paquetes que haya movido a la región de copia de seguridad (según los pasos que se describen en Recuperación), debe buscar y eliminar los objetos NFM de la región recuperada. Se mostrarán en el mismo grupo de recursos que los recursos del plano de control de la red troncal de paquetes y el valor de Región coincidirá con la región recuperada.
A continuación, dispone de dos opciones para la administración continua:
- Use la región de copia de seguridad operativa como nueva región primaria y use la región recuperada como copia de seguridad. No es necesario hacer nada.
- Convierta la región recuperada en la nueva región primaria activa según las instrucciones que se indican en Traslado de recursos a otra región para cambiar a la región recuperada.
Prueba
Si quiere probar los planes de recuperación ante desastres, puede seguir el procedimiento de recuperación para una red troncal de paquetes en cualquier momento. Tenga en cuenta que esto provocará una interrupción del servicio de la red troncal de paquetes e interrumpirá la conectividad de red a los equipos de usuario durante un máximo de cuatro horas. Por esta razón, se recomienda hacerlo solo con implementaciones de redes troncales de paquetes que no sean de producción o en un momento en el que una interrupción no afecte negativamente al negocio.