Hallo,
folgende Ausstattung:
HP ML2012i mit 2 Shelfs
Unit 0: 12x 146GB SAS (für VM´s)
Unit 1: 12x 1TB SATA
Wir wollen unseren bisherigen Hardware-File-Server virtualisieren. D. h. das Betriebssystem soll sich auf Unit 0 befinden und die virtuellen Festplatten kommen von Unit 1. Wir sprechen hier von einem Datenbestand von ca. 750GB mit 20% Wachstum pro Jahr.
Für die Sicherung der VM´s und der Daten des Fileservers will ich einen HP DL380G4 einsetzen mit einem Qlogic HBA und BackupExec 12.5 mit 2 Vmware-Agents (für 2 Vmware ESX-Hosts).
Welche Möglichkeiten gibt es die Daten des Fileservers zu sichern, außer der Variante, einen Backup-Exec Agent zu installieren und über diesen zu sichern? Brauche ich bei anderen Varianten irgendwelche Agents? Ist dieser Gedanke des virtuellen Fileservers sinnvoll?
Gruß
Mull
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!
File-Server auf ESX 3.5 - Backup-Fragen
vcb verwende ich bereits jetzt zum sichern der virtuellen maschinen. als sicherungsziel verwende ich eine buffalo-terastation. besser als nix. die terastation ist als netzlaufwerk auf dem vcb-windows-server gemappt. genau das soll sich jetzt ändern mit einer bandbibliothek und dem umbau.
wie würde eine vcb-sicherung eines fileservers aussehen. ich sichere den ganzen server täglich? wie kommt die sicherung auf band mit vcb?
mit raw device mapping hab ich mich noch nie richtig beschäftigt. werde ich jetzt mal in der testumgebung angehen.
wie würde eine vcb-sicherung eines fileservers aussehen. ich sichere den ganzen server täglich? wie kommt die sicherung auf band mit vcb?
mit raw device mapping hab ich mich noch nie richtig beschäftigt. werde ich jetzt mal in der testumgebung angehen.
Man sollte sich den backup Vorgang nicht alleine anschauen, die Frage ist auch: Was mache ich im Falle eines Restores? Wenn hauptsächlich Restores auf Fileebene erfolgen, ist ein Backup per VCB eher unangebracht, denn es wird immer die komplette VM gesichert (und diese muss auch komplett wieder hergestellt werden). Es gibt Backup Proxies, die auf dem VCB aufsetzen und Restores auf File Ebene ermöglichen und auch inkrementelle backups ermöglichen aber das geht so per def. nicht mit VCB.
Wie viel Änderungsdaten habt ihr bei jedem Backup? Ein Fileserver mit 750 GB jeden Tag Full zu sichern ist auch nicht wirklich produktiv, wenn die Änderungsdaten nur ein Bruchstück des gesamten Platzes in Anspruch nehmen, ist ein Backup per Backup-Agent durchaus ratsam.
Generell sollte man sich bei Backups immer die wirklichen Erfordernisse anschauen und das Passende auswählen.
Das schöne an VM, man kann sich "rauspicken" was man braucht, z.B. per Snapshot die Systemplatte sichern und per Agent die Datenplatte sichern.
Wie kommt die Sicherung per VCB auf Band? Das ist dein Problem
VCB liefert nur den Mechanismus wie die VM vom ESX rauskommt, wo diese dann landet ist Sache des Backup Programms, mittlerweile liefern die großen Hersteller so genannte VCB Integratoren, so dass man Backups über die gewohnte GUI starten kann und diese dann den VCB Mechanismus starten. Am einfachsten sind natürlich explizite Lösungen, die sich zwischen VMware und dem Backupsystem "klemmen", da hängt es aber vom Budget und von der verwendeten BAckup Lösung welches man wählt.
Zwei Kandidaten sind das verbreitete vRanger oder das relativ unbekannte aber durchaus empfehlenswerte IcCider.
Wie viel Änderungsdaten habt ihr bei jedem Backup? Ein Fileserver mit 750 GB jeden Tag Full zu sichern ist auch nicht wirklich produktiv, wenn die Änderungsdaten nur ein Bruchstück des gesamten Platzes in Anspruch nehmen, ist ein Backup per Backup-Agent durchaus ratsam.
Generell sollte man sich bei Backups immer die wirklichen Erfordernisse anschauen und das Passende auswählen.
Das schöne an VM, man kann sich "rauspicken" was man braucht, z.B. per Snapshot die Systemplatte sichern und per Agent die Datenplatte sichern.
Wie kommt die Sicherung per VCB auf Band? Das ist dein Problem
VCB liefert nur den Mechanismus wie die VM vom ESX rauskommt, wo diese dann landet ist Sache des Backup Programms, mittlerweile liefern die großen Hersteller so genannte VCB Integratoren, so dass man Backups über die gewohnte GUI starten kann und diese dann den VCB Mechanismus starten. Am einfachsten sind natürlich explizite Lösungen, die sich zwischen VMware und dem Backupsystem "klemmen", da hängt es aber vom Budget und von der verwendeten BAckup Lösung welches man wählt.
Zwei Kandidaten sind das verbreitete vRanger oder das relativ unbekannte aber durchaus empfehlenswerte IcCider.
Wir werden BackupExec 12.5 verwenden mit 2 ESX-Host-Lizenz. Somit habe ich den Anschluss an die Tape-Library, Agent-Sicherung und Vmware-Sicherung der kompletten Maschinen.
Dann natürlich Differenz-Sicherungen vom File-Server.
Somit dürfte dann alles abgesichert sein.
Ich bin mir halt noch nicht ganz sicher in Sachen:
-Fileserver auf Vmware
-welcher Festplattenmodus (VMDK o. RDM)
-Zeitfenster für Backup
Dann natürlich Differenz-Sicherungen vom File-Server.
Somit dürfte dann alles abgesichert sein.
Ich bin mir halt noch nicht ganz sicher in Sachen:
-Fileserver auf Vmware
-welcher Festplattenmodus (VMDK o. RDM)
-Zeitfenster für Backup
mullfreak hat geschrieben:
Ich bin mir halt noch nicht ganz sicher in Sachen:
-Fileserver auf Vmware
-welcher Festplattenmodus (VMDK o. RDM)
-Zeitfenster für Backup
1. hängt von der jetzt verbrauchten Leistung ab. Zugriffe, Bandbreite. Kann man nicht pauschal beantworten. Die Größe alleine (750 GB) ist zunächst irrelevant. Wichtig ist wie die Zugriffe erfolgen. Ich habe hier 2 Fileserver mit ca 200 GB, einer ist physisch als Cluster für ca. 600 GLEICHZEITIGE Benutzer mit Profilen, Homelaufwerken, Daten usw. und ein virtueller der selben Größe für 15 Mitarbeite, von denen vielleicht 5 gleichzeitig arbeiten.
2. Was ich bisher gelesen habe, gibt es inzwischen wenig Gründe für RDM und gegen VMDK, auch eine VMDK lässt sich auf den SAN so konfigurieren, das sie der VM exclusiven Zugriff ermöglicht, dazu benötigt man kein RDM. Von der Perfomance her würde ich sagen, dass es inzwischen keine Unterschied machen sollte. Aber ich denke da gibt es auch andere Meinungen. Google mal ein wenig nach "RDM vs VMDK", da sind interessante Artikel zu finden.
3. Zeitfenster ist wie bisher, dann wenn am wenigsten los ist
Hi,
ich habe hier eien Fileserver als VM laufen. Festplattenmodus als VDMK. Die Kiste läuft ohne Probleme.
Backup ist bei uns wie folgt organisiert:
1. Backup Exec sicher die Daten (Zuwachs und Vollsicherung in bestimmten Intervallen)
2. vRanger sicher die gesamte VM alle x Wochen
Gruß Peter Leitner
ich habe hier eien Fileserver als VM laufen. Festplattenmodus als VDMK. Die Kiste läuft ohne Probleme.
Backup ist bei uns wie folgt organisiert:
1. Backup Exec sicher die Daten (Zuwachs und Vollsicherung in bestimmten Intervallen)
2. vRanger sicher die gesamte VM alle x Wochen
Gruß Peter Leitner
philipp24 hat geschrieben:schreib bitte deine Erfahrungen wenn du den Fileserver virtualisiert hast. Arbeite auch gerade an dem Projekt dürfte bei uns aber noch etwas dauern.
danke
Da gibt es nichts zu erzählen, es läuft einfach
, aber den großen Fileserver für 600 User habe ich ja auch noch nicht virtualisiert, da gäbe es evtl. mehr zu erzählen, aber da bleibe ich lieber beim MS Cluster, reines Bauchgefühl.du wirst um eine Analyse deiner Umgebung nicht herum kommen. Werf den perfmon an und log solche Sachen wie HD Utilization, Netzwerklast, cpu last usw. über einen längeren Zeitraum. Dann hast du Parameter mit denen du was anfangen kannst. Gerade Fileserver sind Systeme mit einer unendlichen Bandbreite an unterschiedlichen Anforderungen. mein Ansatz wäre: "Warum sollte das unter VMware nicht laufen". Letztendlich wird m.E. der Storage und Netzwerk die Grenzen aufweisen und nicht das VMware System.
Ja, OK. Das Projekt steht jetzt grad im Invest-Antrag, d. h. es wird noch etwas dauern. Bisher haben wir einen Server virtualisiert du ca. 450 gleichzeitige Verbindungen auf ein Windows-System hat. Der ist für unser KIS (Krankenhaus Informations System) zuständig und bildet soz. den Gateway auf einen HP-UX mit Oracle-DB.
Hier gibts keine Probleme. Der wurde mit dem Converter abgezogen und läuft eigentlich besser als auf der alten Hardware (HP DL380G3 mit XEON und 2.0GB RAM).
Unser Fileserver hatte heute während des Tages immer so um die 550 Sitzungen lt. Sitzungsanzeige in der Computerverwaltung.
Werde jetzt mal wirklich den Perfmon anschmeißen und mal nachsehen was genau da abgeht. Ansonsten könnte man die Daten auch auf mehrere Server verteilen, das wäre immerhin noch ein Ansatz. Die Migration wird eh nicht übers WE zu machen sein, so könnte man auch unterm Projekt Flaschenhälse erkennen.
An PeterDA:
Bezüglich der Sicherung mit BackupExec hätte ich noch folgende Fragen:
-wieviel GB oder TB an Daten hast Du?
-auf welchem Storage befinden sich die VMDK´s (iSCSI oder FC?)
-welche Festplatten hat das Storage (SAS oder SATA?)
-welchen RAID-Level benutzt Du für die VMDK´s des Fileservers?
-wie lange benötigt eine Vollsicherung?
-wie lange benötigt eine Zuwachssicherung (inkrementell oder differenziell)?
Gruß
Mull
p.s. natürlich werde ich berichten was abgeht
Hier gibts keine Probleme. Der wurde mit dem Converter abgezogen und läuft eigentlich besser als auf der alten Hardware (HP DL380G3 mit XEON und 2.0GB RAM).
Unser Fileserver hatte heute während des Tages immer so um die 550 Sitzungen lt. Sitzungsanzeige in der Computerverwaltung.
Werde jetzt mal wirklich den Perfmon anschmeißen und mal nachsehen was genau da abgeht. Ansonsten könnte man die Daten auch auf mehrere Server verteilen, das wäre immerhin noch ein Ansatz. Die Migration wird eh nicht übers WE zu machen sein, so könnte man auch unterm Projekt Flaschenhälse erkennen.
An PeterDA:
Bezüglich der Sicherung mit BackupExec hätte ich noch folgende Fragen:
-wieviel GB oder TB an Daten hast Du?
-auf welchem Storage befinden sich die VMDK´s (iSCSI oder FC?)
-welche Festplatten hat das Storage (SAS oder SATA?)
-welchen RAID-Level benutzt Du für die VMDK´s des Fileservers?
-wie lange benötigt eine Vollsicherung?
-wie lange benötigt eine Zuwachssicherung (inkrementell oder differenziell)?
Gruß
Mull
p.s. natürlich werde ich berichten was abgeht
Hi mullfreak,
geht so um rund 1TB mal mehr mal weniger Datenmengen schwanken Projektbedingt stark. Daher dauert die Zuwachssicherung auch unterschiedlich teilweise sind 200-300GB neu. Ob inkrementell oder differenziell aknn ich leider gerade nicht sagen... Da wir gerade auf 12.5 Updaten kann ich von meiner Kiste nicht auf die Konsole zugreifen um zu schauen wie lange die Komplettsicherung dauert.
Storage ist ein iSCSI - Netapp mit SATA und DP (sowas wie RAID 6 nur anderst, wie NetApp immer wieder sagt..)
VMs mit VDMK Dateien
geht so um rund 1TB mal mehr mal weniger Datenmengen schwanken Projektbedingt stark. Daher dauert die Zuwachssicherung auch unterschiedlich teilweise sind 200-300GB neu. Ob inkrementell oder differenziell aknn ich leider gerade nicht sagen... Da wir gerade auf 12.5 Updaten kann ich von meiner Kiste nicht auf die Konsole zugreifen um zu schauen wie lange die Komplettsicherung dauert.
Storage ist ein iSCSI - Netapp mit SATA und DP (sowas wie RAID 6 nur anderst, wie NetApp immer wieder sagt..)
VMs mit VDMK Dateien
Ich hatte kürzlich Gelegenheit, auf einer jungfräulichen DS3400 die verschiedenen Filesysteme und auch virtuell/physikalisch zu vergleichen. Dabe habe ich eine Reihe von Messungen mit IOmeter gemacht und einige Kopieraktionen dürchgeführt (robocopy eines Verzeichnisses mit 13 GB in 130000 unterschiedlich großen Dateien)...
Zum Thema RDM oder VMFS: Die Performance-Unterschiede dürften im Normalbetrieb eher vernachlässigbar sein. Mir scheint aber, als ob das RDM umso besser liegt, je mehr man die IOps an die Grenze treibt. Weiterer Vorteil eines RDM: Man ist aus der Nummer schneller wieder raus, wenn sich die Virtualisierung als Sackgasse erweisen sollte.
Ansonsten ist mein Eindruck, dass der physikalische Fileserver nicht nur bei extremen Anforderungen, sondern auch im Normalbetrieb fühlbar im Vorteil ist. Zahlen nenne ich lieber nicht, da meine Benchmarks sicherlich nicht wirklich belastbar sind und VMware das meines Wissens auch untersagt. Virtualisierung bedeutet nicht vernachlässigbare Performanceverluste - das ist jedenfalls meine Erfahrung. Wenn man damit leben kann und die Vorteile überwiegen...
Zum Schluss nur noch die Anmerkung, dass ich eigentlich eher zu denen zähle, die alles virtualisieren, was nicht bei Drei aufm Baum ist... Und da das eigentliche Thema ja Backup war: Nutzerdaten _immer_ auf Dateiebene mit einem entsprechenden Agent und nicht mit VMware-Mitteln sichern.
Georg.
Zum Thema RDM oder VMFS: Die Performance-Unterschiede dürften im Normalbetrieb eher vernachlässigbar sein. Mir scheint aber, als ob das RDM umso besser liegt, je mehr man die IOps an die Grenze treibt. Weiterer Vorteil eines RDM: Man ist aus der Nummer schneller wieder raus, wenn sich die Virtualisierung als Sackgasse erweisen sollte.
Ansonsten ist mein Eindruck, dass der physikalische Fileserver nicht nur bei extremen Anforderungen, sondern auch im Normalbetrieb fühlbar im Vorteil ist. Zahlen nenne ich lieber nicht, da meine Benchmarks sicherlich nicht wirklich belastbar sind und VMware das meines Wissens auch untersagt. Virtualisierung bedeutet nicht vernachlässigbare Performanceverluste - das ist jedenfalls meine Erfahrung. Wenn man damit leben kann und die Vorteile überwiegen...
Zum Schluss nur noch die Anmerkung, dass ich eigentlich eher zu denen zähle, die alles virtualisieren, was nicht bei Drei aufm Baum ist... Und da das eigentliche Thema ja Backup war: Nutzerdaten _immer_ auf Dateiebene mit einem entsprechenden Agent und nicht mit VMware-Mitteln sichern.
Georg.
@PeterDA
Was machst Du bei einem Komplettausfall der NetApp?
Warum hast Du nicht die CIFS-Option der NetApp genutzt?
@GTMK
In Bezug auf die Sicherung gebe ich Dir vollkommen recht. Wir werden weiter mit den Agents arbeiten wie gehabt und zusätzlich mit BackupExec 12.5 und den Vmware Agents die virtuellen Maschinen sichern. So bleibt alles in einer Software. Die Kollegen bedienen es seit Jahren und sind mit der Oberfläche vertraut.
Was machst Du bei einem Komplettausfall der NetApp?
Warum hast Du nicht die CIFS-Option der NetApp genutzt?
@GTMK
In Bezug auf die Sicherung gebe ich Dir vollkommen recht. Wir werden weiter mit den Agents arbeiten wie gehabt und zusätzlich mit BackupExec 12.5 und den Vmware Agents die virtuellen Maschinen sichern. So bleibt alles in einer Software. Die Kollegen bedienen es seit Jahren und sind mit der Oberfläche vertraut.
Hi Mulfreak,
Da die NetApp ein Clusterversion ist halte ich das Risiko für überschaubar. Was ich mach wenn es trotozdem passiert: Telefonauschalten und warten bis NetApp da ist...
Alle VMs liefen vorher auf Hardwarekisten und die haben wir einfahc per Converter auf die ESX gezogen. Wenn ich mal Zeit habe steht das an.
Gruß Peter
Was machst Du bei einem Komplettausfall der NetApp?
Da die NetApp ein Clusterversion ist halte ich das Risiko für überschaubar. Was ich mach wenn es trotozdem passiert: Telefonauschalten und warten bis NetApp da ist...
Warum hast Du nicht die CIFS-Option der NetApp genutzt?
Alle VMs liefen vorher auf Hardwarekisten und die haben wir einfahc per Converter auf die ESX gezogen. Wenn ich mal Zeit habe steht das an.
Gruß Peter
OK, ebenso hier. Wenn das Storage mal den Geist aufgibt, dann hoffe ich, ich bin weit weg in Urlaub oder so.
Eine Metro-Cluster war leider nicht drin.
Das hätte das Budget bei weitem gesprengt. Als Ausfallsicherheit habe ich jetzt die Backups von VCB. Die wichtigsten Server müsste ich dann auf anderen Geräten zum rennen kriegen.
Gruß
Mull
Eine Metro-Cluster war leider nicht drin.
Das hätte das Budget bei weitem gesprengt. Als Ausfallsicherheit habe ich jetzt die Backups von VCB. Die wichtigsten Server müsste ich dann auf anderen Geräten zum rennen kriegen.
Gruß
Mull
mullfreak hat geschrieben:OK, ebenso hier. Wenn das Storage mal den Geist aufgibt, dann hoffe ich, ich bin weit weg in Urlaub oder so.
Eine Metro-Cluster war leider nicht drin.
Gruß
Mull
PeterDA hat geschrieben:Hi,
das sehe ich auch so! Zumal ein metrocluster für mich nur dann wirklich Sinn machen würde, wenn ich auch zwei räumlich getrennte Serverräume hätte um den SPOF möglichst weit weit weit weg zu schieben.
Gruß Peter
Ein Metro Cluster ist schon was schönes, macht aber nicht nur sinn wenn die Storages auseinder stehen. Klar ist ein Backup RZ was Feines, aber ich hab mehr Angst, dass mir mein (altes) Storage um die Ohren fliegt und nicht dass das RZ abbrennt. Obwohl mittlerweile sogar bei der GF angekommen ist, dass ein backup RZ auch von den Wirtschaftsprüfern verlangt wird. Ist also nicht nur ein ITler Problem.
Mich würd mal interessieren wie viele Storages komplett um die Ohren geflogen sind, evtl. sogar mit Datenverlust. Unsere DS4400 läuft seit 5 Jahren durch, und scheint unkaputtbar. Ich seh das aber wie mit nem Erd-Beben oder Vulkanausbruch, der Nächste kommt auf jeden Fall, und je länger man wartet, desto stärker fällt er aus.
Und wenn ich denke, dass ein gesamtes Unternehmen mit mehreren 1000 Mitarbeitern an EINEM Storage hängen (95% virtualisiertes RZ und der Rest hängt auch am Storage), dann sollte ein Metrocluster eigentlich drin sein.
Wir sind gerade dabei sowas wie ein 2. RZ anzurichten. Schön langsam wirds schon. Mehr als einen Schrank werden wir eh nicht vollkriegen.
Ich bin in einem Klinikum beschäftigt und hoffe das in den nächsten Jahren das digitale Archiv Realität wird. Dann MUSS ein gescheiter Storage-Cluster her. Dann schlägt auch die Stunde der Netzwerktechnik!!!
Ich bin in einem Klinikum beschäftigt und hoffe das in den nächsten Jahren das digitale Archiv Realität wird. Dann MUSS ein gescheiter Storage-Cluster her. Dann schlägt auch die Stunde der Netzwerktechnik!!!
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast