Funcionamiento en una red bloqueada
La aplicación CycleCloud y los nodos de clúster 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 una serie de API de Azure para orquestar máquinas virtuales de 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 Azure ARM)
- login.microsoftonline.com (Azure AD)
- watson.telemetry.microsoft.com (telemetría de Azure)
- dc.applicationinsights.azure.com (Azure Application Insights)
- dc.applicationinsights.microsoft.com (Azure Application Insights)
- dc.services.visualstudio.com (Azure Application 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í.
Puede encontrar los intervalos de direcciones IP de Azure Insights y Log Analytics aquí.
Azure CycleCloud debe 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 a través de puntos de conexión de servicio de red virtual.
Si usa grupos de seguridad de red o 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 de 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 Azure Firewall o un proxy HTTPS es configurar un grupo estricto de seguridad de red de Azure para la subred de la máquina virtual cycleCloud. La manera más sencilla de hacerlo es usar etiquetas de servicio en el nivel de subred o máquina virtual grupo de seguridad de red para permitir el acceso de salida de Azure necesario.
Configuración de un de punto de conexión de servicio de almacenamiento de
para la subred para permitir el acceso desde CycleCloud a Azure Storage Agregue la siguiente regla de salida de NSG para denegar acceso saliente de forma predeterminada mediante la etiqueta de servicio de destino "Internet" destination:
| Prioridad | Nombre | Puerto | Protocolo | Fuente | Destino | Acción |
|---|---|---|---|---|---|---|
| 4000 | BlockOutbound | Cualquier | Cualquier | Cualquier | Internet | Negar |
- Agregue las siguientes reglas de salida de NSG a Permitir el acceso de salida a los servicios de Azure necesarios por etiqueta de servicio de destino:
| Prioridad | Nombre | Puerto | Protocolo | Fuente | Destino | Acción |
|---|---|---|---|---|---|---|
| 100 | AllowAzureStorage | 443 | TCP | Cualquier | Almacenamiento | Conceder |
| 101 | AllowActiveDirectory | 443 | TCP | Cualquier | AzureActiveDirectory | Conceder |
| 102 | AllowAzureMonitor | 443 | TCP | Cualquier | AzureMonitor | Conceder |
| 103 | AllowAzureRM | 443 | TCP | Cualquier | AzureResourceManager | Conceder |
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 | Fuente | Destino | 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 a Internet saliente es totalmente compatible hoy en día, 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 de clúster y los proyectos para eliminar la mayoría o todo ese trabajo. Sin embargo, si se producen 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 suele requerir lo siguiente:
- Azure Cyclecloud debe ser accesible desde las máquinas virtuales del clúster para una funcionalidad completa. Cualquiera de los dos:
- Las máquinas virtuales de clúster deben poder conectarse a Azure Cyclecloud directamente a través de HTTPS y AMQP, o bien
- La característica Cyclecloud ReturnProxy debe estar habilitada en el momento de creación del clúster y Cyclecloud en sí 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 por 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 red virtual para Azure Storage.
Actualizaciones de proyectos desde GitHub
Cyclecloud descargará proyectos de clúster de GitHub durante la fase de orquestación "Staging". 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 3.0.8. Normalmente es el número de versión más alto de la base de datos de un proyecto determinado. Puede determinar la versión más reciente visitando la página del proyecto de GitHub o consultando CycleCloud para obtener la versión más reciente.
Para consultar CycleCloud (tenga en cuenta que a menudo habrá varias versiones enumeradas):
/opt/cycle_server/cycle_server execute 'select Name, Version, Url from cloud.project where name == "slurm" order by Version'
Name = "slurm"
Version = "3.0.8"
Url = "https://github.com/Azure/cyclecloud-slurm/releases/3.0.8"
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/3.0.8).
Puede descargar todos los artefactos de versión manualmente, pero la CLI de CycleCloud proporciona un asistente para esta operación.
En primer lugar, use la CLI de CycleCloud para capturar y preparar el repositorio desde github (esta es la misma operación que CycleCloud realiza durante la fase "Recursos de almacenamiento provisional"):
RELEASE_URL="https://github.com/Azure/cyclecloud-slurm/releases/3.0.8"
RELEASE_VERSION="3.0.8"
mkdir "${RELEASE_VERSION}"
cd "${RELEASE_VERSION}"
# Download release artifacts from githug (on a machine with github access)
cyclecloud project fetch "${RELEASE_URL}" .
# Create a tarbal with the project files pre-staged
cyclecloud project build
mv ./build/slurm "./${RELEASE_VERSION}"
tar czf "slurm-${RELEASE_VERSION}.tgz" ./blobs "./${RELEASE_VERSION}"
A continuación, copie el tarball del proyecto empaquetado en el servidor CycleCloud y extraiga:
#... copy the "slurm-${RELEASE_VERSION}.tgz" file to the Cyclecloud server in /tmp
sudo -i
mkdir -p /opt/cycle_server/work/staging/projects/slurm
cd /opt/cycle_server/work/staging/projects/slurm
tar xzf "/tmp/slurm-${RELEASE_VERSION}.tgz"
chown -R cycle_server:cycle_server /opt/cycle_server/work/staging
Una vez almacenados provisionalmente estos archivos en Cyclecloud localmente, los detectará y no intentará descargarlos desde GitHub.