Frage Virtualisierung Fallstricke / Lessons Learned


Was sind einige Fallstricke oder Lektionen, die nach dem Konvertieren vorhandener Hardware in eine virtualisierte Umgebung gelernt wurden? Gibt es irgendetwas, das Sie zu virtualisieren versucht haben, aber nie wieder tun wird?


23
2018-06-10 17:37


Ursprung


Vielleicht sollte dies ein Community-Wiki sein. - jtimberman


Antworten:


Werfen Sie IMMER alle virtuellen Medien (CD / DVD / Floppy) aus, wenn Sie damit fertig sind, da dies häufig dazu führt, dass vMotion in seinen Tracks nicht mehr funktioniert.

Erhalten Sie Ihre NTP und DNS-Einstellungen richtig, das wird Sie davor bewahren, über Selbstmord nachzudenken :)

Sie können nie genug Speicher oder Speicher haben.

Stellen Sie sicher, dass Sie über einen Remote-Zugriff ohne Betriebssystem auf Ihre Maschinen wie das iLO-System von HP zugreifen können.

Halten Sie ein Repository von OS / App. ISO-Dateien.

Keine direkte Antwort auf Ihre Frage, aber in der Hoffnung, dass sich jemand in Zukunft die Haare ausreißt, wenn er diese Antwort findet - HP Blade Server werden nicht standardmäßig mit ihrem VT-Bit ausgeliefert, Sie müssen dies aktivieren es im BIOS (F9). Ohne dies wirft ESX 3.5U4 keinen nützlichen Fehler, nein es hängt nur vor der Code-Installation :(


14
2018-06-10 17:55



Es ist nicht nur Sie, ich denke, die meisten Prozessoren haben ihre VT standardmäßig aktiviert. Zumindest die anfängliche Panik erspart Ihnen die Tasse Kaffee! - Kara Marfia
+1 für mehr Speicher. Es sieht so aus, als ob wir immer neue VMs aufstellen und wir haben viel von CPU zu umgehen (auch mit relativ langsamen 2,3 GHz CPUs), aber sehr wenig RAM! - Matt Rogish
Für HPs iLO erhalten Sie die große Lizenz. Die Basislizenz gibt Ihnen nach dem Start des Bootloaders keinen Konsolenzugriff. Mit der Basislizenz können Sie nur den Strom einschalten (und eine Verbindung zur seriellen Schnittstelle herstellen) und nicht viel mehr. Ein getty auf einem seriellen Port hat nichts an einem echten Konsolenport. (Mit Sparc erhalten Sie jedoch eine echte Konsole auf der seriellen Ebene, und Suns Pendant zu iLO hat eine Konsole ohne zusätzliche Lizenz). - Thomas


Um die gestellte Frage zu beantworten - Fallstricke im Zusammenhang mit P2V-Migrationen.

Erstens - P2V-Migrationen funktionieren größtenteils sehr gut. Je sauberer und neuer die Systeme, desto besser, aber selbst bei der Migration von alten (NT4-Systemen) lag meine Erfolgsquote nach mehr als hundert Migrationen in einer Reihe von Umgebungen bei etwa 90%. Das sind Systeme, die migriert und am Tag (naja, meist nachts) an die Produktion übergeben wurden. Ich hatte immer nur ein System, das wir nach einer scheinbar erfolgreichen Migration ausschalten mussten - eine SQL-Box, die mehr CPU-Leistung benötigte, als die Plattform je liefern könnte. VMware Converter ist gut und kostenlos (für die Nicht-Enterprise-Version), Platespin ist sehr gut (aber teuer).

Das heißt - es gibt Dinge zu vermeiden.

MSCS-Cluster. Sie können sie zum Laufen bringen, aber es ist nie eine großartige Idee und Microsoft wird Ihnen fast sicher nicht helfen, wenn Sie später Probleme haben. Erstellen Sie stattdessen neue eigenständige Systeme.

Große SQL Server - Schwerpunkt auf großen. Diese sollten vorher von einer CPU-Anforderungs-POV rot markiert werden, aber nicht versucht sein, eine zu verschieben, wenn Sie nicht sicher sind, dass die Ziel-VM über ausreichend CPU-Headroom verfügen wird.

Wenn Sie vorhaben, Systemnamen oder IP-Adressen (oder beides) während der Migration zu ändern, sollten Sie zuerst überlegen, ob Sie das nicht tun. Wenn Sie absolut keine Wahl haben, stellen Sie sicher, dass Sie wissen, wie sich diese Änderungen auswirken Systeme in Frage. Meine schlimmste Migration war ein RSA ACE-Server, der zur Authentifizierung eines DMZ-lokalisierten VPNs verwendet wurde, bei dem der Client meine Einwände ablehnte und darauf bestand, sowohl den Namen als auch die IP-Adresse während der Migration zu ändern.

Bezogen auf das oben genannte - wenn Sie etwas anderes als ein komplett flaches Netzwerk haben, dann bauen Sie einige Test-VMs und stellen Sie 100% sicher, dass Ihre VM-Netzwerke die physischen, von denen Sie migrieren, perfekt replizieren.

Stellen Sie in Windows AD-Umgebungen immer sicher, dass Sie über ein lokales Administratorkonto für die zu migrierende Box verfügen. Und testen Sie es vor der Migration.

Stellen Sie sicher, dass Sie eine gute Vorstellung davon haben, wie lange die Dinge dauern werden. Die P2V-Kopierzeiten variieren (abhängig von der verfügbaren Netzwerkbandbreite), können aber auch stark von der Anzahl der Dateien in jedem zu migrierenden Volume beeinflusst werden. Dies ist insbesondere ein Problem bei der Migration von NT4 * -Systemen durch Platespin, wirkt sich jedoch auf das Kopieren von P2V-Software auf Dateiebene aus (was in der Regel zutrifft, wenn Sie die Größe von Volumes ändern). Kopierraten von 70-80 Megabyte pro Sekunde sind mit GigE-Netzwerken möglich, relativ schnelle Quelle und eine gute Zieleinrichtung, aber 20-30 Megabyte / Sek. Ist typischer und für die oben genannten NT-Systeme mit 100Meg-Netzwerken und vielen Dateien habe ich Kopierraten gesehen Drop-Down in den Bereich 50 Kilobyte / Sek.

  • Im Idealfall würden Sie diese loswerden, aber einige Leute haben nicht diesen Luxus und ein solches Betriebssystem der völlig irreparablen Hardware zu bekommen, ist wahrscheinlich fast immer eine gute Idee.

13
2018-06-10 22:12





  • Stellen Sie eine solide Backup-Strategie bereit. Entscheiden Sie, ob Sie gehen um die VM zu sichern, als ob sie auf Bare Metal wäre, oder wenn Sie es tun Sichern Sie die virtuellen Festplatten in den Datenspeichern (oder beiden). Allgemein Ich habe festgestellt, dass mein erforderlicher Backup-Footprint zugenommen hat zunächst deutlich, also seien Sie auf einen anfänglichen Spike vorbereitet Dort könnten Sie sowohl eine alte physische Maschine als auch eine neue VM sichern bevor du alle Knicke durchgearbeitet hast.
  • VM Sprawl ist auch etwas, auf das man achten sollte. Sobald die Virtualisierung startet, wird der Drang, alles auf die VM zu verschieben, groß. Während dies funktionieren kann, haben Sie wahrscheinlich nicht sofort genug Hardware bestellt.
  • Ich denke, es gibt Maschinen, die nicht konvertiert werden können, und andere Maschinen, die wahrscheinlich sollte nicht konvertiert werden. Während es schön ist, ein 10 Jahre alte physische Maschine und klonen es auf eine VM, mit Warzen und allem, Es gibt sicherlich Szenarien, in denen es besser wäre, ein Gebäude zu bauen
    säubern OS und migriert Objekte von der physischen Maschine über. Manchmal Sie sind besser dran, nicht über die Spinnweben zu konvertieren.
  • Bereiten Sie sich darauf vor, viele Netzwerk-Ports zu verwenden. Wenn Sie Systeme haben, die auf verschiedenen VLANs ausgeführt werden, während einzelne Ports bündelfähig sind, möchten Sie wahrscheinlich individuelle Ports für Ihre VLANs haben, die in Ihren vSwitch eingespeist werden. Wenn Sie Redundanz wünschen und iSCSI verwenden, könnten Sie sich viele NICs ansehen.

8
2018-06-10 20:12





Aus meiner Erfahrung, seien Sie sehr vorsichtig mit Ihrem Speichermedium. Wir gingen mit einem iSCSI-SAN, das nur 100Mbit-Verbindungen unterstützt. Eine VM auf dem System zu betreiben, war nicht schlecht, zwei waren weniger angemessen ... und als wir unser Ziel von 8 VMs erreichten, waren sie schrecklich.

Meine persönliche Lektion gelernt: Überprüfen Sie die bewerteten IOPS und lesen Sie mehr Bewertungen zu einem Produkt die sich auf die Art beziehen, wie Sie das Speichergerät verwenden möchten

Eine weitere nützliche Sache, die ich gelernt habe ... Das Erstellen eines "Backup" -Diskettenimages nach einer Basisinstallation und -härtung beschleunigt den Aufbau jedes anderen Systems und ist eine sehr praktische Sache, die man behalten kann.


7
2018-06-10 18:10





Versuchen Sie nicht, Produktionsdatenbankserver in einer virtuellen Umgebung auszuführen. Die Gemeinkosten für E / A sind nicht akzeptabel. Wir hatten riesige Probleme, als unser DBA unseren primären MSSQL-Server virtualisieren ließ. Die Abfrage dauerte Tausende von Millisekunden. Als wir sie davon überzeugten, sie wieder in eine spezielle Box zu verschieben, gab es eine Steigerung von Durchsatz und Geschwindigkeit um 10.000%.


6
2018-06-10 23:00





Verwenden Sie redunant network für vmotion / vmkernel-Verkehr. Sie möchten nicht, dass virtuelle Maschinen heruntergefahren werden, nur weil ein Switch neu gestartet wurde.

Oh, und lassen Sie einen DC / DNS / DHCP-Server aus der Virtualisierung heraus. Ihre Benutzer werden Sie weniger hassen, wenn Sie einen großen SAN-Absturz bekommen.


6
2018-06-12 12:21



+1 für nicht virtualisierte Basis-Netzwerkdienste - ich würde NIS in diese Liste aufnehmen. Ich mag es auch, den zentralen Syslog-Server als nichtvirtualisiert zu betrachten, so dass, wenn alles stirbt, Sie eine bessere Chance haben, herauszufinden, was schief gelaufen ist. - David Mackintosh
Guter Punkt, Management-Server (wie VCenter vCenter) sollten nicht virtualisiert werden (ja, es ist möglich, aber nicht tun). - pauska


Falls Sie noch keine haben - Führen Sie vor der Migration eine vollständige Sicherung der physischen Maschine durch. Ein Image ist wahrscheinlich das beste und / und eine ASR / Systemwiederherstellung oder was auch immer, das Ihnen einen kompletten System-Snapshot bietet, anstelle der üblichen Inhaltssicherung, die die meisten Maschinen haben.

P2V-Tools können unerwartet auf Sie zurückschießen und den physischen Rechner ruinieren (ich hatte den VMWare-Konverter zum Töten eines Rechners, den ich einmal mit P2V versucht hatte, zum Glück war es nur eine Testmigration). Seien Sie darauf vorbereitet, das System von Grund auf neu zu erstellen. Ja, das ist vielleicht eine 1000 zu 1 Chance, aber willst du das sein?


5
2018-06-10 20:56