Funcionamiento en una red bloqueada
Los nodos de clúster y aplicación CycleCloud pueden funcionar en entornos con acceso limitado a Internet, aunque hay un número mínimo de puertos TCP que deben permanecer abiertos.
Instalación de Azure CycleCloud en una red bloqueada
La máquina virtual CycleCloud debe poder conectarse a varias API de Azure para orquestar las máquinas virtuales del clúster y autenticarse en Azure Active Directory. Dado que estas API usan HTTPS, CycleCloud requiere acceso HTTPS saliente a:
- management.azure.com (Administración de Arm de Azure)
- login.microsoftonline.com (Azure AD)
- watson.telemetry.microsoft.com (telemetría de Azure)
- dc.applicationinsights.azure.com (Aplicación de Azure Insights)
- dc.applicationinsights.microsoft.com (Aplicación de Azure Insights)
- dc.services.visualstudio.com (Aplicación de Azure Insights)
- ratecard.azure-api.net (datos de precios de Azure)
La API de administración se hospeda de forma regional y los intervalos de direcciones IP públicas se pueden encontrar aquí.
El inicio de sesión de Azure AD forma parte de las API comunes de Microsoft 365 y los intervalos de direcciones IP para el servicio se pueden encontrar aquí.
Los intervalos de direcciones IP de Azure Insights y Log Analytics se pueden encontrar aquí.
Azure CycleCloud debe ser capaz de acceder a las cuentas de Azure Storage. La manera recomendada de proporcionar acceso privado a este servicio y cualquier otro servicio de Azure admitido es a través de Virtual Network puntos de conexión de servicio.
Si usa grupos de seguridad de red o el Azure Firewall para limitar el acceso saliente a los dominios necesarios, es posible configurar Azure Cyclecloud para enrutar todas las solicitudes a través de un proxy HTTPS. Consulte: Uso de un proxy web
Configuración de un grupo de seguridad de red de Azure para la máquina virtual CycleCloud
Una manera de limitar el acceso saliente a Internet desde la máquina virtual CycleCloud sin configurar el Azure Firewall o un proxy HTTPS es configurar un grupo de seguridad de red de Azure estricto para la subred de la máquina virtual de CycleCloud. La manera más sencilla de hacerlo es usar etiquetas de servicio en la subred o en el grupo de seguridad de red de nivel de máquina virtual para permitir el acceso saliente de Azure necesario.
Configuración de un punto de conexión de servicio de almacenamiento para la subred para permitir el acceso desde CycleCloud a Azure Storage
Agregue la siguiente regla de salida de NSG a Denegar el acceso saliente de forma predeterminada mediante la etiqueta de servicio de destino "Internet":
| Priority | Nombre | Port | Protocolo | Source | Destination | Acción |
|---|---|---|---|---|---|---|
| 4000 | BlockOutbound | Any | Any | Any | Internet | Denegar |
- Agregue las siguientes reglas de salida de NSG para permitir el acceso saliente a los servicios de Azure necesarios por etiqueta de servicio de destino:
| Priority | Nombre | Port | Protocolo | Source | Destination | Acción |
|---|---|---|---|---|---|---|
| 100 | AllowAzureStorage | 443 | TCP | Any | Almacenamiento | Allow |
| 101 | AllowActiveDirectory | 443 | TCP | Any | AzureActiveDirectory | Allow |
| 102 | AllowAzureMonitor | 443 | TCP | Any | AzureMonitor | Allow |
| 103 | AllowAzureRM | 443 | TCP | Any | AzureResourceManager | Allow |
Comunicaciones internas entre nodos de clúster y CycleCloud
Estos puertos deben estar abiertos para permitir la comunicación entre los nodos del clúster y el servidor CycleCloud:
| Nombre | Source | Destination | Servicio | Protocolo | Intervalo de puertos |
|---|---|---|---|---|---|
| amqp_5672 | Nodo de clúster | CycleCloud | AMQP | TCP | 5672 |
| https_9443 | Nodo de clúster | CycleCloud | HTTPS | TCP | 9443 |
Inicio de clústeres de Azure CycleCloud en una red bloqueada
Nota
La ejecución de nodos de clúster en una subred sin acceso saliente a Internet es totalmente compatible actualmente, pero es un tema avanzado que a menudo requiere una imagen personalizada o una personalización de los tipos de clúster y proyectos predeterminados de CycleCloud o ambos.
Estamos actualizando activamente los tipos y proyectos de clúster para eliminar la mayoría o todo ese trabajo. Sin embargo, si encuentra errores con el tipo de clúster o el proyecto en el entorno bloqueado, considere la posibilidad de abrir una solicitud de soporte técnico para obtener ayuda.
La ejecución de máquinas virtuales o clústeres de Cyclecloud en una red virtual o subred con acceso saliente a Internet normalmente requiere lo siguiente:
- Azure Cyclecloud debe ser accesible desde las máquinas virtuales del clúster para obtener una funcionalidad completa. Tener instaladas localmente una de las siguientes:
- Las máquinas virtuales de clúster deben poder conectarse directamente a Azure Cyclecloud a través de HTTPS y AMQP, o
- La característica Cyclecloud ReturnProxy debe estar habilitada en el momento de creación del clúster y Cyclecloud debe poder conectarse a la máquina virtual ReturnProxy a través de SSH.
- Todos los paquetes de software requeridos por el clúster deben ser:
- Preinstalado en una imagen administrada personalizada para las máquinas virtuales del clúster o
- Disponible en un reflejo del repositorio de paquetes accesible desde las máquinas virtuales o
- Copiado en la máquina virtual desde Azure Storage e instalado directamente mediante un proyecto cyclecloud
- Todos los nodos de clúster deben poder acceder a las cuentas de Azure Storage. La manera recomendada de proporcionar acceso privado a este servicio y cualquier otro servicio de Azure compatible es habilitar un punto de conexión de servicio de Virtual Network para Azure Storage.
Project Novedades desde GitHub
Cyclecloud descargará proyectos de clúster de GitHub durante la fase de orquestación de "ensayo". Esta descarga se producirá después de la instalación inicial, después de actualizar Cyclecloud, o al iniciar un clúster de un tipo determinado por primera vez. En un entorno bloqueado, es posible que se bloquee el tráfico saliente HTTPS a github.com . En tal caso, se producirá un error en la creación de nodos durante la fase de recursos de almacenamiento provisional.
Si el acceso a GitHub se puede abrir temporalmente durante la creación del primer nodo, CycleCloud preparará los archivos locales para todos los nodos posteriores. Si el acceso temporal no es posible, los archivos necesarios se pueden descargar de otra máquina y copiarlos en CycleCloud.
En primer lugar, determine qué proyecto y versión necesitará el clúster, por ejemplo, Slurm 2.5.0. Normalmente es el número de versión más alto de la base de datos para un proyecto determinado.
/opt/cycle_server/cycle_server execute 'select * from cloud.project where name == "slurm"'
AdType = "Cloud.Project"
Version = "2.5.0"
ProjectType = "scheduler"
Url = "https://github.com/Azure/cyclecloud-slurm/releases/2.5.0"
AutoUpgrade = false
Name = "slurm"
Esta versión del proyecto y todas las dependencias se encuentran en la [etiqueta de versión] (https://github.com/Azure/cyclecloud-slurm/releases/tag/2.5.0). Todos los artefactos de una versión deben descargarse. Primero descargue el artefacto de código y cree un directorio de blobs para las dependencias adicionales.
wget https://github.com/Azure/cyclecloud-slurm/archive/refs/tags/2.5.0.tar.gz
tar -xf 2.5.0.tar.gz
cd cyclecloud-slurm-2.5.0 && mkdir blobs
#... download all other release artifacts to the /blobs directory with wget ...
wget -P "blobs/" https://github.com/Azure/cyclecloud-slurm/releases/download/2.6.1/cyclecloud_api-8.1.0-py2.py3-none-any.whl
#... copy all the files to the Cyclecloud server
#... then on the Cyclecloud server:
cyclecloud project build
mkdir -p /opt/cycle_server/work/staging/projects/slurm/2.5.0
mkdir -p /opt/cycle_server/work/staging/projects/slurm/blobs
cp build/slurm/* /opt/cycle_server/work/staging/projects/slurm/2.5.0/
cp blobs/* /opt/cycle_server/work/staging/projects/slurm/blobs/
chown -R cycle_server:cycle_server /opt/cycle_server/work/staging
Una vez que estos archivos se hayan almacenado provisionalmente en Cyclecloud localmente, los detectará y no intentará descargarlos desde GitHub.