Einführung in das Thema Azure Migrate
Ich möchte in diesem Beitrag auf Azure Migrate eingehen, insbesondere auf die Migration von virtuellen Maschinen die On Premises auf VMware oder Hyper-V laufen.
Azure Migrate baut im Hintergrund auf Azure Site Recovery auf. Site Recovery ist die Lösung, die über einen Agenten eine VM von einer «Site» in eine andere «Site» repliziert und somit im Desaster Fall einen schnellen Wechsel auf die sekundäre Site erlaubt. Site steht hierfür für einen Standort.
Bei Azure Site Recovery geht’s in den meisten Fällen daher darum eine VM vom Boden nach Azure zu bringen. Azure Site Recovery (ASR) kann auch genutzt werden, um eine VM über Azure Regionen zu replizieren.
Daher ist Site Recovery als Desaster Lösung positioniert, Azure Migrate jedoch als Migrations- Werkzeug. Während Site Recovery in der Lage ist einen Workload immer wieder von A nach B und von B nach A zu bringen, sieht das Azure Migrate prinzipiell nicht vor. Azure Migrate ist als Einbahnstrasse nach Azure ausgeleg
Azure Migrate dient nun als ein Migrations- Cockpit, das den ganzen technischen Prozess für den Anwender einfacher gestalten soll.
Neben der Möglichkeit VMs migrieren zu können, beherrscht Azure Migrate auch Datenbanken, VDI Umgebungen und Web Applikationen.
Wie jedoch bereits erwähnt, werde ich in diesem Beitrag lediglich auf VMs eingehen.
Lift & Shift oder lieber neu?
Es grundsätzlich 2 verschiedene Konzepte, um mit den Systemen am Boden nach Azure zu kommen.
- Lift & Shift
Lift & Shift fällt in die Kategorie Azure Migrate. Das bedeutet, dass man Systeme am Boden erfasst, auswertet und diese dann über eine Replikation nach Azure bringt.
Dies hat den Vorteil, dass die Systeme so in Azure ankommen, wie sie am Boden sind. Zugleich ist dies aber auch ein riesiger Nachteil da die Systeme, während dem Übergang nicht angefasst werden können. Der grösste Nachteil ist hier die Einhaltung einer Namenskonvention wie ich schon in diesem Artikel ausführlich erklärt habe: Azure Grundlagen – Namenskonvention - Neu bauen
Auch wenn dies die meisten erschrecken mag, ist neu bauen eine Chance Altlasten loszuwerden und vor allem auch auf neue Technologien wie PaaS und SaaS aufzuspringen. Es kann auch eine Variante sein, dass neu bauen nach einem Lift & Shift passiert, also zuerst alles nach Azure bringen und anschliessend neu bauen und transformieren.
Hypervisor On Premises
Microsoft hat über Jahre einen harten Kampf an der Hypervisor Front geführt. VMware hat den On Premises Markt seit jeher dominiert und dem wollte Microsoft mit dem eigenen Produkt Hyper-V entgegenstellen. Ich selbst habe in meiner Rolle als PFE bei Microsoft über Jahre die Fahne für Hyper-V hochgehalten und insbesondere in der Schweiz, wo nicht immer der Preis entscheidend ist, viel Überzeugungsarbeit leisten müssen.
Bei Microsoft haben sich durch die Cloud jedoch die Prioritäten geändert und dies macht sich hier deutlich bemerkbar. On Premises hat noch eine untergeordnete Rolle und ich glaube da erschrecke ich auch niemanden mit der Aussage. Wenn es dann noch zu Virtualisierung kommt, insbesondere in mittleren und grösseren Umgebungen mit System Center, dann wird es leider etwas schwierig.
VMM vs vCenter
Dies soll hier auch kein Vergleich der Hypervisor werden. Ich bin der Meinung, dass es ziemlich egal ist ob Hyper-V, VMware, KVM, Open Stack, virtualisieren können alle Produkte gut.
Der grosse Unterschied bei all diesen Lösungen ist das Management derer. Bei VMware ist es, dass vCenter und bei Microsoft steht dem System Center Virtual Machine Manager, kurz VMM gegenüber.
Es hat aus Sicht Microsoft absolut Sinn gemacht für das Management die System Center Suite herzunehmen, waren doch viele Management Systeme in Form von SCCM, SCOM schon vorhanden. Während man also im Microsoft Umfeld einmal den ganzen System Center Stack erlernen musste, um halbwegs ein Management zu erhalten, ist dies bei VMware anders.
VMware hat mit ihrem vCenter eine Management Lösung hingestellt die explizit nur für ihren Hypervisor gebaut wurde und daher jedem System Admin in die Hände spielt- alles an einem Ort, ein Produkt, eine Konsole und intuitiv aufgebaut. Kurzum, jeder Junior Admin hat nach einigen Stunden das Basis Management mit VMware im Griff.
Der VMM und das vCenter unterscheiden sich in einem Punkt auch noch grundsätzlich und dies macht die Story nicht einfacher.
Das vCenter ist ein «Live» Management System. Will heissen, was ich sehe und was ich an dem System verändere, passiert umgehend und ich kriege auch umgehend Feedback von dem System zurück.
VMM ist kein Live Management System. Der VMM arbeitet über seine Agents auf den Hyper-V Systemen im Push-Pull Betrieb. Will heissen, der VMM holt sich über den Agenten die Infos auf dem System, schreibt die Info in eine Datenbank und präsentiert das Ergebnis dann in der Konsole. Das gleiche in die andere Richtung, wenn man was einstellt in der Konsole.
In einer perfekten Welt würde dies nicht auffallen, doch was ist, wenn der VMM Probleme hat die Infos zu holen- was zeigt er uns dann? Genau- die letzte Information, die in der Datenbank steht und diese ist meistens die falsche. Daher hört man auch viel, dass der VMM «lügt». Korrekt wäre, er weiss es einfach nicht besser.
Dies führt dann im Support auch dazu, dass man zuerst mal den VMM missachtet und auf den Failover Cluster Manager oder den Hyper-V Manager wechselt- da dort die Daten in Echtzeit daherkommen.