V-Server down bei IP-Projects
- Thread starter cmeerw
- Start date
kiwee
Member
Moin,
schau mal auf welchem Hostsystem dein VPS liegt, IPP zieht derzeit einige VM's auf ein neues Hostsystem um.
Link: http://status.ip-projects.de/
Und alternativ einfach mal anrufen
Viele Grüße,
kiwee
schau mal auf welchem Hostsystem dein VPS liegt, IPP zieht derzeit einige VM's auf ein neues Hostsystem um.
Link: http://status.ip-projects.de/
Und alternativ einfach mal anrufen
Viele Grüße,
kiwee
A
andreas0
Guest
Hattest du denn nachdem du das Problem erkannt hattest zeitnah auch ein Ticket aufgegeben? Denn der Provider löst nach Zumeldung von Problemen erfahrungsgemäß recht schnell Probleme.
IP-Projects.de
Active Member
Das zugrundeliegende Problem wurde durch unsere Entwickler behoben. Gerne kann man bei Störungen oder Problemen auch jederzeit bei uns anrufen.
Das Problem hatte nur die HVM virtuellen Maschinen auf dem neuen Hostsystem betroffen, daher ist es nicht sofort aufgefallen. Dabei hat das Netzwerk Script bei HVM VMs ein Problem verursacht.
Unsere Webseite war kurzzeitig nicht erreichbar, da wir seit kurzem RIPE LIR sind und einige Services auf unsere eigenen IP Bereiche migriert haben. Ein sonniges Wochenende bietet sich für solche Arbeiten immer gerne an, da hier das Besucher- und E-Mail Aufkommen gering ist.
Das Problem hatte nur die HVM virtuellen Maschinen auf dem neuen Hostsystem betroffen, daher ist es nicht sofort aufgefallen. Dabei hat das Netzwerk Script bei HVM VMs ein Problem verursacht.
Unsere Webseite war kurzzeitig nicht erreichbar, da wir seit kurzem RIPE LIR sind und einige Services auf unsere eigenen IP Bereiche migriert haben. Ein sonniges Wochenende bietet sich für solche Arbeiten immer gerne an, da hier das Besucher- und E-Mail Aufkommen gering ist.
Wurde das Problem mit dem Einfrieren der Hosts gefunden? In den Statusmeldungen scheint das ja die letzten Wochen munter weiter zu gehen. Da sind mehrere Hosts dabei. Das muntere Hardwarewechseln macht eher ratlos. Die Instabilität bei gedrosselten I/O Werten auf den virtuellen Maschinen ist jedenfalls recht merkwürdig. Das geht ja auch ins Geld für den Provider.
IP-Projects.de
Active Member
Der vServer Host mit den freeze Problem ist aktuell stabil nachdem wir alle SSDs, Mainboard und CPU getauscht haben. Heute ist v10 ausgefallen, dieser lief jetzt ca. 6 Monate störungsfrei.
Das Problem mit den IO hängt mit den kostenlosen täglichen Backups zusammen. Wir haben letzte Woche mit unseren Entwicklern ein finalen Meeting für unser neues inkrementelles Backupkonzept abgeschlossen. Auf den Testsystem läuft schon alles einwandfrei so dass wir mit unseren neuen vServer Tarifen kommende Woche sich unser neues Backupkonzept ausrollen werden.
Das Problem mit den IO hängt mit den kostenlosen täglichen Backups zusammen. Wir haben letzte Woche mit unseren Entwicklern ein finalen Meeting für unser neues inkrementelles Backupkonzept abgeschlossen. Auf den Testsystem läuft schon alles einwandfrei so dass wir mit unseren neuen vServer Tarifen kommende Woche sich unser neues Backupkonzept ausrollen werden.
A
andreas0
Guest
Baut ihr eure Server aus einzeln gekauften Hardwarekomponenten selber zusammen oder kauft bzw. mietet ihr zertifizierte Hardware, die auch schon durch den Hersteller auf Herz und Nieren getestet wurde?
IP-Projects.de
Active Member
Wir bauen die Server selbst zusammen, da wir ein Fan davon sind zu wissen, was in unseren Servern an Hardware verbaut ist. Zudem brauchen wir keinen technischen Support wie z.B. vor Ort Tausch Services, da wir ein sehr umfangreiches Hardwarelager haben. Erschwerend kommt hinzu, dass Markenhardware von HP oder anderen Distributoren bei Spezialanforderungen, wie diese bei uns zum Tragen kommen, doch meist sehr sehr teuer ist. Wir haben uns bei den RAID Arrays und der eingesetzten Hardware sehr viel Gedanken gemacht gerade bei der Konstellation der Drives und den eingesetzten RAID Controllern.
Bei der Virtualisierung setzen wir https://xenproject.org/ ein. Das ist die Basis aller bekannten auf Xen basierenden Virtualisierungslösungen. Meines Wissens basiert auch die Amazon Cloud auf Xen. Mir ist allerdings keine Zertifizierte Hardware für das freie Xen bekannt lediglich für Xen Citrix Server. Die meisten unserer Systeme laufen auch grundsätzlich stabil es gibt aber durchaus den Fall wo alle 2 Monate ein System Freezed, dort tauschen wir dann Schritt für Schritt die Bauteile die für das Problem am Wahrscheinlichsten sind, wenn es kein klares Fehlerbild gibt. Z.B. RAM, Mainboard, Hard Drives, RAID Controller, ... Ein Problem das unregelmäßig auftritt kann leider auch durch einen vorherigen Hardware Checkup nicht identifiziert werden.
A
andreas0
Guest
Wenn ich mich nicht irre, testet ihr doch gerade euer zukünftiges System, welches zukünftig auf die Virtualisierungstechnologie KVM / QEMU setzt. Von daher bezog sich meine Frage auch eher auf euer zukünftiges System. Wie stellt ihr auch für dieses System sicher, dass es auch so stabil laufen wird, wie ein vom namhaften Hersteller zertifiziertes System?
IP-Projects.de
Active Member
Wir planen nicht von Xen weg zu gehen. Xen läuft grundsätzlich sehr gut. Jede Virtualisierungsvariante hat ihre Vor- und Nachteile, ein Wechsel auf KVM würde bei uns mehr Nachteile als Vorteile bringen. Wir haben unser gesamtes System - vServer Verwaltungsbereiche - für Xen ausgelegt und gerade die Para Virtualisierung lässt noch viele Möglichkeiten offen die wir noch nicht ausgeschöpft haben. Ein großer Vorteil dabei ist, dass sich die Para Virtualisierung verhält wie das alt bekannte OpenVZ hinsichtlich Flexibilität und Ressourcenteilung. OpenVZ wird ja in den aktuellsten Kernel nicht mehr unterstützt, unsere Xen Para virtualisierten Maschinen können wir aber problemlos auf die neusten Kernel patchen.
Grundsätzlich ist auch zertifizierte Hardware kein Garant für weniger Ausfälle oder Probleme. Wir verbauen was die Hostsysteme angeht keine schlechte oder billige Hardware sondern gängige Serverhardware die wir schon hunderfach im Einsatz haben. Nur leider scheinen wir mit manchen Systemen hier etwas Pech zu haben trotz Supermicro Servermainboard, ECC Registered RAM, großen LSI RAID Controllern mit SSD Cache, 10 G Netzwerkkarten, ... Dies ist vermutlich bedingt durch die deutlich höhere Ressourcenausnutzung als bei vergleichbaren Kundensystemen.
Jedes Hostsystem kostet ca. 4.500-5.500 € alleine in der Anschaffung.
In den letzten Monaten haben wir im Bereich vServer sehr viel Geld und Entwicklerzeit investiert und ein Storagekonzept gefunden was neben SSD Swap noch andere Features unseren Kunden liefert. Alle vServer wurden bereits auf die neuen Systeme umgestellt nur beißt sich unser Ansatz der Datensicherheit - kostenlose tägliche Snapshots der vServer - etwas mit der Performance des Daten Arrays. Das werden wir in den nächsten Tagen aber auch noch umstellen so dass die Backups schneller und ressourcenschonender abgeschlossen werden. Dann ist die Gesamtperformance der Storages um ein vielfaches besser.
Inkrementell anstatt Fullsnapshots? Klingt gerade bei instabilen Zuständen nicht so gut. Aber das Konzept wurde ja noch nicht kommuniziert, daher nur ein Gefühl.
Wenn es nicht an den Investitionen liegt, dann müssen anderen Provider (wie z.B Jiffybox von df) ja einen Trick haben, um Fullsnapshots ohne merklichen I/O Einbruch hinzubekommen. LSI mit seiner SSD-Cache-Steuerung dürfte auch eher hinderlich sein, das I/O Verhalten des Systems nachzuvollziehen.
killerbees19
Member
Weil Du gerade DF ins Spiel bringst: Bei der JiffyBox gab es eine Zeit lang dafür massive Netzwerkprobleme durch die nächtlichen Backups. Alles nachzulesen in deren Forum. Das wurde nach aufwändiger Analyse behoben. Die kurzzeitigen Lastspitzen sind einfach unbemerkt durchs Monitoring gerutscht.
Und eingeschränkte I/O Leistung durch Backups gab bzw. gibt es auch bei der JB immer wieder. Auf diese Tatsache weist sogar das Control Panel hin, wenn man ein manuelles Backup startet.
Unabhängig davon hat DF wieder das Problem, dass die Backups von großen Systemen zeitweise so lange brauchen, dass sie nicht einmal innerhalb von 24 Stunden fertig werden. Das haben sie meinen Informationen nach aktuell zwar wieder im Griff, aber es zeigt sehr deutlich, dass auch DF kein Wundermittel hat, das jegliche Kopfschmerzen vertreibt. Die Systemadministratoren und Entwickler standen oder stehen vor ähnlichen Problemen. Und letzten Endes kochen alle nur mit Wasser.
MfG Christian
Und eingeschränkte I/O Leistung durch Backups gab bzw. gibt es auch bei der JB immer wieder. Auf diese Tatsache weist sogar das Control Panel hin, wenn man ein manuelles Backup startet.
Unabhängig davon hat DF wieder das Problem, dass die Backups von großen Systemen zeitweise so lange brauchen, dass sie nicht einmal innerhalb von 24 Stunden fertig werden. Das haben sie meinen Informationen nach aktuell zwar wieder im Griff, aber es zeigt sehr deutlich, dass auch DF kein Wundermittel hat, das jegliche Kopfschmerzen vertreibt. Die Systemadministratoren und Entwickler standen oder stehen vor ähnlichen Problemen. Und letzten Endes kochen alle nur mit Wasser.
MfG Christian
IP-Projects.de
Active Member
Guten Abend,
vielen Dank für das rege Interesse Gerne gehe ich hier etwas genauer auf das Konzept dahinter ein.
Wir arbeiten bei den vServern mit LVM Devices. Jede Para VM hat zwei LVM Devices. Ein LVM Device für SWAP und ein LVM Device für Daten. Bei HVM gibt es wie bei KVM nur ein LVM Device.
LVM hat die sehr gute Eigenschaft, dass man davon ein Snapshot erstellen kann. Ein LVM Snapshot ist aber kein VM Snapshot sondern es ist quasi ein eingefrorener Zustand des Devices. Diesen eingefrorenen Zustand kann man dann mounten oder als Device kopieren. Aktuell ist es so, dass wir quasi mit Hilfe eines Tools eine 1 zu 1 Kopie des LVM Devices auf ein SAS Array im Server kopieren, dort eine Komprimierung durchführen und die Komprimierung dann auf eine zentrale interne Backupstorage kopieren. Das Problem ist, mit z.B. dd Copy kann man nur das gesamte Device anfassen nicht aber die Daten die darin sind. Bei einer 50 GB VM in der 5 GB genutzt werden kopiert er quasi die 50 GB und komprimiert diese dann nach dem Kopiervorgang auf einem SAS Array auf 5 GB. Da hier immer alle Daten des Kunden angefasst werden müssen, dauert dieser Backupvorgang natürlich eine gewisse Zeit und während des Backupvorgangs ist natürlich auch die I/O Last sehr groß.
Wir haben jetzt ein neues Tool entwickelt, das den LVM Snapshot mountet und einen direkt Abgleich der Daten auf der Backupstorage durchführt. Das bedeutet, das System prüft, welche Dateien haben sich verändert und sichert dann die veränderten Dateien in Ordner mit einem bestimmten Timestemp. Der Vorteil hierbei ist, er fasst zwar jede Datei an, vergleicht aber nur, ob die Daten sich verändert haben und wenn sich die Daten verändert haben, kopiert er nur die Files die wirklich verändert wurden. Das spart massiv I/O und insgesamt läuft das Backup natürlich deutlich schneller durch.
Es kann aber nichts passieren, denn selbst wenn das Backup abbrechen sollte, wird der Datenbestand auf der Backupstorage nicht berührt.
Bei HVM virtuellen Maschinen geht das natürlich nicht, da wir die partition table der VM nicht kennen. Insgesamt haben wir aber 80 % Para 20 % HVM virtuelle Maschinen, daher ist es nicht weiter schlimm die HVM VMs weiterhin nach dem bisherigen Verfahren zu sichern.
vielen Dank für das rege Interesse
Gerne gehe ich hier etwas genauer auf das Konzept dahinter ein.Wir arbeiten bei den vServern mit LVM Devices. Jede Para VM hat zwei LVM Devices. Ein LVM Device für SWAP und ein LVM Device für Daten. Bei HVM gibt es wie bei KVM nur ein LVM Device.
LVM hat die sehr gute Eigenschaft, dass man davon ein Snapshot erstellen kann. Ein LVM Snapshot ist aber kein VM Snapshot sondern es ist quasi ein eingefrorener Zustand des Devices. Diesen eingefrorenen Zustand kann man dann mounten oder als Device kopieren. Aktuell ist es so, dass wir quasi mit Hilfe eines Tools eine 1 zu 1 Kopie des LVM Devices auf ein SAS Array im Server kopieren, dort eine Komprimierung durchführen und die Komprimierung dann auf eine zentrale interne Backupstorage kopieren. Das Problem ist, mit z.B. dd Copy kann man nur das gesamte Device anfassen nicht aber die Daten die darin sind. Bei einer 50 GB VM in der 5 GB genutzt werden kopiert er quasi die 50 GB und komprimiert diese dann nach dem Kopiervorgang auf einem SAS Array auf 5 GB. Da hier immer alle Daten des Kunden angefasst werden müssen, dauert dieser Backupvorgang natürlich eine gewisse Zeit und während des Backupvorgangs ist natürlich auch die I/O Last sehr groß.
Wir haben jetzt ein neues Tool entwickelt, das den LVM Snapshot mountet und einen direkt Abgleich der Daten auf der Backupstorage durchführt. Das bedeutet, das System prüft, welche Dateien haben sich verändert und sichert dann die veränderten Dateien in Ordner mit einem bestimmten Timestemp. Der Vorteil hierbei ist, er fasst zwar jede Datei an, vergleicht aber nur, ob die Daten sich verändert haben und wenn sich die Daten verändert haben, kopiert er nur die Files die wirklich verändert wurden. Das spart massiv I/O und insgesamt läuft das Backup natürlich deutlich schneller durch.
Es kann aber nichts passieren, denn selbst wenn das Backup abbrechen sollte, wird der Datenbestand auf der Backupstorage nicht berührt.
Bei HVM virtuellen Maschinen geht das natürlich nicht, da wir die partition table der VM nicht kennen. Insgesamt haben wir aber 80 % Para 20 % HVM virtuelle Maschinen, daher ist es nicht weiter schlimm die HVM VMs weiterhin nach dem bisherigen Verfahren zu sichern.
Last edited by a moderator:
d4f
Kaffee? Wo?
Ich hatte für meinen Arbeitgeber ein clientseitig (=vHost) deduplizierendes BackupSystem entworfen welches jeweils für eine feste(*) Blockgrösse von bspw 1MB einen Hash erstellt. Falls dieser Hash dem Backupserver bekannt ist, im Backup nur referenzieren, ansonsten komprimieren und übertragen.
Leere Bereiche werden damit automatisch nicht mit übertragen und der Speicherzuwachs ist in einer ähnlichen Liga wie inkrementelle Backups ohne die ganze Referenz-Problematik. Im Endeffekt sind klein-mittlere vServer damit binnen Sekunden bis wenige Minuten übertragen und ganze Hostsysteme angenehm schnell übertragen, sogar mit ionice Kategorie 3.
Die entstandenen Backups bestehen dann aus einer Datenbank aus Referenzen auf gespeicherte Dateien so dass sich daraus recht leicht ein Fuse-basiertes virtuelles Dateisystem mit unkomprimierten Image-Dateien auf dem Backupserver aufbauen lässt welche man dann per NBD an den Hostserver zwecks Backupeinbindung durchreichen kann. Eine Auszeichnung für Lesegeschwindigkeit kriegt man zwar nicht, es ist aber für alle üblichen Einsatzzwecke mehr als schnell genug.
Leider lässt sich das Problem dass die ganzen LV's mal vollständig gelesen werden können (und damit bspw bcache Caches kurzzeitig stark stören) nicht vermeiden, aber eine Interpretierung der im LV enthaltenen Daten ist zu ungewiss und auch nicht byte-korrekt während das beschriebene Deduplikationsverfahren es ist.
*: Der enorme Ressourcenaufwand für sliding-window oder variable-size Backups ist den kleinen Speichervorteil in meinen Tests nie wert gewesen.
Last edited by a moderator:
IP-Projects.de
Active Member
Ist eine deduplizierung nicht sehr RAM lastig?
d4f
Kaffee? Wo?
Wirklich RAM- und CPU-lastig sind Deduplikationen nur bei sliding-window und variable-size Backups weil er ständig überprüfen muss ob ein Block passen könnte.
Meine Implementierung verwendet "nur" statische Blockgrössen so dass der Verbrauch lediglich linear ansteigt in Relation zur Grösse des Datastore. Aktuell im Einsatz ist eine 64bit-lange Hashfunktion was die Match-Probabilität bei jeweils getrennten Datastores pro VPS ausreichend vernachlässigbar hält und einen RAM-Verbrauch im MB-Bereich erreicht.
Der Read Cache ist in vielen Fällen höher als der RAM-Verbrauch, genaue Werte für grosse VM's kann ich aber aus dem Produktivbetrieb nicht nennen da es fast ausschliesslich für kleinere VPS (80GB-100GB) eingesetzt wird. Andere Forenteilnehmer haben aber ähnliche Deduplikation im Einsatz wenngleich noch auf Server- und nicht Clientseite, ggf kann der ja konkrete Zahlen zu grossen VM's nennen.
Beispiel in Bezug auf Speichereffizienz mit einem kleinen VPS mit hoher Datenaktivität.
Anmerkung:
- 3 Vhosts backupen gleichzeitig
- Backupserver hat 1000Mbit/s Anbindung
- es wird immer nur 1 geänderter Block gleichzeitig übertragen, aber aufeinanderfolgende bekannte Blöcke gleichzeitig
- Verbindung erfolgt SSL-verschlüsselt
Backup:
- 81920 MB VPS Grösse, rund 40GB aktiv genutzt
- Blocksize 1MB
- Aktuell 72 tägliche Backups vorrätig
- 349 Sekunden Backupdauer (Schnitt über 5 Backups)
- 42GB Datastore für alle Backups zusammen
- 65395 unterschiedliche Blöcke
Vergleich von 2 aufeinanderfolgenden Backups:
- zwischen 200 und 500 neue Blöcke pro Tag
IP-Projects.de
Active Member
ok, wir schauen mal wie unser neues Backupkonzept läuft. Eventuell macht das Sinn hier noch etwas mit Deduplizierung mit zu implementieren. Die größte zu sichernde Storage ist bei uns aktuell 6.5 TB groß. Der Faktor Zeit ist bei unseren aktuellen Backupsystem der größte Punkt den es gilt zu verbessern