Replication

[Klaus_Urban]

Hallo,
ich teste gerade die Tages-Replication einer Windows 2008 R2 Terminalserver VM, die während der Arbeitszeit jede halbe Stunde gestartet wird.

Bei Acronic vmProtect 7 erhalte ich folgende Werte:
Snapshot erstellen: 2 Minuten
Replication zum ESXi5 #2: 4 Minuten
Snapshot löschen 12 Minuten.
In der VM läuft dabei ein Benchmark-Programm.
Ohne Replication dauert es 388 Sekunden.
Mit Replication 616 Sekunden.
Der Snaphot bremmst den Server sehr aus.
Ist das Normal?

Ich habe das mal alle 30 Minuten per WBadmin gestetet.
Da dauert die incrementelle Sicherung 2 Minuten und der Benchmark dauert nur 405 Sekunden.

Kann man den Snapshot unter ESXi 5 noch beschleunigen, oder geht es nicht schneller?

Wenn nein, ja, dann nehme ich WBadmin und spare 2000€.
Dann muss ich aber beim 2. ESXI noch die aktuelle Tagessicherung zurücksichern,
weil nur nachts die VM kopiert wird.

Klaus

[continuum]

Code: Alles auswählen

In der VM läuft dabei ein Benchmark-Programm.

Das ist eine sichere Methode um die Snapshot-erstellung zu verlangsamen - wozu soll das gut sein ?

[Klaus_Urban]

Ulli schrieb:
Das ist eine sichere Methode um die Snapshot-erstellung zu verlangsamen - wozu soll das gut sein ?

Damit ich herausfinde, um wieviel der Terminalserver langsamer wird.
Ich verkaufe meinen Kunden doch keine 2000€ Lösung, die dann das System dermaßen ausbremmst. Im Moment wird nur Nachts gesichert. Bei einem Totalausfall sind im schlimmsten Fall die Daten eines Tages verloren.
Sichere ich aber auch tagsüber, wird der Ausfall geringer.

Noch besser wäre der VMware vCenter Site Recovery Manager 5 Standard.
Aber den gibt es erst ab 25 VM's für ca. 3700€ zusätzlich zum VMware vSphere 5 Essentials Plus Kit. Das ist bei einer VM etwas viel.

Klaus[/code]

[mangold]

warum muss man einen Terminal Server regelmäßig sichern? Da wird einmal ein Backup nach der Installation gemacht und evtl. wenn man eine Änderung am System durchführt. Das wars. Auf einem Terminal Server gehören keine Daten die sich ändern, und auch sicherungswürdig wären. Das ist dann ein Design Fehler in der Terminal Server Umgebung.

[deathrow]

warum muss man einen Terminal Server regelmäßig sichern?

Code: Alles auswählen


Hab ich mich auch grade gefragt, vor allem alle 30min??

Daten auf einen Fileserver oder ordentliches NAS legen, Server einmal die Woche Nachts sichern, Daten per Band oder HDD oder was auch immer sichern, daß kann dann ja alle 30min laufen.

[Klaus_Urban]

> warum muss man einen Terminal Server regelmäßig sichern?

weil das der einzigste Server ist. Darauf greifen Thin-Clients zu.
Ich spreche hier von einem kleinen Netzwerk. Also keine 2 AD,s und 2 TS und 2 SAN.
Das wären sonst mehr Server als Clients. ;.)

Also suche ich eine günstige uns sichere Lösung für eine kleine TS Umgebung.
Aber die halbwegs bezahlbaren Lösungen sind bei dieser Umgebung ja schlechter als meine jetzigen Installationen.

Ich könnte natürlich neben dem Hardware-Raid noch eine zusätzliche Sata-Festplatte als Datenstore-Spiegelung einrichten und beim Terminal-Server eine Software Spiegelung einrichten. Dann stecke ich, wenn der ESXi #1 ausfällt die Festplatte einfach in den ESXi #2.

Klaus

[PeterDA]

Hallo du
hast eine Virtualisierungslösung, warum packst du dann Dienste die nicht zusammen gehören auf eine VM. Einfache einen Fileserver noch als VM installieren und schon ist die ganze Sache viel Sauberer.

Gruß Peter

[mangold]

Hallo du
hast eine Virtualisierungslösung, warum packst du dann Dienste die nicht zusammen gehören auf eine VM. Einfache einen Fileserver noch als VM installieren und schon ist die ganze Sache viel Sauberer.

Gruß Peter

jupp, genau so sieht es aus. Ein separater DC und FS sind ein Muss und virtualisiert kein Problem. Diese Lösung wie sie oben beschrieben wurde, mit irgendwelchen Hintergrunddiensten, die alle 30 Minuten sichern, sind auf einer TS Umgebung, wo es auf Latenzen ankommt, also CPU / Netzwerk absolut stimmen müssen um die "User Experience" auf einem erträglichen Maß zu halten, Pflicht.

[Klaus_Urban]

> hast eine Virtualisierungslösung, warum packst du dann Dienste die nicht
> zusammen gehören auf eine VM. Einfache einen Fileserver noch als VM
> installieren und schon ist die ganze Sache viel Sauberer.

Nein, dann ist der Zugriff ja übers langsame Netzwerk.
Selbst Fast-Ethernet ist doch langsamer als der direkte Festplattenzugriff.
Außerdem, welche Dienste gehören nicht zusammen? TS und AD?
Bei dieser Lösung benötige ich keinen AD. Die Passwörter werden auf dem TS gespeichert und gegenseitige Freigaben gibt es nicht. Alle Drucker sind auf dem TS als lokale IP-Drucker eingerichtet.

Also nochmal: 2-10 Clients greifen auf einen Terminalserver zu. Darauf ist alles installiert, was sonst auf einem Einzelplatzrechner installiert ist. Dadurch ist die Einrichtung und die Wartung einfach. Defekte Clients können problemlos getauscht werden. Es muss nur der TS gesichert werden. Weil aber ohne TS nicht mehr funktioniert, richte ich einen Ersatz-Server ein.

Klaus

[mangold]

unabhängig von dieser Designentscheidung (die ich nach vollziehen kann, aber nicht gut finden muss )
wie Ulli schon geschrieben hat;

Code: Alles auswählen

In der VM läuft dabei ein Benchmark-Programm.

Das ist eine sichere Methode um die Snapshot-erstellung zu verlangsamen - wozu soll das gut sein ?

beim Erstellen des Snapshots versucht der ESXi Server über die VMware Tools das FS der VM zu quiescen. Das macht der VSS Provider. Wenn der wegen dauernder Aktivität des Systems hängt, dann dauert das Erstellen auch ewig. Ausserdem wächst das Delta bei Schreibaktivität rasant an, was wieder dazu führt, dass das Löschen des Snapshots deutlich länger dauert.

Das Quescen des FS zu deaktivieren, ist aber eher kontraproduktiv, weil man sich damit u.U. ein inkonsistentes Backup einhandelt.

[irix]

...
beim Erstellen des Snapshots versucht der ESXi Server über die VMware Tools das FS der VM zu quiescen. Das macht der VSS Provider. Wenn der wegen dauernder Aktivität des Systems hängt, dann dauert das Erstellen auch ewig.

Er hat geschrieben das die Erstellung ca. 2min dauert. was nun im oberen Bereich liegt was die Dauer angeht wenn ich es mal mit einen VMs vergleiche.

Die Dauer fuer das Einarbeiten haengt natuerlich primaer von der Groesse und der Schnelligkeit des Storages ab. Da er aber von ca. 30min geschrieben hat die Frage was die Deltas so anwachsen laesst und wenn Sie klein sind ob das Storage dann ueberlastet ist.

Bei Windows 2008 und disk.EnableUUID=true werden auch 2 Snaps pro Disk erstellt.

Mir hat der VMware Support erzaehlt das mit akt. Snaps die IO last um das 1.5 fache ansteigt.

Ob nun Prozesse in der VM laenger brauchen waere mir Egal solange die Benutzer ohne Stoerungen arbeiten koennen.

Gruss
Joerg

[PeterDA]

Nur mal so als Frage wenn du nur einen TSbrauchst warum denn dann virtualisieren??

Halte das Design für ziemlich ....

Gruß Peter

[mangold]

Er hat geschrieben das die Erstellung ca. 2min dauert. was nun im oberen Bereich liegt was die Dauer angeht wenn ich es mal mit einen VMs vergleiche.

lange Zeiten beim Erstellen eines Snapshots kenne ich auch nur, wenn ich angebe, dass der RAM auch gespeichert werden soll. Dann dauert das auch ein paar Sekunden länger bei 8 GB vRam. Bei normalen Backups ist das aber zumindest bei mir nicht aktiviert.

Andererseits habe ich immer wieder bei den nächtlichen Backups Fehler, dass es beim Erstellen des Snapshot zum Timeout kam. Das passiert bei sehr IO lastigen VMs oder wenn der Ram ausgeht. Genaueres erkennt man dann im Eventlog der VM, im letzteren Fall steht dann wirklich so was wie "Snapshot Provider hat keinen Ram mehr"

Letztendlich stellt sich die Frage ob sein Benchmark das so stark beeinflusst, und ob das Snapshotten und Committen ohne laufenden Benchmark schneller laufen würde. Wie immer; kede Messung beeinflusst das System das man messen möchte.

Du hast natürlich recht, im Endeffekt zählt ob der User das bemerkt, ich wage aber zu behaupten, dass auf einem TS mit 10 Usern ein sich alle 30 Minuten wiederholender Snapshot durchaus negativ bemerkbar macht, vor allem weil auf einem TS, der noch als Datenspeicher missbraucht wird, das Delta recht schnell "anschwillt".

[Klaus_Urban]

Hallo Peter,

> Nur mal so als Frage wenn du nur einen TSbrauchst warum denn dann virtualisieren??

1. Weil man mit einer VM besser umziehen kann. Sprich Ausfallsicherheit.
2. Weil ich per VPN / SSH den Server neu aufsetzen bzw. zurücksichern kann.

Denn ich betreue ca. 100 Netzwerke und muss nicht jedesmal zum Kunden hinfahren.
Daher rüste ich jetzt nach und nach auf ESXi um. So kann man im Extremfall auf den 2. ESXi umschalten. Dann habe ich etwas Zeit.

Klaus

[Klaus_Urban]

Hallo mangold,

ich habe jetzt mal den Testserver im Leerlauf Repliziert. Das dauerte nur 7 Minuten.
Wenn 3 Power-User ohne Beeinträchtigung Daten erfassen können scheint es ja doch zu funktionieren.

Klaus

[pitbullracer]

Moin,

die Sinnhaftigkeit dieser Lösung einmal nicht betrachtet:

Sichere doch einfach die Daten mit entsprechendem Tool alle 30 Minuten auf ein NAS.
Und die VM entsprechend jeden Nacht / jede Woche voll.

Die Daten auf dem NAS bieten zudem den Vorteil, das diese im Worst-Case auch bsp. durch ein Notebook aufgerufen werden können und keine Abhängigkeit von einem ESXi Server besteht.

[Klaus_Urban]

Hallo Pitbullracer,
> die Sinnhaftigkeit dieser Lösung einmal nicht betrachtet:
was soll an einer Datensicherung sinnlos sein?

Noch besser wäre eine vSphere Storage Appliance.
Aber 10.000€ sind dann doch zuviel.
Und gespiegelte SAN sind sowieso Overkill.

Nachden Acronis vmProtect 7 und Veeam Backup & Restore 6 wegen dem langsamen Snapshot rausgeflogen sind, habe ich nun zwei andere Lösungen im Test.

1. Nachts per FastSCP die VM kopieren und tagsüber alle 30 Minuten per
WBAdmin zur NAS. Dabei fällt die Leistung nicht ab.
Hier muss aber im Fehlerfall erst die letze Sicherung zurückgesichert werden.

2. Softwarespiegelung zur NAS und die normale Datensicherung per WBAdmin.
Hier kann ich die VM vom ESXi I#2 direkt aus dem NAS herhaus starten.
Wenn ich die Spiegellaufwerke im Player-Format anlege, kann sie sogar der
VMWare Player starten.

Klaus