Auf dieser Seite findest Du eine Übersicht der APC-Modelle und ihrer Funktionen. Aktualität unbekannt.
RETPCT
: Battery charge % required after power off to restore power
Grüße
galleto
Zu 1) IBM UPS1000THV, Rest dürfte beantwortet sein
Ich möchte die Idee der „Cloud-Watchdogs“ nochmal aufgreifen… Was genau soll der denn bewirken? Ich meine was ist denn wenn irgend ein Server-Verbund im Netz feststellt, dass irgend ein IPS bei einem zu Hause nicht mehr erreichbar ist?
Toni
Na, da gibt’s ne Reihe von Möglichkeiten:
Beim Bundespräsidialamt anrufen oder der Kanzlerin eine e-mail schicken.
Na, mal ernsthaft:
Eine (oder mehrere) e-mail(s) versenden?
Eine SMS Versenden?
Irgendwie den, der Zuständig für die Kiste ist, informieren, weil es die eigene Kiste (offenbar) nicht mehr kann?
jwka
Na wenn das alles ist…
Hab grad etwas Ähnliches für einen Kunden gemacht. Allerdings in seinem lokalen Netzwerk. Wenn man beim Endanwender DynDNS und am Router eine konfigurierte Firewall samt Portweiterleitung voraussetzt fehlt eigentlich nur noch ein zentraler Mailserver als Verteiler (freemail, googlemail oder so). Dann könnten sich die IPS-Server der Teilnehmer gegenseitig übers Internet überwachen.
Einfacher wäre es wohl einen virtuellen Server im Netz zu betreiben und den ganzen Cloud-Overhead einzusparen. Wenn der allerdings selbst grad nicht erreichbar ist… :rolleyes:
Ein lokaler Watchdog hat natürlich den Vorteil, dass er gleich Gegenmaßnahmen einleiten könnte wenn er noch läuft. Vielleicht kann man diese Eigenschaften auch kombinieren indem man das Problem in einen Server- und einen Client-Part unterteilt.
Reines Gedankenspiel im Moment…
ich frag mich immer noch, warum ich auf Biegen und Brechen eine Homeautomation online haben muss, wenn ich a) der Strom ausgefallen ist b) längere Zeit nicht zu Hause bin und c) ich keine Ressource vor Ort habe, die im Fehlerfall helfend eingreifen kann (zumindest sind das die Rahmenbedingungen, die ich meine, aus jwka’s Postings herausgelesen zu haben).
Meine spontane Überlegung wäre dazu: kurze Stromausfälle werden mit ner USV überbrückt, längere Stromausfälle werden mit kontrolliertem Runterfahren gemanaged (und zwar nicht hibernate, sondern runterfahren). Warum um alles in der Welt muss das System online bleiben? Mag sein, dass es auch hier Gründe gibt, ich kann sie aber in den Postings nicht finden.
Dass die jüngste Diskussion auf die „ganz speziellen“ Rahmenbedingungen von jwka gescoped ist, ist ja ok, aber um hier wirklich zielführend Lösungsansätze zu diskutieren, vermisse ich
- eine genaue Analyse und strukturierte Auflistung der potenziellen Fehlerursachen
- zu den Fehlerursachen passende Zielformulierungen (was will ich erreichen).
Das einzige Problem, was -glaub ich- hinreichend klar und nachvollziehbar besprochen wurde, ist das Stromversorgungs-Desaster in Andalusien. Aber auch hier gab es von jwka auf jeden Vorschlag nur zig Argumente, warum das alles nicht geht. Mag sein, dass das wirklich so ist.
Aber zum Thema Failover, vermaschte Überwachung und was da noch so alles an Lösungen im Raume schweben, habe ich bisher weder klar zuzuordnende Ursachen noch Zielformulierungen gelesen (oder nicht verstanden).
Statt dessen wird über verschiedenste Lösungsansätze diskutiert (die -für sich allein stehend absolut diskussionswürdig - weil technisch interessant - sind), aber in diesem Thread-Kontext frage ich mich immer wieder: wozu? Gegen welches spezielle Problem soll der Vorschlag helfen?
Noch dazu habe ich den Eindruck, das Eines dem Anderen widerspricht (beispielhaft):
Irgendwie den, der Zuständig für die Kiste ist, informieren, weil es die eigene Kiste (offenbar) nicht mehr kann?
Hattest Du, jwka, nicht geschrieben, dass du im Falle Deiner (mehrmonatigen) Abwesenheit vor Ort auf keine Ressourcen zugreifen kannst, die qualifiziert unterstützen können? Selbst wenn (ich verweise wieder auf das transparente Szenario „Stromausfall“): was soll derjenige tun?
Hört sich vielleicht wie Nörgelei an (könnte ich sogar nachvollziehen :D), aber irgendwie würde ich mir wünschen, dass dies eine zielführende, lösungsorientierte Diskussion wird (und damit will ich keine Einzelbeiträge abwerten, keinesfalls). Dann haben vieleicht noch mehr User was davon 
Das mit der „Cloud“ hat - neben dem Ausfalldilemma des (zentralen) Servers - noch den Vorteil, dass auch bei Ausfall eines Segments im Internet die Wahrscheinlichkeit von Fehlmeldungen geringer ist, weil sich der „scheinbar Tote“ immer noch bei anderen Servern melden wird und evtl. diese sogar dann den anderen mitteilen könenn, wer verfügbar ist und wer nicht.
Und wenn es keine reine IPS-Abbildung gibt, können ja beliebige Server in einem solchen Netzwerk mitmachen.
Ich stelle mir ein echtes Mesh vor, wo sich Server gegenseitig (zufällig) Listen verfügbarer Server (plus „Abtastzeit“ schicken, aus denen man dann am Ende eine recht sichere „ist nicht verfügbar“ Aussage ableiten - und ggf. auch vor Meldung nochmals prüfen - kann.
@raketenschecke:
Toni hat gerade, und andere weiter oben auch schon, nicht zum Thema „jwka-Stromproblem“ gesprochen, was ich auch sehr begrüße.
Lass es einfach mal gut sein damit.
@all
Da es scheinbar an klaren Vorgaben mangelt:
Ich Frage hier gezielt nach Möglichkeiten und Vorbereitungen, ein System in Abwesenheit (mehr als nur ein paar Stunden während des „normalen Alltags“ - nehmen wir einfach mal an, 4 Wochen Urlaub?):
1.) So gut und lange es geht, Aufrecht zu erhalten
2.) bei Problemen (die nicht zwangsläufig zum Ausfall führen müssen) diese frühzeitig gemeldet zu bekommen um ggf. Maßnahmen vorzubereiten
3.) Im Falle des Ausfalls wieder Herzustellen, ohne selbst dabei sein zu müssen - soweit es eben geht. Könnte ja auch nur der Ausfall eines Teilsystems sein.
Beispiele:
Es macht z.B. nicht so richtig Spass, wenn man - vielleicht erst nach ein paar Tagen - mal eben über die IP Cam zuhause nach dem Rechten sehen möchte und nix geht - weil vielleicht schon seit zwei Tagen das Wasser einen halben Meter hoch im Keller steht.
Wenn „nur“ der Switch ausgefallen ist, kann evtl. noch ein Teilsegment gehen und es gibt dafür vielleicht auch eine Redundanzmöglichkeit.
Beim Ausfall des Internet könnte es via Modem, UMTS, ??? eine Möglichkeit geben, dies mitzuteilen. Dann kann man „später“ nochmal reinsehen oder bei der Telefongesellschaft nachfragen.
Und es gibt ja auch Leute, die „bessere“ Nachbarschaften haben, als ich.
Und noch was: Wenn ich eine Möglichkeit habe, herauszufinden dass SICHER sein ein Eingriff (und am besten noch recht exact, welcher) nötig ist, kann man sich auch aus der Ferne Techniker hinzurufen.
Es ist nur ziemlich ärgerlich, wenn man ein paar Hundert Euro zahlen soll, bloss weil vielleicht irgendeine Lappalie - z.B. Ausfall eines Internetsegments - vorgefallen war.
Auch die Feststellung, dass man nichts tun KANN (Stromausfall in einer ganzen Region) hilft in der Ferne, denn es bleibt keon komisches Gefühl, dass da vielleicht Vandalen in der Wohnung sind, und- inclusive Server - alles zerstört haben (Extrembeispiel).
Für bestimmte „kleinere Havarien“ gibt es daneben auch Dinge, deren Reparatur man auch für Laien vorbereiten kann. Ich habe z.B, auf dem Router einen zweiten stehen, komplett eingerichtet, versteht sich (NAT, Portweiterleitung, Passworte). Da muss der Laie nur drei (unterschiedliche und daher nicht verwechselbare) Stecker umstecken und das ist machbar.
Vielleicht gibt’s noch viele solche Dinge?
jwka
nun ja, solange du nicht mit konkreten Fakten (besser noch: Ursachen) rüber kommst, auf die man Lösungen entwickeln kann, und immer wieder wild alle möglichen Szenarien und Ansätze durcheinander geworfen werden, ist das hier eine ziemlich akademisch/theoretische Diskussion.
Das ist in etwa der Aktionismus, den ich in der IT vor 10 Jahren und in der TK-Branche vor 5 Jahren erleben durfte. Exakt die selben Verhaltensmuster: Sypmtom identifiziert, innnerhalb kürzester zeit mit nem Patchwork drauf geschossen, koste es, was es wolle. Ob das die eigentlichen, ursächlichen Probleme gelöst hat…war eigentlich egal.
Servus
ich kann Erkläbärs letzten Post nur zustimmen.
Versuche dein Problem nicht als ganzes zu sehen über da du dann die große Cloud stülpen willst (bildlich gesprochen).
Sonderen teile dein Problem in mehrere kleine eindeutig voneinander abgegrenzte Fälle auf.
Für diese kannst du dann im Regelfall auch ganz dediziert Ursache - Wirkung - Gegenmaßnahme definieren.
Diese Liste dann sukzessive abarbeiten und du wirst irgendwann bei einem stabilen System bzw. kontrollierten und verstandenem Systemverhalten landen.
Ja, das ist Knochenarbeit, aber lohnt sich. Ich arbeite in der Chipindustrie, da machen wir das ständig um einerseits die Qualität zu erhöhen und andererseits unter stabilen Bedingungen produzieren zu können.
Kurz gesagt, du mußt DEINE Probleme das systematisch angehen. Sonst wirds nix.
@Toni: für deinen Vorschlag hab ich ein paar Posts weiter vorne den Einsatz eines alten Smartphones erwogen.
Vorerst muß jwka aber mal systematik reinbringen, dann gehts weiter.
schöne grüße
bb
Wenn man unbedingt ein Cloud Watchdog haben will, wäre der imho recht einfach zu realisieren.
Serverliste a,b,c,d,e
Normales Verhalten: a fragt b ob er lebt. b fragt dann c, c fragt e und e fragt a ab (vielleicht mit ner Verzögerung).
Ausfallszenario: A fragt B - keine Antwort. A sendet Mail, A fragt C ab (ist C auch tot geht er zu D über usw.). C stellt fest A callt mich und nicht B und setzt seinerseits auch noch mal ne Mail an B ab. Und dann halt normal weiter.
Da sollte völlig reichen da muss nich wild jeder, jeden anfunken.
Gruß,
Jan
Rakete hat Recht. Solange kein klares Ziel, in diesem Fall die Lösung eines konkreten Problems, benannt ist bleibt die Diskussion oberflächlich.
Ich kann ja mal mit voller Streuung einen Fächer abschießen:
[ul]
[li] Den IPS-Server von extern anpingen stellt fest ob dieser generell erreichbar ist.[/li][li] optional einen Weiteren Server im lokalen Netz anpingen gibt Auskunft darüber ob das Problem globaler Natur ist.[/li][li] Ein Portscan vorher festgelegter Ports (WebIf/SOAP Schnittstelle/SSH) gibt Auskunft über die „Kommunikationsbereitschaft“ des Servers.[/li][li] Über die SOAP-Schnittstelle mit IPS kommunizieren um zu sehen ob der Dienst gestartet ist und reagiert[/li][li] ggf auch das Webinterface auf reaktion prüfen.[/li][li] ein lokaler Dienst auf dem IPS-Server könnte zusätzlich optional Informationen sammeln und der cloud ggf zwecks Fehlermeldung zur Verfügung stellen.[/li][/ul]
DynDNS/feste IP und eingetragene Route, angepasste Firewall und Portfreigabe sind natürlich Bedingung für so ein Vorgehen.
Wenn es nur die Überwachung eines Servers sein soll ohne IPS-spezifische funktionen dann gibts ja Dienste wie Pingdom.com.
Toni
Ich glaube, auf solche konstruktiven Vorschläge hat der Themenstarter eigentlich gewartet! Prima.
Deine Liste ist doch erst mal Klasse und ein sehr guter Start für eine sich mehr und mehr füllende Anforderungssammlung.
ICh würd gerne noch dazu fügen, dass die Tests irgendwie klassifiziert werden sollten und man sicher stellen muss, dass es ein gewisses „Mesh“ gibt, welches z.B. Internet-Segmantausfälle kompensieren kann, damit Meldungen mit recht großer Sicherheit auch tatsächlich auf den Ausfall eines Servers/Service und nicht etwa die externe Infrastruktur zurück zu führen sind.
Beispiel:
Server_1 kann Server_A nicht erreichen, aber Server_2 kann das und Server_2 kann auch (vielleicht sogar über weitere Server?) Server_1 erreichen.
–> keine Meldung erzeugen, weil die Nichterreichbarkeit ja offenbar nicht am Server_A liegt
Oder anders: Die Liste nicht erreichbarer Server&Services auf Servern muss quasi je abgefragtem Server hochgezählt werden und erst ab einem bestimmten kritischen Wert wird reagiert.
Dass es das, was wir da gerade durchdenken, vielleicht sogar schon gibt, könnte ich mir auch denken. Aber ich habe da noch keine tiefere Recherche angestellt.
Und natürlich würe es schon interessant, auch eine Info für die Meldung an den zur Verfügung zu haben, die dem empfangenden Admin hilft, näheres zu sehen. Sowas könnten ja interne Statusmeldungen sein, die mittels PGP verschlüsselt und so nur vom „autorisierten“ Admin zu lesen sind.
Solche können dadurch generiert werden, dass der IPS Server in bestimmten Abständen Protokolle erzeugt, diese verschlüsselt und an die beteiligten Mesh Server sendet …
Weiss nicht. Mein ursprüngliches Thema war sehr allgemein formuliert, weil ich von den vielen unterschiedlichen Ansätzen, Erfahrungen und überlegungen etwas lernen wollte. Aus meiner Sicht hat das prima geklappt und war ein Gewinn für mich (und vermutlich für viele Andere). Die Power eines gemeinsamen Brainstorms ist nicht zu unterschätzen!
Aber einverstanden - wenn es dann um ein konkretes Projekt geht, muss man konkreter werden.
Das ist ein wirklich sehr guter Hinweis - danke! Hatte ich nicht gekannt. Das löst schon mal 90% meiner Ueberwachungsprobleme!!!