Usługa Azure CycleCloud i łączność klastra

Węzły w klastrze muszą komunikować się z serwerem Azure CycleCloud w celu wykonywania działań, takich jak monitorowanie, raportowanie stanu, synchronizacja usług i skalowanie automatyczne. Protokoły HTTPS i AMQP są używane z domyślnymi portami TCP (odpowiednio 443 i 5672).

Jeśli serwer Azure CycleCloud jest wdrażany w tej samej sieci wirtualnej co klaster obliczeniowy, zwykle spełniasz wymagania dotyczące łączności. Jeśli jednak topologia sieci lub zapory blokują bezpośrednią komunikację, rozważ następujące alternatywy:

• Wyznaczanie zwrotnego serwera proxy
• Konfiguracja peeringu sieci wirtualnych

W przypadku instalacji, w których jest zainstalowany lokalny serwer aplikacji CycleCloud:

• Połączenie VPN
• Serwer bastionu

Konfigurowanie zwrotnego serwera proxy

Jeśli topologia sieci lub zapory uniemożliwiają komunikację między serwerem Azure CycleCloud i węzłami klastra, możesz wyznaczyć węzeł w klastrze jako zwrotny serwer proxy. Dzięki tej konfiguracji porty nasłuchiwania na serwerze Azure CycleCloud są przekazywane za pośrednictwem tunelu SSH. Węzły klastra docierają do serwera CycleCloud za pośrednictwem portów 37140 i 37141 na serwerze proxy. Typowe wdrożenie ma węzeł główny klastra wyznaczony jako serwer proxy dla żądań zwrotnych, ale każdy węzeł stały może pełnić tę samą rolę.

Aby uzyskać więcej informacji na temat konfigurowania zwrotnego serwera proxy, zobacz Zwracany serwer proxy.

Peerowanie sieci wirtualnej

Komunikacja równorzędna sieci wirtualnych umożliwia łączenie sieci wirtualnych platformy Azure. Po utworzeniu połączenia sieci wirtualne działają jak jedna całość dla celów łączności. Ruch między maszynami wirtualnymi w równorzędnych sieciach wirtualnych jest kierowany przez infrastrukturę szkieletową firmy Microsoft. Podobnie jak ruch kierowany między maszynami wirtualnymi w tej samej sieci wirtualnej, ruch jest kierowany tylko za pośrednictwem prywatnych adresów IP.

Aby uzyskać instrukcje dotyczące konfigurowania peeringu sieci wirtualnych, odwiedź stronę dokumentacji Azure Virtual Network.

VPN

Jeśli wdrożysz serwer Usługi Azure CycleCloud w sieci wewnętrznej, użyj tej metody, aby włączyć łączność między serwerem aplikacji a węzłami klastra. Serwer Azure CycleCloud może bezpośrednio uzyskiwać dostęp do węzłów klastra w sieci wirtualnej platformy Azure.

Aby uzyskać informacje o tworzeniu połączenia między platformą Azure i siecią VPN, zobacz dokumentację połączenia typu lokacja-lokacja (lub odpowiednią dokumentację dostawcy usług w chmurze).

Serwer bastionu

Poza połączeniem sieci firmowej bezpośrednio z konfiguracją wirtualną najlepszym rozwiązaniem jest utworzenie serwera zewnętrznego (nazywanego również serwerem bastionu lub serwerem przesiadkowym) z publicznie dostępnym statycznym adresem IP. Platforma Azure udostępnia kilka scenariuszy w dokumentacji najlepszych rozwiązań dotyczących zabezpieczeń sieci . Wybierz scenariusz, który najlepiej sprawdza się w twoim środowisku.

Węzeł proxy

Zamiast używać dedykowanego serwera bastionu, można skonfigurować jeden z węzłów w klastrze tak, aby działał jako serwer proxy komunikacji z powrotem do usługi Azure CycleCloud. Aby użyć tej opcji, skonfiguruj podsieć publiczną, aby automatycznie przypisywać publiczne adresy IP.

[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

Węzeł proxy w tym szablonie klastra służy jedynie jako proxy dla komunikacji między węzłami a platformą CycleCloud. Nie pośredniczy w komunikacji z większym Internetem.