VMware-Forum

Hallo zusammen,

ist es möglich über den ESX Server eine Spiegelung im RAID 1 über mehrere (2) SANs einzurichten. Ich möchte gerne zwei LUNs über den ESX spiegeln und als ein Speicher zur Verfügung stellen.

Darüber hinaus habe ich noch eine Frage bezüglich den RAW-Bereiche, die in die virtuelle Maschine weitergeleitet werden. Wo liegen die Vorteile bzw. Nachteile das ESX-Storage zu nutzen bzw. die LUN weiterzureichen.

DANKE!

Gruß
Hollyman

ESX kann nicht spiegeln.

Schade! Wie ist denn der Vergleich zwischen virtuellen Festplatten auf der RAW-LUN und dem ESX-Speicher zu sehen? Danke!!!

das vmware keine spiegelung kann ist sehr schade und dadurch leider ist der storage auch der single point of failure. drum herum kommt man mit storage virtualisierung.

raw device mapping ist nützlich wenn man exclusiven zugriff auf ein laufwerk braucht (cluster) oder wenn eine anwendung direkt auf ein scsi device zugreifen möchte, performance technisch soll es ab version 3 egal sein ob man vmfs verwendet oder raw device mapping. hier ein etwas älteres dokument zu raw device mapping

http://www.vmware.com/pdf/esx25_rawdevicemapping.pdf

hab nichts zu 3.x gefunden. wir verwenden kein RDM weil bis zu version 2.5 kein vmotion damit ging, seit dem haben wir es auch nicht mehr gebraucht.

hier meiner meinung nach ein sehr guter artikel dazu

http://www.forum.searchsecurity.de/showthread.php?t=542

Storagevirtualisierung ist nett, aber auf gar keinen Fall die Lösung für alle Probleme. Lieber mal den Site Recovery Manager anschauen und die für den SRM zertifizierten Produkte für Storagesysteme, z.B. HP Continuous Access EVA.

Naja, SRM ist aber auch nichts finde ich.

Na ja, hier ging es um Spiegeln. Storagevirtualisierung ist kein Allerheilmittel, auch wenn das Spiegeln da ein interessanter Nebeneffekt ist. Für die Spiegelung sind nun mal Produkte wie HP CA, EMC² SRDF usw. gedacht.

wenn ich mir die spiegelung anschaue die kein automatischens Failover macht, und ich für 100 VMs neue Pfade zu den Luns konfigurieren muss, dann ist Storage Virtualisierung für mich das Mittel der Wahl weil ich a) keine Pfade neu konfigurieren muss, b) keine VM erstmal weg ist und c) der Storage gespiegelt wird. Für Vmware ist das völlig transparent und für mich DIE Lösung schlechthin im VMware bereich, so lange VMware selbst kein Storage Mirroring á la LVM wie bei AIX kann. Selbst Windows kann Software Raid (über die Qualität müssen wir nicht diskutieren) und Storage ist eben DER Single Point of Failure, das hat VMware immer noch nicht kapiert.

Ich gebe dir recht was SAN Virtualisierung angeht aber VMware hat es scho verstanden und sieht es einfach nicht als die Aufgabe die bei VMware hängt. Finde ich in Ordnung

Heros hat geschrieben:Ich gebe dir recht was SAN Virtualisierung angeht aber VMware hat es scho verstanden und sieht es einfach nicht als die Aufgabe die bei VMware hängt. Finde ich in Ordnung

ja war deren aussage, sollen sich andere drum kümmern

und das finde ich in Ordnung

kinzwischen gebe ich dir recht, aber vor nicht zu langer Zeit gab es m.E. keine vernünftigen Lösungen, die dann auch noch von VMware supported waren.

Ja, das mit dem Support ist eine andere Sache! Das Thema war bzw. ist schon recht schwierig.

Bei Lösungen wie HP CA hat VMware ja auch nichts damit zu tun. Der Site Recovery Manager ist in diesem Fall nur dafür gedacht, das Sekundärsystem zu aktivieren, im Fehlerfall. Insofern verstehe ich deinen Einwand nicht ganz.

Ich finde den SRM einfach sehr teuer und aufgeblasen dafür das er da eigentlich nicht viel macht, oder?
Das einzige was da passiert ist das 10 Skripte ablaufen und das man einen großen roten Knopf hat.

Hallo zusammen,

wir haben vor 3 Wochen das Projekt SAN-Virtualisierung erfolgreich abgeschloosen.

Umbegbung: 2 x EVA 4000 jeweils 56 HDD mit 146 GB

Als Lösung haben wir DATACORE eingesetzt und sind voll und ganz zufrieden.
Hervoragende Performanc und wesentlich günstiger als die Lösung die HP bietet (CA)

Grüße
Peter

Bei SANmelody stimmt das, bei SANsymphony ist CA günstiger. Aber CA und SANmelody/ SANsymphony verfolgen unterschiedliche Ziele. Der Mirror, den die DataCore Produkte mitbringen hat seinen Preis: Man macht sich vom Hersteller abhängig. Ohne DataCore geht nix mehr. Sehr lustig bei Migrationen oder Inkompatibilitäten. Ich bin nicht gegen DataCore (bin selber DCIE für SANsymphony), aber man muss den Usecase betrachten. Trotzdem habe auch ich Kunden, die genau deswegen auf DataCore gesetzt haben: Einzig und allein wegen dem Mirror.

ja wir haben SANmelody im Einsatz. Aber das Argument mit dem Abhängig machen gilt doch genauso bei CA. Ich bin der Meinung, dass man sich mit CA noch viel mehr abhängig macht, da man HP voll ausgeliefert ist. Bei DataCore kann ich zumindest das dahinter liegende Storage frei wählen.

Dies war zumindest bei uns der Grund warum wir Datacore wählten. Bei CA so die Aussage von HP, wäre bei einem Storage wechsel z.B. EVA 4000 auf EVA 8000 die Lizenz von CA hinfällig gewesen und es wären neue Lizenzen anzuschaffen gewesen..

Hallo

solange ein anderes Unternehmen über VMware steht und ein Interesse hat, das seine Produkte (Storage Based Mirroring [SBM] ) verkauft werden, werden wir bei Vmware die Host Based Mirroring (HBM) Funktionalität oder auch sowas wie Cluster FS lange vermissen.

So hat das besagte Unternehmen in seiner Roadmap die Funtkionalität Transparent Failover in Kombinatiion mit SBM (=Datacore) zurückgestellt. Warum eigentlich?. Vieleicht weil diese Funktionalität mit dem SRM (Site Recovery Manager) wiederum kommerziell kollidiert.

Was Datacore derzeit bietet ist vieleicht nicht das Allheilmittel, aber es maskiert zumindest den single point of failure im Storage Layer gegenüber dem Computing Layer. Vergleichbares findet man schon seit mehreren Jahren im IBM z/OS Umfeld (mit Hyperswap und PPRC). Es ist nicht verwunderlich, da dort ein end-2-end-development mit hauseigenen Produkten stattfindet, was in der Open Systems Welt nicht funktioniert (=> Heterogenität und Alleinstellungsmerkemale).

Mich interessiert in Kombination mit Datacore folgendes Thema über welches vieleicht der eine oder andere in diesem Forum auch gestolpert ist:

Mehrere ESX Server greifen via Datacore Alternate Path über Ihren HBA_A auf einen Pool von LUNS zu, die über den SDS_A Read/Write bereit gstellt werden. Der SDS_A spiegelt die Write-I/Os auf den SDS_B. Der HBA_A von allen ESX Server sowie der SDS_A befinden sich in der Fabric_A.Analog befinden sich die HBA_B Karten von allen ESX Servern, sowie der SDS_B in der Fabric B.
Im Normalzustand laufen Write und Read I/Os über den "A" Strang (HBA_A => Fabric_A => SDS_A).
Gesetzt den Fall, der HBA_A eines ESX Servers fällt aus (HBA defekt, Kabel defekt, oder Switch Port defekt). Dieser Server kann und wird wohll über den HBA_B I/Os absetzen. Was machen die anderen ESX Server, die nach wie vor kein Problem mit den "A" Pfad haben ?

Bin gerne bereit das Thema offline zu diskutieren, sollte es hier den Rahmen des Forums gesprengt haben!

Gruß

Soweit ich weiß arbeiten die anderen Server ganz normal weiter. Die bekommen davon nichts mit. Warum auch? Der wechsel des Pfades wird vom Initiator ausgelöst.

Hallo,

hmm das ist eine gute Frage, hab diese mal an unseren Implementeur weitergelitet. Denke er wird gleich antworten.


Nach meinem Verständnis dürfte der Ausfall des HBA-A keine Auswirkung haben, da der Pfadwechsel vom Initiator ausgelöst wird.

Falls es jemanden Interessiert, habe ich als Anlage mal Anschluss und Verkabelungsschema beigefügt.

Einzig was es in diesem Zusammenhang zu beachten gibt ist, wenn ein SDS ausfällt und später wieder zur Verfügung steht, dass im ESX-Umfeld die HBAs neu gescannt werden müssen.

Peter

Hallo Peter,

richtig der betroffene ESX Server, der nun keine I/Os mehr über den HBA_A senden kann wird diese über den HBA_B senden, die wiederum gegen den SDS_B gehen.

Sollten nun alle anderen ESX Server über den HBA_A arbeiten, müssen beide SDSen Write I/Os verarbeiten. Ist das so richtig dargestellt? Es ist nämlich nicht unwahrscheinlich, dass dann beide SDSen Write I/Os auf einen und den selben Block durchführen müssen.
Was passiert dann? Da die SDSen klassisch Storage Based Mirroring machen kann ich mir nicht vorstellen, dass in diesem Falle beide SDSen eine LUN bidirektional spiegeln.

Gruß, ITARCH

DataCore nutzt für ESX einen 3rd Party Mirror, nicht Alternate Path. Alle ESX nutzen einen SDS als primären SDS, bzw. ein Volume hat einen primären SDS. Wenn es nun einen Pfadfehler gibt, dann wechseln alle ESXer zum sekundären ESX.

zu sekundären SDS wolltest du bestimmt sagen.

Das ist interessant! Wusste ich nicht! Danke für die Info.

Ja, natürlich. War in Gedanken wo anders. Danke.