Das Unternehmen Maxnet Systems verwendete lange Zeit die kostenlose Version von VMware - ESXi ab Version 5.0 als Hypervisor. Die kostenpflichtige Version von vSphere hat das Lizenzmodell abgeschreckt, während die kostenlose Version eine Reihe von Nachteilen aufwies, die in der kostenpflichtigen Version nicht verfügbar waren, die Sie jedoch in Kauf nehmen konnten. Als sich jedoch in den neuen Versionen von ESXi die neue Weboberfläche weigerte, mit der alten zu arbeiten, und die Überwachung von RAID-Arrays keine Lebenszeichen mehr zeigte, entschied sich das Unternehmen für eine universellere und offenere Lösung. Das Unternehmen hatte bereits gute Erfahrungen und einen guten Eindruck von LXC - Linux Containers. Daher wurde klar, dass der Traumhypervisor hybride sein und KVM und LXD für unterschiedliche Belastungen kombinieren wird - eine evolutionäre Fortsetzung von LXC. Auf der Suche nach Informationen über KVM wurde das Unternehmen mit Missverständnissen, Rechen und schädlichen Praktiken konfrontiert, aber Tests und Zeit haben alles in Ordnung gebracht.
Lev Nikolaev (
Maniaque ), Administrator und Entwickler hochgeladener Systeme, Trainer für Informationstechnologie, wird darüber informieren, wie man mit dem Wechsel von ESXi zu KVM
umgeht und kein Rad auf einem Rechen
fährt . Lassen Sie uns über das Netzwerk, Repositorys, Container, KVM, LXD, LXC, Bereitstellung und praktische virtuelle Maschinen sprechen.
Prolog
Wir werden die Schlüsselgedanken sofort identifizieren und sie dann genauer analysieren.
Netzwerk. Während die Geschwindigkeit Ihrer Schnittstellen 1 Gbit / s nicht überschreitet, reicht Bridge für Sie aus. Sobald Sie mehr drücken möchten, werden Sie eingeschränkt.
Repository. Erstellen Sie einen gemeinsam genutzten Netzwerkspeicher. Selbst wenn Sie nicht bereit sind, 10 Gbit / s im Netzwerk zu verwenden, erhalten Sie mit 1 Gbit / s 125 MB / s Speicherplatz. Für eine Reihe von Lasten reicht dies mit einem gewissen Spielraum aus, und die Migration virtueller Maschinen ist eine elementare Angelegenheit.
Container oder KVM? Vor- und Nachteile, Fallstricke. Welche Arten von Ladungen werden am besten in einem Container platziert und welche verbleiben am besten in einer KVM?
LXD oder LXC . Ist LXD LXC? Oder eine andere Version? Oder ein Add-On? Worum geht es hier? Lassen Sie uns Mythen zerstreuen und die Unterschiede zwischen LXD und LXC verstehen.
Bequeme Bereitstellung . Was ist bequemer: Nehmen Sie jedes Mal das gleiche Image oder installieren Sie das System von Grund auf neu? Wie geht das jedes Mal schnell und genau?
Praktische virtuelle Maschine. Es wird Gruselgeschichten über Bootloader, Partitionen und LVM geben.
Verschiedenes . Viele kleine Fragen: Wie kann man eine virtuelle Maschine schnell von ESXi auf KVM ziehen, wie kann man gut migrieren, wie kann man Festplatten richtig virtualisieren?
Grund für den Umzug
Woher kam die verrückte Idee, von ESXi zu KVM / LXD zu wechseln? ESXi ist bei kleinen und mittleren Unternehmen beliebt. Dies ist ein guter und billiger Hypervisor. Aber es gibt Nuancen.
Wir haben mit Version 5.0 begonnen - bequemerweise funktioniert alles! Die nächste Version 5.5 ist dieselbe.
Seit Version 6.0 ist es schon schwieriger. Unter ESXi wurde die Weboberfläche erst ab Version 6.5 sofort kostenlos, bevor ein Dienstprogramm für Windows erforderlich war. Wir lassen uns damit abfinden. Wer OS X ausführt, kauft Parallels und installiert dieses Dienstprogramm. Dies ist ein bekannter Schmerz.
Die Überwachung blinkte regelmäßig. Es war notwendig, die Verwaltungsdienste in der Serverkonsole neu zu starten - dann wurde CIM Heartbeat erneut angezeigt. Wir haben es ausgehalten, da er nicht immer abgefallen ist.
ESXi 6.5 Version - Müll, Abfall und Gräueltaten. Schrecklicher Hypervisor. Und hier ist warum.
- Angular fällt mit Ausnahme des Eingangs zur Weboberfläche aus. Sobald Sie Ihren Benutzernamen und Ihr Passwort eingeben - sofort eine Ausnahme!
- Die Möglichkeit, den Status des RAID-Arrays aus der Ferne zu überwachen, funktioniert nicht, da dies für uns praktisch ist. Früher war es praktisch, aber in Version 6.5 ist alles schlecht.
- Schwache Unterstützung für moderne Netzwerkkarten von Intel . Netzwerkkarten von Intel und ESXi verursachen Schmerzen. Es gibt einen qualvollen Thread im ESXi-Support-Forum dazu. VMware und Intel sind keine Freunde und die Beziehungen werden sich in naher Zukunft nicht verbessern. Das Traurige ist, dass selbst Kunden mit kostenpflichtigen Lösungen Probleme haben.
- Keine Migration innerhalb von ESXi . Kopieren und starten Sie den Vorgang, es sei denn, die Migration wird als Pause angesehen. Wir machen eine Pause, kopieren es schnell und starten es an einem anderen Ort. Aber es ist unmöglich, es Migration zu nennen - es gibt immer noch eine einfache.
Nachdem wir uns das alles angesehen hatten, kamen wir auf die verrückte Idee, mit ESXi 6.5 zu wechseln.
Wunschliste
Zunächst haben wir eine Wunschliste für eine ideale Zukunft geschrieben, in die wir gehen werden.
Verwaltung unter SSH und Web und mehr optional. Das Webinterface ist großartig, aber auf einer Geschäftsreise von einem iPhone aus ist es unpraktisch und schwierig, in das ESXi-Webinterface zu gehen und dort etwas zu tun. Daher ist die einzige Möglichkeit, alles zu verwalten, SSH. Es wird keine andere geben.
Windows-Virtualisierung. Manchmal fragen Kunden nach seltsamen Dingen, und unsere Mission ist es, ihnen zu helfen.
Immer frische Treiber und die Möglichkeit, eine Netzwerkkarte zu konfigurieren . Angemessenes Verlangen, aber unter reinem ESXi nicht realisiert.
Live-Migration, kein Clustering . Wir möchten die Möglichkeit haben, Maschinen von einem Hypervisor auf einen anderen zu ziehen, ohne Verzögerungen, Ausfallzeiten oder Unannehmlichkeiten zu spüren.
Die Wunschliste ist fertig, dann hat eine schwierige Suche begonnen.
Mehl der Wahl
Der Markt dreht sich um KVM oder LXC mit verschiedenen Saucen. Manchmal scheint es, dass Kubernetes irgendwo oben ist, wo alles in Ordnung ist, die Sonne und das Paradies, und auf der Ebene darunter gibt es Morlocks - KVM, Xen oder so etwas ...
Zum Beispiel ist Proxmox VE Debian, das vom Kernel von Ubuntu gezogen wurde. Es sieht komisch aus, aber bringt es es in die Produktion?
Unsere Nachbarn unten sind Alt Linux. Sie haben eine schöne Lösung gefunden: Sie haben Proxmox VE als Paket zusammengestellt. Sie setzen das Paket einfach in einen Befehl. Dies ist praktisch, aber wir rollen Alt Linux nicht in die Produktion, daher passte es nicht zu uns.
Nimm KVM
Am Ende haben wir uns für KVM entschieden. Sie haben es nicht genommen, Xen zum Beispiel wegen der Community - KVM hat viel mehr. Es schien, dass wir immer die Antwort auf unsere Frage finden würden. Wir haben später herausgefunden, dass die Größe einer Community keinen Einfluss auf ihre Qualität hat.
Zunächst haben wir berechnet, dass wir eine Bare-Metal-Maschine nehmen, das Ubuntu hinzufügen, mit dem wir arbeiten, und KVM / LXD von oben rollen. Wir haben mit der Fähigkeit gerechnet, Container zu betreiben. Ubuntu ist ein bekanntes System und es gibt keine Überraschungen bei der Lösung von Boot- / Wiederherstellungsproblemen für uns. Wir wissen, wohin wir treten müssen, wenn der Hypervisor nicht startet. Alles ist klar und bequem für uns.
KVM Crashkurs
Wenn Sie aus der Welt von ESXi kommen, werden Sie viele interessante Dinge finden. Lernen Sie drei Wörter: QEMU, KVM und libvirt.
QEMU übersetzt die Wünsche eines virtualisierten Betriebssystems in die Herausforderungen eines regulären Prozesses. Funktioniert fast überall gut, aber langsam. QEMU selbst ist ein eigenständiges Produkt, das eine Reihe anderer Geräte virtualisiert.
Weiter auf der Szene kommt eine Reihe von
QEMU-KVM . Dies ist das Linux-Kernelmodul für QEMU. Die Virtualisierung aller Anweisungen ist teuer, daher haben wir ein KVM-Kernelmodul,
das nur wenige Anweisungen übersetzt . Dies ist erheblich schneller, da nur wenige Prozent der Anweisungen aus dem allgemeinen Satz verarbeitet werden. Dies sind alle Kosten für die Virtualisierung.
Wenn Sie nur QEMU haben, sieht das Starten der virtuellen Maschine ohne Bindung folgendermaßen aus:
$ qemu < >
Blockieren Sie in den von Ihnen beschriebenen Parametern Geräte. Alles ist wunderbar, aber unpraktisch. Daher gibt es libvirt.
Das Ziel von libvirt ist es, ein einziges Werkzeug für alle Hypervisoren zu sein . Es kann mit allem funktionieren: mit KVM, mit LXD. Es scheint, dass es nur bleibt, um die Syntax von libvirt zu lernen, aber in Wirklichkeit funktioniert es schlechter als in der Theorie.
Diese drei Wörter sind alles, was benötigt wird, um die erste virtuelle Maschine in KVM zu starten. Aber auch hier gibt es Nuancen ...
Libvirt verfügt über eine Konfiguration, in der virtuelle Maschinen und andere Einstellungen gespeichert werden. Es speichert die Konfiguration in XML-Dateien - stilvoll, modisch und direkt aus den 90er Jahren. Falls gewünscht, können sie von Hand bearbeitet werden, aber warum, wenn es bequeme Befehle gibt. Praktisch ist auch, dass Änderungen an XML-Dateien wunderbar versioniert sind. Wir verwenden
etckeeper - version das verzeichnis etc. Es ist bereits möglich, etckeeper zu verwenden, und es ist höchste Zeit.
LXC Crashkurs
Es gibt viele Missverständnisse über LXC und LXD.
LXC ist die Fähigkeit des modernen Kernels, Namespaces zu verwenden - um vorzutäuschen, dass es überhaupt nicht der Kern ist, der es ursprünglich war.
Sie können diese Namespaces für jeden Container beliebig viele erstellen. Formal ist der Kern einer, aber er verhält sich wie viele identische Kerne. Mit LXC können Sie Container ausführen, es werden jedoch nur grundlegende Tools bereitgestellt.
Canonical, das hinter Ubuntu steht und Container aggressiv vorantreibt, hat
LXD veröffentlicht, ein Analogon von libvirt . Dies ist eine Bindung, die das Ausführen von Containern erleichtert, aber darin befindet sich immer noch LXC.
LXD ist ein Container-Hypervisor, der auf LXC basiert.
Unternehmen regiert in LXD. LXD speichert die Konfiguration in seiner Datenbank - im Verzeichnis
/var/lib/lxd . Dort führt LXD seine Konfiguration zur Konfiguration in SQlite. Das Kopieren ist nicht sinnvoll, aber Sie können die Befehle aufschreiben, mit denen Sie die Konfiguration des Containers erstellt haben.
Es gibt kein Entladen als solches, aber die meisten Änderungen werden von Teams automatisiert. Dies ist ein Analogon zur Docker-Datei, nur mit manueller Steuerung.
Produktion
Womit wir konfrontiert waren, als wir alle in Betrieb gingen.
Netzwerk
Wie viel höllischer Müll und Aufhebens im Internet über das Netzwerk in KVM! 90% der Materialien geben an, eine Brücke zu verwenden.
Hör auf, die Brücke zu benutzen!
Was ist los mit ihm? In letzter Zeit habe ich das Gefühl, dass der Wahnsinn mit Containern passiert: Legen Sie Docker auf Docker, damit Sie Docker in Docker ausführen können, während Sie Docker beobachten. Die meisten verstehen nicht, was Bridge tut.
Es versetzt Ihren Netzwerkcontroller in den
Promiscuous-Modus und empfängt den gesamten Datenverkehr, da er nicht weiß, welcher und welcher nicht. Infolgedessen durchläuft der gesamte Bridge-Verkehr einen wunderbaren, schnellen Linux-Netzwerkstapel, und es wird viel kopiert. Am Ende ist alles langsam und schlecht. Verwenden Sie daher keine Brücke in der Produktion.
SR-IOV
SR-IOV ist die Fähigkeit zur Virtualisierung innerhalb einer Netzwerkkarte . Die Netzwerkkarte selbst kann einen Teil von sich selbst für virtuelle Maschinen zuweisen, was Hardware-Unterstützung erfordert. Dies verhindert die Migration. Das Migrieren einer virtuellen Maschine, auf der SR-IOV fehlt, ist schmerzhaft.
SR-IOV sollte verwendet werden, wenn es im Rahmen der Migration von allen Hypervisoren unterstützt wird. Wenn nicht, dann ist macvtap genau das Richtige für Sie.
macvtap
Dies ist für diejenigen, deren Netzwerkkarte SR-IOV nicht unterstützt. Dies ist die Light-Version der Bridge: An einer Netzwerkkarte hängen verschiedene MAC-Adressen, und es wird eine
Unicast-Filterung verwendet : Die Netzwerkkarte akzeptiert nicht alles, sondern genau die Liste der MAC-Adressen.
Weitere blutige Details finden Sie in Toshiaki Makitas großartigem Vortrag
, Virtual Switching Technologies und Linux Bridge . Er ist voller Schmerzen und Leiden.
90% der Materialien zum Aufbau eines Netzwerks in KVM sind nutzlos.
Wenn jemand sagt, dass Bridge fantastisch ist, sprechen Sie nicht mehr mit dieser Person.
Mit macvtap
spart die
CPU aufgrund weniger Kopien
etwa 30% . Aber der Promiscuous-Modus hat seine eigenen Nuancen. Sie können vom Hypervisor selbst - vom Host aus - keine Verbindung zur Netzwerkschnittstelle des Gastcomputers herstellen. Ein Toshiaki-Bericht beschreibt dies detailliert. Aber kurz gesagt - es wird nicht funktionieren.
Vom Hypervisor gehen selten SSH. Es ist bequemer, dort eine Konsole zu starten, beispielsweise eine Win-Konsole. Es ist möglich, den Datenverkehr auf der Schnittstelle zu überwachen. Sie können keine Verbindung über TCP herstellen, der Datenverkehr auf dem Hypervisor ist jedoch sichtbar.
Wenn Ihre Geschwindigkeit über 1 Gigabit liegt, wählen Sie macvtap.
Bei Schnittstellengeschwindigkeiten von bis zu oder um 1 Gigabit pro Sekunde kann auch Bridge verwendet werden. Wenn Sie jedoch eine 10-GB-Netzwerkkarte haben und diese irgendwie entsorgen möchten, bleibt nur Macvtap übrig. Es gibt keine anderen Optionen. Außer SR-IOV.
systemd-networkd
Dies ist eine großartige Möglichkeit, die Netzwerkkonfiguration auf dem Hypervisor selbst zu speichern . In unserem Fall ist dies Ubuntu, aber für andere Systeme funktioniert systemd.
Früher hatten wir eine Datei
/etc/network/interfaces in der wir uns alle befanden. Es ist unpraktisch, jedes Mal eine Datei zu bearbeiten. Mit systemd-networkd können Sie die Konfiguration in mehrere kleine Dateien aufteilen. Dies ist praktisch, da es mit jedem Versionsverwaltungssystem funktioniert: Es wurde an Git gesendet und Sie sehen, wann und welche Änderung stattgefunden hat.
Es gibt einen Fehler, den unsere Netzwerker entdeckt haben. Wenn Sie dem Hypervisor ein neues VLAN hinzufügen müssen, gehe ich und konfiguriere. Dann sage ich: "systemctl systemd-networkd neu starten". In diesem Moment ist alles in Ordnung mit mir, aber wenn BGP-Sitzungen von diesem Computer ausgelöst werden, brechen sie ab. Unsere Netzwerker sind damit nicht einverstanden.
Für den Hypervisor passiert nichts Schlimmes. Systemd-networkd ist nicht für Grenzgänger, Server mit erhöhtem BGP und für Hypervisoren geeignet - ausgezeichnet.
Systemd-networkd ist noch lange nicht endgültig und wird niemals fertiggestellt. Dies ist jedoch bequemer als das Bearbeiten einer großen Datei. Eine Alternative zu systemd-networkd in Ubuntu 18.04 ist Netplan. Dies ist eine „coole“ Methode, um das Netzwerk zu konfigurieren und auf den Rechen zu treten.
Netzwerkgerät
Nach der Installation von KVM und LXD auf dem Hypervisor sehen Sie zunächst zwei Bridges. Einer machte KVM für sich und der zweite - LXD.
LXD und KVM versuchen, ihr Netzwerk bereitzustellen.
Wenn Sie noch eine Brücke benötigen - für Testmaschinen oder zum Spielen - töten Sie die Brücke, die standardmäßig aktiviert ist, und erstellen Sie Ihre eigene - die gewünschte. KVM oder LXD machen es schrecklich - gib dnsmasq ab und der Horror beginnt.
Lagerung
Es spielt keine Rolle, welche Implementierungen Sie mögen - verwenden Sie Shared Storage.
Zum Beispiel iSCSI für virtuelle Maschinen. Sie werden den „Fehlerpunkt“ nicht beseitigen, aber Sie können den
Speicher an einem Punkt konsolidieren . Dies eröffnet neue interessante Möglichkeiten.
Dazu müssen mindestens 10 Gbit / s-Schnittstellen im Rechenzentrum vorhanden sein. Aber auch wenn Sie nur 1 Gbit / s haben - machen Sie sich keine Sorgen. Dies sind ungefähr 125 MB / s - ziemlich gut für Hypervisoren, die keine hohe Festplattenlast benötigen.
KVM kann Speicher migrieren und ziehen. Im Workload-Modus ist das Übertragen einer virtuellen Maschine auf ein paar Terabyte jedoch ein Problem. Für die Migration mit einem gemeinsamen Speicher reicht nur RAM aus, was elementar ist. Dies
reduziert die Migrationszeit .
Am Ende LXD oder KVM?
Zunächst gingen wir davon aus, dass wir für alle virtuellen Maschinen, bei denen der Kernel mit dem Hostsystem übereinstimmt, LXD verwenden werden. Und wo wir einen anderen Kern brauchen - nehmen Sie KVM.
In Wirklichkeit sind die Pläne nicht aufgegangen. Um zu verstehen, warum, schauen Sie sich LXD genauer an.
Lxd
Das Hauptplus ist das Speichern von Speicher auf dem Kern. Der Kernel ist der gleiche und wenn wir neue Container starten, ist der Kernel der gleiche. Damit endeten die Vor- und Nachteile.
Blockgerät mit rootfs muss gemountet sein. Es ist schwieriger als es klingt.
Es gibt wirklich keine Migration . Es ist und basiert auf dem wunderbaren düsteren Instrument Criu, das unsere Landsleute gesehen haben. Ich bin stolz auf sie, aber in einfachen Fällen funktioniert criu nicht.
zabbix-agent verhält sich in einem container seltsam . Wenn Sie es im Container ausführen, werden eine Reihe von Daten vom Hostsystem und nicht vom Container angezeigt. Bisher kann nichts getan werden.
Wenn Sie sich die Liste der Prozesse auf dem Hypervisor ansehen, ist es unmöglich, schnell zu verstehen, aus welchem Container ein bestimmter Prozess wächst . Es braucht Zeit, um herauszufinden, welcher Namespace vorhanden ist, was und wo. Wenn die Last irgendwo mehr als sonst gesprungen ist, dann schnell nicht verstehen. Dies ist das Hauptproblem - die Einschränkung der Antwortmöglichkeiten. Für jeden Fall wird eine Mini-Untersuchung durchgeführt.
Das einzige Plus von LXD ist die Einsparung von Kernspeicher und die Reduzierung des Overheads.
Der gemeinsam genutzte Kernel-Speicher in KVM spart jedoch bereits Speicher.
Bisher sehe ich keinen Grund, ernsthafte Produktion und LXD einzuführen. Trotz der Bemühungen von Canonical in diesem Bereich bringt die Produktion von LXD mehr Probleme als Lösungen mit sich. In naher Zukunft wird sich die Situation nicht ändern.
Es kann jedoch nicht gesagt werden, dass LXD böse ist. Er ist gut, aber in begrenzten Fällen, auf die ich etwas später eingehen werde.
Criu
Criu ist ein düsteres Dienstprogramm.
Erstellen Sie einen leeren Container, der mit einem DHCP-Client ankommt und sagt: "Suspend!" Erhalten Sie den Fehler, weil es einen DHCP-Client gibt: „Horror, Horror! Er öffnet die Steckdose mit dem Schild "roh" - was für ein Albtraum! " Schlimmer nirgendwo.
Impressionen von Containern: Keine Migration, Criu arbeitet jedes Mal.
Ich "mag" die Empfehlung des LXD-Teams, was mit Criu zu tun ist, damit es keine Probleme gibt:
-
Nehmen Sie eine frischere Version aus dem Repository!Und kann ich es irgendwie aus dem Paket nehmen, um nicht in das Repository zu laufen?
Schlussfolgerungen
LXD ist wunderbar, wenn Sie eine CI / CD-Infrastruktur erstellen möchten. Wir nehmen LVM - Logical Volume Manager, machen einen Schnappschuss daraus und starten den Container darauf. Alles funktioniert super! In einer Sekunde wird ein neuer sauberer Behälter erstellt, der zum Testen und Rollen des Küchenchefs konfiguriert ist - wir verwenden ihn aktiv.
LXD ist schwach für ernsthafte Produktion . Wir können nicht herausfinden, was mit LXD in der Produktion zu tun ist, wenn es nicht gut funktioniert.
Wählen Sie KVM und nur KVM!Die Migration
Ich werde das kurz sagen. Migration war für uns eine wunderbare neue Welt, die wir mögen. Dort ist alles einfach - es gibt ein Team für Migration und zwei wichtige Optionen:
virsh migrate <vm> qemu+ssh://<hypervisor>/system --undefinesource -persistent
Wenn Sie in Google "KVM-Migration" eingeben und das erste Material öffnen, wird ein Befehl für die Migration angezeigt, jedoch ohne die letzten beiden Schlüssel. Sie werden keine Erwähnung sehen, dass sie wichtig sind: "Führen Sie einfach diesen Befehl aus!" Führen Sie den Befehl aus - und er migriert wirklich, aber nur wie?
Wichtige Migrationsoptionen.
undefinesource - Entfernen Sie die virtuelle Maschine aus dem Hypervisor, von dem wir migrieren. Wenn Sie nach einer solchen Migration neu starten, startet der von Ihnen verlassene Hypervisor diesen Computer neu. Sie werden überrascht sein, aber das ist normal.
Ohne den zweiten Parameter - persistent - betrachtet der Hypervisor, in den Sie verschoben haben, dies überhaupt nicht als permanente Migration. Nach dem Neustart merkt sich der Hypervisor nichts mehr.
- virsh dominfo <vm> | grep persistent
Ohne diesen Parameter ist die virtuelle Maschine ein Kreis auf dem Wasser. Wenn der erste Parameter ohne den zweiten angegeben wird, raten Sie, was passieren wird.
Es gibt viele solche Momente mit KVM.
- Netzwerk: Sie erzählen immer von Bridge - es ist ein Albtraum! Sie lesen und denken - wie so ?!
- Migration: Sie sagen auch nichts Verständliches, bis Sie Ihren Kopf gegen diese Wand schlagen.
Wo soll ich anfangen?
Um spät anzufangen - ich spreche über etwas anderes.
Bereitstellung: Bereitstellung
Wenn Sie mit den Standardinstallationsoptionen zufrieden sind, ist der Voreinstellungsmechanismus großartig.
Unter ESXi haben wir virt-install verwendet. Dies ist eine normale Methode zum Bereitstellen einer virtuellen Maschine. Es ist praktisch, wenn Sie eine Voreinstellungsdatei erstellen, in der Sie das Image Ihres Debian / Ubuntu beschreiben. Starten Sie eine neue Maschine, indem Sie ihr ein ISO-Verteilungskit und eine Voreinstellungsdatei zuführen. Dann rollt sich das Auto. Sie verbinden sich über SSH damit, schließen es an einen Koch an, rollen Kekse - das war's, eilen Sie zum Produkt!
Aber wenn Sie genug virt-install haben, habe ich schlechte Nachrichten. Dies bedeutet, dass Sie das Stadium nicht erreicht haben, in dem Sie etwas anderes tun möchten. Wir haben festgestellt, dass eine virtuelle Installation nicht ausreicht. Wir kamen zu einem „goldenen Image“, das wir klonen und dann virtuelle Maschinen starten.
Und wie arrangiere ich eine virtuelle Maschine?
Warum sind wir zu diesem Bild gekommen und warum ist die Bereitstellung wichtig? Weil es in der Community immer noch ein schwaches Verständnis dafür gibt, dass es große Unterschiede zwischen einer virtuellen Maschine und einer normalen Maschine gibt.
Eine virtuelle Maschine benötigt keinen komplizierten Startvorgang und keinen intelligenten Bootloader . Es ist viel einfacher, die Festplatten einer virtuellen Maschine an eine Maschine anzuschließen, die über einen vollständigen Satz von Tools verfügt, als im Wiederherstellungsmodus zu versuchen, irgendwo herauszukommen.
Eine virtuelle Maschine benötigt die Einfachheit eines Geräts . Warum benötige ich Partitionen auf einer virtuellen Festplatte? Warum nehmen Leute eine virtuelle Festplatte und platzieren dort Partitionen, nicht LVM?
Eine virtuelle Maschine benötigt maximale Erweiterbarkeit . Normalerweise wachsen virtuelle Maschinen. Dies ist ein „cooler“ Prozess, bei dem die Partition im MBR erhöht wird. Sie löschen es, wischen sich in diesem Moment den Schweiß von der Stirn und denken: "Schreiben Sie jetzt einfach nicht, schreiben Sie einfach nicht!" - und mit den neuen Parametern neu erstellen.
LVM @ lilo
Als Ergebnis kamen wir zu LVM @ lilo. Dies ist ein Bootloader, mit dem Sie aus einer einzelnen Datei konfigurieren können. Wenn Sie die GRUB-Konfiguration bearbeiten möchten, bearbeiten Sie eine spezielle Datei, die die Template-Engine steuert und die monströse boot.cfg erstellt, dann mit Lilo - eine Datei und nichts weiter.
Partitionsloses LVM macht das System perfekt und einfach. Das Problem ist, dass GRUB ohne MBR oder GPT nicht leben kann und friert. Wir sagen ihm: "GRUB lässt sich hier nieder", aber er kann nicht, weil es keine Trennwände gibt.
Mit LVM können Sie schnell erweitern und Backups erstellen. Standarddialog:
- Leute, wie macht man ein virtuelles Backup?- ... wir nehmen ein Blockgerät und kopieren.- Haben Sie versucht, wieder bereitzustellen?- Nein, alles funktioniert bei uns!Sie können ein Blockgerät in einer virtuellen Maschine jederzeit lecken. Wenn jedoch ein Dateisystem vorhanden ist, erfordert jeder Datensatz drei Bewegungen - diese Prozedur ist nicht atomar.
Wenn Sie einen Snapshot der virtuellen Maschine von innen erstellen, kann diese mit dem Dateisystem kommunizieren, sodass der gewünschte konsistente Status erreicht wird. Das ist aber nicht für alles geeignet.
Wie baue ich einen Container?
Um einen Container zu starten und zu erstellen, gibt es reguläre Tools aus den Vorlagen. LXD bietet die Ubuntu 16.04 oder 18.04 Vorlage an. Wenn Sie jedoch ein fortgeschrittener Kämpfer sind und keine reguläre Vorlage möchten, sondern Ihre benutzerdefinierten Rootfs, die Sie selbst anpassen können, stellt sich die Frage: Wie kann ein Container in LXD von Grund auf neu erstellt werden?
Behälter von Grund auf neu
Rootfs vorbereiten . Debootstrap hilft dabei: Wir erklären, welche Pakete benötigt werden, welche nicht und installieren.
Erklären Sie LXD, dass wir einen Container aus bestimmten rootfs erstellen möchten . Erstellen Sie zunächst einen leeren Container mit einem kurzen Befehl:
curl --unix-socket /var/lib/lxd/unix.socket -X POST -d '{"name": "my-container", "source": {"type": "none"}}' lxd/1.0/containers
Es kann sogar automatisiert werden.
Ein nachdenklicher Leser wird sagen - wo ist rootfs my-container? Wo ist es an welcher Stelle angegeben? Aber ich habe nicht gesagt, dass das alles ist!
Wir mounten rootfs des Containers, in dem er leben wird. Dann geben wir an, dass der rootfs-Container hier leben wird:
lxc config set my-container raw.lxc "lxc.rootfs=/containers/my-container/rootfs"
Auch dies ist automatisiert.
Containerlebensdauer
Der Container hat keinen eigenen Kernel , daher ist das Laden einfacher
: systemd, init und flog!
Wenn Sie für die Arbeit mit LVM keine regulären Tools verwenden, müssen Sie in den meisten Fällen zum Starten des Containers die Container-Rootfs im Hypervisor bereitstellen.
Ich finde manchmal Artikel, die Autofs empfehlen. Tu das nicht. Systemd verfügt über Automount-Einheiten, die funktionieren, Autofs jedoch nicht. Daher können und sollten systemd automount-Einheiten verwendet werden, aber autofs lohnt sich nicht.
Schlussfolgerungen
Wir mögen KVM mit Migration . Mit LXD ist dies noch nicht der Fall, obwohl wir es zum Testen und Erstellen der Infrastruktur verwenden, wenn keine Produktionslast vorhanden ist.
Wir lieben die Leistung von KVM . Es ist vertrauter, nach oben zu schauen, dort einen Prozess zu sehen, der für diese virtuelle Maschine relevant ist, und zu verstehen, wer und was wir tun. Dies ist besser, als eine Reihe seltsamer Dienstprogramme mit Containern zu verwenden, um herauszufinden, welche Art von Unterwasserschlägen es gibt.
Wir freuen uns über die Migration. Dies ist hauptsächlich auf den gemeinsam genutzten Speicher zurückzuführen. Wenn wir durch Ziehen von Datenträgern migrieren würden, wären wir nicht so glücklich.
Wenn Sie wie Leo bereit sind, über die Überwindung der Schwierigkeiten bei Betrieb, Integration oder Support zu sprechen, ist es jetzt an der Zeit , einen Bericht an die Herbst- DevOpsConf- Konferenz zu senden . Und wir im Programmkomitee werden dazu beitragen, die gleiche inspirierende und nützliche Präsentation wie diese vorzubereiten.
Wir warten nicht auf die Frist für Call for Papers und haben bereits mehrere Berichte zum Konferenzprogramm angenommen. Abonnieren Sie den Newsletter und den Telegrammkanal und bleiben Sie über Neuigkeiten zu den Vorbereitungen für die DevOpsConf 2019 auf dem Laufenden. Verpassen Sie keine neuen Artikel und Videos.