Zum Inhalt springen

Empfohlene Beiträge

Geschrieben

Wenn ich das ganze halbwegs Verstanden habe geht es um ein System im Produktionsnetz das bei Fehlern Mails absetzen soll.

Das System ist also ganz offensichtlich in dieser Rolle ein Mail Client.

Die Frage scheint zu sein ob dieses System den normalen Mailserver des Büronetzes verwenden soll (vermutlich MTA/MSA/MAA) oder einen eigenen Mailserver im Produktionsnetz bekommen soll.

Ein zweiter Mailserver im Produktionsnetz ist imho sinnfrei, da er vermutlich nur ein MTA wäre - Mailboxen würden da wohl eher nicht liegen. Es kann gewünscht sein wenn viele Maschinen im Produktionsnetz Mails verschicken, denn dann würden sie alle über den Produktions-MTA gehen und man benötigt nur eine strikte ACL im trennenden Router.

Vorteile für 2 MTAs: ACL bleibt übersichtlich, kein fehlkonfiguriertes System kann wild Mails verschicken

Nachteile: Eine zusätzliche Maschine die gekauft, gewartet, gepatcht und überwacht werden muss.

Geschrieben
Wenn ich das ganze halbwegs Verstanden habe geht es um ein System im Produktionsnetz das bei Fehlern Mails absetzen soll.

Das System ist also ganz offensichtlich in dieser Rolle ein Mail Client.

Die Frage scheint zu sein ob dieses System den normalen Mailserver des Büronetzes verwenden soll (vermutlich MTA/MSA/MAA) oder einen eigenen Mailserver im Produktionsnetz bekommen soll..

Korrekt.

Ein zweiter Mailserver im Produktionsnetz ist imho sinnfrei, da er vermutlich nur ein MTA wäre - Mailboxen würden da wohl eher nicht liegen. Es kann gewünscht sein wenn viele Maschinen im Produktionsnetz Mails verschicken, denn dann würden sie alle über den Produktions-MTA gehen und man benötigt nur eine strikte ACL im trennenden Router.

Wäre es nicht denkbar, dass die Rechner die im Produktionsnetz liegen eigene Email-Clients verwenden. Also ganz ohne Anschluß an den Büro - Exchange.

Diese Clients würden nur die Alarm Mails empfangen ?

Würde sich doch relativ einfach einrichten lassen, oder ?

Geschrieben

Wäre es nicht denkbar, dass die Rechner die im Produktionsnetz liegen eigene Email-Clients verwenden. Also ganz ohne Anschluß an den Büro - Exchange.

Diese Clients würden nur die Alarm Mails empfangen ?

Würde sich doch relativ einfach einrichten lassen, oder ?

Sicher ist das denkbar. Ob die Einrichtung einfacher ist sei mal dahingestellt, da tut sich nicht viel. Ist eher ein organisatorisches Problem.

Eine weitere interne Maildomain (Produktionsnetz) steht allein. Liest da dann auch jemand regelmäßig Mails? Ist es auch der, der es wissen sollte wenn ein Fehler auftritt?

Würde eine solche interne Maildomain nicht eh dazu führen das Mitarbeiter später verlangen von dort auch ins Büronetz mailen zu können? Dann war der Aufwand sinnlos.

Ab hier kann man nur noch mutmaßen. Die Umstände sind immer verschieden.

Geschrieben (bearbeitet)

Wäre es nicht denkbar, dass die Rechner die im Produktionsnetz liegen eigene Email-Clients verwenden.

Ein Client reicht bei Empfang der Mails nicht aus. Um Mails empfangen zu können, brauchst Du schon einen MTA.

Aber warum das ganze per Mail !? Wenn der Mailserver down ist, dann nützt die ganze Benachrichtung nichts. Ich kann das jetzt aus der Nagios Sicht sehen, d.h. mein Nagios sammelt via SNMP (oder anderen Mechanismen) Informationen über die Verfügbarkeit der Dienste. Alleine diesen Dienst kann man redundant betreiben, d.h. fällt Nagios aus, habe ich hier direkt die Redundanz. Der Nagios Dienst kann, wenn eben die Dienste nicht korrekt funktionieren eine SMS und/oder Mail generieren und versenden. Wenn man eben die SMS versendet, dann würde man die Hardware dafür direkt an das Nagiossystem anschließen. Bei Mail ist wieder das Problem, was passiert wenn der MTA nicht funktioniert (oder das LAN). Zusätzlich kann man bei Nagios auch über ein FF Browserplugin sehen, ob alles okay ist.

Irgendwie entsteht bei mir der Eindruck, dass hier ein Planungsproblem vorliegt. Denn die Fragestellung heißt doch "wie bekomme ich zuverlässig mit, dass etwas nicht in Ordnung ist" und nicht "wie versende ich automatisch Mails". D.h. die Benachrichtigung muss über verschiedene Medien transportiert werden, damit bei dem Ausfall eines Mediums trotzdem die Chance besteht, dass die Benachrichtigung empfangen wird. Ein Medium kann Mail sein, wobei eben der Dienst, der die Benachrichtigung generiert eben einen SMTP Dienst nutzt und der SMTP Dienst muss natürlich eben auch mit dem Zielsystem kommunizieren können, so dass die Mail korrekt zugestellt werden kann. Der entsprechende Mitarbeiter muss dann die Mail z.B. via POP3 oder IMAP abholen, wobei hier ein weiterer Dienst (und damit eine Fehlerquelle) entsteht. Was ist z.B. wenn der Mitarbeiter in Urlaub oder krank ist!? Wenn ich jetzt auf den Transfer der Mails beschränke, dann muss der Benachrichtigungsdienst per SMTP mit einem MTA kommunizieren und auf diesem System muss ein Client via POP3 oder IMAP Zugriff auf die Mails erhalten. SMTP, POP3 / IMAP kommunizieren letztendlich über IP, d.h. diese Struktur muss ebenfalls funktionsfähig sein (und die Route zwischen Benachrichtigungsdienst und ZeilMTA immer überwacht werden).

Ich würde aber noch einmal vorschlagen, dass Du das Konzept etwas überdenkst, denn bei Ausfällen ist nicht nur relevant, dass eine Benachrichtigung generiert wird, sondern auch dass diese Information den zuständigen Mitarbeiter erreicht. Wenn z.B. die Benachrichtigung generiert wird, aber z.B. eine ACL im Router gesetzt wurde, dass SMTP Pakete blockiert werden, dann wird die Benachrichtigung nicht zugestellt und es scheint so, dass alles in Ordnung wäre. Wenn das funktioniert, aber z.B. der MTA die Mail in der Queue behält ohne sie in die Postbox des Empfänger zu werfen, weil z.B. die Festplatte voll ist, dann scheint für den Benutzer auch alles okay. Wohin gegen ein defekter POP3 / IMAP Dienst dem User auffällt, sofern er die Mails regelmäßig abfragt.

Ich finde dass das Problem etwas zu kurz geplant wurde, da solche Probleme doch erheblichen wirtschaftlichen Schaden nach sich ziehen können

Bearbeitet von flashpixx
Geschrieben (bearbeitet)
Aber warum das ganze per Mail !? Wenn der Mailserver down ist, dann nützt die ganze Benachrichtung nichts.

Deine Argumente sind nicht von der Hand zu weisen.

Bringt mich allerdings doch wieder auf die Möglichkeit die Alarme via SNMP zu einem Visualsierungssystem zu versenden und dort anzuzeigen.

Da es ein SCADA - System mit eigenem Alarm Logging ist, kann man dort auch

bereits gekommene und wieder gegangene Fehler noch mal nachträglich abfragen.

Das SCADA- System ist redundant.

Für mich bedeutet das dann aber mehr Konfigurationsaufwand.:(

Ich muss dann auf beiden Seiten gleiche OPC - Variable anlegen.

Das sind jede Menge :(:(

Bei der Email Geschichte muss ich nur den SMTP Server und den Email- Empfänger angeben und ich bin fertig.

Bearbeitet von Eleu
SMNP in SMTP geändert
Geschrieben

Bringt mich allerdings doch wieder auf die Möglichkeit die Alarme via SNMP zu einem Visualsierungssystem zu versenden und dort anzuzeigen.

Das ist doch das gleiche in grün! Wenn zwischen den Systemen z.b. ein Router steht oder ein Switch, also eine Ethnert bzw IP Verbindung bestehen muss und diese ausfällt oder z.B. der Router wegen eines Updates falsche ACLs hat oder die VLANs im Switch falsch eingetragen sind, dann nützt Dir das rein gar nichts, weil Deine SNMP Pakete niemals ankommen. Da Du nicht die ganze Zeit an dem System sitzt wirst Du das auch nicht mitbekommen.

Für mich bedeutet das dann aber mehr Konfigurationsaufwand.:(

ich denke das ist der Kern des Problems, dass eine entsprechende Struktur zu Arbeit führt

Bei der Email Geschichte muss ich nur den SMNT Server und den Email- Empfänger angeben und ich bin fertig.

SMNT gibt es nicht, ich gehe davon aus, dass Du SMTP meinst.

Es ist damit eigentlich nicht getan irgendwo einen Mailempfänger & -server einzutragen, damit ist das Problem nicht vom Tisch: Was ist wenn der MTA oder der Weg dorthin ausfällt, Redundanz des SCADA Systems nützt da nichts, weil sofern das Netz nicht redundant ausgelegt ist die Mail nicht ankommen kann. Weiterhin ist der SMTP Server nur für den Empfang der Mail, davon kann der User seine Mails noch nicht lesen, d.h. Du brauchst hier einen weiteren Dienst. Wenn Du einen bestehenden Dienst hast, dann kannst Du den nutzen, aber die Problematik mit dem Ausfall der darunterliegenden LAN Strukur bleibt bestehend oder eben, dass der User einfach seine Mails nicht liest (Krankheit / Urlaub)

Geschrieben
Das ist doch das gleiche in grün! Wenn zwischen den Systemen z.b. ein Router steht oder ein Switch, also eine Ethnert bzw IP Verbindung bestehen muss und diese ausfällt oder z.B. der Router wegen eines Updates falsche ACLs hat oder die VLANs im Switch falsch eingetragen sind, dann nützt Dir das rein gar nichts, weil Deine SNMP Pakete niemals ankommen. Da Du nicht die ganze Zeit an dem System sitzt wirst Du das auch nicht mitbekommen.

Wieso ? Bei einem SCADA System wird das Fehlerbit unmittelbar erfasst und eine entsprechend projektierte Meldung wird angezeigt.

Diese Meldung wird überdies mit Uhrzeit für "Kommt" und "Geht" in einem Archivspeicher abgelegt.

M.E. bleibt auch bei Netzproblemen der Fehler im Steuerungssystem erhalten.

Sind die Netzwerkprobleme behoben wird der Fehler wieder vom Scada System erfasst.

Beispiel:

In der Steuerung gibt es eine Variable "Steuerung 4 Lüftertemperatur"

Im Scada System gibt es ebenfalls eine Variable "Steuerung 4 Lüftertemperatur"

Übersteigt die Temperatur z.B. 100 °C generiert das SCADA- System eine frei programmierbare Meldung.

Aber Du hast natürlich recht, sicherlich wäre ein redundant ausgelegtes Netzwerk besser.

Das zu projektieren ist ein ziemlicher Aufwand...aber dafür viel sicherer, da man bei kritischen Alarmmeldungen überdies auch noch automatisierte Prozesse auslösen kann. (Alarmhupe o.ä.) QUOTE]

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...