DevTest Labs: Referenzarchitektur für Unternehmen

Dieser Artikel enthält eine Referenzarchitektur zum Bereitstellen von Azure DevTest Labs in einem Unternehmen. Die Architektur umfasst die folgenden Schlüsselelemente:

• Lokale Konnektivität mithilfe von Azure ExpressRoute
• Ein Remotedesktopgateway zur Remoteanmeldung bei virtuellen Computern (VMs)
• Konnektivität mit einem privaten Artefaktrepository
• Andere PaaS-Komponenten (Platform as a Service), die von Labs verwendet werden

Aufbau

Das folgende Diagramm zeigt eine typische DevTest Labs-Unternehmensbereitstellung. Diese Architektur verbindet mehrere Labs in verschiedenen Azure-Abonnements mit dem lokalen Netzwerk eines Unternehmens.

DevTest Labs-Komponenten

DevTest Labs gestaltet es für Unternehmen einfach und schnell, Zugriff auf Azure-Ressourcen bereitzustellen. Jedes Lab enthält SaaS- (Software-as-a-Service), IaaS- (Infrastructure-as-a-Service) und PaaS-Ressourcen (Platform as a Service). Lab-Benutzer können virtuelle Computer, PaaS-Umgebungen und VM-Artefakte erstellen und konfigurieren.

Im obigen Diagramm zeigt Team Lab 1 im Azure-Abonnement 1 ein Beispiel für Azure-Komponenten, auf die Labs zugreifen und diese verwenden können. Weitere Informationen finden Sie unter Informationen zu DevTest Labs.

Konnektivitätskomponenten

Sie benötigen lokale Konnektivität, wenn Ihre Labs auf lokale Unternehmensressourcen zugreifen müssen. Häufige Szenarien:

• Einige lokale Daten können nicht in die Cloud verschoben werden.
• Sie möchten Lab-VMs mit einer lokalen Domäne verknüpfen.
• Sie möchten den gesamten Datenverkehr im Cloudnetzwerk aus Sicherheits- oder Konformitätsgründen durch eine lokale Firewall leiten.

Diese Architektur verwendet ExpressRoute für die Konnektivität mit dem lokalen Netzwerk. Sie können auch eine Site-to-Site-VPN-Verbindung verwenden.

Lokal ermöglicht ein Remotedesktopgateway ausgehende RDP-Verbindungen (Remotedesktopprotokoll) mit DevTest Labs. Unternehmensfirewalls blockieren normalerweise ausgehende Verbindungen an der Unternehmensfirewall. Sie können wie folgt vorgehen, um die Konnektivität zu aktivieren:

• Verwenden Sie ein Remotedesktopgateway, und lassen Sie die statische IP-Adresse des Gatewaylastenausgleichs zu.
• Verwenden Sie die Tunnelerzwingung, um den gesamten RDP-Datenverkehr über die ExpressRoute- oder Site-to-Site-VPN-Verbindung zurückzuleiten. Die Tunnelerzwingung ist eine gängige Funktion für DevTest Labs-Bereitstellungen auf Unternehmensniveau.

Netzwerkkomponenten

In dieser Architektur bietet Microsoft Entra ID Identitäts- und Zugriffsverwaltung für alle Netzwerke. Lab-VMs verfügen in der Regel über ein lokales Administratorkonto für den Zugriff. Wenn eine Microsoft Entra ID-Domäne, eine lokale Domäne oder eine Microsoft Entra Domain Services-Domäne verfügbar ist, können Sie Lab-VMs mit der Domäne verknüpfen. Benutzer können dann ihre domänenbasierte Identität verwenden, um eine Verbindung mit den virtuellen Computern herzustellen.

Azure-Netzwerktopologie: Diese steuert, wie Lab-Ressourcen auf lokale Netzwerke und das Internet zugreifen und mit ihnen kommunizieren. Diese Architektur zeigt eine übliche Art und Weise, wie Unternehmen DevTest Labs vernetzen. Die Labs stellen eine Verbindung mit virtuellen Netzwerken mit Peering in einer Hub-Spoke-Konfiguration über die ExpressRoute- oder Site-to-Site-VPN-Verbindung mit dem lokalen Netzwerk her.

Da DevTest Labs Azure Virtual Network jedoch direkt verwendet, gibt es keine Einschränkungen bei der Einrichtung der Netzwerkinfrastruktur. Sie können eine Netzwerksicherheitsgruppe festlegen, um den Datenverkehr in der Cloud auf der Grundlage von Quell- und Ziel-IP-Adressen einzuschränken. Sie können z. B. nur Datenverkehr, der aus dem Unternehmensnetzwerk stammt, in den Netzwerken des Labs zulassen.

Überlegungen zur Skalierbarkeit

DevTest Labs hat keine integrierten Kontingente oder Grenzwerte, aber andere Azure-Ressourcen, die Labs verwenden, verfügen über Kontingente auf Abonnementebene. Bei einer typischen Unternehmensbereitstellung benötigen Sie mehrere Azure-Abonnements, um eine umfangreiche Bereitstellung von DevTest Labs abzudecken. Unternehmen erreichen in der Regel die folgenden Kontingente:

• Ressourcengruppen. DevTest Labs erstellt eine Ressourcengruppe für jeden neuen virtuellen Computer, und Lab-Benutzer erstellen Umgebungen in Ressourcengruppen. Abonnements können bis zu 980 Ressourcengruppen enthalten, sodass die Anzahl der virtuellen Computer und Umgebungen in einem Abonnement begrenzt ist.

  Zwei Strategien können Ihnen helfen, die Grenzwerte für Ressourcengruppen einzuhalten:

  • Alle VMs werden in derselben Ressourcengruppe platziert. Diese Strategie hilft Ihnen, den Grenzwert für die Ressourcengruppe einzuhalten, hat aber Auswirkungen auf den Grenzwert für den Ressourcentyp pro Ressourcengruppe.
  • Verwenden Sie freigegebene öffentliche IP-Adressen. Wenn virtuelle Computer über öffentliche IP-Adressen verfügen dürfen, fügen Sie alle virtuellen Computer der gleichen Größe und Region zu derselben Ressourcengruppe hinzu. Mit dieser Konfiguration können sowohl Ressourcengruppenkontingente als auch Ressourcentyp-pro-Ressourcengruppe-Kontingente erfüllt werden.

• Ressourcen pro Ressourcengruppe pro Ressourcentyp Das Standardlimit für Ressourcen pro Ressourcengruppe, pro Ressourcentyp liegt bei 800. Wenn Sie alle virtuellen Computer in derselben Ressourcengruppe platzieren, wird dieser Grenzwert viel früher erreicht, insbesondere wenn die virtuellen Computer über viele zusätzliche Datenträger verfügen.

• Speicherkonten Jedes Lab in DevTest Labs wird mit einem Speicherkonto bereitgestellt. Das Azure-Kontingent für Anzahl von Speicherkonten pro Region und Abonnement beträgt standardmäßig 250. Daher beträgt die maximale Anzahl der DevTest Labs in derselben Region ebenfalls 250. Mit einer Kontingenterhöhung können Sie bis zu 500 Speicherkonten pro Region erstellen. Weitere Informationen finden Sie unter Erhöhen von Azure Storage-Kontokontingenten.

• Rollenzuweisungen. Eine Rollenzuweisung gibt einem Benutzer oder Prinzipal Zugriff auf eine Ressource. Azure hat einen Grenzwert von 2.000 Rollenzuweisungen pro Abonnement.

  Standardmäßig erstellt DevTest Labs für jede Lab-VM eine Ressourcengruppe. Der Ersteller des virtuellen Computers erhält die Berechtigung Besitzer für die VM und die Berechtigung Leser für die Ressourcengruppe. Daher verwendet jede Lab-VM zwei Rollenzuweisungen. Beim Erteilen von Benutzerberechtigungen für das Lab werden auch Rollenzuweisungen verwendet.

• API-Lesevorgänge/-Schreibvorgänge Sie können Azure und DevTest Labs mithilfe von REST-APIs, PowerShell, der Azure CLI und dem Azure SDK automatisieren. Pro Azure-Abonnement sind bis zu 12.000 Leseanforderungen und 1.200 Schreibanforderungen pro Stunde zulässig. Durch die Automatisierung von DevTest Labs können Sie den Grenzwert für API-Anforderungen erreichen.

Überlegungen zur Verwaltbarkeit

Sie können das Azure-Portal verwenden, um jeweils eine einzelne DevTest Labs-Instanz zu verwalten, aber Unternehmen haben möglicherweise mehrere Azure-Abonnements und viele Labs zu verwalten. Konsistente Änderungen an allen Labs müssen daher mithilfe von Skripting/Automatisierung vorgenommen werden.

Hier sind einige Beispiele für die Verwendung von Skripts in DevTest Labs-Bereitstellungen:

• Ändern der Lab-Einstellungen. Aktualisieren Sie eine bestimmte Lab-Einstellung für alle Labs mithilfe von PowerShell-Skripts, der Azure CLI oder von REST-APIs. Aktualisieren Sie z. B. alle Labs, um eine neue VM-Instanzgröße zuzulassen.

• Aktualisierung der persönlichen Zugriffstoken (PATs) für das Artefaktrepository. PATs für Git-Repositorys laufen normalerweise nach 90 Tagen, einem Jahr oder zwei Jahren ab. Um Kontinuität zu gewährleisten, ist es wichtig, das PAT zu verlängern. Oder erstellen Sie ein neues PAT und verwenden Sie die Automatisierung, um es auf alle Labs anzuwenden.

• Einschränken von Änderungen an Lab-Einstellungen Um bestimmte Einstellungen einzuschränken, z. B. die Verwendung von Marketplace-Images, können Sie Azure Policy verwenden, um Änderungen an einem Ressourcentyp zu verhindern. Oder Sie können eine benutzerdefinierte Rolle erstellen und Benutzern diese Rolle anstelle einer integrierten Lab-Rolle erteilen. Sie können Änderungen für die meisten Lab-Einstellungen einschränken, z. B. interne Unterstützung, Lab-Ankündigungen und zulässige VM-Größen.

• Anwenden einer Namenskonvention für VMs. Sie können Azure Policy verwenden, um ein Benennungsmuster festzulegen, das die Identifizierung von VMs in cloudbasierten Umgebungen erleichtert.

Sie verwalten Azure-Ressourcen für DevTest Labs auf dieselbe Weise wie für andere Zwecke. Beispielsweise gilt Azure Policy für virtuelle Computer, die Sie in einem Lab erstellen. Microsoft Defender für Cloud kann Berichte zur Konformität von virtuellen Lab-Computern erstellen. Azure Backup kann regelmäßige Sicherungen für Lab-VMs bereitstellen.

Sicherheitshinweise

DevTest Labs profitiert automatisch von integrierten Azure-Sicherheitsfeatures. Wenn Sie also für alle eingehenden Remotedesktopverbindungen nur Verbindungen aus dem Unternehmensnetzwerk zulassen möchten, können Sie dazu dem virtuellen Netzwerk auf dem Remotedesktopgateway eine Netzwerksicherheitsgruppe hinzufügen.

Ein weiterer Sicherheitsaspekt ist die Berechtigungsstufe, die Sie den Lab-Benutzern gewähren. Lab-Besitzer verwenden die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC), um Benutzern Rollen zuzuweisen und Berechtigungen auf Ressourcen- und Zugriffsebene festzulegen. Die gängigsten DevTest Labs-Berechtigungen sind „Besitzer“, „Mitwirkender“ und „Benutzer“. Sie können auch benutzerdefinierte Rollen erstellen und zuweisen. Weitere Informationen finden Sie unter Hinzufügen von Besitzern und Benutzern in Azure DevTest Labs.

Nächste Schritte

Weitere Informationen finden Sie im nächsten Artikel dieser Reihe: Bereitstellen eines Proof of Concept.