Arbeitsgruppe Mailinglisten/Konzept dezentrale Server

Aus Freiheit statt Angst!

Version vom 01:07, 26. Jun. 2009

Alternativkonzept für dezentrale Mailinglistenserver

Einige Ortsgruppen oder AK Mitglieder betreiben schon Server auf denen ein Teil der Mailinglisten mitlaufen könnte.

Auf diese Weise

• ist das Risiko des Totalausfalls gering
• ist ggf. der Aufwand zur Totalüberwachung größer
• ist der Ressourcenaufwand pro Server überschaubar
• wird der Zusammenhalt und die Aktivität in der Regio gefördert
• steigern wir die technische Kompetenz der AK-Mitglieder auf breiterer Basis

Hier soll ein Konzept entwickelt werden, wie dies umgesetzt werden kann.

Benennung der Listen

Da die Listen auf unterschiedlichen Servern laufen müßten sie auch unterschiedliche Domainnamen haben. Je nach Anzahl verfügbarer Server würden sich verschiedene Schemata anbieten.

nach Region

z.B. Ortsgruppen nach Region

• hamburgnord.ak-vds.de
• muenchensued.ak-vds.de
• koelnwest.ak-vds.de

Zentrallisten ohne Subdomain

• mlak-vds.de

nach Funktion

z.B. alle Ortsgruppenlisten auf einem Server:

• hamburgog.ak-vds.de

eventuell Arbeitsgruppenlisten auf einem zweiten Server:

• technikag.ak-vds.de

Zentrallisten auf anderem Server ohne Subdomain

• mlak-vds.de
• diskussionak-vds.de

Hauptlisten auf unterschiedlichen Servern

Zur besseren Ausfallsicherheit der Hauplisten:

• mllists1.ak-vds.de
• diskussionlists2.ak-vds.de

Redundante "HA"-Lösung

Eine Lösung mit unterschiedlichen Listen-Adressen ist für "normale" Benutzer nicht unbedingt einfach zu handhaben, zumal auch erstmal erkannt werden muß, daß der primäre Server nicht funktioniert. Außerdem wird dies unter Umständen zur duplizierung der Mails sorgen, da Nutzer erst an den einen, dann an den anderen schicken.

Eine Umsetzung mit zwei (oder mehr) gleichwertigen MXen sollte dagegen technisch mit moderatem Aufwand umzusetzen sein. Voraussetzung dabei wäre aber, daß die Administration der Benutzer nur auf einem System passiert.

Das Master-System sorgt dann in regelmäßigen Abständen dafür, daß Änderungen an den Anmeldungen in den verschiedenen Listen auf das oder die Slave-Systeme übermittelt werden; diese übernehmen die Änderungen in ihren Tabellen.

Wobei dann wieder ein SPoF entsteht. Ich würde eine völlig unabhängige Lösung bevorzugen. --roam 14:03, 4. Mai 2009 (CEST)

Der SPoF wäre aber nur für Änderungen an den Listen zuständig, die übers Webinterface kommen, alles andere würde ich so auslegen, dass jeder Server Änderungen an Listen vornehmen kann und diese entsprechend komuniziert. Das muss sogar passieren, da man sich auch per Mail in Listen ein- und austragen kann. --CeBe 03:03, 26. Jun. 2009 (CEST)

Durch die gleichwertigen MX-Einträge wird zum einen für eine höhere Ausfallsicherheit gesorgt, zum anderen verteilt sich auch die Last relativ gleichmäßig, weswegen die Verteilung der Listen-Mails auch schneller passsieren sollte. Weiterhin läßt sich die Lösung auch problemlos auf weitere Server erweitern, sofern die Scripte entsprechend angelegt sind.

Das sollten wir auf jeden Fall so auslegen, dass es egal ist, welcher Server ausfällt, es also keinen Master gibt. --CeBe 03:03, 26. Jun. 2009 (CEST)

In wiefern der automatische Abgleich der Listenserver auch auf die Mailinglisten selber ausgedehnt werden kann, kann ich im Moment aber noch nicht sagen ... Garry 19:04, 3. Mai 2009 (CEST)

Verfügbare Server

bitte ergänzen

• lists.ak-vorrat.org, betrieben von roam
• Angebot zum Betrieb eines dedizierten Servers von Garry Glendown
• Würde einen meiner Mailserver auch mit in den Verbund aufnehmen --CeBe
• Man könnte auch den bereits vorhandenen mail.vorratsdatenspeicherung.de in den Cluster mit aufnehmen... --CeBe

Notfallplan

Meine Idee dazu: Auf jedem der Server gibt es eine not-ml@ (oder auch anders zu benennen), die im Normalbetrieb nicht genutzt wird, auf der aber alle ML-Abonenten automatisch auch angemeldet werden. Es steht somit bei einem Ausfall sofort eine Ausweichmöglichkeit zur Verfügung. Ist ne spontane Idee, noch nicht ausgereift, sollte man aber weiterdenken, mein ich. --CeBe 12:32, 28. Apr. 2009 (CEST)

M.E. reicht es, wenn z.B. ml und diskussion nicht gleichzeitig ausfallen können. Im Normalfall reden wir ja nur über ein paar Stunden downtime und selbst wenn wir die ml auf einen anderen Server migrieren würde das nicht länger dauern und wäre zu verkraften. --roam 14:01, 4. Mai 2009 (CEST)

Ziehe meine Idee zurück, viel besser ist System mit gleichwertigen MX-Einträgen, dann bekommen die Nutzer einen Ausfall garnicht mit. --CeBe 03:06, 26. Jun. 2009 (CEST)