Hallo zusammen,
ich setze VMware 4.52 für folgende Zwecke ein:
1.) Mein WebServer im Keller (Linux2.6-VM) mit IpCop (Linux2.4-VM) auf Linux2.6 Host (Debian)
2.) W2kServer mit Microsoft VC6.0++ als VM auf Linux2.6 Host (Debian) als Cross-Develope-System für Linux
3.) W98 als VM für DSO2000 (spez. Hardware/Software die nicht unter Linux/NT läuft)
Das allgemeine Verhalten, was wohl jeder kennt ist doch, das sich zu 99% nach einem Systemabsturz ein Windows oder Linux wieder booten lässt.
Nicht so bei virtuellen Festplatten von VMware, hier ist ja eine Schicht mehr vorhanden. Das beste Journal-FS nützt hier wohl nichts. Da ich die Problematik kenne, habe ich immer eine Datensicherung der VM's, bei Änderungen an den VM's ziehe ich direkt wieder eine neue Dasi. Alle Hosts bei mir laufen mit RAID1. Nutzdaten befinden sich mit einer einzigen Ausnahme (DMZ) nur auf den Host-Rechnern (SAMBA, NFS. ...).
Meine Frage an alle die hier schon Erfahrung gesammelt haben.
1.) Ist ein Gast auf einer phys. Partition hier stabiler ???
2.) Gibt es andere Möglichkeiten hier mehr Stabilität einzubauen ???
3.) Hat jemand schon mal einen Linux-Gast mit 2 phys. Platten und Software-Raid1 eingerichtet und hilft das ???
PS: Ich hatte schon zweimal einen Stromausfall (ganzer Straßenzug) und jeden mal kam mein WebServer nicht mehr von alleine hoch.
Mauze
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!
Stabilität von virtuellen Festplatten
Das allgemeine Verhalten, was wohl jeder kennt ist doch, das sich zu 99% nach einem Systemabsturz ein Windows oder Linux wieder booten lässt.
Nicht so bei virtuellen Festplatten von VMware, hier ist ja eine Schicht mehr vorhanden. Das beste Journal-FS nützt hier wohl nichts.
Kann ich so für NTFS nicht bestätigen. Wenn ich meine XP-NTFS-VM nicht herunterfahre, sondern direkt beende, was einem direkten Reset unter einer physischen Maschine entspricht, dann startet diese VM-XP-NTFS bei nächsten Mal wieder klaglos. Das liegt allein daran, dass die Journaling-FS-Funktionen von NTFS unter VMware genauso wirksam sind wie unter einer physischen Maschine.
Mich wundert das auch nicht, weil das Dateisystem ja nicht hardwarebezogen ist.
ich kann das auch nicht nachvollziehen - meine maschinen (egal ob windows- oder linux-gast mit ntfs, reiserfs, ext3 oder jfs auf einem xp-host mit ntfs) kamen alle stehts ohne probleme wieder ans rennen. von software-raid kann ich nur abraten - raid1 hatte ich allerdings in software noch nie ausprobiert. ich glaube auch nicht, das raw-partitionen bessere ergebnisse bringen - sicher ist da dann eine logische schicht weniger zwischen, die frage ist aber: welches dateisystem läuft auf dem webserver? ntfs ist reichlich stabil, eine ähnlich hohe recover-rate wirst du inter linux nur mit ext3 bekommen (reiserfs, jfs und xfs jounalisieren ausschließlich metadaten (mode = writeback), ext3 journalisiert in einem zwischenschritt auch den inode der neuen nutzdaten (mode = data ordered) - oder wenn man es noch sicherer will alle meta- und nutzdaten (mode = data journal).
mein tip: falls du reiserfs nutzt, probier mal ext3 im standardmodus (data = ordered) - das ist stabiler als reiserfs und nicht sooo lahm wie der mode = data journal.
mfg
looping
mein tip: falls du reiserfs nutzt, probier mal ext3 im standardmodus (data = ordered) - das ist stabiler als reiserfs und nicht sooo lahm wie der mode = data journal.
mfg
looping
- continuum
- UNSTERBLICH(R.I.P.)
- Beiträge: 14759
- Registriert: 09.08.2003, 05:41
- Wohnort: sauerland
- Kontaktdaten:
Ich kann mich nur franzkat und looping anschliessen.
Bei der Frage ob eine raw-disk stabiler ist als eine standard-vmdk wuerde ich sagen - theoretisch ja - in der Praxis aber nur in dem Fall wenn man zB einen Linuxhost verwendet und einen Windowsgast in einer raw-disk hat oder umgekehrt.
Bei einem Windowsgast bei Windowshost sind raw-disks eher problematischer, da es nicht so einfach ist dem Host ein checkdisk der raw-disk zu verbieten.
Probleme nach Abstuerzen kenne ich eigentlich nur vin Win9x und in einem einzigen Fall bei FreeBSD mit damals experimentellen Soft-updates (BSD-Variante von Journaling FS)
Bei der Frage ob eine raw-disk stabiler ist als eine standard-vmdk wuerde ich sagen - theoretisch ja - in der Praxis aber nur in dem Fall wenn man zB einen Linuxhost verwendet und einen Windowsgast in einer raw-disk hat oder umgekehrt.
Bei einem Windowsgast bei Windowshost sind raw-disks eher problematischer, da es nicht so einfach ist dem Host ein checkdisk der raw-disk zu verbieten.
Probleme nach Abstuerzen kenne ich eigentlich nur vin Win9x und in einem einzigen Fall bei FreeBSD mit damals experimentellen Soft-updates (BSD-Variante von Journaling FS)
Bei einem Windowsgast bei Windowshost sind raw-disks eher problematischer, da es nicht so einfach ist dem Host ein checkdisk der raw-disk zu verbieten.
VMware empfiehlt ja deshalb in seiner Hilfe sogar, das Laufwerk in der Datenträgerverwaltung des Host ganz auszuhängen, um unerwünschte Parallellzugriffe mit im ungünstigen Fall fatalen Folgen zu vermeiden.
Hallo Leute,
erst mal Danke für Eure Meinungen.
Evtl. habe ich mich etwas falsch ausgedrückt, wenn ich einen Gast im Ruhezustand (tut sein einigen Minuten nichts oder nur wenig) hart beende, dann kommt dieser auch zu 99% wieder hoch. Das Problem entsteht meiner Meinung nach verstärkt, wenn der Wirt und die Gäste unter Dampf sind, und dann hart beendet werden (egal ob durch Stromausfall oder Absturz).
kann ich nicht ganz nachvollziehen, seit dem ich mal IBM-Platten (IL35-Serie - Schrott vom feinsten) hatte benutze ich Softraid unter Linux für jeden Host. Ist zwar etwas kompliziert beim einrichten, bringt aber Performance (Lesezugriffe) und Sicherheit. Da ich Swap auch als Raid einrichte, kann im laufenden Betrieb eine Platte entfernt werden - die Büchsen booten ohne Eingriff wieder - Dann neue Platte einbauen, partitionieren, Bootloader manuell schreiben und Softsysnc starten.
Aber zurück zum Thema:
Mit Windows Wirten habe ich dies bezüglich keine Erfahrungen, habe ich nur mal zum Test aufgesetzt. Ich setze keine Windows Wirte ein, weil ich unter Windows mit Bordmitteln und ohne spez. Hardware keine gespiegelten und bootfähige Software-Raids einrichten kann.
Ich denke das looping hier evtl. den Nagel (fast) auf dem Kopf getroffen hat, alle meine Wirte und Gäste haben mit der Ausnahme von /boot (ext2) grundsätzlich und damit auch im WebServer das Hans Reiser FS.
-Evtl. hat hier jemand mehr Erfahrungen zum Unterschied von EXT3, ReiserFS und anderen Journaling-FS, dann bitte posten.
Ich werde hier mal (dauert aber ein paar Tage) auf EXT3 wechseln, oder hat einer einen besseren Vorschlag ???
PS: raw-disks möchte ich wegen der damit verbundenen Probleme eigentlich nicht nutzen.
Danke Mauze
erst mal Danke für Eure Meinungen.
Evtl. habe ich mich etwas falsch ausgedrückt, wenn ich einen Gast im Ruhezustand (tut sein einigen Minuten nichts oder nur wenig) hart beende, dann kommt dieser auch zu 99% wieder hoch. Das Problem entsteht meiner Meinung nach verstärkt, wenn der Wirt und die Gäste unter Dampf sind, und dann hart beendet werden (egal ob durch Stromausfall oder Absturz).
looping: von software-raid kann ich nur abraten - raid1 hatte ich allerdings in software noch nie ausprobiert
kann ich nicht ganz nachvollziehen, seit dem ich mal IBM-Platten (IL35-Serie - Schrott vom feinsten) hatte benutze ich Softraid unter Linux für jeden Host. Ist zwar etwas kompliziert beim einrichten, bringt aber Performance (Lesezugriffe) und Sicherheit. Da ich Swap auch als Raid einrichte, kann im laufenden Betrieb eine Platte entfernt werden - die Büchsen booten ohne Eingriff wieder - Dann neue Platte einbauen, partitionieren, Bootloader manuell schreiben und Softsysnc starten.
Aber zurück zum Thema:
Mit Windows Wirten habe ich dies bezüglich keine Erfahrungen, habe ich nur mal zum Test aufgesetzt. Ich setze keine Windows Wirte ein, weil ich unter Windows mit Bordmitteln und ohne spez. Hardware keine gespiegelten und bootfähige Software-Raids einrichten kann.
looping: welches dateisystem läuft auf dem webserver?
Ich denke das looping hier evtl. den Nagel (fast) auf dem Kopf getroffen hat, alle meine Wirte und Gäste haben mit der Ausnahme von /boot (ext2) grundsätzlich und damit auch im WebServer das Hans Reiser FS.
-Evtl. hat hier jemand mehr Erfahrungen zum Unterschied von EXT3, ReiserFS und anderen Journaling-FS, dann bitte posten.
Ich werde hier mal (dauert aber ein paar Tage) auf EXT3 wechseln, oder hat einer einen besseren Vorschlag ???
PS: raw-disks möchte ich wegen der damit verbundenen Probleme eigentlich nicht nutzen.
Danke Mauze
es gibt eine hervorragende file-system-reihe in der ibm-knowledge-base. insgesamt sind das bestimmt 10 artikel von daniel robbins (den ex gentoo ceo) über dieverse journalisierende dateisysteme, deren modi, vor- und nachteile. den ext3-artikel hab ich dir mal rausgesucht - guckst du hier.
mfg
looping
mfg
looping
standardmäßig nutze ich reiserfs 3.6, bei wichtigeren sachen ext3 (standard, also data=ordered), experimentel jfs und reiserfs 4. ich habe mal mit dem ext3-modi data=journal rumgespielt - die performance geht tierisch in den keller. da ich bis heute noch keine probleme mit der datensicherheit hatte/habe, habe ich mich aber nicht eingehender damit beschäftigt.
meist lege ich zudem eine große root-partition an - bei meinem backup-server habe ich allerdings eine klassische linux-partitionierung mit eigener /boot, /, /var, /usr, /tmp und /home sowie den eingehängten backup-platten (/data) angelegt. /boot ist da ext2, /data ext3, der rest reiserfs. meiner meinung nach ist das aber nicht wirklich notwendig - ich tendiere eher dazu eine relativ kleine systemplatte (bis max. ~10gb) mit einer großen, allumfassenden root zu belegen und die datenplatten in eigenen mountpoints anzuhängen. ist dann was drann, ist die systemplatte schnell recovert (image) bzw. neu installiert und die daten bekommen davon gar nichts mit. ärger mit überlaufenden log-files oder einem aus den nähten platzendem /tmp hatte ich noch nie.
mfg
looping
meist lege ich zudem eine große root-partition an - bei meinem backup-server habe ich allerdings eine klassische linux-partitionierung mit eigener /boot, /, /var, /usr, /tmp und /home sowie den eingehängten backup-platten (/data) angelegt. /boot ist da ext2, /data ext3, der rest reiserfs. meiner meinung nach ist das aber nicht wirklich notwendig - ich tendiere eher dazu eine relativ kleine systemplatte (bis max. ~10gb) mit einer großen, allumfassenden root zu belegen und die datenplatten in eigenen mountpoints anzuhängen. ist dann was drann, ist die systemplatte schnell recovert (image) bzw. neu installiert und die daten bekommen davon gar nichts mit. ärger mit überlaufenden log-files oder einem aus den nähten platzendem /tmp hatte ich noch nie.
mfg
looping
NACHTRAG VON MAUZE: ACHTUNG, dieser Artikel ist fehlerhaft
(persistent bezieht sich nicht auf die gleichnamige Einstellung aus VMware, Nachtrag siehe weiter unten zum Thema)
Hallo zusammen,
ich habe mal etwas gelesen, überlegt und auch experimentiert.
Meiner Meinung nach macht ein Journal-FS im Gast überhaupt keinen Sinn, wenn die virtuelle Platte im Wirt nicht "Independent->Persistent" konfiguriert ist.
Einträge die mit Priorität in das Journal der virtuellen Platte durch den Gast geschrieben werden, werden ansonsten bei nicht persistenter Einstellung durch den Wirt gepuffert. Dies führt zum Absurdum und macht keinen Sinn. Die VMware Kern-Treiber für die virtuellen Platten erhalten beim schreiben ja keine Informationen über die Priorität des Schreibvorgangs. Anbetrachts dieser Tatsache werde ich in Zukunft wichtige virtuelle Maschinen auf zwei virt. Platten aufteilen. Eine persistent und damit sehr langsam, die andere nicht persistent und schnell.
Beispiel WebServerKeller
PERSISTENT: Root und Progs (Webserver, PHPBB2, ...)
NON-PERSISTENT: Temp, WebServer-Dynamic-Data, MySql-DB for PHPBB2, ...
zyklisch erfolgt dann eine Datensicherung der Laufzeitdaten von non-persistent nach persistent.
Mauze
XFS was sonst. XFS ist extrem schnell und zuverlässig und kann ACL und Quota reiser4 kann das nicht. Zum Umgang mit dem Dateisystem sind die xfsprogs führend. XFS Reparieren ( bei unsauber gestoppten Softwareraids ) ist leicht . Meist wird nur ne neue Logfile angelegt. Nachteil der Treiber ist im Kernel sehr gross. Aber dafür braucht es im Vergleich zu Reiser 4 weniger Ressourcen. Wenn du eine Rettungsdiskette haben willst reicht es Debian auf einer 120 MB grossen Partition mit ext3 zu installieren und den Rest auszugliedern. /var sollte min ca 1 GB gross sein. Denke immer an /var/cache/apt/archives bei einem Update. Wenn das Dokumentenverzeichniss noch in /var/www ist sollte man das entsprechend mit Einkalkulieren. Wenn kein eigener Kernel kompelliert werden soll, also nur Web mit LAMP oder File mit nfsd und samba komme ich auf nem Server mit 1 Gb für /usr mehr als locker aus
- continuum
- UNSTERBLICH(R.I.P.)
- Beiträge: 14759
- Registriert: 09.08.2003, 05:41
- Wohnort: sauerland
- Kontaktdaten:
@ Mauze
Wie kommst du denn auf diese Zuordnung ?
Immer wenn ein REDO-log zwischen geschaltet wird sollte doch eigentlich die Performance leiden weil ein zusaetzlicher Vorgang noetig wird.
Was passiert denn eigentlich?
Gast-OS an IDE/SCSI Treiber: gib Inhalt von Sector 12345678
auf Host-ebene passiert daraufhin im persistent modus:
VMware an Datei gast.vmdk: gib Inhalt von Zuordnungsposition 12345678
und im non-persistent oder mit REDO-modus
VMware an Datei gast.vmdk.REDO : gib Inhalt von Zuordnungsposition 12345678
Datei gast.vmdk.REDO an VMware: Zuordnungsposition 12345678 ist in Datei gast.vmdk
VMware an Datei gast.vmdk : gib Inhalt von Zuordnungsposition 12345678
Eine persistent und damit sehr langsam, die andere nicht persistent und schnell.
Wie kommst du denn auf diese Zuordnung ?
Immer wenn ein REDO-log zwischen geschaltet wird sollte doch eigentlich die Performance leiden weil ein zusaetzlicher Vorgang noetig wird.
Was passiert denn eigentlich?
Gast-OS an IDE/SCSI Treiber: gib Inhalt von Sector 12345678
auf Host-ebene passiert daraufhin im persistent modus:
VMware an Datei gast.vmdk: gib Inhalt von Zuordnungsposition 12345678
und im non-persistent oder mit REDO-modus
VMware an Datei gast.vmdk.REDO : gib Inhalt von Zuordnungsposition 12345678
Datei gast.vmdk.REDO an VMware: Zuordnungsposition 12345678 ist in Datei gast.vmdk
VMware an Datei gast.vmdk : gib Inhalt von Zuordnungsposition 12345678
NACHTRAG PERSISTENT
Ich habe Schei... gebaut, continuum hat natürlich vollkommen Recht mit seiner Erklärung. Getestet hatte ich unter einem LINUX-Wirt, später habe ich dann hier etwas zum Thema auf meiner WINDOWS Workstation geschrieben. Damit ich die richtigen Bezeichnungen benutze habe ich dann auf dem Windows-Wirt VMware gestartet und das "Advanced Virtual Disk Options" Fenster zum nachschlagen aufgerufen. Irgendwie sah das was anders aus als unter LINUX, da es hier weniger Konfigurationen gibt (was mir aber nicht aufgefallen ist), habe ich die möglichen Bezeichnungen auch in meinem Post ins Forum verwendet.
RICHTIGSTELLUNG:
Die Festplatte die sicher und damit langsam sein soll (root/boot/..) ist NICHT "independent", aber "Disable write caching" ist aktiviert, Somit werden alle Daten direkt phys. geschrieben (keine Pufferung im Wirt-OS), ein JournalFS im Gast macht Sinn.
Die Festplatte die schnell und damit in Bezug auf ein JournalFS im Gast nicht wirklich sicher ist, hat keine spez. Konfigurationen in VMware. Damit ist das write caching aktiv.
Große Entschuldigung für die Verwirrung, man treue Asche über mein Haupt.
Mauze
Ich habe Schei... gebaut, continuum hat natürlich vollkommen Recht mit seiner Erklärung. Getestet hatte ich unter einem LINUX-Wirt, später habe ich dann hier etwas zum Thema auf meiner WINDOWS Workstation geschrieben. Damit ich die richtigen Bezeichnungen benutze habe ich dann auf dem Windows-Wirt VMware gestartet und das "Advanced Virtual Disk Options" Fenster zum nachschlagen aufgerufen. Irgendwie sah das was anders aus als unter LINUX, da es hier weniger Konfigurationen gibt (was mir aber nicht aufgefallen ist), habe ich die möglichen Bezeichnungen auch in meinem Post ins Forum verwendet.
RICHTIGSTELLUNG:
Die Festplatte die sicher und damit langsam sein soll (root/boot/..) ist NICHT "independent", aber "Disable write caching" ist aktiviert, Somit werden alle Daten direkt phys. geschrieben (keine Pufferung im Wirt-OS), ein JournalFS im Gast macht Sinn.
Die Festplatte die schnell und damit in Bezug auf ein JournalFS im Gast nicht wirklich sicher ist, hat keine spez. Konfigurationen in VMware. Damit ist das write caching aktiv.
Große Entschuldigung für die Verwirrung, man treue Asche über mein Haupt.
Mauze
Zurück zu „VMware Workstation und VMware Workstation Pro“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 11 Gäste