Consideraciones de planeación de la integración del centro de datos para sistemas integrados de Azure Stack Hub
Si está interesado en un sistema integrado de Azure Stack Hub, debe comprender las principales consideraciones de planeación en torno a la implementación y cómo encaja el sistema en el centro de datos. En este artículo se proporciona información general de alto nivel de estas consideraciones que le ayudarán a tomar decisiones importantes de infraestructura para los sistemas integrados de Azure Stack Hub. Comprender estas consideraciones ayuda a trabajar con el proveedor de hardware oem mientras implementan Azure Stack Hub en el centro de datos.
Nota
Los sistemas integrados de Azure Stack Hub solo se pueden comprar de proveedores de hardware autorizados.
Para implementar Azure Stack Hub, debe proporcionar información de planeación al proveedor de soluciones antes de que se inicie la implementación para ayudar al proceso a continuar rápidamente y sin problemas. La información necesaria abarca toda la información de redes, seguridad e identidad con muchas decisiones importantes que pueden requerir conocimientos de muchas áreas y responsables de la toma de decisiones diferentes. Necesitará personas de varios equipos de su organización para asegurarse de que tiene toda la información necesaria lista antes de la implementación. Puede ayudar a comunicarse con su proveedor de hardware al recopilar esta información porque pueden tener consejos útiles.
Al investigar y recopilar la información necesaria, es posible que tenga que realizar algunos cambios de configuración previos a la implementación en el entorno de red. Estos cambios podrían incluir la reserva de espacios de direcciones IP para la solución de Azure Stack Hub, así como la configuración de enrutadores, conmutadores y firewalls para prepararse para la conectividad con los nuevos conmutadores de solución de Azure Stack Hub. Asegúrese de que el experto en áreas temáticas esté alineado para ayudarle con su planificación.
Consideraciones sobre el planeamiento de capacidad
Al evaluar una solución de Azure Stack Hub para la adquisición, se realizan opciones de configuración de hardware que tienen un impacto directo en la capacidad general de la solución de Azure Stack Hub. Entre ellas se incluyen las opciones clásicas de CPU, densidad de memoria, configuración de almacenamiento y escala general de soluciones (por ejemplo, número de servidores). A diferencia de una solución de virtualización tradicional, no se aplica la aritmética simple de estos componentes para determinar la capacidad utilizable. La primera razón es que Azure Stack Hub está diseñado para hospedar la infraestructura o los componentes de administración dentro de la propia solución. La segunda razón es que parte de la capacidad de la solución se reserva para apoyar la resiliencia al actualizar el software de la solución de forma que se minimice la interrupción de las cargas de trabajo de los inquilinos.
La hoja de cálculo del planificador de capacidad de Azure Stack Hub le ayuda a tomar decisiones fundamentadas para planificar la capacidad de dos maneras. La primera consiste en seleccionar una oferta de hardware e intentar ajustarse a una combinación de recursos. La segunda consiste en definir la carga de trabajo que está destinada a ejecutar Azure Stack Hub para visualizar los SKU de hardware disponibles que pueden soportarla. Por último, la hoja de cálculo está pensada como guía para ayudar a tomar decisiones relacionadas con la planeación y configuración de Azure Stack Hub.
La hoja de cálculo no está pensada para servir como sustituto de su propia investigación y análisis. Microsoft no realiza ninguna representación o garantía, expresa o implícita, con respecto a la información proporcionada dentro de la hoja de cálculo.
Consideraciones de administración
Azure Stack Hub es un sistema sellado, donde la infraestructura está bloqueada desde una perspectiva de permisos y de red. Las listas de control de acceso de red (ACL) se aplican para bloquear todo el tráfico entrante no autorizado y todas las comunicaciones innecesarias entre los componentes de la infraestructura. Este sistema dificulta que los usuarios no autorizados accedan al sistema.
Para la administración y las operaciones diarias, no hay acceso de administrador sin restricciones a la infraestructura. Los operadores de Azure Stack Hub deben administrar el sistema a través del portal de administración o a través de Azure Resource Manager (mediante PowerShell o la API REST). No hay acceso al sistema mediante otras herramientas de administración como Hyper-V Manager o Failover Cluster Manager. Para ayudar a proteger el sistema, no se puede instalar software de terceros (por ejemplo, agentes) dentro de los componentes de la infraestructura de Azure Stack Hub. La interoperabilidad con software de seguridad y administración externa se produce a través de PowerShell o la API REST.
Póngase en contacto con el soporte técnico de Microsoft cuando necesite un mayor nivel de acceso para solucionar problemas que no se resuelven a través de los pasos de mediación de alertas. A través del soporte técnico, hay un método para proporcionar acceso de administrador completo temporal al sistema para operaciones más avanzadas.
Consideraciones de identidad
Elección del proveedor de identidades
Deberá tener en cuenta qué proveedor de identidades desea usar para la implementación de Azure Stack Hub, ya sea el identificador de Microsoft Entra o AD FS. No se pueden cambiar los proveedores de identidades después de la implementación sin la reimplementación completa del sistema. Si no posee la cuenta de Microsoft Entra y usa una cuenta proporcionada por su proveedor de soluciones en la nube, y si decide cambiar de proveedor y usar otra cuenta de Microsoft Entra, tendrá que ponerse en contacto con el proveedor de soluciones para volver a implementar la solución a su costo.
La elección del proveedor de identidades no tiene ningún efecto en las máquinas virtuales (VM) del inquilino, el sistema de identidades, las cuentas que usan o si pueden unirse a un dominio de Active Directory, etc. Estas cosas son independientes.
Puede implementar varios sistemas de Azure Stack Hub con el mismo inquilino de Microsoft Entra o Active Directory.
Integración de AD FS y Graph
Si decide implementar Azure Stack Hub con AD FS como proveedor de identidades, debe integrar la instancia de AD FS en Azure Stack Hub con una instancia de AD FS existente a través de una confianza de federación. Esta integración permite que las identidades de un bosque de Active Directory existente se autentiquen con recursos en Azure Stack Hub.
También puede integrar el servicio Graph en Azure Stack Hub con active Directory existente. Esta integración le permite administrar Role-Based Control de acceso (RBAC) en Azure Stack Hub. Cuando se delega el acceso a un recurso, el componente Graph busca la cuenta de usuario en el bosque de Active Directory existente mediante el protocolo LDAP.
En el diagrama siguiente se muestra el flujo de tráfico integrado de AD FS y Graph.
diagrama de 
Modelo de licencias
Debe decidir qué modelo de licencias desea usar. Las opciones disponibles dependen de si implementa Azure Stack Hub conectado a Internet:
- Para una implementación conectada, puede elegir licencias de pago por uso o según la capacidad. El pago por uso requiere una conexión a Azure para notificar el uso, que se factura a través del comercio de Azure.
- La licencia según la capacidad solo se admite si implementa desconectado desde Internet.
Para más información acerca de los modelos de licencias, consulte Paquetes y precios de Microsoft Azure Stack Hub.
Decisiones de nomenclatura
Deberá pensar en cómo quiere planear el espacio de nombres de Azure Stack Hub, especialmente el nombre de región y el nombre de dominio externo. El nombre de dominio completo externo (FQDN) de la implementación de Azure Stack Hub para puntos de conexión públicos es la combinación de estos dos nombres: <región>.<fqdn>. Por ejemplo, east.cloud.fabrikam.com. En este ejemplo, los portales de Azure Stack Hub estarían disponibles en las siguientes direcciones URL:
https://portal.east.cloud.fabrikam.comhttps://adminportal.east.cloud.fabrikam.com
Importante
El nombre de región que elija para la implementación de Azure Stack Hub debe ser único y aparecerá en las direcciones del portal.
En la tabla siguiente se resumen estas decisiones de nomenclatura de dominio.
| Nombre | Descripción |
|---|---|
| Nombre de la región | Nombre de la primera región de Azure Stack Hub. Este nombre se usa como parte del FQDN para las direcciones IP virtuales públicas (VIP) que administra Azure Stack Hub. Normalmente, el nombre de la región sería un identificador de ubicación física, como una ubicación del centro de datos. El nombre de la región debe constar de solo letras y números entre 0 y 9. No se permiten caracteres especiales (como -, #, etc.). |
| Nombre de dominio externo | Nombre de la zona de Sistema de nombres de dominio (DNS) para los puntos de conexión con direcciones VIP de uso externo. Se utiliza en el FQDN para estas VIP públicas. |
| Nombre de dominio privado (interno) | Nombre del dominio (y zona DNS interna) creado en Azure Stack Hub para la administración de infraestructuras. |
Requisitos de certificado
Para la implementación, deberá proporcionar certificados de SSL (capa de puertos seguros) para conexiones públicas. En un nivel alto, los certificados tienen los siguientes requisitos:
- Puede usar un único certificado comodín o bien un conjunto de certificados dedicados y utilizar caracteres comodín solo para los puntos de conexión, como el almacenamiento y Key Vault.
- Los certificados se pueden emitir mediante una entidad de certificación (CA) de confianza pública o una ENTIDAD de certificación administrada por el cliente.
Para más información sobre los certificados PKI necesarios para implementar Azure Stack Hub y cómo obtenerlos, consulte requisitos de certificado de infraestructura de clave pública de Azure Stack Hub.
Importante
La información del certificado PKI proporcionada debe usarse como guía general. Antes de adquirir certificados PKI para Azure Stack Hub, trabaje con el asociado de hardware oem. Proporcionarán instrucciones y requisitos de certificados más detallados.
Sincronización de hora
Debe elegir un servidor de hora específico que se usa para sincronizar Azure Stack Hub. La sincronización de hora es fundamental para Azure Stack Hub y sus roles de infraestructura, ya que se usa para generar tickets Kerberos. Los vales de Kerberos se usan para autenticar servicios internos entre sí.
Debe especificar una dirección IP para el servidor de sincronización de hora. Aunque la mayoría de los componentes de la infraestructura pueden resolver una dirección URL, algunas solo admiten direcciones IP. Si utiliza la opción de implementación desconectada, debe especificar un servidor de tiempo en la red corporativa al que esté seguro de poder acceder desde la red de infraestructura de Azure Stack Hub.
Importante
Si el servidor de hora no es un servidor NTP basado en Windows, debe añadir ,0x8 al final de la dirección IP. Por ejemplo, 10.1.1.123,0x8.
Conexión de Azure Stack Hub a Azure
En escenarios de nube híbrida, deberá planear cómo quiere conectar Azure Stack Hub a Azure. Hay dos métodos admitidos para conectar redes virtuales de Azure Stack Hub a redes virtuales en Azure:
Conexión de sitio a sitio: una conexión de red privada virtual (VPN) a través de IPsec (IKE v1 y IKE v2). Este tipo de conexión requiere un dispositivo VPN o un servicio de enrutamiento y acceso remoto (RRAS). Para obtener más información sobre las puertas de enlace de VPN en Azure, consulte Acerca de VPN Gateway. La comunicación a través de este túnel está cifrada y segura. Sin embargo, el ancho de banda está limitado por el rendimiento máximo del túnel (100-200 Mbps).
NAT de Salida: De forma Predeterminada, todas las máquinas virtuales de Azure Stack Hub tendrán conectividad a redes externas a través de NAT de Salida. Cada red virtual que se crea en Azure Stack Hub obtiene una dirección IP pública asignada. Tanto si a la máquina virtual se le asigna directamente una dirección IP pública como si está detrás de un equilibrador de carga con una dirección IP pública, tendrá acceso a Internet mediante NAT de salida utilizando la IP virtual (VIP) de la red virtual. Este método solo funciona para la comunicación iniciada por la máquina virtual y destinada a redes externas (internet o intranet). No se puede usar para comunicarse con la máquina virtual desde fuera.
Opciones de conectividad híbrida
Para la conectividad híbrida, es importante tener en cuenta qué tipo de implementación desea ofrecer y dónde se implementará. Deberá tener en cuenta si necesita aislar el tráfico de red por inquilino y si tendrá una implementación de intranet o de Internet.
Azure Stack Hub de inquilino único: una implementación de Azure Stack Hub que parece, al menos desde una perspectiva de la red, como si fuera un inquilino. Puede haber muchas suscripciones de inquilino, pero como cualquier servicio de intranet, todo el tráfico viaja a través de las mismas redes. El tráfico de red de una suscripción viaja a través de la misma conexión de red que otra suscripción y no es necesario aislarse a través de un túnel cifrado.
Azure Stack Hub de varios inquilinos: implementación de Azure Stack Hub donde el tráfico de suscripción de cada inquilino que está limitado por redes externas a Azure Stack Hub debe aislarse del tráfico de red de otros inquilinos.
Implementación de intranet: Una implementación de Azure Stack Hub situada en una intranet corporativa, generalmente en un espacio de direcciones IP privadas y detrás de uno o varios cortafuegos. Las direcciones IP públicas no son realmente públicas porque no se pueden enrutar directamente a través de la red pública de Internet.
Implementación en Internet: implementación de Azure Stack Hub que está conectada a la red pública de Internet y usa las direcciones IP públicas que se pueden redirigir por Internet para el intervalo de dirección VIP público. La implementación todavía puede ubicarse detrás de un firewall, pero el intervalo de dirección VIP público es accesible directamente desde Azure y la red pública de Internet.
En la tabla siguiente se resumen los escenarios de conectividad híbrida con las ventajas, desventajas y casos de uso.
| Escenario | Método de conectividad | Ventajas | Contras | Bueno para |
|---|---|---|---|---|
| Azure Stack Hub de inquilino único, implementación en intranet | NAT de salida | Mejor ancho de banda para transferencias más rápidas. Fácil de implementar; no se requieren puertas de enlace. | Tráfico no cifrado; sin aislamiento ni cifrado fuera de la pila. | Implementaciones empresariales en las que todos los inquilinos son igualmente de confianza. Empresas que tienen un circuito Azure ExpressRoute en Azure. |
| Azure Stack Hub de varios inquilinos, implementación en intranet | VPN de sitio a sitio | El tráfico desde la VNet del inquilino hacia el destino es seguro. | El ancho de banda está limitado por túnel VPN de sitio a sitio. Requiere una puerta de enlace en la red virtual y un dispositivo VPN en la red de destino. |
Implementaciones empresariales en las que cierto tráfico de inquilinos debe protegerse de otros inquilinos. |
| Azure Stack Hub de inquilino único, implementación en Internet | NAT de salida | Mejor ancho de banda para transferencias más rápidas. | El tráfico no está cifrado; no hay aislamiento ni cifrado fuera del stack. | Escenarios de hospedaje en los que el inquilino obtiene su propia implementación de Azure Stack Hub y un circuito dedicado al entorno de Azure Stack Hub. Por ejemplo, ExpressRoute y conmutación de etiquetas de multiprotocolo (MPLS). |
| Azure Stack Hub de varios inquilinos, implementación en Internet | VPN de sitio a sitio | El tráfico de la red virtual del inquilino al destino es seguro. | El ancho de banda está limitado por túnel VPN de sitio a sitio. Requiere una puerta de enlace en la red virtual y un dispositivo VPN en la red de destino. |
Escenarios de hospedaje en los que el proveedor quiere ofrecer una nube multiinquilino, donde los inquilinos no confían entre sí y se debe cifrar el tráfico. |
Uso de ExpressRoute
Puede conectar Azure Stack Hub a Azure a través de ExpressRoute para escenarios de intranet de inquilino único y de varios inquilinos. Necesitará un circuito ExpressRoute aprovisionado a través de un proveedor de conectividad.
En el diagrama siguiente se muestra ExpressRoute para un escenario de un solo inquilino (donde "La conexión del cliente" es el circuito ExpressRoute).
diagrama de 
En el diagrama siguiente se muestra ExpressRoute para un escenario multiinquilino.
Diagrama de 
Supervisión externa
Para obtener una vista única de todas las alertas de la implementación y los dispositivos de Azure Stack Hub, así como para integrar las alertas en los flujos de trabajo existentes de administración de servicios de TI para el control de incidencias, puede integrar Azure Stack Hub con soluciones externas de supervisión de centros de datos.
Incluido con la solución de Azure Stack Hub, el host del ciclo de vida de hardware es un equipo fuera de Azure Stack Hub que ejecuta herramientas de administración proporcionadas por el proveedor oem para hardware. Puede usar estas herramientas u otras soluciones que se integren directamente con las soluciones de supervisión existentes en el centro de datos.
En la tabla siguiente se resume la lista de opciones disponibles actualmente.
| Área | Solución de supervisión externa |
|---|---|
| Software de Azure Stack Hub | Paquete de administración de Azure Stack Hub para Operations Manager Complemento de Nagios Llamadas API basadas en REST |
| Servidores físicos (BMC a través de IPMI) | Hardware OEM: módulo de administración del distribuidor de Operations Manager Solución proporcionada por el proveedor de hardware OEM Complementos de Nagios del proveedor de hardware. Solución de supervisión soportada por socios OEM (incluida) |
| Dispositivos de red (SNMP) | Detección de dispositivos de red por Operations Manager Solución proporcionada por el proveedor de hardware OEM Complemento conmutador de Nagios |
| Supervisión del estado de suscripción del inquilino | módulo de administración de System Center para Windows Azure |
Tenga en cuenta los siguientes requisitos:
- La solución que use debe ser sin agente. No puede instalar agentes de terceros dentro de los componentes de Azure Stack Hub.
- Si desea usar System Center Operations Manager, se requiere Operations Manager 2012 R2 o Operations Manager 2016.
Copia de seguridad y recuperación ante desastres
La planeación de la copia de seguridad y la recuperación ante desastres implica planear la infraestructura subyacente de Azure Stack Hub que hospeda máquinas virtuales IaaS y servicios PaaS, así como para aplicaciones y datos de inquilinos. Planee estas cosas por separado.
Protección de componentes de infraestructura
Puede realizar una copia de seguridad de los componentes de infraestructura de Azure Stack Hub en el recurso compartido SMB que especifique:
- Necesitará un recurso compartido de archivos SMB externo en un servidor de archivos basado en Windows existente o en un dispositivo de terceros.
- Use este mismo recurso compartido para la copia de seguridad de los conmutadores de red y el host del ciclo de vida del hardware. El proveedor de hardware oem le ayudará a proporcionar instrucciones para la copia de seguridad y restauración de estos componentes, ya que son externos a Azure Stack Hub. Es responsable de ejecutar los flujos de trabajo de copia de seguridad en función de la recomendación del proveedor de OEM.
Si se produce una pérdida de datos grave, puede usar la copia de seguridad de infraestructura para volver a usar los datos de implementación, como:
- Entradas e identificadores de implementación
- Cuentas de servicio
- Certificado raíz de CA
- Recursos federados (en implementaciones desconectadas)
- Planes, ofertas, suscripciones y cuotas
- Políticas de RBAC y asignaciones de roles
- Secretos de Key Vault
Advertencia
De forma predeterminada, la instancia de Azure Stack Hub está configurada solo con una cuenta de CloudAdmin. No hay opciones de recuperación si las credenciales de la cuenta se pierden, se ponen en peligro o se bloquean. Perderá el acceso al punto de conexión con privilegios y a otros recursos.
Se recomienda encarecidamente crear cuentas de CloudAdmin adicionales para evitar la reimplementación de su sello a su propio costo. Asegúrese de documentar estas credenciales en función de las directrices de su empresa.
Protección de aplicaciones de inquilino en máquinas virtuales IaaS
Azure Stack Hub no realiza una copia de seguridad de las aplicaciones y los datos de inquilinos. Debe planear la protección de copia de seguridad y recuperación ante desastres en un destino externo a Azure Stack Hub. La protección de inquilinos es una actividad controlada por inquilinos. En el caso de las máquinas virtuales IaaS, los usuarios pueden usar tecnologías de invitado para proteger las carpetas de archivos, los datos de las aplicaciones y el estado del sistema. Sin embargo, como proveedor de servicios o empresa, es posible que quiera ofrecer una solución de copia de seguridad y recuperación en el mismo centro de datos o externamente en una nube.
Para realizar copias de seguridad de máquinas virtuales IaaS de Linux o Windows, debe usar productos de copia de seguridad con acceso al sistema operativo invitado para proteger los datos de archivo, carpeta, estado del sistema operativo y aplicación. Puede usar Azure Backup, System Center Datacenter Protection Manager o productos de terceros compatibles.
Para replicar datos en una ubicación secundaria y orquestar la conmutación por error de la aplicación si se produce un desastre, puede usar Azure Site Recovery o productos de terceros compatibles. Además, las aplicaciones que admiten la replicación nativa, como Microsoft SQL Server, pueden replicar datos en otra ubicación donde se ejecuta la aplicación.
Aprende más
- Para obtener información sobre los casos de uso, la compra, los asociados y los proveedores de hardware oem, consulte la página del producto Azure Stack Hub.
- Para obtener información sobre el mapa de ruta y la disponibilidad geográfica de los sistemas integrados de Azure Stack Hub, consulte el documento técnico: Azure Stack Hub: una extensión de Azure.