Działanie w zablokowanej sieci
Węzły aplikacji CycleCloud i klastra mogą działać w środowiskach z ograniczonym dostępem do Internetu, chociaż istnieje minimalna liczba portów TCP, które muszą pozostać otwarte.
Instalowanie usługi Azure CycleCloud w zablokowanej sieci
Maszyna wirtualna CycleCloud musi mieć możliwość nawiązania połączenia z wieloma interfejsami API platformy Azure w celu organizowania maszyn wirtualnych klastra i uwierzytelniania w usłudze Azure Active Directory. Ponieważ te interfejsy API korzystają z protokołu HTTPS, usługa CycleCloud wymaga wychodzącego dostępu HTTPS do:
- management.azure.com (Azure ARM Management)
- login.microsoftonline.com (Azure AD)
- watson.telemetry.microsoft.com (telemetria platformy Azure)
- dc.applicationinsights.azure.com (Azure Application Insights)
- dc.applicationinsights.microsoft.com (Azure Application Insights)
- dc.services.visualstudio.com (Azure Application Insights)
- ratecard.azure-api.net (dane dotyczące cen platformy Azure)
Interfejs API zarządzania jest hostowany regionalnie, a zakresy publicznych adresów IP można znaleźć tutaj.
Logowanie Azure AD jest częścią wspólnych interfejsów API Microsoft 365, a zakresy adresów IP usługi można znaleźć tutaj.
Zakresy adresów IP usług Azure Insights i Log Analytics można znaleźć tutaj.
Usługa Azure CycleCloud musi mieć dostęp do kont usługi Azure Storage. Zalecanym sposobem zapewnienia prywatnego dostępu do tej usługi i innych obsługiwanych usług platformy Azure jest użycie punktów końcowych usługi sieci wirtualnej.
W przypadku używania sieciowych grup zabezpieczeń lub usługi Azure Firewall w celu ograniczenia dostępu wychodzącego do wymaganych domen można skonfigurować usługę Azure Cyclecloud w celu kierowania wszystkich żądań za pośrednictwem serwera proxy HTTPS. Zobacz: Korzystanie z internetowego serwera proxy
Konfigurowanie sieciowej grupy zabezpieczeń platformy Azure dla maszyny wirtualnej CycleCloud
Jednym ze sposobów ograniczenia wychodzącego dostępu do Internetu z maszyny wirtualnej CycleCloud bez konfigurowania usługi Azure Firewall lub serwera proxy HTTPS jest skonfigurowanie ścisłej sieciowej grupy zabezpieczeń platformy Azure dla podsieci maszyny wirtualnej CycleCloud. Najprostszym sposobem, aby to zrobić, jest użycie tagów usługi w podsieci lub sieciowej grupy zabezpieczeń maszyny wirtualnej w celu zezwolenia na wymagany wychodzący dostęp do platformy Azure.
Skonfiguruj Storage Service Endpoint dla podsieci, aby umożliwić dostęp z CycleCloud do Azure Storage
Dodaj następującą regułę ruchu wychodzącego grupy zabezpieczeń sieciowych (NSG), aby domyślnie blokować dostęp wychodzący, używając tagu usługi "Internet".
| Priorytet | Nazwa | Port | Protokół | Źródło | Destynacja | Akcja |
|---|---|---|---|---|---|---|
| 4000 | BlockOutbound | Jakikolwiek | Jakikolwiek | Jakikolwiek | Internet | Odmów |
- Dodaj następujące reguły ruchu wychodzącego sieciowej grupy zabezpieczeń, aby zezwolić na dostęp wychodzący do wymaganych usług platformy Azure według docelowego tagu usługi:
| Priorytet | Nazwa | Port | Protokół | Źródło | Destynacja | Akcja |
|---|---|---|---|---|---|---|
| 100 | ZezwalajazureStorage | 443 | TCP | Jakikolwiek | Magazynowanie | Pozwól |
| 101 | AllowActiveDirectory | 443 | TCP | Jakikolwiek | AzureActiveDirectory | Pozwól |
| 102 | AllowAzureMonitor | 443 | TCP | Jakikolwiek | AzureMonitor | Pozwól |
| 103 | ZezwalajazureRM | 443 | TCP | Jakikolwiek | AzureResourceManager | Pozwól |
Wewnętrzna komunikacja między węzłami klastra a aplikacją CycleCloud
Te porty muszą być otwarte, aby umożliwić komunikację między węzłami klastra i serwerem CycleCloud:
| Nazwa | Źródło | Destynacja | Usługa | Protokół | Zakres portów |
|---|---|---|---|---|---|
| amqp_5672 | Węzeł klastra | CycleCloud | AMQP (Protokół przesyłania danych asynchronicznych) | TCP | 5672 |
| https_9443 | Węzeł klastra | CycleCloud | HTTPS | TCP | 9443 |
Uruchamianie klastrów usługi Azure CycleCloud w zablokowanej sieci
Uwaga
Uruchamianie węzłów klastra w podsieci bez wychodzącego dostępu do Internetu jest obecnie w pełni obsługiwane, ale jest to zaawansowany temat, który często wymaga niestandardowego obrazu lub dostosowania domyślnych typów klastrów i projektów CycleCloud lub obu tych typów.
Aktywnie aktualizujemy typy klastrów i projekty, aby wyeliminować większość lub wszystkie te działania. Jeśli jednak wystąpią błędy z typem klastra lub projektem w zablokowanym środowisku, rozważ otwarcie wniosku o pomoc techniczną.
Uruchamianie maszyn wirtualnych lub klastrów Cyclecloud w sieci wirtualnej lub podsieci z wychodzącym dostępem do Internetu zwykle wymaga następujących elementów:
- Usługa Azure Cyclecloud musi być osiągalna z maszyn wirtualnych klastra w celu zapewnienia pełnej funkcjonalności. Albo:
- Maszyny wirtualne klastra muszą mieć możliwość nawiązania połączenia z usługą Azure Cyclecloud bezpośrednio za pośrednictwem protokołów HTTPS i AMQP lub
- Funkcja Cyclecloud ReturnProxy musi być włączona w czasie tworzenia klastra, a sama usługa Cyclecloud musi mieć możliwość nawiązania połączenia z maszyną wirtualną ReturnProxy za pośrednictwem protokołu SSH
- Wszystkie pakiety oprogramowania wymagane przez klaster muszą być następujące:
- Wstępnie zainstalowany w niestandardowym obrazie zarządzanym dla maszyn wirtualnych klastra lub
- Dostępne w lustrzanym repozytorium pakietów dostępnym z maszyn wirtualnych lub
- Skopiowane do maszyny wirtualnej z usługi Azure Storage i zainstalowane bezpośrednio przez projekt Cyclecloud
- Wszystkie węzły klastra muszą mieć dostęp do kont usługi Azure Storage. Zalecanym sposobem zapewnienia prywatnego dostępu do tej usługi i innych obsługiwanych usług platformy Azure jest włączenie punktu końcowego usługi dla sieci wirtualnej dla usługi Azure Storage.
Aktualizacje projektu z usługi GitHub
Usługa Cyclecloud pobierze projekty klastrów z GitHub podczas fazy orkiestracji "przygotowawcza". To pobranie nastąpi po początkowej instalacji, po uaktualnieniu aplikacji Cyclecloud lub podczas uruchamiania klastra określonego typu po raz pierwszy. W zablokowanym środowisku ruch wychodzący HTTPS do github.com może zostać zablokowany. W takim przypadku tworzenie węzła w fazie przejściowej zasobów zakończy się niepowodzeniem.
Jeśli podczas tworzenia pierwszego węzła można tymczasowo otworzyć dostęp do usługi GitHub, usługa CycleCloud przygotuje pliki lokalne dla wszystkich kolejnych węzłów. Jeśli dostęp tymczasowy nie jest możliwy, niezbędne pliki można pobrać z innego komputera i skopiować do aplikacji CycleCloud.
Najpierw określ, który projekt i wersja klastra będą potrzebne, np. Slurm 3.0.8. Zwykle jest to najwyższy numer wersji w bazie danych dla danego projektu. Najnowszą wersję można określić, odwiedzając stronę projektu github lub wysyłając zapytanie do aplikacji CycleCloud dla najnowszej wersji.
Aby wysłać zapytanie do usługi CycleCloud (pamiętaj, że często na liście jest dostępnych wiele wersji):
/opt/cycle_server/cycle_server execute 'select Name, Version, Url from cloud.project where name == "slurm" order by Version'
Name = "slurm"
Version = "3.0.8"
Url = "https://github.com/Azure/cyclecloud-slurm/releases/3.0.8"
Ta wersja projektu i wszystkie zależności znajdują się w [tagu wydania] (https://github.com/Azure/cyclecloud-slurm/releases/tag/3.0.8).
Wszystkie artefakty wydania można pobrać ręcznie, ale CLI CycleCloud udostępnia narzędzie pomocnicze do tej operacji.
Najpierw użyj CycleCloud CLI, aby pobrać i przygotować repozytorium z GitHub (jest to ta sama operacja wykonywana przez CycleCloud w fazie "Przygotowywanie zasobów"):
RELEASE_URL="https://github.com/Azure/cyclecloud-slurm/releases/3.0.8"
RELEASE_VERSION="3.0.8"
mkdir "${RELEASE_VERSION}"
cd "${RELEASE_VERSION}"
# Download release artifacts from githug (on a machine with github access)
cyclecloud project fetch "${RELEASE_URL}" .
# Create a tarbal with the project files pre-staged
cyclecloud project build
mv ./build/slurm "./${RELEASE_VERSION}"
tar czf "slurm-${RELEASE_VERSION}.tgz" ./blobs "./${RELEASE_VERSION}"
Następnie skopiuj spakowany projekt tarball do serwera CycleCloud i wyodrębnij:
#... copy the "slurm-${RELEASE_VERSION}.tgz" file to the Cyclecloud server in /tmp
sudo -i
mkdir -p /opt/cycle_server/work/staging/projects/slurm
cd /opt/cycle_server/work/staging/projects/slurm
tar xzf "/tmp/slurm-${RELEASE_VERSION}.tgz"
chown -R cycle_server:cycle_server /opt/cycle_server/work/staging
Po utworzeniu tych plików lokalnie usługa Cyclecloud wykryje je i nie spróbuje pobrać ich z usługi GitHub.