Da ich einen Hang zu HA-Lösungen habe, spiele ich gerne und oft mit Clustern . Dabei ist mir herzlich egal ob es sich dabei um Windows oder Linux Maschinen handelt. Wenn man nun nicht genug Hardware hat um ein Cluster aufzubauen, der kann auch mit VMware ein HA-Cluster aufbauen. Alles was dazu notwendig ist bringt VMware mit. Das Problem mit dem shared Storage, kann man auf zwei Wegen umgehen:

• iSCSI Target in einer dritten VM, z.B. OpenFiler
• shared SCSI Bus mit VMware

Ich habe bisher immer einen OpenFiler in einer dritten VM laufen gehabt. Da man aber bei einem Windows Cluster auch ein Active Directory benötigt, musste man min. vier VMs laufen haben,. Um mir das zu sparen, habe ich mich hingesetzt und ein wenig mit dem shared SCSI Bus rumgespielt. Grundsätzlich bieten auch VMware Workstation und der VMware GSX die Möglichkeit, mit einem shared SCSI Bus zu arbeiten. Der Nachteil des shared SCSI Bus ist, dass nur max. zwei Nodes an einem Cluster beteiligt sein können. Das sollte aber zu Testzwecken mehr als ausreichend sein. Was brauchen wir denn nun?

1. Zwei VMware Gäste

Als Betriebssystem kommen nur Windows Server 2003 Enterprise / Data Center Edition oder Windows 2000 Advanced Server / Data Center Edition in Frage. Windows Server 2008 lasse ich hier erstmal Außen vor. Grundsätzlichen müssen die Installationen identisch sein. Daher ist es am einfachsten, erst eine Maschine aufzusetzen, und diese dann zu kopieren. Natürlich darf man nicht vergessen die MAC Adressen, die IP-Adressen, den Namen und die SID der Maschine zu ändern. Das sollte natürlich auch vor dem Betritt zur Domäne gemacht werden. Die SID lässt sich über newsid aus der Sysinternals Suite ändern. Hat man die erste Maschine fertig, so kann man diese herunterfahren und aus dem Inventory entfernen.

2. Shared Storage

Jetzt kommt der interessante Teil. Wir legen nun in dem Ordner, in dem unsere Gäste liegen, einen Ordner für die Clusterdisks an. Meine Clusterknoten heißen z.B. tst-cl01 und tst-cl02. Daher lege ich noch einen Ordner tst-cl-disks an. Mit dem Programm vmware-vdiskmanager muss man nun min. zwei VDMK Files anlegen. Ein ca. 1 GB großes VMDK für das Qorum, und eine Platte für die Daten. Das ist Minimalausstattung. Ich lege meist noch eine dritte Disk an. Nun muss das VMX File ,des gerade erstellen VMware Gastes, angepasst werden. Dazu kann man per Copy 'n Paste den folgenden Teil dort einfügen.

# Shared Storage

disk.locking = "FALSE" 

scsi1.present = "TRUE"

scsi1.sharedbus = "virtual"

scsi1.virtualDev = "lsilogic"

scsi1:0.present = "TRUE"

scsi1:0.fileName = "C:\Virtual Machines\tst-cl-disks\clusterdisk0.vmdk"

scsi1:0.mode = "independent-persistent"

scsi1:0.shared = "TRUE"

scsi1:0.redo = ""

scsi1:1.present = "TRUE"

scsi1:1.fileName = "C:\Virtual Machines\tst-cl-disks\clusterdisk1.vmdk"

scsi1:1.mode = "independent-persistent"

scsi1:1.shared = "TRUE"

scsi1:1.redo = ""

scsi1:2.present = "TRUE"

scsi1:2.fileName = "C:\Virtual Machines\tst-cl-disks\clusterdisk2.vmdk"

scsi1:2.mode = "independent-persistent"

scsi1:2.shared = "TRUE"

scsi1:2.redo = ""

Wenn man den VMware Gast nun wieder in das Inventory importiert, tauchen auch gleich die drei neuen Platten auf. Man kann jetzt den Gast kopieren und daraus den zweiten Gast erstellen.

3. Clustersetup

Es gibt jetzt zwei Nodes, die gemeinsam auf eine Reihe von VMDK Files gleichzeitig zugreifen könnten. Das ist natürlich nicht gut. Konkurrierender Zugriff auf NTFS Dateisysteme gibt nicht nur Datenmüll, sondern auch Ärger mit dem Chef. Also was tun? Erstmal wird der erste Node hochgefahren. Dann kann man mit der Einrichtung der Platten beginnen. Auf jeden Fall darf man die Datenträger NICHT in dynamische Datenträger umwandeln. Sobald man die Datenträger formatiert hat, sollte man ihnen sinnvolle Namen geben. Die 1 GB große Platten wird das Quorum. Daher bietet sich auch hier der Name Quorum an. Laufwerksbuchstaben kann man sich aussuchen. Sobald das geschehen ist, muss die Maschine heruntergefahren werden. Dann kann man die zweite Maschine starten, und dort nachsehen, ob die Platten verfügbar sind. Der zweite Node sollte das Dateisystem und die Namen der Platten erkennen. Wichtig ist es, die gleichen Laufwerksbuchstaben zu vergeben und den Zugriff zu testen. Ist das okay, kann der zweite Node wieder heruntergefahren werden. Nach dem erneuten Start des ersten Nodes kann die Cluster MMC geöffnet, und ein neues Cluster erstellt werden. Jetzt kann der zweite Node gestartet, und dieser dann dem Cluster hinzugefügt werden. Details zum Clustersetup findet man bei Microsoft in der Technet, oder auch über Google. Für Testzwecke reicht diese Form eines Clusters. Ich habe damit erfolgreich Exchange oder auch MS SQL hochverfügbar gemacht, zumindest solange mein Notebook lief. ;)

Bis zu dem Zeitpunkt als SQL2005 Express offiziell durch VMware supported wurde, war es üblich einen SQL Server oder eine Oracel Datenbank als Datenbank für das VMware Virtual Center zu nutzen. So sieht es auch bei meinen Kunden aus. Nun habe ich aber die ersten Fälle, wo ich die Datenbank von einem SQL2000 Server in eine MS SQL 2005 Express umziehen möchte.

Quelle:

• Windows Server 2003 Standard
• Virtual Center Datenbank in einer MS SQL 2000
• Virtual Center 2.0.x

Ziel:

• Windows Server 2003 Standard
• Virtual Center Datenbank in einer lokalen MS2005 Express
• Virtual center 2.5 Update 1

Als erstes greift man sich die LDF und die MDF Datei der alten Datenbank vom SQL Server und kopiert diese auf den neuen Server. Die Dateien müssen unter C:\Programme\MS SQL Server\MSSQL.1\MSSQL\Data abgelegt werden. Zudem müssen die Rechte an den Dateien müssen angepasst werden: Der Gruppe "SQLServer2005MSSQLUser$SERVERNAME$SQLEXPRESS" muss noch das Recht "Ändern" für die beiden Dateien gegeben werden. Anschließend sollte man Virtual Center komplett deinstallieren und die Maschine neu starten.

Im nächsten Schritt muss man sich eine MS SQL 2005 Express besorgen Das geht am einfachsten bei Microsoft. Wenn man schon mal dabei ist, kann man sich auch gleich das .NET Framework 2.0 herunterladen. Das braucht man in jedem Fall. Das war aber noch nicht alles: Das SQL Server Management Studio Express braucht man auch noch. Wenn man das alles heruntergeladen hat, kann man alles installieren.

1. .NET Framework
2. MS SQL 2005 Express
3. SQL Server Management Studio

Nach einem Neustart hat man alles was man braucht. Jetzt startet man die SQL Server-Oberflächenkonfiguration aus dem Startmenü und sorgt dafür das der SQL2005 auch Remoteverbindungen annimmt. Zudem sollte der SQL Server-Browser laufen und auch automatisch gestartet werden. Nun muss im SQL Server Management Studio ein Benutzer für die Verbindung zur Virtual Center Datenbank angelegt werden. Hier gelten die gleichen Vorgaben wie bei einer Neuinstallation des VC: Benutzer, SQL Anmeldung, Kennwort, Rollen usw.. Wenn man schon mal dabei ist, kann man auch gleich die Datenbanken anhängen: Rechtsklick auf "Datenbanken" und aus dem Kontextmenü "Anhängen..." wählen. Wenn man tut, was einem dort gesagt wird, hat man nach wenigen Sekunden die alte Datenbank im neuen MS SQL 2005 Server.

Der nächste Schritt wäre das Erstellen eines System-DSN. Auch das geschieht analog zu einer frischen VC Installation, nur das man hier "SQL Native Client" wählen muss. Der Rest bleibt gleich. Wenn man nun Virtual Center neu installiert, dann wird man gefragt, ob die gefundene Datenbank aktualisiert werden soll. Hier auf jeden Fall zustimmen. Das Schema der Datenbank hat sich in der Zwischenzeit geändert und muss angepasst werden. Dabei wird man aber von einem Assistenten zu einem späteren Installationszeitpunkt unterstützt.

Das sollte es gewesen sein, ein kurzer Abriss zum Thema "Wie nagel ich eine MS SQL 2000 Datenbank von einem Cluster in eine MS SQL 2005 Express". Wie immer ohne Garantie das es bei euch funktioniert. :)

blazilla.de wird betrieben mit freundlicher Unterstützung von Debian Linux und lighttpd. Da ich mich immer wieder über die grafische Darstellung von irgendwelchen nutzlosen Daten freue, habe ich mit dem im Lieferumfang von lighty enthaltenen mod_rrdtool rumgespielt. Hier das quick `n dirty Howto:

1. mod_rrdtool in der /etc/lighttpd/lighttpd.conf einkommentieren.

server.modules = (

"mod_access",

"mod_alias",

"mod_accesslog",

"mod_status",

"mod_compress",

"mod_rrdtool",

)

2. Pfad zur rrdtool Binary und zur DB in der lighttpd.conf setzen.

#### rrdtool

rrdtool.binary = "/usr/bin/rrdtool"

rrdtool.db-name = "/var/www/blazilla.de/rrd/lighttpd.rrd"

3. Alias dafür setzen.

# Lighttpd Performance Monitoring

$HTTP["remoteip"] == "xxx.xxx.xxx.xxx/24" {

        alias.url += (

                "/xxx/" => "/var/www/blazilla.de/xxx/",

        )

}

4. Crontab Eintrag für rrdtool.sh machen. rrdtool.sh baut die Grafiken aus der rrd DB.

0,20,40     nice -n 10 /etc/lighttpd/rrdtool.sh >& /dev/null

Das rrdtool.sh und das index.html gibt es hier zum herunterladen.

Die Doku zum mod_rrdtool gibt es hier. Sofern man alles richtig gemacht hat, sollte man nach ein paar Minuten eine hübsche Seite mit ein paar Grafiken erhalten. Zu sehen gibt es dann die eingegangenen und ausgegangenen Bytes und die Anzahl der Request. Jeweils über ein paar Stunden, den Tag und über ein paar Wochen verteilt. Viel Spaß damit.

Oft bekomme ich bei MS Clustern, die nicht von mir aufgesetzt wurden, spontante Anfälle von Brech-Durchfall. Der IMHO am häufigsten gemachte Fehler ist die falsche Konfiguration der Clustergruppen. Viele missbrauchen die Cluster-Gruppe auch direkt für Ressourcen, wie z.B. Fileshares usw. Sehr geil sind dann auch Kombinationen, bei denen in einer zweiten Gruppe z.B. nur ein Fileshare und ein physikalischer Datenträger vorhanden sind. Die Gruppe an sich ist nicht lebensfähig, sofern sie auf einen anderen Node geschoben wird. Es kann doch nicht so schwer sein, oder?? Leute die keine Ahnung haben, sollten vor allem von Clustern, einfach mal die Finger lassen. Es kann so einfach sein:

Die Cluster-Gruppe enthält nur Ressourcen zur Verwaltung des Clusters, also Cluster-IP-Adresse, Clusternamen und Quorum.

Für alles andere baut man bitte schön eine neue Gruppe. Wenn man z.B. einen hochverfügbaren Fileserver hochziehen will, dann erstellt man eine zweite Gruppe und fügt dort als Ressourcen eine IP-Adresse hinzu, einen Namen, einen oder mehrer Datenträger, sowie eine oder mehrere Dateifreigaben. Freigaben sind von Datenträgern abhängig, Namen von IP-Adressen. Schon hat man eine lebensfähige Clustergruppe die man durch die Gegend schieben kann. :)

Wäre nur schön wenn das auch jeder machen würde.... Allen anderen empfele ich dringend die Lektüre der Microsoft TechNet.

Einen sehr interessanten Bericht, samt einem kurzem HowTo, zu HA-Clustern mit RHEL / CentOS gibt es hier zu lesen. Die Erkenntnis des Autors, dass HA-Cluster für manche Kunden etwas sind, was man besser nicht anfasst, kann ich verstehen. Ebenso kenne ich Kunden, die A/P HA-Cluster gerne mal durch die Weltgeschichte schwenken, einfach nur damit der passive Node mal was zu tun hat... kein Kommentar. An dieser Stelle sei auch noch mal auf meine Experimente mit HA-Clustern verwiesen, nachzulesen hier, hier und hier

Ich habe zwei sehr schöne HowTos zum Einsatz von mdadm unter Linux gefunden. Das erste HowTo beschäftigt sich mit dem nachträglichen Spiegeln von Partitionen. Manchmal baut man eine Maschine mit einer Platte auf und möchte später spiegeln. Das zweite HowTo zeigt sehr schön, wie man mdadm zum kopieren von Platten verwenden kann. Habe ich selber schon oft genug gemacht um Daten zwischen Storagesystemen zu spiegeln. :)

Wer mal mit mdadm spielen will, dem kann ich nur VMware Server ans Herz legen. Was würde ich nur ohne VMware machen? :)