Connectivité Azure CycleCloud et Cluster

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 des services 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 vous déployez le serveur Azure CycleCloud dans le même réseau virtuel que le cluster de calcul, vous répondez généralement aux exigences de connectivité. Toutefois, si votre topologie de réseau ou vos pare-feu bloquent la communication directe, tenez compte des alternatives suivantes :

• Désigner un proxy de retour
• Configurer le peering des 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, vous pouvez désigner un nœud dans le cluster comme proxy de retour. Avec cette configuration, les ports d’écoute sur le serveur Azure CycleCloud sont transférés via un tunnel SSH. Les nœuds de cluster atteignent 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 Proxy de retour.

Appairage de réseaux virtuels

L’appairage de réseaux virtuels permet de connecter des réseaux virtuels Azure. Une fois homologués, les réseaux virtuels apparaissent comme un seul réseau à toutes fins de connectivité. Le trafic entre les machines virtuelles dans les réseaux virtuels appairés est acheminé via l'infrastructure principale de Microsoft. Comme le trafic routé entre les machines virtuelles du même réseau virtuel, le trafic est acheminé via des adresses IP privées uniquement.

Pour obtenir des instructions sur la configuration du peering de réseaux virtuels, consultez la page de documentation du réseau virtuel Azure.

VPN

Si vous déployez votre serveur Azure CycleCloud au sein de votre réseau interne, utilisez cette méthode pour activer la connectivité entre le serveur d’applications et les nœuds de cluster. Votre serveur Azure CycleCloud peut atteindre directement des nœuds de cluster à l’intérieur du réseau virtuel Azure.

Pour plus d’informations sur la création d’une connexion entre Azure et votre VPN, consultez la documentation sur la connexion de site à site (ou la documentation appropriée pour votre fournisseur de cloud).

Serveur Bastion

En dehors de connecter votre réseau d’entreprise directement à votre configuration virtuelle, la meilleure option consiste à créer un serveur externe (également appelé serveur bastion ou jump box) avec une adresse IP statique accessible publiquement. Azure fournit plusieurs scénarios dans la documentation relative aux meilleures pratiques de sécurité réseau . Choisissez le scénario qui convient le mieux à votre environnement.

Nœud proxy

Au lieu d’utiliser un serveur bastion dédié, vous pouvez configurer l’un des nœuds de votre cluster pour qu’il agisse comme proxy pour communiquer avec Azure CycleCloud. Pour utiliser cette option, configurez le sous-réseau public pour attribuer 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

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