Archiv » September, 2011 «

30 | 09 | 2011

vSphere Storage Appliance (VSA) – in aller Kürze

Geschrieben von um 15:26 Uhr

Mit dem Erscheinen von vSphere 5 ist nun auch der Versuch von VMWare erhältlich, produktionsfähige Installationen ohne Shared Storage zu ermöglichen – die vSphere Storage Appliance, oder VSA. Der Anspruch ist es, eine hochverfügbare Storage-Lösung für die Unterbringung virtueller Maschinen auf Grundlage des in den Hosts verbauten internen Festplattenspeichers zu schaffen. Die offizielle Resource von VMWare ist hier: http://www.vmware.com/products/datacenter-virtualization/vsphere/vsphere-storage-appliance/overview.html

Was wird benötigt?

Man braucht wahlweise zwei oder drei ESXi5-Hosts, die folgenden Anforderungen entsprechen:

  • CPU: Die VSA verbraucht kaum CPU, d.h. man muß vom Bedarf der später auf der Infrastruktur zu hostenden VMs ausgehen. Die Hosts werden jedoch zwangsläufig in einem Cluster zusammengefaßt, daher sollten die CPUs möglichst identisch sein, um EVC nicht zu bemühen
  • RAM: Auch hier gilt: Die VSA selbst ist nicht besonders hungrig. Dennoch nimmt sie vRAM auf jedem Host in Anspruch, und dieser kostet bei vSphere 5 nun mal Geld.
  • Storage: Jeder Host muß über einen fertig eingerichteten Datastore verfügen, und zwar über genau einen. Die offizielle Systemvoraussetzung lautet außerdem, daß sich dieser Datastore auf einem RAID10 mit mindestens 8 Platten befinden muß, dies wird aber nicht überprüft (wie auch). Die RAID-Einrichtung der Hosts ist auch gleichzeitig die einzige Sicherung gegenüber Ausfall einzelner Festplatten in diesem Konzept. Wichtig – Bei der Installation wird angedroht, die auf den Datastores befindlichen Daten zu löschen. In der jetzt ausgelieferten Fassung geschieht dies dann zwar doch nicht, man sollte sich aber nicht darauf verlassen! Die Datastores müssen übrigens nicht zwangsläufig gleich groß sein. Sind sie jedoch unterschiedlich groß, wird Speicherplatz verschenkt (s.u.)
  • Network: Jeder Host benötigt 4 Netzwerkkarten. Alle müssen angeschlossen sein. Wichtig – Alle NICs an allen Hosts müssen zum Zeitpunkt der Installation untereinander und mit dem vCenter kommunizieren können, denn der VSA Cluster Installer wird sie nach eigenem Gutdünken teamen und auf Back Edn und Front End verteilen. Wenn man sie später durch physisch separate Switche oder portbasierte VLANs isolieren möchte, kann man das freilich tun. Es darf nur die Standard-Netzwerkeinrichtung vorgenommen worden sein – alle Änderungen zum Default-Networking führen zum Abbruch der Installation. VMWare spricht hier von einem „Greenfield-Host“.
  • VMs: Es dürfen keine VMs auf den Hosts registriert sein.

Außerdem braucht man einen fertig eingerichteten vCenter 5 Server. Dieser muß unter Windows laufen (der VSA Cluster Manager ist ein Windows-Dienst!) und darf zum Zeitpunkt der Installation des Storage-Clusters nicht auf der Cluster-Infrastruktur virtualisiert sein. Also entweder eine physische Maschine oder eine VM, dann aber auf einem vierten Host virtualisiert. Später kann der vCenter Server durchaus auf den VSA Cluster verschoben werden. Die zukünftigen Cluster-Hosts sollten idealerweise bereits in das vCenter eingebunden sein, dies ist jedoch lt. VMWare nicht Bedingung (diese Konstellation habe ich nicht getestet).

Was bekommt man am Ende?

Nach der Installation des VSA bekommt man einen fertig konfigurierten HA Cluster, der die obigen Hosts umfaßt. Auf jedem Host läuft eine VSA-Instanz als VM. Jede VSA-Instanz exportiert einen NFS-Datastore, welcher auf allen Hosts im Cluster schon gemountet ist, und hostet außerdem eine Replica von dem anderen (oder einem der beiden anderen) Datastores.

  • Die exportierten NFS-Datastores sind gleich groß, und zwar genau halb so groß wie der kleinste lokale Datastore auf den Hosts.
  • Weitere Hosts, die nicht Bestandteil des Clusters sind, dürfen und können auf die NFS-Exports zugreifen, müssen dafür aber von derselben vCenter-Instanz wie der Cluster verwaltet werden. Dies hat ggfls. Auswirkungen auf die Lizenzierung, s. weiter unten.

Was kostet das Ganze? (Preisangaben natürlich ohne jegliche Gewähr und nur Listenpreise!)

Es kommt darauf an. Klar ist, daß die kleinste Lizenz, die diese Einrichtung überhaupt zuläßt, eine Essentials Plus ist. VMWare hat die beiden Produkte im Bundle für knapp 7.500 €, was für das, was man kriegt, ja ziemlich günstig ist. Einzeln kostet das Add-On knapp 6.000 – 9.000 €, je nach gebuchtem Support-Level, unabhängig von der zugrunde liegenden vSphere- und vCenter-Lizenz. Bei der Essentials Plus-Einrichtung mit drei Hosts darf na kein weiterer Host auf die VSA zugreifen (s.o.).

 

Mein Fazit: Auf jeden Fall interessant. Nächste Woche schreibe ich ausführlich über die Installation und den Betrieb der Lösung, zumindest hier im Labor.

Tags » , , , , «

+

29 | 09 | 2011

Meine erste Zertifizierung :-)

Geschrieben von um 19:16 Uhr

Ich habe meine erste Industrie-Zertifizierung erworben: Den Microsoft MCTS: Configuring Windows Server 2008 Active Directory (70-640).

Nächstes Examen: 70-642 Network Infrastructure…

Tags » , , , , , «

+

27 | 09 | 2011

Kerio Connect auf MacOS X – Backup mit Hindernissen

Geschrieben von um 21:37 Uhr

Man sollte meinen, das wäre die einfachste Aufgabe der Welt: Die Daten eines Kerio Connect (früher als Kerio Mail Server bekannt, nach eigenen Angaben bester Mailserver wo gibt 🙂 ) zeitgesteuert und unbeaufsichtigt auf einen externen Storage sichern. Richtig? Leider nicht ganz. Das Problem? Der Mailserver und damit auch das Backup läuft im Systemkontext, also quasi als Root. Aber eins nach dem anderen:

1. Backup des Kerio in Reinform

Man sollte meinen, es ist alles da: Man kann wählen, an welchem Tag und um welche Uhrzeit ein vollständiges Backup stattfindet, wann ein differenzielles, wo die Backups gespeichert werden, wer per e-Mail benachrichtigt wird usw. Unter „Erweitert“ kann man sogar angeben, wieviele vollständige Backups aufgehoben werden sollen und wie groß die „chunks“ sein sollen, in die die Backup-Datei aufgeteilt wird. Als Resultat legt Kerio im angegebenen Pfad ZIP-Dateien im Format [F|I]YYYYMMDDTHHMMSS.NN.zip an, wo die Datum- und Uhrzeitangabe dem Beginn der Sicherung entsprechen, ein F für „Full“ und ein I für „Incremental“ steht.

2. Enter external storage

Nun habe ich aber natürlich nicht auf fest verbaute Datenträger, sondern auf externen Storage sichern wollen – in diesem Fall eine Thecus 5200, die eine Vielzahl von Protokollen beherrscht, unter anderem auch AFP, SMB und FTP. Also: eine Share eingehängt, den Backup-Pfad bei Kerio geändert, eine Testsicherung laufen lassen – alles war gut. Bis eines Nachts durch eine Stromschwankung die Netzwerkverbindung zwischen dem Kerio-Server und dem Storage abbrach – kurz zwar, aber da es während der Sicherung war, genügte es, damit das Volume ausgehängt wurde.

Man sollte vielleicht meinen – eine Negativmeldung an die eingestellte e-Mail-Adresse? Weit gefehlt. Sowohl das fragliche Backup als auch die folgenden liefen glatt durch. Bis eines Tages der Server schrie, die Systemplatte sei voll. Ich schrieb ja schon, Kerio läuft als Root. Nun, was macht ein Root, wenn er die Datei /Volumes/Thecus/kerio.bak/I*****.ZIP anlegen will, das Volume „Thecus“ aber nicht da ist? Richtig, er legt einfach unter /Volumes wo er ja ein Schreibrecht hat, einen neuen Ordner namens Thecus an und schreibt los. Dieser Ordner liegt dann aber natürlich auf der Systempartition.

Somit scheidet ein direktes Backup auf einen externen Storage leider aus, wenn das Ganze einigermaßen unbeaufsichtigt laufen soll.

3. Backup auf Umwegen

Ich hatte noch Platz auf einem FireWire-Laufwerk (das ist das RAID5-Volume, das man oben auf dem Screenshot sieht). Da sich die Einbindung des NAS-Volumes als „too flaky“ für ein unbeaufsichtigtes nächtliches Backup herausstellte, beschloss ich, ein robusteres Protokoll zwischen Mailserver und NAS zu benutzen, nämlich FTP. Es gibt eine Fülle von Backup-Programmen für den Mac, die FTP als Ziel unterstützen, die Wahl fiel auf Bonkey. Die Einrichtung war Bonkey-typisch unkompliziert, doch gleich bei der Testsicherung zeigten sich Fehlermeldungen wie

Error: F2011xxxxxxxxxxxxxx.ZIP access denied

. Ein kurzer Blick auf die Zugriffsrechte der vom Kerio Backup angelegten ZIP-Dateien verriet auch sofort die Ursache:

mail: ~admin$ cd /Volumes/RAID5/keriobackup
mail:keriobackup ~admin$ ls -l
-rw-------  1 root staff 1062352453 Sep 27 01:11 F...Z.zip

Oha! Das sind ja nicht wirklich viele Rechte! Das hat man also davon, auf ein lokales Volume zu sichern. Nun ja, im Zweifel besser als 777, dennoch muß eine Lösung her. Und da es mir, wie jedem anderen Admin auch, widerstrebt, ein interaktives Backup-Programm (was dazu noch in Java geschrieben ist) ständig als Root laufen zu lassen, müssen die Zugriffsrechte auf den Dateien nach deren Erstellung angepaßt werden. Leider läßt das Kerio Backup die Funktion „Skript nach Sicherung ausführen“ vermissen (Kerio! Hört ihr mich? Diese Ergänzung ist dringendst nötig!!!), so daß man das mit anderen Mitteln regeln muß.

4. Zugriffsrecht, chmod dich!

Da, wie wir gesehen haben, nur der Root überhaupt Zugriff auf die Files hat, muß der entsprechende chmod-Befehl als Root laufen. Da ich einen relativ guten Überblick darüber hatte, wie lange die Backups brauchen, beschloß ich, auf die zusätzliche Komplexität der Üerwachung des Ordners auf neue Dateien hin zu verzichten und den entsprechenden Befehl einfach als zeitgesteuerten Task laufen zu lassen. Letzten Endes ist es ja nur wichtig, daß die Anpassung der Zugriffsrechte zwischen der Erstellung der Datei und dem Versuch, sie über FTP auf das NAS zu kopieren, geschieht – und da hat man buchstäblich den ganzen Tag Zeit.

Jetzt wollen wir mal als Root arbeiten (um den Root-Benutzer zu aktivieren und dessen Kennwort zu setzen, s. hier: http://support.apple.com/kb/HT1528):

mail: ~admin$ su -l
Password:
mail: ~root#

Schnell kontrollieren, ob administrative Handlungen ohne interaktive Passwort-Abfrage durchgeführt werden können:

mail: ~root# visudo
# sudoers file
#
# This file MUST be edited with the 'visudo' command as root.
...
# User privilege specification
root    ALL=(ALL)    NOPASSWD=ALL

OK, alles in Ordnung, der Skript wird zeitgesteuert laufen können. Verlassen vi mit

:q
visudo:  sudoers file unchanged
mail: ~root# 

Nun zu der eigentlichen Zeitsteuerung. Das ganze läuft auf einem MacOS 10.5.8 Server ab, d.h. die cron-Funktionalität ist zwar in launchd eingebunden, die Tasks, die als Root laufen sollen, verwenden aber nach wie vor cron.  Schauen wir mal, ob bereits cron-Aufgaben für den Root definiert wurden:

mail: ~root# crontab -l
mail: ~root# 

Die crontab ist also leer, das erleichtert die Sache. Dann legen wir einfach eine neue Datei und lesen sie ein:

mail: ~root# crontab -e

In die nun geöffnete leere Datei fügen wir dann

0   12   *   *   *   sudo chmod 755 /Volumes/RAID5/keriobackup/*.*

(was soviel bedeutet wie: setze jeden Tag um 12:00 die Zugriffsrechte für alle Dateien in dem Backup-Ordner auf 755) und bestätigen mit

:wq

wonach es nur noch übrig bleibt zu kontrollieren, ob cron bereits läuft:

mail: ~root# ps -A | grep cron
91982    ??   0:02.40  cron
mail: ~root#

und falls nicht, einmal den daemon mit

mail: ~root# cron

zu starten. Beim nächsten Systemstart prüft launchd, ob eine crontab vorhanden ist, und ruft dann den cron-daemon automatisch auf.

Das war’s!

Tags » , , , , , «

+

13 | 09 | 2011

Hallo Welt!

Geschrieben von um 15:37 Uhr

Hallo und Willkommen!

Mein Name ist Evgenij Smirnov, ich bin ein IT Professional aus Berlin und fange diesen Blog anläßlich der wohl größten Veränderung in meinem Berufsleben an: Nach 15 Jahren Selbständigeit bin ich zu einem größeren Team gestoßen und fange im Oktober meinen neuen Job as IT-Consultant bei der CEMA Berlin.

Dies aber wiederum begründet die Notwendigkeit, mir endlich auch private Dinge anzuschaffen, die für einen ‚digital native‘ unentbehrlich sind: Private e-Mail-Adresse, ein privates Handy… und eben einen privaten Blog. Hier ist er. Enjoy!

Tags » , «

+