Partager via


Fonctionnement dans un réseau verrouillé

L’application CycleCloud et les nœuds de cluster peuvent fonctionner dans des environnements avec un accès Internet limité, même s’il existe un nombre minimal de ports TCP qui doivent rester ouverts.

Installation d’Azure CycleCloud dans un réseau verrouillé

La machine virtuelle CycleCloud doit être en mesure de se connecter à un certain nombre d’API Azure pour orchestrer des machines virtuelles de cluster et s’authentifier auprès d’Azure Active Directory. Étant donné que ces API utilisent HTTPS, CycleCloud nécessite un accès HTTPS sortant à :

  • management.azure.com (Gestion Azure ARM)
  • login.microsoftonline.com (Azure AD)
  • watson.telemetry.microsoft.com (Télémétrie 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 (Azure Price Data)

L’API de gestion est hébergée régionalement et les plages d’adresses IP publiques sont disponibles ici.

La connexion Azure AD fait partie des API courantes microsoft 365 et des plages d’adresses IP pour le service sont disponibles ici.

Les plages d’adresses IP Azure Insights et Log Analytics sont disponibles ici.

Azure CycleCloud doit être en mesure d’accéder aux comptes stockage Azure. La méthode recommandée pour fournir un accès privé à ce service et tout autre service Azure pris en charge est via Réseau virtuel points de terminaison de service.

Si vous utilisez des groupes de sécurité réseau ou des Pare-feu Azure pour limiter l’accès sortant aux domaines requis, il est possible de configurer Azure Cyclecloud pour acheminer toutes les requêtes via un proxy HTTPS. Voir : Utilisation d’un proxy web

Configuration d’un groupe de sécurité réseau Azure pour la machine virtuelle CycleCloud

Une façon de limiter l’accès Internet sortant à partir de la machine virtuelle CycleCloud sans configurer le Pare-feu Azure ou un proxy HTTPS consiste à configurer un groupe de sécurité réseau Azure strict pour le sous-réseau de la machine virtuelle CycleCloud. Le moyen le plus simple d’utiliser des balises de service dans le sous-réseau ou le groupe de sécurité réseau au niveau de la machine virtuelle pour autoriser l’accès Azure sortant requis.

  1. Configurer un point de terminaison de service de stockage pour le sous-réseau pour autoriser l’accès de CycleCloud à Stockage Azure

  2. Ajoutez la règle de trafic sortant NSG suivante pour refuser l’accès sortant par défaut à l’aide de la balise de service de destination « Internet » :

Priority Nom Port Protocol Source Destination Action
4000 Bloquer le trafic sortant Quelconque Quelconque Quelconque Internet Deny
  1. Ajoutez les règles de trafic sortant NSG suivantes pour autoriser l’accès sortant aux services Azure requis par balise de service de destination :
Priority Nom Port Protocol Source Destination Action
100 AllowAzureStorage 443 TCP Quelconque Stockage Allow
101 AllowActiveDirectory 443 TCP Quelconque AzureActiveDirectory Allow
102 AllowAzureMonitor 443 TCP Quelconque AzureMonitor Autoriser
103 AllowAzureRM 443 TCP Quelconque AzureResourceManager Autoriser

Communications internes entre les nœuds de cluster et CycleCloud

Ces ports doivent être ouverts pour permettre la communication entre les nœuds de cluster et le serveur CycleCloud :

Nom Source Destination Service Protocol Plage de ports
amqp_5672 Nœud de clusters CycleCloud AMQP TCP 5672
https_9443 Nœud de clusters CycleCloud HTTPS TCP 9443

Lancement de clusters Azure CycleCloud dans un réseau verrouillé

Notes

L’exécution de nœuds de cluster dans un sous-réseau sans accès Internet sortant est entièrement prise en charge aujourd’hui, mais il s’agit d’une rubrique avancée qui nécessite souvent une image personnalisée ou une personnalisation des types et projets cycleCloud par défaut ou les deux.

Nous mettons activement à jour les types de cluster et les projets pour éliminer la plupart ou l’ensemble de ces travaux. Toutefois, si vous rencontrez des échecs avec votre type de cluster ou projet dans votre environnement verrouillé, envisagez d’ouvrir une demande de support pour obtenir de l’aide.

L’exécution de machines virtuelles ou de clusters Cyclecloud dans un réseau virtuel ou un sous-réseau disposant d’un accès Internet sortant nécessite généralement les éléments suivants :

  1. Azure Cyclecloud doit être accessible à partir des machines virtuelles de cluster pour une fonctionnalité complète. Un des deux éléments suivants :
    1. Les machines virtuelles de cluster doivent être en mesure de se connecter directement à Azure Cyclecloud via HTTPS et AMQP, ou
    2. La fonctionnalité Cyclecloud ReturnProxy doit être activée au moment de la création du cluster et Cyclecloud elle-même doit être en mesure de se connecter à la machine virtuelle ReturnProxy via SSH
  2. Tous les packages logiciels requis par le cluster doivent être :
    1. Préinstallé dans une image managée personnalisée pour les machines virtuelles de cluster ou
    2. Disponible dans un miroir de référentiels de package accessible à partir des machines virtuelles ou
    3. Copié vers la machine virtuelle à partir du stockage Azure et installé directement par un projet Cyclecloud
  3. Tous les nœuds de cluster doivent pouvoir accéder aux comptes stockage Azure. La méthode recommandée pour fournir un accès privé à ce service et tout autre service Azure pris en charge consiste à activer un point de terminaison de service Réseau virtuel pour stockage Azure.

Projet Mises à jour à partir de GitHub

Cyclecloud télécharge les projets de cluster à partir de GitHub pendant la phase d’orchestration « Intermédiaire ». Ce téléchargement se produit après l’installation initiale, après la mise à niveau de Cyclecloud ou lors du démarrage d’un cluster d’un certain type pour la première fois. Dans un environnement verrouillé, le trafic sortant HTTPS vers github.com peut être bloqué. Dans ce cas, la création de nœud pendant la phase de ressources intermédiaires échoue.

Si l’accès à GitHub peut être ouvert temporairement pendant la création du premier nœud, CycleCloud prépare les fichiers locaux pour tous les nœuds suivants. Si l’accès temporaire n’est pas possible, les fichiers nécessaires peuvent être téléchargés à partir d’un autre ordinateur et copiés sur CycleCloud.

Commencez par déterminer le projet et la version dont votre cluster aura besoin, par exemple Slurm 2.5.0. Il s’agit normalement du numéro de version le plus élevé dans la base de données d’un projet donné.

/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"

Cette version de projet et toutes les dépendances sont trouvées dans la [balise de mise en production] (https://github.com/Azure/cyclecloud-slurm/releases/tag/2.5.0). Tous les artefacts d’une version doivent être téléchargés. Commencez par télécharger l’artefact de code et créez un répertoire d’objets blob pour les dépendances supplémentaires.

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

Une fois que ces fichiers ont été intermédiaires, Cyclecloud les détecte et n’essaieront pas de les télécharger à partir de GitHub.