Ungereimtes
Unter Ubuntu ist in Citrix die CTRL-Taste plötzlich nicht mehr vorhanden. Neu mit Citrix verbinden hilft auch nichts. Ausserhalb des Citrix-Fensters funktioniert alles wie gewohnt.
Unter gnome-tweaks war „Ort des Zeigers“ aktiv, das schaltet offenbar unter Citrix – und NUR unter Citrix – die CTRL-Taste aus! :-/
Manchmal kommt es vor, dass das Handy stumm geschaltet ist und man wichtige Mitteilungen, z.B von der Hausautomatisierung, einfach nicht mitbekommt.
Wieder zu Hause angekommen, ist dann die Überraschung groß, wenn der Keller vollgelaufen ist.
Zum Glück gibt es ein probates Mittel, mit dem man den Mitteilungsdrang der Hausautomatisierung priorisieren kann.
Text-to-speech heißt das Zauberwort, mit dem man home assistant dazu verhelfen kann, selbst bei lautlos geschaltetem Handy Nachrichten zuzustellen. Der entsprechende Service ist sogar schon an Bord.
service: notify.mobile_app_mein_handy
data:
message: TTS
data:
tts_text: 'auf Android kann der Server Sprachnachrichten schicken, auch wenn das Gerät lautlos geschaltet ist!'
ttl: 0
priority: high
channel: alarm_stream_maxObiges Code-Schnipsel vollbringt dieses technische Wunder.
Wohlgemerkt, das ist ein Feature, das nur auf dem Android-client von home assistant funktioniert!
Seit Version 20.x hat Nextcloud unter Chrome ein Font-problem.
Die Abstände stimmen nicht mehr.
Abhilfe schafft, den Font „Noto Color Emoji“ zu löschen, dann sieht das sofort wieder besser aus.
Mir klingeln noch die Ohren ob der Klagen, die in der IT in den letzten 20 Jahren aufkamen:
Mein Rechner ist zu langsam, ich brauche eine schnellere CPU – Microsoft hatte eine neue Version am Start
Mein RAM ist zu wenig, ich brauche mehr Speicher – die Softwareanbieter sind auf Java umgestiegen
Meine Grafikkarte ist zu langsam, ich brauche eine Schnellere – Gaming war angesagt
Mein Internet ist zu langsam, ich brauche DSL – oh, Filesharing entdeckt?
Mein Internet ist zu langsam, ich brauche Glasfaser – oh, Nextflix gefunden?
Ich habe zu wenig Bandbreite, ich brauche eine Flatrate – oh, einer der letzten Filesharer?
Strom ist zu teuer, ich brauche billigere Energie – oh, E-Auto gekauft?
Alle Errungenschaften der letzten 30 Jahre waren von den technischen Anforderungen der jeweils aktuellen Strömungen getrieben. Jetzt ist es mal wieder genau so weit, die aktuelle Anforderung heißt: billige Überschuß-Energie.
Benötigt wird die hauptsächlich für die Bereiche
E-Mobilität — ich möchte meinen Stromer mit billigem Strom betanken
Wärmepumpe — wenn es kalt ist, benötige ich Mengen an Strom
Proof of Work – vulgo Bitcoin-Mining
Zwei dieser Bereiche haben – im Gegensatz zu „traditionellen“ Verbrauchern – den Riesenvorteil, dass sie zeitsteuerbar sind. Mein E-Auto kann ich nachts oder (wenn ich einen Speicher besitze) in Zeiten billigen Stroms laden.
Meine Bitcoins kann ich minen, wenn der Strom preiswert ist.
Für den Stromanbieter sind das paradiesische Zustände: er kann eine Grundlast als jederzeit gut verkaufbar einplanen, wenn auch zu „reduzierten“ Preisen.
In Hochlastsituationen kann er die „steuerbaren“ Verbraucher vom Netz nehmen und seinen Strom teurer verkaufen.
Insofern stellt das Mining via Proof of Work einen bezahlten Puffer für die Energieversorger dar, die mittels diesem ihre Investitionen über die garantierte, bezahlte Grundlast perfekt planen können.
Also vor der Forderung nach dem Verbot des Minings bitte nachdenken. Ansonsten wäre auch ein Verbot von schnellem Internet, schnellen Rechnern, viel RAM oder schnellen Grafikkarten genauso sinnvoll. Oder von Autos – da war das Anforderungsszenario nur 40 Jahre vorher aktuell…
Die Macher von Proxmox gehen in den meisten Fällen davon aus, dass die Knoten des Clusters in einem gemeinsamen Rechenzentrum stehen. Das ist sicherlich der Normalfall, bei Ausnahmen lässt die Dokumentation aber etwas zu wünschen übrig.
Daher an dieser Stelle die Beschreibung einer einfachen, performanten und preiswerten Lösung eines VLan-fähigen „Backbone“ über unterscheidliche Standorte.
Es existiert ein Cluster auf drei Root-Servern bei Hetzner. Dieser soll erweitert werden um zwei im eigenen kleinen RZ gehostete Knoten.
Ziel ist die performante Anbindung des Clusters mit der Möglichkeit, VMs im Gesamtcluster umziehen zu können ohne an der Netzwerkkonfiguration schrauben zu müssen.
Darüber hinaus sollen die einzelnen VMs in diversen VLANs gruppiert werden können.
Zur Anbindung von Hetzner muss man nicht viel sagen – schnell und zuverlässig. Dass das Peering ins Netz der Deutschen Telekom eine Katastrophe ist und Magenta zu Hetzner nur einen nassen Schnürsenkel vorweisen kann, ist allein der Telebimm zuzuschreiben. Das bremst den Zugriff aus dem Netz der Telebimm schon mal auf <1MBit aus… Schwaches Bild, liebe Telekom, aber genau aus diesem Grund bin ich ja auch kein Kunde mehr! 🙂
Die Anbindung des heimischen RZ hängt an einer sehr zuverlässigen 1000MBit-Glasfaser der GGEW. Typische Performancewerte: 928MBit Download, 278MBit Upload!
Den Anschluss an die Faser übernimmt eine FritzBox 7490 mit PPPoE, dahinter hängt als „Exposed Host“ eine pfsense. Diese wiederum verteilt auf ein Admin- und ein Work-LAN, in dem die beiden PVE sitzen.
Was muss ich aufreißen?
Die Zerotier-Dokumentation ist da recht einfach:
That means your peers could be listening on any port. To talk with them directly, you need to be able send to any port.
No. Let ZeroTier and UPnP, NAT-PMP, and IPv6 handle it automatically.
Also recht einfach, ich muss pfsense nur sagen, dass UPnP zugelassen werden soll und die Maschinen im Work-LAN Rechte auf die notwendigen Dienste haben sollen.
Um die Knoten miteinander zu verbinden, erzeugen wir in in der zerotier-GUI ein neues Netzwerk und wählen IPv4-Auto-assign.
Nach dem Join verändern wir die Einstellungen der verbundenen Knoten und aktivieren die Bridge-Funktion
Damit „sehen“ sich die Knoten gegenseitig, unabhängig vom Standort.
Die Wahl des VLAN fiel auf das seit 6.3 recht stabile VXLAN-Paket von Proxmox, das aber immer noch als experimentell eingestuft wird!
Um das Paket zu benutzen, muss auf den teilnehmenden Knoten ein
apt install libpve-network-perl
ausgeführt werden. Ein Neustart zumindest des pve-cluster ist danach notwendig.
Danach taucht auf RZ-Ebene der Menueintrag „SDN“ auf.
Unter „Zonen“ legen wir jetzt eine neue Zone vom Typ VXLAN an.
Danach können wir unter „Vnets“ ein Netz in dieser Zone definieren
Jetzt müssen wir alle Zonen noch anwenden. Damit werden die Konfigurationen auf die Knoten in die Datei /etc/network/interfaces.d/sdn exportiert und die Netzwerkkonfiguration neu erstellt.
Jetzt können wir den VMs ein Interface aus den erzeugten Vnets zuweisen, mit oder ohne VLAN-Tag und uns an performantem Traffic innerhalb des clusterweiten VLAN erfreuen! 🙂
Ein immer wiederkehrender Quell großer Freude ist eine falsch gesetzte MTU!
Ping funktioniert fast immer, die meisten Websites ebenfalls, Downloads o.ä. hangen – viel Spaß beim Suchen! 🙂
Da die Interfaces Bridges darstellen, muss die MTU der Guest-Interfaces geringer als der Standard von 1500 gewählt werden. 1480 ist hier der Wert der Wahl!
Eine VM, die auf einem Hetzner-Rootserver unter virsh läuft, soll in einen existierenden Proxmox-Cluster umgezogen werden. Soweit kein Problem, aaaaber: die offizielle IP-Adresse, eine Hetzner-Zusatz-IP soll erhalten bleiben.
Da Hetzner die Zusatz-IPs nur maschinenspezifisch vergibt und keinen Umzug auf eine andere Maschine ermöglicht, muss der Traffic von der alten IP zur neuen VM im PVE umgeleitet werden. Nach Möglichkeit sollte das mit Bordmitteln (und zerotier) ohne iptables-Umleitungen funktionieren.
Das Mittel der Wahl, diverse Hosts performant miteinander zu verbinden, ist hier zerotier.
Unter der GUI wird ein neues Netzwerk angelegt, das alle teilnehmenden Hosts joinen.
Für den alten Virtualisierungshost (im Folgenden VH, wie Virsh-Host) genannt, sowie alle teinehmenden PVEs wird ein Eintrag in dieser Form angelegt:
Auf dem alten Host wird eine Bridge mit einer privaten IP und einer Route zur Zusatz-IP angelegt:
auto vmbr1001
iface vmbr1001
address 10.111.222.1/24
bridge-ports none
bridge-stp off
bridge-fd 0
up brctl addif vmbr1001 ztks553soy
up ip link set ztks553soy up
up ip route add <Zusatz-IP>/32 dev vmbr1001
# bridge fuer alte VMDie Zusatz-IP wird also auf diese Bridge geroutet
Auf den teilnehmenden PVEs wird eine ähnliche Bridge gleichen Namens (muss nicht!) angelegt, allerdings ohne IP-Adresse und Route.
auto vmbr1001
iface vmbr1001
bridge-ports none
bridge-stp off
bridge-fd 0
# siehe if-up.d/vmbr1001
# bridge fuer alte VMBeide Bridges werden über das vorher erzeugte Zerotier-Interface verbunden.
Da die Zerotier-Interfaces erst nach dem kompletten Netzwerk-Setup gestartet werden, muss das weitere Setup zeitverzögert erfolgen. Leider unterstützt zerotier bislang keine Script-hooks, ähnlich if-up.d, sonst könnte das weitere Setup dort erfolgen. So erledigt diese Aufgabe das Script if-up.d/vmbr1001 mit dem etwas unschönen „sleep“.
!/bin/sh [ "$IFACE" != "vmbr1001" ] && exit 0 # Interface ztks553soy kommt erst mit zerotier hoch, # ist also jetzt noch nicht bereit. # Daher muss der folgende Block verzögert ausgeführt werden. ( sleep 30 brctl addif vmbr1001 ztks553soy ip link set ztks553soy up ip r add <guest ip>/32 dev vmbr1001 ) &
Im portierten Guest wird als externes Interface jetzt die (auf dem PVE erzeugte) Bridge zugewiesen.
Im Gast wird jetzt die Hetzner Zusatz-IP dem externen Interface zugewiesen.
Im Guest muss jetzt noch das Gateway bekannt gemacht werden.
ip route add <private-ip-von-vmbr1001> dev eth0 ip route add default via <private-ip-von-vmbr1001> dev eth0
Danach sollte die Verbindung über die Bridge funktionieren.
Der Proxmox-Cluster verliert einzelne Knoten, diese rebooten und reißen damit die verbleibenden Knoten ebenfalls ins Jenseits. Das passiert nicht nur einmal, sondern in bunter Reihenfolge!
Nach Isolation eines Knoten mittels pvecm expected 1 lässt sich dieser vom Dauerboot abhalten. Zu beobachten ist, dass der zerotier-Prozess mehrere CPUs voll belegt und sein Speicherbedarf stetig steigt. Bei 120GB ist dann Schluss, das OS schießt den Prozess ab.
Da der Heartbeat des corosync über einen mittels zerotier aufgebauten Tunnel läuft, ist der Knoten jetzt isoliert und das Fencing reißt ihn nach 60 Sekunden in den Abgrund… Nach dem Reboot passiert das Gleiche wieder und wieder…
Zerotier greift sich zum Aufbau des Tunnels alle verfügbaren physischen Interfaces.
Wenn also ein Zerotier-Interface Teil einer Bridge ist, geht der Zerotier-Traffic auch über diese Bridge und damit rekursiv wieder über das Zerotier-Interface – eine perfekte Schleife, die alles verfügbare RAM aufbraucht!
Man kann zerotier das Verhalten abgewöhnen, indem man die kritischen Interfaces in eine blacklist einträgt. Das geschieht mittels der Datei /var/lib/zerotier-one/local.conf
Falls diese noch nicht existiert, muss sie angelegt werden.
{
"physical": {
"172.16.0.0/16": {
"blacklist": true
},
"10.0.0.0/8": {
"blacklist": true
}
},
"settings": {
"interfacePrefixBlacklist": [ "eth100","vmbr10","vmbr666","vmbr999" ]
}
}Es sollten alle nicht nach draußen führenden Interfaces – und alle privaten IP-Ranges ausgeschlossen werden. Danach zerotier neu starten und sich über den moderaten Ressourcenverbrauch freuen…
Kleine Ursache, große Wirkung, lange Analyse, lange Downtime -> nicht schön!
Davon abgesehen ist es keine sehr gute Idee, den Heartbeat über zerotier laufen zu lassen, die Latenzen sind bisweilen gigantisch, was der Stabilität des Clusters nicht gut bekommt.
Mittlerweile kommt auch für den Heartbeat tinc zum Einsatz, der Cluster ist damit deutlich stabiler geworden!
Über mehrere Proxmox-Nodes soll ein VPN gespannt werden, über das mehrere VLANs den VMs zur Verfügung gestellt werden. Dies sollte mit Bordmitteln geschehen.
Das VPN wird mit tinc aufgesetzt, weil es schnell, einfach und mesh-fähig ist.
Ziel ist, einen einzigen tinc-Tunnel für mehrere VLANs zu verwenden.
Die Konfiguration ist am Standard angelehnt, Besonderheiten sind fett.
Device=/dev/net/tun DeviceType=tap Forwarding=kernel PMTUDiscovery=yes PriorityInheritance=yes Interface=eth200 AddressFamily=any Mode=switch ProcessPriority=high Name=v0 PrivateKeyFile=/etc/tinc/pvebridge/rsa_key.priv ConnectTo=v1 ConnectTo=v2 ConnectTo=...
tinc wird mit systemctl enable tinc@pvebridge ins System eingebunden und dann mit systemctl start tinc@pvebridge gestartet.
Das Start-script tinc-up bindet das Interface an die Bridge.
!/bin/sh BRIDGE=vmbr666 ip address add 10.66.66.2/24 dev $INTERFACE ip link set $INTERFACE master $BRIDGE ip link set $BRIDGE up ip link set $INTERFACE up bridge vlan add vid 2-4094 dev $INTERFACE
Das Interface benötigt eine IP-Adresse, bevor es in die Bridge aufgenommen wird!
Das bridge-Kommando mappt alle verfügbaren VLAN-IDs auf das darunterliegende Interface. Es funktioniert erst, nachdem das Interface in die bridge aufgenommen wurde.
Jetzt wird der erste Container (hier Ubuntu 18.04) angelegt und mit Netzwerk konfiguriert.
Nach der Generierung des zweiten Containers auf einem anderen Knoten
funktioniert der ping zwischen beiden Knoten über das VLAN.
Bei Änderungen an der tinc-Konfiguration sollten die Instanzen auf den einzelnen Knoten mit zeitlichem Abstand gestartet werden, da sonst die einzelnen Instanzen ihre Gegenseite nicht finden und somit keine Verbindung zustande kommt.
Nicht vergessen, die evtl. vorhandene Zerotier-Konfiguration anzupassen und die VLAN-Interfaces auszusparen!
Die Performance der Guests in Proxmox hängt definitiv vom Setup der darunterliegenden Virtualisierung ab. Dass die Unterschiede aber so groß sind, überrascht…
Setup 1: NVME+Software-Mirror, Guest: Ubuntu 18.04 KVM
Setup 2: NVME als Log und Cache für einen mirrored ZFS-Pool, Guest wie in 1
Aus gegebenem Anlass teile auch ich Rezos Video.
Bitte schaut es euch an. Es ist wichtig. Für uns alle.