Conectividad de Clúster y Azure CycleCloud

Los nodos de un clúster deben comunicarse con el servidor de Azure CycleCloud para actividades como la supervisión, los informes de estado, la sincronización del servicio y el escalado automático. Los protocolos HTTPS y AMQP se usan con los puertos TCP predeterminados (443 y 5672 respectivamente).

Si el servidor de Azure CycleCloud se implementa en la misma red virtual que el clúster de proceso, normalmente se cumplen los requisitos de conectividad anteriores. Sin embargo, en las implementaciones en las que la topología de red o los firewalls bloquean esta comunicación directa, hay varias alternativas:

• Designar un proxy de devolución
• Configuración del emparejamiento de VNET

Para las instalaciones en las que el servidor de aplicaciones cycleCloud está instalado localmente:

• Conexión VPN
• Servidor bastión

Configuración de un proxy de devolución

Si la topología de red o los firewalls impiden la comunicación entre el servidor de Azure CycleCloud y los nodos de clúster, se puede designar un nodo del clúster como proxy de retorno con los puertos de escucha en el servidor de Azure CycleCloud reenviado a través de un túnel SSH. A continuación, los nodos del clúster llegarán al servidor CycleCloud a través de los puertos 37140 y 37141 en el proxy. Una implementación típica tiene el nodo principal del clúster designado como proxy de devolución, pero cualquier nodo persistente puede desempeñar ese mismo rol.

Puede encontrar más información sobre cómo configurar el proxy de devolución en esta página.

Emparejamiento de VNET

El emparejamiento de redes virtuales permite conectar sin problemas redes virtuales de Azure. Una vez emparejadas, a efectos de conectividad las redes virtuales aparecen como una sola. El tráfico entre las máquinas virtuales de las redes virtuales emparejadas se enruta a través de la infraestructura de la red troncal de Microsoft, de forma muy parecida a como se enruta el tráfico entre máquinas virtuales de la misma red virtual a través únicamente de direcciones IP privadas.

La página de documentación de Azure Virtual Network incluye instrucciones para establecer el emparejamiento de VNET.

VPN

Si el servidor de Azure CycleCloud se implementa dentro de la red interna, este es el método más sencillo y recomendado para habilitar la conectividad entre el servidor de aplicaciones y los nodos del clúster. Los nodos de clúster dentro del Virtual Network de Azure podrán acceder directamente al servidor de Azure CycleCloud.

Para crear una conexión entre Azure y la VPN, consulte la documentación conexión de sitio a sitio (o la documentación adecuada para el proveedor de nube).

Servidor bastión

Fuera de conectar la red corporativa directamente a la configuración virtual, la siguiente mejor opción es crear un servidor externo (también denominado servidor bastión o jumpbox) con una dirección IP estática accesible públicamente. Azure proporciona varios escenarios diferentes en su documentación sobre procedimientos recomendados de seguridad de red : elija el que mejor funcione para su entorno concreto.

Nodo proxy

En lugar de usar un servidor bastión dedicado, también puede configurar uno de los nodos del clúster para que actúe como proxy para comunicarse con Azure CycleCloud. Para que esto funcione, deberá configurar la subred pública para asignar automáticamente direcciones IP públicas:

[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

Tenga en cuenta que proxy el nodo de esta plantilla de clúster solo comunica los servidores proxy desde los nodos a CycleCloud. No proxy la comunicación a Internet más grande.