Letzte Woche habe ich endlich meine fast 10 Jahre alten KVM Server gegen neue ausgetauscht. Aus Bequemlichkeit setze ich auch weiterhin Proxmox ein.

Die alte Anlage bestand aus zwei Pizza-Schachteln mit je Quadcore-Xeon, 24 GiB RAM and 4 x 1 TB SATA HDDs im Software RAID-5 und DRBD. Die neue Anlage besteht aus drei Einschüben, welche sich ein 2HE Chassis teilen mit je 2 x Hexacore Xeon, 32 GiB RAM und 3 x 500 GB SATA SSDs im Software RAID-5 und Ceph. Beide Anlagen konnten durch die Replikation des Storages live Migration und Hochverfügbarkeit für die VMs nutzen.

Die neue Anlage ist neben Gigabit Ethernet (einmal DMZ für die VMs und einmal LAN für die Clusterkommunikation) auch noch mit zwei Infiniband Adaptern ausgestattet (einer onboard und der andere as PCIexpress Karte). Damit habe ich noch ein drittes Mesh-Netzwerk gemacht, welches 40 Gigabit pro Link für die Storage-Replikation nutzen kann. Diese Bandbreite erreiche ich zwar mit iperf nicht (10 Gb/s auf dem den Infiniband-IP-Stack) aber die SSDs würden unter idealen Bedingungen sowieso höchstens 3 x 500 MB/s, also 1,5 GB/s oder 12 Gb/s liefern. In der Praxis messe ich bisher 200 - 300 MB/s wenn ich z.B. VMs kopiere. Hat also noch Luft nach oben.

Leider ist einer der beiden alten Server vor einigen Monaten ausgefallen und mehrere Reparaturversuche ergaben, dass da was mit dem Mainboard nicht mehr stimmte. Nach so vielen Jahren Dauereinsatz verüble ich das dem Server nicht und es war die Gelegenheit endlich mal über eine Neuanschaffung nachzudenken.

Einige der VMs (z.B. mein Minecraft-Server) lagen auf den lokalen, nicht-DRBD Partitionen des ausgefallenen Servers und waren daher auch nicht Hochverfügbar ausgelegt. Nachdem ich letzte Woche die neue Anlage im RZ eingebaut und alle VMs migriert habe, hatte ich endlich wieder Zugriff auf diese. Da diese monatelang ausgeschaltet waren, habe ich die erst mal gründlich durchgepatcht. Etliche VMs mussten noch von Debian Jessie auf Stretch upgegradet werden.

Was mich dabei geärgert hat, war der höhere Arbeitsspeicher-Verbrauch. Etliche VMs liefen noch mit 256 MiB RAM und konnten auch problemlos geupgradet werden. Nach dem Reboot liefen Sie anfangs gut, aber je nach Anwendung schlug dann bald mal der OOM (out of memory) Killer zu. Aus Performance-Gründen betreibe ich die VMs alle ohne Swap. Soweit ich das sehen konnte ergibt sich der höhere Verbrauch einerseits aus einem etwas grösseren Kernel und dem Wechsel vieler Systemtools auf Python 3, welches scheinbar deutlich verschwenderischer mit dem Speicher umgeht als Version 2.

Was waren das noch für Zeiten, als eine VM mit 128 MiB RAM mehr als genug war um einen Bind oder apt-cacher zu betreiben.

Ein Freund hat mich vor Kurzem um Rat gefragt, da er eine Installation eines Ubuntu-Ablegers für ein Resourcen-armes System zurechtstutzen wollte und ihm dabei die Abhängigkeiten der Pakete in den Weg kamen. Ich arbeite meist mit aptitude auf Debian-basierten Systemen, komme daher mit diesem Werkzeug am besten zurecht um solche Abhängigkeits-Probleme zu lösen und habe ihm einige Tips dazu gesendet:

Ich arbeite immer noch am liebsten mit dem ncurses-basierten Tool "aptitude" auf debian-artigen Systemen.
Manchmal gibt es gemeine Kombinationen, so hatte man bei Debian früher mal das Problem, dass ssh-server über eine optionale Abhängigkeit xorg nach sich zog. Sollte Dir so etwas die Pakete beim updaten wieder installieren wollen, kannst Du das unerwünschte Paket auf "hold" setzen:
http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html#s-puttingonhold

Bei Ubuntu und seinen Ablegern gibt es ein bestimmtes Paket welches darüber entscheidet, welchen Desktop, respektive welche Ubuntu-Variante Du installiert hast und welches bei Dir vermutlich diese Abhängigkeiten verursacht. Bei Ubuntu ist das der "ubuntu-desktop", bei Kubuntu der "kubuntu-desktop", bei Lubuntu der "lubuntu-desktop" und sicher hast Du das Muster bereits erkannt. Dieses kann gefahrlos entfernt werden, da die davon gepullten Pakete werden nicht als abhängig definiert und können dann nach Bedarf manuell entfernt werden, wie Du es bereits versucht hast.

Es kann zu Problemen beim Upgrade auf die nächste Version führen dieses Paket zu entfernen, da dann neue, für das booten essentielle, Pakete nicht automatisch installiert werden. Es empfiehlt sich daher dieses Paket während einem dist-Upgrade wenn möglich wieder hinzuzufügen und gleich wieder abzuwählen um zu sehen, welche Pakete es installiert hätte.

Beim arbeiten mit aptitude kannst Du das update prüfen, bevor es angewendet wird: Drücke [U] um die Paketliste zu aktualisieren, [shift]+[U] wählt dann alle Updates und deren Abhängigkeiten aus. Danach kannst Du mit [G] zur Vorschau wechseln und allenfalls nicht erwünschte Pakete mit [_] zum Entfernen markieren und per [shift]+[0] (=) den Zustand fixieren (das oben erwähnte "hold"). Bist Du in der Vorschau zufrieden, kannst Du nochmals [G] drücken um die (de)installation zu starten.

Wenn Du Konflikte verursachst erscheint ein roter Balken und Du kannst die Konfliktansicht mit [E] betreten um die Problempakete zu untersuchen und zu entscheiden was damit passiert.

Falls Du ein Durcheinander mit den Paketen bekommst, kannst Du über das Menü auch alle aktuelle geplanten Änderungen verwerfen und nochmals neu beginnen.

Allgemein navigiert man in aptitude mit den Pfeiltasten, bei graphischen Terminals auch mit der Maus. Mit [Enter] öffnest Du das
markierte Element, [Escape] bringt Dich wieder einen Schritt zurück, auch über mehrere Schritte, wenn gewünscht.

Ach ja, und aptitude beisst sich nicht mit apt-get oder dem GUI-Updater, da die alle nur Frontends für dpkg sind. Es kann aber stets nur eines dieser Werkzeuge gleichzeitig laufen, Du musst den GUI-Updater also unter Umständen schliessen, wenn es die Paket-Verwaltung blockiert (was Dir aptitude sagen würde).