Arquitectura de referencia de línea base para Azure Stack HCI

Esta arquitectura de referencia de línea base proporciona instrucciones y recomendaciones independientes de la carga de trabajo para configurar Azure Stack HCI 23H2 y una infraestructura posterior que garantiza una plataforma confiable que pueda implementar y administrar 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 los nodos físicos que proporcionan características locales de proceso, almacenamiento y redes. También se describe cómo usar los servicios de Azure para simplificar y optimizar la administración diaria de Azure Stack HCI.

Para obtener más información sobre los patrones de arquitectura de la carga de trabajo optimizados para ejecutarse en Azure Stack HCI, consulte el contenido ubicado en el menú de navegación Cargas de trabajo de Azure Stack HCI.

Esta arquitectura es un punto de partida para usar el diseño de red conmutada de almacenamiento para implementar un clúster de Azure Stack HCI de varios nodos. Las aplicaciones de carga de trabajo implementadas en un clúster de Azure Stack HCI deben tener una buena arquitectura. Las aplicaciones de carga de trabajo con una buena arquitectura deben implementarse mediante varias instancias o alta disponibilidad de cualquier servicio de carga de trabajo crítico, además de tener los controles adecuados de continuidad empresarial y recuperación ante desastres (BCDR). Estos controles BCDR incluyen copias de seguridad periódicas y funcionalidades de conmutación por error de recuperación ante desastres. Para centrarnos en la plataforma de infraestructura de HCI, estos aspectos de diseño de cargas de trabajo se excluyen intencionadamente de este artículo.

Para obtener más información sobre las directrices y recomendaciones para los cinco pilares del marco de trabajo del Marco de buena arquitectura de Azure, consulte Guía de servicios del Marco de buena arquitectura de Azure Stack HCI.

Diseño del artículo

Arquitectura

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

Posibles casos de uso

Los casos de uso típicos de Azure Stack HCI incluyen la capacidad de ejecutar cargas de trabajo de alta disponibilidad (HA) en ubicaciones locales o perimetrales, lo que proporciona una solución para satisfacer los requisitos de la carga de trabajo. Puede:

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

• Implementar y administrar cargas de trabajo de alta disponibilidad perimetrales virtualizadas o basadas en contenedores que se implementan en una sola ubicación o en varias ubicaciones. Esta estrategia permite que las aplicaciones y los servicios críticos para la empresa funcionen de forma resistente, rentable y escalable.

• Reducir el costo total de propiedad (TCO) mediante soluciones certificadas por Microsoft, implementación basada en la nube, administración centralizada y supervisión y alertas.

• Proporcionar una funcionalidad de aprovisionamiento centralizada mediante Azure y Azure Arc para implementar cargas de trabajo en varias ubicaciones de forma coherente y segura. Las herramientas como Azure Portal, CLI de Azure o plantillas de infraestructura como código (IaC), usan Kubernetes para la contenedorización o la virtualización de cargas de trabajo tradicionales para impulsar la automatización y la repetibilidad.

• Cumplir los estrictos requisitos de seguridad, cumplimiento y auditoría. Azure Stack HCI se implementa con una posición de seguridad protegida configurada de forma predeterminada o segura de forma predeterminada. Azure Stack HCI incorpora hardware certificado, arranque seguro, módulo de plataforma segura (TPM), seguridad basada en virtualización (VBS), Credential Guard y directivas de control de aplicaciones de Windows Defender aplicadas. También se integra con servicios modernos de seguridad y administración de amenazas basados en la nube, como Microsoft Defender for Cloud y Microsoft Sentinel.

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 la carga de trabajo de ejemplo que puede implementar en Azure Stack HCI.

Uso de Azure Arc con Azure Stack HCI

Azure Stack HCI se integra directamente con Azure mediante Azure Arc para reducir el TCO y la sobrecarga operativa. Azure Stack HCI se implementa y administra a través de Azure, que proporciona integración incorporada de Azure Arc mediante la implementación del componente de puente de recursos de Azure Arc. Este componente se instala durante el proceso de implementación del clúster de HCI. Los nodos de clúster de Azure Stack HCI se inscriben con Azure Arc para servidores como requisito previo para iniciar la implementación basada en la nube del clúster. Durante la implementación, las extensiones obligatorias se instalan en cada nodo de clúster, como Lifecycle Manager, Administración de dispositivos de Microsoft Edge y Telemetría y diagnóstico. Puede usar Azure Monitor y Log Analytics para supervisar el clúster de HCI después de la implementación habilitando Azure Stack HCI Insights. Las actualizaciones de características para Azure Stack HCI se publican periódicamente para mejorar la experiencia del cliente. Las actualizaciones se controlan y administran mediante el Azure Update Manager.

Puede implementar recursos de la carga de trabajo como máquinas virtuales (VM) de Azure Arc, Azure Kubernetes Service (AKS) habilitado para Azure Arc y hosts de sesión de Azure Virtual Desktop que usan Azure Portal seleccionando una ubicación personalizada del clúster de Azure Stack HCI como destino para la implementación de cargas de trabajo. Estos componentes proporcionan administración, gestió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 Ventaja híbrida de Azure a Azure Stack HCI, máquinas virtuales de Windows Server y 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 Stack HCI para incluir:

• Máquinas virtuales de Azure Arc para aplicaciones o servicios tradicionales que se ejecutan en máquinas virtuales en Azure Stack HCI.

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

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

• Servicios de datos habilitados para Azure Arc para un servidor de Azure SQL Managed Instance o de Azure Database for PostgreSQL en contenedores que use AKS habilitado en Azure Arc hospedados en Azure Stack HCI.

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

• Machine Learning habilitado para Azure Arc con un clúster de AKS implementado en Azure Stack HCI 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 implementaciones de Azure Stack HCI, como automatizar la configuración del SO invitado con extensiones de máquina virtual de Azure Arc o evaluar el cumplimiento de las normativas del sector o los estándares corporativos mediante Azure Policy. Puede activar Azure Policy a través de Azure Portal o automatización de IaC.

Aproveche la configuración de seguridad predeterminada de Azure Stack HCI.

La configuración de seguridad predeterminada de Azure Stack HCI 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 contra amenazas internas y externas es crucial en entornos que tienen un soporte técnico de TI limitado o carecen de centros de datos dedicados. Azure Stack HCI cuenta con un refuerzo de seguridad predeterminado y una profunda integración con los servicios de Azure para que pueda afrontar estos desafíos.

El hardware certificado de Azure Stack HCI garantiza un arranque seguro, firmware UEFI (Unified Extensible Firmware Interface) y compatibilidad con TPM. Use estas tecnologías en combinación con la seguridad VBS para proteger las cargas de trabajo sensibles a la seguridad. Puede usar el cifrado de unidad BitLocker para cifrar los volúmenes del disco de arranque y los volúmenes directos de espacios de almacenamiento en reposo. El cifrado de bloque de mensajes de servidor (SMB) proporciona cifrado automático del tráfico entre servidores del clúster (en la red de almacenamiento) y la firma del tráfico SMB entre los nodos del clúster y otros sistemas. El cifrado SMB también sirve de ayuda para evitar ataques de transmisión y facilita el cumplimiento de los estándares normativos.

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

Componentes

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

Recursos de la plataforma

La arquitectura requiere los siguientes recursos y componentes obligatorios:

• Azure Stack HCI es una solución de infraestructura hiperconvergente (HCI) que se implementa localmente o en ubicaciones perimetrales mediante el hardware físico del servidor y la infraestructura de red. Azure Stack HCI proporciona una plataforma para implementar y administrar cargas de trabajo virtualizadas, como máquinas virtuales, clústeres de Kubernetes y otros servicios habilitados por Azure Arc. Los clústeres de Azure Stack HCI se pueden escalar desde una implementación de un solo nodo a un máximo de dieciséis nodos mediante categorías de hardware validadas, integradas o premium proporcionadas por los partners de fabricantes de equipos originales (OEM).

• Azure Arc es un servicio basado en la nube que amplía el modelo de administración basado en Azure Resource Manager a Azure Stack HCI y otras ubicaciones que no son de Azure. Azure Arc usa Azure como plano de control y administración para habilitar la gestión de varios recursos, como máquinas virtuales, clústeres de Kubernetes y datos en contenedores, así como servicios de aprendizaje automático.

• Azure Key Vault es un servicio en la nube que puede usar para almacenar y acceder de forma segura a los secretos. Un secreto es cualquier elemento al que se desee restringir estrictamente el acceso, como claves de API, contraseñas, certificados, claves criptográficas, credenciales de administrador local y claves de recuperación de BitLocker.

• Testigo en la nube es una característica de Azure Storage que actúa como cuórum de clúster de conmutación por error. Los nodos de clúster de Azure Stack HCI usan este cuórum para votar, lo que garantiza una alta disponibilidad para el clúster. La cuenta de almacenamiento y la configuración del testigo se crean durante el proceso de implementación en la nube de Azure Stack HCI.

• Update Manager es un servicio unificado diseñado para administrar y controlar las actualizaciones de Azure Stack HCI. Puede usar Update Manager para administrar las cargas de trabajo que se implementan en Azure Stack HCI, incluido el cumplimiento de actualizaciones del sistema operativo invitado para máquinas virtuales Windows y Linux. Este enfoque unificado simplifica la administración de revisiones en Azure, entornos locales y otras plataformas en la nube a través de un único panel.

Recursos compatibles con la plataforma

La arquitectura incluye los siguientes servicios auxiliares opcionales para mejorar las funcionalidades de la plataforma:

• Monitor es un servicio basado en la nube para recopilar, analizar y actuar sobre los registros de diagnóstico y la telemetría de las cargas de trabajo locales y en la nube. Puede usar Monitor para maximizar la disponibilidad y el rendimiento de las aplicaciones y los servicios mediante una solución de supervisión completa. Implemente Azure Stack HCI Insights para simplificar la creación de la regla de recopilación de datos (DCR) de Monitor y habilitar rápidamente la supervisión de clústeres de Azure Stack HCI.

• 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 con las propiedades de esos recursos para las reglas de negocio, denominadas definiciones de directivas, para determinar el cumplimiento o las funcionalidades que puede usar para aplicar la configuración de invitado de máquina virtual mediante la configuración de directiva.

• Defender for Cloud es una aplicación de administración de seguridad de infraestructura completa. Mejora la posición de seguridad de los centros de datos y ofrece protección avanzada contra amenazas para cargas de trabajo híbridas, tanto si residen en Azure como en otros lugares y en entornos locales.

• Azure Backup es un servicio basado en la nube que proporciona una solución sencilla, segura y rentable para hacer una copia 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 Stack HCI y almacenarlas en el servicio Backup.

• Site Recovery es un servicio de recuperación ante desastres que proporciona funcionalidades de BCDR al permitir que las aplicaciones empresariales y las cargas de trabajo conmuten por error 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 y máquinas virtuales físicos entre su sitio principal (local) y una ubicación secundaria (Azure).

Opciones de diseño del clúster

Es importante comprender los requisitos de rendimiento y resistencia de la carga de trabajo al diseñar un clúster de Azure Stack HCI. Estos requisitos incluyen los objetivos de tiempo de recuperación (RTO) y los tiempos de los objetivos de punto de recuperación (RPO), los requisitos de proceso (CPU), memoria y almacenamiento para todas las cargas de trabajo que se implementan en el clúster de Azure Stack HCI. Varias características de la carga de trabajo afectan al proceso de toma de decisiones e incluyen:

• Funcionalidades de arquitectura de la unidad de procesamiento central (CPU), incluidas las características de la tecnología de seguridad de hardware, el número de la CPU, la frecuencia de GHz (velocidad) y el número de núcleos por socket de la 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 por nodo o la cantidad de memoria física necesaria para ejecutar la carga de trabajo.

• Número de nodos físicos del clúster, de 1 a 16 nodos a escala. El número máximo de nodos es tres cuando se usa la arquitectura de red sin conmutador de almacenamiento.

  • Para mantener la resistencia de proceso, debe reservar al menos N+1 nodos de capacidad en el clúster. 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 de misión crítica o críticas para la empresa, considere la posibilidad de reservar N+2 nodos de capacidad para aumentar la resistencia. Por ejemplo, si dos nodos del clúster están sin conexión, la carga de trabajo puede permanecer en línea. Este enfoque proporciona resistencia para escenarios en los que un nodo que ejecuta una carga de trabajo se desconecta durante un procedimiento de actualización planeado y da como resultado que dos nodos estén sin conexión simultáneamente.

• Requisitos de resistencia, capacidad y rendimiento de almacenamiento:

  • Resistencia: se recomienda implementar tres o más nodos para habilitar la creación de reflejo 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 copias. Este número es aproximadamente el 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 determinan las capacidades de rendimiento de almacenamiento para la carga de trabajo cuando se multiplican por el tamaño de bloque de la aplicación.

Para diseñar y planificar una implementación de Azure Stack HCI, se recomienda usar la herramienta de dimensionamiento de Azure Stack HCI y crear un nuevo proyecto para dimensionar los clústeres de HCI. El uso de la herramienta de dimensionamiento requiere conocer los requisitos de la carga de trabajo. Al considerar el número y el tamaño de las máquinas virtuales de carga de trabajo que se ejecutan en el clúster, 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 dimensionamiento, le guía a través de preguntas relacionadas con el tipo de sistema (solución Premier, Sistema integrado o Nodos validados) y las opciones de familia de la CPU. También le ayuda a seleccionar los requisitos de resistencia del clúster. Asegúrese de que:

• Reserva un mínimo de N+1 nodos de capacidad, o un nodo, en el clúster.

• Reserva N+2 nodos de capacidad en todo el clúster para aumentar la resistencia. Esta opción permite al sistema resistir un error de nodo durante una actualización u otro evento inesperado que afecte simultáneamente a dos nodos. También garantiza que haya suficiente capacidad en el clúster para que la carga de trabajo se ejecute en los nodos 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 los clústeres que tienen tres o más nodos físicos.

La salida de la herramienta de dimensionamiento de Azure Stack HCI es una lista de las SKU de solución de hardware recomendadas que pueden proporcionar los requisitos de resistencia de la plataforma y la capacidad de carga de trabajo necesarios en función de los valores de entrada del proyecto de Sizer. Para obtener más información sobre las soluciones de partners de hardware OEM disponibles, consulte Catálogo de soluciones de Azure Stack HCI. Para ayudarle a adaptar las SKU de solución para satisfacer sus requisitos, póngase en contacto con el proveedor de soluciones de hardware o el partner de integración de sistemas (SI).

Unidades de disco físicas

Los espacios de almacenamiento directo admiten varios tipos de unidad de disco físico que varían en cuanto a rendimiento y capacidad. Al diseñar un clúster de Azure Stack HCI, trabaje con el partner 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 NVMe. Estas unidades a menudo se denominan 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 discos adecuados a sus necesidades. Use soluciones de almacenamiento all-flash, como unidades NVMe o SSD, para cargas de trabajo con 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 cualquier carga de trabajo de misión crítica o crítica para la empresa que tenga requisitos de almacenamiento de baja latencia o alto rendimiento. Utilice implementaciones all-flash para maximizar el rendimiento del almacenamiento. Todas las configuraciones de unidades NVMe o SSD, especialmente a pequeña escala, mejoran la eficiencia del almacenamiento y maximizan el rendimiento porque no se usan unidades como un nivel de caché; para obtener más información, consulte Almacenamiento basado en all-flash.

Para cargas de trabajo de uso general, una configuración de almacenamiento híbrido, como unidades NVMe o SSD para caché y HDD para capacidad, podría proporcionar más espacio de almacenamiento. La desventaja es que los discos giratorios tienen un rendimiento menor si la carga de trabajo supera el conjunto de trabajo de la caché y los HDD tienen un tiempo medio entre errores menor en comparación con las unidades NVMe y SSD.

El rendimiento del almacenamiento en clúster se ve afectado por el tipo de unidad de disco físico, que 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. En función de los requisitos de las cargas de trabajo y las restricciones de presupuesto de Azure Stack HCI, puede optar por maximizar el rendimiento, maximizar la capacidad o implementar una configuración de tipo de unidad mixta que equilibre el rendimiento y la capacidad.

Los Espacios de almacenamiento directo proporciona una caché de servidor, de lectura y escritura, en tiempo real, persistente e integrada, que maximiza el rendimiento del almacenamiento. La memoria caché debe tener el tamaño y la configuración para acomodar el espacio de trabajo de las aplicaciones y las cargas de trabajo. Los discos virtuales de Espacios de almacenamiento directo, o volúmenes, se usan en combinación con la memoria caché de lectura de volumen compartido de clúster (CSV) para mejorar el rendimiento de Hyper-V, especialmente para el acceso de entrada sin búfer a los archivos de disco duro virtual (VHD) o de disco duro virtual v2 (VHDX) de la carga de trabajo.

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. Usar los mismos puertos NIC para todos los propósitos relacionados con la intención se denomina una configuración de red totalmente convergente.

Aunque se admite una configuración de red totalmente convergente, la configuración óptima para el rendimiento y la confiabilidad es que la intención de almacenamiento use puertos de adaptador de red dedicados. Por lo tanto, esta arquitectura de línea base proporciona instrucciones de ejemplo sobre cómo implementar un clúster de Azure Stack HCI de varios nodos mediante la arquitectura de red conmutada de almacenamiento con dos puertos de adaptador de red convergentes para las intenciones de administración y proceso y dos puertos de adaptador de red dedicados para la intención de almacenamiento. Para obtener más información, consulte Consideraciones de red para implementaciones en la nube de Azure Stack HCI.

Esta arquitectura requiere dos o más nodos físicos y hasta un máximo de 16 nodos a escala. Cada nodo 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 grupo de agregación de vínculos 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 el acceso directo a memoria remota (RDMA). Estos puertos requieren una velocidad de vínculo mínima de 10 Gbps, pero se recomienda una velocidad de 25 Gbps o superior. Los dos puertos de adaptador de red que se usan para las intenciones de administración y procesamiento convergen mediante la tecnología de formación de equipos insertada (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 físicas reales entre los nodos y los componentes de red.

Necesita los siguientes componentes cuando diseñe una implementación de Azure Stack HCI conmutada de almacenamiento de varios nodos que use esta arquitectura de línea base:

• Conmutadores ToR dobles:

  • Los conmutadores de red ToR dobles son necesarios para la resistencia de red y la capacidad de atender o aplicar actualizaciones de firmware a los conmutadores sin generar tiempos de inactividad. Esta estrategia impide un único punto de error (SPoF).

  • Los conmutadores ToR dobles 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 los nodos a través de cables Ethernet.

• Dos o más nodos físicos y hasta un máximo de 16 nodos a escala:

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

  • Cada nodo 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.

  • El almacenamiento 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 vínculo y ancho de banda prioritario dedicado para el tráfico de almacenamiento de SMB directo.

  • 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 dobles se conectan a la red externa, como la LAN corporativa interna, para proporcionar acceso a las direcciones URL de salida necesarias mediante el dispositivo de red de borde perimetral. Este dispositivo puede ser un firewall o enrutador. Estos conmutadores enrutan el tráfico que entra y sale del clúster de Azure Stack HCI 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. Esto se logra mediante dos puertos de conmutador y dos puertos de adaptador de red por nodo que convergen a través de la formación de equipos insertada (SET) y un conmutador virtual dentro de Hyper-V para garantizar la resistencia. Estos componentes funcionan para proporcionar conectividad externa para máquinas virtuales de Azure Arc y otros recursos de carga de trabajo implementados en las redes lógicas que se crean en Resource Manager mediante Azure Portal, la CLI 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.

Un resumen de la configuración lógica de esta arquitectura de línea base conmutada de almacenamiento de varios nodos para Azure Stack HCI es el siguiente:

• Conmutadores ToR dobles:

  • Antes de implementar el clúster, los dos conmutadores de red ToR deben configurarse con los ID 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 Stack HCI o solicite ayuda al proveedor de hardware del conmutador o al partner de SI.

• Azure Stack HCI usa el enfoque de ATC de red 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 las intenciones de administración, proceso de carga de trabajo y 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 del nodo en función de las entradas de parámetro que se especifican como parte del proceso de implementación en la nube de Azure Stack HCI.

• Comunicación externa:

  • Cuando los nodos o la carga de trabajo necesitan comunicarse externamente mediante el acceso a la LAN corporativa, Internet u otro servicio, se enrutan mediante los conmutadores ToR dobles. Este proceso se describe en la sección anterior Topología de red física.

  • Cuando los dos conmutadores ToR actúan 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:

  • Los nodos físicos 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 ID de VLAN específico configurado que debe coincidir con la configuración de los puertos de conmutador en los identificadores de VLAN de almacenamiento predeterminados: 711 y 712 de los conmutadores ToR.

  • 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 del nodo de Azure Stack HCI.

  • Cada nodo puede acceder a las funcionalidades de Espacios de almacenamiento directo del clúster, como discos físicos remotos que se usan en el grupo de almacenamiento, los discos virtuales y los volúmenes. El acceso a estas funcionalidades se facilita a través del protocolo RDMA SMB-Direct a través de los dos puertos de adaptador de red de almacenamiento dedicados que están disponibles en cada nodo. Se usa SMB multicanal 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 Stack HCI y que establece la Asociación de Estándares del Instituto de Ingenieros Eléctricos y Electrónicos (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 Link Layer Discovery Protoco (LLDP).

Si tiene pensado usar conmutadores de red existentes para una implementación de Azure Stack HCI, revise la lista de estándares y especificaciones de IEEE obligatorios que deben proporcionar los conmutadores de red y la configuración. Al comprar nuevos conmutadores de red, póngase en contacto con el proveedor del conmutador para asegurarse de que los dispositivos cumplen los requisitos de especificación IEEE de Azure Stack HCI o revise la lista de modelos de conmutador certificados por el proveedor de hardware que admiten los requisitos de red de Azure Stack HCI..

Requisitos de las 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 nodo físico, hasta un máximo de 16 nodos dentro de un único clúster. Por ejemplo, para implementar una configuración conmutada de almacenamiento de dos nodos de Azure Stack HCI, la infraestructura del clúster requiere la asignación de un mínimo de 11 direcciones IP. Se requieren más direcciones IP si usa microsegmentación o redes definidas por software. Para obtener más información, consulte Revisión de los requisitos de IP del patrón de referencia de almacenamiento de dos nodos para Azure Stack HCI.

Al diseñar y planificar los requisitos de direcciones IP para Azure Stack HCI, 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 infraestructura y clúster de Azure Stack HCI. Si tiene previsto implementar AKS en Azure Stack HCI, consulte Requisitos de red de Azure Arc habilitados para AKS..

Supervisión

Para mejorar la supervisión y las alertas, habilite Monitor Insights en Azure Stack HCI. Insights se puede escalar para supervisar y administrar varios clústeres locales mediante una experiencia consistente con Azure. Insights usa contadores de rendimiento del clúster y canales de registro de eventos para supervisar las características clave de Azure Stack HCI. El DCR recopila los registros que se configuran a través de Monitor y Log Analytics.

La característica Insights de Azure Stack HCI se crea mediante Monitor y Log Analytics, lo que garantiza una solución escalable y siempre actualizada 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 Stack HCI. 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.

Administración de actualizaciones

Los clústeres de Azure Stack HCI y los recursos de la carga de trabajo implementados, como las máquinas virtuales de Azure Arc, 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 y mejora la confiabilidad general y la compatibilidad de sus recursos. Le recomendamos que utilice evaluaciones manuales automáticas y periódicas para la detección temprana y la aplicación de parches de seguridad y actualizaciones del sistema operativo.

Actualizaciones de infraestructura

Azure Stack HCI se actualiza continuamente para mejorar la experiencia del cliente y agregar nuevas características y funcionalidades. Este proceso se administra a través de series, que proporcionan nuevas compilaciones de línea base trimestrales. Las compilaciones de línea base se aplican a los clústeres de Azure Stack HCI para mantenerlos actualizados. Además de las actualizaciones de compilación de línea base normales, Azure Stack HCI se actualiza con las actualizaciones mensuales de seguridad y confiabilidad del sistema operativo.

Update Manager es un servicio de Azure que puede usar para aplicar, ver y administrar actualizaciones de Azure Stack HCI. Este servicio proporciona un mecanismo para ver todos los clústeres de Azure Stack HCI en toda la infraestructura y las ubicaciones perimetrales mediante Azure Portal para proporcionar una experiencia de administración centralizada. Para obtener más información, consulte los siguientes recursos:

• Acerca de la información de la versión de Azure Stack HCI

• Cadencia del ciclo de vida de Azure Stack HCI

• Revisión de las fases de actualización de Azure Stack HCI

• Uso de Azure Update Manager para actualizar Azure Stack HCI

Es importante comprobar si hay nuevas actualizaciones de controladores y firmware con regularidad, por ejemplo, cada tres o seis meses. Si usa una versión de categoría de solución Premier para el hardware de Azure Stack HCI, las actualizaciones de la extensión del Generador de soluciones 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 partner de SI.

Aplicación de revisiones del SO invitado de la carga de trabajo

Puede inscribir máquinas virtuales de Azure Arc que se implementan en Azure Stack HCI mediante el Azure Update Manager (AUM) para proporcionar una experiencia unificada de administración de revisiones mediante el mismo mecanismo que se usa para actualizar los nodos físicos del clúster de Azure Stack HCI. Puede usar AUM para crear configuraciones de mantenimiento de invitado. Estas configuraciones controlan opciones de configuración, como el 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 de Azure Arc para el ámbito. Estos ajustes controlan la configuración cuando se instalan parches de seguridad del sistema operativo dentro del sistema operativo invitado de la máquina virtual de la carga de trabajo.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.

Identificar los posibles puntos de error

Cada arquitectura es susceptible a errores. El análisis del modo de error le permite anticiparse a los fallos y estar preparado para mitigarlos. En la tabla siguiente se describen cuatro ejemplos de posibles puntos de error en esta arquitectura:

Para más información, consulte Recomendaciones para realizar el análisis del modo de error.

Objetivos de confiabilidad

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

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

  • 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 clústeres de Azure Stack HCI a un pequeño grupo de usuarios de confianza y calificados. Este enfoque evita el tiempo de inactividad debido a las acciones involuntarias o accidentales realizadas en los recursos de producción. Es más, los registros de eventos de seguridad para los controladores de dominio local de Active Directory Domain Services (AD DS) 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 clústeres de Azure Stack HCI mediante una solución de administración de eventos de información de seguridad (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.

• Los 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, así como criterios claros de éxito para que se revise o apruebe un cambio.

  Para obtener más información, consulte Recomendaciones para prácticas de implementación seguras.

• Las revisiones de seguridad mensuales y las actualizaciones de línea base trimestrales se aplican a los clústeres de Azure Stack HCI de producción solo después de que el entorno de preproducción las haya validado. Update Manager y la característica de actualización compatible con clúster automatizan el proceso de uso de la migración en vivo de la máquina virtual 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 de línea base 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 días de copias de seguridad diarias (de lunes a sábado), las últimas 3 copias de seguridad semanales (cada domingo) y 3 copias de seguridad mensuales, conservando cada domingo la semana 4 para convertirse en las copias de seguridad del mes 1, mes 2 y mes 3 mediante el uso de un programa basado en un calendario móvil documentado y auditable. Este enfoque cumple los requisitos de Contoso Manufacturing para lograr un equilibrio adecuado entre la cantidad de puntos de recuperación de datos disponibles y la reducción de 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 sean válidos y que la empresa esté protegida si ocurre 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 y procedimientos operativos descritos anteriormente en el artículo y las recomendaciones de la Guía de servicios del Marco de buena arquitectura de Azure Stack HCI, permiten a Contoso Manufacturing cumplir su objetivo de SLO del 99,8 % y escalar y administrar de forma eficaz las implementaciones de las cargas de trabajo y de Azure Stack HCI en varios sitios de fabricación distribuidos en todo el mundo.

  Para obtener más información, consulte Recomendaciones para definir objetivos de confiabilidad.

Redundancia

Considere la posibilidad de implementar una carga de trabajo en un único clúster de Azure Stack HCI como una implementación con redundancia local. El clúster proporciona alta disponibilidad en el nivel de plataforma, pero debe implementar el clúster en un único bastidor. Para casos de uso críticos para la empresa o la misión, se recomienda implementar varias instancias de una carga de trabajo o servicio en dos o más clústeres de Azure Stack HCI independientes, idealmente en ubicaciones físicas separadas.

Use patrones de alta disponibilidad estándar del sector para cargas de trabajo que proporcionan replicación activa y pasiva, replicación sincrónica o replicación asincrónica, como SQL Server Always On. También puede usar una tecnología de equilibrio de carga de red externa (NLB) que enruta las solicitudes de usuario a través de varias instancias de la carga de trabajo que se ejecutan en clústeres de Azure Stack HCI 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 use Azure ExpressRoute o un túnel VPN para conectarse a un servicio local.

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

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

Las consideraciones de seguridad incluyen:

• Una base segura para la plataforma Azure Stack HCI:: Azure Stack HCI 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 plataforma Azure Stack HCI y la seguridad de la carga de trabajo. Cuando se implementa con la configuración de seguridad predeterminada, Azure Stack HCI tiene habilitado el control de aplicaciones de Windows Defender, Credential Guard y BitLocker. Para simplificar la delegación de permisos mediante PoLP, use los roles integrados de control de acceso basado en roles (RBAC) de Azure Stack HCI, como el administrador de Azure Stack HCI para administradores de plataformas y colaborador de máquina virtual de Azure Stack HCI o el lector de máquinas virtuales de Azure Stack HCI para operadores de la carga de trabajo.

• Configuración de seguridad predeterminada: el valor predeterminado de seguridad de Azure Stack HCI aplica la configuración de seguridad predeterminada para el clúster de Azure Stack HCI durante la implementación y habilita el control de desfase para mantener los nodos 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 para Azure Stack HCI se integra con soluciones de supervisión de seguridad mediante la recuperación de los 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 los clústeres de Azure Stack HCI frente a diversas amenazas y vulnerabilidades. Este servicio mejora la posición de seguridad del entorno de Azure Stack HCI y protege 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 que tienen como destino AD DS, que proporcionan servicios de autenticación a los nodos del clúster de Azure Stack HCI y a sus cargas de trabajo de máquina virtual de Windows Server.

• Aislamiento de red: aísla las redes si es necesario. Por ejemplo, puede aprovisionar varias redes lógicas que usan VLAN independientes e 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 los nodos del clúster de Azure Stack HCI 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 la carga de trabajo.

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

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

Las consideraciones de optimización de costos incluyen:

• Modelo de facturación de licencias en la nube: los precios de Azure Stack HCl siguen el modelo de facturación de suscripción mensual con una tarifa plana por núcleo de procesador físico en un clúster de Azure Stack HCl. Se aplican cargos adicionales si utiliza otros servicios de Azure. Si posee licencias básicas locales para la edición Windows Server Datacenter Edition con Software Assurance activo, puede optar por intercambiar estas licencias para activar las tarifas de suscripción del clúster de Azure Stack HCI y de la máquina virtual de Windows Server.

• Aplicación automática de revisiones de invitado de máquina virtual para máquinas virtuales de Azure Arc: esta característica reduce la sobrecarga de la aplicación manual de revisiones 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 Stack HCI Insights y la revisión mediante Update Manager para Azure Stack HCI. Insights usa Monitor para proporcionar métricas enriquecidas y funcionalidades de alertas. El componente del administrador del ciclo de vida de Azure Stack HCI se integra con Update Manager para simplificar la tarea de mantener actualizados los clústeres mediante la consolidación de flujos de trabajo de actualización para varios componentes en una sola experiencia. Use 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 para optimizar el tiempo del personal.

• Capacidad inicial de carga de trabajo y crecimiento: al planificar la implementación de Azure Stack HCI, tenga en cuenta la capacidad inicial de la carga de trabajo, los requisitos de resistencia y las consideraciones de crecimiento futuro. Considere si el uso de una arquitectura sin conmutador de almacenamiento de dos o tres nodos podría reducir los costos, como eliminar 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 clústeres de Azure Stack HCI. En su lugar, puede usar los conmutadores existentes para redes de administración y proceso, lo que simplifica la infraestructura. Si las necesidades de capacidad de la carga de trabajo y resistencia no se escalan más allá de una configuración de tres nodos, considere usar conmutadores existentes para las redes de administración y proceso y utilice la arquitectura sin conmutadores de almacenamiento de tres nodos para implementar Azure Stack HCI.

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

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.

Las consideraciones sobre la excelencia operativa incluyen:

• Experiencia simplificada de aprovisionamiento y administración integrada con Azure: la implementación basada en la nube en Azure proporciona una interfaz controlada por asistentes que muestra cómo crear un clúster de Azure Stack HCI. Del mismo modo, Azure simplifica el proceso de administración de clústeres de Azure Stack HCI y máquinas virtuales de Azure Arc. Puede automatizar la implementación basada en el portal del clúster de Azure Stack HCI mediante la plantilla de ARM. Esta plantilla proporciona coherencia y automatización para implementar Azure Stack HCI a escala, específicamente en escenarios perimetrales, como tiendas minoristas o sitios de fabricación que requieren un clúster de Azure Stack HCI para ejecutar cargas de trabajo críticas para el negocio.

• Funcionalidades de automatización para máquinas virtuales: Azure Stack HCI proporciona una amplia gama de funcionalidades de automatización para administrar las cargas de trabajo, como máquinas virtuales de Azure Arc, con la implementación automatizada de máquinas virtuales de Azure Arc mediante la CLI de Azure, ARM o la plantilla de Bicep, con actualizaciones del sistema operativo de máquina virtual mediante la extensión de Azure Arc para actualizaciones y el Azure Update Manager para actualizar cada clúster de Azure Stack HCI. Azure Stack HCI también proporciona compatibilidad con la administración de máquinas virtuales de Azure Arc mediante la CLI de Azure y las máquinas virtuales que no son de Azure Arc, mediante Windows PowerShell. Puede ejecutar localmente los comandos de la CLI de Azure desde uno de los servidores de Azure Stack HCI 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 las cargas de trabajo de máquina virtual a través de extensiones de Azure Arc.

  Para obtener más información, consulte Recomendaciones para usar IaC.

• Funcionalidades de automatización para contenedores en AKS: Azure Stack HCI 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. Actualice los clústeres de cargas de trabajo de AKS mediante la extensión de Azure Arc para las actualizaciones de Kubernetes. También puede administrar Azure Arc-enabled AKS mediante la CLI de Azure. Puede ejecutar localmente los comandos de la CLI de Azure desde uno de los servidores de Azure Stack HCI o de forma remota desde un equipo de administración. Realice la integración con Azure Arc para obtener 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 Recomendaciones para habilitar la automatización.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.

Las consideraciones de eficiencia del rendimiento incluyen:

• 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 un clúster de Azure Stack HCI. Puede usar la herramienta VMFleet para generar la carga y medir el rendimiento de un subsistema de almacenamiento. Evalúe si debe usar VMFleet para medir el rendimiento del subsistema de almacenamiento.

  • Se recomienda establecer una línea base para el rendimiento de los clústeres de Azure Stack HCI 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 las pruebas de rendimiento.

• Resistencia del almacenamiento de cargas de trabajo: tenga en cuenta las ventajas de la resistencia del almacenamiento, la eficacia del uso (o la capacidad) y el rendimiento. La planificación de los volúmenes de Azure Stack HCI incluye la identificación del equilibrio óptimo entre resistencia, eficacia del uso y rendimiento. Puede resultarle difícil optimizar este equilibrio porque maximizar una de estas características suele tener un efecto negativo en una o más 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 seleccionado. Cuando la resistencia y el rendimiento son la prioridad y, cuando se usan tres o más nodos, la configuración de almacenamiento predeterminada emplea el reflejo triple para los volúmenes de infraestructura y de usuario.

  Para obtener más información, consulte Recomendaciones para la planificación de la capacidad..

• Optimización del rendimiento de red: considere la posibilidad de optimizar el rendimiento de la red. Como parte de su diseño, asegúrese de incluir la asignación de ancho de banda de tráfico de red proyectada al determinar la configuración óptima de hardware de red.

  • Para optimizar el rendimiento del proceso en Azure Stack HCI, puede usar la aceleración de GPU. La aceleración de GPU es beneficiosa para las cargas de trabajo de IA o aprendizaje automático de alto rendimiento que implican información de datos o inferencia. Estas cargas de trabajo requieren implementación en ubicaciones perimetrales debido a consideraciones como la fuerza de atracción de datos o los requisitos de seguridad. En una implementación híbrida o local, es importante tener en cuenta los requisitos de rendimiento de la carga de trabajo, incluidas las GPU. Mediante este enfoque podrá seleccionar los servicios adecuados al diseñar y adquirir los clústeres de Azure Stack HCI.

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

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 Stack HCI, incluidas las tareas y consideraciones de requisitos previos. Esta lista de flujo de trabajo pretende ser únicamente una 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.

Escenario: existe un requisito de proyecto o caso de uso para implementar una solución de nube híbrida en una ubicación local o perimetral para proporcionar un proceso local para las funcionalidades de procesamiento de datos y un deseo de usar experiencias de facturación y administración coherentes con Azure. En la sección posibles casos de uso de este artículo se describen más detalles. En los pasos restantes se supone que Azure Stack HCI es la solución de plataforma de infraestructura elegida para el proyecto.

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

2. Revise la salida del dimensionamiento de Azure Stack HCI para la solución de partner de hardware recomendada. Esta salida incluye detalles sobre la marca y el modelo de hardware del servidor físico recomendado, el número de nodos físicos y las especificaciones de configuración de la CPU, memoria y almacenamiento de cada nodo físico necesarias para implementar y ejecutar las cargas de trabajo.

3. Use la herramienta de dimensionamiento de Azure Stack HCI 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 las opciones para el tipo de sistema, la familia de CPU preferida y los requisitos de resistencia para una alta disponibilidad y la tolerancia a errores de almacenamiento, como se explica en la sección Opciones de diseño de clúster anterior.

4. Revise la solución del dimensionamiento de Azure Stack HCI para la solución de partner de hardware recomendada. Esta solución incluye detalles del hardware del servidor físico recomendado (marca y modelo), el número de nodos físicos y las especificaciones de configuración de la CPU, memoria y almacenamiento de cada nodo físico necesarias para implementar y ejecutar las cargas de trabajo.

5. Póngase en contacto con el partner de hardware de OEM o SI para calificar aún más la idoneidad de la versión de hardware recomendada frente a los requisitos de la carga de trabajo. Si está disponible, use herramientas de dimensionamiento específicas de OEM para determinar los requisitos de dimensionamiento de hardware específicos de OEM para las cargas de trabajo previstas. Este paso suele incluir discusiones con el OEM de hardware o partner 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 partner para ayudar a acelerar el proyecto o los resultados empresariales.

6. Implemente dos conmutadores ToR para la integración de red. Para las soluciones de alta disponibilidad, los clústeres de HCI requieren que se implementen dos conmutadores ToR. Cada nodo físico requiere cuatro NIC, dos de las cuales deben ser compatibles con RDMA, que proporciona dos vínculos de cada nodo a los dos conmutadores ToR. Dos NIC, una conectada a cada conmutador, 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 tiene previsto usar conmutadores de red existentes, asegúrese de que la marca y el modelo de los conmutadores están en la lista aprobada de conmutadores de red compatibles con Azure Stack HCI.

7. Trabaje con el partner de hardware de OEM o SI para organizar la entrega del hardware. Luego, el partner de SI o sus empleados deben integrar el hardware en su centro de datos local o ubicación perimetral, como colocar en bastidores y apilar el hardware, la red física y el cableado de la unidad de fuente de alimentación para los nodos físicos.

8. Realice la implementación del clúster de Azure Stack HCI. En función de la versión de la solución elegida (solución Premier, Sistema integrado o Nodos validados), el partner de hardware, el partner de SI o sus empleados pueden implementar el software de Azure Stack HCI. Este paso comienza incorporando los nodos físicos del sistema operativo Azure Stack HCI en servidores habilitados para Azure Arc y, a continuación, iniciando el proceso de implementación en la nube de Azure Stack HCI. Los clientes y partners pueden generar una solicitud de soporte técnico directamente con Microsoft en Azure portal seleccionando el icono de Soporte técnico y solución de problemas o poniéndose en contacto con su partner de hardware de OEM o SI, en función de la naturaleza de la solicitud y la categoría de solución de hardware.

   Sugerencia

   La implementación de referencia del clúster de Azure Stack HCI 23H2 muestra cómo implementar una implementación multiservidor conmutada de Azure Stack HCI mediante una plantilla de ARM y un archivo de parámetros. Como alternativa, en el ejemplo de Bicep se muestra cómo usar una plantilla de Bicep para implementar un clúster de Azure Stack HCI, incluidos sus recursos de requisitos previos.

9. Implemente cargas de trabajo de alta disponibilidad en Azure Stack HCI mediante Azure Portal, la CLI o las plantillas de ARM + Azure Arc para la automatización. Use el recurso de ubicación personalizada del nuevo clúster de HCI como región de destino al implementar recursos de carga de trabajo como máquinas virtuales de Azure Arc, AKS, hosts de sesión de Azure Virtual Desktop u otros servicios habilitados para Azure Arc que puede habilitar a través de extensiones de AKS y contenedorización en Azure Stack HCI.

10. Instale actualizaciones mensuales para mejorar la seguridad y confiabilidad de la plataforma. Para mantener actualizados los clústeres de Azure Stack HCI, es importante instalar actualizaciones de software de Microsoft y actualizaciones de firmware y controladores de 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 su partner de 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 Nodos validados). Para obtener más información, consulte Actualizaciones de infraestructura.

Recursos relacionados

• Diseño de arquitectura híbrida
• Opciones híbridas de Azure
• Automation en un entorno híbrido
• State Configuration de Azure Automation
• Optimización de la administración de instancias de SQL Server en entornos locales y de varias nubes mediante Azure Arc

Pasos siguientes

Documentación del producto:

• Información de la versión de Azure Stack HCI versión 23H2
• AKS en Azure Stack HCI
• Azure Virtual Desktop para Azure Stack HCI
• ¿Qué es la supervisión de Azure Stack HCI?
• Protección de cargas de trabajo de máquina virtual con Site Recovery en Azure Stack HCI
• Información general de Monitor
• Información general sobre Seguimiento de cambios e inventario
• Información general sobre Update Manager
• ¿Qué son los servicios de datos habilitados para Azure Arc?
• ¿Qué son los servidores habilitados para Azure Arc?
• ¿Qué es el servicio Backup?

Documentación del producto para obtener más información sobre servicios específicos de Azure:

• Azure Stack HCI
• Azure Arc
• Key Vault
• Azure Blob Storage
• Supervisión
• Azure Policy
• Azure Container Registry
• Defender for Cloud
• Recuperación de sitios
• Backup

Módulos de Microsoft Learn:

• Configuración de Monitor
• Diseño de una solución de Site Recovery en Azure
• Introducción a los servidores habilitados para Azure Arc
• Introducción a los servicios de datos habilitados para Azure Arc
• Introducción a AKS
• Implementación de modelos a escala con Machine Learning en cualquier lugar: blog de Tech Community
• Implementación de Machine Learning en cualquier lugar con AKS y Machine Learning habilitado para Azure Arc: blog de Tech Community
• Machine Learning en AKS híbrido y Stack HCI mediante el Machine Learning habilitado para Azure Arc: blog de la comunidad tecnológica
• Introducción al destino de proceso de Kubernetes en Machine Learning
• Mantenimiento de las máquinas virtuales actualizadas
• Protección de la configuración de la máquina virtual con State Configuration de Azure Automation
• Protección de las máquinas virtuales con Azure Backup