Forum: PC Hard- und Software Nachweis, daß der Server nicht der Konfiguration wegen nicht erreichbar war


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Oleg Krapp (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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?

von TestX (Gast)


Bewertung
6 lesenswert
nicht lesenswert
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..

von Thomas O. (kosmos)


Bewertung
0 lesenswert
nicht lesenswert
indem du eine Backup deiner Konfiguration vorlegst

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von oszi40 (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Thomas O. (kosmos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von derwildearmin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von derwildearmin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Alex G. (dragongamer)


Bewertung
2 lesenswert
nicht lesenswert
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
von Reinhard S. (rezz)


Bewertung
0 lesenswert
nicht lesenswert
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...

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von mirfaelltnixein2006@yahoo.dr (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von mirfaelltnixein2006@yahoo.de (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von TestX (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@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...

von Knallex (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von oldschooldev (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
aws, docker & kybernetes, elastic beanstalk...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.