Nginx: Webserver – klein und schnell

Wenn es um Webserver geht, fällt den meisten Administratoren zuerst Apache ein, der in der globalen Statistik des Web auch den ersten Rang belegt ( Abbildung 1 ). Kleinere und schnellere Alternativen gewinnen aber immer mehr Anhänger, etwa Lighttpd und Cherokee.

Abbildung 1: Wie die grüne Linie rechts unten zeigt, gewinnt Nginx immer mehr Anhänger. (Quelle: Netcraft)

Als zusätzlicher Wettbewerber stieg vor einiger Zeit der Nginx-Server (englisch ausgesprochen Engine-ex) in den Ring [1] . Er steht für hohe Performance, Stabilität, umfangreiche Features, einfache Konfiguration und geringen Ressourcenverbrauch. Das Resultat der Bemühungen des Programmierers Igor Sysoev verrichtet seinen Dienst in vielen großen Sites, zum Beispiel Wordpress.com, Hulu und Linuxquestions.org. Ungewöhnlich: Außer als Webserver kann Nginx auch als Proxy für die Mailprotokolle IMAP und POP3 auftreten.

In der Domäne HTTP kann Nginx die folgenden Fähigkeiten vorweisen: statische Dateien ausliefern, reverse Proxying mit optionalem Caching, fehlertolerantes Load Balancing, remote Fast-CGI mit Caching/Beschleunigung und SSL/TLS Server Name Indication (SNI), was die Notwendigkeit einer eigenen IP-Adresse zur SSL-Konfiguration für jeden virtuellen Server überflüssig macht.

Wie Apache ist Nginx modular aufgebaut und bietet einiges an Funktionalität über Module an, die der Administrator aktivieren oder deaktivieren kann. Anders als der Prozess-basierte Apache verarbeitet Nginx alle Anfragen asynchron und skaliert dadurch wesentlich besser.

Wenn Sie nur eine einfache Site betreiben oder gerade ein Projekt neu starten, können Sie möglicherweise auch komplett auf Apache verzichten. Am besten werfen Sie einen Blick auf die Modules-Seite von Nginx [2] und prüfen, ob die Module ihre Ansprüche befriedigen. Dieser Artikel beschreibt einen typischen Aufbau, in dem Nginx als die Last ausgleichender Revery Proxy vor mehreren Apache-Backends arbeitet. Nginx liefert einen Teil der statischen Inhalte aus und komprimiert selbsttätig die dynamischen Seiten, die vom Apache kommen.

Die meisten Linux-Distributionen führen Nginx-Pakete in ihren Repositories, sodass sich der Server leicht über den Paketmanager installieren lässt. Wenn das Paket zu alt ist oder ganz fehlt, finden Sie den Quellcode auf der Nginx-Homepage. Die Installation läuft über die typischen Configure- und Make-Aufrufe. Obwohl die Defaults in den meisten Fällen wohl in Ordnung sind, sollten Sie einen Blick auf die Konfiguration werfen und sie gegebenenfalls anpassen.

Die Ausgabe von Configure sieht typischerweise etwa so aus:

Configuration summary
  + using system PCRE library
  + using system OpenSSL library
  + md5: using OpenSSL library
  + using sha1 library: /usr/include
  + using system zlib library

Sie sollten sicherstellen, dass die geforderten Bibliotheken auch installiert sind, wenn Sie die entsprechende Funktionalität nutzen möchten. So erfordert Rewrite beispielsweise die PCRE-Library, und SSL setzt die Open-SSL-Bibliothek voraus.

Abbildung 2: Zusätzlich zu Konfigurationsbeispielen und Dokumentation bietet die Nginx-Community auch Mailinglisten, ein Forum und einen IRC-Kanal zum Chatten.

Einstellungssache

Dieser Artikel bezieht sich auf eine aus drei Servern bestehende Infrastruktur. Der Computer mit Nginx befindet sich im Internet vor den beiden Rechnern, die dahinter im privaten Netz stehen. Sie haben deshalb auch keine IP-Adresse im Internet. Tabelle 1 fasst das Layout zusammen. Die zugehörige Konfigurationsdatei »nginx.conf« sieht aus wie in Listing 1 .

Diese Konfiguration führt zu dem Ergebnis, dass beide Backend-Server ungefähr gleich viele Zugriffe abbekommen. Per Default führt Nginx ein einfaches Load Balancing nach der Round-Robin-Methode durch, das heißt, bei jeder Anfrage ist einfach der nächste Backend-Server dran. Um eine Verteilung basierend auf der IP-Adresse des anfragenden Clients zu realisieren, bietet Nginx die Konfigurationsdirektive »ip_hash« . Ausgefeiltere Load-Balancing-Methoden sind für künftige Nginx-Versionen geplant.

Ohne weiteres Zutun kommen die Requests bei den Backend-Servern alle mit der IP-Adresse des Nginx-Frontends an. Am besten übergeben Sie die IP-Adresse der ursprünglichen Anfrage mit dem HTTP-Header »X-Forwarded-For« und verarbeiten sie in den Apache-Prozessen mit dem Modul »mod_rpaf« weiter. Es schreibt die Remote-Adresse wieder um, sodass andere Apache-Module die gewünschte Information erhalten. Das freie Modul finden Sie auf der Website [3] .

SSL-sicher

Nginx als SSL-Proxy zu verwenden bringt mehrere Vorteile. Die Apache-Konfiguration vereinfacht sich, die CPU-Belastung durch SSL-Verschlüsselung wird verringert und das Load Balancing wird einfacher, da der Admin sich nicht um SSL-Sessions kümmern muss. SSL mit Nginx einrichten ist einfach und setzt die gleichen CRT- und KEY-Dateien voraus wie sonst Apache. Die zusätzlichen Einstellungen zeigt Listing 2 .

Allerdings gibt es zwei Einschränkungen beim Nginx-SSL-Support. Die Stable-Version beherrscht keine Revocation Lists, mit denen sich Zertifikate ungültig machen lassen. In der Entwicklerversion ist diese Funktion aber bereits unterstützt. Außerdem lassen sich Chain-Zertifikate nicht wie bei Apache in extra Dateien verwalten. Stattdessen muss der Administrator die Daten des Chain-Zertifikats an das Hauptzertifikat anhängen, zum Beispiel mit »cat chain.crt >> server.crt« . Danach braucht er sich nicht weiter um das Chain-Zertifikat zu kümmern, sondern kann wie gehabt mit dem im Konfigurationspunkt »ssl_certificate« angegebenen Zertifikat arbeiten.