Entwerfen der Workloadarchitektur vor der Migration

In diesem Artikel werden der Prozess und die Überlegungen zum Entwerfen des beabsichtigten migrierten Zustands einer Workload in der Cloud beschrieben. Der Artikel überprüft Aktivitäten, die Teil der Definition der Architektur einer Workload innerhalb einer Iteration sind.

Der Artikel über inkrementelle Rationalisierung weist darauf hin, dass einige Architekturannahmen Teil jeder Unternehmenstransformation sind, die eine Migration umfasst. In diesem Artikel werden typische Annahmen erläutert. Es weist auch auf einige Hindernisse hin, die Sie vermeiden können, und identifiziert Möglichkeiten, den Geschäftswert zu steigern, indem architektonische Annahmen infrage gestellt werden. Dieses inkrementelle Modell für das Entwerfen der Architektur hilft Teams, schneller zu arbeiten und schneller Geschäftsergebnisse zu erzielen.

Gestaltung der Basisarchitektur basierend auf allgemeinen Annahmen

Die folgenden Annahmen sind typisch für alle Migrationsanstrengungen:

• Gehen Sie von einer IaaS-Workload (Infrastructure-as-a-Service) aus. Das Migrieren von Workloads umfasst in erster Linie das Verschieben von Servern aus einem physischen Rechenzentrum in ein Cloud-Rechenzentrum über eine IaaS-Migration. Der Prozess erfordert in der Regel eine minimale Neuentwicklung oder Neukonfiguration. Dieser Ansatz wird als Lift & Shift-Migration bezeichnet.
• Halten Sie die Architektur konsistent. Das Vornehmen von Änderungen an der Kernarchitektur während einer Migration erhöht die Komplexität erheblich. Durch das Debuggen eines geänderten Systems auf einer neuen Plattform werden viele Variablen eingeführt, die schwer zu isolieren sind. Workloads sollten nur geringfügige Änderungen während der Migration durchlaufen, und alle Änderungen sollten gründlich getestet werden.
• Planen der Größenänderung von Ressourcen Gehen Sie davon aus, dass nur wenige lokale Anlagen eine Ressource voll ausschöpfen. Vor oder während der Migration werden die Ressourcen größentechnisch angepasst, um den tatsächlichen Nutzungsanforderungen am besten zu entsprechen. Tools wie Azure Migrate und Modernize bieten eine Größenanpassung basierend auf der tatsächlichen Verwendung.
• Erfassen von Anforderungen für Geschäftskontinuität und Notfallwiederherstellung (BCDR). Wenn Sie über einen vereinbarten Servicelevelvertrag (SLA) für die bereits mit dem Unternehmen ausgehandelte Workload verfügen, verwenden Sie die SLA nach der Migration zu Azure weiterhin. Wenn eine SLA noch nicht festgelegt ist, definieren Sie eine, bevor Sie die Workload in der Cloud entwerfen, um sicherzustellen, dass Sie ordnungsgemäß entwerfen.
• Planen der Ausfallzeiten bei der Migration Ähnlich wie das Nichterfüllen von SLA-Anforderungen können Ausfallzeiten, die auftreten, wenn Sie eine Arbeitslast in die Produktion überführen, sich nachteilig auf das Unternehmen auswirken. Manchmal müssen Lösungen, die mit minimalen Ausfallzeiten übergehen müssen, Architekturänderungen vornehmen. Bevor Sie mit der Veröffentlichungsplanung beginnen, gehen Sie davon aus, dass ein allgemeines Verständnis der Anforderungen an Ausfallzeiten festgelegt ist.
• Definieren von Benutzer- und Anwendungsdatenverkehrsmustern. Vorhandene Lösungen können von vorhandenen Netzwerkroutingmustern und -lösungen abhängen. Identifizieren Sie die Ressourcen, die Sie benötigen, um die aktuelle Netzwerknutzung zu unterstützen.
• Plan zur Vermeidung von Netzwerkkonflikten. Wenn Sie Rechenzentren in einem einzelnen Cloudanbieter konsolidieren, erstellen Sie wahrscheinlich Konflikte in Domain Name System (DNS) oder anderen Netzwerkstrukturen. Während der Migration ist es wichtig, diese Konflikte zu vermeiden, um Unterbrechungen von Produktionssystemen zu vermeiden, die in der Cloud gehostet werden.
• Planen von 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.

Entwurf der Architektur für eine Landezone

In der Phase Bereit des Cloud Adoption Frameworks hat Ihre Organisation gemeinsam genutzte Plattformdienste im Rahmen der Einführung von Azure-Zielzonen bereitgestellt. In Vorbereiten Ihrer Zielzone für die Migration haben Sie die Zielzone für den Empfang migrierter Workloads vorbereitet.

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

• Hybridkonnektivität verbindet Ihre Azure-Netzwerke mit Ihren lokalen Netzwerken.
• Netzwerksicherheitsgeräte wie Azure Firewall übernehmen die Überprüfung des Datenverkehrs außerhalb Ihrer Arbeitslast.
• Azure-Richtlinien zum Erzwingen von Governancepraktiken wie Protokollierungsanforderungen, zulässigen Regionen, unzulässigen Diensten und anderen Steuerelementen sind aktiv.
• Ein Azure Monitor Logs-Arbeitsbereich für die gemeinsame Protokollierung wurde in Azure Monitor eingerichtet.
• Es müssen freigegebene Identitätsressourcen zur Unterstützung von in die Domäne eingebundenen Servern oder anderen Identitätsanforderungen eingerichtet werden.

Wenn diese Migrationsgrundlagen nicht eingerichtet sind, sollte Ihre Organisation sofort zur Phase "Bereit" zurückkehren, um diese Bedürfnisse zu bearbeiten. Ohne diese Komponenten hat Ihre Migration wahrscheinlich Verzögerungen und Rückschläge und ist weniger erfolgreich.

Der von Ihnen entworfene Workload ist ein Abonnement zugewiesen (idealerweise über einen Abonnementverkaufsprozess). Das Abonnement kann mehrere Workloads oder nur eine Workload enthalten, je nachdem, wie Ihre Organisation ihre Ressourcenorganisation für Workloads eingerichtet hat. Wenn Sie eine Workload mit vielen Anwendungsumgebungen migrieren, verfügen Sie möglicherweise sogar über mehrere Abonnements. Dies entspricht den Leitfäden für Anwendungsumgebungen.

Entwerfen der Netzwerkarchitektur von Workload

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 der Anleitung 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 das N-Tier-Architekturhandbuch verwenden, um diese Ressourcen in Azure zu planen.

Entwerfen von Arbeitslastabhängigkeiten

Ihre Migrationsbewertungstools sollten Ihnen eine Möglichkeit bieten, Abhängigkeitsanalysen vorzunehmen, wie Abhängigkeitsanalyse in Azure Migrate und 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 zwischen Workloads berücksichtigen. Beispielsweise benötigen einige Arbeitslasten möglicherweise eine häufige Kommunikation. Wenn dies der Fall ist, trägt die Planung Ihrer Migrationswellen und Abhängigkeiten dazu bei, diese Anforderung zu berücksichtigen und Ihre Migration erfolgreich zu machen.

Sie können Anleitungen im Azure Architecture Center verwenden, z. B. für Speichen-zu-Speichen--Netzwerk, um zu entwerfen, wie miteinander verbundene Workloads nach der Migration funktionieren.

Vorbereiten der Einführung vertraulicher Computer

Eine Teilmenge Ihrer Workloads mit Souveränitätsanforderungen kann dazu führen, dass vertrauliche Computer verwendet werden. Als Teil der Bereitstellung einer souveränen Landezone werden Verwaltungsgruppen für vertrauliches Computing erstellt.

Innerhalb eines Souveränitätskontexts erfordert die Verwendung vertraulicher Computer Azure Key Vault und vom Kunden verwaltete Schlüssel als unterstützenden Dienst. Weitere Informationen finden Sie unter Verschlüsselung mit vom Kunden verwalteten Schlüsseln in Microsoft Cloud for Sovereignty.

Aktualisieren Ihrer anfänglichen Cloud-Schätzung

Wenn Sie Ihr Architekturdesign abgeschlossen haben, überprüfen Sie Ihre Cloudschätzung, um sicherzustellen, dass Sie sich noch im geplanten Budget befinden. 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 Modernisieren verwenden können, um detaillierte Kostenverwaltungsübungen durchzuführen, sollten Sie Ihre Schätzungen regelmäßig erneut überprüfen, während Sie Ihren Architekturentwurf anpassen.

Wenn Sie mit herkömmlichen IT-Beschaffungsprozessen vertraut sind, könnte die Schätzung von Ressourcen in der Cloud fremd erscheinen. Wenn Sie Cloudtechnologien einführen, wechselt der Erwerb von einem starren strukturierten Kapitalkostenmodell zu einem dynamischen Betriebsausgabenmodell. Die Planung einer Migration in die Cloud ist häufig das erste Mal, dass eine Organisation oder ein IT-Team mit dieser Veränderung konfrontiert wird.

Im herkömmlichen Kapitalkostenmodell versucht ein IT-Team, Die Kaufkraft für mehrere Workloads in verschiedenen Programmen zu kombinieren. Dieser Ansatz zentralisiert einen Pool gemeinsam genutzter IT-Ressourcen, die jede dieser Lösungen unterstützen können. Im Cloudmodell für Betriebsausgaben können die Kosten direkt den Supportanforderungen einzelner Workloads, Teams oder Geschäftseinheiten zugeordnet werden. Sie bietet einer Organisation eine direktere Zuordnung von Kosten zu internen Kunden und den von ihnen unterstützten Geschäftszielen. Dieser dynamischere Ansatz für das Finanzmanagement wird häufig als FinOps bezeichnet. Obwohl FinOps keine azurespezifische Berücksichtigung ist, kann es hilfreich sein, ein erweitertes Verständnis von FinOps zu haben. Weitere Informationen finden Sie unter Was ist FinOps?.

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

Außerdem sollten Sie nach der Migration Ihrer Workload weiterhin daran arbeiten, die Workloadkosten zu optimieren. Weitere Informationen dazu, wie Organisationen ihre Kostenmanagementfähigkeiten reifen können, finden Sie unter Verbessern der Kostenmanagementdisziplin.

Wissen, wann Ihre Architektur geändert werden soll

Migrationen konzentrieren sich in der Regel auf die Aufrechterhaltung einer vorhandenen Architektur und die Umstellung auf Ihre Cloudplattform. Es gibt jedoch Situationen, in denen Sie Ihre Arbeitsauslastung möglicherweise neu erstellen müssen, auch für die Migration. Diese Liste enthält Beispiele dafür, wann Sie vor der Migration möglicherweise Architekturänderungen vornehmen müssen:

• Begleichung der technischen Schuld. Einige ältere Workloads haben hohe technische Schulden. Technische Schulden können zu langfristigen Herausforderungen führen, indem die Hostingkosten bei jedem Cloudanbieter erhöht werden. Wenn technische Schulden unnatürlich die Hostingkosten erhöhen, sollten Sie alternative Architekturen auswerten.
• Verbesserung der Zuverlässigkeit. Standardbetriebsbasispläne bieten ein gewisses Maß an Zuverlässigkeit und Wiederherstellung in der Cloud. Einige Arbeitsauslastungsteams erfordern möglicherweise höhere SLAs, was zu Architekturänderungen führen könnte.
• Kostenintensive Workloads Während der Migration sollten Sie alle Ressourcen optimieren, um die Größe an der tatsächlichen Nutzung auszurichten. Einige Workloads erfordern möglicherweise Architekturänderungen, um bestimmte Kostenprobleme zu beheben.
• Leistungsanforderungen. Wenn sich die Arbeitsauslastung direkt auf das Unternehmen auswirkt, kann eine zusätzliche architektonische Berücksichtigung erforderlich sein.
• Sichere Anwendungen. Sicherheitsanforderungen werden in der Regel zentral implementiert und in der Regel auf alle Workloads in einem Portfolio angewendet. Einige Workloads verfügen möglicherweise über bestimmte Sicherheitsanforderungen, die zu Architekturänderungen führen können.

Jedes dieser Kriterien dient als Indikator für ein potenzielles Migrationshindernis. In den meisten Fällen können Sie das Kriterium beheben, nachdem Sie die Workload migriert haben, indem Sie Server mit der rechten Größe anpassen, neue Server hinzufügen oder andere Änderungen vornehmen. Wenn jedoch eines dieser Kriterien erforderlich ist, bevor Sie eine Workload übertragen, dann entfernen Sie die Workload aus der Migrationswelle und bewerten Sie sie einzeln.

Das Azure Well-Architected Framework und Azure Well-Architected Review kann ihnen helfen, Unterhaltungen mit dem technischen Besitzer einer bestimmten Workload zu führen, um ihnen bei der Auswahl alternativer Optionen für die Bereitstellung der Workload zu helfen.

Die Workload wird dann in Ihrem Cloud-Einführungsplan als Umbruch- oder Modernisierungsaufwand klassifiziert. Aufgrund der zusätzlichen Zeit, die es erfordert, eine Workload neu zu gestalten, sollten Sie diese Alternativen zur Einführung von Workloads als getrennt vom Migrationsprozess in Betracht ziehen.

Checkliste für Architektur

Sie können die folgende Checkliste verwenden, um sicherzustellen, dass Sie kritische Architekturaspekte 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 Maschinen in der Größe entsprechend der tatsächlichen benötigten Rechenzeit angepasst sind.
• Vergewissern Sie sich, dass Ihre Datenträger in Bezug auf die tatsächliche Größe und Leistung, die Sie benötigen, richtig dimensioniert sind.
• 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 enthalten.
• Vergewissern Sie sich, dass Sie bei Bedarf souveränitäts- und vertrauliche Computeranforderungen geplant haben.

Nächster Schritt

Bereitstellen von Migrationsworkloads