Entwerfen der Workloadarchitektur vor der Migration

Dieser Artikel beschreibt den Prozess und die Überlegungen zur Gestaltung des beabsichtigten migrierten Zustands eines Workloads in der Cloud. Der Artikel gibt einen Überblick über die Aktivitäten, die zur Definition der Architektur eines Workloads innerhalb einer Iteration gehören.

Der Artikel über inkrementelle Rationalisierung weist darauf hin, dass einige architektonische Annahmen Teil einer jeden Unternehmenstransformation sind, die eine Migration beinhaltet. Dieser Artikel erläutert typische Annahmen. Es werden auch einige Hindernisse aufgezeigt, die Sie vermeiden können, und es werden Möglichkeiten aufgezeigt, den Geschäftswert zu steigern, indem Sie die Annahmen der Architektur in Frage stellen. Dieses inkrementelle Modell für die Entwicklung der Architektur hilft den Teams, schneller voranzukommen und schneller Unternehmensergebnisse zu erzielen.

Bauen Sie die Basisarchitektur auf allgemeinen Annahmen auf

Die folgenden Annahmen sind für alle Migrationsvorgänge typisch:

• Nehmen wir an, es handelt sich um eine Infrastruktur-als-Service (IaaS)-Workload. Bei der Migration von Workloads werden in erster Linie aus einem physischen Rechenzentrum über eine IaaS-Migration in ein Cloudrechenzentrum verschoben. Dieser Prozess erfordert in der Regel nur minimale Neuentwicklungs- oder Neukonfigurationsmaßnahmen. Dieser Ansatz wird als Lift & Shift-Migration bezeichnet.
• Halten Sie die Architektur konsistent. Änderungen an der Kernarchitektur während einer Migration erhöhen die Komplexität erheblich. Das Debuggen eines geänderten Systems auf einer neuen Plattform beinhaltet unzählige Variablen, die möglicherweise nur schwierig zu isolieren sind. Während der Migration sollten nur geringfügige Änderungen an den Workloads vorgenommen werden, die dann auch gründlich getestet werden müssen.
• Planen Sie das Ändern der Größe von Ressourcen. Gehen Sie davon aus, dass nur wenige lokale Ressourcen alle Ressourcen vollständig verwenden. Vor oder während der Migration wird die Größe der Ressourcen an die tatsächlichen Nutzungsanforderungen angepasst. Tools wie Azure Migrate and Modernize bieten eine Größenanpassung basierend auf der tatsächlichen Verwendung.
• Erfassen Sie die Anforderungen an Business Continuity & Disaster Recovery (BCDR). Wenn Sie bereits eine Vereinbarung zum Servicelevel (Service-Level-Agreement, SLA) für den Workload mit dem Unternehmen ausgehandelt haben, können Sie dieses SLA auch nach der Migration zu Azure weiter nutzen. Wenn noch keine SLA festgelegt wurde, sollten Sie eine definieren, bevor Sie die Workload in der Cloud entwerfen, um sicherzustellen, dass Sie ordnungsgemäß entwerfen.
• Planen sie die Ausfallzeiten der Migration. Ebenso wie die Nichteinhaltung von SLA-Anforderungen können auch Ausfallzeiten, die bei der Überführung eines Workloads in die Produktion auftreten, negative Auswirkungen auf das Unternehmen haben. In einigen Fällen erfordern Lösungen, die mit minimalen Ausfallzeiten umgestellt werden müssen, Änderungen an der Architektur. Bevor Sie mit der Release-Planung beginnen, sollten Sie davon ausgehen, dass ein allgemeines Verständnis der Anforderungen an die Ausfallzeiten vorhanden ist.
• Definieren von Benutzer- und Anwendungsdatenverkehrsmustern. Bestehende Lösungen hängen möglicherweise von bestehenden Netzwerk-Routing-Mustern und -Lösungen ab. Ermitteln Sie die Ressourcen, die Sie für die aktuelle Netzwerknutzung benötigen.
• Planen Sie, um Netzwerkkonflikte zu vermeiden. Wenn Sie Rechenzentren bei einem einzigen Cloud-Anbieter konsolidieren, kommt es wahrscheinlich zu Konflikten im Domain Name System (DNS) oder anderen Netzwerkstrukturen. Bei der Migration ist es wichtig, diese Konflikte zu vermeiden, um Unterbrechungen der in der Cloud gehosteten Produktionssysteme zu verhindern.
• Planen Sie die Routingtabellen. Stellen Sie sicher, dass Ihr Projekt einen Plan zum Ändern von Routingtabellen enthält, wenn Sie Netzwerke oder Rechenzentren konsolidieren. Erwägen Sie die Anforderungen des rechenzentrumsübergreifenden Routings.

Entwerfen der Architektur für eine Zielzone

In der Ready-Phase des Cloud Adoption Framework hat Ihr Unternehmen im Rahmen der Übernahme von Azure Zielzonen gemeinsame Plattformdienste bereitgestellt. Bei der Vorbereitung Ihrer Zielzone für die Migration haben Sie die Zielzone auf die Aufnahme der migrierten Workloads vorbereitet.

Basierend auf dieser Planung können Sie davon ausgehen, dass die folgenden Migrationskomponenten vorhanden sind:

• Hybride Konnektivität verbindet Ihre Azure-Netzwerke mit Ihren lokalen Netzwerken.
• Netzwerksicherheits-Anwendung wie Azure Firewall verwalten die Überprüfung des Datenverkehrs außerhalb Ihrer Workload.
• Azure-Richtlinien zum Erzwingen von Governance-Praktiken wie Protokollierungsanforderungen, zulässigen Regionen, unzulässigen Diensten und anderen Steuerelementen sind aktiv.
• Ein Azure Monitor Protokoll-Arbeitsbereich für die gemeinsame Protokollierung wird in Azure Monitor eingerichtet.
• Gemeinsame Identitätsressourcen zur Unterstützung domänenverbundener Server oder anderer Identitätsanforderungen werden eingerichtet.

Wenn diese grundlegenden Voraussetzungen für die Migration nicht gegeben sind, sollte Ihr Unternehmen sofort die Vorbereitungsphase wiederholen, um diese Anforderungen zu erfüllen. Ohne diese Komponenten wird Ihre Migration wahrscheinlich Verzögerungen und Rückschläge aufweisen und weniger erfolgreich sein.

Dem Workload, den Sie entwerfen, ist ein Abonnement zugewiesen, idealerweise über einen Abonnement-Verkaufsprozess. Das Abonnement kann mehrere Workloads oder nur einen Workload enthalten, je nachdem, wie Ihr Unternehmen seine Ressourcenorganisation für Workloads abgeschlossen hat. Wenn Sie einen Workload migrieren, der viele Anwendungsumgebungen umfasst, haben Sie möglicherweise sogar mehrere Abonnements, die auf den Richtlinien für Anwendungsumgebungen basieren.

Entwerfen einer Workload-Netzwerkarchitektur

Planen Sie die Bereitstellung anwendungsspezifischer Ressourcen in einem bestimmten Abonnement, und planen Sie, ein dediziertes virtuelles Netzwerk für die Workload zu entwerfen. Weitere Informationen finden Sie in den Anleitungen zum Entwerfen Ihrer Netzwerkarchitektur. Sie sollten sich insbesondere auf das Segmentieren virtueller Netzwerke konzentrieren.

Ihr Netzwerk benötigt wahrscheinlich Ressourcen wie Lastenausgleichsgeräte und andere Anwendungsbereitstellungsressourcen. Sie können die Anleitung für n-schichtige Architektur verwenden, um diese Ressourcen in Azure zu planen.

Entwerfen von Arbeitsauslastungsabhängigkeiten

Ihre Migrationsbewertungstools sollten Ihnen eine Möglichkeit bieten, Abhängigkeitsanalysen durchzuführen, z. B. Abhängigkeitsanalysen in Azure Migrate and Modernize. Mit dem Tool können Sie Abhängigkeiten zwischen Servern identifizieren.

Zusätzlich zur Planung der Architektur für die Workload selbst müssen Sie möglicherweise Abhängigkeiten von Workload zu Workload berücksichtigen. Beispielsweise können einige Arbeitslasten eine häufige Kommunikation benötigen. Wenn dies der Fall ist, hilft die Planung Ihrer Migrationswellen und Abhängigkeiten, um diese Anforderung zu berücksichtigen, ihre Migration erfolgreich zu gestalten.

Sie können Anleitungen im Azure Architecture Center verwenden, z. B. für die Spoke-to-Spoke-Netzwerke, um zu planen, wie miteinander verbundene Arbeitslasten nach der Migration funktionieren.

Vorbereiten der Einführung von Confidential Computing

Eine Teilmenge Ihrer Arbeitslasten mit Anforderungen an die Souveränität könnte dazu führen, dass Sie Confidential Computing einsetzen. Als Teil einer Einrichtung von souveränen Zielzonen werden Verwaltungsgruppen für Confidential Computing erstellt.

Im Rahmen der Souveränität erfordert die Nutzung von Confidential Computing Azure Key Vault und vom Kunden verwaltete Schlüssel als unterstützenden Service. Weitere Informationen finden Sie unter Verschlüsselung mit kundenseitig verwalteten Schlüsseln in Microsoft Cloud for Sovereignty.

Aktualisieren Ihrer anfänglichen Cloud-Schätzung

Wenn Sie den Entwurf Ihrer Architektur abschließen, überprüfen Sie Ihre Cloud-Schätzung, um sicherzustellen, dass Sie sich immer noch im Rahmen des geplanten Budgets bewegen. Wenn Sie unterstützende Dienste wie Lastenausgleichsgeräte oder Sicherungen hinzufügen, können sich die Kosten ändern. Obwohl Sie Tools wie Geschäftsfälle in Azure Migrate und Modernize verwenden können, um ein detailliertes Kostenmanagement durchzuführen, sollten Sie Ihre Schätzungen in regelmäßigen Abständen überprüfen, wenn Sie Ihr den Entwurf Ihrer Architektur anpassen.

Wenn Sie mit traditionellen IT-Beschaffungsprozessen vertraut sind, mag Ihnen die Schätzung von Ressourcen in der Cloud fremd erscheinen. Bei der Einführung von Cloudtechnologien wechselt der Erwerb von einem festen, strukturierten Investitionskostenmodell zu einem fließenden Betriebskostenmodell. Die Planung einer Migration in die Cloud ist oft das erste Mal, dass eine Organisation oder ein IT-Team mit dieser Veränderung konfrontiert wird.

Beim traditionellen Investitionskostenmodell versucht ein IT-Team, die Kaufkraft für mehrere Arbeitslasten über verschiedene Programme hinweg zu kombinieren. Dieser Ansatz zentralisiert einen Pool gemeinsam genutzter IT-Ressourcen, die jede dieser Lösungen unterstützen können. Beim Betriebskosten-Cloudmodell können Kosten direkt den Unterstützungsanforderungen einzelner Workloads, Teams oder Unternehmenseinheiten zugeordnet werden. Dies ermöglicht einer Organisation eine direktere Zuordnung der Kosten zu den internen Kunden und den Geschäftszielen, die sie unterstützen. Dieser dynamischere Ansatz für das Finanzmanagement wird oft als Finanzoperationen (Financial Operations, FinOps) bezeichnet. Obwohl FinOps keine Azure-spezifische Überlegung ist, kann es hilfreich sein, ein erweitertes Verständnis von FinOps mitzubringen. Weitere Informationen finden Sie unter Was ist FinOps?.

Wenn Sie Ihre Workload-Architektur für die Migration entwerfen, können Sie den Preisrechner mit Ihren Bewertungsinformationen verwenden, um den Preis des gesamten Workloads zu verstehen.

Auch nach der Migration Ihres Workloads sollten Sie weiter daran arbeiten, die Kosten für den Workload zu optimieren. Weitere Informationen darüber, wie Unternehmen ihre Fähigkeiten im Bereich Kostenmanagement weiterentwickeln können, finden Sie unter Verbessern der Kostenmanagementdisziplin.

Wissen, wann Sie Ihre Architektur ändern sollten

Bei Migrationen geht es in der Regel darum, eine bestehende Architektur zu erhalten und auf Ihre Cloud-Plattform zu übertragen. Es kann jedoch vorkommen, dass Sie Ihre Arbeitslast neu strukturieren müssen, auch für die Migration. Diese Liste enthält Beispiele dafür, wann Sie vor der Migration Änderungen an der Architektur vornehmen müssen:

• Ausgleichen technischer Schulden: Einige ältere Workloads umfassen ein hohes Maß an technischen Schulden. Technische Schulden können langfristig zu Schwierigkeiten führen und die Hostingkosten bei jedem Cloudanbieter erhöhen. Wenn technische Schulden die Hosting-Kosten unnatürlich in die Höhe treiben, sollten Sie alternative Architekturen prüfen.
• Verbessern der Zuverlässigkeit. Standard-Betriebsbaselines bieten ein gewisses Maß an Zuverlässigkeit und Wiederherstellbarkeit in der Cloud. Einige Workload-Teams verlangen möglicherweise höhere SLAs, was zu Änderungen der Architektur führen könnte.
• Kostenintensive Workloads. Während der Migration sollten Sie alle Assets optimieren, um die Größe mit der tatsächlichen Nutzung in Einklang zu bringen. Einige Workloads erfordern jedoch möglicherweise Änderungen an der Architektur, um bestimmte Kostenprobleme zu beheben.
• Leistungsanforderungen. Wirkt sich die Workloadleistung direkt auf das Unternehmen aus, sind möglicherweise weitere Architekturüberlegungen erforderlich.
• Sichere Anwendungen. Sicherheitsanforderungen werden in der Regel zentral implementiert und gelten in der Regel für alle Workloads in einem Portfolio. Für einige Workloads gelten möglicherweise besondere Sicherheitsanforderungen, die zu Änderungen der Architektur führen können.

Jedes dieser Kriterien dient als Indikator für eine potenzielle Migrationssperre. In den meisten Fällen können Sie das Kriterium nach der Migration der Workload beheben, indem Sie die Größe der Server anpassen, neue Server hinzufügen oder andere Änderungen vornehmen. Trifft jedoch eines der Kriterien vor der Migration einer Workload zu, entfernen Sie die Workload aus dem Migrationsdurchlauf, und bewerten Sie sie einzeln.

Azure Well-Architected Framework und Azure Well-Architected Review können diese Gespräche mit dem technischen Besitzer einer bestimmten Workload unterstützen, um alternative Optionen für die Bereitstellung des Workloads in Betracht zu ziehen.

Der Workload wird dann in Ihrem Plan zur Cloud-Einführung als Umstrukturierungs- oder Modernisierungsaufwand eingestuft. Aufgrund des zusätzlichen Zeitaufwands für die Neugestaltung eines Workloads sollten Sie diese alternativen Workload-Übernahmepfade unabhängig vom Migrationsprozess betrachten.

Architektur-Prüfliste

Sie können die folgende Prüfliste verwenden, um sicherzustellen, dass Sie wichtige architektonische Überlegungen berücksichtigen:

• Vergewissern Sie sich, dass Ihre Architektur SLAs für Verfügbarkeit, Notfallwiederherstellung und Datenwiederherstellung erfüllt.
• Vergewissern Sie sich, dass Sie die Methoden für die Netzwerksegmentierung auf Ihren Netzwerkentwurf angewendet haben.
• Vergewissern Sie sich, dass Sie die Überwachung und Protokollerfassung geplant haben.
• Vergewissern Sie sich, dass ihre virtuellen Computer entsprechend für die tatsächliche Computerzeit angepasst werden, die Sie benötigen.
• Vergewissern Sie sich, dass ihre Datenträger entsprechend der tatsächlichen Größe und Leistung angepasst werden, die Sie benötigen.
• Vergewissern Sie sich, dass Sie bei Bedarf Lastenausgleichsdienste geplant haben. Die Dienste können Instanzen von Azure Load Balancer, Azure Application Gateway, Azure Front Door oder Azure Traffic Manager umfassen.
• Vergewissern Sie sich, dass Sie bei Bedarf Souveränitäts- und Confidential Computing-Anforderungen geplant haben.

Nächster Schritt

Bereitstellen von Migrationsworkloads