VMware-Forum

Hallo,

wir planen unsere aktuelle IT-Umgebung zu virtualisieren (VMWare Server, jeweils W2k3 host und gast).
Ich möchte sie hier kurz skizzieren und Euch bitten ein kurzes Feedback bzw. mögliche Probleme / Erfahrungen zu schildern. Danke vorab.

IST-Situation:
1. Server phy./Standort A: Intel 3 GHz, 2 GB RAM, (W2K3, DC, File-Server)
2. Server phy./Standort A: Intel P3 1 GHz Dual, 1 GB RAM (W2k3, Exchnage)
3. Server phy./Standort A: Intel P4 2.8 GHz, 3 GB RAM (W2k3, SQL, 4 Datenbanken)
4. Server phy./Standort B: AMD Opteron 1,8, 4 GB RAM (Backup) mit REV-Drive

Standort A und B sind per Gigabit Glasfaser verbunden.

SOLL-Situation:
Es wird ein zusätzlicher Backup-Server für Standort A gekauft, der das REV-Drive aus Server 4 erhält und per Arcserve und den entsprechenden Dienst die Bewegungsdaten sichert (Systemstatus für DC recovery, Exchange, SQL) und gleichzeitig als 2. DC läuft (beides auch virtuell).

Desweiteren werden nachts per Batch die VMs der Server 1-3 und dem neuen Backup-Server (tagsüber) auf den Server 4/Standort B kopiert.

Fällt einer der Server 1-3 aus, soll die Maschine auf dem Server 4/Standort B gestartet werden (Stand der VM jeweils die Nacht vor dem Crash).

Werden vom User Daten gelöscht, können diese über das Arcserve zurückgesichert werden (es gibt 5 Wochen-Sätze an Medien). Der Iomega-REV Autoloader kann auch an Server 4 /Standort angeschlossen werden und dort zurückgesichert werden!

Danke und Gruss
Frederik

Hallo Frederik!

Ich setze VMWare Server seit der ersten Beta bei mir ein und auch mittlerweile bei meinen Kunden.

Warum Du, wenn Du bereits alle Server virtualisierst, noch immer ArcServe einsetzt, verstehe ich nicht ganz.
Ich verwende virtuelle Festplatten, was beim Erstellein einer virtuellen HDD ENORM VIEL ZEIT UND RESSOURCEN beansprucht, ABER jede virtuelle HDD kannst Du auch an eine andere virtuelle Maschine anschließen und dadurch Daten aus einem z. B. Backup wiederherstellen. Ich will damit sagen, seitdem ich VMWare Server mit diversesten VMs mit virtuellen HDDs verwende, benötige ich keine Backup-Software mehr (wie ArcServe, Veritas, etc.). Ich benötige nur mehr ein Kopierprogramm (wie XCOPY) und sämtliche Datensicherungen finden mit AutoIt-Scripts statt.

Was ich auch nicht so ganz verstehe bei den heutigen Hardware-Preisen ist, warum man noch Server mit nur 1 GB RAM betreibt. Sämtliche meiner Server habe ich bereits auf 4 GB aufgerüstet und DAS sind Investitionen, die es bringen, egal was für eine Aufgabe der jeweilige Server hat. Und wenn Du dies in jeden Server investierst, dann ist es meiner Meinung nach egal, wo im Störungsfall welche VM läuft: VM umkopieren, VM hochfahren, das wars.

Das Sichern des Systemstatus des ersten DCs fällt bei mir völlig flach, DA ich den ersten DC in einer ganz kleinen VM (meist nur 256-512 MB RAM, 8 GB virtuelle HDD) installiere, nur mit DHCP-Server und DNS-Server UND KEINERLEI Zugriff der Benutzer darauf lasse (z. B. Fileserver). Das Sichern dieses primären DCs dauert ca. 8 min: VM per Skript herunterfahren, VM wegkopieren, VM per Skript hochfahren, alles vom Host aus. Erst auf den zweiten DC lasse ich dann z. B. Filesharing zu. Ist der erste DC defekt (AD defekt etc.) kann ich jederzeit auf die gesicherte VM vom Vortag zugreifen UND man hat ja noch den zweiten (oder dritten) DC, und der dann "alte" erste DC wird synchronisiert mit den anderen DCs und auf den neuesten Stand gebracht.

Die Idee Exchange und Datenbankserver in gesonderten VMs (und natürlich auch auf gesonderten Servern) laufen zu lassen finde ich sehr gut.

Was Du nicht erwähnt hast, ist, wieviele User Du mit diesen 4 Servern versorgst.

Hoffe Dir geholfen zu haben mit meinen Erfahrungen und würde mich über ein weiteres Feedback freuen.

Gruß Peter

Warum Du, wenn Du bereits alle Server virtualisierst, noch immer ArcServe einsetzt, verstehe ich nicht ganz.

Ich schon (abgesehen davon, daß es Arcserve ist - das ist bei mir vor 3 Jahre rausgeflogen). Der OP hat es auch gesagt: Weil ab und an Benutzer Dateien löschen . Virtualisierung ersetzt kein Backup auf Dateiebene, aber es macht Imaging leichter.

Ich benötige nur mehr ein Kopierprogramm (wie XCOPY) und sämtliche Datensicherungen finden mit AutoIt-Scripts statt.

Mit Verlaub: Das ist kein ernsthaftes Backup und allenfalls etwas für Privatanwender, aber nichts für geschäftskritische Daten.

Ist der erste DC defekt (AD defekt etc.) kann ich jederzeit auf die gesicherte VM vom Vortag zugreifen UND man hat ja noch den zweiten (oder dritten) DC, und der dann "alte" erste DC wird synchronisiert mit den anderen DCs und auf den neuesten Stand gebracht.

Hast Du Dein DC-Backup-Konzept mal getestet? Ich fürchte, das funktioniert nicht. Meines Wissens läßt sich ein DC (außer es gibt nur einen) nicht aus einem Image restaurieren, sondern nur aus dem System State-Backup, weil die Replikation aus dem Tritt ist. Du könntest höchstens dem überlebenden DC alle FSMO-Rollen übertragen, den alten DC aus dem AD löschen und einen neuen installieren.

DCs sind hervorragende Kandiaten für VMs. Wie wäre es z.B., auf zwei Maschinen VMware Server zu installieren und die DCs komplett zu virtualisieren? Zwei DC-Gäste, einer auf jedem VMware Server, die nichts weiter machen als AD, DHCP und DNS, und den Fileserver auch nichts anderes machen zu lassen als Fileserver? Ich bevorzuge eine Trennung der Zuständigkeiten...

Mein Exchange ist auch eine VM, allerdings unter ESX. Keine Probleme damit.

Grüße, Georg.

Grundsätzlich verkaufe ich nichts, was ich nicht auch selbst ausgetestet habe.

Und ich kann Dir versichern, das Konzept mit einem virtuellen ersten DC, der im ausgeschaltetem Zustand wegkopiert wird und im Fehlerfall wieder zurückkopiert und wieder hochgefahren wird, funktioniert BESTENS, WESENTLICH BESSER, als jeder Restore einer Backup-Software des System-States im Verzeichnisdienstwiederherstellungsmodus. Ich habe sämtliche dieser Erfahrungen gemacht und bin aus dieser Erfahrung zu diesem, jetzigen Konzept gekommen, und seitdem kann ich beruhigt schlafen.

Zu Arcserve:

SEHR WOHL (!!!!!!!) kann man aus einer virtuellen HDD angeschlossen an eine x-beliebige VM mit gleichem OS AUF DATEIEBENE OHNE Backup-Software sich Daten wiederherstellen: Man richtet sich eine VM NUR für solch einen Fall ein, schließt die virtuelle HDD AUS EINEM BACKUP VOM z. B. VORTAG an diese VM an und BINGO ich kann auf die Dateien zugreifen, ob das nun die Datenbank eines Exchange-Servers oder SQL-Servers oder ein simpler Word-Brief eines Benutzers ist, ICH KANN OHNE Arcserve, Veritas, etc. AUF DATEIEBENE DARAUF ZUGREIFEN!!! Man muß halt ein wenig nachdenken...

Mit Verlaub: Ein ernsthaftes Backup ist für mich einen brauchbaren IST-Zustand SO RASCH ALS MÖGLICH wiederherzustellen. Und nochmal mit Verlaub: einen heruntergefahrenen Server, egal ob DC, Exchange-Server, SQL-Server, waseweißichnochwas, wegzukopieren (einschließlich seiner virtuellen HDDS) ist das Gleiche, wie den Server auszuschalten und in einen Tresor zu stellen, ihn im Fehlerfall herauszunehmen und wieder einzuschalten, was in großen Unternehmen mit Stammzertifikaten auf z. B.: Notebooks oder USB-Sticks geschieht.. Was ist da falsch oder "nur für Privatanwender" an solch einem Backup???? Ein ernsthaftes Backup sagt nicht aus, welches Medium oder welche Software ich für ein Backup benutzen muß, bei einem ernsthaftem Backup muß ich die Daten wiederherstellen können, egal wie.

An diejenigen, die dieses Konzept kritisieren: Ich bin über jede Art von Kritik sehr dankbar, ABER bevor jemand sagt, das geht nicht oder das ist nicht ernsthaft: er möge sich hinsetzen, darüber nachdenken und es ausprobieren, die VMs machen es möglich.

Ich weiß, dass es bestens funktioniert.

Gruß Peter

solange das dc image nicht zu alt ist, wird es funktionieren. es kann aber durchaus zu replikations problemen kommen, im normalfall sind diese aber lösbar.

seitens microsoft bekommt man dafür aber keinerlei support. sicherheitshalber würde ich deshalb täglich oder zumindestens 1x pro woche per ntbackup zusätzlich einen systemstate des dc´s speichern.

Hi,

zur Backup-Thematik noch eine Anmerkung:

Nachteil bei der Sicherung der VMDK-Dateien: Ich muss immer die komplette (virtuelle) Platte sichern. Differentielle oder inkrementelle Backups sind nicht möglich (evtl. gibts Zusatzsoftware von Drittanbietern) => Backup-Zeit und v.a. Platzbedarf ist um einiges größer.

Statt dem Einbinden der VMDK-Sicherung in eine VM gibts noch die Möglichkeit, das Disk Mount Utility von VMware zu nutzen. Das bindet eine VMDK-Datei auf Windows-Ebene als Laufwerk ein (egal ob in einer VM oder Physikalische Maschine).

Insgesamt haben die Backup-Strategien unterschiedliche Vor-und Nachteile. Ich kann mir gut vorstellen, ArcServe innerhalb der VMs zu verwenden (und die Virtualisierung beim Backup außen vor zu lassen), wenn ich mich damit gut auskenne, die Prozesse im Unternhemen etabliert sind, Lizenzen vorhanden usw.


Viele Grüße,
Jörg

Hallo Peter,

ABER bevor jemand sagt, das geht nicht oder das ist nicht ernsthaft: er möge sich hinsetzen, darüber nachdenken und es ausprobieren, die VMs machen es möglich.

Du kannst mir glauben, daß ich mir über Backup-Konzepte schon ziemlich lange ziemlich viele Gedanken gemacht habe. Und ich habe nicht gesagt, das geht nicht. Aber daß eine Skripting-Lösung mit xcopy für geschäftskritische Daten nicht geeignet ist - dabei bleibe ich, weil ich es, auch wenn Du hervorragend skripten kannst, für zu fehleranfällig halte.

Mit Verlaub: Ein ernsthaftes Backup ist für mich einen brauchbaren IST-Zustand SO RASCH ALS MÖGLICH wiederherzustellen.

Das ist nur ein Teilaspekt, Backup umfaßt weit mehr als das. Dazu gehört nicht nur das Vorhalten der Daten in mehreren Generationen, sondern auch die Möglichkeit, die zuückzusichernden Dateien schnell zu finden. Stell Dir vor, Dein Geschäftsführer kommt zu Dir und braucht eine wichtige Präsentation, die er auf dem Fileserver nicht mehr findet. Er weiß nur noch fragmentarisch, wie die Datei hieß und seit wann sie verschwunden ist. Sein Zug geht in einer Stunde. Was jetzt?

Du kannst möglicherweise eine Lösung skripten, die das leistet. Aber sie wird aufwendig und daher fehleranfällig sein, weil Du dafür eine leistungsfähige Datenbank brauchst und die entsprechenden Prozeduren und Schnittstellen.

Wir setzen TSM ein. Ich gebe zu, das ist eine Liga, die erst ab einer bestimmten Größe einen Sinn macht. Mein Fileserver wird zweimal täglich gesichert, alte Versionen 2 Monate vorgehalten, die einzige Version einige Jahre. Wenn ein Benutzer genau weiß, welche Datei er zurück möchte, ist sie wieder auf dem Fileserver, noch bevor er aus der Tür ist, sofern sie noch im Diskcache liegt. Wenn nicht, dauert es halt etwas länger, aber der Geschäftsführer bekommt seinen Zug noch - mit der Datei.

Bei statistischen Daten wie den von Dir genannten Stammzertifikaten ist eine Kopie okay und die gehört in den Tresor. Aber bei dynamischen Datenbeständen? Exchange? SQL?
Exchange läßt sich bekanntlich so konfigurieren und mit ntbackup so sichern, daß bei Datenbankverlust nicht eine einzige E-Mail verlorengeht. Verzeihen Dir Deine Kunden, wenn Du in so einem Fall die Maschine aus dem Tresor holst und die Mails des letzten Tages fehlen?

Datensicherheit ist wie eine Versicherung: You get what you pay for. Willst Du höhere Sicherheit, mußt Du höhere Prämien bezahlen.

Grundsätzlich verkaufe ich nichts, was ich nicht auch selbst ausgetestet habe.

Okay, das erwarte ich auch. Entschuldige, wenn ich Dir da zu nahe getreten bin. Aber Du kannst nicht alle möglichen Szenarien, die im Feld auftreten können, austesten. Das ist das Problem bei - man verzeihe mir die Wortwahl - Bastellösungen.

Beste Grüße.

Georg.

Hallo,

wie schätzt Ihr die Lösung ein, ein Exchange-Server, der in einer DMZ läuft, auf einem Server mit anderen VMs (aus dem richtigen LAN) zusammenlaufen zu lassen?!?

Danke vorab.

Gruss
Frederik

Das sollte kein Problem darstellen, und ich denke, daß es ein recht häufiges Szenario ist. Mir ist nicht bekannt, daß allein über den Host Daten aus einem Netzwerksegment in ein anderes diffundiert wären.

Ich würde dafür aber eher ESX einsetzen. Bei VMware Server unter Windows sollte ausschließlich das VMware-Protokoll an die Netzkarte gebunden, die in der DMZ hängt, nicht aber TCP/IP usw. Der Host sollte mit mindestens 3 Netzkarten ausgestattet sein: Je eine in jedes Netzwerksegment, über die die Gäste mit der Außenwelt kommunizieren, und eine für den Host selbst (die Service Console in ESX).

Grüße, Georg.