NodeJS HA mit PM2…

ich hatte in Vergangenheit bereits einen Blog Post über NodeJS in Verbindung mit dem NodeJS ‘Cluster’ Modul geschrieben ( siehe hier ), nun möchte ich euch zeigen wie Ihr eure NodeJS Anwendung auch ohne Programmierarbeit (also als reine Ops Tätigkeit) zum Cluster umfunktioniert und wie ihr diese anschließend verwalten könnt.
nodejs-logo-2015
Legen wir los, wir benötigen hierzu NodeJS, am besten 4.4 LTS und 4 zusätzliche Module/Helper, fangen wir also mit der Installation an…

$ npm install -g pm2
$ npm install -g express-generator
$ mkdir ~/project && cd project
$ npm install --save express
$ npm install --save sleep

…nun generieren wir das Express Anwendungsgerüst…

$ express -f .
   create : .
   create : ./package.json
   create : ./app.js
   create : ./public
   create : ./public/javascripts
   create : ./public/images
   create : ./public/stylesheets
   create : ./public/stylesheets/style.css
   create : ./routes
   create : ./routes/index.js
   create : ./routes/users.js
   create : ./views
   create : ./views/index.jade
   create : ./views/layout.jade
   create : ./views/error.jade
   create : ./bin
   create : ./bin/www
   install dependencies:
     $ cd . && npm install
   run the app:
     $ DEBUG=project:* npm start
$

… danach löschen wir in der Datei app.js alles von Zeile 13 bis 58, wir benötigen nur das Gerüst selbst und ein paar Zeile selbst geschriebenen Code, um diesen kommen wir leider nicht herum, da wir ja auch was sehen wollen.
Fügt nun ab Zeile 14 folgenden Code hinzu…

var crypto = require( 'crypto' );
var util = require( 'util' );
var sleep = require( 'sleep' ).sleep;
function getRandHash() {
    var current_date = (new Date()).valueOf().toString();
    var random = Math.random().toString();
    return crypto.createHash('sha1').update(current_date + random).digest('hex');
}
var myID = getRandHash();
app.get( '/', function( req, res ) {
    sleep( Math.floor( (Math.random() * 3) + 1 ) );
    res.send({
        "ID": myID,
        "PID": process.pid,
        "ENV": process.env
    });
});

…nun starten wir die App über PM2 im Cluster Mode, hier bitte dem Parameter ‘-i’ nur einen Wert gleich der Anzahl der CPU Cores mitgeben. Dann testen wir das Ganze doch gleich mal…

$ cd project
$ pm2 start bin/www -i 4

…ihr solltet nun folgende Ausgabe zu sehen bekommen…
pm2-start-www-cluster
…ihr könnt eure Anwendung auch auf Fehler überprüfen, dafür gibt euch PM2 einen Parameter ‘logs’ mit, der wiederum einige Flags kennt. Wenn ihr nur ‘pm2 logs’ eingebt dann bekommt ihr die Standardausgabe unserer Anwendung zu sehen, wenn ihr zusätzlich das Flag ‘–err’ mit angebt, bekommt ihr die Standard Fehlerausgabe, was für das Debugging recht hilfreich ist.
pm2-logs-examine
So, nun könnt ihr in eurem Browser mal die Anwendung aufrufen. Der Listener der Anwendung horcht auf dem Port 3000. Ein Aufruf auf http://127.0.0.1:3000 sollte ein JSON liefern, ähnlich zu dieser Ausgabe hier…
pm2-cluster-test1
Da wir in unserem Code eine künstliche Verzögerung eingebaut haben, könnt ihr nun mit 2 direkt Aufeinander folgenden Browser Reload sehen das sich die ID u. PID Werte gelegentlich ändern, dies bedeutet, dass unsere Cluster Anwendung funktioniert.
pm2-logo
Ich hoffe ich konnte euch nun zum Spielen und Experimentieren animieren. PM2 wird von der Firma Kissmetrics als OpenSource Project stetig weiter entwickelt und hat noch so viel mehr zu bieten, ganz findige unter euch werden die Monitoring API zu schätzen wissen und diese vmtl. in Icinga2, Graphite, Kibana und anderen Lösungen integrieren wollen.
Dann bis demnächst 🙂

KVM-Cluster: Hochverfügbarkeit und zuverlässiges Locking

Im Internet, in Büchern und einer Reihe von Fachartikeln findet sich umfangreiche Unterstützung für das Einrichten unterschiedlichster hochverfügbarer Linux-Cluster. Zur Zeit hoch im Kurs ist die Clusterlösung Pacemaker in Kombination mit Corosync/OpenAIS. Als Virtualisierungslösung mausert sich KVM (neben LXC) zum Produkt der Wahl. Und beides zusammen ergibt einen richtig schönen Cluster mit VMs, die “nach Belieben” von einem Rechner zum anderen wandern können. Oder auf Neudeutsch: eine “Private Cloud”.
Soweit nichts Neues, allerdings sind die meisten der vorgestellten Lösungen, die sich so finden, höchst riskant. Wer nämlich auf die Live-Migration nicht verzichten will, muss auf “Shared Storage” zurückgreifen. Dabei hat man die Wahl zwischen einer Lösung wie NFS (was man für VMs nicht unbedingt haben möchte), oder aber einem gemeinsamen Blockdevice (SAN, DRBD, iSCSI) mit einem Cluster-Filesystem wie GFS2 oder OCFS2. Bei vielen Knoten bieten sich Lustre, GlusterFS oder für wagemutige auch Ceph an – diese Lösungen lassen wir jetzt aber mal außen vor.

Soweit, so gut. Aber: QEMU/KVM betreibt keinerlei Locking für seine Disk Images. Das bedeutet, dass man sehr leicht versehentlich dasselbe Image zweimal gleichzeitig booten kann. So etwas hat katastrophale Auswirkungen, das Filesystem der VM wird schneller als einem lieb ist korrupt und ist zudem sehr bald kaum noch wiederherstellbar. Zwar kann man eine VM mit libvirt nicht zweimal gleichzeitig starten, wohl aber z.B. beim Clonen einer VM versehentlich dasselbe Image im XML-File stehen lassen. Genauso “tödlich” ist es, wenn in einem Cluster dieselbe VM auf zwei unterschiedlichen Knoten startet. Und spätestens in einer Split-Brain-Situation wird das früher oder später passieren.
Kürzlich konnte ich bei einem Kunden eine interessante Lösung hierfür implementieren. Libvirt bietet nämlich mittlerweile eine Schnittstelle für Lock-Manager an, und “sanlock” ist ein solcher. Damit gelang es nicht nur, auf einem GFS2 in Kombination mit mit einem Dual-Primary DRBD ein funktionierendes Locking für die VM-Images umzusetzen, sondern sogar in Kombination mit cLVM und GFS2-basiertem Sanlock auf dem DRBD sitzende einzelne Logical Volumes als virtuelle Disks den einzelnen VMs zuzuweisen.
Mit dem üblichen Minimal-Tuning für GFS2 bedeutete dies für die LVM-basierten VMs verglichen mit dem was wir in den GFS2-basierten messen konnten immer noch fast doppelten Durchsatz bei sequentiellem Schreiben und ein Fünftel der Latenzzeit!

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Anmeldung zur OSDC 2009 jetzt online!

Der Startschuss zur NETWAYS Open Source Data Center Conference ist gefallen. Ab sofort ist die Online-Anmeldung freigeschalten.
Mit der Open Source Data Center Conference zum Einsatz von Open Source Software in Rechenzentren und großen IT Umgebungen bietet NETWAYS die Gelegenheit, zur Teilnahme an hochkarätigen Vorträgen und Workshops führender Open Source Profis.
Interessante und spannende Diskussionen über die neuesten Trends und Möglichkeiten im Bereich OS Data Center Solutions, die vorgestellten Best Practices, sowie der Erfahrungsaustausch unter den Konferenzteilnehmern und das aktuellste Know-how werden Nürnberg einmal mehr als DIE Open Source Metropole glänzen lassen.
Und übrigens: Mit einer Registrierung bis zum 31.01.2009 ist die Teilnahme zu den besonders attraktiven Frühbucherpreisen gesichert.
Alle weiteren Informationen zur Open Source Data Center Conference 2009 finden Sie unter: http://www.netways.de/osdc

Pamela Drescher
Pamela Drescher
Head of Marketing

Pamela hat im Dezember 2015 das Marketing bei NETWAYS übernommen. Sie ist für die Corporate Identity unserer Veranstaltungen sowie von NETWAYS insgesamt verantwortlich. Die enge Zusammenarbeit mit Events ergibt sich aus dem Umstand heraus, dass sie vor ein paar Jahren mit Markus zusammen die Eventsabteilung geleitet hat und diese äußerst vorzügliche Zusammenarbeit nun auch die Bereiche Events und Marketing noch enger verknüpft. Privat ist sie Anführerin einer vier Mitglieder starken Katzenhorde, was ihr den absolut...