Die Empfehlung lautet ja, Snapshots zu entfernen, wenn diese nicht mehr benötigt werden. Netcup kann aber ja nicht wissen, ob der Kunde sie noch benötigt oder nicht.
Deswegen würde ich diese Information beim Anlegen des Snapshots ja gerne mitgeben. Von anderen Anbietern habe ich gelesen, dass Snapshots dort teilweise voreingestellt nach einer Zeit gelöscht werden. Unmöglich ist es also definitiv nicht so etwas zu implementieren.
Mein vServer wird mittlerweile gefühlt 1x im Monat ankündigt und unangekündigt auf ein neues Wirtssystem umgezogen. Da ich beim Booten ein Passwort eingeben muss, führt das leider gelegentlich zu längeren Downtimes, wenn der Neustart nicht direkt aufgefallen oder kein PC in der Nähe ist. Jedes Mal erhält man dazu noch eine schlaue Mail, die empfiehlt, die "Snapshots zu entfernen, wenn diese nicht benötigt werden", damit kein Neustart erforderlich ist. Leider wird die Mail von einer Noreply-Adresse gesendet, sonst hätte ich direkt mal nachgefragt, wieso keine automatisierte Löschung nach X Tagen möglich ist, wenn es denn empfohlen wird.
Snapshots mache ich grundsätzlich nur vor größeren Updates und benötige sie eigentlich auch nicht länger als einen Tag zur Sicherheit. Außer zum Snapshot machen melde ich mich aber eigentlich so gut wie nie im SCP an, weshalb diese dort auch unnötigerweise mal länger liegen. Wieso wird daher nicht einfach eine automatisierte Löschung angeboten, wenn ein längeres Aufbewahren sowieso nicht empfohlen wird?
Ich würde auch mal dafür plädieren, wenigstens zu Anschauungszwecken eingehendes NTP in die Default Policies aufzunehmen. Im Gegensatz zu Ping ist das im Zweifel geschäftskritisch. Ich habe schon Firewalls von mindestens vier verschiedenen Herstellern konfiguriert und auch wenn die UDP-Problematik in der Anleitung erklärt wird, finde ich es nicht wirklich intuitiv und musste auch noch mal nachbessern.
Nochmal eine Rückfrage zur Speicheroptimierung: Wie sieht das bei Dir im SCP genau aus nach der Speicheroptimierung. Steht dann da, dass Du genau die Festplattenkapazität erreicht hat, oder bist Du immer noch über dem Limit Deiner SSD?
Kurz nach der Optimierung war es etwas über 200. Mittlerweile wurden schon wieder anderen Blöcke beschrieben.
Bisher sind die IOWaits 24 Stunden nach der Speicheroptimierung nicht mehr aufgetreten. Ich werds noch etwas länger beobachten.
Wäre super, wenn Du das Ergebnis Deiner Speicheroptimierung teilst, gerne auch mit Auslastungswerten Deiner vda vorher/nachher im SCP.. Ich habe das noch nie gemacht, nach meinem Verständnis würde das bei einer Vollverschlüsselung auch nichts bringen, da aus Sicht des Hosts halt einfach alle Blöcke belegt sind.
Das Ergebnis zu den Werten habe ich dir in dem Post oben schon verraten 
. Ist nicht meine erste Speicheroptimierung. Nur die erste in dem Kontext dieses Problems
Könnte sogar tatsächlich sein, dass die Probleme erst angefangen haben, seitdem der Wert der Speichernutzung im SCP überschritten wurde. Ist aber nur eine Vermutung. Nach der Speicheroptimierung wissen wir vielleicht mehr.
Definitionsfehler von mir: Der Fehler lässt sich durch einen Reboot nicht beseitigen. Nur mit einem Ein- und Ausschalten des kompletten Servers. Ein Reboot bekommt das Hostsystem soweit ich weiß ja nicht mit, aber ein Ein-/Ausschalten schon. Würde daher ja schon dafür sprechen, dass sich auf dem Hostsystem in dem Moment etwas ändert.
Meine IOWaits haben fast genau 24 Stunden nach dem Reboot Ein-/Ausschalten auch wieder angefangen. Beim Generieren des fio-Testfiles hat der Server für 2 Minuten auf überhaupt keine Eingaben mehr reagiert. Ich denke ich werde später mal eine Speicheroptimierung durchführen, vielleichts bringts ja was.
Block Size | 4k (IOPS) | 64k (IOPS)
------ | --- ---- | ---- ----
Read | 6.56 MB/s (1.6k) | 5.89 MB/s (92)
Write | 6.57 MB/s (1.6k) | 6.19 MB/s (96)
Total | 13.13 MB/s (3.2k) | 12.08 MB/s (188)
| |
Block Size | 512k (IOPS) | 1m (IOPS)
------ | --- ---- | ---- ----
Read | 5.60 MB/s (10) | 5.49 MB/s (5)
Write | 6.17 MB/s (12) | 6.17 MB/s (6)
Total | 11.78 MB/s (22) | 11.67 MB/s (11)SiebenG Benutzt du zufälligerweise auch Ubuntu 24.04.3 LTS? Vielleicht gab es ja wirklich eine softwarespezifische Änderung in einem Update.
Bei einem RS sollte die CPU doch immer gleich abliefern, da dediziert? Gibt es bei Netcup jetzt überhaupt irgendwas Dediziertes? Ich gehe aus dem Thread mit mehr Fragen raus, als ich reingekommen bin 
Ist eigentlich auch seltsam, wenn man mal so drüber nachdenkt ...240 GiB stimmt aber, laut Vertrag und meine vda ist auch so groß.
Die Anzeige ist normal bei verschlüsselten Systemen, damit Dateigrößen bzw. genutzte Blöcke nicht an das Hostsystem geleaked werden. Bei Bedarf kannst du einen manuellen Trim machen und den Speicher übers SCP optimieren, dann stimmt die Anzeige (zumindest eine Zeit lang) wieder.
Solche Performanceprobleme sollte das aber trotzdem nicht auslösen. Ich hab auch noch einen 7 Jahre alten VPS mit SAS und noch nie solche Probleme gehabt. Dort laufen aber auch keine allzu ressourcenintensiven Sachen.
Das Problem mit der DNS-Auflösung im Rettungssystem hatte ich auch, aber lies sich dann lösen über die Netzwerkkonfiguration über das grml-Menü. Sollte wer bei Netcup vielleicht ins Wiki aufnehmen, vor allem, wenn man mit der Distro noch nie gearbeitet hat. Disk Speed konnte ich wegen Verschlüsselung auch nicht testen.
Ein Reboot (vor dem Gewurschtel mit dem Rettungssystem) hat keine Besserung gebracht, das Aus- und wieder Einschlaten dann schon. Ich dachte erstmal super, Problem gelöst, aber nach ca. 10-12 Stunden war es dann wieder unbenutzbar.
Nach meinem Reboot heute hat sich das Ganze erst mal beruhigt. Die Ursache konnte ich jetzt aber nicht wirklich nachvollziehen. Der Server hatte auch nur eine Uptime von 14 Tagen oder so, also ist jetzt nicht so, als wäre der monatelang durchgelaufen.
Der Server ist erst circa ein Jahr alt mit SSD und Virtio-Treiber.
Welche IOWait-Probleme hattest du denn?
Ich habe eine relativ "aktive" Datenbankanwendung und letzte Woche hatte Postgres ohne erkennbaren Grund immer langsamere Queries. Stellenweise war die CPU auf 100%, aber nur mit IOWait-Last. So 3% IOWait sind im Schnitt mal normal, aber hier waren es teilweise 20% im Durchschnitt eines Tages.
Ich habe den Server vor einer Stunde mal komplett neugestartet, da der Support Benchmarks angefordert hat und bisher sieht es wieder besser aus. Muss ich mal noch eine Weile beobachten. Am besten wären natürlich trotzdem 0% IOWait, falls das mit den Root Servern wahrscheinlicher erzielbar wäre (?).
Aufgrund von ein paar IOWait-Problemen habe ich überlegt von einem VPS auf einen RS zu wechseln, aber wenn ich mir hier die Benchmarks anschaue, hat das vermutlich keinen Vorteil?
Wäre natürlich trotzdem deutlich kundenfreundlicher, wenn die auch irgendwo dokumentiert wären 
Wenn du netcup DNS-Server/Resolver suchst, in den fertigen Images sieht das bei mir auf dem VPS ARM G11 in der /etc/resolv.conf so aus:
Werden die per DHCP verteilt? Wenn ja, hab ich ja keine Garantie dafür, dass die DNS-Server in 2 Jahren überhaupt noch laufen, wenn ich das bei mir statisch hinterlege. Und natürlich wäre ich bei einem Ausfall dann vermutlich selbst schuld, da die ja nirgendwo offiziell dokumentiert sind.
Man bekommt so das Gefühl vermittelt, dass eigene Images nicht verwendet werden sollen.
Ticket aufmachen
Ja, hab ich mir auch schon überlegt.
Ich bin eigentlich auch gerade dabei, einen neuen Server zu konfigurieren und etwas perplex, dass das Netcup-Wiki hierzu scheinbar alle Informationen entfernt hat.
Früher habe ich die Anleitung aus dem Wiki benutzt, um eine statische IPv6-Adresse zu konfigurieren, heute gibt es nur noch eine Anleitung für ein zusätzliches IPv6-Subnetz.
Was ist denn die "offizielle" Konfiguration diesbezüglich? Wenn ich v4 und v6 statisch konfigurieren möchte, müsste ich ja vermutlich zwangsweise irgendwelche DNS-Server angeben. Oder soll/muss v4 auf DHCP bleiben? Einfach irgendwelche öffentlichen DNS-Server nutzen?
Hi,
ich bin mal euren Vorgaben gefolgt @DatAres void und stoße jetzt jedoch auf den Fehler:CodeERROR: Network nginx-proxy declared as external, but could not be found. Please create the network manually using `docker network create nginx-proxy` and try again.Könnt ihr mir sagen, was ich falsch gemacht habe? Es scheint, als hätte ich etwas vergessen.
Viele Grüße
Tobi
Das nginx-proxy Netzwerk ist einfach das Netzwerk deines Nginx Reverseproxys. Wenn das bei dir anders heißt, musst du den Namen natürlich ersetzen.
DMARC mit reject. Was anderes macht für mich eigentlich keinen Sinn.
So kleines Update zum Thema, nachdem ich mal wieder einen Snapshots gebraucht habe: Scheinbar war das Trimmen bereits standardmäßig aktiviert (Ubuntu 18.04), selbst mit LUKS. Mir wurde im SCP mehr als 3x so viel belegter Speicherplatz angezeigt, wie tatsächlich belegt wurde. Nach der Speicheroptimierung war das wieder korrekt. Hat sogar nur ein paar Minuten gedauert statt der angezeigten Stunde. Also kann man wohl nur empfehlen das mal zu machen
Hm ok, ich bin jetzt davon ausgegangen, dass das einen Unterschied macht, da der SSD-Server mit der gleichen Standard-Installationsroutine verschlüsselt wurde (nur unter Ubuntu 20.04 statt 18.04) und dort freier/gelöschter Speicherplatz nach außen sichtbar freigegeben wurde, aber auch nicht auf das GB präzise. Auf den ersten Blick sehe ich hier eigentlich auch keine Konfigurationsunterschiede.
In crypttab haben beide discard eingetragen, in der lvm.conf ebenso, in der fstab fehlt es bei beiden. Nach dem Eintragen sollte das das Hostsystem wohl mitbekommen (?). Fstrim wird laut einem Systemd Timer ja schon wöchentlich ausgeführt.
Der einzige "Nachteil" wäre wohl, dass theoretisch oberflächliche Infos zu Dateien oder zum Filesystem nach außen geleaked werden könnten. Von daher würde mir der Trim eigentlich auch manuell bei Bedarf ausreichen, wenn mal ein Snapshot o.ä. gebraucht wird.
