2018-01-24 07:04:08
2018-01-24 06:27:56
2018-01-24 06:27:56
50210
KVM upgrade / Debian Stretch upgrade
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.
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.
Open Source (x)
Beobachtungen (x)