Konfigurowanie subskrypcji platformy Azure

Aby uruchomić usługę Azure CycleCloud, potrzebujesz prawidłowej subskrypcji platformy Azure i sieci wirtualnej.

Ogólnie rzecz biorąc, osoby podejmujące decyzje biznesowe zajmują się tworzeniem i konfigurowaniem dzierżaw i subskrypcji Azure. Jednak ze względu na to, że aplikacje HPC (obliczenia wysokowydajne) i wymagające duże obliczenia korzystają z wielu zasobów, rozważ utworzenie dedykowanej subskrypcji w celu śledzenia rozliczeń, ustalania limitów użycia oraz izolowania wykorzystania zasobów i interfejsu API. Aby uzyskać więcej informacji na temat projektowania dzierżawy i subskrypcji platformy Azure, zobacz Zarządzanie subskrypcjami platformy Azure.

Konfigurowanie sieci wirtualnej

Wybierz istniejącą sieć wirtualną platformy Azure i podsieci lub utwórz nową sieć wirtualną, aby uruchomić maszynę wirtualną CycleCloud i klastry obliczeniowe zarządzane przez usługę CycleCloud.

Jeśli sieć wirtualna nie została jeszcze utworzona, rozważ rozpoczęcie od podanego wdrożenia szablonu usługi ARM CycleCloud. Szablon usługi ARM CycleCloud tworzy nową sieć wirtualną dla aplikacji CycleCloud i klastrów obliczeniowych podczas wdrażania. Alternatywnie możesz postępować zgodnie z tymi instrukcjami, aby utworzyć nową sieć wirtualną.

Następnie, jeśli nie skonfigurowaliśmy jeszcze usługi Express Route lub sieci VPN dla sieci wirtualnej, możesz nawiązać połączenie z siecią wirtualną za pośrednictwem publicznego Internetu. Zdecydowanie zalecamy jednak skonfigurowanie bramy sieci VPN.

Konfigurowanie podsieci i sieciowej grupy zabezpieczeń

Ponieważ usługa CycleCloud zazwyczaj ma inne wymagania dotyczące zabezpieczeń sieci i zasady dostępu niż klastry obliczeniowe, często dobrym rozwiązaniem jest uruchomienie usługi Azure CycleCloud w innej podsieci platformy Azure niż klastry.

Zalecanym najlepszym rozwiązaniem jest użycie co najmniej dwóch podsieci — jednej dla maszyny wirtualnej CycleCloud i innych maszyn wirtualnych z tymi samymi zasadami dostępu oraz dodatkowych podsieci dla klastrów obliczeniowych. Należy jednak pamiętać, że w przypadku dużych klastrów zakres adresów IP podsieci może stać się czynnikiem ograniczającym. Ogólnie rzecz biorąc, podsieć CycleCloud powinna używać małego zakresu CIDR, a podsieci obliczeniowe powinny być duże.

Aby utworzyć co najmniej jedną podsieć w sieci wirtualnej, postępuj zgodnie z instrukcjami w połączonym artykule.

Używanie wielu podsieci na potrzeby obliczeń

Klastry CycleCloud można skonfigurować tak, aby uruchamiały węzły i tablice węzłów w wielu podsieciach, o ile wszystkie maszyny wirtualne mogą komunikować się w klastrze i z usługą CycleCloud (być może za pośrednictwem zwrotnego serwera proxy). Na przykład często przydatne jest uruchomienie węzła harmonogramu lub węzłów przesyłania w podsieci, która ma inne reguły zabezpieczeń niż te stosowane dla węzłów wykonywania. Domyślne typy klastrów w usłudze CycleCloud zakładają pojedynczą podsieć dla całego klastra, ale można skonfigurować podsieć dla każdego węzła lub tablicy węzłów przy użyciu SubnetId atrybutu w szablonie węzła.

Jednak domyślne rozpoznawanie nazw hostów oparte na pliku hosts, stosowane w klastrach CycleCloud, generuje tylko plik hosts dla podsieci węzła. Dlatego podczas tworzenia klastra obejmującego wiele podsieci należy dostosować rozpoznawanie nazw hostów dla klastra.

Aby obsługiwać wiele podsieci obliczeniowych, należy wprowadzić dwie podstawowe zmiany szablonu klastra:

1. SubnetId Ustaw atrybut w każdej tablicy węzłów lub węzła, która nie znajduje się w domyślnej podsieci klastra.
2. Skonfiguruj rozpoznawanie nazw hostów dla wszystkich podsieci według jednego z następujących elementów:
   • Używanie strefy DNS platformy Azure i wyłączanie domyślnego rozwiązywania opartego na pliku hostów
   • Ustawienie atrybutu CycleCloud.hosts.standalone_dns.subnets na zakres CIDR dla sieci wirtualnej (VNet) albo na listę zakresów CIDR, rozdzieloną przecinkami, dla każdej podsieci. Aby uzyskać szczegółowe informacje, zobacz dokumentację konfiguracji węzła .

Ustawienia sieciowej grupy zabezpieczeń dla podsieci CycleCloud

Konfigurowanie sieci wirtualnej platformy Azure pod kątem zabezpieczeń jest szerokim tematem wykraczającym poza zakres tego dokumentu.

Klastry CycleCloud i CycleCloud mogą działać w zablokowanych środowiskach. Aby uzyskać szczegółowe informacje o konfiguracji, zobacz Running in Locked Down Networks (Uruchamianie w zablokowanych sieciach) i Running behind a Proxy (Uruchamianie za serwerem proxy).

Jednak w przypadku mniej restrykcyjnych sieci postępuj zgodnie z tymi ogólnymi wytycznymi. Najpierw użytkownicy graficznego interfejsu użytkownika usługi CycleCloud muszą mieć dostęp do maszyny wirtualnej CycleCloud za pośrednictwem protokołu HTTPS, a administratorzy mogą potrzebować dostępu SSH. Użytkownicy klastra zwykle potrzebują dostępu SSH do co najmniej węzłów przesyłania w klastrach obliczeniowych i ewentualnie innego dostępu, takiego jak RDP dla klastrów systemu Windows. Ostatnia ogólna reguła polega na ograniczeniu dostępu do minimum wymaganego.

Aby utworzyć nową sieciową grupę zabezpieczeń dla każdej utworzonej podsieci, zobacz Tworzenie sieciowej grupy zabezpieczeń.

Reguły zabezpieczeń dla ruchu przychodzącego

Podsieć maszyny wirtualnej CycleCloud

Podsieci obliczeniowe

Reguły zabezpieczeń dla ruchu wychodzącego

Ogólnie rzecz biorąc, maszyna wirtualna CycleCloud i klastry obliczeniowe muszą uzyskiwać dostęp do Internetu na potrzeby instalacji pakietu i wywołań interfejsu API REST platformy Azure.

Jeśli zasady zabezpieczeń blokują wychodzący dostęp do Internetu, postępuj zgodnie z instrukcjami dotyczącymi uruchamiania w zablokowanych sieciach i Uruchamiania za serwerem proxy , aby uzyskać szczegółowe informacje o konfiguracji.