SRM

Möchte man in einer SRM Umgebung mit EMC Clariion und MirrorView eine geplante SRM Umschaltung machen, ist einiges zu beachten.

Bei diesem Storage werden LUNs die gemeinsam umgeschaltet werden zu s.g. Consistency Groups zusammengefasst. Da liegt der Hund begraben! Bei einer geplanten Umschaltung mit zeitnaher Rückschaltung muss man ggf. beachten, dass nicht alle LUNs während der Umschaltung konsistent sind.

Hähh? Was soll das! - Zur Erklärung: Die Clariion kann die LUNs nur als valid bei der Umschaltung betrachten, wenn zum Zeitpunkt des Mirror Breaks auf keiner LUN der Consistency Group geschrieben wird. Sobald noch IOs auf die erfolgen, wird die entsprechende LUN dirty und muss vor dem Zurückschalten komplett neu aussynchronisiert werden.

Bei einer Consitency Group mit 10 oder mehr LUNs wird man es nie schaffen, dass alle LUNs ohne IO Operationen daher dümpeln. Leider hat die Clariion keine Möglichkeit IOs auf LUNs zu unterbinden. Da ich von Anwendern ab und zu gefragt werde - Warum finden IOs statt, obwohl doch alle VMs angehalten sind? Ganz einfach, es gibt auch vom ESX Host ohne “Zutun” genügend IOs. Das sind z.B. (Ergänzungen willkommen…)

1. VMFS Metadaten Heartbeat - IOs im Intervall durch einen ESX Host, wenn er auf irgend etwas einen Lock gesetzt hat. Durch diesen Intervall wird sichergestellt, dass die anderen Hosts wissen, dass der Lock noch da ist und -viel wichtiger - das dieser Lock automatisch frei wird, sollte der blockierende Host ausfallen
2. VMware HA - bei ESXi 5 werden auch Datastores für den HA Hearbeat genutzt.
3. Virtual Distributed Switch Info - Damit ein ESX Host auch ohne vCenter weiss, welche VMs an welchen vDS Ports hängen und wie der vDS konfiguriert ist, werden diese Infos auf den Datastore redundant abgelegt.
4. Logdateien - Da die scratch Partition bei ESXi nicht besonders groß ist und Logfiles sehr schnell rotieren gibt es die Möglichkeit die Logdateien in einen VMFS Datastore zu legen.
5. Storage IO Control Metriken - hat man Storage IO Control eingeschaltet, werden von jedem Host auf den Datastores Metriken zum Lastverhalten abgelegt.
6. eigene Scripte - gut, nicht von ESX selber, aber in vielen Umgebungen laufen irgendwelche Scripte, die z.B. Snapshot Infos direkt vom VMFS holen. Die werden gern bei der Suche nach “IO Verursachern” vergessen.

Es gibt also jede Menge Quellen von IOs! Wichtig ist nur, dass bei geplanten Umschaltungen mit zeitnahen Rückschaltterminen darauf geachtet werden muss, dass im ungünstigsten Fall erst einmal alle LUNs neu aussynchronisiert werden müssen. D.h. evtl. mehrere Tage synchronisieren, es sei denn, man kann das Synchronisieren hoch priorisieren.

Wenn man eine SRM Umgebung mit NetApp aufbaut, gibt es auch einige Dinge zu beachten. Falls bei der Konfiguration der Arrays ein Fehler auftritt, der besagt, dass die NetApp nicht gefunden wird, und im Log die Meldung

…in Zapi::invoke, cannot connect to socket

auftaucht, kann es sein, dass über http die ZApi nicht ansprechbar ist. (Besonders in Umgebungen mit ONTAP 8.1.x und höher, wo nur noch onCommand zum Einsatz kommt)

Abhilfe schafft einfach

options httpd.admin.enable on

Die SRM Log Dateien findet man unter C:\ProgramData\VMware\VMware vCenter Site Recovery Manager\Logs

Nutzt man SRM zusammen mit der vSphere Replication gibt es einige Punkte zu beachten.

Wichtig ist vor allem konsequent überall FQDN Namen zu verwenden. Wir die Replikation Manager Appliance konfiguriert, muss unbedingt bei der Angabe des vCenters von der Default eingetragenen vCenter IP auf vCenter FQDN umgestellt werden.

Dazu gibt es auch den KB Artikel 2007463.

Eine gute Kurzanleitung findet man unter http://fvandonk.wordpress.com/2011/11/10/srm-5-vsphere-replication-how-to-install-and-configure/