Paso 1: Preparación de la implementación
El primer paso de la implementación del clúster de HPC es tomar decisiones importantes, como decidir el número de nodos principales y elegir una topología de red para el clúster. Las siguientes tareas le ayudarán a prepararse para la implementación del clúster.
1.1: Revisión de los requisitos del sistema
Si aún no lo ha hecho, revise los requisitos del sistema de para Microsoft HPC Pack 2019. Tenga en cuenta que HPC Pack tiene requisitos diferentes para diferentes roles de nodo y opciones de implementación. Es posible que quiera volver a revisar los requisitos del sistema después de haber finalizado las decisiones de la implementación.
1.2: Decidir si desea configurar el nodo principal para alta disponibilidad
Si tendrá que seguir ejecutando trabajos de HPC durante una interrupción planeada o no planeada en los servicios de un equipo de nodo principal, puede planear configurar el nodo principal para lograr una alta disponibilidad. Para ello, deberá instalar HPC Pack en al menos dos equipos de nodo principal.
1.3: Decidir si desea implementar el clúster con bases de datos remotas
HPC Pack 2019 requiere y admite Microsoft SQL Server 2014 o una versión posterior. HPC Pack usa cinco bases de datos de SQL Server diferentes para almacenar datos de administración de clústeres, programación de trabajos, informes, diagnósticos y supervisión. Puede instalar una o varias de estas cinco bases de datos HPC en uno o varios servidores remotos, en lugar de instalarlas en el nodo principal del clúster. De forma predeterminada, HPC Pack instala SQL Server Express 2019 en el nodo principal y crea las bases de datos de HPC en el nodo principal si elige un único nodo principal. Si decide implementar tres nodos principales, la ventaja de instalar las bases de datos de HPC en uno o varios servidores remotos es que guarda recursos en el nodo principal, lo que ayuda a garantizar que pueda administrar el clúster de forma eficaz.
Importante
Se recomienda el uso de SQL Server 2019 Express en el nodo principal para clústeres de prueba de concepto o desarrollo y para clústeres de producción más pequeños. Debe considerar la posibilidad de instalar las bases de datos de HPC en uno o varios servidores remotos si el clúster tendrá más de 256 nodos, tiene previsto configurar el nodo principal para lograr alta disponibilidad, o los requisitos de rendimiento y generación de informes de trabajos podrían superar las funcionalidades de SQL Server 2019 Express.
Para instalar las bases de datos de HPC en un servidor remoto, ese servidor debe ejecutar la edición Standard o Enterprise de SQL Server 2008 R2 o posterior y configurarse para que funcione con HPC Pack. Antes de instalar HPC Pack con bases de datos remotas, pida al administrador de bases de datos que ejecute el script de SetupHpcDatabase.ps1 en la carpeta setup o para realizar o modificar manualmente las tareas del script. El script crea automáticamente las bases de datos necesarias y los inicios de sesión de instancia de SQL y los usuarios de la base de datos para la cuenta que instalará HPC Pack y para la cuenta de equipo para los servicios de HPC. Para obtener información detallada, consulte Implementación de un clúster de HPC de Windows con bases de datos remotas guía paso a paso.
1.4: Decidir qué tipo de nodos desea agregar al clúster y cuántos
Puede agregar los siguientes tipos de nodos al clúster local:
- nodos de proceso: los nodos de proceso se usan para ejecutar trabajos. Este tipo de nodo no puede convertirse en un tipo diferente de nodo (es decir, cambiar roles) sin volver a implementarse.
- nodos de Broker: los nodos de agente de Windows Communication Foundation (WCF) se usan para enrutar llamadas WCF desde los clientes de Service-Oriented Architecture (SOA) a los servicios SOA que se ejecutan en los nodos del clúster. Este tipo de nodo puede cambiar los roles para convertirse en un nodo de proceso sin volver a implementarse.
- nodos de estación de trabajo y nodos de servidor no administrados: los nodos de estación de trabajo y los nodos de servidor no administrados son equipos de su organización que también pueden ejecutar trabajos, pero no son recursos de clúster dedicados. Se pueden programar para que estén disponibles para ejecutar trabajos en momentos específicos o se pueden poner a disposición a petición. Este tipo de nodo no puede cambiar los roles.
- nodos de Microsoft Azure: si tiene una suscripción de Microsoft Azure, puede agregar nodos de Azure a petición para aumentar la capacidad del clúster cuando lo necesite. Al igual que los nodos de proceso, los nodos de estación de trabajo y los nodos de servidor no administrados, los nodos de Azure pueden ejecutar trabajos. Al agregar nodos de Azure, también se configura un número fijo o variable de nodos proxy en la implementación de Azure para facilitar la comunicación entre el nodo principal local y los nodos de Azure.
- nodos iaaS de Microsoft Azure: si tiene una suscripción de Microsoft Azure, puede agregar nodos iaaS de Microsoft Azure a petición para aumentar la capacidad del clúster cuando lo necesite.
Para obtener más información sobre los roles de nodo en un clúster de HPC de Windows, consulte Descripción de los roles de nodo en Microsoft HPC Pack.
Cuando se instala HPC Pack, dependiendo del tipo de nodo que se crea, se instalan diferentes características. Estas características determinan el rol que el nodo realizará en el clúster. En algunos casos, un nodo puede cambiar los roles porque tiene las características necesarias para realizar un rol diferente. La capacidad de cambiar roles es un aspecto importante que debe tener en cuenta al decidir el tipo de nodos que desea agregar al clúster.
Otra decisión importante que debe tomar es el número de nodos que desea agregar. Si va a agregar nodos de agente, también debe decidir cuántos nodos de proceso agregará para cada nodo de agente que esté disponible en el clúster. La relación entre los nodos de agente y los nodos de proceso puede afectar al rendimiento del clúster.
Si planea agregar nodos de Azure, debe tener en cuenta el número de nodos proxy que es óptimo para el número de nodos implementados en Azure y los trabajos que se ejecutarán en esos nodos. Los nodos proxy son necesarios para la comunicación con el nodo principal local y pueden ser un cuello de botella para determinados tamaños y cargas de trabajo del clúster.
Por último, si desea configurar el nodo principal o un nodo de agente en un clúster de conmutación por error, necesita un equipo adicional para cada nodo de clúster de conmutación por error que configure, lo que podría reducir el número de nodos de proceso que puede agregar al clúster.
1.5: Elija el dominio de Active Directory para el clúster.
Desde HPC Pack 2016 en, HPC Pack se puede instalar en un equipo que no está unido a un dominio, pero esta característica está diseñada solo para clústeres de HPC en Azure. Para un clúster de HPC local, debe crear el clúster en un dominio de Active Directory.
Los nodos del clúster de HPC local serán miembros de un dominio de Active Directory. Antes de implementar el clúster local, elija el dominio de Active Directory que usará para el clúster de HPC.
Según el entorno de Active Directory de la organización, puede resultar útil configurar una unidad organizativa (OU) independiente para los equipos que serán miembros del clúster de HPC. Con una unidad organizativa independiente, si es necesario, se pueden aplicar directivas y configuraciones diferentes a los nodos del clúster que a los demás equipos de la organización.
Si no tiene un dominio de Active Directory al que puede unirse al clúster o si prefiere no unirse a un dominio existente, puede crear un nuevo dominio de Active Directory. Para obtener más información sobre cómo instalar el rol de Active Directory Domain Services, consulte Implementación de Active Directory Domain Services (AD DS) en Su empresa.
Consideraciones adicionales
El nodo principal de HPC Pack 2019 no se puede instalar en un controlador de dominio si tiene previsto instalar un clúster de alta disponibilidad con Microsoft Service Fabric. Esto se debe a que el clúster de Microsoft Service Fabric no se puede implementar en un controlador de dominio.
Si tiene previsto agregar nodos de estación de trabajo o nodos de servidor no administrados al clúster de HPC, esos equipos se pueden unir a cualquier dominio de Active Directory que tenga una relación de confianza establecida con el dominio al que está unido el nodo principal.
1.6: Elegir una cuenta de dominio para agregar nodos
Para instalar HPC Pack en el nodo principal, debe iniciar sesión con una cuenta de usuario de dominio que sea miembro del grupo Administradores en el equipo del nodo principal. Además, durante el proceso de configuración del nodo principal de HPC después de la instalación de HPC Pack, debe proporcionar credenciales para una cuenta de usuario de dominio que se usará para agregar nodos locales y para la configuración del sistema de esos nodos. Debe elegir una cuenta existente o crear una nueva antes de iniciar la implementación del clúster.
Consideraciones para elegir una cuenta de usuario
- La cuenta de usuario que elija debe ser una cuenta de dominio con privilegios suficientes para crear cuentas de equipo de Active Directory para los nodos y unir los nodos al dominio.
- Si las directivas de su organización le restringen el uso de una cuenta de dominio que puede agregar nuevos equipos al dominio, deberá pedir al administrador de dominio que cree previamente los objetos de equipo en Active Directory Domain Services antes de implementar los nodos. Para obtener más información, vea Implementar nodos con objetos de equipo creados previamente en Active Directory.
- Si parte de la implementación requiere acceso a los recursos de la red empresarial, la cuenta de usuario debe tener los permisos necesarios para acceder a esos recursos; por ejemplo, los archivos de instalación que están disponibles en un servidor de red.
- Si desea reiniciar los nodos de forma remota mediante el Administrador de clústeres de HPC, la cuenta debe ser miembro del grupo administradores local en el nodo principal. Este requisito solo es necesario si no tiene herramientas de control de energía con script que puede usar para reiniciar los nodos de forma remota.
1.7: Elección de una topología de red para el clúster
HPC Pack admite cinco topologías de clúster. Estas topologías se distinguen por cómo se conectan los nodos del clúster entre sí y a la red empresarial. Las cinco topologías de clúster admitidas son:
- Topología 1: nodos de proceso aislados en una red privada
- Topología 2: todos los nodos de redes privadas y empresariales
- Topología 3: nodos de proceso aislados en redes privadas y de aplicaciones
- Topología 4: todos los nodos de las redes de aplicaciones, privadas y empresariales
- Topología 5: todos los nodos de una red empresarial
Para obtener más información sobre cada topología de red y cada red de clúster de HPC, consulte Apéndice 1: Redes de clúster de HPC, más adelante en esta guía.
Al elegir una topología de red, debe tener en cuenta la infraestructura de red existente y el tipo de nodos que agregará al clúster:
- Decida qué red de la topología que ha elegido servirá como la red empresarial, la red privada y la red de aplicaciones.
- No tenga el adaptador de red conectado a la red empresarial en el nodo principal en la configuración automática (es decir, la dirección IP de ese adaptador no comienza por: 169.254). Ese adaptador debe tener una dirección IP válida, dinámica o manualmente asignada (estática).
- Si elige una topología que incluye una red privada y planea agregar nodos al clúster sin sistema operativo, haga lo siguiente:
- Asegúrese de que no haya ningún servidor de entorno de ejecución previo al arranque (PXE) en la red privada.
- Si desea usar un servidor DHCP existente para la red privada, asegúrese de que está configurado para reconocer el nodo principal como servidor PXE en la red.
- Si desea habilitar el servidor DHCP en el nodo principal para las redes privadas o de aplicaciones y hay otros servidores DHCP conectados a esas redes, debe deshabilitar esos servidores DHCP.
- Si tiene un servidor de sistema de nombres de dominio (DNS) existente conectado a la misma red que los nodos del clúster, no es necesario realizar ninguna acción, pero los nodos se anularán automáticamente del registro de ese servidor DNS.
- Póngase en contacto con el administrador del sistema para determinar si se aplica la seguridad del protocolo de Internet (IPsec) en el dominio a través de la directiva de grupo. Si IPsec se aplica a su dominio a través de la directiva de grupo, puede experimentar problemas durante la implementación. Una solución alternativa consiste en convertir el nodo principal en un servidor de límites de IPsec para que los demás nodos del clúster puedan comunicarse con el nodo principal durante el arranque pxe.
- Si desea agregar nodos de estación de trabajo o nodos de servidor no administrados al clúster, la topología 5 (todos los nodos de una red empresarial) es la topología recomendada, pero se admiten otras topologías. Si desea agregar nodos de estación de trabajo en otras topologías, consulte el contenido de Agregar nodos de estación de trabajo a un clúster de HPC de Windows.
- Si desea agregar nodos de agente al clúster, deben estar conectados a la red donde están conectados los clientes que inician sesiones SOA (normalmente la red empresarial) y a la red donde están conectados los nodos que ejecutan los servicios SOA (si son diferentes de la red donde están conectados los clientes).
- Si desea agregar nodos de Azure al clúster, el clúster de HPC se puede configurar en cualquier topología de red de clúster compatible con HPC Pack. El nodo principal y cualquier equipo cliente que se use para administrar el clúster y que necesite una conexión a Azure debe poder conectarse a través de Internet a los servicios de Azure.
1.8: Preparación de certificados usados para proteger la comunicación entre nodos de HPC
El clúster de Microsoft HPC Pack 2016 (y versiones posteriores) usa el certificado X.509 para proteger la comunicación entre los nodos de HPC. Puede usar un mismo certificado en todos los nodos de HPC o usar dos certificados diferentes:
- certificado para el nodo principal: este certificado se instala en el nodo principal (o nodos principales) para proteger el clúster de Service Fabric (si se usa para alta disponibilidad) y la comunicación entre nodos de HPC. Y si el certificado está autofirmado, también lo importará al certificado de Azure Key Vault si tiene previsto implementar nodos de proceso de IaaS de Azure con Ráfaga a máquina virtual iaaS de Azure característica.
- certificado para otros nodos: este certificado se instala en los nodos de HPC distintos del nodo principal (o nodos principales) para proteger la comunicación entre los nodos de HPC. Si decide usar un mismo certificado en todos los nodos de HPC, este es el mismo certificado con Certificado para el nodo principal.
Los certificados deben cumplir los siguientes requisitos:
- Tener una clave privada capaz de intercambiar claves;
- El uso de claves incluye firma digital, cifrado de claves, contrato de clave y firma de certificados;
- El uso mejorado de claves incluye de autenticación de cliente y de autenticación del servidor ;
- Si se usan dos certificados diferentes, deben tener un mismo nombre de sujeto.
Si el certificado se usa para proteger también clúster de Service Fabric, debe cumplir los siguientes requisitos requisitos adicionales:
- El proveedor del certificado debe ser Microsoft Enhanced RSA y AES Cryptographic Provider;
- La longitud de la clave RSA debe ser 2048 bits.
Si aún no tiene certificados que cumplan estos requisitos, puede solicitar los certificados de una entidad de certificación o, como alternativa, puede usar certificados autofirmados. Proporcionamos una herramienta de script de PowerShell CreateHpcCertificate.ps1 certificado en la carpeta setup del medio de instalación de HPC Pack para generar un certificado autofirmado.
.\CreateHpcCertificate.ps1 -CommonName "HPCPackNodeCommunication" -Path "d:\hpccomm.pfx" -Password (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force)
Si usa un certificado firmado por la entidad de certificación (CA) o un certificado autofirmado existente, puede ejecutar el siguiente comando y comprobar el valor de KeySpec, Subject, Key Usage, Enhanced Key Usage, Public Key Length, y Provider.
CertUtil.exe -p "<password>" -v -dump <path-of-pfxFile>
Si el valor de Subject, Key Usage, Enhanced Key Usage o Public Key Length no coincide, debe volver a generar el certificado.
Si el valor de keySpec (debe ser "1 AT_KEYEXCHANGE") o proveedor no coincide, No es necesario volver a generar el certificado, ejecute el siguiente comando para importar el certificado con modificados valores de KeySpec y Provider y, a continuación, ejecute certlm.msc para exportar el certificado (incluida la clave privada) a un nuevo archivo PFX que cumpla los requisitos.
CertUtil.exe -f -p "<password>" -csp "Microsoft Enhanced RSA and AES Cryptographic Provider" -importpfx "<path-of-pfxFile>" AT_KEYEXCHANGE
Si decidió usar un único nodo principal en el paso 1.2 y desea usar un certificado autofirmado, también puede generar un certificado autofirmado en el Asistente para la instalación durante la instalación del nodo principal.
Si decide usar un certificado autofirmado para otros nodos, puede generar un certificado autofirmado en el Administrador de clústeres de HPC en paso 3.4, más adelante en esta guía.
1.9: Preparación para la integración de herramientas de control de energía con script (opcional)
La consola de administración del clúster (Administrador de clústeres de HPC) incluye acciones para iniciar, apagar y reiniciar nodos de forma remota. Estas acciones están vinculadas a un archivo de script (CcpPower.cmd) que realiza estas operaciones de control de energía mediante comandos del sistema operativo. Puede reemplazar los comandos de sistema operativo predeterminados en ese archivo de script por sus propios scripts de control de energía, como scripts de Intelligent Platform Management Interface (IPMI) proporcionados por el proveedor de soluciones de clúster.
Para preparar esta integración, debe obtener todos los scripts, archivos .dll necesarios y otros componentes de las herramientas de control de energía. Después de haber obtenido todos los componentes necesarios, pruébelos de forma independiente y asegúrese de que funcionan según lo previsto en los equipos que va a implementar como nodos en el clúster.
Para obtener información sobre cómo modificar CcpPower.cmd para integrar sus propias herramientas de control de energía con script, consulte Apéndice 5: Herramientas de control de energía con script, más adelante en esta guía.