Improved NodeJS Events durch Cluster …


… jeder von euch kennt das Problem, der Kollege kommt um die Ecke und möchte wenn möglich sofort, dass ein neues geiles Tools mit in den Infra Stack aufgenommen wird, gesagt getan.
In diesem Bespiel eine besonders cooles in NodeJS geschriebenes Dashboard für… lass es hier ein DockerManagement Tool sein. Dabei stößt man bei der großen Akzeptanz durch die Kollegen, auch auf einmal auf noch ganz andere Probleme (Stichwort: Performance Bottlenecks wie DDoS durch eigene Leute).
Hierbei könnte euch das NodeJS Modul Cluster behilflich sein, hier ist die Doku zu finden.
Cluster macht dabei nicht viel, es erweitert den NodeJS Stack insbesondere das Event Driven Modell von NodeJS ( so Arbeitet Google(s) v8 Engine ) um eine Art Interprocess Schnittstelle zu forked Child NodeJS Prozessen, die sich dabei Filesystem Elemente/Typen wie Sockets, Filedeskriptoren etc. teilen können und somit gemeinsam auf diesen operieren können.
Hier wollen wir eine schon bestehende Express Framework Anwendung mit einigen wenigen Zeilen Code um die Fähigkeit erweitern, dem System zur Verfügung stehenden CPU Cores effizienter ausnutzen zu können, damit sich die Events schneller abarbeiten lassen.
Ich werde hier allerdings nicht Express selber beschreiben, sondern setzte hier voraus das der Leser dieses Framework kennt. Wenn nicht könnt ihr die Infos unter diesem Link abrufen, so let’s beginn …

$ sudo -i                                  # <- da meine Workstation ein Ubuntu ist sollten wir zumindest was die Essentials sind kurz zu 'root' werden um diese Problemlos installiert zu bekommen
$ npm install express -g                   # <- installiert uns das Express Framework samt CLI Tools
express@4.13.3 /usr/lib/node_modules/express
├── escape-html@1.0.2
├── merge-descriptors@1.0.0
├── cookie@0.1.3
├── array-flatten@1.1.1
├── cookie-signature@1.0.6
├── utils-merge@1.0.0
├── content-type@1.0.1
├── fresh@0.3.0
├── path-to-regexp@0.1.7
├── content-disposition@0.5.0
├── vary@1.0.1
├── etag@1.7.0
├── serve-static@1.10.0
├── range-parser@1.0.2
├── methods@1.1.1
├── parseurl@1.3.0
├── depd@1.0.1
├── qs@4.0.0
├── on-finished@2.3.0 (ee-first@1.1.1)
├── finalhandler@0.4.0 (unpipe@1.0.0)
├── debug@2.2.0 (ms@0.7.1)
├── proxy-addr@1.0.8 (forwarded@0.1.0, ipaddr.js@1.0.1)
├── send@0.13.0 (destroy@1.0.3, statuses@1.2.1, ms@0.7.1, mime@1.3.4, http-errors@1.3.1)
├── type-is@1.6.9 (media-typer@0.3.0, mime-types@2.1.7)
└── accepts@1.2.13 (negotiator@0.5.3, mime-types@2.1.7)
$ npm install express-generator -g
/usr/bin/express -> /usr/lib/node_modules/express-generator/bin/express
express-generator@4.13.1 /usr/lib/node_modules/express-generator
├── sorted-object@1.0.0
├── commander@2.7.1 (graceful-readlink@1.0.1)
└── mkdirp@0.5.1 (minimist@0.0.8)
$ exit                                     # <- ab hier geht es ohne 'root' Rechte weiter
$ mkdir cool-app && cd cool-app            # <- Projekt Verzeichnis anlegen und in dieses wechseln
$ pwd                                      # <- vergewissern das wir uns auch in diesem wirklich befinden
/home/enzo/nodejsProjects/cool-app
$ express --git .                          # <- wir provisionieren uns unser Projekt from Scratch, dieses ist somit direkt Lauffähig ohne das wir einen Zeile Code schreiben müssen, haben hier leider keine Zeit zu 😉
   create : .
   create : ./package.json
   create : ./app.js
   create : ./.gitignore
   create : ./public
   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
   create : ./public/javascripts
   create : ./public/images
   create : ./public/stylesheets
   create : ./public/stylesheets/style.css
   install dependencies:
     $ cd . && npm install
   run the app:
     $ DEBUG=cool-app:* npm start
$

Ab hier können wir das ganze mal kurz testen, um uns zu vergewissern das die Anwendung auch läuft ...

$ npm start
> cool-app@0.0.0 start /home/enzo/nodejsProjects/cool-app
> node ./bin/www

Nicht wundern die Applikation bleibt im Vordergrund hängen, was ist Ok ist, somit können wir diese schneller terminieren und relaunchen. Weiter geht es mit einem Test im Browser, die Anwendung lauscht standardmäßig am Port 3000, somit rufen wir hier einmal http://localhost:3000 auf und lassen uns überraschen was da so schönes kommt ...

Geil es läuft also, nun gut machen wir das ganze mit Cluster noch skalierbarer, let's go ...
Öffnet hierzu im Projekt Verzeichnis einmal die bin/www Datei, diese stellt laut package.json unseren Eintrittspunkt in die Anwendung dar, wir kopieren uns diese als Backup weg bevor wir anfangen hier Änderungen vorzunehmen.
Kommentiert bitte folgende Zeilen einmal aus ...

/**
 * Get port from environment and store in Express.
 */
var port = normalizePort(process.env.PORT || '3000');
app.set('port', port);
/**
 * Create HTTP server.
 */
var server = http.createServer(app);
/**
 * Listen on provided port, on all network interfaces.
 */
server.listen(port);
server.on('error', onError);
server.on('listening', onListening);

... nun fügt ihr ab Zeile 10 bitte folgendes hinzu ...

// cluster requirements
var cluster = require('cluster');
var numCPUs = require('os').cpus().length;
if( cluster.isMaster ) {
  for( var i = 0; i < numCPUs; i++ ) {
    cluster.fork();
  }
  cluster.on( 'listening', function( worker ){
    console.log( 'worker ' + worker.process.pid + ' is now listen for incoming connections ... ' );
  });
  cluster.on( 'exit', function( worker, code, signal ) {
    console.log( 'worker ' + worker.process.pid + ' died' );
  });
} else {
    // Workers can share any TCP connection
    // In this case it is an HTTP server
    /**
    * Get port from environment and store in Express.
    */
    var port = normalizePort(process.env.PORT || '3000');
    app.set('port', port);
    /**
    * Create HTTP server.
    */
    var server = http.createServer(app);
    /**
    * Listen on provided port, on all network interfaces.
    */
    server.listen(port);
    server.on('error', onError);
    server.on('listening', onListening);
}

.. jetzt sollte das ganze auch schon funktionieren, probieren wir es doch einmal aus.

$ npm start
> cool-app@0.0.0 start /home/enzo/nodejsProjects/cool-app
> node ./bin/www
worker 31979 is now listen for incoming connections ...
worker 31974 is now listen for incoming connections ...
worker 31985 is now listen for incoming connections ...
worker 31996 is now listen for incoming connections ...
GET / 304 840.784 ms - -
GET /stylesheets/style.css 304 31.416 ms - -

Jetzt könnte man denken das sich hier nichts geändert hat, dem ist aber nicht so, der Beweis ist in der Prozess Tabelle zu finden, gucken wir doch kurz einmal hinein ...

$ ps auxf | grep node
enzo     31969  0.1  0.4 901264 33004 pts/7    Sl+  14:47   0:00          |   |       \_ node ./bin/www
enzo     31974  0.1  0.4 901256 32324 pts/7    Sl+  14:47   0:00          |   |           \_ /usr/bin/nodejs /home/enzo/nodejsProjects/cool-app/bin/www
enzo     31979  0.4  0.6 946192 47560 pts/7    Sl+  14:47   0:01          |   |           \_ /usr/bin/nodejs /home/enzo/nodejsProjects/cool-app/bin/www
enzo     31985  0.1  0.4 902668 32736 pts/7    Sl+  14:47   0:00          |   |           \_ /usr/bin/nodejs /home/enzo/nodejsProjects/cool-app/bin/www
enzo     31996  0.1  0.4 901256 32168 pts/7    Sl+  14:47   0:00          |   |           \_ /usr/bin/nodejs /home/enzo/nodejsProjects/cool-app/bin/www

Whoop whoop, 4 neue NodeJS Prozesse die hier ihre Arbeit verrichten, somit lassen sich auch die beschäftigsten Web Anwendungen wieder beschleunigen.
Das ist aber nur der Anfang wie sich NodeJS Applications aller Art verbessern lassen, für weiter Themen habe ich heute allerdings keine Zeit daher heben wir uns den Rest einfach für ein anderes mal auf.
Ich wünsche euch hiermit noch viel Spaß, ich hoffe ihr habt nun mehr Lust auf NodeJS bekommen.

Load Balancing mit dem Raspberry Pi – ein kleines Praxisbeispiel mit ldirectord

Was im großen geht, das geht natürlich auch im Kleinen.
Da sich meine Bastelaktivitäten mit dem Raspberry Pi mit der Zeit immer mehr eingestellt haben, da einige Projekte umgesetzt und andere wiederum im Sande verlaufen sind, stellte sich die Frage, was man denn nun mit den kleinen Rechenzwergen anfangen könnte. Zum brach rumliegen sind sie ja definitiv zu schade 😉
Da ich es immer schon ein wenig n3rd1g fand ein Webprojekt direkt von daheim zu hosten und das ganze möglichst ausfallsicher zu gestalten, entschied ich mich dazu einen kleinen Blog auf meinen RPi’s zu betreiben.
Damit alle meine Pi’s eine sinnvolle Tätigkeit bekommen, entschied ich mich einen Loadbalancer auf dem einen zu installieren und die restlichen zwei als “App-Server” laufen zu lassen.
Hierbei ist die Software IPVS in Verbindung mit dem Ldirectord auf jeden Fall eine gute Wahl. Ldirectord ist ein Daemon, welcher mit IPVS spricht und noch viele Funktionen mitbringt, die IPVS von Hause aus nicht abdecken kann, wie zum Beispiel das automatische Herausnehmen eines Servers aus einem Load Balancing Pool, wenn dieser nicht den gewünschten Content ausliefert.
Es stehen mehrere Möglichkeiten zur Auswahl, wie der Load Balancer mit den Real-Servern (also unsere App-Server) die Daten austauschen kann. Die wichtigsten stellen wohl das Direct-Routing und das Masquerading dar.
In diesem Beispiel habe ich mich für Direct-Routing entschieden, da Masquerading doch zu einem Teil auf die Rechenleistung des Raspberry’s niederschlägt.
Auf dem Loadbalancer reicht es aus, wenn das Paket ldirectord installiert wird. Alle benötigten Abhängigkeiten wie IPVS werden automatisch mit installiert.

Konfiguration ldirectord

Nach abgeschlossener Installation muss zunächst die Datei /etc/default/ldirectord angepasst werden. Hier wird über die Variable “CONFIG_FILE” der Ort der Config definiert:

# Set the following variable to define a default configuration
# file for ldirectord.
CONFIG_FILE=/etc/ldirectord.cf

Im Anschluss muss jene Datei natürlich noch angelegt und mit dem richtigen Inhalt befüllt werden, wie in folgendem Beispiel:

# Global Directives
checktimeout=10
checkinterval=10
fallback=127.0.0.1:80
autoreload=yes
logfile="/var/log/ldirectord.log"
quiescent=no
#callback="/usr/local/bin/sync_ldirectord"
# Virtual Server for HTTP
virtual=192.168.0.40:80
real=192.168.0.41:80 gate
real=192.168.0.42:80 gate
service=http
request="alive.html"
receive="foobar3000"
scheduler=rr
# persistent=600
protocol=tcp
checktype=negotiate

Die Config ist an und für sich recht einfach zu verstehen. Ein paar Einträge möchte ich jedoch erklären:
callback: Hier kann ein Script angegeben werden, welches nach einem Autoreload ausgeführt wird. Üblicherweise sollte hier eine Synchronisation zu einem zweiten Load Balancer statt finden.
virtual: Die IP samt Port für den Service, der balanced werden soll. Diese IP ist von außen direkt ansprechbar (einfach gesagt: Die IP kommt in den A-Record 😉 ) und muss auf dem Load Balancer als zusätzliche IP konfiguriert werden. Dahinter stehen die Realserver, auf die Anfragen verteilt werden.
checktype: Art der Überprüfung, ob ein Realserver ordnungsgemäß funktioniert. Bei einem Webdienst ist negotiate anzuraten, da hierbei ein Ergebnis (receive) angegeben werden kann, welches bei der Anforderung (request) zurückgegeben werden muss.
scheduler: Die Art, wie verteilt wird. Hier wird nur die Abkürzung eingetragen. Welche Arten es gibt, kann in der Man-Page von ipvsadm nachgelesen werden (Schalter -s, –scheduler)
fallback: Der Name ist selbsterklärend 😉 Sollten Alle Realserver aus dem Pool rausspringen, so wird ein Fallback Server (in unserem Beispiel localhost) eingesetzt. Hier kann beispielsweise eine Wartungsseite ausgeliefert werden.
Nachdem nun auch die Service-IP auf dem Load Balancer-Pi eingerichtet wurde (ifconfig eth0:1 192.168.0.40/32 – in unserem Beispiel), kann der Ldirectord gestartet werden. Im definierten Logfile werden wir jedoch feststellen, dass der Ldirector seine Realserver noch nicht erreichen kann und somit auf den Fallback Server geschaltet hat.

Konfiguration App-Server

Unsere Realserver können leider nicht ohne Weiteres die Anfragen, die vom Load Balancer kommen verarbeiten. Immerhin wird ja die Anfrage direkt an die IP 192.168.0.40 gestellt, welche ja auf den Systemen nicht bekannt ist. Damit das funktioniert, muss die Service-IP auf den Real-Servern noch als Loopbackdevice gebunden werden, damit sich der Realserver auch angesprochen fühlt. Jedoch Vorsicht: Nicht einfach so die Service IP als Loopback einbinden! Das würde dazu führen, dass der Realserver ARP-Anfragen mit seiner MAC-Adresse beantwortet, was wir ja nicht wollen. Das könnte den gesamten Dienst still legen. Hier muss im Vorfeld noch folgendes in die /etc/sysctl.conf eingetragen und mit sysctl -p übernommen werden, was das Verhalten unterbindet:

net.ipv4.conf.all.arp_ignore = 0
net.ipv4.conf.default.arp_ignore = 0
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.lo.arp_ignore = 0
net.ipv4.conf.all.arp_announce = 0
net.ipv4.conf.default.arp_announce = 0
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.lo.arp_announce = 0

Nun kann das Loopbackdevice hochgefahren werden:

root@rpi1:~# ifconfig lo:1 192.168.0.40/32

Sobald nun der Realserver die Datei “alive.html” mit dem Inhalt “foobar3000” ausliefern kann, wird er auch im Load Balancer als aktiv markiert und die Anfragen werden entsprechend weitergeleitet. Das der Webdienst richtig dafür eingerichtet wurde, setze ich an der Stelle einfach mal voraus 😉
Das Schöne am Ldirectord ist, dass er sich nicht nur auf Webdienste beschränkt. Es kann jeder TCP/UDP Dienst über den Load Balancer verteilt werden. Durch die optional einstellbare Persistenz kann auch sichergestellt werden, dass eine Verbindung immer wieder bei dem gleichen Realserver ankommen wird (für den konfigurierten Zeitraum).

Einfache Lastverteilung unter Linux ohne Loadbalancer

Wer eine einfache und robuste Methode zur Lastverteilung seines Netztraffics sucht, wird bei netfilter fündig. Mit dem Target CLUSTERIP lässt sich auf einfachste Weise ein mehrere Knoten umfassender Cluster aufbauen. Zum Verfahren: Es findet eine gemeinsame IP-Adresse auf allen Knoten Verwendung und wird dort auch aufgesetzt, so dass nun alle Knoten auf diese Adresse antworten könnten. Da dies natürlich zu Verwirrungen bei ARP-Anfragen vom anfragenden Host bzw. Router führt, verwendet CLUSTERIP eine Multicast MAC für die Cluster-IP-Adresse. D.h. eingehende Pakete werden auf allen beteiligten Knoten empfangen. Damit nun aber nicht jeder Knoten auf die Anfrage antwortet, verwendet CLUSTERIP einen Hash über wahlweise die Source-IP, Source-IP und -Port oder Source-IP,-Port und Destination-Port, um zu entscheiden, ob er auf die Anfrage antworten darf. Somit ist auch keine Kommunikation der Knoten untereinander nötig, um zu entscheiden wer der “richtige” Knoten ist.
Hier nun ein kleines Beispiel, eines Webclusters, bestehend aus den beiden Knoten node1 und node2. Es reichen jeweils zwei Kommandos aus, den Cluster zu erzeugen.
Kommandos auf node1:
root@node1# iptables -A INPUT -i eth1 -d 192.168.56.20 -p tcp –dport 80 -j CLUSTERIP –new –hashmode sourceip –clustermac 01:23:45:67:89:AB –total-nodes 2 –local-node 1
root@node1# ifconfig eth1:0 192.168.56.20/24 up
Analog ist auf node2 mit
root@node2# iptables -A INPUT -i eth1 -d 192.168.56.20 -p tcp –dport 80 -j CLUSTERIP –new –hashmode sourceip –clustermac 01:23:45:67:89:AB –total-nodes 2 –local-node 2
root@node2# ifconfig eth1:0 192.168.56.20/24
die Konfiguration abgeschlossen. Die Destination-Adresse ist die geimeinsame IP, wir verwenden in diesem Beispiel nur die Source-IP als Hash. Da in diesem Beispiel auf beiden Konten das gleiche Interface eth1 werwendet wird, unterscheiden sich die beiden Befehle lediglich in der Option  –local-node, welche die “Position” im Cluster bestimmt bzw. um den wievielten Knoten es sich handelt. Dies kann nun auch mit
root@node1# cat /proc/net/ipt_CLUSTERIP/192.168.56.20
dem Kernel entnommen werden. Hier steht also drin, für was der jeweilige Host zuständig ist. Möchte man nun z.B. node1 aus dem Cluster herausnehmen, muss man dies über eine Konfiguration auf beiden Hosts vornehmen.
root@node1# echo “-1” > /proc/net/ipt_CLUSTERIP/192.168.56.20
root@node2# echo “+1” > /proc/net/ipt_CLUSTERIP/192.168.56.20

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Call for Papers für die Open Source Datacenter Conference 2009

Der Call for Papers zur ersten NETWAYS Open Source Datacenter Conference hat begonnen.
Die am 29. und 30. April 2009 im NH Hotel Nürnberg-City stattfindende Konferenz zum Einsatz von Open Source Software in Rechenzentren und großen IT Umgebungen, richtet sich vornehmlich an erfahrene Administratoren und Architekten und ist auf folgende Themenfelder ausgerichtet:

  • Cluster & Hochverfügbarkeit
  • Loadbalancing
  • Security & Firewalls
  • Monitoring
  • Change & Configuration Management

Interessenten können ab sofort unter http://www.netways.de/osdc/ Vorschläge für Konferenzbeiträge  einreichen. Dort finden Sie auch alle weitergehenden Informationen und Voraussetzungen. Einsendeschluss ist der 30. November 2008. Wir freuen uns auf Ihre Präsentationen und Ideen!
Alles weitere rund um die NETWAYS Open Source Datacenter 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...