Zentrales Hochskalieren Ihrer Azure DevTest Labs-Infrastruktur

Zur Orchestrierung einer erfolgreichen Implementierung von DevTest Labs auf Unternehmensniveau müssen wichtige Entscheidungspunkte berücksichtigt und ein Ansatz für die schnelle Bereitstellung und Implementierung von Azure DevTest Labs geplant werden.

In diesem Artikel werden die wichtigsten Entscheidungspunkte beschrieben, die Sie bei der Planung Ihrer Implementierung berücksichtigen sollten, und es wird ein empfohlener Ansatz für die Bereitstellung beschrieben.

Wichtige Entscheidungspunkte

Vor der Implementierung von DevTest Labs auf Unternehmensebene sind mehrere wichtige Entscheidungspunkte zu berücksichtigen. Diese Entscheidungspunkte auf hoher Ebene zu verstehen, hilft Organisationen bei zukünftigen Entwurfsentscheidungen. Sie sollten jedoch eine Organisation nicht daran hindern, einen Proof of Concept zu starten.

Die obersten drei Bereiche für die anfängliche Planung der Hochskalierung sind:

• Netzwerke und Sicherheit
• Abonnementtopologie
• Rollen und Zuständigkeiten

Netzwerke und Sicherheit

Netzwerke und Sicherheit sind die Stützpfeiler aller Organisationen. Während für eine unternehmensweite Bereitstellung eine erheblich genauere Analyse erforderlich ist, gibt es weniger Anforderungen für einen erfolgreichen Proof of Concept. Zu den wichtigen Schwerpunkten zählen:

• Azure-Abonnement: Zum Bereitstellen von DevTest Labs benötigen Sie Zugriff auf ein Azure-Abonnement mit ausreichenden Berechtigungen zum Erstellen von Ressourcen. Es gibt mehrere Möglichkeiten, Zugriff auf Azure-Abonnements zu erhalten, etwa ein Enterprise Agreement oder die nutzungsbasierte Bezahlung. Weitere Informationen zum Erhalten des Zugriffs auf ein Azure-Abonnement finden Sie unter Lizenzierung von Azure für das Unternehmen.
• Zugriff auf lokale Ressourcen: Bei einigen Organisationen müssen die Ressourcen in DevTest Labs Zugriff auf lokale Ressourcen haben. Sie benötigen eine sichere Verbindung aus Ihrer lokalen Umgebung mit Azure. Es ist wichtig, vorab entweder eine VPN-Verbindung oder eine Azure ExpressRoute-Leitung einzurichten und zu konfigurieren. Weitere Informationen finden Sie unter Übersicht über virtuelle Netzwerke.
• Weitere Sicherheitsanforderungen: Andere Sicherheitsanforderungen, z. B. Computerrichtlinien, Zugriff auf öffentliche IP-Adressen, Verbindung mit dem Internet, sind Szenarien, die möglicherweise vor dem Implementieren eines Proof of Concept überprüft werden müssen.

Abonnementtopologie

Die Abonnementtopologie ist ein wichtiger Entwurfsaspekt für die Bereitstellung von DevTest Labs in Unternehmen. Die Entscheidungen müssen jedoch erst nach Abschluss eines Proof of Concept endgültig festgelegt werden. Bei der Auswertung der erforderlichen Anzahl von Abonnements für eine Unternehmensimplementierung gibt es zwei Extreme:

• Ein Abonnement für die gesamte Organisation
• Ein Abonnement pro Benutzer

Als Nächstes werden die Vorteile der beiden Ansätze genauer erläutert.

Ein Abonnement

Häufig ist der Ansatz, nur ein Abonnement zu verwenden, in einem großen Unternehmen nicht zu bewältigen. Das Beschränken der Anzahl von Abonnements bietet jedoch die folgenden Vorteile:

• Die Prognosekosten für das Unternehmen. Die Budgetzuweisung ist mit einem Abonnement viel einfacher, da sich alle Ressourcen in einem einzelnen Pool befinden. Dieser Ansatz ermöglicht eine einfachere Entscheidungsfindung zur Umsetzung von Kostenkontrollmaßnahmen zu einem beliebigen Zeitpunkt während eines Abrechnungszyklus.
• Die Verwaltbarkeit von VMs, Artefakten, Formeln, Netzwerkkonfigurationen, Berechtigungen und Richtlinien ist einfacher, da alle Aktualisierungen nur in einem und nicht in vielen Abonnements vorgenommen werden müssen.
• Der Netzwerkaufwand verringert sich bei einem einzelnen Abonnement für Unternehmen, bei denen lokale Konnektivität eine Voraussetzung ist. Es ist notwendig, virtuelle Netzwerke über Abonnements hinweg zu verbinden (Hub-Spoke-Modell), und dies erfordert bei weiteren Abonnements zusätzliche Konfiguration, Verwaltung, IP-Adressbereiche usw.
• Die Zusammenarbeit im Team ist einfacher, wenn alle im selben Abonnement arbeiten. Beispielsweise ist es einfacher, Kolleg*innen eine VM erneut zuzuweisen oder Teamressourcen zu teilen.

Ein Abonnement pro Benutzer

Ein separates Abonnement pro Benutzer bietet gleiche Möglichkeiten in einem alternativen Spektrum. Die Vorteile der Nutzung mehrerer Abonnements sind etwa:

• Die Umsetzung wird nicht durch Azure-Skalierungskontingente beeinträchtigt. Zum Zeitpunkt dieses Artikels lässt Azure beispielsweise 200 Speicherkonten pro Abonnement zu. Für die meisten Dienste in Azure bestehen operative Kontingente (viele können angepasst werden, einige nicht). Bei diesem Modell mit einem Abonnement pro Benutzer*in ist es bei den meisten Kontingenten sehr unwahrscheinlich, dass sie erreicht werden. Weitere Informationen zu aktuellen Azure-Skalierungskontingenten finden Sie unter Grenzwerte für Azure-Abonnements und Dienste, Kontingente und Einschränkungen.
• Die verbrauchsbasierte Kostenzuteilung für Gruppen oder einzelne Entwickler ist wesentlich einfacher, sodass Organisationen Kosten mit ihrem aktuellen Modell einplanen können.
• Besitz und Berechtigungen sind in DevTest Labs-Umgebungen einfach. Sie gewähren Entwicklern Zugriff auf Abonnementebene, und diese sind dann uneingeschränkt für alle Elemente verantwortlich, einschließlich Netzwerkkonfiguration, Labrichtlinien und VM-Verwaltung.

In Unternehmen gibt es möglicherweise zahlreiche Einschränkungen für die Extreme des Spektrums. Daher müssen Sie Abonnements auf eine Weise einrichten, die in der Mitte zwischen diesen Extremen liegt. Als bewährte Methode sollte das Ziel einer Organisation die Verwendung von möglichst wenigen Abonnements sein. Beachten Sie dabei Funktionen, die das Erhöhen der Gesamtanzahl der Abonnements erzwingen. Zusammenfassend gilt: Die Abonnementtopologie ist wichtig für eine Unternehmensbereitstellung von DevTest Labs, sollte jedoch einen Proof of Concept nicht hinauszögern. Im Artikel Governance finden Sie weitere Details zur Entscheidung über die Granularität für das Abonnement und das Lab innerhalb der Organisation.

Rollen und Zuständigkeiten

Ein Proof of Concept für DevTest-Labs weist drei primäre Rollen mit definierten Aufgaben auf: Abonnementbesitzer, DevTest Labs-Besitzer, DevTest Labs-Benutzer – und optional einen Mitwirkenden.

• Abonnementbesitzer: Der Besitzer des Abonnements verfügt über Rechte zum Verwalten eines Azure-Abonnements, einschließlich der Zuweisung von Benutzer*innen, der Verwaltung von Richtlinien, der Erstellung und Verwaltung der Netzwerktopologie und der Anforderung von Kontingenterhöhungen. hier finden Sie weitere Informationen
• DevTest Labs-Besitzer: Der DevTest Labs-Besitzer hat vollen administrativen Zugriff auf das Lab. Diese Person ist verantwortlich für das Hinzufügen/Entfernen von Benutzern, das Verwalten der Kosteneinstellungen, die allgemeinen Lab-Einstellungen und andere Aufgaben bezüglich virtueller Computer und Artefakte. Ein Labbesitzer verfügt auch über alle Rechte von DevTest Labs-Benutzern.
• DevTest Labs-Benutzer: Der DevTest Labs-Benutzer kann die virtuellen Computer im Lab erstellen und nutzen. Diese Personen erfüllen einige minimale Verwaltungsfunktionen auf virtuellen Computern, die sie erstellen (Starten/Beenden/Löschen/Konfigurieren ihrer virtuellen Computer). Die Benutzer können keine VMs von anderen Benutzern verwalten.

Orchestrieren der Implementierung von DevTest Labs

Dieser Artikel stellt einen empfohlenen Ansatz für die schnelle Bereitstellung und Implementierung von Azure DevTest Labs vor. Die folgende Abbildung stellt den Gesamtprozess in Form eines normativen Leitfadens dar, berücksichtigt aber zugleich die erforderliche Flexibilität, um verschiedene Branchenanforderungen und Szenarien zu unterstützen.

Annahmen

In diesem Artikel wird davon ausgegangen, dass die folgenden Elemente verfügbar sind, bevor mit einer DevTest Labs-Pilotimplementierung begonnen wird:

• Azure-Abonnement: Das Pilotteam hat Zugriff auf die Bereitstellung von Ressourcen in einem Azure-Abonnement. Wenn sich die Workloads nur auf Entwicklung und Test beziehen, empfiehlt sich das Enterprise DevTest-Angebot, da es zusätzliche verfügbare Images und niedrigere Sätze für virtuelle Windows-Computer bietet.
• Lokaler Zugriff: Falls erforderlich, wurde der lokale Zugriff bereits konfiguriert. Der lokale Zugriff kann mithilfe einer Site-to-Site-VPN-Verbindung oder über ExpressRoute realisiert werden. Die Einrichtung von Konnektivität mithilfe von ExpressRoute nimmt normalerweise viele Wochen in Anspruch – die ExpressRoute sollte bereits etabliert sein, bevor mit dem Projekt begonnen wird.
• Pilotteams: Die ersten für die Entwicklung zuständigen Projektteams für DevTest Labs wurden benannt, die entsprechenden Entwicklungs- und Testaktivitäten wurden definiert, und die Anforderungen/Ziele für die Teams wurden festgelegt.

Meilenstein 1: Einrichten der anfänglichen Netzwerktopologie und des ersten Netzwerkentwurfs

Der erste Schwerpunkt bei der Bereitstellung einer Azure DevTest Labs-Lösung liegt in der Herstellung der geplanten Konnektivität für die virtuellen Computer. Die folgenden Schritte beschreiben die erforderlichen Prozeduren:

1. Definieren der anfänglichen IP-Adressbereiche, die dem DevTest Labs-Abonnement in Azure zugewiesen werden. Für diesen Schritt muss die erwartete zukünftige Nutzung in Form der Anzahl der VMs eingeschätzt werden, damit ein für zukünftiges Wachstum ausreichend großer Block bereitgestellt werden kann.
2. Identifizieren der gewünschten Zugriffsmethoden auf die DevTest Labs (beispielsweise externer/interner Zugriff). Ein wichtiger Punkt bei diesem Schritt besteht in der Festlegung, ob virtuelle Computer über öffentliche IP-Adressen (so dass sie vom Internet aus direkt zugänglich sind) verfügen sollen.
3. Identifizieren und Einrichten von Konnektivitätsmethoden mit der übrigen Azure-Cloudumgebung und lokalen Ressourcen. Wenn erzwungenes Routing mit ExpressRoute aktiviert ist, benötigen die virtuellen Computer für den Durchgang durch die Unternehmensfirewall wahrscheinlich geeignete Proxykonfigurationen.
4. Wenn VMs Domäneneinbindung erhalten sollen, legen Sie fest, ob sie einer cloudbasierten Domäne (beispielsweise Microsoft Entra Directory Services) oder einer lokalen Domäne beitreten sollen. Legen Sie im Fall der lokalen Domäne fest, zu welcher Organisationseinheit (OU) in Active Directory die virtuellen Computer gehören sollen. Überprüfen Sie ferner, ob Benutzer Zugriff haben (richten Sie ggf. ein Dienstkonto ein, das Computereinträge in der Domäne erstellen kann).

Meilenstein 2: Bereitstellen des Pilot-Labs

Sobald die Netzwerktopologie eingerichtet ist, kann das Pilot-Lab mithilfe der folgenden Schritte erstellt werden:

1. Erstellen der ersten DevTest Labs-Umgebung
2. Bestimmen zulässiger VM-Images und -Größen für die Nutzung im Lab. Entscheiden Sie, ob benutzerdefinierte Images für die Verwendung in DevTest Labs auf Azure hochgeladen werden können.
3. Schützen Sie den Zugriff auf das Lab, indem Sie die rollenbasierte Zugriffssteuerung in Azure (Azure RBAC) für das Lab erstellen (Lab-Besitzer und -Benutzer). Wir empfehlen die Verwendung synchronisierter Active Directory-Konten in Microsoft Entra ID für die Identität in DevTest Labs.
4. Konfigurieren von DevTest Labs für die Verwendung von Richtlinien, wie etwa Zeitplänen, Kostenverwaltung, abrufbaren VMs, benutzerdefinierten Images oder Formeln.
5. Einrichten eines Onlinerepositorys wie Azure Repos/Git.
6. Entscheidung für die Verwendung öffentlicher oder privater Repositorys bzw. einer Kombination aus beiden. Stellen Sie JSON-Vorlagen für Bereitstellungen und langfristig vorbeugende Wartung bereit.
7. Erstellen benutzerdefinierter Artefakte bei Bedarf. Dieser Schritt ist optional.

Meilenstein 3: Dokumentation, Support, Lernen und Verbessern

Die anfänglichen Pilotteams benötigen möglicherweise eingehenden Support für den Einstieg. Nutzen Sie ihre Erfahrungen, um sicherzustellen, dass für das fortgesetzte Rollout von Azure DevTest Labs die passende Dokumentation und geeigneter Support verfügbar sind.

1. Führen Sie die Pilotteams in ihre neuen DevTest Labs-Ressourcen ein (Demos, Dokumentation).
2. Planen Sie ausgehend von den Erfahrungen der Pilotteams Dokumentation nach Bedarf, und stellen Sie sie entsprechend zur Verfügung.
3. Formalisieren Sie den Prozess für das Onboarding neuer Teams (Erstellen und Konfigurieren von Labs, Erteilen des Zugriffs usw.).
4. Überprüfen Sie auf der Grundlage der anfänglichen Akzeptanz, ob die ursprüngliche Einschätzung des IP-Adressbereichs noch realistisch und ausreichend genau ist.
5. Stellen Sie sicher, dass geeignete Überprüfungen von Compliance und Sicherheit durchgeführt werden.

Nächste Schritte

Lesen Sie den nächsten Artikel in dieser Reihe: Governance der Azure DevTest Labs-Infrastruktur