Partager via

Connectivité azure Cyclecloud et cluster

  • Article

Les nœuds d’un cluster doivent communiquer avec le serveur Azure CycleCloud pour les activités telles que la surveillance, la création de rapports d’état, la synchronisation de service et la mise à l’échelle automatique. Les protocoles HTTPS et AMQP sont utilisés avec les ports TCP par défaut (443 et 5672 respectivement).

Si le serveur Azure CycleCloud est déployé dans le même réseau virtuel que le cluster de calcul, les exigences de connectivité ci-dessus sont généralement remplies. Toutefois, dans les déploiements où la topologie réseau ou les pare-feu bloquent ces communications directes, il existe plusieurs alternatives :

  • Désigner un proxy de retour
  • Configurer le peering de réseaux virtuels

Pour les installations où le serveur d’applications CycleCloud est installé localement :

  • Connexion VPN
  • Serveur Bastion

Configuration d’un proxy de retour

Si la topologie réseau ou les pare-feu empêchent la communication entre le serveur Azure CycleCloud et les nœuds de cluster, un nœud du cluster peut être désigné comme proxy de retour avec les ports d’écoute sur le serveur Azure CycleCloud transférés via un tunnel SSH. Les nœuds de cluster atteignent ensuite le serveur CycleCloud via les ports 37140 et 37141 sur le proxy. Un déploiement classique a le nœud principal du cluster désigné comme proxy de retour, mais tout nœud persistant peut jouer ce même rôle.

Pour plus d’informations sur la configuration du proxy de retour, consultez cette page

VNET Peering

Le Peering d’un réseau virtuel vous permet de connecter des réseaux virtuels Azure en toute transparence. Une fois homologués, les réseaux virtuels apparaissent comme un seul réseau à des fins de connectivité. Le trafic entre les machines virtuelles des réseaux virtuels appairés est acheminé via l’infrastructure principale de Microsoft de façon assez semblable au trafic entre des machines virtuelles d’un même réseau virtuel via des IP privées seulement.

La page de documentation d’Azure Réseau virtuel inclut des instructions pour définir le peering de réseaux virtuels.

VPN

Si votre serveur Azure CycleCloud est déployé dans votre réseau interne, il s’agit de la méthode la plus simple et recommandée pour activer la connectivité entre le serveur d’applications et les nœuds de cluster. Les nœuds de cluster à l’intérieur d’Azure Réseau virtuel seront ensuite directement accessibles par votre serveur Azure CycleCloud.

Pour créer une connexion entre Azure et votre VPN, reportez-vous à la documentation de connexion de site à site (ou à la documentation appropriée pour votre fournisseur de cloud).

Serveur Bastion

En dehors de la connexion de votre réseau d’entreprise directement à votre configuration virtuelle, la meilleure option consiste à créer un serveur externe (également appelé serveur bastion ou zone de saut) avec une adresse IP statique accessible publiquement. Azure fournit plusieurs scénarios différents dans leur documentation relative aux meilleures pratiques de sécurité réseau : choisissez celui qui fonctionne le mieux pour votre environnement particulier.

Nœud proxy

Au lieu d’utiliser un serveur bastion dédié, vous pouvez également configurer l’un des nœuds de votre cluster pour agir comme proxy pour communiquer avec Azure CycleCloud. Pour que cela fonctionne, vous devez configurer le sous-réseau public pour affecter automatiquement des adresses IP publiques :

[cluster htcondor]
  [[node proxy]]
  # this attribute configures the node to act as a proxy
  IsReturnProxy = true
  credentials = cloud
  MachineType = Standard_A1
  # this is the public subnet
  subnetid = /ResourceGroupName/VnetName/PublicSubnetName
  ImageName = cycle.image.centos7

  [[node private]]
  # this is the private subnet
  subnetid = /ResourceGroupName/VnetName/PrivatebnetName

Notez que le proxy nœud de ce modèle de cluster ne communique que entre nœuds et CycleCloud. Il ne proxy pas la communication vers l’Internet plus grand.