Compartir a través de


Arquitectura de referencia de línea base local de Azure

Azure Local
Azure Arc
Azure Key Vault
Azure Monitor
Microsoft Defender for Cloud

Esta arquitectura de referencia de línea de base proporciona instrucciones y recomendaciones independientes de la carga de trabajo para configurar Azure Local 2311 y una infraestructura posterior, para proporcionar una plataforma confiable para cargas de trabajo virtualizadas y en contenedores de alta disponibilidad. En esta arquitectura se describen los componentes de recursos y las opciones de diseño del clúster para las máquinas físicas que proporcionan funcionalidades de proceso, almacenamiento y redes locales. También se describe cómo usar los servicios de Azure para simplificar la administración diaria de Azure Local para las operaciones a escala.

Para más información sobre los patrones de arquitectura de carga de trabajo que están optimizados para ejecutarse en Azure Local, consulte el contenido que se encuentra en el menú de navegación cargas de trabajo locales de Azure .

Esta arquitectura es un punto de partida para usar el diseño de red conmutada de almacenamiento para implementar una instancia local de Azure Local de varios nodos. Las aplicaciones de carga de trabajo implementadas en una instancia local de Azure deben estar bien diseñadas. Las aplicaciones de carga de trabajo bien diseñadas deben implementarse mediante varias instancias o alta disponibilidad (HA) de cualquier servicio de carga de trabajo crítico y tener controles adecuados de continuidad empresarial y recuperación ante desastres (BCDR). Estos controles BCDR incluyen copias de seguridad periódicas y capacidades de conmutación por error en caso de recuperación ante desastres. Para centrarse en la plataforma de infraestructura hiperconvergida (HCI), estos aspectos de diseño de cargas de trabajo se excluyen intencionadamente de este artículo.

Para más información sobre las directrices y recomendaciones de los cinco pilares de Azure Well-Architected Framework, consulte la guía del servicio azure Local Well-Architected Framework de .

Diseño del artículo

Architecture Decisiones de diseño Enfoque de Well-Architected Framework
Arquitectura
Componentes de
Recursos de la plataforma
Recursos compatibles con la plataforma
Detalles del escenario
Uso de Azure Arc con Azure Local
Aproveche la configuración de seguridad predeterminada de Azure Local.
posibles casos de uso
Implementación de este escenario
opciones de diseño de clústeres
unidades de disco físico
Diseño de red
Monitorización
Administración de actualizaciones
Fiabilidad
Seguridad
Optimización de costos
Excelencia operativa
Eficiencia del rendimiento

Tip

Logotipo de GitHub Esta plantilla local de Azure muestra cómo usar una plantilla de Azure Resource Manager (plantilla de ARM) y un archivo de parámetros para implementar una implementación conmutada de varios servidores de Azure Local. Como alternativa, en el ejemplo de Bicep se muestra cómo usar una plantilla de Bicep para implementar una instancia local de Azure y sus recursos de requisitos previos.

Architecture

Diagrama que muestra una arquitectura de referencia de instancia local de Azure de varios nodos con conmutadores de la parte superior del bastidor (ToR) duales para la conectividad externa norte-sur.

Para obtener más información, consulte Recursos relacionados.

Components

Esta arquitectura consta de hardware de servidor físico que puede usar para implementar instancias locales de Azure en ubicaciones locales o perimetrales. Para mejorar las funcionalidades de la plataforma, Azure Local se integra con Azure Arc y otros servicios de Azure que proporcionan recursos auxiliares. Azure Local proporciona una plataforma resistente para implementar, administrar y operar aplicaciones de usuario o sistemas empresariales. Los recursos y servicios de la plataforma se describen en las secciones siguientes.

Recursos de la plataforma

  • Azure Local es una solución de HCI que se implementa de forma local o en ubicaciones perimetrales y usa hardware de servidor físico e infraestructura de red. Azure Local proporciona una plataforma para implementar y administrar cargas de trabajo virtualizadas, como máquinas virtuales (VM), clústeres de Kubernetes y otros servicios que Azure Arc habilita. Las instancias locales de Azure pueden escalar de una implementación de una sola máquina a un máximo de 16 máquinas físicas mediante categorías de hardware validadas, integradas o premium que proporcionan los asociados fabricantes de equipos originales (OEM). En esta arquitectura, Azure Local proporciona la plataforma principal para hospedar y administrar cargas de trabajo virtualizadas y en contenedores locales o en el perímetro.

  • Azure Arc es un servicio basado en la nube que amplía el modelo de administración basado en Resource Manager a Azure Local y otras ubicaciones que no son de Azure. Azure Arc usa Azure como plano de control y administración para habilitar la administración de varios recursos, como máquinas virtuales, clústeres de Kubernetes y datos en contenedores y servicios de aprendizaje automático. En esta arquitectura, Azure Arc permite la administración y gobernanza centralizadas de los recursos implementados en Azure Local a través del plano de control de Azure.

  • azure Key Vault es un servicio en la nube que puede usar para almacenar y acceder a secretos de forma segura. Un secreto es todo lo que desea restringir estrechamente el acceso, como claves de API, contraseñas, certificados, claves criptográficas, credenciales de administrador local y claves de recuperación de BitLocker. En esta arquitectura, Key Vault protege la información confidencial y las credenciales que usan las cargas de trabajo y los componentes de infraestructura en Azure Local.

  • El testigo en la nube es una característica que usa Azure Storage para actuar como cuórum de clúster de conmutación por error. Azure Local (solo dos máquinas) usa un cloud witness como quórum para votar, lo que garantiza la HA del clúster. La cuenta de almacenamiento y la configuración del testigo se crean durante el proceso de implementación de la nube local de Azure. En esta arquitectura, el testigo en la nube proporciona cuórum para que los clústeres de dos nodos mantengan una alta disponibilidad.

  • Azure Update Manager es un servicio unificado diseñado para administrar y controlar las actualizaciones de Azure Local. Puede usar Update Manager para administrar las cargas de trabajo que se implementan en Azure Local, incluido el cumplimiento de actualizaciones del sistema operativo invitado para máquinas virtuales Windows y Linux que se pueden habilitar mediante Azure Policy. Este enfoque unificado centraliza la administración de revisiones en azure, entornos locales y otras plataformas en la nube a través de un único panel. En esta arquitectura, Update Manager proporciona administración centralizada de actualizaciones y revisiones para la infraestructura y las cargas de trabajo.

Recursos compatibles con la plataforma

  • Azure Monitor es un servicio basado en la nube para recopilar, analizar y actuar en registros de diagnóstico y telemetría de cargas de trabajo locales y en la nube. Puede usar Azure Monitor para maximizar la disponibilidad y el rendimiento de las aplicaciones y los servicios a través de una solución de supervisión. Implemente Insights para Azure Local para simplificar la creación de la regla de recopilación de datos (DCR) de Azure Monitor y habilitar la supervisión de instancias locales de Azure. En esta arquitectura, Azure Monitor proporciona supervisión y telemetría para clústeres y cargas de trabajo locales de Azure.

  • Azure Policy es un servicio que evalúa los recursos locales y de Azure. Azure Policy evalúa los recursos mediante la integración con Azure Arc, utilizando las propiedades de esos recursos junto con las reglas de negocio, conocidas como definiciones de directivas, para determinar el cumplimiento o las capacidades que se pueden usar para aplicar la configuración de invitados en máquinas virtuales a través de las configuraciones de políticas. En esta arquitectura, Azure Policy proporciona una funcionalidad de auditoría y cumplimiento para la configuración de seguridad del sistema operativo de las máquinas locales de Azure. La configuración se aplica continuamente mediante el control de desfase.

  • Defender for Cloud es un sistema de administración de seguridad de infraestructura. Mejora la posición de seguridad de los centros de datos y ofrece protección contra amenazas avanzada para cargas de trabajo híbridas, tanto si residen en Azure como en otros lugares y en entornos locales. En esta arquitectura, Defender for Cloud proporciona supervisión de seguridad y protección contra amenazas para cargas de trabajo que se ejecutan en Azure Local.

  • Azure Backup es un servicio basado en la nube que proporciona una solución segura y rentable para realizar copias de seguridad de los datos y recuperarlos de microsoft Cloud. Azure Backup Server se usa para realizar copias de seguridad de las máquinas virtuales que se implementan en Azure Local y almacenarlas en el servicio Backup. En esta arquitectura, Azure Backup protege los datos y permite la recuperación de máquinas virtuales hospedadas en Azure Local.

  • Azure Site Recovery es un servicio de recuperación ante desastres que proporciona funcionalidades de continuidad del negocio y recuperación ante desastres (BCDR) al permitir que las aplicaciones empresariales y las cargas de trabajo realicen el cambio automático si se produce un desastre o una interrupción. Site Recovery administra la replicación y la conmutación por error de las cargas de trabajo que se ejecutan en servidores físicos y máquinas virtuales entre su sitio primario (local) y una ubicación secundaria (Azure). En esta arquitectura, Site Recovery habilita la recuperación ante desastres y la conmutación por error para cargas de trabajo que se ejecutan en Azure Local.

Detalles del escenario

En las secciones siguientes se proporciona más información sobre los escenarios y los posibles casos de uso de esta arquitectura de referencia. Estas secciones incluyen una lista de ventajas empresariales y tipos de recursos de carga de trabajo de ejemplo que puede implementar en Azure Local.

Uso de Azure Arc con Azure Local

Azure Local se integra directamente con Azure mediante Azure Arc para reducir el costo total de propiedad (TCO) y la sobrecarga operativa. Azure Local se implementa y administra a través de Azure, que proporciona integración integrada de Azure Arc mediante la implementación del componente puente de recursos de Azure Arc. Este componente se implementa como parte del proceso de implementación en la nube de la instancia local de Azure. Las máquinas locales de Azure están inscritas con Azure Arc para servidores como requisito previo para iniciar la implementación en la nube de la instancia local de Azure. Durante la implementación, las extensiones obligatorias se instalan en cada máquina, como el Administrador de ciclo de vida, la administración de dispositivos de Microsoft Edge y las extensiones de telemetría y diagnóstico. Puede usar Azure Monitor y Log Analytics después de la implementación para supervisar la solución habilitando Insights para Azure Local. Las actualizaciones de características de Azure Local se publican cada seis meses para mejorar la experiencia del cliente. Las actualizaciones de Azure Local se controlan y administran mediante Update Manager.

Puede implementar recursos de carga de trabajo como máquinas virtuales de Azure Arc, AKS habilitado para Azure Arc y hosts de sesión de Azure Virtual Desktop que usan Azure Portal seleccionando una ubicación personalizada de instancia local de Azure como destino para la implementación de cargas de trabajo. Estos componentes proporcionan administración, administración y soporte técnico centralizados. Si tiene Software Assurance activo en las licencias principales de Windows Server Datacenter existentes, puede reducir aún más los costos aplicando la Ventaja híbrida de Azure a azure Local, las máquinas virtuales Windows Server y los clústeres de AKS. Esta optimización ayuda a administrar los costos de forma eficaz para estos servicios.

La integración de Azure y Azure Arc amplían las funcionalidades de las cargas de trabajo virtualizadas y en contenedores de Azure para incluir las siguientes soluciones:

  • Máquinas virtuales locales de Azure para aplicaciones o servicios tradicionales que se ejecutan en máquinas virtuales en Azure Local.

  • AKS en Azure Local para aplicaciones o servicios en contenedores que se benefician del uso de Kubernetes como plataforma de orquestación.

  • Virtual Desktop para implementar los hosts de sesión para cargas de trabajo de Virtual Desktop en Azure local (en las instalaciones). Puede usar el plano de control y administración en Azure para iniciar la creación y configuración del grupo de hosts.

  • Azure Arc-enabled data services para instancias de Azure SQL administradas en contenedores.

  • Azure Container Apps habilitadas por Azure Arc para ejecutar aplicaciones y microservicios basados en contenedores. Puede implementarlo mediante la extensión Container Apps para Kubernetes, lo que permite el aprovisionamiento de entornos de Container Apps conectados. Después de habilitarlo en un clúster de AKS, puede ejecutar servicios como Azure Functions. Para admitir el escalado automático controlado por eventos, puede instalar opcionalmente la extensión Kubernetes Event-Driven Autoscaling (KEDA).

  • La extensión de Azure Event Grid habilitada para Azure Arc para Kubernetes para implementar los componentes agente de Event Grid y agente de Event Grid . Esta implementación permite funcionalidades como temas y suscripciones de Event Grid para el procesamiento de eventos.

  • de aprendizaje automático habilitado para Azure Arc con un clúster de AKS implementado en Azure Local como destino de proceso para ejecutar Azure Machine Learning. Puede usar este enfoque para entrenar o implementar modelos de aprendizaje automático en el perímetro.

Las cargas de trabajo conectadas a Azure Arc proporcionan una mayor coherencia y automatización de Azure Para las implementaciones locales de Azure, como automatizar la configuración del sistema operativo invitado con extensiones de máquina virtual local de Azure o evaluar el cumplimiento de las normativas del sector o los estándares corporativos mediante Azure Policy. Puede activar Azure Policy a través del portal de Azure o de la automatización de infraestructura como código (IaC).

Aproveche la configuración de seguridad predeterminada de Azure Local.

La configuración de seguridad predeterminada de Azure Local proporciona una estrategia de defensa en profundidad para simplificar los costos de seguridad y cumplimiento. La implementación y administración de servicios de TI para escenarios de venta al por menor, fabricación y oficina remota presenta desafíos únicos de seguridad y cumplimiento. La protección de cargas de trabajo frente a amenazas internas y externas es fundamental en entornos que tienen compatibilidad de TI limitada o falta o centros de datos dedicados. Azure Local tiene la protección de seguridad predeterminada y la integración profunda con los servicios de Azure para ayudarle a abordar estos desafíos.

El hardware certificado local de Azure garantiza el arranque seguro integrado, la interfaz de firmware extensible unificada (UEFI) y la compatibilidad con el módulo de plataforma segura (TPM). Use estas tecnologías en combinación con la seguridad basada en virtualización (VBS) para ayudar a proteger las cargas de trabajo sensibles a la seguridad. Puede usar el cifrado de unidad BitLocker para cifrar los volúmenes de disco de arranque y los volúmenes de Espacios de almacenamiento directo en reposo. El cifrado del bloque de mensajes del servidor (SMB) proporciona cifrado automático del tráfico entre las máquinas físicas del clúster (en la red de almacenamiento) y la firma del tráfico SMB entre las máquinas físicas del clúster y otros sistemas. El cifrado SMB también ayuda a evitar ataques de retransmisión y facilita el cumplimiento de los estándares normativos.

Puede incorporar máquinas virtuales locales de Azure en Defender for Cloud para activar el análisis de comportamiento basado en la nube, la detección de amenazas y la corrección, las alertas y los informes. Administre máquinas virtuales locales de Azure en Azure Arc para que pueda usar Azure Policy para evaluar su cumplimiento con las normativas del sector y los estándares corporativos.

Casos de uso potenciales

Entre los casos de uso típicos de Azure Local se incluyen la ejecución de cargas de trabajo de alta disponibilidad en ubicaciones locales o perimetrales. Azure Local proporciona una plataforma para satisfacer los requisitos, como las siguientes funcionalidades:

  • Proporcione una solución conectada a la nube que se implemente en el entorno local para abordar los requisitos de soberanía, regulación y cumplimiento de los datos o latencia.

  • Implemente y administre cargas de trabajo basadas en contenedores o virtualizadas de alta disponibilidad que se implementan en una o varias ubicaciones perimetrales. Esta funcionalidad permite que las aplicaciones y los servicios críticos para la empresa funcionen de forma resistente, rentable y escalable.

  • Reduzca el TCO mediante la implementación de una solución certificada por Microsoft y sus asociados oem de hardware. Esta solución usa un proceso de implementación moderno basado en la nube y proporciona una experiencia de supervisión y administración centralizada coherente de Azure.

  • Proporcione una funcionalidad de aprovisionamiento centralizada mediante Azure y Azure Arc. Esta funcionalidad permite la implementación de cargas de trabajo en varias ubicaciones de forma coherente y segura. Las herramientas como Azure Portal, la CLI de Azure o las plantillas de IaC (plantillas de ARM, Bicep y Terraform) mejoran la automatización y la repetibilidad. Este enfoque permite una implementación y administración rápidas de clústeres de Azure Kubernetes Service (AKS) para cargas de trabajo en contenedor y máquinas virtuales locales de Azure para cargas de trabajo virtualizadas tradicionales.

  • Cumplir los requisitos estrictos de seguridad, cumplimiento y auditoría. Azure Local se implementa con una posición de seguridad protegida configurada de forma predeterminada, conocida como segura de forma predeterminada. Azure Local incorpora hardware certificado, arranque seguro, TPM, VBS, Credential Guard y directivas de control de aplicaciones aplicadas. Azure Local tiene la capacidad de integrarse con servicios modernos de seguridad y administración de amenazas basados en la nube, como Microsoft Defender for Cloud y Microsoft Sentinel. Esta integración proporciona funcionalidades de detección y respuesta extendidas (XDR) y administración de eventos de información de seguridad (SIEM).

Opciones de diseño de clúster

Comprender los requisitos de rendimiento y confiabilidad de la carga de trabajo. Para lograr resistencia, comprenda las expectativas de que la plataforma y las cargas de trabajo sigan funcionando durante errores de hardware o nodo. Defina también el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) para la estrategia de recuperación. Factorice los requisitos de proceso, memoria y almacenamiento para todas las cargas de trabajo implementadas en la instancia local de Azure. Varias características de la carga de trabajo afectan al proceso de toma de decisiones:

  • Funcionalidades de arquitectura de unidad de procesamiento central (CPU), incluidas las características de la tecnología de seguridad de hardware, el número de CPU, la frecuencia de gigahercios (GHz) y el número de núcleos para cada socket de CPU.

  • Requisitos de la unidad de procesamiento de gráficos (GPU) de la carga de trabajo, como la inteligencia artificial o el aprendizaje automático, la inferencia o la representación de gráficos.

  • Memoria de cada máquina o la cantidad de memoria física necesaria para ejecutar la carga de trabajo.

  • Número de máquinas físicas de la instancia de 1 a 16 máquinas a escala. El número máximo de máquinas físicas es cuatro cuando se usa la arquitectura de red sin conmutador de almacenamiento.

    • Para mantener la resistencia de proceso, debe reservar al menos máquinas físicas N+1 de capacidad en la instancia. Esta estrategia permite la purga de nodos para las actualizaciones o la recuperación de interrupciones repentinas, como interrupciones de energía o errores de hardware.

    • En el caso de las cargas de trabajo críticas o críticas para la empresa, considere la posibilidad de reservar máquinas físicas N+2 por valor de capacidad para aumentar la resistencia. Por ejemplo, si dos máquinas físicas de la instancia están sin conexión, la carga de trabajo puede permanecer en línea. Este enfoque proporciona resistencia para escenarios en los que una máquina que ejecuta una carga de trabajo se desconecta durante un procedimiento de actualización planeado y da como resultado que dos máquinas físicas de instancia estén sin conexión simultáneamente.

  • Requisitos de resistencia, capacidad y rendimiento de almacenamiento:

    • Resiliencia: Recomendamos desplegar tres o más máquinas físicas para permitir el espejo triple, que proporciona tres copias de los datos, para los volúmenes de infraestructura y usuario. La creación de reflejo triple aumenta el rendimiento y la confiabilidad máxima para el almacenamiento.

    • Capacidad: Se tiene en cuenta el almacenamiento utilizable total necesario después de la tolerancia a errores o las copias. Este número es aproximadamente 33% del espacio de almacenamiento sin procesar de los discos de nivel de capacidad cuando se usa la creación de reflejo triple.

    • Rendimiento: Operaciones de entrada y salida por segundo (IOPS) de la plataforma que determina las funcionalidades de rendimiento de almacenamiento de la carga de trabajo cuando se multiplican por el tamaño de bloque de la aplicación.

Para diseñar y planear una implementación local de Azure, se recomienda usar la herramienta de ajuste de tamaño local de Azure y crear un nuevo proyecto para cambiar el tamaño de las instancias locales de Azure. El uso de la herramienta de ajuste de tamaño requiere que comprenda los requisitos de la carga de trabajo. Cuando tenga en cuenta el número y el tamaño de las máquinas virtuales de carga de trabajo que se ejecutan en la instancia, asegúrese de tener en cuenta factores como el número de vCPU, los requisitos de memoria y la capacidad de almacenamiento necesaria para las máquinas virtuales.

La sección Preferencias de la herramienta de ajuste de tamaño le guía a través de preguntas relacionadas con el tipo de sistema, incluida la solución Premier, el sistema integrado o el nodo validado y las opciones de familia de CPU. También le ayuda a seleccionar los requisitos de resistencia de la instancia. Para establecer niveles de resistencia, siga estas recomendaciones:

  • Reserve un mínimo de capacidad equivalente a N+1 máquinas físicas o un nodo dentro de la instancia. Este enfoque garantiza que puede aplicar actualizaciones de soluciones mediante la purga y el reinicio de cada nodo uno a uno, sin provocar tiempo de inactividad de la carga de trabajo.

  • Reserva una capacidad equivalente a N+2 máquinas físicas en toda la instancia para obtener una mayor resistencia. Esta opción permite al sistema resistir un error de máquina durante una actualización u otro evento inesperado que afecte a dos máquinas simultáneamente. También garantiza que haya suficiente capacidad en la instancia de para que la carga de trabajo se ejecute en las máquinas en línea restantes.

Este escenario requiere el uso de la creación de reflejo triple para los volúmenes de usuario, que es el valor predeterminado para las instancias que tienen tres o más máquinas físicas.

La salida de la herramienta de ajuste de tamaño local de Azure es una lista de las SKU de solución de hardware recomendadas que pueden proporcionar la capacidad de carga de trabajo necesaria y los requisitos de resistencia de la plataforma en función de los valores de entrada del proyecto Sizer. Para más información sobre las soluciones de asociados de hardware OEM disponibles, consulte Catálogo de soluciones locales de Azure. Para ayudar a ajustar correctamente el tamaño de las SKU de solución para satisfacer sus requisitos, póngase en contacto con el proveedor de soluciones de hardware preferido o el asociado de integración del sistema (SI).

Unidades de disco físicas

Espacios de almacenamiento directo admite varios tipos de unidad de disco físico que varían en el rendimiento y la capacidad. Al diseñar una instancia local de Azure, trabaje con el asociado oem de hardware elegido para determinar los tipos de unidad de disco físico más adecuados para satisfacer los requisitos de capacidad y rendimiento de la carga de trabajo. Algunos ejemplos incluyen unidades de disco duro giratorias (HDD) o unidades de estado sólido (SSD) y unidades de memoria express (NVMe) no volátiles. Estas unidades se conocen a menudo como unidades flash o almacenamiento de memoria persistente (PMem), que se conoce como memoria de clase de almacenamiento (SCM).

La confiabilidad de la plataforma depende del rendimiento de las dependencias críticas de la plataforma, como los tipos de disco físico. Asegúrese de elegir los tipos de disco correctos para sus requisitos. Use soluciones de almacenamiento all-flash, como unidades NVMe o SSD para cargas de trabajo que tengan requisitos de alto rendimiento o baja latencia. Estas cargas de trabajo incluyen, entre otras, tecnologías de base de datos transaccionales, clústeres de AKS de producción o cargas de trabajo críticas o críticas para la empresa que tengan requisitos de almacenamiento de baja latencia o alto rendimiento. Use implementaciones all-flash para maximizar el rendimiento del almacenamiento. Configuraciones completamente NVMe o completamente SSD, especialmente a menor escala, mejoran la eficiencia del almacenamiento y maximizan el rendimiento porque no se usa ninguna unidad como capa de caché. Para obtener más información, consulte almacenamiento basado en Todo flash.

Diagrama que muestra una arquitectura de almacenamiento de instancia local de Azure de varios nodos para una solución de almacenamiento híbrido. Usa unidades NVMe como el nivel de caché y las unidades SSD para la capacidad.

El tipo de unidad de disco físico influye en el rendimiento del almacenamiento del clúster. El tipo de unidad varía en función de las características de rendimiento de cada tipo de unidad y del mecanismo de almacenamiento en caché que elija. El tipo de unidad de disco físico es una parte integral de cualquier diseño y configuración de Espacios de almacenamiento directo. Según los requisitos de carga de trabajo local de Azure y las restricciones presupuestarias, puede elegir maximizar el rendimiento, maximizar la capacidad o implementar una configuración de tipo de unidad mixta que equilibre el rendimiento y la capacidad.

Para cargas de trabajo de uso general que requieren un almacenamiento persistente de gran capacidad, una configuración de almacenamiento híbrido puede proporcionar el almacenamiento más utilizable, como el uso de unidades NVMe o SSD para el nivel de caché y los HDD para la capacidad. La compensación es que los discos duros tienen un rendimiento y una capacidad de transferencia inferiores en comparación con las unidades flash. Estas limitaciones pueden afectar al rendimiento del almacenamiento si la carga de trabajo supera el conjunto de trabajo de caché. Además, los HDD tienen un tiempo medio inferior entre el valor de error en comparación con las unidades NVMe y los SSD.

Espacios de almacenamiento directo proporciona una caché integrada del lado servidor persistente que admite operaciones de lectura y escritura. Esta caché maximiza el rendimiento del almacenamiento. Ajuste el tamaño y configure la memoria caché para dar cabida al conjunto de trabajo de las aplicaciones y las cargas de trabajo. Los discos virtuales de Espacios de Almacenamiento Directo o volúmenes se utilizan en combinación con la memoria caché de lectura en volúmenes compartidos de clúster (CSV) para mejorar el rendimiento de Hyper-V. Esta combinación es especialmente eficaz para el acceso de entrada sin búfer a los archivos de disco duro virtual (VHD) o disco duro virtual v2 (VHDX) de carga de trabajo.

Tip

Para cargas de trabajo sensibles a la latencia o alto rendimiento, se recomienda usar una configuración de almacenamiento todo flash (todo NVMe o ssd) y un tamaño de clúster de tres o más máquinas físicas. La implementación de este diseño con la configuración de almacenamiento predeterminada usa de creación de reflejo triple para los volúmenes de infraestructura y usuario. Esta estrategia de implementación proporciona el mayor rendimiento y resistencia. Cuando se usa una configuración all-NVMe o all-SSD, se beneficia de la capacidad de almacenamiento utilizable completa de cada unidad flash. A diferencia de las configuraciones de NVMe y SSD híbridas o mixtas, no hay capacidad reservada para el almacenamiento en caché cuando se usa un solo tipo de unidad. Esta configuración garantiza un uso óptimo de los recursos de almacenamiento. Para obtener más información sobre cómo equilibrar el rendimiento y la capacidad para satisfacer los requisitos de la carga de trabajo, consulte Planeamiento de volúmenes: cuando el rendimiento sea importante para la mayoría de los.

Diseño de red

El diseño de red es la disposición general de los componentes dentro de la infraestructura física de la red y las configuraciones lógicas. Puede usar los mismos puertos de tarjeta de interfaz de red física (NIC) para todas las combinaciones de intenciones de red de administración, proceso y almacenamiento. El uso de los mismos puertos NIC para todos los propósitos relacionados con la intención se conoce como una configuración de red totalmente convergente.

Se admite una configuración de red totalmente convergente, pero la configuración óptima para el rendimiento y la confiabilidad es que la intención de almacenamiento use puertos de adaptador de red dedicados. Como resultado, esta arquitectura de línea de base proporciona instrucciones de ejemplo sobre cómo implementar una instancia de Azure Local de varios nodos mediante el uso de la arquitectura de red conmutada de almacenamiento con dos puertos de adaptador de red convergentes para intentos de gestión y cómputo y dos puertos de adaptador de red dedicados para el intento de almacenamiento. Para más información, consulte Consideraciones de red para las implementaciones en la nube de Azure Local.

Esta arquitectura requiere dos o más máquinas físicas y hasta un máximo de 16 máquinas a escala. Cada máquina requiere cuatro puertos de adaptador de red que están conectados a dos conmutadores de la parte superior del bastidor (ToR). Los dos conmutadores ToR deben estar interconectados a través de vínculos de vínculo de varios chasis (MLAG). Los dos puertos de adaptador de red que se usan para el tráfico de intención de almacenamiento deben admitir acceso directo a memoria remota (RDMA). Estos puertos requieren una velocidad de vínculo mínima de 10 gigabits por segundo (Gbps), pero se recomienda una velocidad de 25 Gbps o superior. Los dos puertos de adaptador de red utilizados para las funciones de administración y cómputo se integran mediante la tecnología Switch Embedded Teaming (SET). La tecnología SET proporciona redundancia de vínculos y funcionalidades de equilibrio de carga. Estos puertos requieren una velocidad de vínculo mínima de 1 Gbps, pero se recomienda una velocidad de 10 Gbps o superior.

Topología de red física

La siguiente topología de red física muestra las conexiones de red físicas entre las máquinas locales de Azure y los componentes de red.

Necesita los siguientes componentes al diseñar un almacenamiento de múltiples nodos conmutado en una implementación local de Azure que utiliza esta arquitectura de referencia.

Diagrama que muestra la topología de red física para una instancia local de Azure de varios nodos que usa una arquitectura de almacenamiento conmutada con conmutadores ToR duales.

  • Conmutadores tor duales:

    • Los conmutadores de red tor duales son necesarios para la resistencia de red y para atender o aplicar actualizaciones de firmware a los conmutadores sin incurrir en tiempo de inactividad. Esta estrategia impide un único punto de error (SPoF).

    • Los conmutadores ToR duales se usan para el almacenamiento o el tráfico este-oeste. Estos conmutadores usan dos puertos Ethernet dedicados que tienen redes de área local virtuales de almacenamiento específicas (VLAN) y clases de tráfico de control de flujo de prioridad (PFC) definidas para proporcionar comunicación RDMA sin pérdida.

    • Estos conmutadores se conectan a las máquinas físicas a través de cables Ethernet.

  • Dos o más máquinas físicas y hasta un máximo de 16 máquinas físicas:

    • Cada máquina es un servidor físico que ejecuta el sistema operativo Azure Stack HCI.

    • Cada máquina requiere cuatro puertos de adaptador de red en total: dos puertos compatibles con RDMA para el almacenamiento y dos puertos de adaptador de red para la administración y el tráfico de proceso.

    • Storage usa los dos puertos de adaptador de red compatibles con RDMA dedicados que se conectan con una ruta de acceso a cada uno de los dos conmutadores ToR. Este enfoque proporciona redundancia de ruta de acceso de vínculo y ancho de banda prioritario dedicado para el tráfico de almacenamiento directo de SMB.

    • La administración y el proceso usan dos puertos de adaptador de red que proporcionan una ruta de acceso a cada uno de los dos conmutadores ToR para la redundancia de la ruta de acceso de vínculo.

  • Conectividad externa:

    • Los conmutadores ToR duales se conectan a la red externa, como a su red de área local (LAN) corporativa interna, para proporcionar acceso a las direcciones URL de salida necesarias mediante su dispositivo de red perimetral de borde. Este dispositivo puede ser un firewall o enrutador. Estos conmutadores enrutan el tráfico que entra y sale de la instancia local de Azure o del tráfico norte-sur.

    • La conectividad del tráfico norte-sur externo admite la intención de administración de clústeres y las intenciones de proceso. Esta configuración de red se logra mediante dos puertos de conmutador y dos puertos de adaptador de red para cada máquina que se converge a través de SET y un conmutador virtual dentro de Hyper-V para garantizar la resistencia. Estos componentes proporcionan conectividad externa para máquinas virtuales locales de Azure y otros recursos de carga de trabajo implementados en las redes lógicas que se crean en Resource Manager mediante Azure Portal, la CLI de Azure o las plantillas de IaC.

Topología de red lógica

La topología de red lógica muestra información general sobre cómo fluyen los datos de red entre dispositivos, independientemente de sus conexiones físicas.

En el ejemplo siguiente se muestra un resumen de la configuración lógica para esta arquitectura de línea de base conmutada de almacenamiento de varios nodos para Azure Local.

Diagrama que muestra la topología de red lógica para una instancia local de Azure local de varios nodos mediante la arquitectura conmutada de almacenamiento con conmutadores ToR duales.

  • Conmutadores tor duales:

    • Antes de implementar el clúster, los dos conmutadores de red ToR deben configurarse con los identificadores de VLAN necesarios, la configuración máxima de la unidad de transmisión y la configuración de puente del centro de datos para los puertos de administración, proceso y almacenamiento . Para obtener más información, consulte Requisitos de red física para Azure Localo solicite ayuda al proveedor de hardware del conmutador o al asociado de SI.
  • Network ATC:

    • Azure Local usa el enfoque de Network ATC para aplicar la automatización de red y la configuración de red basada en intenciones.

    • Azure Local usa el enfoque de Network ATC para aplicar la automatización de red y la configuración de red basada en intenciones.

    • Network ATC está diseñado para garantizar una configuración de red óptima y el flujo de tráfico mediante intenciones de tráfico de red. Network ATC define qué puertos de adaptador de red físicos se usan para las diferentes intenciones de tráfico de red (o tipos), como para la administración del clúster, el proceso de carga de trabajo y las intenciones de almacenamiento del clúster.

    • Las directivas basadas en intenciones simplifican los requisitos de configuración de red mediante la automatización de la configuración de red de la máquina en función de las entradas de parámetro que se especifican como parte del proceso de implementación de la nube local de Azure.

  • Comunicación externa:

    • Cuando las máquinas físicas o la carga de trabajo necesitan comunicarse externamente mediante el acceso a la LAN corporativa, Internet u otro servicio, se enrutan a través de los conmutadores ToR duales.

    • Cuando los dos conmutadores ToR sirven como dispositivos de nivel 3, controlan el enrutamiento y proporcionan conectividad más allá del clúster al dispositivo de borde perimetral, como el firewall o el enrutador.

    • La intención de red de administración usa la interfaz virtual del equipo SET convergente, que permite que la dirección IP de administración del clúster y los recursos del plano de control se comuniquen externamente.

    • Para la intención de red de proceso, puede crear una o varias redes lógicas en Azure con los identificadores de VLAN específicos para su entorno. Los recursos de carga de trabajo, como las máquinas virtuales, usan estos identificadores para conceder acceso a la red física. Las redes lógicas usan los dos puertos de adaptador de red físicos que convergen mediante un equipo SET para las intenciones de proceso y administración.

  • Tráfico de almacenamiento:

    • Las máquinas físicas se comunican entre sí mediante dos puertos de adaptador de red dedicados que están conectados a los conmutadores ToR para proporcionar un alto ancho de banda y resistencia para el tráfico de almacenamiento.

    • Los puertos de almacenamiento SMB1 y SMB2 se conectan a dos redes no enrutables independientes (o capa 2). Cada red tiene un identificador de VLAN específico configurado que debe coincidir con la configuración de los puertos de conmutador en el identificadores de VLAN de almacenamiento predeterminados: 711 y 712.

    • No hay ninguna puerta de enlace predeterminada configurada en los dos puertos de adaptador de red de intención de almacenamiento dentro del sistema operativo Azure Stack HCI.

    • Cada nodo de clúster puede acceder a las funcionalidades de Espacios de almacenamiento directo del clúster, como unidades físicas remotas que se usan en el bloque de almacenamiento, los discos virtuales y los volúmenes. El acceso a estas funcionalidades se facilita a través del protocolo RDMA de SMB-Direct a través de los dos puertos de adaptador de red de almacenamiento dedicados que están disponibles en cada máquina. SMB multicanal se usa para la resistencia.

    • Esta configuración proporciona una velocidad de transferencia de datos suficiente para las operaciones relacionadas con el almacenamiento, como mantener copias coherentes de datos para volúmenes reflejados.

Requisitos del conmutador de red

Los conmutadores Ethernet deben cumplir las distintas especificaciones requeridas por Azure Local y establecidas por el Institute of Electrical and Electronics Engineers Standards Association (IEEE SA). Por ejemplo, para implementaciones conmutadas de almacenamiento de varios nodos, la red de almacenamiento se usa para RDMA a través de RoCE v2 o iWARP. Este proceso requiere IEEE 802.1Qbb PFC para garantizar la comunicación sin pérdida para la clase de tráfico de almacenamiento . Los conmutadores ToR deben proporcionar compatibilidad con IEEE 802.1Q para VLAN y IEEE 802.1AB para el Protocolo de detección de capas de vínculo.

Si tiene previsto usar conmutadores de red existentes para una implementación local de Azure, revise la lista de de las especificaciones y estándares DE IEEE obligatorios que deben proporcionar los conmutadores de red y la configuración. Al comprar nuevos conmutadores de red, revise la lista de modelos de conmutador certificados por el proveedor de hardware que admiten los requisitos de red local de Azure.

Requisitos de direcciones IP

En una implementación conmutada de almacenamiento de varios nodos, el número de direcciones IP necesarias aumenta con la adición de cada máquina física, hasta un máximo de 16 máquinas físicas dentro de un único clúster. Por ejemplo, para implementar una configuración conmutada de almacenamiento de dos nodos de Azure Local, la infraestructura del clúster requiere que se asignen 11 x direcciones IP como mínimo. Se requieren más direcciones IP si usa microsegmentación o redes definidas por software. Para más información, consulte Revisión de los requisitos de dirección IP del patrón de referencia de almacenamiento de dos nodos para Azure Local.

Al diseñar y planear los requisitos de direcciones IP para Azure Local, recuerde tener en cuenta las direcciones IP adicionales o los intervalos de red necesarios para la carga de trabajo más allá de las necesarias para los componentes de la instancia local y de la infraestructura de Azure. Si tiene previsto implementar AKS en Azure Local, consulte AKS habilitado por los requisitos de red de Azure Arc.

Conectividad de red saliente

Es importante comprender los requisitos de conectividad de red salientes de Azure Local y tener en cuenta estos requisitos en el plan de diseño e implementación antes de implementar la solución. Se requiere conectividad de red saliente para permitir que Azure Local se comunique con Azure y Azure Arc para las operaciones de administración y plano de control. Por ejemplo, la conectividad saliente es necesaria para aprovisionar recursos habilitados para Azure Arc, como máquinas virtuales locales de Azure o clústeres de AKS, y para usar servicios de administración de Azure como Update Manager y Azure Monitor.

La planeación inicial y la debida diligencia para habilitar la comunicación de red con los puntos de conexión públicos necesarios es fundamentalmente importante al integrar Azure Local en una red de centro de datos local existente. Este requisito es especialmente importante si tiene reglas de salida estrictas configuradas en dispositivos proxy o firewall. Además, si los controles de seguridad de red incluyen tecnologías de inspección de Secure Sockets Layer (SSL), tenga en cuenta que la inspección SSL no es compatible con la comunicación de la red local de Azure.

¿Por qué importa la conectividad de red saliente?

La conectividad de red saliente es necesaria desde la instancia local de Azure. Este requisito incluye las máquinas físicas, el dispositivo de puente de recursos de Azure Arc , los clústeres de AKS y las máquinas virtuales locales de Azure si usa Azure Arc para la administración del sistema operativo invitado de máquina virtual. Estos dispositivos tienen agentes locales o servicios que se conectan a puntos de conexión públicos a través de acceso de red saliente para la comunicación en tiempo real, lo que permite la conectividad con los proveedores de recursos del plano de control y administración que operan en Azure. Por ejemplo, la conectividad saliente es necesaria para que los operadores usen Azure Portal, la CLI de Azure o herramientas de IaC, como arm, Bicep o plantillas de Terraform para aprovisionar recursos, administrarlos o realizar ambas acciones. Azure y el puente de recursos de Azure Arc funcionan en combinación con el recurso de ubicación personalizada de la instancia local de Azure. Esta combinación le permite tener como destino la instancia local de Azure específica para cualquier operación CRUD de recursos (crear, leer, actualizar o eliminar) para los recursos de carga de trabajo habilitados para Azure Arc.

Para habilitar la conectividad, configure el firewall, el proxy o la tecnología de salida de Internet, o una combinación de estos componentes, para permitir el acceso saliente a los puntos de conexión públicos necesarios. Tenga en cuenta las siguientes consideraciones clave para los requisitos de red de salida local de Azure:

  • Azure Local no admite la inspección de paquetes SSL/TLS a lo largo de ninguna de las rutas de acceso de red de las instancias locales de Azure a los puntos de conexión públicos. Además, no se admiten Private Link y Azure ExpressRoute para la conexión con los puntos de acceso públicos necesarios. Para más información, consulte requisitos de firewall de para Azure Local.

  • Considere la posibilidad de usar la puerta de enlace de Azure Arc para simplificar los requisitos de conectividad. Este enfoque reduce significativamente el número de puntos de conexión necesarios que se deben agregar a las reglas de firewall o proxy para la implementación y administración de Azure Local.

  • Al implementar Azure Local mediante un servidor proxy para controlar y administrar el acceso de salida de Internet, revise los requisitos del proxy.

Monitoring

Insights para Azure Local se basa en Azure Monitor y Log Analytics, lo que garantiza una solución siempre up-to-date y escalable que es altamente personalizable. Insights proporciona acceso a libros predeterminados con métricas básicas, junto con libros especializados creados para supervisar características clave de Azure Local. Estos componentes proporcionan una solución de supervisión casi en tiempo real y permiten la creación de gráficos, la personalización de las visualizaciones a través de la agregación y el filtrado, y la configuración de reglas de alertas personalizadas de Resource Health.

Para mejorar la supervisión y las alertas, habilite Azure Monitor Insights en Azure Local. Insights se puede escalar para supervisar y administrar varias instancias locales a través de una experiencia coherente con Azure. Insights usa contadores de rendimiento del clúster y canales de registro de eventos para supervisar las características clave de Azure Local. La DCR configurada a través de Azure Monitor y Log Analytics recoge los registros.

Administración de actualizaciones

Las instancias locales de Azure y los recursos de carga de trabajo implementados, como las máquinas virtuales locales de Azure, deben actualizarse y revisarse periódicamente. Al aplicar actualizaciones periódicamente, asegúrese de que su organización mantiene una posición de seguridad sólida. También mejora la confiabilidad general y la capacidad de soporte de su patrimonio. Se recomienda usar evaluaciones manuales automáticas y periódicas para la detección temprana y la aplicación de revisiones de seguridad y actualizaciones del sistema operativo.

Actualizaciones de infraestructura

Azure Local se actualiza continuamente para mejorar la experiencia del cliente e introducir nuevas características y funcionalidades. Las actualizaciones de nuevas funciones se entregan cada seis meses a través de esquemas de lanzamiento, con nuevas versiones publicadas en abril (YY04) y octubre (YY10). Además de las actualizaciones de características periódicas, Azure Local recibe actualizaciones acumulativas mensuales que incluyen mejoras de confiabilidad y seguridad del sistema operativo, así como actualizaciones de extensiones y agentes.

Update Manager es un servicio de Azure que puede usar para aplicar, ver y administrar actualizaciones para Azure Local. Este servicio proporciona un mecanismo para ver todas las instancias locales de Azure en toda la infraestructura y las ubicaciones perimetrales que usan Azure Portal para proporcionar una experiencia de administración centralizada. Para obtener más información, consulte los siguientes recursos:

Es importante comprobar si hay nuevas actualizaciones de controladores y firmware con regularidad, como cada tres a seis meses. Si usa una versión de categoría Premier Solution para el hardware local de Azure, las actualizaciones de paquetes de la extensión del Generador de soluciones (SBE) se integran con Update Manager para proporcionar una experiencia de actualización simplificada. Si usa nodos validados o una categoría de sistema integrada, puede haber un requisito para descargar y ejecutar un paquete de actualización específico del OEM que contenga las actualizaciones de firmware y controladores para el hardware. Para determinar cómo se proporcionan las actualizaciones para el hardware, póngase en contacto con el oem de hardware o el asociado de SI.

Aplicación de revisiones del sistema operativo invitado de carga de trabajo

Puede inscribir máquinas virtuales locales de Azure que se implementan en Azure Local en Update Manager para proporcionar una experiencia unificada de administración de revisiones mediante el mismo mecanismo que se usa para actualizar las máquinas físicas de la instancia local de Azure. Puede usar Update Manager para crear configuraciones de mantenimiento de invitado. Estas configuraciones controlan las opciones de configuración de reinicio, si es necesario, la programación (fechas, horas y opciones de repetición) y una lista dinámica (suscripción) o estática de las máquinas virtuales locales de Azure para el ámbito. Esta configuración controla la configuración de cuando se instalan revisiones de seguridad del sistema operativo dentro del sistema operativo invitado de la máquina virtual de carga de trabajo.

Considerations

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, vea Lista de comprobación de revisión de diseño para lade confiabilidad.

Identificar los posibles puntos de error

Cada arquitectura es susceptible a errores. Puede prever errores y prepararse con mitigaciones mediante el análisis del modo de error (FMA). En la tabla siguiente se describen cuatro ejemplos de posibles puntos de error en esta arquitectura.

Component Risk Likelihood Impacto y mitigación Outage
Interrupción de la instancia local de Azure Error de alimentación, red, hardware o software Medium Para evitar una interrupción prolongada de la aplicación causada por el fallo de una instancia local de Azure en casos de uso críticos o esenciales para el negocio, la carga de trabajo debe diseñarse utilizando principios de Alta Disponibilidad y Recuperación ante Desastres. Por ejemplo, puede usar tecnologías de replicación de datos de carga de trabajo estándar del sector para mantener varias copias de datos de estado persistentes que se implementan mediante varias máquinas virtuales locales de Azure o instancias de AKS que se implementan en instancias locales de Azure independientes y en ubicaciones físicas independientes. Posible interrupción
Interrupción de una sola máquina física local de Azure Error de energía, hardware o software Medium Para evitar una interrupción prolongada de la aplicación causada por el error de una sola máquina local de Azure, la instancia local de Azure debe tener varias máquinas físicas. Los requisitos de capacidad de carga de trabajo durante la fase de diseño del clúster determinan el número de máquinas físicas. Se recomienda tener tres o más máquinas físicas. También se recomienda usar la creación de reflejo triple, que es el modo de resistencia de almacenamiento predeterminado para los clústeres con tres o más máquinas físicas. Para evitar una SPoF y aumentar la resistencia de la carga de trabajo, implemente varias instancias de la carga de trabajo mediante dos o más máquinas virtuales locales de Azure o pods de contenedor que se ejecutan en varios nodos de trabajo de AKS. Si se produce un error en una sola máquina, las máquinas virtuales locales de Azure y los servicios de carga de trabajo o aplicación se reinician en las máquinas físicas en línea restantes del clúster. Posible interrupción
Máquina virtual local de Azure o nodo de trabajo de AKS (carga de trabajo) Misconfiguration Medium Los usuarios de la aplicación no pueden iniciar sesión ni acceder a la aplicación. Identificar configuraciones incorrectas durante la implementación. Si estos errores se producen durante una actualización de configuración, el equipo de DevOps debe revertir los cambios. Si es necesario, puede volver a implementar la máquina virtual. La reimplementación tarda menos de 10 minutos en implementarse, pero puede tardar más en función del tipo de implementación. Posible interrupción
Conectividad a Azure Interrupción de la red Medium Azure Local requiere conectividad de red a Azure para que las operaciones del plano de control estén disponibles. Por ejemplo, para aprovisionar nuevas máquinas virtuales locales de Azure o clústeres de AKS, instale las actualizaciones de soluciones mediante Update Manager o supervise el estado de mantenimiento de la instancia mediante Azure Monitor. Si la conectividad a Azure no está disponible, la instancia funciona en un estado degradado, donde estas funcionalidades no están disponibles. Sin embargo, las cargas de trabajo existentes que ya se ejecutan en Azure Local continúan ejecutándose. Si la conectividad de red a Azure no se restaura en un plazo de 30 días, la instancia escribe un estado "Fuera de directiva", que puede limitar la funcionalidad. El dispositivo de puente de recursos de Azure no puede estar sin conexión durante más de 45 días , ya que esta inactividad puede afectar a la validez de la clave de seguridad usada para la autenticación. Operaciones de administración no disponibles

Para obtener más información, consulte Recomendaciones para realizar FMA.

Destinos de confiabilidad

En esta sección se describe un escenario de ejemplo. Un cliente ficticio conocido como Contoso Manufacturing usa esta arquitectura de referencia para implementar Azure Local. Quieren abordar sus requisitos e implementar y administrar cargas de trabajo en el entorno local. Contoso Manufacturing tiene un objetivo interno de objetivo de nivel de servicio (SLO) de 99,8% que las partes interesadas de la empresa y la aplicación coinciden en sus servicios.

  • Un SLO de tiempo de actividad del 99.8%, o disponibilidad, da como resultado los siguientes períodos de tiempo de inactividad permitidos, o falta de disponibilidad, para las aplicaciones que se implementan mediante máquinas virtuales que se ejecutan en Azure Local:

    • Semanal: 20 minutos y 10 segundos

    • Mensual: 1 hora, 26 minutos y 56 segundos

    • Trimestral: 4 horas, 20 minutos y 49 segundos

    • Anual: 17 horas, 23 minutos y 16 segundos

  • Para ayudar a cumplir los objetivos de SLO, Contoso Manufacturing implementa el principio de privilegios mínimos (PoLP) para restringir el número de administradores de instancias locales de Azure a un pequeño grupo de usuarios de confianza y calificados. Este enfoque ayuda a evitar el tiempo de inactividad debido a acciones involuntarias o accidentales realizadas en los recursos de producción. Además, los registros de eventos de seguridad de los controladores de dominio de Active Directory Domain Services (AD DS) locales se supervisan para detectar e informar de los cambios de pertenencia a grupos de cuentas de usuario, conocidos como acciones de adición y eliminación , para el grupo de administradores de instancias locales de Azure que usa una solución SIEM. La supervisión aumenta la confiabilidad y mejora la seguridad de la solución.

    Para obtener más información, consulte Recomendaciones para la administración de identidades y acceso.

  • procedimientos estrictos de control de cambios están en vigor para los sistemas de producción de Contoso Manufacturing. Este proceso requiere que todos los cambios se prueben y validen en un entorno de prueba representativo antes de la implementación en producción. Todos los cambios enviados al proceso semanal del consejo de asesoramiento de cambios deben incluir un plan de implementación detallado (o vínculo al código fuente), una puntuación de nivel de riesgo, un plan de reversión completo, pruebas posteriores a la versión y comprobación, y criterios claros de éxito para que se revise o apruebe un cambio.

    Para obtener más información, consulte recomendaciones de para procedimientos de implementación seguros.

  • Las revisiones de seguridad mensuales y las actualizaciones trimestrales de línea base se aplican a las instancias locales de Azure de producción solo después de que el entorno de preproducción las valide. Update Manager y la característica de actualización compatible con el clúster automatizan el proceso de uso de migración en vivo de máquinas virtuales para minimizar el tiempo de inactividad de las cargas de trabajo críticas para la empresa durante las operaciones de mantenimiento mensuales. Los procedimientos operativos estándar de Contoso Manufacturing requieren que las actualizaciones de compilación de seguridad, confiabilidad o base de referencia se apliquen a todos los sistemas de producción en un plazo de cuatro semanas a partir de su fecha de lanzamiento. Sin esta directiva, los sistemas de producción no pueden mantenerse al día con las actualizaciones mensuales del sistema operativo y de seguridad. Los sistemas obsoletos afectan negativamente a la confiabilidad y seguridad de la plataforma.

    Para obtener más información, consulte Recomendaciones para establecer una línea base de seguridad.

  • Contoso Manufacturing implementa copias de seguridad diarias, semanales y mensuales para conservar los últimos 6 x días de copias de seguridad diarias (lunes a sábado), las últimas 3 x semanales (cada domingo) y 3 x copias de seguridad mensuales, y cada domingo 4 se conservan para convertirse en las copias de seguridad del mes 1, el mes 2 y el mes 3 mediante una programación basada en calendario gradual documentada y auditable. Este enfoque cumple los requisitos de fabricación de Contoso para obtener un equilibrio adecuado entre el número de puntos de recuperación de datos disponibles y reducir los costos del servicio de almacenamiento de copia de seguridad en la nube o fuera del sitio.

    Para obtener más información, consulte Recomendaciones para diseñar una estrategia de recuperación ante desastres.

  • los procesos de copia de seguridad y recuperación de datos se prueban para cada sistema empresarial cada seis meses. Esta estrategia garantiza que los procesos de BCDR son válidos y que la empresa está protegida si se produce un desastre en un centro de datos o un incidente cibernético.

    Para obtener más información, consulte Recomendaciones para diseñar una estrategia de pruebas de confiabilidad.

  • Los procesos operativos y los procedimientos descritos anteriormente en el artículo y las recomendaciones de la guía del servicio Well-Architected Framework para Azure Local, habilite Contoso Manufacturing para cumplir su destino de SLO 99.8% y escale y administre de forma eficaz las implementaciones de Azure Local y de cargas de trabajo en varios sitios de fabricación distribuidos en todo el mundo.

    Para obtener más información, consulte recomendaciones de para definir destinos de confiabilidad.

Redundancy

Considere una carga de trabajo que implemente en una sola instancia local de Azure como una implementación con redundancia local. El clúster proporciona alta disponibilidad a nivel de plataforma, pero se debe implementar el clúster en un único rack. En el caso de casos de uso críticos o críticos para la empresa, se recomienda implementar varias instancias de una carga de trabajo o servicio en dos o más instancias locales de Azure independientes, idealmente en ubicaciones físicas independientes.

Use patrones de alta disponibilidad estándar del sector para cargas de trabajo que proporcionan replicación activa/pasiva, replicación sincrónica o replicación asincrónica, como SQL Server AlwaysOn. También puede usar una tecnología externa de equilibrio de carga de red (NLB) que enruta las solicitudes de usuario a través de varias instancias de carga de trabajo que se ejecutan en instancias locales de Azure que se implementan en ubicaciones físicas independientes. Considere la posibilidad de usar un dispositivo NLB externo asociado. También puede evaluar las opciones de equilibrio de carga que admiten el enrutamiento de tráfico para servicios híbridos y locales, como una instancia de Azure Application Gateway que usa ExpressRoute o un túnel VPN para conectarse a un servicio local.

Para obtener más información, consulte recomendaciones de para diseñar la redundancia.

Security

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

  • Una base segura para la plataforma local de Azure:Azure Local es un producto seguro de forma predeterminada que usa componentes de hardware validados con un TPM, UEFI y arranque seguro para crear una base segura para la seguridad de la carga de trabajo y la plataforma local de Azure. Cuando se implementa con la configuración de seguridad predeterminada, Azure Local tiene habilitado El control de aplicaciones, Credential Guard y BitLocker. Para simplificar la delegación de permisos usando el principio de menor privilegio (PoLP), utilice los roles integrados de control de acceso basado en roles (RBAC) de Azure Local, como el de Administrador Local de Azure para los administradores de la plataforma y los roles de Colaborador de Máquina Virtual Local de Azure o Lector de Máquinas Virtuales Locales de Azure para los operadores de operaciones de carga de trabajo.

  • Configuración de seguridad predeterminada: Azure Local aplica la configuración de seguridad predeterminada para la instancia local de Azure durante la implementación y permite que el control de desfase mantenga las máquinas físicas en un estado correcto conocido. Puede usar la configuración predeterminada de seguridad para administrar la seguridad del clúster, el control de desfase y la configuración del servidor principal protegido en el clúster.

  • Registros de eventos de seguridad: el reenvío de syslog local de Azure se integra con soluciones de supervisión de seguridad mediante la recuperación de registros de eventos de seguridad pertinentes para agregar y almacenar eventos para la retención en su propia plataforma SIEM.

  • Protección frente a amenazas y vulnerabilidades:Defender for Cloud protege la instancia local de Azure frente a diversas amenazas y vulnerabilidades. Este servicio ayuda a mejorar la posición de seguridad del entorno local de Azure y puede protegerse frente a amenazas existentes y en evolución.

  • Detección y corrección de amenazas:Microsoft Advanced Threat Analytics detecta y corrige amenazas, como las amenazas que tienen como destino AD DS, que proporcionan servicios de autenticación a las máquinas de instancia local de Azure y sus cargas de trabajo de máquina virtual de Windows Server.

  • Aislamiento de red: Aislar redes si es necesario. Por ejemplo, puede aprovisionar varias redes lógicas que usan VLAN independientes y intervalos de direcciones de red. Al usar este enfoque, asegúrese de que la red de administración pueda llegar a cada red lógica y VLAN para que las máquinas físicas de la instancia local de Azure puedan comunicarse con las redes VLAN a través de los conmutadores tor o las puertas de enlace. Esta configuración es necesaria para la administración de la carga de trabajo, como permitir que los agentes de administración de infraestructura se comuniquen con el sistema operativo invitado de carga de trabajo.

    Para obtener más información, consulte recomendaciones de para crear una estrategia de segmentación.

Optimización de costos

La optimización de costos se centra en 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 costos.

  • Modelo de facturación de estilo de nube para licencias: Los precios de Azure Local siguen el modelo de facturación de suscripciones mensuales con una tarifa plana para cada núcleo de procesador físico en una instancia local de Azure. Se aplican cargos de uso adicionales si usa otros servicios de Azure. Si posee licencias básicas locales para Windows Server Datacenter Edition con Software Assurance activo, puede optar por intercambiar estas licencias para activar las cuotas de suscripción de máquina virtual de Azure Local y Windows Server.

  • Aplicaciones automáticas de actualizaciones para máquinas virtuales invitadas en las máquinas virtuales locales de Azure: Esta característica ayuda a reducir la sobrecarga de las actualizaciones manuales y los costos de mantenimiento asociados. Esta acción no solo ayuda a que el sistema sea más seguro, sino que también optimiza la asignación de recursos y contribuye a la eficiencia global de los costos.

  • Consolidación de la supervisión de costos: Para consolidar los costos de supervisión, use Azure Local Insights y aplique parches mediante Update Manager para Azure Local. Azure Local Insights usa Azure Monitor para proporcionar métricas enriquecidas y funcionalidades de alertas. El componente del administrador de ciclo de vida de Azure Local se integra con Update Manager para simplificar la tarea de mantener los clústeres up-to-date consolidando los flujos de trabajo de actualización para varios componentes en una sola experiencia. Use Azure Monitor y Update Manager para optimizar la asignación de recursos y contribuir a la eficiencia global de los costos.

    Para obtener más información, consulte recomendaciones de para optimizar el tiempo del personal.

  • Capacidad inicial de carga de trabajo y crecimiento: Al planear la implementación local de Azure, tenga en cuenta la capacidad inicial de la carga de trabajo, los requisitos de resistencia y las consideraciones de crecimiento futuras. Considere si usar una arquitectura sin conmutador de almacenamiento de dos, tres o cuatro nodos puede reducir los costos, como quitar la necesidad de adquirir conmutadores de red de clase de almacenamiento. La protección de conmutadores de red de clase de almacenamiento adicionales puede ser un componente costoso de las nuevas implementaciones de instancias locales de Azure. En su lugar, puede usar conmutadores existentes para redes de administración y proceso, que simplifican la infraestructura. Si la capacidad de carga de trabajo y las necesidades de resistencia no se escalan más allá de una configuración de cuatro nodos, considere la posibilidad de usar conmutadores existentes para las redes de administración y proceso y use la arquitectura sin conmutador de almacenamiento para implementar Azure Local.

    Para obtener más información, consulte recomendaciones de para optimizar los costos de los componentes.

Tip

Puede reducir los costos mediante la Ventaja Híbrida de Azure si tiene licencias de Windows Server Datacenter que incluyen Software Assurance activo. Para más información, consulte Ventaja híbrida de Azure para Azure Local.

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, vea Lista de comprobación de revisión de diseño para la excelencia operativa.

  • Experiencia simplificada de aprovisionamiento y administración integrada con Azure: La implementación basada en la nube en Azure proporciona una interfaz controlada por el asistente que muestra cómo crear una instancia local de Azure. Del mismo modo, Azure simplifica el proceso de administración de instancias locales de Azure y máquinas virtuales locales de Azure. Puede automatizar la implementación basada en el portal de la instancia local de Azure mediante esta plantilla de ARM. El uso de plantillas proporciona coherencia y automatización para implementar Azure Local a escala, específicamente en escenarios perimetrales, como tiendas minoristas o sitios de fabricación que requieren una instancia local de Azure para ejecutar cargas de trabajo críticas para la empresa.

  • Funcionalidades de automatización para Azure Virtual Machines: Azure Local proporciona una amplia gama de funcionalidades de automatización para administrar cargas de trabajo, como máquinas virtuales locales de Azure. Estas funcionalidades incluyen la implementación automatizada de máquinas virtuales locales de Azure mediante la CLI de Azure, las plantillas de ARM o las plantillas de Bicep. Las actualizaciones del sistema operativo de máquina virtual se entregan a través de la extensión de Azure Arc para actualizaciones y Update Manager, que aplica actualizaciones a cada instancia local de Azure. Azure Local también proporciona compatibilidad con la administración de máquinas virtuales locales de Azure mediante la CLI de Azure y las máquinas virtuales locales que no son de Azure mediante Windows PowerShell. Puede ejecutar los comandos de la CLI de Azure localmente desde una de las máquinas locales de Azure o de forma remota desde un equipo de administración. La integración con Azure Automation y Azure Arc facilita una amplia gama de escenarios de automatización adicionales para cargas de trabajo de máquina virtual a través de extensiones de Azure Arc.

    Para obtener más información, consulte recomendaciones de para usar iaC.

  • Funcionalidades de automatización para contenedores en AKS: Azure Local proporciona una amplia gama de funcionalidades de automatización para administrar cargas de trabajo, como contenedores, en AKS. Puede automatizar la implementación de clústeres de AKS mediante la CLI de Azure. Use la extensión de Azure Arc para las actualizaciones de Kubernetes para actualizar los clústeres de cargas de trabajo de AKS. También puede administrar AKS habilitado para Azure Arc mediante la CLI de Azure. Puede ejecutar los comandos de la CLI de Azure localmente desde una de las máquinas locales de Azure o de forma remota desde un equipo de administración. Integración con Azure Arc para una amplia gama de escenarios de automatización adicionales para cargas de trabajo en contenedores a través de extensiones de Azure Arc.

    Para obtener más información, consulte los siguientes recursos:

Eficiencia del 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, vea Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

  • Rendimiento del almacenamiento de cargas de trabajo: Considere la posibilidad de usar la herramienta DiskSpd para probar las funcionalidades de rendimiento del almacenamiento de cargas de trabajo de una instancia local de Azure. Puede usar la herramienta VMFleet para generar la carga y medir el rendimiento de un subsistema de almacenamiento. Determine si debe usar VMFleet para medir el rendimiento del subsistema de almacenamiento.

    Se recomienda establecer una base de referencia para el rendimiento de las instancias locales de Azure antes de implementar cargas de trabajo de producción. DiskSpd usa varios parámetros de línea de comandos que permiten a los administradores probar el rendimiento de almacenamiento del clúster. La función principal de DiskSpd es emitir operaciones de lectura y escritura y métricas de rendimiento de salida, como latencia, rendimiento e IOPS.

    Para obtener más información, consulte Recomendaciones para pruebas de rendimiento.

  • Resistencia del almacenamiento de cargas de trabajo: Tenga en cuenta las ventajas de la resistencia del almacenamiento, la eficiencia del uso (o la capacidad) y el rendimiento. La planeación de volúmenes locales de Azure incluye la identificación del equilibrio óptimo entre resistencia, eficiencia de uso y rendimiento. Es posible que sea difícil optimizar este equilibrio porque maximizar una de estas características suele tener un efecto negativo en una o varias de las otras características. Aumentar la resistencia reduce la capacidad utilizable. Como resultado, el rendimiento puede variar, en función del tipo de resistencia elegido. Cuando la resistencia y el rendimiento son la prioridad, y cuando se usan tres o más máquinas físicas, la configuración de almacenamiento predeterminada emplea la creación de reflejo triple para los volúmenes de infraestructura y usuario.

    Para obtener más información, consulte recomendaciones de para planear la capacidad.

  • Optimización del rendimiento de red: Considere la optimización del rendimiento de la red. Como parte del diseño, asegúrese de incluir la asignación de ancho de banda de tráfico de red proyectado al determinar la configuración óptima del hardware de red.

    Para optimizar el rendimiento del proceso en Azure Local, puede usar la aceleración de GPU. La aceleración de GPU es beneficiosa para cargas de trabajo de inteligencia artificial o aprendizaje automático de alto rendimiento que implican información o inferencia de datos. Estas cargas de trabajo requieren la implementación en ubicaciones perimetrales debido a consideraciones como la gravedad de los datos o los requisitos de seguridad. En una implementación híbrida o una implementación local, es importante tener en cuenta los requisitos de rendimiento de la carga de trabajo, incluidas las GPU. Este enfoque le ayuda a seleccionar los servicios correctos al diseñar y adquirir las instancias locales de Azure.

    Para obtener más información, consulte Recomendaciones para seleccionar los servicios correctos.

Implementación de este escenario

En la sección siguiente se proporciona una lista de ejemplo de las tareas de alto nivel o el flujo de trabajo típico que se usa para implementar Azure Local, incluidas las tareas y consideraciones de requisitos previos. Esta lista de flujo de trabajo solo está pensada como guía de ejemplo. No es una lista exhaustiva de todas las acciones necesarias, que pueden variar en función de los requisitos organizativos, geográficos o específicos del proyecto.

En este escenario, un proyecto o un caso de uso requiere que implemente una solución de nube híbrida en una ubicación local o perimetral para entregar el proceso local para el procesamiento de datos. También es necesario mantener experiencias de facturación y administración coherentes con Azure. En la sección Casos de uso potenciales de este artículo se describen más detalles. En los pasos restantes se supone que Azure Local es la solución de plataforma de infraestructura elegida para el proyecto.

  1. Recopile los requisitos de carga de trabajo y casos de uso de las partes interesadas pertinentes. Esta estrategia permite al proyecto confirmar que las características y funcionalidades de Azure Local cumplen los requisitos de escala, rendimiento y funcionalidad de la carga de trabajo. Este proceso de revisión debe incluir comprender la escala o el tamaño de la carga de trabajo y las características necesarias, como las máquinas virtuales locales de Azure, AKS, Virtual Desktop o los servicios de datos habilitados para Azure Arc o el servicio Machine Learning habilitado para Azure Arc. Los valores de RTO y RPO de carga de trabajo (confiabilidad) y otros requisitos no funcionales (escalabilidad de rendimiento y carga) deben documentarse como parte de este paso.

  2. Revise la salida del generador de tamaños local de Azure para la solución del socio de hardware recomendada. Esta salida incluye detalles de la marca y modelo recomendados del hardware del servidor físico, el número de máquinas físicas y las especificaciones de la configuración de CPU, memoria y almacenamiento para cada nodo físico para implementar y ejecutar las cargas de trabajo.

  3. Use la herramienta de ajuste de tamaño local de Azure para crear un nuevo proyecto que modele el tipo de carga de trabajo y la escala. Este proyecto incluye el tamaño y el número de máquinas virtuales y sus requisitos de almacenamiento. Estos detalles se introducen junto con opciones para el tipo de sistema, la familia de CPU preferida y los requisitos de resistencia para la alta disponibilidad y la tolerancia a errores de almacenamiento, como se explica en la sección Opciones de diseño del clúster .

  4. Revise la salida de Azure Local Sizer para la solución de asociado de hardware recomendada. Esta solución incluye detalles del hardware de servidor físico recomendado (marca y modelo), el número de máquinas físicas y las especificaciones de la configuración de CPU, memoria y almacenamiento para cada nodo físico para implementar y ejecutar las cargas de trabajo.

  5. Póngase en contacto con el OEM o socio de SI para evaluar más a fondo la idoneidad de la versión de hardware recomendada frente a sus requisitos de carga de trabajo. Si está disponible, use herramientas de ajuste de tamaño específicas de OEM para determinar los requisitos de ajuste de tamaño de hardware específicos del OEM para las cargas de trabajo previstas. Este paso suele incluir discusiones con el oem de hardware o asociado de SI para los aspectos comerciales de la solución. Estos aspectos incluyen presupuestos, disponibilidad del hardware, tiempos de entrega y cualquier servicio profesional o de valor añadido que proporcione el asociado para ayudar a acelerar el proyecto o los resultados empresariales.

  6. Implemente dos conmutadores ToR para la integración de red. En el caso de las soluciones de alta disponibilidad, las instancias locales de Azure requieren el despliegue de dos switches ToR. Cada máquina física requiere cuatro NIC, dos de las cuales deben ser compatibles con RDMA, que proporciona dos vínculos de cada máquina a los dos conmutadores ToR. Dos NIC, una conectada a cada conmutador, se convergen para la conectividad saliente norte-sur para las redes de proceso y administración. Las otras dos NIC compatibles con RDMA están dedicadas al tráfico este-oeste de almacenamiento. Si planea usar conmutadores de red existentes, asegúrese de que la marca y el modelo de los conmutadores se encuentran en la lista aprobada de conmutadores de red admitidos por Azure Local.

  7. Trabaje con el socio de hardware OEM o SI para organizar una entrega del hardware. A continuación, el asociado de SI o los empleados deben integrar el hardware en el centro de datos local o la ubicación perimetral, como el bastidor y apilar el hardware, la red física y el cableado de la unidad de fuente de alimentación para las máquinas físicas.

  8. Realice la implementación de la instancia local de Azure. En función de la versión de la solución elegida (Solución Premier, Sistema integrado o Nodo validado), el asociado de hardware, el asociado de SI o los empleados pueden implementar el software local de Azure. Este paso comienza incorporando el sistema operativo Azure Stack HCI en servidores habilitados para Azure Arc y, a continuación, iniciando el proceso de implementación en la nube local de Azure. Los clientes y asociados pueden generar una solicitud de soporte técnico directamente con Microsoft en Azure Portal seleccionando el icono Soporte técnico y solución de problemas o poniéndose en contacto con su asociado de HARDWARE OEM o SI, en función de la naturaleza de la solicitud y la categoría de solución de hardware.

    Tip

    Logotipo de GitHub La implementación de referencia del sistema operativo Azure Stack HCI, versión 23H2 , muestra cómo implementar una implementación conmutada de varios nodos de Azure Local mediante una plantilla de ARM y un archivo de parámetros. Como alternativa, el ejemplo de Bicep muestra cómo usar una plantilla de Bicep para implementar una instancia local de Azure, incluidos sus recursos de requisitos previos.

  9. Implemente cargas de trabajo de alta disponibilidad en Azure Local mediante Azure Portal, la CLI o las plantillas de ARM + Azure Arc para la automatización. Use el recurso de ubicación personalizada de la nueva instancia local de Azure como región de destino al implementar recursos de carga de trabajo como máquinas virtuales locales de Azure, AKS, hosts de sesión de Virtual Desktop u otros servicios habilitados para Azure Arc que puede habilitar mediante extensiones de AKS y la contenedorización en Azure Local.

  10. Instale actualizaciones mensuales para mejorar la seguridad y confiabilidad de la plataforma. Para mantener actualizadas las instancias locales de Azure, es importante instalar actualizaciones de software de Microsoft y actualizaciones de firmware y controladores oem de hardware. Estas actualizaciones mejoran la seguridad y confiabilidad de la plataforma. Update Manager aplica las actualizaciones y proporciona una solución centralizada y escalable para instalar actualizaciones en un único clúster o en varios clústeres. Consulte con el asociado oem de hardware para determinar el proceso de instalación de actualizaciones de controladores de hardware y firmware, ya que este proceso puede variar en función del tipo de categoría de solución de hardware elegido (Solución Premier, Sistema integrado o Nodo validado). Para obtener más información, consulte Actualizaciones de infraestructura.

Pasos siguientes

Documentación del producto de Microsoft Learn:

Documentación del producto de Azure:

Aprendizaje de Microsoft Learn:

Otros recursos: