Ejecución de una máquina virtual Linux en Azure

Azure Backup
Azure Bastion
Azure Blob Storage
Azure Resource Manager
Azure Storage
Azure Virtual Machines

Para aprovisionar una máquina virtual (VM) en Azure, necesita más componentes que la propia máquina virtual. Una implementación completa incluye recursos de red y almacenamiento. En este artículo se describen los procedimientos recomendados para ejecutar una máquina virtual Linux segura en Azure.

Arquitectura

Diagrama que muestra una implementación de máquina virtual en Azure.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

En este ejemplo se muestra una implementación básica que usa los componentes necesarios para una sola máquina virtual. La máquina virtual puede ejecutar cargas de trabajo y acceder a la red pública de Internet, a la vez que evita la exposición directa a amenazas externas. En esta arquitectura:

  • Las cargas de trabajo de la máquina virtual no tienen exposición directa a Internet. El acceso está restringido a los recursos dentro de la misma red virtual o de una red virtual conectada mediante emparejamiento, como en una configuración hub-and-spoke.

  • La máquina virtual se administra mediante Azure Bastion mediante Secure Shell (SSH). No hay acceso directo desde la red pública de Internet a la máquina virtual para la administración.

  • La puerta de enlace de traducción de direcciones de red (NAT) y su dirección IP pública asociada proporcionan acceso saliente a Internet externo.

Components

Esta arquitectura usa los siguientes componentes.

Grupo de recursos

Un grupo resource es un contenedor lógico que contiene recursos Azure relacionados. Los grupos de recursos permiten implementar, supervisar y eliminar recursos relacionados juntos y realizar un seguimiento de sus costos como una unidad.

En general, agrupe los recursos por ciclo de vida compartido y propiedad. Use nombres descriptivos y coherentes para los recursos para facilitar su identificación y comprensión. Para obtener más información, vea Defina su convención de nomenclatura.

Máquina virtual

Puede aprovisionar una máquina virtual de una lista de imágenes publicadas, una imagen administrada personalizada o un disco duro virtual (VHD) cargado en Azure Blob Storage. Azure admite distribuciones populares de Linux, como Debian, Red Hat Enterprise Linux (RHEL) y Ubuntu. Para más información, consulte Distribuciones aprobadas de Linux.

Azure proporciona muchos tamaños de máquina virtual diferentes. Si mueve una carga de trabajo existente a Azure, comience con el tamaño de máquina virtual que mejor coincida con los servidores locales. Después de implementar la máquina virtual, mida el rendimiento de la carga de trabajo real en términos de operaciones de CPU, memoria y salida de disco por segundo (IOPS) y ajuste el tamaño según sea necesario.

Elija una región de Azure más cercana a los usuarios o clientes internos. No todos los tamaños de máquina virtual están disponibles en todas las regiones. Para obtener más información, vea Azure geographies. Para obtener una lista de los tamaños de máquina virtual disponibles en una región específica, ejecute el siguiente comando desde el CLI de Azure:

az vm list-sizes --location <location>

Para obtener información sobre cómo elegir una imagen de máquina virtual publicada, consulte Buscar información sobre imágenes de Azure Marketplace.

Discos

Para obtener el mejor rendimiento de entrada y salida de disco (E/S), se recomiendan SSD Premium, que almacenan datos en unidades de estado sólido (SSD). La capacidad del disco aprovisionado determina el costo, las IOPS y el rendimiento (velocidad de transferencia de datos). Tenga en cuenta los tres factores al seleccionar un tamaño de disco. Los SSD Premium incluyen ráfagas gratuitas, lo que le ayuda a satisfacer los picos de demanda sin necesidad de sobreaprovisionar y reduce el coste de la capacidad no utilizada cuando se combina con un conocimiento de los patrones de carga de trabajo.

Nota

Los discos SSD Premium v2 y Ultra solo se pueden usar para discos de datos. No se admiten para discos del sistema operativo (SO).

Managed Disks facilita la administración de discos y controla el almacenamiento automáticamente. Los discos administrados no requieren una cuenta de almacenamiento. Indique el tamaño y el tipo de disco y se implementará como un recurso de alta disponibilidad. Los discos administrados también reducen los costos al proporcionar el rendimiento que necesita sin aprovisionamiento excesivo, lo que ayuda a evitar el pago de la capacidad aprovisionada sin usar.

De forma predeterminada, el disco del sistema operativo es un disco administrado almacenado en Azure Disk Storage, por lo que se conserva incluso cuando la máquina host está inactiva. En el caso de las cargas de trabajo sin estado, donde se desea el aprovisionamiento rápido y sin persistencia del sistema operativo, use discos de sistema operativo efímeros. Estos discos colocan la imagen del sistema operativo en el almacenamiento local del host de la máquina virtual en lugar de en Azure Storage remoto, lo que reduce la latencia de lectura, acelera la reaplicación de la imagen y elimina el coste de los discos administrados. Sin embargo, todos los datos de un disco efímero del sistema operativo se pierden al detenerse (desasignar), al volver a crear la imagen o durante eventos de recuperación por mantenimiento del host. Los discos efímeros del sistema operativo no admiten instantáneas ni copias de seguridad de Azure. Utiliza discos efímeros del sistema operativo solo cuando las máquinas virtuales sean totalmente reimplementables mediante automatización.

De forma predeterminada, muchas imágenes de Linux no configuran espacio de intercambio. Si su carga de trabajo requiere un área de intercambio, créela en el disco temporal usando cloud-init en lugar de en el disco del sistema operativo o en un disco de datos.

Se recomienda crear uno o varios discos de datos para los datos de la aplicación. Los discos de datos son discos administrados persistentes respaldados por Storage.

Al crear un disco, no tiene formato. Inicie sesión en la máquina virtual para dar formato al disco. En el shell de Linux, los discos de datos se muestran como /dev/sdc, /dev/sdd, y posteriormente con letras sucesivas. Puede ejecutar lsblk para mostrar los dispositivos de bloque, lo que incluye los discos. Para utilizar un disco de datos, cree una partición y un sistema de archivos y monte el disco. Por ejemplo:

# Create a partition.

sudo fdisk /dev/sdc     # Enter 'n' to partition, 'w' to write the change.

# Create a file system.

sudo mkfs -t ext3 /dev/sdc1

# Mount the drive.

sudo mkdir /data1
sudo mount /dev/sdc1 /data1

Cuando agrega un disco de datos, se asigna un identificador de número de unidad lógica (LUN) al disco. También puede especificar el identificador de LUN si, por ejemplo, va a reemplazar un disco y desea conservar el mismo identificador de LUN, o si tiene una aplicación que busca un identificador de LUN específico. Sin embargo, los identificadores LUN deben ser únicos para cada disco.

Para los discos de almacenamiento Premium, puede que quiera cambiar el programador de E/S para optimizar el rendimiento de los SSD. Una recomendación habitual es utilizar el programador No Operation (NOOP) para los SSD, pero deberías utilizar una herramienta como iostat para supervisar el rendimiento de E/S del disco en tu carga de trabajo.

Muchas máquinas virtuales se crean con un disco temporal, que se almacena en una unidad física en la máquina host. No se guarda en Almacenamiento y podría eliminarse durante los reinicios y otros eventos del ciclo de vida de la máquina virtual. Use este disco solo para datos temporales, como archivos de paginación o de intercambio. Para máquinas virtuales con Linux, el disco temporal es /dev/disk/azure/resource-part1 y se monta en /mnt/resource o /mnt.

Red

Los componentes de red incluyen los siguientes recursos:

  • Red virtual: Cada máquina virtual se implementa en una red virtual que se segmenta en subredes.

  • Tarjeta de interfaz de red (NIC): La NIC conecta la máquina virtual a la red virtual y controla todo el tráfico entrante y saliente. Cada tamaño de máquina virtual define un número máximo de NIC.

  • Dirección IP pública: Se puede usar una dirección IP pública para comunicarse con la máquina virtual desde fuera Azure a través de SSH. Sin embargo, se desaconseja esta opción porque es un riesgo de seguridad potencial.

    Warning

    Evite asociar una dirección IP pública directamente a una máquina virtual. Solo lo haga en circunstancias extremas e incluya otras medidas de seguridad, como el uso de grupos de seguridad de red (NSG) para filtrar el tráfico.

    Para el acceso de administración a una máquina virtual, use Azure Bastion para el acceso SSH basado en explorador o conéctese de forma privada a través de una VPN o Azure ExpressRoute.

    • La dirección IP pública puede ser dinámica o estática. El valor predeterminado es dinámico. Reserve una dirección IP estática cuando necesite una dirección IP fija que no cambie, por ejemplo, si necesita crear un registro "A" dns o agregar la dirección IP a una lista segura.

    • También puede crear un nombre de dominio completo (FQDN) para la dirección IP. Después, puede registrar un registro CNAME en DNS que apunte al nombre de dominio completo. Para más información, consulte Creación de un nombre de dominio completo para una máquina virtual.

  • NSG: Use NSGs para permitir o denegar el tráfico de red a máquinas virtuales y subredes. Asócielos a las subredes o a NIC individuales conectadas a máquinas virtuales.

    Todos los NSG contienen un conjunto de reglas de seguridad predeterminadas, incluida una regla que bloquea todo el tráfico entrante de Internet. No puede eliminar las reglas predeterminadas, pero puede invalidarlas con otras reglas. Por ejemplo, puede crear reglas que permitan el tráfico entrante de Internet a puertos específicos, como el puerto 443 para HTTPS.

  • Puerta de enlace de traducción de direcciones de red (NAT) de Azure:Azure NAT Gateway permite que todas las instancias de una subred privada se conecten de forma saliente a Internet sin dejar de ser totalmente privadas. Solo los paquetes que llegan como paquetes de respuesta a una conexión saliente pueden pasar a través de una puerta de enlace NAT. No se permiten conexiones entrantes no solicitadas desde Internet.

    Nota

    Para mejorar la seguridad predeterminada, el acceso implícito a Internet saliente está en desuso para todas las nuevas redes virtuales. Debe configurar explícitamente la conectividad saliente a Internet mediante otros recursos, como NAT Gateway, Azure equilibradores de carga estándar o firewalls. Para obtener más información, consulte Acceso saliente predeterminado en Azure.

  • Azure Bastion:Azure Bastion es una solución de plataforma como servicio (PaaS) totalmente administrada que proporciona acceso seguro a las máquinas virtuales a través de direcciones IP privadas. Con esta configuración, las máquinas virtuales no necesitan una dirección IP pública que las exponga a Internet, lo que mejora su estado de seguridad. Azure Bastion proporciona conectividad ssh o protocolo de Escritorio remoto segura (RDP) a las máquinas virtuales directamente a través de la seguridad de la capa de transporte (TLS) mediante varios métodos, incluido el portal de Azure o los clientes SSH o RDP nativos.

Operaciones

En esta sección se tratan los procedimientos operativos clave para administrar una máquina virtual Linux en Azure.

  • SSH: Antes de crear una máquina virtual Linux, genere un par de claves pública-privada RSA de 2048 bits. Utilice el archivo de clave pública al crear la máquina virtual. Para obtener más información, consulte Creación y uso de un par de claves pública-privada SSH.

  • Diagnósticos: Habilite la supervisión y el diagnóstico, incluidas las métricas de mantenimiento básicas, los registros de infraestructura de diagnóstico y los diagnósticos de arranque. Los diagnósticos de arranque pueden ayudarle a diagnosticar errores de arranque si la máquina virtual entra en un estado que no se puede arrancar. Almacene los registros de diagnóstico en una cuenta de Almacenamiento. Una cuenta de almacenamiento estándar con redundancia local (LRS) es suficiente para los registros de diagnóstico. Para obtener más información, consulte Procedimientos recomendados para la supervisión y el diagnóstico.

  • Availability:El mantenimiento planeado o el tiempo de inactividad no planeado pueden afectar a la máquina virtual. Puede usar los registros de reinicio de la máquina virtual para determinar si el mantenimiento planeado provocó un reinicio de la máquina virtual. Para obtener una mayor disponibilidad, implemente varias máquinas virtuales en zonas de disponibilidad dentro de una región. Esta implementación proporciona un acuerdo de nivel de servicio (SLA) superior. Cuando no se admiten zonas de disponibilidad, los conjuntos de disponibilidad pueden ayudar a proporcionar protección frente a errores o actualizaciones del host. Sin embargo, las zonas de disponibilidad son la opción recomendada siempre que sea posible.

  • Copias de seguridad: Para protegerse contra la pérdida accidental de datos, use el servicio Azure Backup para realizar copias de seguridad de las máquinas virtuales en el almacenamiento. En función de la región, puede usar almacenamiento con redundancia geográfica o almacenamiento con redundancia de zona para las copias de seguridad. Azure Backup proporciona copias de seguridad coherentes con la aplicación. Para cargas de trabajo en las que el rendimiento es fundamental o distribuciones de Linux especializadas que no admiten agentes de copia de seguridad tradicionales, utiliza la función de copia de seguridad multidisco sin agente y consistente ante errores para automatizar la protección mediante copias de seguridad sin afectar al rendimiento de las aplicaciones.

  • Detener una máquina virtual: Azure hace una distinción entre los estados detenidos y desasignados. Se le cobrará cuando el estado de la máquina virtual sea detenida, pero no cuando se desasigne la máquina virtual. En el portal de Azure, el botón Stop libera la máquina virtual. Si apagas la máquina virtual a través del sistema operativo mientras estás conectado, la máquina virtual se detiene pero no se desasigna, por lo que seguirás pagando.

  • Eliminación de una máquina virtual: Si elimina una máquina virtual, puede optar por eliminar o conservar sus discos, lo que le permite conservar los datos. Sin embargo, sigues pagando por los discos. Puede eliminar discos administrados como cualquier otro recurso de Azure. Para evitar eliminaciones por error, use un bloqueo de recurso para bloquear el grupo de recursos completo o recursos individuales, como una máquina virtual.

Alternatives

  • Azure Virtual Machine Scale Sets proporcionan la capacidad de distribuir cargas de trabajo entre nodos. Las cargas de trabajo que son críticas para las operaciones empresariales nunca deben depender de una sola máquina virtual. Puedes añadir o eliminar instancias de máquinas virtuales automáticamente en función de la demanda, y puedes ampliar la capacidad en momentos de mayor tráfico o reducirla cuando el tráfico sea menor para ayudar a minimizar los costes.

  • Azure Load Balancer distribuye el tráfico entre varias máquinas virtuales o un conjunto de escalado de máquinas virtuales. También se puede usar como alternativa a una puerta de enlace NAT para permitir el acceso a una carga de trabajo desde Internet, al tiempo que admite el acceso saliente.

  • Application Gateway proporciona funcionalidad de equilibrio de carga a la Azure Load Balancer para cargas de trabajo HTTP/HTTPS dentro de una región de Azure.

  • Para una implementación de nivel empresarial, consulte Arquitectura de referencia de Azure Virtual Machines en una zona de aterrizaje de Azure.

Detalles del escenario

En el diagrama anterior se muestra una implementación básica de una sola máquina virtual en una red virtual. Este escenario es útil para proporcionar una carga de trabajo no crítica para usuarios solo internos.

Posibles casos de uso

Esta arquitectura se adapta a una aplicación sencilla que no necesita exposición pública a Internet y puede tolerar tiempos de inactividad ocasionales. Una herramienta de informes interna básica es un caso de uso típico.

Consideraciones

Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Well-Architected Framework.

Reliability

La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

En esta arquitectura de ejemplo se usa una sola máquina virtual, por lo que proporciona un nivel mínimo de confiabilidad. Cualquier problema con la máquina virtual o con el host donde se ejecuta, provoca una interrupción y hace que las cargas de trabajo hospedadas no estén disponibles. Para cualquier carga de trabajo que necesite una mayor disponibilidad, implemente varias máquinas virtuales que contengan la misma carga de trabajo y coloque esas instancias detrás de una solución de equilibrio de carga adecuada. Si se encuentran dentro de la misma región, implemente esas máquinas virtuales en zonas de disponibilidad (donde se admita) y agréguelas al back-end de un Azure Standard Load Balancer o una instancia de Application Gateway si la carga de trabajo está basada en HTTP/HTTPS. Esta arquitectura permite que la carga de trabajo permanezca disponible si una sola máquina virtual del back-end deja de funcionar.

Los conjuntos de escalado de máquinas virtuales son otra opción para ayudar a simplificar la administración de cargas de trabajo de varios nodos que necesitan la capacidad de escalar automáticamente el número de instancias dentro o fuera en función de cualquiera de varias métricas, como el consumo de CPU y memoria.

Alta disponibilidad y recuperación ante desastres (HA/DR)

Para limitar el impacto y mejorar la capacidad de recuperación, implemente la carga de trabajo en varias regiones y siga las directrices de la zona de aterrizaje de Azure. Esta implementación podría realizarse en una configuración activa-pasiva, con conmutación por error a la región secundaria si la región principal deja de estar disponible, o en una arquitectura activa-activa en la que ambas regiones atienden el tráfico de los usuarios.

Para obtener un ejemplo, consulte Aplicación web multitier creada para alta disponibilidad y recuperación ante desastres. En el ejemplo de ese artículo se usa Azure Site Recovery para replicar los discos de máquinas virtuales individuales en una región secundaria. Puede utilizar Site Recovery para realizar la conmutación por error de esas máquinas virtuales a la región secundaria utilizando un objetivo de punto de recuperación (RPO) y un objetivo de tiempo de recuperación (RTO) bajos.

Asegúrese de evaluar la arquitectura para satisfacer los requisitos de alta disponibilidad y recuperación ante desastres en todos los componentes, no solo las máquinas virtuales. En todas estas decisiones, incluya consideraciones como redes, identidades y datos.

Seguridad

La seguridad proporciona protecciones contra ataques deliberados y el uso indebido de sus valiosos datos y sistemas. Para obtener más información, vea Lista de comprobación para la revisión de diseño de seguridad.

Tenga en cuenta estos puntos al desarrollar la arquitectura:

  • Use Microsoft Defender para la nube para obtener una vista central del estado de seguridad de los recursos de Azure. Defender for Cloud supervisa los posibles problemas de seguridad y proporciona una visión completa del estado de seguridad de la implementación. Configurar Defender for Cloud para cada suscripción de Azure y habilitar la recopilación de datos de seguridad. Defender for Cloud examina automáticamente las máquinas virtuales creadas en esa suscripción.

    • Administración de revisiones: Cuando está habilitada, Defender for Cloud identifica las actualizaciones críticas y de seguridad que faltan.

    • Antimalware: Cuando está habilitada, Defender for Cloud comprueba si está instalado software antimalware. También puede usar Defender for Cloud para instalar software antimalware directamente desde el portal de Azure.

  • Use control de acceso basado en roles de Azure (Azure RBAC) para controlar el acceso a los recursos de Azure. Con Azure RBAC, solo concede a los usuarios los permisos que necesitan para realizar su trabajo. Por ejemplo, el rol Lector puede ver Azure recursos, pero no puede crearlos, administrarlos o eliminarlos. Algunos permisos son específicos de un tipo de recurso Azure. Por ejemplo, el rol Colaborador de máquina virtual puede reiniciar o desasignar una máquina virtual, restablecer la contraseña del administrador y crear una nueva máquina virtual. Otros roles integrados que podrían resultar útiles para esta arquitectura incluyen usuario de DevTest Labs y colaborador de red.

    Nota

    Azure RBAC no limita las acciones que puede realizar un usuario que haya iniciado sesión en una máquina virtual. El tipo de cuenta en el sistema operativo invitado determina esos permisos.

  • Use registros de auditoría para ver las acciones de aprovisionamiento y otros eventos de máquina virtual.

  • Habilite el cifrado en el host para lograr el cifrado de un extremo a otro para los datos de la máquina virtual, incluidos los discos temporales y las memorias caché de disco. El cifrado en el host gestiona el cifrado en la infraestructura del anfitrión de máquina virtual y no consume recursos de CPU de la máquina virtual, a diferencia del cifrado basado en el huésped. Puede usar claves administradas por customer con Azure Key Vault para discos de datos y sistema operativo persistentes. Los discos temporales y los discos del sistema operativo efímeros se cifran con claves administradas por la plataforma. Compruebe que el tamaño de VM seleccionado admite el cifrado en el host antes de aprovisionar la máquina virtual.

Optimización de costos

La optimización de costos se centra en encontrar formas de reducir los gastos innecesarios y mejorar la eficiencia operativa. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.

Hay varios tamaños de máquina virtual y la elección de uno u otro dependerá del uso y la carga de trabajo. El rango incluye la opción más económica de la serie Bs a las máquinas virtuales de GPU más recientes optimizadas para machine learning. Para obtener información sobre las opciones disponibles, consulte Precios de máquinas virtuales Linux de Azure.

Para cargas de trabajo predecibles, utilice Azure Reservations y el plan de ahorro de Azure para recursos de proceso. Un contrato de uno o tres años puede reducir considerablemente los costes de computación en comparación con las tarifas de pago por uso. En el caso de cargas de trabajo sin tiempo predecible de finalización o consumo de recursos, considere la opción Pago por uso.

Las máquinas virtuales de Azure Spot usan la capacidad sobrante de Azure a precios significativamente más bajos. Azure puede desalojar máquinas virtuales Spot con poca antelación cuando necesita recuperar esa capacidad, por lo que solo son adecuadas para cargas de trabajo tolerantes a errores sin un plazo de finalización estricto. Considere las máquinas virtuales puntuales para:

  • Escenarios informáticos de alto rendimiento, trabajos de procesamiento por lotes o aplicaciones de representación visual.
  • Entornos de prueba, incluidas las cargas de trabajo de integración continua y entrega continua.
  • Aplicaciones sin estado a gran escala.

Use la calculadora de precios Azure para calcular los costos.

Excelencia operativa

La excelencia operativa abarca los procesos de operaciones que implementan una aplicación y lo mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.

Use plantillas de infraestructura como código (IaC) para aprovisionar recursos de Azure y sus dependencias. Puede escribir estas plantillas mediante Bicep, Azure Resource Manager o Terraform. Estas plantillas se pueden usar como parte de una canalización de integración continua e implementación continua (CI/CD) a través de la implementación automatizada. Este enfoque proporciona control de versiones sobre la arquitectura, garantiza la coherencia entre entornos y aplica la reproducibilidad, la seguridad y el cumplimiento.

Para ayudar a supervisar y diagnosticar problemas, habilite los registros de diagnóstico en los recursos y envíelos a Azure Monitor para el análisis y la optimización. Puede usar estos registros para generar alertas y notificaciones sobre eventos críticos y, en algunos casos, permitir la remediación automatizada o la creación de tickets en su sistema de gestión de servicios de TI (ITSM).

Eficiencia en el rendimiento

La eficiencia del rendimiento hace referencia a la capacidad de escalado de la carga de trabajo para satisfacer las demandas de los usuarios de forma eficaz. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

La eficiencia del rendimiento le ayuda a minimizar la latencia, lograr arquitecturas escalables, optimizar el uso de recursos y mejorar continuamente el rendimiento del sistema. Las decisiones que tome con respecto a la arquitectura de carga de trabajo, el tamaño de máquina virtual y las configuraciones de disco pueden afectar considerablemente al rendimiento de la carga de trabajo. Tomar las decisiones adecuadas puede impedir la necesidad de rediseñar la solución en el futuro, agregar flexibilidad y ahorrar costos.

Tenga en cuenta estos puntos al desarrollar la arquitectura:

  • Use conjuntos de escalado de máquinas virtuales si la carga de trabajo tiene una carga dinámica. Por ejemplo, amplíe la capacidad en momentos de mucho tráfico y luego redúzcala cuando el tráfico disminuya. Este enfoque garantiza una potencia de procesamiento adecuada al tiempo que mantiene bajo control los costos.

  • Elija las SKU de disco y máquina virtual adecuadas para satisfacer las IOPS necesarias durante el procesamiento. Configure el almacenamiento en caché para mejorar aún más el rendimiento.

  • Si la carga de trabajo es inusualmente sensible a la latencia, utilice grupos de ubicación por proximidad (PPG) para asegurarse de que varias máquinas virtuales estén ubicadas físicamente cerca unas de otras y así obtener un mejor rendimiento. También puede combinar PPG con conjuntos de disponibilidad para lograr baja latencia y alta disponibilidad dentro de un único centro de datos físico.

  • Siempre que sea posible, habilite las redes aceleradas para minimizar la latencia entre los componentes.

  • Diseñe la arquitectura de red para minimizar los saltos innecesarios.

  • Use Azure Monitor y otras herramientas para analizar continuamente las métricas y crear líneas base de rendimiento actualizadas. Use la información de rendimiento para determinar dónde implementar los cambios y, a continuación, probar con esas líneas base.

Contributors

Microsoft mantiene este artículo. Los siguientes colaboradores escribieron originalmente este artículo.

Autor principal:

  • Donnie Trumpower | Arquitecto sénior de soluciones de nube e inteligencia artificial

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes