Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El aprovisionamiento de una máquina virtual (VM) en Azure requiere componentes adicionales además de la propia máquina virtual, incluidos los recursos de red y almacenamiento. En este artículo se muestran los procedimientos recomendados para ejecutar una máquina virtual Linux segura en Azure.
Arquitectura
Descargue un archivo Visio de esta arquitectura.
Flujo de trabajo
En este ejemplo se muestra una implementación básica mediante una sola máquina virtual con los componentes necesarios. La máquina virtual puede ejecutar cargas de trabajo, es manejable y puede comunicarse con la red pública de Internet. Está diseñado para evitar la exposición directa a amenazas externas.
- Los trabajos que se ejecutan en la máquina virtual no son accesibles desde el exterior y solo son accesibles desde la misma red o desde una red virtual emparejada, como en una configuración de hub y radio.
- El acceso de administración a la máquina virtual se muestra mediante Azure Bastion a través de Secure Shell (SSH) y no se permite directamente desde la red pública de Internet.
- El acceso externo saliente a Internet se proporciona a través del uso de la puerta de enlace de traducción de direcciones de red (NAT) y su dirección IP pública asociada.
Components
Grupo de recursos
Un grupo resource es un contenedor lógico que contiene recursos Azure relacionados. Por lo general, agrupe los recursos en función de su duración y quién se encargará de administrarlos.
Implemente recursos estrechamente asociados que comparten el mismo ciclo de vida en el mismo grupo de recursos. Los grupos de recursos permiten implementar y supervisar los recursos como un grupo, y realizar un seguimiento de los costes de facturación por grupo de recursos. También se pueden eliminar recursos en conjunto, lo que resulta útil cuando se realizan implementaciones de prueba. Asigne nombres de recursos significativos para simplificar la ubicación de un recurso específico y comprender su rol. Para obtener más información, vea Recommended Naming Conventions for Azure Resources.
Máquina virtual
Puede aprovisionar una máquina virtual desde una lista de imágenes publicadas o desde una imagen administrada personalizada o un archivo de disco duro virtual (VHD) cargado en Azure Blob Storage. Azure admite la ejecución de varias distribuciones populares de Linux, como Debian, Red Hat Enterprise Linux (RHEL) y Ubuntu. Para obtener más información, consulte Azure y Linux.
Azure proporciona diferentes tamaños de máquinas virtuales. Si mueve una carga de trabajo existente a Azure, comience con el tamaño de máquina virtual que más se asemeje a sus servidores locales. Luego, mida el rendimiento de la carga de trabajo real, en términos de CPU, memoria y operaciones de entrada/salida por segundo (IOPS) del disco, y ajuste el tamaño según sea necesario.
Por lo general, 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, consulte Productos disponibles por región. 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 Búsqueda de imágenes de máquina virtual Linux.
Discos
Para obtener el mejor rendimiento de E/S de disco, se recomiendan SSD Premium, que almacenan datos en unidades de estado sólido (SSD). El coste se basa en la capacidad del disco aprovisionado. Las E/S por segundo y el rendimiento (es decir, la velocidad de transferencia de datos), también dependen del tamaño del disco, por lo que al aprovisionar un disco, debería tener en cuenta los tres factores (capacidad, E/S por segundo y rendimiento). Los SSD Premium ofrecen una expansión gratuita que, combinada con una comprensión de los patrones de carga de trabajo, ofrece una estrategia eficaz de selección de SKU y optimización de costos para la infraestructura de IaaS. Esto permite un alto rendimiento sin exceso de aprovisionamiento y minimizando el costo de la capacidad sin usar.
Nota
Actualmente, los discos SSD Premium v2 y Ultra solo se pueden usar para discos de datos. No se admiten para discos de sistema operativo.
Managed Disks simplifican la administración de discos al encargarse del almacenamiento. 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. Managed disks también ofrecen optimización de costos al proporcionar el rendimiento deseado sin necesidad de aprovisionamiento excesivo, tener en cuenta los patrones de carga de trabajo fluctuantes y minimizar 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, se recomiendan discos de sistema operativo efímeros . Estos discos colocan la imagen del sistema operativo en el almacenamiento local del host de máquina virtual en lugar de la Azure Storage remota, lo que reduce la latencia de lectura, acelera el restablecimiento de imagen y elimina el costo del disco administrado. Sin embargo, todos los datos de un disco del sistema operativo efímero se pierden al detener (desasignación), reimagen o durante eventos de mantenimiento y reparación del host. Los discos efímeros del sistema operativo no admiten instantáneas ni copias de seguridad de Azure. Use discos de sistema operativo efímeros solo cuando las máquinas virtuales se puedan volver a desplegar completamente de la automatización.
Muchas imágenes de Linux no configuran el espacio de intercambio de forma predeterminada. Si la carga de trabajo requiere swap, créelo en el disco temporal mediante 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 Azure 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. Opcionalmente, puede especificar el id. de LUN, por ejemplo, si 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, recuerde que los id. de LUN debe ser únicos para cada disco.
Es posible que desee cambiar el programador de E/S para optimizar el rendimiento en ssd al usar discos Premium Storage. Una recomendación común es usar el programador NOOP para SSD, pero debe usar una herramienta como iostat para supervisar el rendimiento de E/S de disco en relación con la 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. Es not guardado en Azure Storage y puede eliminarse durante los reinicios y otros eventos de 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 un virtual network que se segmenta en subredes.
Interfaz de red (NIC) . La NIC permite a la máquina virtual comunicarse con el virtual network. Si necesita varias NIC para la máquina virtual, se define un número máximo de NIC para cada tamaño VM.
Dirección IP pública. Una dirección IP pública may usarse para comunicarse con la máquina virtual desde fuera de Azure a través de SSH. Sin embargo, esto no se recomienda, ya que es un riesgo de seguridad potencial.
Warning
La asociación de una dirección IP pública representa directamente un riesgo de seguridad potencial. Solo debe realizarse en circunstancias extremas y solo junto con otros métodos de seguridad, como filtrar el tráfico mediante grupos de seguridad de red.
Para el acceso de administración a una máquina virtual, se recomienda usar Azure Bastion o internamente cuando se conecte 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 si necesita una dirección IP fija que no cambie; por ejemplo, si tiene que crear un registro "A" en 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 obtener más información, consulte Crear un nombre de dominio completo en el portal de Azure.
Grupo de seguridad de red (NSG) . Los grupos de seguridad de red se usan para permitir o denegar el tráfico de red a máquinas virtuales o subredes. Se pueden asociar a las subredes o a NIC individuales conectadas a máquinas virtuales.
- Todos los NSG contienen un conjunto de reglas predeterminadas, incluida una que bloquea todo el tráfico de entrada de Internet. No se puede eliminar las reglas predeterminadas, pero otras reglas pueden reemplazarlas. Por ejemplo, para habilitar el tráfico de Internet, cree reglas que permitan el tráfico entrante a puertos específicos, como el puerto 443 para HTTPS.
Gateway de Traducción de Direcciones de Red (NAT) de Azure.Las puertas de enlace de traducción de direcciones de red (NAT) permiten que todas las instancias de una subred privada se conecten a Internet de manera saliente mientras permanecen completamente 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. La conectividad saliente a Internet deberá configurarse explícitamente mediante el uso de otros recursos, como puertas de enlace NAT, Azure equilibradores de carga estándar o firewalls. Consulte acceso saliente predeterminado en Azure para obtener más información.
Azure Bastion.Azure Bastion es una solución de plataforma como servicio 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 segura Escritorio remoto Protocol (RDP) o SSH a las máquinas virtuales directamente a través de seguridad de la capa de transporte (TLS) a través de varios métodos, incluido el portal de Azure o los clientes SSH o RDP nativos.
Operaciones
SSH. Antes de crear una máquina virtual Linux, genere un par de clave pública y 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 How to Use SSH with Linux and Mac on Azure.
Diagnóstico. Habilite la supervisión y el diagnóstico, como las métricas básicas de estado, 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 de imposibilidad de arranque. Cree una cuenta de Azure Storage para almacenar los registros. 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 Habilitación de supervisión y diagnóstico.
Disponibilidad. La máquina virtual podría verse afectada por un mantenimiento programado o un tiempo de inactividad no planeado. Puede usar los registros de reinicio de VM para determinar si un reinicio de la máquina virtual se debió al mantenimiento planeado. Para obtener una mayor disponibilidad, implemente varias máquinas virtuales en zonas de disponibilidad dentro de una región. Esto 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 contra errores de host o actualizaciones de host. Sin embargo, las zonas de disponibilidad son la opción recomendada siempre que sea posible.
Copias de seguridad. Para protegerse frente a 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 el almacenamiento con redundancia geográfica o con redundancia de zona para las copias de seguridad. Azure Backup proporciona copias de seguridad coherentes con la aplicación. Para cargas de trabajo sensibles al rendimiento o distribuciones especializadas de Linux que no admiten agentes tradicionales de copia de seguridad, use la funcionalidad de copia de seguridad consistente ante fallos de varios discos sin agente que habilita la protección de copias de seguridad automatizada sin afectar al rendimiento de la aplicación.
Parada de una máquina virtual. Azure hace una distinción entre los estados "detenidos" y "liberados". Se le cobra cuando el estado de la máquina virtual se detiene, pero no cuando se desasigna la máquina virtual. En el portal de Azure, el botón Stop libera la máquina virtual. Si apaga a través del sistema operativo mientras ha iniciado sesión, la VM se apaga pero no se desasigna, por lo que se le continuará cobrando.
Eliminación de una máquina virtual. Si elimina una máquina virtual, tiene la opción de eliminar o mantener sus discos. Esto significa que puede eliminar de forma segura la VM sin perder datos. Sin embargo, se le seguirá cobrando por los discos. Puede eliminar discos administrados igual que 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
Conjuntos de escalado de máquinas virtuales: las cargas de trabajo críticas para las operaciones empresariales nunca deben depender de una sola máquina virtual. Los conjuntos de escalas proporcionan la capacidad de distribuir las cargas de trabajo entre nodos y pueden escalar horizontalmente en momentos de mayor tráfico o reducirse cuando el tráfico es mínimo para ayudar a minimizar los costos.
Azure Load Balancer sería útil para proporcionar equilibrio de carga 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 proporcionaría funcionalidad de equilibrio de carga al Azure Load Balancer para cargas de trabajo HTTP/HTTPS dentro de una región de Azure.
Para obtener una implementación a nivel empresarial, consulte la arquitectura de línea base de Azure Virtual Machines en una zona de recepción de Azure.
Detalles del escenario
En el diagrama anterior, este escenario sería útil para proporcionar una carga de trabajo no crítica que sea útil para los usuarios solo internos.
Posibles casos de uso
Se podría usar una sola implementación de máquina virtual para hospedar una aplicación sencilla que no necesita exponerse a Internet y puede resistir algún tiempo de inactividad. Por ejemplo, esto puede ser una aplicación de informes interna básica.
Consideraciones
Estas consideraciones implementan los pilares del marco de Azure Well-Architected, que es un conjunto de principios rectores que se pueden usar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Microsoft Azure Well-Architected Framework.
Reliability
La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.
Dado que esta arquitectura es solo un ejemplo sencillo mediante una sola máquina virtual, tiene un nivel mínimo de confiabilidad. Cualquier problema con la propia máquina virtual o el host en el que se ejecuta provocará una interrupción, lo que provocará que las cargas de trabajo hospedadas no estén disponibles. Para cualquier carga de trabajo que necesite una mayor disponibilidad, se deben implementar varias máquinas virtuales que contengan la misma carga de trabajo, con esas instancias detrás de una solución de equilibrio de carga adecuada. Si se encuentran dentro de la misma región, esas máquinas virtuales deben implementarse en zonas de disponibilidad (donde se admiten) y agregarlas 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. Esto permite que la carga de trabajo siga estando disponible si una sola máquina virtual del back-end estaba inactiva.
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 o memoria.
Alta disponibilidad/recuperación ante desastres (HA/DR)
Para reducir el "radio de explosión", la carga de trabajo debe implementarse en varias regiones y aprovechar la guía de la Zona de Aterrizaje de Azure. Esto podría estar en una configuración activa-pasiva, con conmutación por error a la región secundaria si la región primaria deja de estar disponible, o en una arquitectura activa-activa donde ambas regiones envían tráfico a los consumidores. Para obtener un ejemplo, consulte Aplicación web de varios niveles creada para alta disponibilidad y recuperación ante desastres en Pasos siguientes .
En el ejemplo de ese artículo se usa Azure Site Recovery para replicar los discos de máquinas virtuales individuales a una región secundaria, donde se puede usar Site Recovery para realizar una conmutación por error de esas máquinas virtuales a la región secundaria con un objetivo de punto de recuperación (RPO)/objetivo de tiempo de recuperación (RTO).
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 garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para obtener más información, vea Lista de comprobación para la revisión de diseño de seguridad.
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 imagen completa del estado de seguridad de su implementación. Defender for Cloud está configurado por suscripción de Azure. Habilite la recopilación de datos de seguridad tal como se describe en Connect your Azure subscriptions. Una vez habilitada la recopilación de datos, Defender for Cloud busca automáticamente las máquinas virtuales creadas en esa suscripción.
Gestión de parches. Si está habilitada esta opción, Defender for Cloud comprueba si falta alguna actualización crítica y de seguridad.
Antimalware. Si está habilitado, Defender for Cloud comprueba si está instalado software antimalware. También puede usar Defender for Cloud para instalar software antimalware desde el portal de Azure.
Control de acceso. Use control de acceso basado en roles de Azure (Azure RBAC) para controlar el acceso a los recursos de Azure. Azure RBAC le permite asignar roles de autorización a los miembros del equipo de DevOps. Por ejemplo, el rol Lector puede ver Azure recursos, pero no 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 inició sesión en una máquina virtual. Esos permisos están determinados por el tipo de cuenta en el sistema operativo invitado.
Registros de auditoría. Use registros de auditoría para ver las acciones de aprovisionamiento y otros eventos de máquina virtual.
Cifrado de datos. Habilite encryption en host para lograr el cifrado de un extremo a otro para los datos de la máquina virtual, incluidos los discos temporales y las cachés 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 consiste en examinar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. 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, use Azure Reservations y Plan de ahorro de Azure para cómputo con un contrato de un año o tres años y reciba importantes ahorros respecto a los precios de pago sobre la marcha. En el caso de cargas de trabajo sin tiempo predecible de finalización o consumo de recursos, considere la opción Pago por uso.
Use Azure Spot VMs para ejecutar cargas de trabajo que se pueden interrumpir y no requieren la finalización en un período de tiempo predeterminado o un acuerdo de nivel de servicio. Azure implementa máquinas virtuales Spot si hay capacidad disponible y las retira cuando necesita recuperar la capacidad. Los costos asociados a spot virtual machines son significativamente menores. Considere la posibilidad de usar VM de Spot para estas cargas de trabajo:
- 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 el Azure Calculadora de precios para calcular los costos.
Para obtener más información, consulte la sección costo de Microsoft Azure Well-Architected Framework.
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.
Utilice plantillas de infraestructura como código (IaC) para aprovisionar recursos de Azure y sus dependencias. Pueden escribirse con Bicep, Azure Resource Manager plantillas (plantillas de ARM) o Terraform, según sus preferencias y opciones de herramientas establecidas. Estas plantillas permiten un proceso de integración continua e implementación continua (CI/CD) como parte de una metodología de implementación automatizada para implementar y configurar recursos. Este enfoque permite el control de versiones de las arquitecturas y garantiza la coherencia entre entornos, así como la aplicación de la reproducibilidad, la seguridad y el cumplimiento.
Para ayudar a supervisar y diagnosticar problemas, asegúrese de que los registros de diagnóstico están habilitados en los recursos y están disponibles para Azure Monitor para ayudar con el análisis y la optimización de los recursos. Estos registros se pueden usar para implementar alertas y notificaciones de eventos críticos y, en algunos casos, permitir la corrección automatizada o registrar un vale en el sistema de administración de servicios de TI (ITSM).
Eficiencia en el rendimiento
La eficiencia del rendimiento se centra en optimizar las cargas de trabajo en la nube para la velocidad, la capacidad de respuesta y la escalabilidad. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.
Algunos objetivos clave incluyen minimizar la latencia, garantizar arquitecturas escalables, optimizar el uso de recursos y mejorar continuamente el rendimiento del sistema.
Como se mencionó anteriormente, las decisiones tomadas con respecto a la arquitectura de la carga de trabajo, la SKU de máquina virtual y las configuraciones de disco pueden tener un gran impacto en el rendimiento de la carga de trabajo. Tomar las decisiones correctas podría impedir tener que volver a diseñar la solución en el futuro, agregando flexibilidad y ahorro de costos.
Asegúrese de tener en cuenta estos puntos al desarrollar la arquitectura:
- Use conjuntos de escalado de máquinas virtuales si la carga de trabajo tendrá una carga dinámica. Por ejemplo, escale hacia fuera en tiempos de gran cantidad de tráfico y, a continuación, escale hacia adentro cuando el tráfico se reduzca. Esto garantizará una potencia de procesamiento adecuada mientras mantiene los costos bajo control.
- 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, use grupos de selección de ubicación de proximidad (PPG) para asegurarse de que varias máquinas virtuales se encuentran físicamente cerca entre sí para lograr un mejor rendimiento. Los PPG también se pueden usar junto con conjuntos de disponibilidad para combinar baja latencia con 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, VM Insights 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. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Donnie Trumpower | Arquitecto sénior de soluciones de nube e inteligencia artificial
Pasos siguientes
- Para crear una máquina virtual Linux, consulte Quickstart: Creación de una máquina virtual Linux en el portal de Azure.
- Para instalar un controlador NVIDIA en una máquina virtual Linux, consulte Instalación de controladores de GPU de NVIDIA en máquinas virtuales de la serie N que ejecutan Linux.
- Para aprovisionar una máquina virtual Linux, consulte Crear y administrar máquinas virtuales Linux con el CLI de Azure.
- Default outbound access en Azure.
- Para obtener un ejemplo de una arquitectura más compleja, consulte arquitectura de línea base de máquinas virtuales de Azure en una zona de destino de Azure.
- Para implementar una aplicación web entre regiones, consulte Aplicación web de varios niveles creada para alta disponibilidad y recuperación ante desastres.