Evgenij Smirnov – IT Pro aus Berlin …because IT matters :)

Datenbankserver db2 läuft wieder. Grund der Störung war ein lockres Patchkabel, weshalb keine Netzwerkverbindung mehr bestand.

Die Entstörungsdauer betrug 22 Minuten (!).

Wenn man die Exchange 2007 oder 2010 Management-Konsole auf einem Rechner, wo auch Internet Explorer 9 installiert ist, öffnete, auf den Knoten „Organisationskonfiguration -> Mailbox“ ging und dann versuchte, die Konsole zu schließen, bekam man die folgende Fehlermeldung:

Dies ist nun gelöst, siehe Exchange Team-Blog:

http://blogs.technet.com/b/exchange/archive/2011/10/17/a-fix-for-the-interoperability-issues-between-exchange-2007-and-2010-emc-and-ie9-is-now-available.aspx

Der Hotfix kann hier angefordert werden:

http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2624899

Nach einer Migration von Exchange 2003 auf Exchange 2010 SP1 wird in regelmäßigen Abständen (und jedes Mal, wenn man einen PS-Befehl absetzt) die folgende Warnuing mit der Ereignis-ID 2937 und Quelle MSExchange ADAccess protokolliert:

Im Internet finden sich Hinweise auf das Update-Recipient Cmdlet, welches aber natürlich gezielt angewandt werden muß, da es auch alle Empfängerrichtlinien neu anwendet. Leider ist es nicht so einfach wie bei einem aktiven User, wo man einfach

Update-Recipient -Identity "<username>"

schreiben würde – der Empfänger wird nicht gefunden. Abhilfe schafft hingegen folgende Syntax:

Get-Mailbox -Arbitration | Where {$_.Name -like "SystemMailbox{*" } | Update-Recipient

Wer keine Angst vor ADSIEdit hat, kann freilich den Inhalt des homeMTA-Atributs von einer aktiven Mailbox in die entsprechende System-Mailbox kopieren, aber der Weg über Update-Recipient ist natürlich sicherer.

Ich hatte ja schon über die grundlegenden Eckdaten der VSA geschrieben (hier). Seither sind einige Wochen vergangen, in denen ich anderes zu tun hatte, aber nun möchte ich den VSA-Thread endlich fortführen.

Heute wollen wir die Installation der VSA live ausprobieren. VMWare verspricht eine Installation in 15 Minuten, was durchaus zutreffen kann, wenn die Voraussetzungen (über welche ich in dem o.g. früheren Beitrag schon ausführlich schrieb) geschaffen wurden – was freilich gut und gerne eine Stunde in Anspruch nehmen kann.

Als erstes wird auf dem vCenter Server die Installations-CD eingelegt. Ohne größere Abfragen oder bunte Splash-Screens startet der Installationsvorgang, der übrigens gleich die über das Netzwerk erreichbare vSphere-Infrastruktur inventarisiert. Sie muß in diesem Augenblick noch nicht vollständig stehen, aber es erleichtert die Sache.

Danach ist im vSphere Client (im Datacenter-Knoten) ein neuer Tab verfügbar: VSA Manager. Dieser benötigt Flash, im Gegensatz zu den anderen Komponenten des vSphere Clients. Es ist noch keine aktive VSA konfiguriert, daher erscheint beim Aufruf des Plug-Ins die Aufforderung, eine zu installieren:

Wir wollen eine Neuinstallation riskieren und lassen die Auswahl daher bei „New Installation“. Es folgt ein kurzer Überblick darüber, was alles eingerichtet wird und warum es ganz toll ist:

Danach folgt die Auswahl und Untersuch des gewünschten Datacenters für den VSA Cluster. In dem „Essentials Plus + 3er VSA“ – Szenario, welches VMWare als DAS Einsatzszenario für die VSA anzusehen scheint, ist freilich nur ein Datacenter hier möglich. Implementiert man die VSA mit den „großen“ Produkten, können hier sicher auch weitere Datacenter erscheinen.

Hier sieht man die CPU-Kompatibilität der Hosts im zukünftigen Cluster. Bei diesen beiden handelt es sich um Maschinen unterschiedlicher Leistungsklassen – ein Athlon und ein Opteron, daher auch der recht bescheidene Grad an Übereinstimmung, wie man sieht:

Manchmal sind beim ersten Durchlauf ein oder mehrere Hosts im „Degraded“-Status. Einen Schritt zurück gehen und den Host rebooten hat ab und zu geholfen – immer unter der Annahme, daß die übrigen Voraussetzungen stimmen.

Nun wir das Netzwerk für den VSA-Cluster konfiguriert, sie muß im selben Subnetz liegen wie der VSA Cluster Manager-Rechner, in diesem Fall also der vCenter-Server.

Mit der Eingabe der beiden ersten IP-Adressen werden automatisch auch weitere Adressen auf die Hosts verteilt:

Das sieht dann so aus:

und für den zweiten Host:

Ein Wort der Warnung, was das Networking auf den Hosts angeht: Im Moment haben die Hosts noch ihre Management-Interfaces schön mit einer IP-Adresse versehen. Wenn es an die Konfiguration des Clusters geht, wird der Installer die Netzwerkschnittstellen neu mischen. Die Adressen bleiben zwar erhalten, es kann aber sein, daß sie plötzlich einer anderen Netzwerkkarte zugewiesen werden! Daher sollte die Kommunikation zwischen den 4 NICs in jedem Host und dem vCenter in diesem Augenblick noch „flach“ sein, d.h. jede Netzwerkkarte muß jede andere erreichen können. Später kann man sie dann trennen, sei es um den Traffic zu isolieren oder um Ausfallsicherheit gegenüber dem Defekt eines Switches zu erhöhen.

Nun die letzte Frage, bevor’s losgeht – jetzt oder später formatieren. Meine Erfahrung hier ist so:

• formatiert man gleich, dauert es lange
• formatiert man später, merkt man es gar nicht.

Daher rate ich, die Formatierung nicht als Teil der Installation vorzunehmen.

Jetzt noch mal die Konfiguration überprüfen…

…und schon wird einem der erschreckende Hinweis präsentiert, daß alle Daten gleich futsch sind:

Die Erfahrung zeigt, dem ist nicht so, jedenfalls nicht in diesem Release. Trotzdem ist es nicht gut, Daten im Datastore zu haben:

1. da VMWare das offensichtlich so vorgesehen hat, wird es vermutlich in einem der späteren Releases umgesetzt
2. eben weil die bestehenden Daten erhalten bleiben, reduzieren sie die Gesamtkapazität der VSA. Zur Erinnerung: alle von der VSA präsentierten Shares sind gleich groß, und zwar etwa halb so groß wie der kleinste verfügbare Platz auf einem der Hosts!

Nun aber wird tatsächlich installiert. Das sind die berühmten 15 Minuten:

… man sieht schon ein wenig vom Cluster:

… und die beiden Appliances (das wären bei 3 Hosts natürlich auch drei):

… nun ist der Cluster auch per TCP/IP zu erreichen:

… und fertig!

Jetzt zeigt der VSA Cluster Manager auch sinnvolle Daten zum Zustand des Clusters an:

Die VSA ist fertig und läuft. Herzlichen Glückwunsch!

Zwei Anmerkungen an dieser Stelle noch:

1.  obwohl der VSA Installer recht tiefgreifende Einstellungen am vCenter vornimmt, stellt er an den physischen Datastores der Hosts (die ja dann durch die VMDKSs der VSA-Appliances ja richtig voll sind!) die Alarmaktionen nicht ab, die dann auch immer anschlagen. Allerdings ist es bei der HP-Appliance und bei manch anderen, die ich gesehen habe, auch nicht anders
2. Will man die VSA wieder deinstallieren, so darf man nicht anfangen, den Cluster aufzulösen, die Appliance-VMs händisch zu entfernen usw. Dafür gibt es einen Skript, der mit der VSA zusammen installiert wird. Die Benutzung wird hier in der VMWare-KB beschrieben. In meinem Fall mußte im Unterschied zum KB-Artikel der Pfad zur Java-Umgebung manuell gesetzt werden (systemweite Umgebungsvariable).