Confiabilidad en Azure Bastion

Azure Bastion es una plataforma como servicio (PaaS) totalmente administrada que se aprovisiona para proporcionar conexiones de alta seguridad a máquinas virtuales a través de una dirección IP privada. Proporciona una conectividad RDP/SSH ininterrumpida a las máquinas virtuales directamente sobre TLS desde Azure Portal o a través del cliente nativo SSH o RDP instalado en el equipo local. Cuando se conecta a través de Azure Bastion, las máquinas virtuales no necesitan una dirección IP pública, un agente ni software cliente especial.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que Azure Bastion sea resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones de regiones. Resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de Azure Bastion.

Recomendaciones de implementación de producción para la confiabilidad

En el caso de las cargas de trabajo de producción, se recomienda que usted:

Introducción a la arquitectura de confiabilidad

Al utilizar Azure Bastion, debe implementar un servidor bastión en una subred que cumpla con los requisitos de Azure Bastion.

Un host bastión tiene un número definido de instancias, que a veces también se denominan unidades de escalado. Cada instancia representa una sola máquina virtual dedicada que controla las conexiones de Azure Bastion. La plataforma administra automáticamente la creación de instancias, la supervisión de estado y la sustitución de instancias incorrectas, por lo que no ve ni administra directamente las máquinas virtuales.

La SKU básica admite exactamente dos instancias. Las SKU estándar y Premium admiten el escalado de host, donde puede configurar el número de instancias, con un mínimo de dos instancias. Al agregar más instancias, el host bastión puede dar cabida a conexiones de cliente simultáneas adicionales.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que sus aplicaciones puedan administrar errores transitorios, generalmente reintentando las solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Si los errores transitorios afectan a la máquina virtual o al host bastión, los clientes que usan el host de sockets seguros (SSH) y los protocolos del Protocolo de escritorio remoto (RDP) normalmente vuelven a intentarlo automáticamente.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando se produce un error en una zona, los servicios pueden conmutar por error a una de las zonas restantes.

Azure Bastion admite zonas de disponibilidad en configuraciones con redundancia de zona y zonales:

• Con redundancia de zona: Un host bastión con redundancia de zona logra resistencia y confiabilidad al distribuir sus instancias entre varias zonas de disponibilidad. Usted selecciona las zonas de disponibilidad que desea usar para su host bastión.

  En el diagrama siguiente se muestra un host bastión con redundancia de zona, con sus instancias distribuidas entre tres zonas:

  

  Si especifica más zonas de disponibilidad que instancias tiene, Azure Bastion reparte las instancias entre tantas zonas como pueda.

• Zonal: un host bastión zonal y todas sus instancias están en una sola zona de disponibilidad que seleccione.

  Importante

  La asignación a una sola zona de disponibilidad solo se recomienda cuando la latencia entre zonas es demasiado alta para sus necesidades y después de comprobar que la latencia no cumple sus requisitos. Por sí mismo, un recurso zonal no proporciona resistencia a una interrupción de zona de disponibilidad. Para mejorar la resiliencia de un recurso zonal, debe desplegar explícitamente recursos independientes en múltiples zonas de disponibilidad y configurar el enrutamiento del tráfico y la conmutación por error. Para obtener más información, consulte Recursos zonales y resistencia de zona.

Requisitos

• Soporte de regiones: los hosts bastión zonales y con redundancia de zona pueden implementarse en las siguientes regiones:

  América	Europa	Oriente Medio	África	Asia Pacífico
  Centro de Canadá	Norte de Europa	Centro de Catar	Norte de Sudáfrica	Este de Australia
  Centro de EE. UU.	Centro de Suecia	Centro de Israel		Centro de Corea del Sur
  Este de EE. UU.	Sur de Reino Unido
  Este de EE. UU. 2	Oeste de Europa
  Oeste de EE. UU. 2	Este de Noruega
  EUAP de Este de EE. UU. 2	Norte de Italia
  Centro de México	Centro de España

• SKU: Para configurar los hosts bastión para que sean zonales o con redundancia de zona, debe realizar la implementación con los SKU Básico, Estándar o Premium.

• Dirección IP pública: Azure Bastion requiere una dirección IP pública con redundancia de zona de SKU estándar.

Coste

No hay ningún costo adicional para usar el soporte de zona de disponibilidad de Azure Bastion. Los cargos se basan en la SKU del host bastión y en el número de instancias que usa. Para más información, consulte Precios de Azure Bastion.

Configuración de la compatibilidad con zonas de disponibilidad

• Implemente un nuevo host bastión con compatibilidad con la zona de disponibilidad: Al implementar un nuevo host bastión en una región que admita zonas de disponibilidad, seleccione las zonas específicas en las que desea implementar.

  Para la redundancia de zona, debe seleccionar varias zonas.

  Cuando selecciona qué zonas de disponibilidad usar, en realidad está seleccionando la zona de disponibilidad lógica. Si implementa otros componentes de la carga de trabajo en una suscripción de Azure diferente, podrían usar un número de zona de disponibilidad lógica distinto para acceder a la misma zona de disponibilidad física. Para más información, consulte Zonas de disponibilidad físicas y lógicas.

• Hosts bastión existentes: no es posible cambiar la configuración de zona de disponibilidad de un host bastión existente. En su lugar, debe crear un servidor bastión con la nueva configuración y eliminar el anterior.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar cuando los hosts bastión están configurados para la compatibilidad con zonas de disponibilidad y todas las zonas de disponibilidad están operativas.

• Enrutamiento de tráfico entre zonas: Al iniciar una sesión ssh o RDP, se puede enrutar a una instancia de Azure Bastion en cualquiera de las zonas de disponibilidad seleccionadas.

  Si configura la redundancia de zona en el host bastión, es posible que se envíe una sesión a una instancia bastión en una zona de disponibilidad diferente de la máquina virtual a la que se conecta. En el siguiente diagrama, una solicitud del usuario se envía a una instancia de Azure Bastion en la zona 2, mientras que la máquina virtual se encuentra en la zona 1:

  

  Sugerencia

  En la mayoría de los escenarios, la cantidad de latencia entre zonas no es significativa. Sin embargo, si tiene requisitos de latencia inusualmente estrictos para sus cargas de trabajo, debe implementar un bastión dedicado de una sola zona en la zona de disponibilidad de la máquina virtual. Tenga en cuenta que esta configuración no proporciona redundancia de zona y no se recomienda para la mayoría de los clientes.

• Replicación de datos entre zonas: Dado que Azure Bastion no almacena el estado, no hay datos para replicar entre zonas.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando los servidores bastión están configurados para admitir zonas de disponibilidad y se produce una interrupción en una zona de disponibilidad.

• Detección y respuesta: cuando se usa redundancia de zona, Azure Bastion detecta y responde a errores en una zona de disponibilidad. No necesita hacer nada para iniciar una conmutación por error de una zona de disponibilidad.

  En el caso de las instancias con redundancia de zona, Azure Bastion realiza un intento de mayor esfuerzo para reemplazar las instancias que se pierden debido a un fallo de zona. Sin embargo, no se garantiza que las instancias sean reemplazadas.

• Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas. También puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

• Solicitudes activas: cuando una zona de disponibilidad no está disponible, cualquier conexión de RDP o SSH en curso que use una instancia de Azure Bastion en la zona de disponibilidad defectuosa se cancela y es necesario volver a iniciarla.

  Si la máquina virtual a la que se conecta no está en la zona de disponibilidad afectada, continúa ejecutándose. Para más información sobre la experiencia de indisponibilidad de zona de la VM, consulte Fiabilidad en VMs: comportamiento durante un error de zona.

• Tiempo de inactividad esperado: El tiempo de inactividad esperado depende de la configuración de zona de disponibilidad que usa el host bastión.

  • Con redundancia de zona: Es posible que se produzca un breve período de inactividad mientras el servicio restablece las operaciones. Este tiempo de inactividad suele ser de unos segundos.

  • Zonal: La instancia no está disponible hasta que se recupere la zona de disponibilidad.

• Pérdida de datos esperada: Dado que Azure Bastion no almacena el estado, no se espera ninguna pérdida de datos durante un error de zona.

• Reenrutamiento del tráfico: Al usar redundancia de zona, las nuevas conexiones usan instancias de Azure Bastion en las zonas de disponibilidad correctas. En general, Azure Bastion permanece operativo.

Recuperación de zona

Cuando se recupera la zona de disponibilidad, Azure Bastion restaura automáticamente las instancias de la zona de disponibilidad y vuelve a enrutar el tráfico entre las instancias como normal.

Prueba de fallos de zona

La plataforma Azure Bastion administra el enrutamiento del tráfico, la conmutación por error y la conmutación por recuperación para bastiones con redundancia de zona. Dado que esta característica está totalmente administrada, no es necesario iniciar nada ni validar los procesos de error de zona de disponibilidad.

Resistencia a errores en toda la región

Azure Bastion se implementa en redes virtuales o redes virtuales emparejadas y está asociado a una región de Azure. Azure Bastion es un servicio de una sola región. Si la región no está disponible, el host bastión perderá su disponibilidad.

Azure Bastion admite el acceso a máquinas virtuales en redes virtuales emparejadas globalmente, pero si la región que hospeda el host bastión no está disponible, no podrá usar el host bastión. Para una mayor capacidad de recuperación, si implementa su solución global en varias regiones con redes virtuales independientes en cada región, debería implementar Azure Bastion en cada una de ellas.

Si tiene un sitio de recuperación ante desastres en otra región de Azure, asegúrese de implementar Azure Bastion en la red virtual de esa región.

Acuerdo de nivel de servicio

El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Contenido relacionado

• Confiabilidad en Azure