Nachweis, daß der Server nicht der Konfiguration wegen nicht erreichbar war

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..

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.

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!

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

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

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...