VMware-Forum

moin, ich brauch mal eure Hilfe

Folgendes Szenario:
ESX4 an EMC Symmetrix mit gepiegelten LUNS.
Es gibt zwei Möglichkeiten die LUNs dem ESX Server zu präsentieren.

1.) Nur eine Seite des Storage ist sichtbar, der Mirror bleibt unsichtbar.
Der produktive Storage fällt aus, der Mirror wird aktiviert und dem ESX zugwiesen.
Im Storage wird ein Failover initiiert, die HBAs werden gescannt.
Erkennt der ESX Server die Volumes anhand der Daten und können die VMs ohne manuelle Konfig wieder gestartet werden? Oder "zeigen" alle vDisk Einträge in den vmx Files auf die "falschen" LUNs des anderen Storages?

2.) Beide Seiten sind aktiv, einer ist im RW Modus, der Spiegel ist ReadOnly.
Nach einem Failover werden die LUNs des Mirrors dem ESX zugewiesen.
Eigentlich klassisches Szenario für den SRM, der aber noch nicht für vSphere erhältlich ist.

Es geht hier um 120 VMs an sechs ESX Hosts.
Der Mirror soll einen Datenverlust im SAN Umfeld durch Ausfall eines Storages abfangen, ein unterbrechungsfreier Betrieb ist zwar nicht gewährleistet, aber 6 TB an VMS von Tapes zu holen dauert noch länger. Ein unterbrechungsfreier Betrieb könnte mit Storagevirtualisierung umgesetzt werden, steht hier aber leider nicht zur Diskussion.

Mein Problem ist, ich weiß nicht wie der ESX sich verhält, wenn die LUNs von einem anderen Storage kommen, der Inhalt bleibt aber erhalten. Ein manuelles umkonfigurieren von 120 VMs mit ca. 200 vDisk kommt eher nicht in Frage

Nur zur Info:
SRM 4.0 ist seit gestern draussen.

Gruss
Joerg

Ähm, sooo aufwändig ist es (auch ohne SRM) doch nicht.
Die Spiegel müssen den Hosts writeable präsentiert werden, die Hosts brauchen nen Rescan der HBAs und dann noch eben alle VMs starten.
Da ist nix mit umkonfigurieren von 120VMs oder dergleichen.
Die oben genannten Tasks lassen sich vor allem bei der Sym mit Hilfe von Scripts halbautomatisieren, sodass du fast nur noch die Scripts starten musst. Das Starten der VMs ist ja auch nur noch ein one-liner, also alles halb so wild.

ne so einfach ist das nicht, mit dem oneliner

Storage ist vom Dienstleister, ESX gehört mir. Mit ersterem habe ich nichts zu tun.
Wozu benötige ich denn dann den SRM, wenn ich keine VMs konfigurieren muss, also ein reiner Rescan ausreicht? Aber habe ich das also richtig verstanden? Für den ESX Server ist der Storage Failover völlig transparent (was die Konfigs angeht)?

Also folgende vorgehensweise:
1. Dienstleister: Storage Failover, der Mirror wird dem ESX präsentiert, im RW Modus (gescripted)
2. ICH: Rescan aller HBAs
3. ICH: Alle VMS neu starten
4. ICH: Beten dass nichts kaputt gegangen ist!

Ja doch, der Oneline geht schon, der ist ja wie gesagt nur um die VMs zu starten.
Jupp, im Prinzip läuft es so wie du beschrieben hast.
Der ESX erkennt die LUNs, da sie ja bloß mittels eines anderen Pfad präsentiert werden.
Nachteil des Ganzen ist, dass die Scripte ständig gepflegt werden müssen. Sobald auch bloß eine neue LUN hinzu kommt, musst du das im Script anpassen.

Der SRM macht das sogut wie alles für den User, zudem kann er noch Reihenfolgen beim Start der VMs berücksichtigen, damit kannst du einfacher testen und und und
....ABER eigentlich macht er grob gesehen nicht viel mehr als die beschriebenen Schritte.
Muss man halt gucken ob einem das so viel Geld wert ist, denn wirklich beschleunigen tut auch der SRM den Failover nicht. Also nicht denken damit geht's schneller oder ohne Ausfall....

ok danke, ihr habt mir Fragen beanwortet, die uns unser dienstleister bisher nicht beantworten konnte.

da der storage von ihm komplett betreut wird, muss er zusehen, die luns wieder zur verfügung zu stellen, er muss die SLAs einhalten , wobei emc die verfügbarkeit der symmetrix mit 99,999 angibt.

das scannen der hbas und starten der vms lässt sich in der tat sehr bequem z.B. per Powershell skripten, da mache ich mir keine sorgen. stimmt muss ich noch darüber nachdenken ob sich die geplante investition in den SRM noch lohnt.

Ich bin mir nicht sicher ob ihr ueber die gleiche Sache gesprochen habt .

Das Prinzip vom SRM beruht darauf das es einen zweite Ansammlung von ESX Host(s) gibt welche ihr eigenes Storage/Netzwerk usw. haben. Beide werden von einem eigenen vCenter gemanaged und koennen aus unterschiedlichen Komponenten bzw. Herstellern sein was die Hardware angeht.

Ueber Gruppen werden die zuschuetzenden VMs zusammengefasst und konfiguriert und erhalten so ihren eigenen Recovery Plan. Grob kann man sagen das als kleinster gemeinsammer Nenner immer ein LUN genommen werden muss.

Fuer jedes Element einer VM, welche Teil des Recovery Plans ist, muss ein Mapping erstellt werden in dem genau festgelegt wird welche Resource aus der Primary Side der einer aus der Secondary Site entspricht. Denn auf der Secondary Site werden die LUN und Networks ja ganz andere Namen haben.

Diese VMs werden dann als Schatten VMs auf der Recovery Site angelegt und die Daten vom Storage der Primary Site auf den der Secondary kopiert und syncronisiert. Die Intervalle lassen sich definieren.

So ein Recovery Plan laesst sich dann pruefen oder im Notfall dann auch Real aktivieren. Fuer ersteres lasses sich Reports genereieren.

Das ist meiner Meinung aber was anderes als redundante Pfade zu den LUNs. Je nach Anbieter gibts da ja ganz Unterschiedliche Loesungen fuer die Replikation (das koennen wohl relativ viele auch wenn es oft extra lizenziert werden muss) als auch fuer den transparenten Failover.

Von DataCore San Symphonie bis NetApp Metrocluster ein grosses Feld. Der Anbieter soll sich einfach mal Schlau machen was EMC da fuer seine Symmetrix so anbietet und wie man die ESX Hosts darauf einstellt bzw. was im Notfall den zutun ist.


Achja,
der Punkt mit dem "Beten" taucht bei jeder der Loesungen auf

Gruss
Joerg

ja das Thema hat es in sich,
redudantes Storage und Desaster Recovery gehören aber zusammen, genauso wie Backups.

Letztendlich baut man eine Umgebung auf, deren Verfügbarkeit über mehrere Schichten übereinander aufbaut.

Multipath ist im Storage ja nun angekommen, der Ausfall eines Controllers, eines HBAs oder eines Switches führt nicht zum Ausfall.

Aus Kostengründen wird aber davor gescheut auch im Storage eine Redundanz zu schaffen, Storage ist teuer, da ist man froh sich einen Einzelnen leisten zu können, an den zweiten gar nicht erst zu denken.

Hat man auch diese Hürde übersprungen - also den Datenverlust durch reinen Hardwareausfall - geht es mit der nächsten Stufe weiter, wie schnell ist ist einem solchen Fall das System wieder online oder noch besser, der Ausfall des ehemaligen SPOF führt überhaupt zu keiner Beeinträchtigung der Services.

Die nächste Stufe wäre dann die "globale" Sichtweise, verschiedene Rechenzentren z.B.

Meine Aussage vorhin "wozu brauche ich denn noch den SRM" war ein wenig vorschnell geschrieben, du hast es richtig bemerkt IRIX.

Der SRM macht wesentlich mehr als nur die HBAs zu scannen und die VMs wieder zu starten. Allein weil zum starten den Umgebung (nicht einzelner VMs) ja die Steuereinheit - das Virtual Center - benötigt wird, muss man diese erst ausfindig machen um dann die restlichen VMs wieder in Betrieb zu nehmen, die Reihenfolge ist wesentlich, z.B. erst die DCs, DNS, Server, DHCP und dann erst die Member Server, zuerst die DBs, dann die App Server usw.

Meines Wissens kann dies der SRM deutlich optimieren, und seien wir mal ehrlich, wenn eine komplette Umgebung mit einigen 100 Servern und 1000(den) von User im Nacken nicht läuft, hat kaum einer die Ruhe weg. Vor allem weil kaum einer den Ernstfall mehrmals und regelmäßig probt (Theorie und Praxis gehen leider auseinander).

Dadurch dass der SRM mit zwei aktiven Sites immer Verfübar sein sollte, nimmt das schon viel von der Spannung, wenn die Wiederaufnahme des Betriebes auch noch automatisiert (und geregelt) werden kann, dann ist das schon viel wert.

Also nehme ich meine saloppe Aussage zum SRM wieder zurück

meine ursprüngliche Frage:"was passiert beim Storage FAilover" habt ich zum Glück ja beantwortet, und ich kann mich - nach sehr ausführlichen Test - der nächsten Stufe widmen.

Hallo,

ich nehme mal an, das du mit gespiegeltem Storage die SRDF Funktionalität der Symmetrix meinst.
Da es sich bei dieser Replikation wie gewünscht um eine 1:1 Kopie einer LUN in der lokalen Symmetrix handelt, wird auch die Datastore Signatur auf die remote Symmetrix übertragen.
Die Symmetrixen unterstützen jedoch NAA, dadurch verwendet ESX zur Identifizierung eines Datastores die Device WWN.
Somit wird ein replizierter Datastore auf der zweiten Seite immer als Snapshot erkannt, sofern nicht SRM verwendet wird.
Das mußt du daher durch geeignete Maßnahmen in deinem K-Fall Scenario berücksichtigen.

Im Falle eines notwendigen SRDF Failover müssen die Storage Admins die Backup Seite aktivieren, das ist generell keine große Angelegenheit.
Allerdings wird auch bei den Kollegen im K-Fall einiges los sein, das sollte dir auch klar sein.

Ich empfehle dir übrigens das kostenlosen EMC Storage Viewer Plugin, damit erhälst du detailierte Informationen über den verwendeten EMC Storage.
Gerade in deinem Fall macht das Sinn, damit du im Gespräch mit den Storage Admins die notwendigen Information gleich verfügbar hast.

Falls du weitere Fragen hast .....

Viel Erfolg
Ralf

moin,
vielen Dank für deine Antwort.

kastlr hat geschrieben:Hallo,

ich nehme mal an, das du mit gespiegeltem Storage die SRDF Funktionalität der Symmetrix meinst.
Da es sich bei dieser Replikation wie gewünscht um eine 1:1 Kopie einer LUN in der lokalen Symmetrix handelt, wird auch die Datastore Signatur auf die remote Symmetrix übertragen.

so dachte ich es mir!

kastlr hat geschrieben:Die Symmetrixen unterstützen jedoch NAA, dadurch verwendet ESX zur Identifizierung eines Datastores die Device WWN.
Somit wird ein replizierter Datastore auf der zweiten Seite immer als Snapshot erkannt, sofern nicht SRM verwendet wird.
Das mußt du daher durch geeignete Maßnahmen in deinem K-Fall Scenario berücksichtigen.

jetzt verwirrst du mich: Der erste Fall ist wünschenswert, im zweiten Fall meinst ich müsse "geeignete Maßnahmen" treffen. Was meinst du konkret damit? Mir wäre es am liebsten wenn der ESX Server NICHT merkt, dass die Luns von einem anderen Storage kommen! Was muss ich tun um dies zu erreichen?

Der Einsatz von SRM ist zwar eingeplant, aber a) ist SRM 4.0 für vSphere erst seit zwei Tagen veröffentlicht, deshalb stand SRM nicht sofort zur Verfügung, und b) aus zeitlichen Gründen soll SRM erst später implementiert werden, ich will diese Zeit aber erstmal mit einem guten Gewissen überbrücken.

kastlr hat geschrieben:Im Falle eines notwendigen SRDF Failover müssen die Storage Admins die Backup Seite aktivieren, das ist generell keine große Angelegenheit.
Allerdings wird auch bei den Kollegen im K-Fall einiges los sein, das sollte dir auch klar sein.

Mir ist klar, dass dort etwas Trubel sein wird, aber ich sehe das ganz pragmatisch, der Dienstleister bietet seine Dienstleistung an und es werden SLAs definiert, diese muss er einhalten, ansonsten treten Pönalen in kraft. wie der Dienstleister seine SLAs einhält ist mir ziemlich egal
Ist eine trockene Sichtweise, aber da es nicht die von mir präferierte Lösung ist, muss ich das so sehen.

kastlr hat geschrieben:Ich empfehle dir übrigens das kostenlosen EMC Storage Viewer Plugin, damit erhälst du detailierte Informationen über den verwendeten EMC Storage.
Gerade in deinem Fall macht das Sinn, damit du im Gespräch mit den Storage Admins die notwendigen Information gleich verfügbar hast.

Die Kommunikation mit den Storage Leuten ist bisher sehr gut, haben uns auf eine gemainsame Sprachen einpendeln können. Leider sind die Storage Leute dort keine ESX Fachleute, das sind wieder andere, und von diesen bekomme ich keine genaue Auskuft, deshalb die Fragen hier.

kastlr hat geschrieben:Falls du weitere Fragen hast .....

Viel Erfolg
Ralf

ja habe ich, wäre froh wenn du sie (die obigen Fragen) auch noch beantworten könntest.

Hallo,

mit "geeigneten Maßnahmen" meine ich, das du die Wahl zwischen zwei Optionen hast, einmal das Mounten der Snapshot oder ein Resignature.

SRM verwendet Resignature, um die Informationen des "neuen" Arrays in die Datastores einzutragen.
Der Nachteil bei diesem Verfahren ist der Umstand, das nach der Störungsbehebung ein "Failback" auf das ursprüngliche Array erneut ein Resignature der Datastores erfordert.
Und aktuell gibt es noch keinen Automatismus in SRM, der alle notwendigen Aktionen durchführt.
Allerdings wird daran aktuell wohl intensiv gearbeitet.

ESX erfordert einige besondere Einstellungen auf der Symmetrix, diese müssen dann natürlich auch auf beiden Seiten vorhanden sein.
Für die ESX HBA's müssen folgende FA Flagsettings gesetzt werden.

♦ PP for FC-SW
♦ VCM if using Volume Logix
♦ UWN for Unique WWN
♦ SC3 for SCSI-3 interface
♦ C bit for common serial number when using native failover functionality.
♦ SPC-2 bit for presenting SPC-2 compliant EMC Symmetrix devices

Das EMC Storage Viewer Plugin zeigt dir übrigens an, welche FA Settings gesetzt sind.
Falls du W2K8 einsetzt, muß auf den entsprechenden Symmetrix Devices auch noch das PER Flag aktiviert sein, da der Cluster mit SCSI 3 persistent Reservierungen arbeitet.

Von EMC gibt es zum Thema ESX an Symmetrix ein nettes Dokument, das über Powerlink bereitgestellt wird.
Da es 25MB groß ist, hier nur der Link.
TechBook: Using EMC Symmetrix Storage in VMware Virtual Infrastructure Environments

Falls du noch weitere Fragen hast, feel free.

Gruß
Ralf

ok danke, neuer Erklärungen erzeugen aber leider neue Fragen, meine Storage Kenntnisse sind eher bescheiden, ich komm klar wenn es per default läuft, aber bei solchen Tipps wirds eng...

Habe ich dich richtig verstanden, dass - OHNE Verwendung des SRMs - keine Resignature des Datastores notwendig ist. Ohne SRM wird der Mirror dem ESX gar nicht präsentiert, erst wenn ein Failover erfolgt, wird der Mirror als aktives Storage erkannt, über die Datastore Signature?

SRM benötigt ja beide Storages (aktiv und Mirror) gleichzeitig, deswegen die notwendige "Resignature".

Da es sich bei dieser Replikation wie gewünscht um eine 1:1 Kopie einer LUN in der lokalen Symmetrix handelt, wird auch die Datastore Signatur auf die remote Symmetrix übertragen.
Die Symmetrixen unterstützen jedoch NAA, dadurch verwendet ESX zur Identifizierung eines Datastores die Device WWN.
Somit wird ein replizierter Datastore auf der zweiten Seite immer als Snapshot erkannt, sofern nicht SRM verwendet wird.
Das mußt du daher durch geeignete Maßnahmen in deinem K-Fall Scenario berücksichtigen.

kannst du hier noch mal drauf eingehen? nach dem ersten Satz, wird meine obige Aussage bestätigt. Was meinst du aber mit "jedoch NAA"? Wenn die Indentifizierung dadurch über die WWN erfolgt, dann "merkt" der ESX ja doch, dass es ein anderer Storage ist! Meinst du das mit den Snapshots? Wie mounte ich dann diese Snapshots? Muss das für jede VM einzeln gemacht werden?

Irgendwie ist mir das noch nicht so klar.

Nach dieser Anleitung

http://www.shocknetwork.com/forum/vmwar ... -t138.html

bedeutet das "resignature" das neu registrieren alles VMs!!!!
Das kann doch nciht wirklich sein oder?

Hallo,

korrekt, das Resignaturen eines Datastores erfordert Deregistrierung und anschließendes Registrieren der VM's.

Ein Resignatur eines Datastores ist nicht zwingend notwendig, alternativ kannst du den ESX Server dazu bringen, einen Snapshot einfach zu mounten.
Das erfordert dann aber zwingend, das dieser Server den/die originalen Datastores nicht sieht.
Das macht auch Sinn, da ein ESX Server seine Datastores anhand der Signatur identifiziert, und eine doppelte Signatur ist dann eben fatal.

SRM kümmert sich um den ganzen Blues, der in einem Desaster Fall erforderlich ist.
Im Grunde genommen kanst du das alles auch Scripten oder Manuell durchführen, aber in einem K-Fall dieser Größenordnung geht es üblicherweise drunter und drüber.
Da SRM dann auch noch mit einer Testfunktion daher kommt (erfordert bei Symmetrixen BCV oder Clones), macht das schon einen schlanken Fuß.

Nun noch zu deinen Fragen bzw. Anmerkungen.

Habe ich dich richtig verstanden, dass - OHNE Verwendung des SRMs - keine Resignature des Datastores notwendig ist. Ohne SRM wird der Mirror dem ESX gar nicht präsentiert, erst wenn ein Failover erfolgt, wird der Mirror als aktives Storage erkannt, über die Datastore Signature?

Nein, so einfach ist es nicht.
Ob die Remote Spiegel deinem ESX Server "präsentiert" werden, hängt auch vom Zoning, Masking und der gewählten SRDF Konfiguration in deiner Umgebung ab.
Alles ist erforderlich, um auf die Symmetrix Devices zugreifen zu können, unabhängig ob SRM im Einsatz ist oder nicht.

Auf Zoning und Masking gehe ich nicht weiter ein, hier noch ein paar Infos zu SRDF.

Ein SRDF Failover (ob vom Storage Admin oder von SRM durchgeführt) ändert den Status des remote Spiegels von "Not Ready" ODER "Write Disabled" (abhängig von Symmetrix Konfiguration, WD ist Standard) auf "Read Write".
Daher ist es schon wichtig zu wissen, welchen Status der Remote Mirror im Regelbetrieb hat, denn mit der Symmetrix Standard Einstellung sehen deine ESX Server bereits aktuell die Devices auf der remote Symmetrix und können davon lesen.

Du solltest daher mal die vmkernel Logs nach "SnapShot" durchsuchen.

SRM benötigt ja beide Storages (aktiv und Mirror) gleichzeitig, deswegen die notwendige "Resignature".

SRM setzt eigentlich auf zwei getrennte Rechenzentren, wobei die verwendeten Storage Arrays Ihre Daten untereinander replizieren.
Ergo bräuchtest du je RZ einen ESX Cluster mit Virtual Center, die auschließlich auf ihr lokales Array zugreifen.
Das die ESX Server gleichzeitig beide Arrays sehen, ist nicht vorgesehen und kann ich auch nicht empehlen (doppelte Signaturen)

Ob unter solchen Bedingungen SRM für euch noch eine Option ist, mußt du dir selber überlegen.

Die Symmetrixen unterstützen jedoch NAA, dadurch verwendet ESX zur Identifizierung eines Datastores die Device WWN.

Storage Arrays mit NAA stellen für jedes Device eine unique ID bereit, die sich auch dann nicht ändert, wenn z. B. die LUN ID, der verwendete FrontEnd Adapter oder die Kapazität des Devices ändert.
ESX Server nutzen diese Funktion beim Anlegen eines Datastores und legen diese Kennung in der private Region ab, welche in deinem Fall natürlich ebenfalls repliziert wird.
Beim Starten/Resacn liest ein ESX Server die private Region aus und vergleicht den Inhalt mit den Informationen, die ihm das verwendete Array auf SCSI Anfragen liefert.
In deinem Scenario steht im Datastore die Device WWN der verwendeten LUN vom Array 1 und der SCSI Scan liefert die Device WWN der verwendeten LUN auf dem Array 2.
Diese weichen wie beschrieben von einander ab, daher wird der Datastore in der Default EInstellung nicht gemountet.

Beim ESX 4 gibt es dafür ein neues CLI Kommando, mit dem du auf diesen Sachverhalt reagieren kannst.
esxcfg-volume
Damit kannst du dir die Liste der als Snapshot erkannten Datastores anzeigen lassen und auch festlegen, ob diese gemountet werden sollen oder die Signatur an die neue Umgebung angepasst werden soll.
Verwendest du die Mount Funktion, wird an den Datastores nichts verändert und damit entfällt auch das Registrieren der VM's.
Allerdings darf der Datastore auf der alten Symmetix dann nicht gleichzeitig sichtbar sein, sonst .....

Das sollte es gewesen sein, falls du noch weitere Fragen hast, feel free....

Gruß
Ralf

Hallo zusammen,

mich interessiert dieses Thema auch gerade.

Habt Ihr hier evt. schon ein paar Scripts in der Schublade?

Soweit ich es verstanden habe:

1. Unpresent the failed Storage to the ESX hosts (SAN switch)
2. present the mirrored LUNs on the other storage to the ESX hosts (zoning or masking)
3. rescan the HBAs on all ESX hosts
4. register all VMs // wo soll man das machen, auf einem Host oder Virtual Center ??
5. power on the VMs

Soweit korrekt?

Im nächsten Schritt werde ich die Zoning / Masking Geschichte scripten.
Ich finde den Ansatz übers Masking besser, da man hier nur die Presentation aktivieren muss.

Für den VMWare Teil brauche ich "nur" noch die Scripts. HBA Scan habe ich bereits.
Muss man die LUNs noch den Hosts manuell als Datastore hinzufügen oder reicht ein einfacher HBA rescan aus?

Danke für Eure Hilfe.

Schau dir mal das Tool an! Habe hier etwas dazu geschrieben.

http://www.vmachine.de/cms/index.php/de ... -quick-reg

Besten Dank. Werde ich mir anschauen.

Meine Absicht war aber den gesamten Prozess des Failovers zu scripten.

Ähnlich wie hier beschrieben:

http://www.vmware.com/files/pdf/partner ... eva-wp.pdf

Mir fehlt lediglich das Script mittels VMWare CLI zum scannen u. registrieren der VMs von den neuen (gespiegelten) LUNs.

Cool wäre regelmäßig eine Liste erstellen zu lassen, in der alle aktiven VMs enthalten sind u. diese dann fürs registrieren zu verwenden.

Mal eine ganz dumme Frage für jemanden der noch keinen gespiegelten Storage aufgestellt hat: Es gibt keinen Pathfailover oder dergleichen wenn ein Storage komplett wegfällt? D.h. alle VMs sind pauschal erst mal weg?
Wäre das anders wenn ich einen der Storagevirtualisierer wie Datacore einsetze?

Wenn du Datacore verwendest und nur einen Storage hast dann bleibt das Problem. Hast du aber zwei Storage Systeme und zwei Datacore Storage Domain Server kann irgendwas ausfallen und keiner merkt es.

Danke. Bei Datacore war mir das klar, weil es ja ein virtualisierter Storage ist.
Aber wie ist es denn bei einer EMC oder einer IBM DS3400 oder einer HP MSXXXX welche auch eine Option zum Spiegeln bieten?

JMcClane hat geschrieben:Mal eine ganz dumme Frage für jemanden der noch keinen gespiegelten Storage aufgestellt hat: Es gibt keinen Pathfailover oder dergleichen wenn ein Storage komplett wegfällt? D.h. alle VMs sind pauschal erst mal weg?
Wäre das anders wenn ich einen der Storagevirtualisierer wie Datacore einsetze?

auch mit gespiegeltem SAN sind die VMs erst einmal weg.
Außer Du hast Datacore oder NetAPP oder dergleichen als SAN-Virtualisierung über dem gespiegeltem SAN.
Diesen Luxus gibts bei uns nicht. d.h. ich muss mit einem minimalen Ausfall die VMs wieder zum Laufen bringen.

Das geht anscheinend so wie ich es oben in den Steps beschrieben habe. Alternativ kann man für etwas Budget den SRM v. VMWare kaufen.

Zurück zum Thema:

Es hat keiner zufällig ein Script fürs registrieren der VMs nach einem HBA rescan?

Gibts wirklich so wenig Admins, die solche Anforderungen haben?

Hallo

ich habe zu dem Thema noch eine andere Frage wie ist das wenn ich einen NFS Datastore habe

Danke

Drumcode2003 hat geschrieben:

JMcClane hat geschrieben:Mal eine ganz dumme Frage für jemanden der noch keinen gespiegelten Storage aufgestellt hat: Es gibt keinen Pathfailover oder dergleichen wenn ein Storage komplett wegfällt? D.h. alle VMs sind pauschal erst mal weg?
Wäre das anders wenn ich einen der Storagevirtualisierer wie Datacore einsetze?

auch mit gespiegeltem SAN sind die VMs erst einmal weg.
Außer Du hast Datacore oder NetAPP oder dergleichen als SAN-Virtualisierung über dem gespiegeltem SAN.
Diesen Luxus gibts bei uns nicht. d.h. ich muss mit einem minimalen Ausfall die VMs wieder zum Laufen bringen.

Das geht anscheinend so wie ich es oben in den Steps beschrieben habe. Alternativ kann man für etwas Budget den SRM v. VMWare kaufen.

Zurück zum Thema:

Es hat keiner zufällig ein Script fürs registrieren der VMs nach einem HBA rescan?

Gibts wirklich so wenig Admins, die solche Anforderungen haben?

schau dir mal http://www.mightycare.de/#/de/downloads/mcsdrquickreg/ an, damit kannst du dir evtl. das Skripten sparen.

Noch mal eine Info zum gespiegelten Storage: Wenn ein Storage wegbricht, kann es teilweise ziemlich lange dauern bis man das feststellen kann. Wir haben das getestet und leider kann das in ziemliche Arbeit ausarten, die VMs davon zu überzeugen, dass sie eigentlich kein Storage mehr haben, und deshalb doch in den Status OFF gehen sollen, damit man mit ihnen weiter arbeiten kann (also z.b. entfernen und von neuen Storage neu registrieren).

Diese manuelle Sache ist leider suboptimal, eine Lösung wie SRM oder gar Storage virtualisierung sind meines Erachtens wirklich wichtig bei solchen Umgebungen. Ansonsten ist ein Spiegel nur trügerische Sicherheit.

Hallo Mangold,

ich bin leider immer noch nicht in den Genuss eines vStorage gekommen.

d.h. ich suche immer noch eine "Zwischenlösung".
Neue Firma, altes Problem, sozusagen.

Bisher hatte ich noch keine Zeit mir Skripte zu basteln. Der Link ist zwar nett, aber NAS ist nicht gerade das, was ich mir vorstelle, da ich mit EMC arbeiten muss.