Kategorie-Archiv: SolSoCoG.de

Mir kam neulich so der Gedanke, dass es besser wäre alle Server mit einem eigenen Stratum 3 Server zu synchronisieren um keine Fehler durch zeitlich falsch gestartete Cronjobs oder andere Zeitabhängigige Dinge zu provozieren.

Deshalb habe ich mir auf ntp.5zs.de einen ntpd Server eingerichtet den ich kurz darauf zu einem chronyd Server eingerichtet.

Als Stratum 2 Zeitserver nehme ich 3 verschiedene Fakultäten und die physikalisch technische Bundesanstalt.

Hier mal ein Screenshot in Sachen Genauigkeit von ntpd im Vergleich zu chronyd (nach dem Einbruch ist es chronyd).

Man sieht das der offset extrem reduziert ist, offenbar arbeitet chronyd deutlich genauer und zuverlässiger, keine Ahnung wieso zwischendurch keine Anfrage vom pool.ntp.org zum ntpd durch kam.

Jeder ist dazu eingeladen ntp.5zs.de als Zeitserver zu nutzen, ich habe zur Website time.is, die von sich behauptet eine Atomuhr zur Zeitberechnung anzuzapfen, 0 bis 0.4s peak Zeitunterschied, im Schnitt nur 0.05s.

Im Schnitt geht eine mit Standard Microsoft NTP-Servern synchronisierte Uhr um 2.5s falsch.

Ich zähle, wie man meinen vorhergegangenen Beiträgen entnehmen kann, in Sachen Distribution zu den unentschlossensten Personen.
Gleichzeitig befugt mich das aber auch zu sagen, dass ich mit kaum einer Distribution sonderlich Probleme habe.

Ich liste mal auf wo welche Distribution bei mir genutzt wird:

Debian – Hiawatha Webserver, MariaDB Server, Scripte – Grund: Stabilität
CentOS / RedHat – Zimbra Mailserver, Plex Mediaserver, Dell Server(ehemals) – Grund: Kompatibilität
Ubuntu – Gameserver – Grund: Aktualität
Arch Linux / Gentoo – Nirgendwo – Grund: Neigt schnell zu defekten und macht Dinge unnötig komplex

Ich nutze seit geraumer Zeit Zimbra Open Source als Mailserver, es ist leicht zu konfigurieren, hat eine relativ gute Dokumentation und funktioniert tadellos.

Ich nutze es in Zusammenhang mit CentOS auf einem eigenen vServer.

Kann ich nur empfehlen: https://www.zimbra.com/downloads/zimbra-collaboration-open-source/

Nach über einem Jahr muss ich nun doch, mit kurzen Wortwechsel mit Linuxgenossen auf Twitter, verkünden, das ich CentOS für das sinnvollste Server-Betriebssystem für die Leute halte, die sich keine 30 Euro(Minimalbetrag ohne Support) monatlich für eine RedHat Lizenz leisten können oder wollen.

Man erkennt allein schon an der Versionierung von CentOS das es ganz nah an dessen Ursprung, RedHat anlehnt.

Wenn sich der Zeitpunkt ergibt will ich meine Nodes wieder umstellen. Bis dahin werden aber noch einige Monate ins Land gegangen sein.
Apropos CentOS Umstellung. Begleiten wird die Umstellung noch eine Umstellung von ProxMox auf OpenStack. Ich finde Proxmox einfach zu buggy.
Bspw. lassen sich bei Proxmox openVZ Container die VNC Ansicht nicht korrekt starten und der Hypervisor läuft noch auf 2.6. Finde ich etwas zu stable.

Wenn der Tag der Umstellung näher rückt, werde ich auf OpenStack gesondert eingehen und meine Vorgehensweise erklären.

Vor kurzem noch Fedora empfohlen und jetzt spreche ich wieder Debian an?
Tatsächlich hat Fedora, wie ich dann doch eingestehen musste zu viel an Board, vergleichbar mit einem Ubuntu für Desktops,
das meiste brauch man nicht und stellt eine unnötige Angriffsfläche dar.

Das schlägt sich zudem im Memory und HDD Footprint nieder, jenen wollte ich bei der Virtualisierung der einzelnen Komponenten gering halten.

Da ich OpenVZ nutze hat sich Docker.io gänzlich für mich erledigt, Virtualisierungsinception brauch ich nicht.

Und was macht Devuan grad? Ich weiß es nicht, interessiert mich auch nicht sonderbar, da Devuan für mich immer mehr den Eindruck eines Möchtegernkollektivs mit instabilen Paketen darstellt als eine gute Alternative zu systemd. Zu viele Programme setzen schon auf jenen daemon, als das man ihn effektiv ignorieren könnte.

Ich nutze jetzt schon seit einigen Monaten Fedora und ich muss sagen, ich bin begeistert.

Ich habe 3 Server laufen, die über MariaDB Cluster und GlusterFS Cluster untereinander gespiegelt sind sowie Prozesse wie bind9, Hiawatha und PHP-fpm darauf laufen.

Auch Fedora Rawhide teste ich seit geraumer Zeit und ich bin von der, trotz Bleeding Edge, einwandfreien Funktionstüchtigkeit absolut begeistert.

Es gibt Yum (ab glaube 22-Rawhide durch dnf ersetzt) als Paketmanager. Yum ist um einiges stabiler als apt von Debian. Das weiß ich deshalb, weil ich es bei Debian, in früheren Tagen, schon mehrere male irreperabel zerschossen habe, mir das bei Yum nutzenden Systemen wie CentOS, OpenSUSE, Fedora, etc. aber noch nie passiert ist.

Die Webkonsole Cockpit die standardmäßig dabei ist, sowie die dabei vorhandene Docker Integration sind ganz nett, wobei da der Nachteil ist, das es ein guter Angriffspunkt ist, es scheint nur mit Passwort zu funktionieren.

Zu Docker werde ich mir, wenn ich mal wieder mehr Zeit aufwenden kann und Lust daran habe, eine kleine Teststrecke bauen.

I’m proudly hosting the Fedora hiawatha repository.

I’ll make packages within 3 days of new sourcecode releases,

usually within the first 12 hours of release.

Go check out repo.hiawatha.be !

And now, back to german writing :)!

Devuan ist entstanden aus der Debatte zwischen Systemd und SysVinit unter Debian.

Zu Debian Zeiten habe ich SysVinit genutzt mit erzwungenem Systemd Pin auf Minuswerte.

Nun habe ich Fedora 21 Server in Gebrauch und die setzen nunmal auf Systemd.

Das lässt sich da nicht ohne Komplikationen entfernen,
daher lasse ich das lieber als abgestimmtes System laufen,
auch wenn dadurch Grundsätze von Linux zerstört werden.

Ich persönlich mag den puren /etc/init.d/ Style trotzdem lieber als dieses service postfix start, systemctl start postfix und gelegentlich /etc/init.d Gemixe.

Werde Devuan.net und Devuan.de bei Interesse abtreten.

Das Nasi Goreng von Kung-Fu ist seit geraumer Zeit nicht mehr im deutschen Handel verfügbar. Es gibt eine holländische Variante, aber die schmeckt leider nicht annähernd so lecker. Jo stimmt, die deutsche Variante bestand zu 98% aus Geschmacksverstärkern, war mir aber bei dem köstlichen Geschmack vollkommen egal.

Ich habe zuerst bei dem real,- hier in Bocholt angefragt, wo das Nasi Goreng abgeblieben ist,
nach einigen Telefonaten hatte ich einen Abteilungsleiter, der noch Zuhause war, an der Leitung.
Dieser fuhr später dann in den Markt und bestätigte mir, das das Produkt aus dem Vertrieb genommen wurde, genauere Gründe würde ich nur bei Struik Food bekommen.
Struik Food war unter der Marke Kung-Fu der Hersteller der Mahlzeit, auf einer Email antwortete man mir:

Leider müssen wir Ihnen mitteilen, das wir diesen Artikel aus unserem Produktsortiment rausgenommen haben.

Ich habe jeden Teller dieser in Dosen gepresste Köstlichkeit, den ich noch vorrätig hatte, genossen.
Tot ziens, Kung-Fu Nasi Goreng.
Tot ziens.

Update 2. März 2016:

ich habe ebenfalls bei http://shop.dutch-food.de/ zwei Dosen bestellt, sehr netter Kontakt, gab sogar ein kleines Präsent, Sambal Oelek, was gut zum Nasi passt, danke hierfür. Das Paket wurde äußerst zügig per Hermes geliefert. Der Shop ist meine Empfehlung für holländische Lebensmittel.

Aber leider ist es nicht das Produkt wie man es aus Deutschland kennt, kommt dem aber, mit ordentlich zusätzlichem Würzen und etwas experimentieren, relativ nahe. Nur der distinktive Nasi Goreng Geschmack wie ich ihn von früher kenne fehlt eindeutig und die Zusammensetzung ist deutlich verändert.

Hier mal die Zutatenlisten, die Untere habe ich frei aus den niederländischen Zutatenangaben der Dose übersetzt:

Zutaten (Nasi Goreng aus Deutschland/Alt):
69% weißer Reis, 8,5% Fleisch Würfel (32% Huhn, 19% Rindfleisch, Wasser, Huhn, Weizenmehl, Huhn-Kollagen, Salz, Schmalz, Schweinefleisch, Schweine-Kollagen, hydrolysiertes Sojaeiweiß, Milcheiweiß, Stabilisator (E451i, Hefeextrakt, Gerstenmalz-Extrakt), Zwiebel, Lauch, Karotte, Paprika, pflanzliches Öl, Salz, Geschmacksverstärker E621, Tomatenpulver, Zucker, Gewürze, hydrolysiertes Sojaprotein, Maisprotein, Farbe (E150c), pflanzliches Fett, Gewürze

Zutaten (Nasi Goreng aus Holland/Neu):
46% gekochter Reis, 14% Lauch, Paprika, Karotte, 7,7% Schinkenwürfel (Schweinefleisch, Wasser, Kartoffelstärke, Salz, getrockneter Glukosesirup, Schweinehämoglobin , Paprikaextrakt), Zwiebel, Rapsöl, Sesamöl, Salz, Chili-Pfeffer Püree (Paprika, Salz, Essig, Wasser, Zitrusfaser), Knoblauch, Sojasauce (Wasser, Sojabohnen, Weizenmehl, Salz, Zucker), Hefeextrakt, Zucker, Verdickungsmittel (E412), Kräuter

Zusammenfassung der Änderungen:

• weniger Reis
• mehr Lauch
• Fleisch nur noch aus Schwein, nicht gemischt aus Huhn, Rind und Schwein
• Hämaglobin statt Kollagen
• Unraffiniertes Mononatriumglutamat E621 (Hefeextrakt)
• mehr Öl
• kein Tomatenpulver oder Karotte
• Farbloser (E150c fehlt)
• Statt der leckeren Würzung gibt es zusätzlich Kräuter
• Ein Dutzend kleinere nicht nennenswerte Abweichungen

Altes und neues Design der Dose (anklicken zum vergrößern):

Vor ein paar Tagen hatte ich eine Anfrage zum Thema clustern.

Es ging um eine seit kurzem stark im öffentlichen Interesse stehenden Website.

Ca. Ein Jahr zuvor hatte ich der Konfiguration der Seite den Feinschliff verpasst. Lief soweit ganz gut. Nginx und Co.

Aber seit eben jenem dauerhaft erhöhten Interesse, war die Flut an Anfragen so hoch, das irgendwann alles langsamer wurde, weil die Festplatte (eine SSD wohlgemerkt) nicht mehr hinterher kam.

Daraufhin der erste Schritt: MySQL Tabelle in den RAM. Zack, alles lief wieder schnell. Jedoch ist das keine permanente/gute Lösung, da RAM flüchtig ist uns nach einem Reboot oder Stromausfall wären alle Daten weg.

Und schon wurde der zweite Server bestellt, um Lastspitzen auszugleichen.

Wunderbar. Beide gleich eingerichtet.
Nun ging es ans clustern.

Die Dateien, wie bekomme ich am effektivsten die dynamischen Dateien gesynct.

Versuch 1: Glusterfs.

Gefühlte 4 Stunden lang in ein Glusterfs Volumen kopiert. Als es live ging, fiel nach 4 Sekunden die Performance so in den Keller, das der php timeout erreicht wurde, noch bevor der Webserver mit dem IOWAIT fertig war.
Also kann man Glusterfs in die Tonne treten für Websites, auch als man das ganze als NFS gemountet hatte, was einen Performance boost bringen sollte, hat es keine Minute gedauert, bis die Website unerreichbar wurde.

Dann Unison probiert. Klappt wunderbar.

Jetzt die Frage was machen mit der MySQL DB? Zuerst einmal auf MariaDB wechseln, ganz klar. Anschließend wurde überlegt, wie man einen Ausweg aus dem ramfs Dilemma findet.
Großer Buffer von mehreren GB RAM, sowie trx commit auf 2 brachten den Erfolg, die Daten sind jetzt persistent.
Schön und gut, wie bekomme ich den zweiten Server dazu, die MySQL vom ersten zu benutzen? Socat Socket.

Cool jetzt sind die Server gesynct.

Nun geht es ans loadbalancing.

Ich habe bisher nur mit DNS loadbalancing (aka das balancing für faule) genutzt. Haproxy war mir aber auch ein Begriff, nur nicht notwendig, da ich damals 20 identische nodes für ein Cdn hatte.

Die Website jedoch hat einen starken und einen mittelmäßig starken Server. Da möchte man mit unterschiedlichen Gewichtungen arbeiten.

Es liegt hier nahe, das loadbalancing Angebot des Providers in Anspruch zu nehmen, wäre da nicht die Fußnote das man bei unterschiedlichen points of presence nicht mit Gewichtung arbeiten kann. Toll.

Also musste Plan B, haproxy her.
Vps gemietet, haproxy eingerichtet und es läuft prima.

Daher lasst euch sagen: Glusterfs ist nur was für statische Datenkraken und Unison/haproxy/MariaDB sind tolle Programme.