Betrieb in einem gesperrten Netzwerk
Die CycleCloud-Anwendung und Clusterknoten können in Umgebungen mit eingeschränktem Internetzugriff funktionieren, obwohl es eine minimale Anzahl von TCP-Ports gibt, die geöffnet bleiben müssen.
Installieren von Azure CycleCloud in einem gesperrten Netzwerk
Die CycleCloud-VM muss eine Verbindung mit einer Reihe von Azure-APIs herstellen können, um Cluster-VMs zu koordinieren und azure Active Directory zu authentifizieren. Da diese APIs HTTPS verwenden, erfordert CycleCloud ausgehenden HTTPS-Zugriff auf:
- management.azure.com (Azure ARM-Verwaltung)
- login.microsoftonline.com (Azure AD)
- watson.telemetry.microsoft.com (Azure Telemetry)
- dc.applicationinsights.azure.com (Azure-Anwendung Insights)
- dc.applicationinsights.microsoft.com (Azure-Anwendung Insights)
- dc.services.visualstudio.com (Azure-Anwendung Insights)
- ratecard.azure-api.net (Azure Price Data)
Die Verwaltungs-API wird regional gehostet, und die öffentlichen IP-Adressbereiche finden Sie hier.
Die Azure AD-Anmeldung ist Teil der gemeinsamen MICROSOFT 365-APIs und IP-Adressbereiche für den Dienst finden Sie hier.
Die Azure Insights- und Log Analytics-IP-Adressbereiche finden Sie hier.
Azure CycleCloud muss in der Lage sein, auf Azure Storage-Konten zuzugreifen. Die empfohlene Möglichkeit, privaten Zugriff auf diesen Dienst bereitzustellen und alle anderen unterstützten Azure-Dienste werden über Virtual Network Service-Endpunkte bereitgestellt.
Wenn Sie Netzwerksicherheitsgruppen oder die Azure Firewall verwenden, um den ausgehenden Zugriff auf die erforderlichen Domänen einzuschränken, können Sie Azure Cyclecloud so konfigurieren, dass alle Anforderungen über einen HTTPS-Proxy weitergeleitet werden. Siehe: Verwenden eines Webproxys
Konfigurieren einer Azure Network Security Group für die CycleCloud-VM
Eine Möglichkeit, ausgehenden Internetzugriff von der CycleCloud-VM zu beschränken, ohne das Azure Firewall oder einen HTTPS-Proxy zu konfigurieren, besteht darin, eine strenge Azure Network Security Group für das CycleCloud-VM-Subnetz zu konfigurieren. Die einfachste Möglichkeit, dies zu tun, besteht darin, Diensttags in der Subnetz- oder VM-Ebene Netzwerksicherheitsgruppe zu verwenden, um den erforderlichen ausgehenden Azure-Zugriff zu ermöglichen.
Konfigurieren eines Speicherdienstendpunkts für das Subnetz, um den Zugriff von CycleCloud auf Azure Storage zu ermöglichen.
Fügen Sie die folgende NSG Outbound-Regel hinzu, um den ausgehenden Zugriff standardmäßig mithilfe des Zieldiensttags "Internet" zu verweigern:
| Priority | Name | Port | Protocol | `Source` | Destination | Aktion |
|---|---|---|---|---|---|---|
| 4000 | BlockOutbound | Any | Any | Any | Internet | Verweigern |
- Fügen Sie die folgenden NSG Outbound-Regeln hinzu, um den ausgehenden Zugriff auf die erforderlichen Azure-Dienste nach Zieldiensttag zu zulassen :
| Priority | Name | Port | Protocol | `Source` | Destination | Aktion |
|---|---|---|---|---|---|---|
| 100 | AllowAzureStorage | 443 | TCP | Any | Speicher | Allow |
| 101 | AllowActiveDirectory | 443 | TCP | Any | AzureActiveDirectory | Allow |
| 102 | AllowAzureMonitor | 443 | TCP | Any | AzureMonitor | Allow |
| 103 | AllowAzureRM | 443 | TCP | Any | AzureResourceManager | Allow |
Interne Kommunikation zwischen Clusterknoten und CycleCloud
Diese Ports müssen geöffnet sein, um die Kommunikation zwischen den Clusterknoten und dem CycleCloud-Server zu ermöglichen:
| Name | `Source` | Destination | Dienst | Protocol | Portbereich |
|---|---|---|---|---|---|
| amqp_5672 | Clusterknoten | CycleCloud | AMQP | TCP | 5672 |
| https_9443 | Clusterknoten | CycleCloud | HTTPS | TCP | 9443 |
Starten von Azure CycleCloud-Clustern in einem gesperrten Netzwerk
Hinweis
Das Ausführen von Clusterknoten in einem Subnetz ohne ausgehenden Internetzugriff wird heute vollständig unterstützt, aber es ist ein erweitertes Thema, das häufig ein benutzerdefiniertes Bild oder eine Anpassung der Standard-CycleCloud-Clustertypen und -projekte oder beides erfordert.
Wir aktualisieren aktiv die Clustertypen und -projekte, um die meisten oder alle diese Arbeiten zu beseitigen. Wenn jedoch Fehler mit Ihrem Clustertyp oder Projekt in Ihrer gesperrten Umgebung auftreten, sollten Sie eine Supportanfrage zur Unterstützung öffnen.
Das Ausführen von VMs oder Cyclecloud-Clustern in einem virtuellen Netzwerk oder Subnetz mit ausgehendem Internetzugriff erfordert im Allgemeinen Folgendes:
- Azure Cyclecloud muss über die Cluster-VMs für vollständige Funktionen erreichbar sein. Entweder:
- Cluster-VMs müssen eine direkte Verbindung mit Azure Cyclecloud über HTTPS und AMQP herstellen können oder
- Das Cyclecloud ReturnProxy-Feature muss zur Clustererstellungszeit aktiviert sein, und Cyclecloud selbst muss in der Lage sein, eine Verbindung mit der ReturnProxy-VM über SSH herzustellen.
- Alle softwarepakete, die vom Cluster benötigt werden, müssen entweder:
- Vorinstalliert in einem benutzerdefinierten verwalteten Image für die Cluster-VMs oder
- Verfügbar in einem Paket-Repositoryspiegel, auf den über die VMs zugegriffen werden kann, oder
- Kopiert in den virtuellen Computer aus Azure Storage und direkt von einem Cyclecloud-Projekt installiert
- Alle Clusterknoten müssen auf Azure Storage-Konten zugreifen können. Die empfohlene Möglichkeit, den privaten Zugriff auf diesen Dienst und alle anderen unterstützten Azure-Dienste bereitzustellen, besteht darin, einen Virtual Network Dienstendpunkt für Azure Storage zu aktivieren.
Project Aktualisierungen von GitHub
Cyclecloud lädt Clusterprojekte aus GitHub während der Phase der "Staging"-Orchestrierung herunter. Dieser Download tritt nach der ersten Installation, nach dem Upgrade von Cyclecloud oder beim ersten Starten eines Clusters eines bestimmten Typs auf. In einer gesperrten Umgebung kann https ausgehender Datenverkehr zu github.com blockiert werden. In diesem Fall schlägt die Knotenerstellung während der Stagingressourcenphase fehl.
Wenn der Zugriff auf GitHub während der Erstellung des ersten Knotens vorübergehend geöffnet werden kann, bereitet CycleCloud die lokalen Dateien für alle nachfolgenden Knoten vor. Wenn der temporäre Zugriff nicht möglich ist, können die erforderlichen Dateien von einem anderen Computer heruntergeladen und in CycleCloud kopiert werden.
Ermitteln Sie zuerst, welches Projekt und welche Version Ihr Cluster benötigt, z. B. Slurm 2.5.0. Normalerweise ist es die höchste Versionsnummer in der Datenbank für ein bestimmtes Projekt.
/opt/cycle_server/cycle_server execute 'select * from cloud.project where name == "slurm"'
AdType = "Cloud.Project"
Version = "2.5.0"
ProjectType = "scheduler"
Url = "https://github.com/Azure/cyclecloud-slurm/releases/2.5.0"
AutoUpgrade = false
Name = "slurm"
Diese Projektversion und alle Abhängigkeiten finden Sie im [Release-Tag] (https://github.com/Azure/cyclecloud-slurm/releases/tag/2.5.0). Alle Artefakte für eine Version müssen heruntergeladen werden. Laden Sie zuerst das Codeartefakt herunter, und erstellen Sie ein Blobs-Verzeichnis für die zusätzlichen Abhängigkeiten.
wget https://github.com/Azure/cyclecloud-slurm/archive/refs/tags/2.5.0.tar.gz
tar -xf 2.5.0.tar.gz
cd cyclecloud-slurm-2.5.0 && mkdir blobs
#... download all other release artifacts to the /blobs directory with wget ...
wget -P "blobs/" https://github.com/Azure/cyclecloud-slurm/releases/download/2.6.1/cyclecloud_api-8.1.0-py2.py3-none-any.whl
#... copy all the files to the Cyclecloud server
#... then on the Cyclecloud server:
cyclecloud project build
mkdir -p /opt/cycle_server/work/staging/projects/slurm/2.5.0
mkdir -p /opt/cycle_server/work/staging/projects/slurm/blobs
cp build/slurm/* /opt/cycle_server/work/staging/projects/slurm/2.5.0/
cp blobs/* /opt/cycle_server/work/staging/projects/slurm/blobs/
chown -R cycle_server:cycle_server /opt/cycle_server/work/staging
Sobald diese Dateien lokal staged wurden, erkennt Cyclecloud sie und versucht nicht, sie aus GitHub herunterzuladen.