Este artículo forma parte de una serie que se basa en la arquitectura de referencia de línea de base de Azure Stack HCI. Para implementar eficazmente Azure Stack HCI mediante un diseño sin conmutadores de almacenamiento de tres nodos, es importante comprender la arquitectura de línea de base. Este proceso incluye familiarizarse con las opciones de diseño del clúster para los nodos físicos que proporcionan funcionalidades de proceso, almacenamiento y redes locales. Este conocimiento le ayuda a identificar los cambios necesarios para una implementación correcta. Las instrucciones de este artículo también se aplican a una implementación sin conmutadores de almacenamiento de dos nodos y realiza los ajustes necesarios para los casos en los que el número de nodos físicos disminuye de tres a dos.
El diseño de red sin conmutadores de almacenamiento elimina el requisito de conmutadores de red de clase de almacenamiento para conectar los puertos del adaptador de red que se usan para el tráfico de almacenamiento. En su lugar, los nodos están conectados directamente mediante cables Ethernet Interlink. Esta configuración se usa normalmente en escenarios de venta al por menor, fabricación u oficina remota. Esta configuración también es adecuada para casos de uso perimetral más pequeños que no tienen o no requieren conmutadores de red de centro de datos extensos para el tráfico de replicación de almacenamiento.
Esta arquitectura de referencia proporciona instrucciones y recomendaciones independientes de la carga de trabajo para configurar Azure Stack HCI como una plataforma de infraestructura resistente para implementar y administrar cargas de trabajo virtualizadas. Para obtener más información sobre los patrones de arquitectura de 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 un clúster de Azure Stack HCI de tres nodos que usa un diseño de red sin conmutadores de almacenamiento. Las aplicaciones de carga de trabajo implementadas en un clúster de Azure Stack HCI deben estar bien diseñadas. Este enfoque incluye la implementación de varias instancias para lograr una alta disponibilidad de los servicios críticos de carga de trabajo e implementar los controles adecuados de continuidad empresarial y recuperación ante desastres (BCDR), como las copias de seguridad normales y las funcionalidades de conmutación por error de recuperación ante desastres. Para centrarse 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 la guía del servicio del Marco de buena arquitectura de Azure Azure Stack HCI.
Diseño del artículo
| Arquitectura | Decisiones de diseño | Enfoque de marco de buena arquitectura |
|---|---|---|
| ▪ Diagrama de la arquitectura ▪ Posibles casos de uso ▪ Implementación de este escenario. |
▪ Opciones de diseño de clúster ▪ Redes |
▪ Optimización de costes ▪ Eficacia del rendimiento |
Sugerencia
En esta implementación de referencia se describe cómo implementar una solución de Azure Stack HCI sin conmutadores de almacenamiento de tres nodos mediante una plantilla de ARM y un archivo de parámetros.
Arquitectura
Para obtener más información acerca de estos recursos, consulte Recursos relacionados.
Posibles casos de uso
Use este diseño y los diseños descritos en la arquitectura de referencia de línea de base de Azure Stack HCI para satisfacer los siguientes requisitos de casos de uso:
Implemente y administre cargas de trabajo perimetrales virtualizadas o basadas en contenedores de alta disponibilidad (HA) que se implementen en una sola ubicación para permitir que las aplicaciones y servicios críticos para la empresa funcionen de forma resistente, rentable y escalable.
El diseño de red sin conmutadores de almacenamiento elimina el requisito de implementar conmutadores de red de clase de almacenamiento para conectar los puertos del adaptador de red que se usan para el tráfico de almacenamiento.
Puede usar el diseño de red sin conmutadores de almacenamiento para ayudar a reducir los costes asociados a la adquisición y configuración de conmutadores de red de clase de almacenamiento para el tráfico de almacenamiento, pero aumenta el número de puertos de adaptador de red necesarios en los nodos físicos.
Componentes de la arquitectura
Los recursos de la arquitectura permanecen prácticamente sin cambios respecto a la arquitectura de referencia de línea de base. Para obtener más información, consulte los recursos de la plataforma y los recursos auxiliares de la plataforma que se usan para las implementaciones de Azure Stack HCI.
Opciones de diseño de clúster
Al determinar las opciones de diseño del clúster, consulte la arquitectura de referencia de línea de base. Use estas conclusiones y la herramienta de dimensionamiento de Azure Stack HCI para escalar correctamente un clúster de Azure Stack HCI según los requisitos de carga de trabajo.
Cuando se usa el diseño sin conmutadores de almacenamiento, es fundamental recordar que un clúster de tres nodos es el tamaño máximo admitido. Esta limitación es una consideración clave para las opciones de diseño del clúster, ya que debe asegurarse de que los requisitos de capacidad de la carga de trabajo no superen las funcionalidades de capacidad física de las especificaciones del clúster de tres nodos. Dado que no se puede realizar un gesto de agregar nodo para expandir un clúster sin conmutadores de almacenamiento más allá de tres nodos, es fundamental comprender los requisitos de capacidad de carga de trabajo de antemano y planificar el crecimiento futuro. De este modo, puede asegurarse de que la carga de trabajo no supere la capacidad de almacenamiento y proceso durante la duración esperada del hardware del clúster de Azure Stack HCI.
Precaución
El tamaño máximo de clúster admitido para la arquitectura de red sin conmutadores de almacenamiento es tres nodos físicos. Asegúrese de tener en cuenta este límite durante la fase de diseño del clúster, como incluir los requisitos de capacidad de crecimiento actuales y futuros para la carga de trabajo.
Diseño de red
El diseño de red hace referencia a la disposición general de los componentes físicos y lógicos dentro de la red. En una configuración sin conmutadores de almacenamiento de tres nodos para Azure Stack HCI, se conectan directamente tres nodos físicos sin usar un conmutador externo para el tráfico de almacenamiento. Estas conexiones Ethernet intervinculadas directas simplifican el diseño de red al reducir la complejidad porque no hay ningún requisito para definir o aplicar la calidad de almacenamiento de los servicios y las configuraciones de priorización en los conmutadores. Las tecnologías que respaldan la comunicación RDMA sin pérdida, como la notificación de congestión explícita (ECN), el control de flujo de prioridad (PFC) o la calidad del servicio (QoS) que son necesarios para RoCE v2 e iWARP, no son necesarias. Sin embargo, esta configuración admite un máximo de tres nodos, lo que significa que no se puede escalar el clúster agregando más nodos después de la implementación.
Nota:
Esta arquitectura sin conmutadores de almacenamiento de tres nodos requiere seis puertos de adaptador de red que proporcionan vínculos redundantes para todas las intenciones de red. Tenga en cuenta esto si tiene pensado usar una SKU de hardware de factor de forma pequeño o si hay espacio físico limitado en el chasis del servidor para tarjetas de red adicionales. Consulte a su asociado de fabricante de hardware preferido para obtener más información.
Topología de red física
La topología de red física muestra las conexiones físicas reales entre los nodos y los componentes de red. Las conexiones entre nodos y componentes de red para una implementación de Azure Stack HCI sin conmutadores de almacenamiento de tres nodos son:
Tres nodos (o servidores):
Cada nodo es un servidor físico que se ejecuta en el sistema operativo Azure Stack HCI.
Cada nodo requiere seis puertos de adaptador de red en total: cuatro puertos compatibles con RDMA para el almacenamiento y dos puertos para la administración y el proceso.
Tráfico de almacenamiento:
Cada uno de los tres nodos está interconectado a través de puertos de adaptador de red físicos dedicados dobles para el almacenamiento. En el siguiente diagrama se muestra este proceso.
Los puertos del adaptador de red de almacenamiento se conectan directamente a cada nodo mediante cables Ethernet para formar una arquitectura de red de malla completa para el tráfico de almacenamiento.
Este diseño proporciona redundancia de vínculos, latencia baja dedicada, ancho de banda alto y alto rendimiento.
Los nodos del clúster de HCI se comunican directamente a través de estos vínculos para controlar el tráfico de replicación de almacenamiento, también conocido como tráfico este-oeste.
Esta comunicación directa elimina la necesidad de puertos de conmutador de red adicionales para el almacenamiento y elimina el requisito de aplicar la configuración de QoS o PFC para el tráfico SMB directo o RDMA en los conmutadores de red.
Consulte con el asociado del fabricante de hardware o el proveedor de la tarjeta de interfaz de red (NIC) para conocer los controladores de sistema operativo, las versiones de firmware o la configuración de firmware recomendados para la configuración de red de interconexión sin conmutadores.
Conmutadores dobles de la parte superior del bastidor (ToR):
Esta configuración es sin conmutadores para el tráfico de almacenamiento, pero requiere conmutadores ToR para la conectividad externa. Esta conectividad se denomina tráfico norte-sur e incluye la intención de administración del clúster y la intención de proceso de carga de trabajo.
Los vínculos superiores a los conmutadores de cada nodo usan dos puertos de adaptador de red. Los cables Ethernet conectan estos puertos, uno a cada conmutador ToR, para proporcionar redundancia de vínculo.
Se recomienda usar conmutadores ToR dobles para proporcionar redundancia para las operaciones de mantenimiento y el equilibrio de carga para la comunicación externa.
Conectividad externa:
Los conmutadores ToR dobles se conectan a la red externa, como la LAN corporativa interna, y usan el dispositivo de red perimetral, como un firewall o enrutador, para proporcionar acceso a las direcciones URL de salida necesarias.
Los dos conmutadores ToR controlan el tráfico norte-sur del clúster de Azure Stack HCI, incluido el tráfico relacionado con las intenciones de administración y proceso.
Topología de red lógica
La topología de red lógica proporciona información general sobre cómo fluyen los datos de red entre dispositivos, independientemente de sus conexiones físicas. En la lista siguiente se resume la configuración lógica de un clúster de Azure Stack HCI sin conmutadores de almacenamiento de tres nodos:
Conmutadores ToR dobles:
- Antes de la implementación del clúster, los dos conmutadores de red ToR deben configurarse con los identificadores de VLAN necesarios y la configuración máxima de la unidad de transmisión (MTU) para los puertos de administración y proceso. Para obtener más información, consulte los requisitos de red física o pida ayuda al proveedor de hardware del conmutador o al asociado integrador de sistemas (SI).
Azure Stack HCI aplica la automatización de red y la configuración de red basada en intenciones mediante el servicio Network ATC.
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 de 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 de formación de equipos insertada (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 SET para las intenciones de proceso y administración.
Tráfico de almacenamiento:
Los nodos se comunican entre sí directamente para el tráfico de almacenamiento mediante los cuatro puertos Ethernet de interconexión directa por nodo, que usan seis redes no enrutables independientes (o capa 2) para el tráfico de almacenamiento.
No hay ninguna puerta de enlace predeterminada configurada en los cuatro 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 S2D del clúster, como los 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 garantiza 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 de las direcciones IP
Para implementar una configuración sin conmutadores de almacenamiento de tres nodos de Azure Stack HCI con vínculos dobles para las interconexiones de almacenamiento, la plataforma de infraestructura de clúster requiere que asigne un mínimo de 20 direcciones IP. Se requieren más direcciones IP si usa un dispositivo de máquina virtual proporcionado por el asociado del fabricante de hardware o si usa microsegmentación o redes definidas por software (SDN). Para obtener más información, consulte Revisión de los requisitos de IP del patrón de referencia de almacenamiento de tres nodos para Azure Stack HCI.
Al diseñar y planificar los requisitos de direcciones IP para Azure Stack HCI, recuerde tener en cuenta direcciones IP adicionales o 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 usar Azure Kubernetes Services (AKS) en Azure Stack HCI, consulte Requisitos de red de Azure Arc habilitados para AKS.
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.
Importante
Revise las consideraciones del Marco de buena arquitectura que se describen en la arquitectura de referencia de línea de base de Azure Stack HCI.
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:
- Interconexiones de clúster sin conmutadores frente a interconexiones de clúster basadas en conmutadores. La topología de interconexión sin conmutadores consta de conexiones entre puertos dobles, o con redundancia, puertos de adaptador de red compatibles con RDMA en cada nodo para formar una malla completa. Cada nodo tiene dos conexiones directas con cualquier otro nodo. Aunque esta implementación es sencilla, solo se admite en clústeres de dos nodos o de tres nodos. Un clúster de Azure Stack HCI con cuatro o más nodos requiere la arquitectura de red conmutada de almacenamiento. Puede usar esta arquitectura para agregar más nodos después de la implementación, a diferencia del diseño sin conmutadores de almacenamiento, que no admite operaciones de añadir nodos.
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:
- No puede aumentar la escala (ni realizar una operación de añadir nodos) de un clúster HCI sin conmutadores de almacenamiento de tres nodos existente sin volver a implementar el clúster y agregar funcionalidades de red adicionales, como conmutadores de red, puertos y cables para el tráfico de almacenamiento y los demás nodos necesarios. Tres nodos son el tamaño máximo admitido del clúster para el diseño de red sin conmutadores de almacenamiento. Tenga en cuenta esta limitación en la fase de diseño del clúster para asegurarse de que el hardware puede admitir el crecimiento futuro de la capacidad de la carga de trabajo.
Implementación de este escenario
Para obtener más información sobre cómo diseñar, adquirir e implementar una solución de Azure Stack HCI, consulte la sección Implementación de este escenario de la arquitectura de referencia de línea de base de Azure Stack HCI.
Use la siguiente plantilla de automatización de implementación como ejemplo de cómo implementar Azure Stack HCI mediante la arquitectura sin conmutadores de almacenamiento de tres nodos.
Sugerencia
Automatización de la implementación: esta plantilla de referencia describe cómo implementar una solución de Azure Stack HCI sin conmutadores de almacenamiento de tres nodos mediante una plantilla de ARM y un archivo de parámetros.
Recursos relacionados
- Diseño de arquitectura híbrida
- Opciones híbridas de Azure
- 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
- Introducción a Azure Monitor
- Información general de Change Tracking e Inventario
- Información general de Azure Update Manager
- ¿Qué son los servicios de datos habilitados para Azure Arc?
- ¿Qué son los servidores habilitados para Azure Arc?
- ¿Qué es Azure Backup?
- Introducción al destino de proceso de Kubernetes en Azure Machine Learning
Documentación del producto para servicios específicos de Azure:
- Azure Stack HCI
- Azure Arc
- Azure Key Vault
- Azure Blob Storage
- Supervisión
- Azure Policy
- Azure Container Registry
- Microsoft Defender for Cloud
- Azure Site Recovery
- 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
- Escalado de la implementación de modelos con Azure Machine Learning en cualquier lugar: blog de la comunidad tecnológica
- Realización de Machine Learning en cualquier lugar con AKS y Machine Learning habilitado para Azure Arc: blog de la comunidad tecnológica
- Aprendizaje automático en AKS híbrido y Stack HCI mediante el aprendizaje automático habilitado para Azure Arc: blog de la comunidad tecnológica
- 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 mediante la copia de seguridad