Blog

Mailserver Lastverteilung – load balancing – rr – best practise

Nach vielen Gesprächen mit meinem Kollegen und den Entwicklern von Postfix sowie div. Folien und RFCs hier aus meiner Sicht die Fakten der Lastverteilung bei Mailservern Mailserver bzw. das zugrunde liegende Konzept wurde für Lastverteilung und Ausfallsicherheit entwickelt. Häufig tendiert man jedoch dazu, Loadbalancer vorzuschalten – in speziellen Szenarien mag das auch Sinn machen – muss aber abgewogen werden. Ablauf einer Mailzustellung 1. DNS-Lookup nach MX-Records für Zieldomain oder für Relayserver Das heißt, wenn ein Relayserver für die weitere Zustellung genutzt wird, erfolgt auch ein MX-Lookup 2. Gibt ein Hostname Read more…

By cubewerk, ago

gzip multi-core performance – missing decompression options…

Aufgabe; 400GB LVM Volume zu Backupzwecken möglichst schnell und performant komprimieren und de-komprimieren. gzip gewinnt um Faktor 4-5 gegen bzip2 und lzma. gzip ist jedoch nicht Mutli-Core fähig – nimmt also nur einen Core der CPU. In meinem Fall langweilen sich also 7 Cores. Hierfür gibt es pigz, welches für Multi-CPU/Core entwickelt wurde. Prima – jetzt kann ich meine 400GB mit 8 Kernen komprimieren – reduziert die Zeit auf 42 Minuten und macht Netto 81GB. Jetzt wirds jedoch haarig – die Rücksicherung geht wieder nur mit einem/einer Core/CPU 🙁 In Read more…

By cubewerk, ago

cronjob only on active node / cronjob nur auf aktivem Knoten – cluster

Wie prüft man, ob der derzeitige Knoten in einem Active/Passive Cluster der gerade aktive ist und somit die Ressourcen hält? (Hintergrund, man möchte z.B. einen Cronjob nur dort durchführen, wo auch das Storage gemountet ist)   Snippet aus /etc/crontab   5 15 * * * root    [ $(crm_resource -Q -r cluster1 -W ) = $(hostname) ] && only-on-active.sh Obige Zeile führt only-on-active.sh nur auf dem Aktiven aus. cluster1 ist eine vorhandene Clustergruppe – hier kann auch der Name einer Ressource verwendet werden, wenn der Cluster keine Gruppen zur Gruppierung nutzt.

By cubewerk, ago

innodb fallback to myisam?!

Wir hatten die Tage das Problem, dass eine InnoDB auf myisam zurückgefallen ist. Für uns aus unklaren Gründen.   Ein plausibler Grund könnte jedoch sein, wenn in der my.conf für InnoDB Performancewerte (innodb_log_file_size) geändert werden – die zugehörige innoDB-Datei nicht gelöscht wird im Anschluss. Wenn sich die Größen ändern, muss die Datei gelöscht werden, damit Mysql die Gelegenheit hat, die Datei neu mit passender Größe anzulegen.

By cubewerk, ago

zmap vs. nmap 1:0

Ich war auf dem 30c3 und zmap hat mich umgehauen. Die Ansage war, dass man in ~ einer Stunde den kompletten ipv4 Adressbereich einmal scannen kann. Das würde Monate mit nmap dauern.   Voraussetzung ist ein Standard-PC – jedoch geht man bei obiger Geschwindigkeit von einem 1Gbit Uplink aus.   Der Grund für die enorme Performance von zmap ist, dass intern ein Teil der Komponenten die Anfragen stellt, eine zweite sich um die Auswertung der Antworten kümmert. So kann sichergestellt werden, dass keine Timeouts nötig sind, bis der nächste Host Read more…

By cubewerk, ago

drbdadm – corrupt data – Korrupte Daten feststellen

Wir haben seit Wochen das Problem, dass auf dem zweiten Clusterknoten mit DRBD nach einem Schwenk die Daten korrupt sind. Christian Hammers hat mich auf der DRBD-Mailingliste darauf hingewiesen (danke dafür!), ich könnte ja mal meine Ressource mit   drbdadm verify clusterdb_res prüfen   Hierzu war vorher noch nötig, in meiner DRBD-Konfiguration wie hier beschrieben http://www.drbd.org/users-guide-8.3/s-use-online-verify.html das verify zu aktivieren.   Im Anschluss wurden bereits die ersten out-of-sync blocks gefunden:   [439695.774285] block drbd0: Out of sync: start=688080, size=8 (sectors) [439695.774339] block drbd0: Out of sync: start=688096, size=8 (sectors) [439695.774390] Read more…

By cubewerk, ago

Cluster Knowhow 2013 – corosync – Score – Score Berechnung

Nach mehreren Anfragen an die Pacemaker-Mailingliste, div. äußerst hilfreichen Blogbeiträgen und etlichen Tests, möchte ich meine Erkenntnisse zur Score-Berechnung hier festhalten. Es dreht sich alles um Zahlen. Alle Clusterknoten sind per default gleichwertig. Das heißt, eine Ressource wird abwechselnd auf die Knoten verteilt. Ohne bevorzugte Präferenz. Die Entscheidung, auf welchem Knoten eine Ressource laufen kann, basiert auf Punktständen. Der Knoten, der die höchste Punktzahl erreicht, wird der aktive Knoten. Der Cluster pflegt selbst eine interne Liste, welche Ressource auf welchem Knoten, welche Punktzahl erreicht. Bei einer Ressource und zwei Knoten Read more…

By cubewerk, ago

CWDM Facts DWDM Facts – Fakten 2013

CWDM besteht aus passiven Komponenten. Das heißt, man kann das CWDM-Equipment nicht zum Wandeln der Wellenlänge nutzen (z.B. grau auf farbig) CWDM-Systeme müssen bereits mit der passenden Farbe eingehend versorgt werden. Hier kommen also zwingend teurere DWDM-SFPs zum Einsatz. DWDM ist aktives Equipment. Hier kann und muss von grau auf farbig mit passenden SFP-Modulen gewandelt werden. Häufiger Einsatzzweck von DWDM ist, wenn man SANs oder Switche besitzt, die nur mit grauer Wellenlänge ankommen. Der Aufbau eines DWDM-Systems sieht in etwa so aus: Service–>DWDM-System–>Multiplexer–>MonoMode-Paar(DarkFibre)–>Multiplexer–>DWDM-System–>Service(SWITCH) Über ein DWDM-System können 40 Services (optional Read more…

By cubewerk, ago

corosync apache2 FAILED

2 Empfehlungen: Soll Apache im Cluster überwacht werden, nehmt ocf::heartbeat:apache statt lsb:apache2. Ein Init-Skript ist selten so granular wie das OCF-Skript. Zweitens – nehmt sinnvolle Zeitparameter für start/stop – hier sind meine: primitive p_apache ocf::heartbeat:apache params configfile=“/etc/apache2/apache2.conf“ params httpd=“/usr/sbin/apache2 op monitor interval=“10″ timeout=“20s“ depth=“0″ op start interval=“0″ timeout=“40s“ op stop interval=“0″ timeout=“60s“

By cubewerk, ago