Eine regelmäßige Änderung von Kennwörtern ist unter gängigen Betriebssystemen kein Problem. Aber da gibt es ja auch noch SSH-Keys um sich an Servern anzumelden. Auch ein SSH-Key kann natürlich mit einem Kennwort geschützt werden. Der Server an dem man sich damit anmeldet kann aber weder prüfen ob der Key mit einem Kennwort geschützt ist, noch wann dieses gesetzt wurde. Es mag eine Spitzfindigkeit sein, aber gerade die machen ja oft besonders Spaß. In vielen Dokumenten zum Datenschutz wird eine regelmäßige Änderung von Kennwörtern gefordert, ist das bei einem SSH-Key der Fall? Und wie stellt der Admin das sicher?

Amazon Glacier ein Dienst für langfristige Backups. Die Daten werden auf Tapes archiviert, was beim Abruf zu einer etwas längeren Wartezeit führt, da die Daten zunächst vom Band auf eine Festplatte kopiert werden. Dafür ist Glacier geradezu spottbillig (etwa $0.0045 pro GB, bei S3 wären es etwa $0.0245). Hinzu kommen, ebenfalls geringe, Kosten für bestimmte Operationen. Die konkreten Preise unterscheiden sich je nach AWS-Region, eine Übersicht findet sich unter: https://aws.amazon.com/de/glacier/pricing/

Google bietet im Rahmen der Google Cloud Storage zwei Tarife (Coldline und Nearline) speziell für Backups an. Coldline ist für langfristige Backups gedacht auf die weniger als einmal im Jahr zugegriffen wird. Nearline für Daten die seltener als einmal im Monat gebraucht werden.

Im letzten Artikel habe ich ein minimalistisches Active/Active Clustersetup aufgebaut. Ein Problem hierbei, wenn mal der eine, mal der andere Server eine Anfrage beantwortet klappt das mit vielen PHP-Anwendungen nicht, da die ihre Session-Informationen standardmäßig im Dateisystem ablegen. Somit stehen die Sessions immer nur einem der Cluster-Nodes zur Verfügung. Abhilfe schafft hier memcached bzw. php5-memcache.

Die Installation wird wie folgt gestartet:

apt-get install memcached php5-memcache

An...

Ich habe hier im Blog ja schon öfter Artikel zu Clustern geschrieben, es handelte sich aber immer um Active/Passive Setups. Diesmal soll es ein Active/Active Setup werden.

Worin liegt der Unterschied? Bei einem Active/Passive Setup gibt es einen aktiven Node auf dem alle gewünschten Dienste gestartet sind. Auf dem passiven Node sind zwar dieselben Dienste und Daten vorhanden, aber nicht gestartet. Tritt auf dem aktiven Node ein Fehler auf werden die restlichen Dienste dort heruntergefahren und auf dem passiven Node gestartet. Das dauert natürlich etwas und in der Zeit sind die Dienste nicht erreichbar. In einem Active/Active Setup sind die Dienste auf allen Nodes gestartet und es gibt keine Downtime, wenn auf einem Node ein Fehler auftritt. Ein weiterer Vorteil, man kann die Last auf die Nodes verteilen.

Neben der Serverüberwachung mit Icinga/Nagios habe ich bisher immer Munin verwendet. Munin zeichnet Graphen z.B. für die aktuelle Serverlast (Load) oder die Belegung der Festplatten. Leider skaliert Munin nicht besonders gut. In festen Intervallen fragt Munin die verbundenen Clients nach neuen Daten und rendert neue Grafiken. Das dauert leider einigermaßen lang.

Eine ressourcensparendere Alternative ist collectd (https://collectd.org/).

Vor einiger Zeit habe ich bereits ein Cluster-Setup auf Pacemaker/Corosync-Basis unter Debian Wheezy hier verbloggt. Seitdem hat sich im Pacemakerumfeld ein wenig was getan und somit ist es an der Zeit für ein Update, diesmal mit CentOS7.

Die größte Neuerung (für mich) war der Wegfall des Cluster Resource Managers (crm), er wird durch pcs bzw. pcsd ersetzt, letzterer stellt sogar ein komfortables Webinterface zur Verwaltung des Clusters zur Verfügung.

Ich habe kürzlich beschlossen etwas über meinen Linux-Tellerrand zu schauen und habe mich mal ein wenig mit CentOS beschäftigt. Anfangs war auch alles ziemlich einfach, VirtualBox und los. Aber auf Dauer macht sowas nicht glücklich, also habe ich mich entschlossen es auf Xen-Basis nochmal zu probieren. Die erste Ernüchterung Xen auf CentOS 7-Basis geht nicht. CentOS 6.5 würde gehen, aber ich habe mich entschieden dann doch auf den bewährten Debian-Unterbau zu setzen.

Salt Stack ist ein Tool zur Verwaltung von Rechnern in einem Netzwerk. Es ist damit sehr leicht möglich eine große Anzahl von Maschinen einheitlich (oder auch individuell) zentral zu Konfigurieren.

Der Artikel geht von einem Hostingsetup mit mehreren Xen-Maschinen im Clusterbetrieb aus.