Redundante Servervirtualisierung

Gekürzte und etwas veränderte Dokumentation eines Projekts der Firma Sylphen, welches ich durchgeführt habe. Achtung! Diese Informationen sind relativ alt und ich würde es heute auch nicht mehr so machen. Wer keine Angst vor Microsoft hat, sollte sich auf jeden Fall den kostenlosen Hyper-V Server 2012 anschauen.

Projektbeschreibung

Aus Platz-, Kosten- und Energieeffizienzgründen sollen die bestehenden physikalischen Server eines Unternehmens virtualisiert und auf einem einzigen physikalischen Server in virtuellen Maschinen installiert werden.

Weiterhin soll ein Backupserver zur Verfügung gestellt werden, der bei einem Ausfall des Hauptservers dessen Arbeit übernimmt, so dass ein unterbrechungsfreier Arbeitsfluss gewährleistet wird. Hier wird ein Distributed Replicated Block Device (DRBD) angestrebt, welches, ähnlich einem RAID1-System, für Redundanz im Serverbetrieb sorgt und somit eine optimale Lösung für einen Ausfallserver darstellt.

Lösungsansätze

In Betracht kamen zwei Lösungsansätze:

  1. Synchronisierung des Hauptservers mit dem Ausfallserver über rSync
  2. Einsatz eines DRBD

Aufgrund der großen Datenmengen würde rSync schnell an seine Grenzen geraten, insbesondere da virtuelle Maschinen teilweise sehr groß (10 GB und mehr) werden können. Würde nun während einer Synchronisierungsphase der Hauptserver ausfallen, wäre die virtuelle Maschine, die gerade synchronisiert wird, auf dem Ausfallserver ebenfalls defekt. Der entscheidende Vorteil von DRBD ist jedoch aufgrund der Ähnlichkeit zu einem RAID1, dass hier jedes geänderte Bit einzeln übertragen wird und bei Ausfall des Hauptservers das Backup nur wenige Sekunden alt ist und die Arbeit nach nur einer kurzen Unterbrechung direkt wieder an der Stelle aufgenommen werden kann, die zum Zeitpunkt des Ausfalls bestand.

Der Einsatz von DRBD ist somit die geeignetste Lösung.

Realisierung

Grundsystem

Als Grundsystem wird ein Debian 5.0 (Lenny) 64bit installiert, auf dem der VMware-Server installiert wird. Da das Betreiben eines VMware-Servers auf dem Host-System keine großen Ansprüche hat, reicht die Basisinstallation des Debian-Systems.

Dabei werden dem System eine statische IP sowie ein Hostname zugewiesen. Der Server erhält folgende Netzwerkkonfiguration für die erste Netzwerkkarte (eth0):

Hostname: hauptserver
IP: 192.168.0.11
Subnetzmaske: 255.255.255.0
Standardgateway: 192.168.0.254

Die Rolle des Standardgateways übernimmt hier der vorhandene DSL-Router.

Es wird zusätzlich zu root der Benutzer vmware eingerichtet.

Um zu gewährleisten, dass keine aktuell bekannten Probleme den Betrieb stören, wird ein Update des Debian-Systems mit apt-get update durchgeführt.

Der Backupserver erhält die gleiche Konfiguration wie der Hauptserver. Einzig die IP-Adresse und der Hostname werden anders gewählt:

Hostname: ausfallserver
IP: 192.168.0.12

DRBD

Auf beiden Systemen kann nun DRBD installiert werden. Dazu ist es notwendig, noch einige Pakete zu installieren:

apt-get install make gcc flex drbd8-utils drbd8-modules-2.6-686
apt-get install linux-headers-2.6.26-686 psmisc build-essential

Es wird zunächst in das Verzeichnis /usr/src gewechselt, um die Source-Dateien von DRBD herunter zu laden und zu entpacken:

wget http://oss.linbit.com/drbd/8.3/drbd-8.3.1.tar.gz
tar -xzf drbd-8.3.1.tar.gz

DRBD soll als Modul gestartet werden, also nicht direkt in den Kernel eingebunden werden. Deshalb wird folgender Befehl ausgeführt:

cd drbd-8.3.1
make clean all

Ist die Kompilierung zum Modul erfolgreich verlaufen, wird das Modul im System installiert:

make install

Beide Systeme erhalten nun auf der zweiten Netzwerkkarte IP-Adressen, um miteinander kommunizieren zu können. Die zweite Netzwerkarte ist insofern nützlich, als das der gewöhnliche Netzwerk-Verkehr durch das DRBD nicht eingeschränkt wird.

Das Hauptsystem, hauptserver, erhält die IP-Adresse 192.168.1.11 auf eth1 und der Backupserver, ausfallserver, erhält die IP-Adresse 192.168.1.12 auf eth1.

Wichtig ist es, in die Datei /etc/hosts beide Server mit ihren Adressen auf eth1 einzutragen, um später eine Namensauflösung zu ermöglichen:

192.168.1.11            hauptserver
192.168.1.12            ausfallserver

Die Systeme werden direkt miteinander verbunden, um den Umweg über einen Switch zu vermeiden, womit auch eine potentielle Problem- oder Fehlerquelle ausgeschlossen wird.

Nach der Installation des DRBD-Moduls und der Konfiguration der Netzwerkumgebung wird die Datei /etc/drbd.conf auf jedem Server angepasst.

global {
  usage-count no;
}

common {
  protocol C;
}

resource r0 {
  on hauptserver {
    device    /dev/drbd0;
    disk      /dev/sdb;
    address   192.168.1.11:7789;
    meta-disk internal;
  }
  on ausfallserver {
    device    /dev/drbd0;
    disk      /dev/sdb;
    address   192.168.1.12:7789;
    meta-disk internal;
  }
}

Um das DRBD zu initialisieren, wird der Befehl drbdadm up r0 ausgeführt. Dieser Befehl beinhaltet die einzelnen Befehle create-md, attach, syncer und connect. Mit create-md werden die Metadaten des DRBD erstellt. Der Befehl attach asoziiert das DRBD mit seinem Gegenpart, während syncer die die Synchronisierungsparameter setzt und connect schließlich die Verbindung zum Gegenpart herstellt.

Um zu prüfen, ob das DRBD erfolgreich initialisiert wurde, wird der Befehl cat /proc/drbd eingegeben. Das Ergebnis sieht ungefähr wie folgt aus:

version: 0.7.22 (api:79/proto:74)
SVN Revision: 2554 build by root@hauptserver, 2009-06-19 20:47:34
 0: cs:Connected st:Secondary/Secondary ld:Inconsistent
    ns:0 nr:0 dw:0 dr:0 al:0 bm:752 lo:0 pe:0 ua:0 ap:0

Um dem DRBD nun noch mitzuteilen, welches System das Primärsystem ist, wird folgender Befehl auf hauptserver eingegeben:

drbdadm -- --overwrite-data-of-peer primary r0

DRBD beginnt nun, sich zu synchronisieren, was einige Minuten in Anspruch nimmt. Das DRBD ist somit erschaffen.

Im Anschluss wird das DRBD mit einem Dateisystem zu versehen, damit es verwendet werden kann:

 mkfs.ext3 /dev/drbd0

Heartbeat

Damit ausfallserver im Notfall als Ausfallserver einspringen kann, ist es notwendig, zusätzlich ein Heartbeat-Service einzurichten. Andernfalls würde das DRBD nur ein nicht-lesbares Device auf ausfallserver zur Verfügung stellen.

Zunächst wird Heartbeat auf beiden Systemen installiert:

apt-get install heartbeat-2

Für die Konfiguration des Heartbeat-Services werden nun auf hauptserver die Konfigurationsdateien erstellt:

cd /etc/ha.d
cp -a /usr/share/doc/heartbeat-2/authkeys .
chmod 0600 authkeys
cp -a /usr/share/doc/heartbeat-2/ha.cf.gz .
gunzip ha.cf.gz
cp -a /usr/share/doc/heartbeat-2/haresources.gz .
gunzip haresources.gz

Die Datei ha.cf wird folgendermaßen angepasst:

logfacility     local0
ucast eth1 192.168.1.12
auto_failback on
node    hauptserver
node    ausfallserver

Die Datei  haresources wird mit folgenden Werten gespeichert:

hauptserver drbddisk::r0 \ Filesystem::/dev/drbd0::/data::ext3 \

Zum Abschluss der Grundkonfiguration wird in der Datei authkeys noch die Authentifizierungsmethode gewählt. Da es sich um eine vertrauenswürdige Umgebung handelt, wird die einfachste Methode „CRC“ gewählt:

auth 1
1 crc

Anschließend werden die Konfigurationsdateien, die auf beiden Servern, mit einer Ausnahme in der ha.cf, identisch sein müssen, nach ausfallserver übertragen:

scp ha.cf haresources authkey ausfallserver$PWD:

Auf ausfallserver wird in der ha.cf die IP-Adresse auf 192.168.1.11 geändert.

Initial wird der Heartbeat-Service mit folgendem Befehl auf beiden Systemen gestartet:

/etc/init.d/heartbeat

Unter /data ist nun der Speicherplatz vorhanden, der für die VMs genutzt werden soll.

VMware

Zur Installation des VMware-Servers sind weiterhin noch zusätzliche Pakete notwendig, die noch nachinstalliert werden müssen:

apt-get install psmisc build-essential

Vorbereitend zur Installation des VMware-Servers wird das Verzeichnis /data/VMs erstellt, in dem später die virtuellen Maschinen gespeichert werden sollen.

Der VMware-Server befindet sich bereits auf einer CD, die in das System gemounted wird. Das VMware-Server-Paket wird nach /tmp kopiert und dort entpackt.

cd /tmp
tar xvfz VMware-server-2.0.1-156745.x86_64.tar.gz

Nach dem Entpacken des Paketes wird der VMware-Server installiert.

cd VMware-server-2.0.1-156725.x86_64
./vmware-install.pl

Alle Abfragen, die das Installationsscript stellt, werden mit den Standardwerten beantwortet. Die Annahme der Lizenzvereinbarung wird mit der Eingabe „yes“ bestätigt. Bei der Abfrage nach dem Speicherort für die virtuellen Maschinen wird der Pfad /data/VMs angegeben.

Der Abschluss der Installation ist die Eingabe Seriennummer für den VMware-Server.

Nun können über die Weboberfläche des VMware-Servers (hier https://192.168.0.11:8333) die virtuellen Maschinen angelegt werden.

Fehlervermeidung und -behebung

Die  virtuellen Maschinen werden bei einem Ausfall des primären Servers automatisch auf dem Sekundärserver gestartet. Da vorher in der Regel kein Beenden der virtuellen Maschinen auf dem Primärsystem durchgeführt wurde, kann es dazu kommen, dass die Dateisysteme der virtuellen Maschinen inkonsistent werden. Nach Möglichkeit sollten deshalb so bald wie möglich die virtuellen Maschinen neu gestartet werden, um Inkonsistenzen durch Checkdisk zu beheben.

Sollte die Verbindung zwischen beiden Systemen unterbrochen werden, starten sich die virtuellen Maschinen auf dem Sekundärsystem automatisch, wodurch jeder virtuelle Server nun zweimal im Netzwerk vorhanden ist. In diesem Fall müssen die virtuellen Maschinen auf dem Sekundärsystem manuell wieder heruntergefahren werden. Abhilfe kann hier die Implementierung von STONITH (Shoot the other node in the head) schaffen.

Um weitere Probleme zu vermeiden, sollte man, wenn nötig, immer zuerst das Sekundärsystem herunter fahren und danach das Primärsystem. Bei der Startreihenfolge ist die umgekehrte Reihenfolge zu beachten. Zuerst sollte das Primärsystem gestartet werden, danach erst das Sekundärsystem.

Präsentation

Unter folgendem Link steht die Präsentation des Projektes im PowerPoint 2007 Format zur Verfügung: Präsentation Redundante Servervirtualisierung

Software-Stream.de: Gefälschter Firefox manipuliert Computer

Vor einigen Tagen wurde dem Verbraucherschutzverein Antispam e.V. ein Link zugespielt, der ganz neue Ausmaße der kriminellen Energien von Abzockern aufzeigt. Unter dem URL der-firefox-3.de, der zu dem Abzocknetzwerk der Firma „ontheRoad Networx“ aus Rostock gehört, befindet sich ein angeblicher Download des Firefox 3.1. Lädt man diese Setup-Datei jedoch herunter und versucht damit, den Firefox zu installieren, werden persönliche Daten abgefragt, die später zu Rechnungs- und Mahnungszusendungen verwendet werden sollen. Um Geschädigte davon abzuhalten, sich im Internet über diese Abzocke zu informieren, manipuliert diese Setup-Datei die in Windows-Systemen zur Auflösung von URLs eingesetzte hosts-Datei und „erdet“ die Domains etlicher Verbraucherschutzseiten auf den lokalen PC, so dass diese unerreichbar werden.

Die hosts-Datei befindet sich im Windows-Systemverzeichnis. Also bspw. C:\Windows\System32\drivers\etc\hosts (sie hat keine Dateiendung). Vorbeugender Schutz gegen solche Manipulationen kann das Setzen eines Schreibschutzes auf die hosts-Datei sein. Von dem oben genannten Szenario sind Windows 95/98/ME und XP Systeme betroffen. Ebenfalls ist zu erwarten, dass auch Windows Server 2003 anfällig ist. Unter Windows 2000 führt der Versuch, die hosts-Datei zu manipulieren, in der Regel zu einem Absturz des schädlichen Programmes aufgrund eines Programmierfehlers. Unter Windows-Vista funktionierte das Manipulieren der hosts-Datei, nach bisherigen Erkenntnissen, auch nicht.

Um die hosts-Datei zu reinigen, genügt es, den Windows-internen Texteditor (mit Administratorrechten) zu starten und die schlechten Einträge heraus zu löschen. Dazu geht man wie folgt vor. Klicke auf „Start“ -> „Ausführen“ und gibt ein:

notepad „%windir%\system32\drivers\etc\hosts“

Nach einigen mit dem Raute-Symbol (#) angeführten Kommentaren sollte dort die Zeile 127.0.0.1 localhost stehen. Alle übrigen Einträge, die mit 127.0.0.1 beginnen und worauf eine Domain einer „gutartigen“ Seite folgt (bspw. antispam.de, computerbetrug.de, protecus.de) sollten gelöscht werden. Anschließend speichert man die Datei und die Manipulationen sind wieder gelöscht.

Der Anbieter dieser Setup-Datei, die nach Eingabe der persönlichen Daten und Manipulation der hosts-Datei vom Originalserver herunter lädt, um das Originalprogramm zu installieren, stellt auf seiner Seite software-stream.de noch weitere OpenSource-Software und Shareware bzw. frei verfügbare Demo-Versionen zur Verfügung. Bei manchen Dateien ist das vorherige Anmelden direkt auf der Webseite notwendig, bei anderen wird auch das Prinzip des oben genannten „Installers“ genutzt.

Mein Rat an dieser Stelle ist es, sich solche Software nur von den Original-Quellen (also direkt beim Hersteller und bei den vom Hersteller verlinkten Quellen) herunter zu laden. Ein weiterer Rat, der sich auch mit dem Rat der Verbraucherschutzvereine deckt, ist es, Rechnungen von Abzockern nicht zu bezahlen, so lang man beim angeblichen Vertragsschluss nicht hinreichend über die Modalitäten hingewiesen wurde (bspw. Kosten versteckt auf der Seite angebracht oder in den AGB versteckt).

Die Verbraucherschutzvereine Antispam.de und Computerbetrug.de haben eine gemeinsame Presseerklärung zum Thema veröffentlicht.