Ich habe einen V-Server bei Strato. Am 2018-09-07 war der Server 17 hrs, 21 mins nicht erreichbar, so UptimeRobot. Strato möchte mir nun unterstellen, das sei meine Schuld im Sinne eines schlecht konfigurierten Servers gewesen. Wie kann ich nachweisen, daß es an Strato lag?
wenn du so fragst...garnicht. laut vertrag hast du sicherlich auch nur ein sla von <=99,5% im jahresmittel....von daher wäre 1 tag downtime absolut ok..
indem du eine Backup deiner Konfiguration vorlegst
Thomas O. schrieb: > indem du eine Backup deiner Konfiguration vorlegst Das beweist garnichts. Er müsste nachweisen, dass er die Konfiguration des Servers in der fraglichen Zeit nicht verändert hat, und die Datenaufzeichnungen dazu hat wer? Richtig, Strato. Georg
Oleg Krapp schrieb: > das sei meine Schuld im Sinne eines schlecht > konfigurierten Servers gewesen Mal dort fragen WAS denn schlecht war? Nur so könnte man Fehler vermeiden.
Evtl. alle paar Stunden ein verschlüsseltest Backup auf den Server legen, das könnte man dann selber wieder runterladen und zur Analyse teilt man Strato das Passwort mit, so können die nichts selber dran verändern.
Hallo, vergiss es - faktisch ist der beweis nicht führbar. Die „grossen“ Provider sind da mit allen Salben geschmiert. Wir hatten mal einen Server mit defkten Ram, der über den 1.Mai ausgefallen ist. Mit sehr eindeutigen beweisen (Memtest Remote gebootet). Nix bekommen. Einfach einen vernünftigen (=keinen günstigen) Hoster nehmen, jemanden, bei dem man mehr Kontrolle hat (Aws, Azure & Co.) oder Redundanzen bauen. Wie Werner Vogels (CTO Amazon) sagt: “Everything fails all the time” Grüsse!
Thomas O. schrieb: > Evtl. alle paar Stunden ein verschlüsseltest Backup auf den Server > legen, Prüfsummen sind auch schön. Hilft leider nur bei statischen Daten, aber kaum wenn ein Dienst hängt oder 99% hat. §1: Einige Logfiles legt man nie auf den selben Rechner, weil der bei Fehler oder Diebstahl nicht mehr zu erreichen ist.
derwildearmin schrieb: > Einfach einen vernünftigen ... Hoster nehmen, Auch bei vernünftigen Hostern kann ein Bagger oder der Strom die Ursache sein. Man sollte selbst gelegentlich prüfen, ob seine Sachen noch gut laufen um rechtzeitig reagieren zu können.
oszi40 schrieb: > derwildearmin schrieb: >> Einfach einen vernünftigen ... Hoster nehmen, > > Auch bei vernünftigen Hostern kann ein Bagger oder der Strom die Ursache > sein. Man sollte selbst gelegentlich prüfen, ob seine Sachen noch gut > laufen um rechtzeitig reagieren zu können. Das wird bei einem entsprechend konfigurierten Dienst in der AWS cloud aber schon sehr schwer. Amazon betreibt in Frankfurt drei örtlich getrennte unabhängige Rechenzentren, ein ELB davor geschaltet (https://aws.amazon.com/de/elasticloadbalancing/) -der ist per se Hochverfügbar- und dem Bagger ist der Schrecken gnommen. Ansosnten über mehrere Standorte verteilen. Was das kostet? Weniger als man denkt. Technisch allerdings etwas anspruchsvoller als das 2,99 Hosting von Strator, 1&1 und Co. Grüsse!
derwildearmin schrieb: > Das wird bei einem entsprechend konfigurierten Dienst in der AWS cloud > aber schon sehr schwer. Dann hast du aber keinen Server, den du administrierst, sondern einen Service, der "irgendwo" in der Cloud läuft. Völlig anderes Prinzip.
Oleg Krapp schrieb: > Ich habe einen V-Server bei Strato. Am 2018-09-07 war der Server 17 hrs, > 21 mins nicht erreichbar, so UptimeRobot. Strato möchte mir nun > unterstellen, das sei meine Schuld im Sinne eines schlecht > konfigurierten Servers gewesen. Wie kann ich nachweisen, daß es an > Strato lag? Hast du denn genau nach den 17h und 21min irgendwas getan? Oder hat Strato zu dem Zeitpunkt etwas getan? Also wieso lief es denn plötzlich wieder? Du gibst hier zu wenig Infos...
:
Bearbeitet durch User
derwildearmin schrieb: > Amazon betreibt in Frankfurt drei örtlich > getrennte unabhängige Rechenzentren, ein ELB davor geschaltet > (https://aws.amazon.com/de/elasticloadbalancing/) -der ist per se > Hochverfügbar- und dem Bagger ist der Schrecken gnommen. Es wäre nicht das erste "Hochverfügbare", was trotzdem ausfällt...
Reinhard S. schrieb: > Es wäre nicht das erste "Hochverfügbare", was trotzdem ausfällt... Auch das Umschalten eines Clusters erfordert Wissen und Glück. Es wäre nicht der Erste,der hängt oder flattert.
Hallo, S. R. schrieb: > Dann hast du aber keinen Server, den du administrierst, sondern einen > Service, der "irgendwo" in der Cloud läuft. Völlig anderes Prinzip. Leider falsch ;-) Es handelt sich um EC2 Instanzen (das sind VMs, über die man die komplette Kontrolle hat). Diese werden hinter einen Load Balancer geschaltet, das ist dann wirklich ein Dienst, aber einfach zu konfigurieren. Beim Anlegen der Instanzen kann man definierten, wo diese laufen sollen. Grüße
mirfaelltnixein2006@yahoo.dr schrieb: > Leider falsch ;-) Dann riskierst du aber wieder einen Ausfall der Server- oder Kommunikationsinfrastruktur. ;-) Redundanz hätte hier möglicherweise auch geholfen (falls nicht vorhanden), ist aber ein anderes Thema.
Hallo, S. R. schrieb: > Dann riskierst du aber wieder einen Ausfall der Server- oder > Kommunikationsinfrastruktur. ;-) Eben nicht - selber schon gebaut. Server A steht in Frankfurt in RZ1 Server B steht in Frankfurt in RZ2 Davor ein Loadbalancer (ELB - siehe Link oben), die werden von Amazon hochverfügbar bereit gestellt und werden auch über mehrere Rechenzentren verteilt. Es gibt in dem Setup keinen Single Point of Failure. Oder reden wir einander vorbei? Grüße
mirfaelltnixein2006@yahoo.de schrieb: > Oder reden wir einander vorbei? Ein bisschen. Du redest von Redundanz und hast 2 Server in 2 Rechenzentren. Damit kannst du den Ausfall eines Servers zwar wegstecken, Ausfallen können allerdings immernoch beide (mit deutlich geringerer Wahrscheinlichkeit). Als Cloudservice spielt es theoretisch keine Rolle mehr, wieviele Server gerade tot sind und welche RZs gerade vom Netz abgeschnitten sind, weil du nur noch einen Service betreibst, keine Server. Ist halt ein völlig anderes Prinzip. Angewiesen auf die Kompetenz eines (oder mehrerer) Server-Anbieters bist du in beiden Fällen.
oszi40 schrieb: > Auch das Umschalten eines Clusters erfordert Wissen und Glück. Es wäre > nicht der Erste,der hängt oder flattert. Normalerweise baut man das so, dass nur der Failover automatisch erfolgt.
A. K. schrieb: > Normalerweise Normalerweise funktioniert das auch gut (bis auf wenige Ausnahmen). mirfaelltnixein2006@yahoo.de schrieb: > Es gibt in dem Setup keinen Single Point of Failure. Der Pessimist ist ein Optimist, der durch seine Fehler gelernt hat.
@mirfaelltnixein2006 nur weil amazon/auure damit wirbt heißt es nicht, dass das kram auch immer funktioniert. guck dir einfach mal die ausfälle der letzten 5 jahre an... selbst google hatte letztens einen ausfall der ultrahochverfügbaren loadbalancer. auch geo-bgb-announcements helfen im fall der fälle nur bedingt...
Oleg Krapp schrieb: > Ich habe einen V-Server bei Strato. Am 2018-09-07 war der Server 17 hrs, > 21 mins nicht erreichbar, so UptimeRobot. Strato möchte mir nun > unterstellen, das sei meine Schuld im Sinne eines schlecht > konfigurierten Servers gewesen. Wie kann ich nachweisen, daß es an > Strato lag? Wir haben mal nachgesehen ob unser server am 7.9. nicht erreichbar war. Fehlanzeige! Ich vermute eher dass dein ISP nicht zu Strato durchgekommen ist. Wenn bei euch eine Verbindungslinie ausfällt, könnt ihr zwar euren server nicht emrh erreichen, der server ist dennoch erreichbar. Strato kann also nichts dafür, da müsst ihr zu eurem Provider oder dieser zu seinen.
aws, docker & kybernetes, elastic beanstalk...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.