Hi,
wir benutzen 2 EMC VNX5300er als Block. Nun haben wir uns entschlossen, keine DataMover für CIFS einzusetzen. D. h. es wird ein virtueller Win2008R2 als Fileserver werden.
Bisher hatten wir einen physikalischen Dateiserver mit iSCSI.
Nach googeln unterscheiden sich die Aussagen. Deshalb meine Fragen:
-macht in einem Vmware-Cluster DFS über zwei Server Sinn?
-RDM oder VMDK?
-NetBackup Agent/BackupExec Agent oder diff. Sicherung mit vRanger?
-dedizierte Netzwerkanbindung über 1 o. 2 Ports
-Snapshot/Mirror einer möglichen RDM-LUN?
Danke vorab für alle Antworten.
Gruß
Markus
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Fileserver virtuell - RDM oder VMDK - EMC VNX
-
irix
- King of the Hill
- Beiträge: 13066
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: Fileserver virtuell - RDM oder VMDK - EMC VNX
mullfreak hat geschrieben:Hi,
wir benutzen 2 EMC VNX5300er als Block. Nun haben wir uns entschlossen, keine DataMover für CIFS einzusetzen. D. h. es wird ein virtueller Win2008R2 als Fileserver werden.
Bisher hatten wir einen physikalischen Dateiserver mit iSCSI.
Nach googeln unterscheiden sich die Aussagen. Deshalb meine Fragen:
-macht in einem Vmware-Cluster DFS über zwei Server Sinn?
Ich finde ja. Die Last und verteilt sich und wenn man kann die Freigaben, sofern man mehrere hat, ja dann aufteilen. Bei einem Problem ist dann nicht immer alles Betroffen. DFS selbst bei nur einem Server ist was feines weil man spaeteren migration damit locker entgegen geht.
-RDM oder VMDK?
Schreibe die Vor- und Nachteile auf welche in deiner Umgebung entstehe und entscheide dich.
-NetBackup Agent/BackupExec Agent oder diff. Sicherung mit vRanger?
Wuerde ich von der Groesse/Menge an Daten abhaengig machen und wieoft einzelene Dateien wiederhergestellt werden muessen. Dran denken das es beim vRanger ja nicht direkt geht es an den Originalplatz geht und somit unterumstaenden die Rechte angepasst werden muessen.
-dedizierte Netzwerkanbindung über 1 o. 2 Ports
-Snapshot/Mirror einer möglichen RDM-LUN?
pRDMs lassen sich nicht Snapen.
Danke vorab für alle Antworten.
Gruß
Markus
Gruss
Joerg
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Jörg,
hier meine 2 Cent's.
Meiner Meinung nach nicht wirklich, da DFS eigentlich dafür entwickelt wurde, an mehreren verteilten Standorten ein "zentrales" Filesystem bereitzustellen.
Zwar kannst du das auch zum Zwecke der Lastverteilung einsetzen, aber eigentlich ist auf Fileservern nie wirklich viel Last.
Sofern du deinem Fileserver genügend LUN's bereitstellst um die IO Last zu bewältigen sehe ich keinen wirklichen Vorteil in DFS.
RDM's machen nur dann wirklich Sinn, wenn du entweder Funktionen des Storage Arrays nutzen oder auf physikalische HW umschalten möchtest.
In deinem Thread stellst du ja noch die Frage nach Snapshot & Mirror(view) sowie Backups, gehst aber nicht weiter darauf ein.
Daher ist alles folgende etwas spekulativ, denn sowohl für MirrorView als auch (VNX) Snapshots müßtest du Storage Kapazitäten bereitstellen.
Mit MirrorView kannst du deine Daten (a)synchron auf deine zweite Box spiegeln lassen, somit könntest du auch Desaster Scenarien wie den Ausfall eines kompletten RZ abfangen.
Mit VNX Snapshots könntest du z. B. dein Backup durchführen, ohne den produktiven Fileserver damit zu belasten, indem du deine Snapshots einfach auf einer weiteren VM mountest und das Backup dort laufen läßt.
Wenn du mehrere Snapshots (z.B. für eine Woche) vorhältst, könntest du diese z. B. auch sehr einfach zum Single File restore einsetzen.
Da solltest du uns vielleicht mal etwas mehr über deine Absichten erzählen.
Zu den anderen Punkten kann ich nichts sagen.
Viel Spaß,
Ralf
hier meine 2 Cent's.
Markus hat geschrieben:macht in einem Vmware-Cluster DFS über zwei Server Sinn?
Meiner Meinung nach nicht wirklich, da DFS eigentlich dafür entwickelt wurde, an mehreren verteilten Standorten ein "zentrales" Filesystem bereitzustellen.
Zwar kannst du das auch zum Zwecke der Lastverteilung einsetzen, aber eigentlich ist auf Fileservern nie wirklich viel Last.
Sofern du deinem Fileserver genügend LUN's bereitstellst um die IO Last zu bewältigen sehe ich keinen wirklichen Vorteil in DFS.
Markus hat geschrieben:RDM oder VMDK?
RDM's machen nur dann wirklich Sinn, wenn du entweder Funktionen des Storage Arrays nutzen oder auf physikalische HW umschalten möchtest.
In deinem Thread stellst du ja noch die Frage nach Snapshot & Mirror(view) sowie Backups, gehst aber nicht weiter darauf ein.
Daher ist alles folgende etwas spekulativ, denn sowohl für MirrorView als auch (VNX) Snapshots müßtest du Storage Kapazitäten bereitstellen.
Mit MirrorView kannst du deine Daten (a)synchron auf deine zweite Box spiegeln lassen, somit könntest du auch Desaster Scenarien wie den Ausfall eines kompletten RZ abfangen.
Mit VNX Snapshots könntest du z. B. dein Backup durchführen, ohne den produktiven Fileserver damit zu belasten, indem du deine Snapshots einfach auf einer weiteren VM mountest und das Backup dort laufen läßt.
Wenn du mehrere Snapshots (z.B. für eine Woche) vorhältst, könntest du diese z. B. auch sehr einfach zum Single File restore einsetzen.
Da solltest du uns vielleicht mal etwas mehr über deine Absichten erzählen.
Zu den anderen Punkten kann ich nichts sagen.
Viel Spaß,
Ralf
Hallo,
danke für Eure schnellen Antworten.
Zu DFS:
Ich muss noch prüfen ob DFS auch Access Based Enumeration unterstützt. Wenn nicht, dann ist DFS auch gestorben. Ein "normaler" File-Server würde es auch tun.
Zu RDMs:
Eigentlich ist es gedacht, per MirrorView die LUN(s) für den FileServer auf die zweite VNX zu synchronisieren. Dies funktioniert nur, wenn ich dedizierte LUNs an die VM bringe per RDM? Ansonsten teilen sich doch alle VMs mit allen Platten die LUN. D. h. bei MirrorView (S) würde ich über RDM nicht herumkommen?
Sicherheit:
Storage Snapshots auf der VNX sollen funktionieren. Entweder wir benutzten ShadowCopy des Win-Servers oder oben Snapshots der VNX. Bandsicherung muss natürlich sein, dies soll dann NetBackup mit Agent übernehmen.
Speicherplatz:
Derzeit hat unser gesamter Fileserver ca. 1.5TB.
Gruß
Markus
danke für Eure schnellen Antworten.
Zu DFS:
Ich muss noch prüfen ob DFS auch Access Based Enumeration unterstützt. Wenn nicht, dann ist DFS auch gestorben. Ein "normaler" File-Server würde es auch tun.
Zu RDMs:
Eigentlich ist es gedacht, per MirrorView die LUN(s) für den FileServer auf die zweite VNX zu synchronisieren. Dies funktioniert nur, wenn ich dedizierte LUNs an die VM bringe per RDM? Ansonsten teilen sich doch alle VMs mit allen Platten die LUN. D. h. bei MirrorView (S) würde ich über RDM nicht herumkommen?
Sicherheit:
Storage Snapshots auf der VNX sollen funktionieren. Entweder wir benutzten ShadowCopy des Win-Servers oder oben Snapshots der VNX. Bandsicherung muss natürlich sein, dies soll dann NetBackup mit Agent übernehmen.
Speicherplatz:
Derzeit hat unser gesamter Fileserver ca. 1.5TB.
Gruß
Markus
-
irix
- King of the Hill
- Beiträge: 13066
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
mullfreak hat geschrieben:..
Zu RDMs:
Eigentlich ist es gedacht, per MirrorView die LUN(s) für den FileServer auf die zweite VNX zu synchronisieren. Dies funktioniert nur, wenn ich dedizierte LUNs an die VM bringe per RDM? Ansonsten teilen sich doch alle VMs mit allen Platten die LUN. D. h. bei MirrorView (S) würde ich über RDM nicht herumkommen?
Es zwingt dich keiner in eine LUN mehr als eine VM/VMDK zu tun. Wenn aber ein einfacheres/schnnelleres Backup/Restore eine hohe Gewichtung hat so guck halt was dein Storage wie in welcher Form bietet und was da die besten Bedinungen sind.
Dann ist das naehmlich keine RDM Grundsatzdiskussion sondern eher was EMC VNX Spezifschen im Zusammenspiel mit vSphere.
Gruss
Joerg
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Jörg,
du kannst durchaus VMFS verwenden, du mußt dir halt nur darüber im Klaren sein, das dann ein VNX Snap/Mirror immer die ganze LUN betrifft.
SRM z.b. fasst ja auch mehrere VM's auf einem Datastore in einem Recovery Plan zusammen.
Da MirrorView blockbasiert arbeitet, kannst du damit keine konsistenten Filesysteme garantieren, weil das Array ja nie weiß, zu welchem Zeitpunkt in einem IO Flow das Filesystem mal konsistent ist.
In den meisten Fällen ist das aber kein Problem, da sowohl VMFS als auch NTFS sehr robust sind und NTFS darüber hinaus ja auch noch einen Filesystem Check/Repair ermöglicht.
Mit VNX Snapshots wärst du dagegen sehr wohl in der Lage, zum Zeitpunkt deines Backups für konsistente Filesysteme zu sorgen, sei es mit RDM's oder VMFS.
Ich würde deinen Ansatz sogar kombinieren, in dem ich den ShadowCopy auf dem Windos Server aktivieren und dann einen VNX Snapshot erzeugen.
Danach kannst du den ShadowCopy auf dem Produktiven Host wieder deaktivieren und den VNX SnapShot einem Mount Host zum Backup geben.
Hängt also ganz entscheidend davon ab, was genau du mit der Kombination MirrorView und SnapShot umsetzen mußt.
Gruß,
Ralf
du kannst durchaus VMFS verwenden, du mußt dir halt nur darüber im Klaren sein, das dann ein VNX Snap/Mirror immer die ganze LUN betrifft.
SRM z.b. fasst ja auch mehrere VM's auf einem Datastore in einem Recovery Plan zusammen.
Da MirrorView blockbasiert arbeitet, kannst du damit keine konsistenten Filesysteme garantieren, weil das Array ja nie weiß, zu welchem Zeitpunkt in einem IO Flow das Filesystem mal konsistent ist.
In den meisten Fällen ist das aber kein Problem, da sowohl VMFS als auch NTFS sehr robust sind und NTFS darüber hinaus ja auch noch einen Filesystem Check/Repair ermöglicht.
Mit VNX Snapshots wärst du dagegen sehr wohl in der Lage, zum Zeitpunkt deines Backups für konsistente Filesysteme zu sorgen, sei es mit RDM's oder VMFS.
Ich würde deinen Ansatz sogar kombinieren, in dem ich den ShadowCopy auf dem Windos Server aktivieren und dann einen VNX Snapshot erzeugen.
Danach kannst du den ShadowCopy auf dem Produktiven Host wieder deaktivieren und den VNX SnapShot einem Mount Host zum Backup geben.
Hängt also ganz entscheidend davon ab, was genau du mit der Kombination MirrorView und SnapShot umsetzen mußt.
Gruß,
Ralf
-
irix
- King of the Hill
- Beiträge: 13066
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Da ich keine VNX habe, kannst du kurz erklaeren was und wo die Unterschiede bei Snap und oder Mirror sind?
Die Arbeitsweise von SRM ist mir bekannt und was mein Haus und Hof Storage angeht so bekommt das auch einen konsistenten Storage basierten Snapshot eines VMFS und den VMDKs hin. Weil das Storage hier mit dem vCenter spricht und dieses einen Snap der VMs veranlasst bevor das Storage seinen macht.
Wir haben unsere Fileserver per DFS "One-Way" Replikation in eine 2 Location und dort steht ein wenig mehr Storage zur Verfuegung. Hier sind dann ShadowCopies aktiv. Wir haben in den letzten 1.5 Jahren keine Files mehr aus der primaeren Sicherung holen muessen.
Gruss
Joerg
Die Arbeitsweise von SRM ist mir bekannt und was mein Haus und Hof Storage angeht so bekommt das auch einen konsistenten Storage basierten Snapshot eines VMFS und den VMDKs hin. Weil das Storage hier mit dem vCenter spricht und dieses einen Snap der VMs veranlasst bevor das Storage seinen macht.
Wir haben unsere Fileserver per DFS "One-Way" Replikation in eine 2 Location und dort steht ein wenig mehr Storage zur Verfuegung. Hier sind dann ShadowCopies aktiv. Wir haben in den letzten 1.5 Jahren keine Files mehr aus der primaeren Sicherung holen muessen.
Gruss
Joerg
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Jörg,
MirrorView wird zur Replikation zwischen zwei Arrays eingesetzt.
Da es unterhalb eines Filesystems arbeitet (wie alle Array based Replikationen) ist es somit alleine nicht in der Lage, für einen konsistenten Zustand eines Filesystems zu sorgen.
Snaps werden zu einem vom Anwender definierten Zeitpunkt erzeugt.
Auch hier ist das Array alleine nicht in der Lage, ein konsistentes Filesystem zu gewährleisten.
Das muß durch den User/die Applikation übernehmen und da gibt es eine Vielzahl von Möglichkeiten (VMware Snapshots, VSS, etc.)
Es kommt also auf die Kombination von Software und Hardware an, um von einem laufenden Server/Cluster eine konsistente Kopie eines Filesystems zu erzeugen, diese Anforderung ist für alle Storage Arrays gleich, egal von welchem Hersteller.
Ob und welcher Hersteller hier eine bessere/einfachere Integration in VMware hinbekommt ist ein Thema für sich.
Gruß,
Ralf
MirrorView wird zur Replikation zwischen zwei Arrays eingesetzt.
Da es unterhalb eines Filesystems arbeitet (wie alle Array based Replikationen) ist es somit alleine nicht in der Lage, für einen konsistenten Zustand eines Filesystems zu sorgen.
Snaps werden zu einem vom Anwender definierten Zeitpunkt erzeugt.
Auch hier ist das Array alleine nicht in der Lage, ein konsistentes Filesystem zu gewährleisten.
Das muß durch den User/die Applikation übernehmen und da gibt es eine Vielzahl von Möglichkeiten (VMware Snapshots, VSS, etc.)
Es kommt also auf die Kombination von Software und Hardware an, um von einem laufenden Server/Cluster eine konsistente Kopie eines Filesystems zu erzeugen, diese Anforderung ist für alle Storage Arrays gleich, egal von welchem Hersteller.
Ob und welcher Hersteller hier eine bessere/einfachere Integration in VMware hinbekommt ist ein Thema für sich.
Gruß,
Ralf
Hi,
hab jetzt mal nach ABE geschaut. Dies ist im Windows 2008 Server R2 standardmäßig enthalten: http://www.windows-faq.de/2011/01/03/ac ... ktivieren/
Zum Konsistenz von MirrorView:
Lt. EMC ist MirrorView immer konsistent, siehe hier (Auszug Chat-Protokoll):
markus: "is the mirror application consistent?"
Agent (Chinthalacheruvu, N): "Yes it is."
Ist und bleibt eine Aussage!
Die Königslösung von EMC wäre dann RecoverPoint. Das haben wir (noch) nicht. Also müssen wir mit MirrorView leben. Auch im EMC-Forum wurde öfters bestätigt, dass MirrorView immer konsistent ist. Hmm...
Als Lizenz hätten wir noch RecoverManager von EMC, aber bisher noch nicht getestet. Vielleicht bringt das Segen für den Fileserver.
Stand jetzt wird es nun ein Windows 2008 R2 Server mit mehreren RDMs. Diese werden mit MirrorView(S) auf die zweite VNX geschoben. Weiter im Server gibt's Shadow Copys. Dann Bandsicherung von Snapshots der RDMs die am Backup-Server gemountet sind.
Packen wirs an!
hab jetzt mal nach ABE geschaut. Dies ist im Windows 2008 Server R2 standardmäßig enthalten: http://www.windows-faq.de/2011/01/03/ac ... ktivieren/
Zum Konsistenz von MirrorView:
Lt. EMC ist MirrorView immer konsistent, siehe hier (Auszug Chat-Protokoll):
markus: "is the mirror application consistent?"
Agent (Chinthalacheruvu, N): "Yes it is."
Ist und bleibt eine Aussage!
Die Königslösung von EMC wäre dann RecoverPoint. Das haben wir (noch) nicht. Also müssen wir mit MirrorView leben. Auch im EMC-Forum wurde öfters bestätigt, dass MirrorView immer konsistent ist. Hmm...
Als Lizenz hätten wir noch RecoverManager von EMC, aber bisher noch nicht getestet. Vielleicht bringt das Segen für den Fileserver.
Stand jetzt wird es nun ein Windows 2008 R2 Server mit mehreren RDMs. Diese werden mit MirrorView(S) auf die zweite VNX geschoben. Weiter im Server gibt's Shadow Copys. Dann Bandsicherung von Snapshots der RDMs die am Backup-Server gemountet sind.
Packen wirs an!
Hi,
hab jetzt mal nach ABE geschaut. Dies ist im Windows 2008 Server R2 standardmäßig enthalten: http://www.windows-faq.de/2011/01/03/ac ... ktivieren/
Zum Konsistenz von MirrorView:
Lt. EMC ist MirrorView immer konsistent, siehe hier (Auszug Chat-Protokoll):
markus: "is the mirror application consistent?"
Agent (Chinthalacheruvu, N): "Yes it is."
Ist und bleibt eine Aussage!
Die Königslösung von EMC wäre dann RecoverPoint. Das haben wir (noch) nicht. Also müssen wir mit MirrorView leben. Auch im EMC-Forum wurde öfters bestätigt, dass MirrorView immer konsistent ist. Hmm...
Als Lizenz hätten wir noch RecoverManager von EMC, aber bisher noch nicht getestet. Vielleicht bringt das Segen für den Fileserver.
Stand jetzt wird es nun ein Windows 2008 R2 Server mit mehreren RDMs. Diese werden mit MirrorView(S) auf die zweite VNX geschoben. Weiter im Server gibt's Shadow Copys. Dann Bandsicherung von Snapshots der RDMs die am Backup-Server gemountet sind.
Packen wirs an!
hab jetzt mal nach ABE geschaut. Dies ist im Windows 2008 Server R2 standardmäßig enthalten: http://www.windows-faq.de/2011/01/03/ac ... ktivieren/
Zum Konsistenz von MirrorView:
Lt. EMC ist MirrorView immer konsistent, siehe hier (Auszug Chat-Protokoll):
markus: "is the mirror application consistent?"
Agent (Chinthalacheruvu, N): "Yes it is."
Ist und bleibt eine Aussage!
Die Königslösung von EMC wäre dann RecoverPoint. Das haben wir (noch) nicht. Also müssen wir mit MirrorView leben. Auch im EMC-Forum wurde öfters bestätigt, dass MirrorView immer konsistent ist. Hmm...
Als Lizenz hätten wir noch RecoverManager von EMC, aber bisher noch nicht getestet. Vielleicht bringt das Segen für den Fileserver.
Stand jetzt wird es nun ein Windows 2008 R2 Server mit mehreren RDMs. Diese werden mit MirrorView(S) auf die zweite VNX geschoben. Weiter im Server gibt's Shadow Copys. Dann Bandsicherung von Snapshots der RDMs die am Backup-Server gemountet sind.
Packen wirs an!
mullfreak hat geschrieben:Hi,
hab jetzt mal nach ABE geschaut. Dies ist im Windows 2008 Server R2 standardmäßig enthalten: http://www.windows-faq.de/2011/01/03/ac ... ktivieren/
Also ich würde ja eher dem Hersteller, als einer 3rd Party FAQ trauen...
http://technet.microsoft.com/de-de/libr ... 10%29.aspx
ABE gibt es seit 2003, es ist selbstverständlich in 2008 und 2008 R2 enthalten und lässt sich auch problemlos in Verbindung mit DFS nutzen.
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast