Störungen bei der Bereitstellung der Wahlergebnispräsentation (WEP) der KDVZ Citkomm zur Kommunalwahl 2009

Transkript

1 Störungen bei der Bereitstellung der Wahlergebnispräsentation (WEP) der KDVZ Citkomm zur Kommunalwahl 2009 Störungsdarstellungs- und Analysebericht Martin Krengel Seite: 1 / 80

2 Inhaltsverzeichnis MANAGEMENTZUSAMMENFASSUNG EINLEITUNG VORBEREITUNGEN Ausgangssituation Projektverlauf bis zur Europawahl Projektverlauf bis zur Kommunalwahl Risikomanagement vor dem Wahlabend Performance im Wahlsegment Test der Apache-Server Netzwerkdurchsatz zum Internet Performancetest der neuen WEP-Anwendung Risikomanagement am Wahlabend ( ) Administrativer Ablauf des Wahlabends SYSTEMÜBERBLICK Räumliche Trennung Kommunikation Datenfluss alte Wahlergebnispräsentation (WEP) neue WEP Präsentation alte WEP neue WEP CHRONOLOGIE DER AKTIONEN AM WAHLABEND HANDLUNGSENTWICKLUNG AM WAHLABEND ANALYSE DER TECHNISCHEN URSACHEN Vorgehen Hypothese 1: Überlastung der Hardware Hypothese 2: Optimierungspotential Apache-Konfiguration Hypothese 3: Optimierungspotential Tomcat / WEP neu Hypothese 4: Probleme in der IP-Paketverwaltung der WEP-Server 37 Seite: 2 / 80

3 6.6 Hypothese 5: Physikalische Störungen der Netzwerkkomponenten Hypothese 6: Verwerfen von Paketen der conntrack table Hypothese 7: Überlastung des Datenbankservers TRIPOLIS Zusammenfassende Analyse ANHÄNGE Termine GF zur Wahlvorbereitung Tabellarisch Chronologie inkl. Log-Referenzen Symptomatische Analyse auf Basis MUNIN am Beispiel web in Gegenüberstellung WEP intern vs. extern DNS-Lastprofil Apache Access-Lastprofil der WEP-Server Probleme Web-Server Potentielle Netzwerkfehler DOKOM-Segment Probleme Stabilität des Java-Prozesses Netzwerkprobleme PISA / conntrack Netzlastdarstellungen Open socket Entwicklung weiterer Systemparameter exemplarisch am web Durchgeführte Tests Lasttest WEP-Server Lasttest WEP-Server Lasttest Tomcat Lasttest PISA.ROUTER / Conntrack table Connect-Tests WEP-Server Lasttest WEP-Server Lasttest Web-Server BOGOTA Lasttest Web-Server KOPENHAGEN Workshop Tomcat Wesentliche erkannte Schwachstellen Anwendung WEP neu: Wesentliche ergänzende Erkenntnisse zur Konfiguration Kommunalwahl: Optimierung Systemumgebung Tomcat / Apache: 73 Seite: 3 / 80

4 7.6 Folgeuntersuchungen Tomcat WEP neu Sonstige Analysen conntrack-definition Checkliste Systemkonfigs Wahl Seite: 4 / 80

5 Managementzusammenfassung Die umfangreichen Untersuchungen nach dem Extranet- und Internetausfall der Wahlergebnispräsentation (WEP) der KDVZ Citkomm (Citkomm) haben zu einem klaren Fehlerbild geführt. Hieraus lassen sich die Ursachen für die Probleme der WEP am Wahlabend der Kommunalwahlen NRW 2009 mit einer hohen Sicherheit ableiten. Die Untersuchungen haben mehrere optimierungsbedürftige Umstände oder Fehler zu Tage gefördert, die allerdings sowohl im Regelbetrieb als auch am Wahlabend zu keinen nennenswerten Problemen führten. Diese Probleme wurden trotzdem umgehend beseitigt und werden im weiteren Betrieb soweit wirtschaftlich und technisch sinnvoll nachhaltig vermieden. Die eigentliche Problemursache lag nach allen Anzeichen jedoch in der neuen WEP- Software. Sowohl ihr Laufzeitverhalten, als auch deren Fehlerbehandlung führten unter Last zu einer großen Zahl von offenen Verbindungen, die in der Folge eine Vielzahl von Einzelphänomenen produzierten. Die Veränderung verschiedener Konfigurationsparameter hatte dann zur Folge, dass Verbindungen schneller beendet bzw. dass mehr parallele Verbindungen zugelassen wurden. Die Konfigurationsänderungen führten zwar symptomatisch zur Lösung der Probleme am Wahlabend, sie sind aber nicht als Dauerlösung geeignet, da sie unter anderen Betriebsbedingungen selbst wieder Fehlersituationen begünstigen. Die Erkenntnisse der Analyse führen vor diesem Hintergrund lediglich zu einer optimierten Betriebsstruktur, die leistungsfähiger und fehlertoleranter ist. Für die Zukunft bleibt daher im Wesentlichen die Aufgabe, die Ressourcennutzung in der WEP-Anwendung wesentlich zu verbessern. Die Messtechnik der Citkomm war vor der Kommunalwahl nicht in der Lage, die oben beschriebenen Probleme zu erkennen. Vor diesem Hintergrund muss festgestellt werden, dass die bis dahin gültigen Qualitätssicherungsmaßnahmen konsequent angewendet wurden. Technisch waren sie aber aus heutiger Sicht nicht ausreichend. Diese Punkte wurden mittlerweile beseitigt, so dass nunmehr ein Test der Anwendung unter ähnlichen Bedingungen wie am Wahlabend möglich ist. Damit lassen sich ähnliche Fehler dieses Typs ausschließen. Seite: 5 / 80

6 1. Einleitung Die KDVZ Citkomm (Citkomm) bietet neben dem Betrieb der Software für die operative Wahlabwicklung durch die Wahlämter für ihre Anwender außerdem eine Wahlergebnispräsentation (kurz WEP) im Internet an. Hier wird über eine ansprechende graphische Oberfläche die Analyse des Auszählungsstandes und der aktuellen Wahlergebnisse bei jeder Wahl bis hinab auf Stimmbezirksebene ermöglicht. Aufgrund der kleinräumigen lokalen Ausprägung der den Bürger interessierenden Ergebnisse wird die WEP zur Kommunalwahl in besonderem Maße nachgefragt. Weiterhin werden von den meisten Verwaltungen öffentliche Veranstaltungen mit Präsentation der aktuellen Wahlergebnisse ausgerichtet, auf denen sich interessierte Bürger und auch die zur Wahl stehenden Politiker versammeln und die Auszählungsergebnisse erwarten. Naturgemäß sind die Wahlergebnisse insbesondere in der Phase der Auszählung von besonderem Interesse, um Trends in der Auszählung erkennen zu können. Praktisch bedeutet dies, dass die Hauptproduktion der Software in nur wenigen Stunden stattfindet, d.h. der Betrieb hat im Wesentlichen am Wahlsonntag von ca. 18:00 bis 24:00 Uhr zu erfolgen. Die Anforderungen an die systemtechnische Infrastruktur sind dem entsprechend mit den Anforderungen an ein normales Web-Server-System nicht vergleichbar. Die besonderen Anforderungen lassen sich wie folgt zusammenfassen: Hohe Systemlast durch viele parallele Anfragen, insbesondere bei Kommunalwahlen. Hohe Verfügbarkeitsanforderungen in einem engen Zeitfenster (vom Beginn der ersten Ergebnismeldungen bis zu weitgehend stabilen Ergebnissen vergehen oft nur Minuten). Besondere Erwartungshaltung an eine uneingeschränkte Verfügbarkeit der verwaltungsseitig angebotenen WEP. Die Citkomm stellt sich diesen Herausforderungen seit Jahren mit erprobten Maßnahmen. Diese sind u.a. Redundante Auslegung aller für den Zugriff auf die WEP erforderlichen Netzwerkund Serversysteme. Für alle nicht online redundant verfügbaren Systeme stehen Austauschgeräte vorbereitet am Einbauort der primären Komponente zur Verfügung. Intensive Tests der beteiligten Systeme und Anwendungen durch gezielte Stresstests sowie im Rahmen der obligatorischen Testwahl. Priorisierung kritischer Datenströme. Einsatz eines Spezialistenteams zur jeweiligen Wahl. Neben den eigentlichen Servern für die WEP, sind weitere Systemkomponenten während der Wahl zwingend verfügbar zu halten. Dies betrifft zunächst ganz wesentlich das Wahlverfahren EWA, über das je Wahllokal bzw. Stimmbezirk die ausgezählten Wählerstimmen von den Verwaltungen erfasst werden. Hier wird seitens der Citkomm ein Großrechnerverfahren eingesetzt. Um dieses für die Kunden erreichbar zu halten, sind der Großrechner, die zentralen Kommunikationskomponenten sowie die VPN-Anbindungen der Verwaltungsstandorte an die zentrale Rechenzentrumsinfrastruktur der Citkomm erforderlich. Eine weitere kritische Komponente sind die Web-Sites der Verwaltungen. Obwohl die WEP selbst auf eigens für diese Präsentation eingerichteten Servern läuft, findet der initiale Zugriff der Bürger nahezu immer über die Web-Sites der jeweiligen Verwaltung statt, auf denen Links zu den spezifischen Präsentationen eingerichtet sind. Bei der Kommunalwahl 2009 bestand eine zusätzliche Herausforderung darin, dass parallel zum seit Jahren erprobten Wahlergebnispräsentationsverfahren, welches die Wahlergebnisse mittels Flash in einer animierten Grafik darstellt, erstmalig eine neu entwickelte Java-basierte Lösung parallel zum Einsatz gelangen sollte. Seite: 6 / 80

7 Ausschlaggebend für die Neuentwicklung waren hauptsächlich drei Aspekte: 1. Die Notwendigkeit, die zu übertragende Datenmenge zu reduzieren, um das Webangebot performanter darstellen zu können. 2. Die Umstellung der Entwicklung von proprietärer Flashtechnik auf offene Standards 3. Die Modernisierung und Standardisierung der Navigation innerhalb der WEP Außerdem sollte die Anwendung durch ein offeneres Design mehr Möglichkeiten für kundenindividuelle Anpassungen eröffnen. Die Kommunalwahl 2009 unterlag unabhängig von der Präsentation der Wahlergebnisse einer zusätzlichen Besonderheit in der Ermittlung der Wahlergebnisse, die im Wahlverfahren EWA erfolgt. In Nordrhein-Westfalen musste zur Kommunalwahl erstmals das sog. Sainte- Laguë/Schepers-Verfahren (SLS) zur Berechnung der Sitzverteilung in den Kommunalparlamenten (Kreistag, Stadt-/Gemeinderat) verwendet werden. Durch wahlrechtlich höchst komplexe und verschiedenartige Fallkonstellationen bestanden bei allen Softwareherstellern von entsprechenden Wahlanwendungen Unsicherheiten bezüglich einer lückenlosen Abdeckung aller Konstellationen und einer in jedem Fall korrekten Ermittlung der Sitzverteilung. Nach Auskunft der Softwarehersteller (auch weiteren außer dem EWA- Lieferanten) waren diese Unsicherheiten selbst in Kontakt mit dem Innenministerium des Landes NRW nicht restlos zu beseitigen. Hierzu erfolgte noch am Freitagmorgen vor der Wahl eine entsprechende Information an die kommunalen Wahlämter. Bei der Bereitstellung der WEP zur Kommunalwahl 2009 ist es am Wahlabend ( ) dann zu erheblichen Störungen, d.h. zu einer phasenweisen Nichterreichbarkeit der WEP gekommen. Die Wahlergebniserfassung und ermittlung in den Kommunen war über die operative Wahlanwendung EWA zwar möglich, die grafische WEP konnte aber von Kommunen, Bürger etc. phasenweise nicht aufgerufen bzw. erreicht werden. Die nachfolgenden Darstellungen beschreiben und veranschaulichen die Vorbereitungen, den Störungsverlauf sowie die Aktions- und Handlungsstrategien der Citkomm im Verlauf der Störungsbearbeitung. Anschließend werden die erfolgten Analysen und Erkenntnisse sowie die daraus abgeleiteten Maßnahmen zur zukünftigen Gestaltung der Wahlinfrastruktur ausgeführt. Seite: 7 / 80

8 2. Vorbereitungen 2.1 Ausgangssituation Die Citkomm ist seit Jahrzehnten für die IT-technische Umsetzung der verschiedenen Wahlen zuständig. Da jeder Wahltyp (z.b. Kommunalwahl, Landtagswahl, Bundestagswahl etc.) nicht nur wahlrechtspezifische Besonderheiten aufweist, sondern es auch häufig zu gesetzlichen Veränderungen kommt, ist die Durchführung einer Wahl kein Routinegeschäft. Über die Jahre wurde für die Projektarbeit eine Art Masterplan entwickelt, der sich zunächst nur auf die Wahlergebnisermittlung beschränkte. Seit einigen Jahren wurde er Stück für Stück auch auf die Wahlergebnispräsentation (WEP) ausgeweitet. Die Wahlabwicklung besteht aus zwei weitgehend voneinander unabhängigen Teilprojekten: Die Wahlvorbereitung sowie Erfassung und Ermittlung von Wahlergebnissen erfolgt über das Großrechnerverfahren EWA. Dieses Programm wurde vom KRZN Kamp- Lintfort erstellt und wird von diesem gewartet, d.h. jeweils aktualisiert. Die Präsentation der Wahlergebnisse erfolgt mit einer von der Citkomm erstellten WEP. Hierfür wurden in der Vergangenheit die Rohdaten aus dem EWA-Verfahren ausgelesen, anschließend von der WEP berechnet (z.b. Kandidaten- und Parteiergebnisse, Sitzverteilung etc.) und dann im Internet dargestellt. Die Vorbereitungen für die Wahl beginnen normalerweise rund sechs Monate vor der Wahl. Für das Superwahljahr 2009 begannen die Vorbereitungen schon im Oktober 2008, weil einige Probleme aus den Wahlen der Vorjahre durch neue Lösungen abgestellt werden sollten. Im Rahmen der WEP wurden bisher nicht nur Ergebnisse angezeigt, sondern auch berechnet. Diese Arbeiten waren in den letzten Jahren stets ausgesprochen aufwändig. Außerdem mussten dabei Berechnungen vorgenommen werden, die normalerweise zum Programm EWA gehören. Da sich die Berechnung der Sitzverteilung für die Kommunalwahl 2009 geändert hat (Berechnung nach sog. Sainte-Laguë/Schepers-Verfahren s.o.), wäre der Aufwand dieses Mal besonders hoch gewesen und hätte ein zusätzliches Fehlerrisiko bedeutet. Ursprünglich ließen sich redundante Berechnungen nicht vermeiden, da das Verfahren die Daten nur zur Laufzeit bei Druck- und Bildschirmausgaben dynamisch ermittelte. Seit einiger Zeit bietet EWA auch eine statische Berechnung. In Zukunft sollte daher dieses Modul verwendet werden. Die WEP-Anwendung selbst ist seit vielen Jahren im Einsatz. Sie ist in der Flash- Scriptsprache der Fa. Adobe entwickelt. Diese primär für Animationen konzipierte Sprache hat in der Vergangenheit immer wieder zu Problemen geführt. Die komplexe Logik der Anwendung war nicht ohne Schwierigkeiten umzusetzen. Es gab z.t. Kompatibilitätsprobleme und das Entwicklungs-Know-how in diesem Bereich ist bei der Citkomm nur gering ausgeprägt. Darüber hinaus war bei Verbundwahlen, d.h. unterschiedliche Wahlen an einem Wahltermin, die Adaption an die verschiedenen Wahllogiken nur mit erheblichem Aufwand zu leisten. Diese Punkte wurden zunächst telefonisch mit dem KRZN erörtert. Der Projektstartschuss fand am unter Beteiligung von Technik, Organisation und Geschäftsführung statt. In einer Besprechung am in Iserlohn wurde vereinbart, dass zukünftig das statische Berechnungsmodul des KRZN verwendet werden sollte. Ein entsprechendes Angebot wurde zu Beginn des Jahres 2009 von der Citkomm angenommen. Gleichzeitig Seite: 8 / 80

9 wurde auch in Erwägung gezogen, die mittlerweile vom KRZN entwickelte WEP zu erwerben. Da die Leistungsmerkmale deutlich hinter der bestehenden Flash-Lösung zurück blieben, wurde entschieden, diese Anwendung neu zu entwickeln. Das KRZN zeigte in diesem Zusammenhang Interesse an dieser Lösung und schloss eine Nutzung im eigenen Verbandsgebiet später nicht aus. 2.2 Projektverlauf bis zur Europawahl 2009 In den nächsten Wochen wurde dann stufenweise mit der Spezifikation der Anwendung, der Entwicklung und dem Test der Anwendung begonnen. Dabei war ursprünglich ein erster Test in produktivem Umfeld zur Europawahl am geplant. Gleichzeitig wurde die alte Flash-Anwendung aus Gründen der Risikominimierung an die kommende Wahl angepasst, um für den Fall von Problemen mit der neuen Anwendung gerüstet zu sein. Die Erstellung der neuen WEP-Anwendung gestaltete sich langwieriger als geplant. Während die Erstellung des grafischen Web-Frontends weitgehend planmäßig verlief, gab es Probleme bei der Extraktion der Daten aus der neuen statischen Schnittstelle des Verfahrens EWA. So waren einige für die Entwicklung wesentliche Parameter nur unzureichend dokumentiert. Darüber hinaus wurden wichtige Module später ausgeliefert als geplant, so dass der Einsatz für die Europawahl (ursprünglich sollte zu diesem Termin auch die Kommunalwahl stattfinden) nicht möglich war. Stattdessen wurde die alte Flash-Anwendung für die WEP verwendet. Die technische Infrastruktur war zuletzt bei der Landtagswahl 2005 grundlegend überarbeitet worden. Damals wurde auch erstmals eine Abtrennung der Wahlrechner in ein unabhängiges Segment neben der gewöhnlichen Sicherheitsinfrastruktur der Citkomm etabliert. Dieses Segment wird im Folgenden als Wahlsegment bezeichnet. Die Details dieses Konzeptes werden in den folgenden Kapiteln genauer dargestellt. An dieser Stelle sollen nur einige wichtige Designkriterien dieser Lösung im Überblick dargestellt werden: Ursprünglich verfügte die Citkomm nur über einen Internetzugang. Durch den Preisverfall standen 2005 zwei Verbindungen von unterschiedlichen Internetanbietern zur Verfügung. Diese dienten zur Ausfallsicherung im Regelbetrieb und sollten auch zur Absicherung der WEP dienen. Die Konfiguration der Serversysteme sollte durch eine beliebige Anzahl von preiswerten Servern frei skalierbar sein. Die Citkomm betreibt eine komplexe Firewallinfrastruktur. Für die geringen sicherheitstechnischen Anforderungen am Wahlabend 1 war die bestehende Struktur zu komplex und nicht leistungsfähig genug. Aus diesem Grund sollte die Internetanbindung in einem eigenen Wahlsegment erfolgen. Die Umsetzung dieser Anforderungen ist bei der Wahl 2005 ohne größere Probleme getestet worden und der Einsatz war am Wahlabend in 2005 erfolgreich. Die Systeme wurden danach - wie immer bei längeren Perioden ohne Wahl - abgebaut und für andere Zwecke verwendet. Zur Europawahl 2009 ( ) wurde die gleiche Systemkonzeption mit neuen Serversystemen wieder aufgebaut. Mittlerweile waren die Internetzugänge von 34Mbps auf je 100Mbps ausgebaut worden. Die insgesamt sieben Serversysteme hatten eine wesentlich höhere Leistung als zur Landtagswahl Im Wahlsegment sind ohnehin nur öffentliche Informationen gespeichert und die Firewallregeln müssen lediglich den Webserverbetrieb absichern. Seite: 9 / 80

10 Bei der Europawahl 2009 traten erwartungsgemäß bei äußerst geringer Last keine Probleme auf. 2.3 Projektverlauf bis zur Kommunalwahl 2009 Nach der Europawahl wurden die Entwicklungsarbeiten an der Datenextraktion fortgesetzt. Die grundlegenden Arbeiten verliefen jetzt weitgehend problemlos. Kritisch war vor allen Dingen, dass eine Reihe von Kunden in der WEP andere Anzeigen wünschte, als im Wahlverfahren EWA auf dem Großrechner erfasst. So sollten z.b. Wahllokale statt Stimmbezirke oder umgekehrt oder deren Bezeichnungen in besonderer Reihenfolge angezeigt werden. Dieser Wunsch war bei der alten WEP-Anwendung durch manuelle Erfassung eines Citkomm-Mitarbeiters mit vertretbarem Aufwand umsetzbar, die neue Anwendung bot diese Möglichkeit (noch) nicht und sieht erst in einer späteren Ausbaustufe die direkte Vorgabe durch die Verwaltungen selbst (z.b. Wahlamt) vor. Die funktionalen Tests der Anwendungen konnten zeitgerecht bis eine Woche vor der Wahl abgeschlossen werden. Die Lasttests konnten in der Woche vor der Wahl durchgeführt werden und waren im Ergebnis unauffällig. Insgesamt ist die Fertigstellung ohne jede Pufferzeiten erfolgt, so dass die Tests nicht so intensiv waren, wie ursprünglich vorgesehen. Die Risiken erschienen aber gering, da es möglich war, im Betrieb die neue gegen die alte WEP auszutauschen. Die technische Infrastruktur blieb weitgehend unverändert. Es wurden lediglich zusätzliche Tomcat-Server 2 für den Betrieb der neuen Anwendung installiert. Diese nutzten aber die Webserver in ähnlicher Weise wie die alte Anwendung. Die vielen Aktivitäten wurden durch regelmäßige Sitzungen abgestimmt. Die Geschäftsleitung war bei den meisten Sitzungen vertreten. Darüber hinaus wurde der technische Aufbau auch neben den Sitzungen durch den stellv. Geschäftsführer zuständigkeitshalber intensiv begleitet. Der Geschäftsführer betreute die Entwicklung der neuen WEP-Anwendung zusammen mit dem Wahlprojektleiter. Wegen der terminlichen Kritikalität des Projektes wurden in den letzten vier Wochen vor der Wahl meist täglich kurze Abstimmungsgespräche mit allen an der Entwicklung beteiligen Personen, dem Geschäftsführer und der Projektleitung durchgeführt. 2.4 Risikomanagement vor dem Wahlabend Zum besseren Verständnis der folgenden Darstellung wird zunächst das Risikomanagement vor und am Wahlabend erläutert. Dabei geht es einerseits um das konkrete Risikomanagement, anderseits werden auch einige Ergebnisse der Untersuchung nach der Wahl vorweggenommen, wenn diese für die Bewertung des Risikomanagements erforderlich sind. Die beschriebenen Maßnahmen sind organisatorisch in entsprechende Sitzungen bzw. interne Abstimmungstermine eingebunden, die in festgelegtem Turnus vor einer Wahl erfolgen. Obligatorisch ist ferner eine Testwahl ca. 2,5 Wochen vor dem eigentlichen Wahltermin. Hier wird durch die Kommunen u.a. die flächendeckende Erfassung der Wahlergebnisse simuliert, wie sie am Wahlabend erfolgt. Dies erlaubt auch den funktionalen Test der WEP im Verlauf eines Wahlabends. Außerdem stellt eine Veränderungssperre nach der Testwahl sicher, dass nur noch zwingend notwendige Änderungen (z.b. Bereinigung gravierender Fehler) und diese in 2 Apache Tomcat stellt eine Umgebung zur Ausführung von Java Code auf Webservern bereit. Seite: 10 / 80

11 besonders dokumentierter Form vorgenommen werden. Dazu ist die explizite Genehmigung des Projektleiters oder der Geschäftsführung erforderlich. Im Vorfeld der Wahlen sollten durch eine sorgsame Vorbereitung viele Risiken minimiert oder, falls möglich, ausgeschlossen werden. Dazu gehörten für die Kommunalwahl im Einzelnen: Die redundante Auslegung von Rechnern, Routern und Netzwerkverbindungen, die parallele Bereitstellung von alter und neuer WEP, die Funktionstests an der Anwendungssoftware, die Lasttests an der Anwendungs- und Systemstruktur. In diesem Zusammenhang muss festgestellt werden, dass die Citkomm in den ersten drei Bereichen über jahrelange praktische Erfahrungen verfügt. Das Redundanzkonzept sieht auch im Regelbetrieb eine weitgehend doppelte Auslegung von unternehmenskritischen Webdiensten vor. Die jeweiligen Server sind dabei in aller Regel aus Gründen des Katastrophenschutzes an zwei getrennten Standorten installiert. Der Bereich der Lasttests hat gewöhnlich nur marginale Bedeutung, da die Produktivsysteme der Citkomm so ausgelegt sind, dass sie im Regelbetrieb nicht ernsthaft belastet werden. Entsprechend gehören Lasttests nicht zur Kernkompetenz der Citkomm-Mitarbeiter/innen. Trotzdem wurden vor der Wahl verschiedene Tests vorgenommen. Diese Tests können nicht mit vertretbarem Aufwand alle Aspekte eines realen Wahlabends abbilden, so dass hier eine Modellbildung vorgenommen werden muss. Für die Kommunalwahl waren das im Wesentlichen folgende Szenarien: Gesamtperformanz des Netzaufbaus im Wahlsegment Belastung der Apache-Webserver 3 Lastsituation auf den Netzverbindungen bei einem hohen Datendurchsatz Performanz der neuen WEP-Anwendung 4 Der Gesamtaufbau des Wahlsegments besteht in einer weitgehend redundanten Netzstruktur, die in den folgenden Abschnitten detailliert dargestellt wird, so dass hier nur ein grober Überblick über die durchgeführten Tests erfolgt Performance im Wahlsegment Dem Wahlsegment vorgeschaltet sind zwei sog. Screening-Router 5, die jeder mit einem der beiden Internetprovider verbunden sind. Beide sind über eine sog. Querverbindung miteinander verbunden. Im Falle des Ausfalls eines Providers läuft der Datenverkehr zwischen den RZ-Standorten über diesen Weg. Die beiden Screening-Router sind auch im Regelbetrieb im Einsatz, um den wahlfreien Zugang zu den beiden RZ-Standorten der Citkomm auch bei Ausfall eines Providers sicher zu stellen. Dieser Systemaufbau ist seit Jahren im Einsatz. Die Redundanzkonzepte sind bewährt. Auch im Regelbetrieb kommt es vor, dass ein Provider Verbindungsprobleme hat. 3 Bei der Citkomm werden Webserver des Open Source Projektes Apache verwendet. 4 Auf Lasttests der alten WEP Anwendung wurde vollständig verzichtet, da diese sich in den vergangenen Wahlen nach einer langen Optimierungsphase als problemlos erwiesen hatte. Diese Annahme ist nach allen Messungen, die im Zuge der Untersuchung nach dem Wahlabend erfolgten, auch heute noch valide. 5 Sie liegen vor der eigentlichen Sicherheitsinfrastruktur der Citkomm. Sie adaptieren die Internetprovider an das Netz und filtern (daher der Name Screening ) offensichtlich unerwünschten Datenverkehr noch vor der Firewall aus. Seite: 11 / 80

12 In diesem Fall konnte in den meisten Fällen eine automatische Adaption der Systeme an die Fehlersituation beobachtet werden, so dass ein ausfallfreier Betrieb sichergestellt war. In Einzelfällen, wo dies nicht automatisiert erfolgte, konnte durch Eingriffe des Bereitschaftsdienstes der Citkomm die Verfügbarkeit in kurzer Zeit wiederhergestellt werden. Ein besonderer Test dieser Systeme fand vor der Wahl nicht statt. Tatsächlich waren die Screening-Router am Wahlabend zeitweise in ihrer Filterfunktion überlastet. 6 Aus heutiger Sicht steht aber fest, dass dies ein symptomatisches Phänomen war, das nicht ursächlich für die Probleme am Wahlabend war. Aus dieser Sicht kann festgestellt werden, dass auch die Entscheidung, diesen Bereich nicht weiter zu testen, richtig war. Eine Ausweitung des Risikomanagements in diesem Punkt hätte die Probleme am Wahlabend nicht verhindern können. Die Performanz und Funktion der übrigen Netzteile des Wahlsegments wurde wesentlich durch die im folgenden Abschnitt beschriebenen Tests an den Apache-Servern abgedeckt. Die Funktion der Redundanzkonzepte wurde durch das gezielte Abschalten von Servern bzw. das Abziehen von Netzwerkkabeln simuliert. Hierbei wurde auch die unterliegende Netzwerküberwachung und -protokollierung getestet. Letztere ist in diesem Bereich wichtig, da bei einem Serverausfall am Wahlabend eine manuelle Konfigurationsänderung durch das Server-Operating erfolgen muss, damit das betroffene System nicht mehr im Internet publiziert wird. 7 Diese Funktionen standen am Wahlabend spezifikationsgemäß zur Verfügung Test der Apache-Server Die Konfiguration der Apache-Server hatte sich in der Vergangenheit in Bezug auf die Performanz immer wieder als kritisch erwiesen. Aus diesem Grund wurde im Vorfeld der Wahl ein intensives Literaturstudium im Internet durchgeführt, um dort eine möglichst laststabile Konfiguration zu ermitteln. Die eigenen Konfigurationserfahrungen der Citkomm beziehen sich, wie oben schon ausgeführt, mehr auf den funktionalen als auf den Lastbereich. Eine Übernahme der alten Konfiguration war auch deshalb nicht sinnvoll, weil die Leistungsparameter der neu eingesetzten Server deutlich über denen der Vorwahlen lagen. Die Lasttests wurden von mehreren Servern aus (installiert bei externen Providern) durchgeführt. Hierbei kam das Tool ab (Apache Benchmark) zum Einsatz. Dabei wurde einerseits die Zahl der gleichzeitig möglichen Zugriffe getestet und andererseits der dadurch indizierte Netzwerkverkehr beobachtet. Die Tests zeigten, dass die Leistung der Systeme weit über den höchsten je an einem Wahlabend in der Citkomm gemessenen Zugriffsraten lagen. Die Untersuchungen nach der Wahl zeigten, dass diese Tests nicht alle am Wahlabend auftretenden realen Lastzustände adäquat modellierten. Dies bezieht sich besonders auf den zeitlichen Ablauf von Verbindungsauf- und -abbauprozessen zwischen den Anwendern und den Servern der Citkomm. Im Nachhinein durchgeführte automatisierte Massentests von einer Vielzahl von langsamen Anwendungssystemen, die über DSL-Verbindungen verschiedener Provider angebunden waren, zeigten Fehlersituationen, die mit dem am Wahlabend beobachteten Phänomen weitgehend übereinstimmten. 6 Dies bezieht sich auf den im Folgenden dargestellten Überlauf der sog. ip_conntrack Tabellen. 7 In diesem Fall wird der betreffende Server aus der Namensauflösung der redundanten DNS Server durch das Server Operating entfernt. Dieser Vorgang kann innerhalb von wenigen Sekunden erfolgen. Kunden mit einer bestehenden Verbindung zu diesem Server benötigen unter Umständen einige Minuten, bis ihr lokales System diese Veränderung berücksichtigt. Seite: 12 / 80

13 2.4.3 Netzwerkdurchsatz zum Internet Alle bis hierhin dargestellten Tests führten zu keiner nennenswerten Belastung der Internetund Netzverbindungen. Aus diesem Grund wurden die zu erwartenden Datenmengen für typische Zugriffe messtechnisch ermittelt und in einer Modellrechnung extrapoliert. Dabei ergaben sich keine erkennbaren Leistungsengpässe. Es zeigte sich jedoch, dass die neue WEP deutlich höhere Datenvolumina bewegte als erwartet (ca. 300kB je Zugriff) 8. Durch verschiedene Optimierungsmaßnahmen konnte dieser Wert um mehr als 40% gesenkt werden. Die Modellrechnung ergab unter diesen Bedingungen, dass die Netzwerkkapazitäten ausreichend dimensioniert sind. Diese Überlegungen werden auch durch die Ergebnisse der nachlaufenden Untersuchungen bestätigt Performancetest der neuen WEP-Anwendung Die neue WEP-Anwendung wurde erst kurz vor der Wahl fertig gestellt. Performancefragen wurden während der Entwicklung zugunsten einer möglichst vollständigen funktionalen Umsetzung bewusst zurückgestellt. Die Performancetests wurden erst kurz vor der Wahl begonnen. Für den Fall, dass sich hierbei Probleme ergeben hätten, wäre die alte WEP- Anwendung alleine als bewährte Lösung zum Einsatz gekommen. Die Tests wurden mit dem Tool JMeter ebenfalls von einem externen Server aus durchgeführt. Dabei ergaben sich keine nennenswerten Auffälligkeiten. Im Gegenteil: Trotz des weiter oben beschriebenen relativ hohen Datentransfervolumens war das Antwortzeitverhalten auch unter Last sehr gut. Dieser Befund wurde durch nachlaufende Untersuchungen in wichtigen Aspekten nicht bestätigt. Die Ergebnisse der zusammen mit einem externen Berater durchgeführten Messungen machten deutlich, dass es bei der Bewertung, Modellierung und Konstruktion der Tests Schwachstellen gab, die in der mangelnden Erfahrung in diesem Umfeld begründet sind. Hier liegt ein wesentliches Handlungsfeld, das auch für Anwendungen im Regelbetrieb in Zukunft angegangen wird. Das ist auch deshalb erforderlich, weil eine anschließende Analyse entsprechender Internetforen deutlich zeigte, dass die Citkomm mit diesen Problemen nicht alleine steht. 2.5 Risikomanagement am Wahlabend ( ) Die Vorbereitungen für den Wahlabend zielen darauf ab, dass alle Systeme ohne Operatoreingriff automatisiert ablaufen. Aus diesem Grund sind typischerweise nur einige wenige manuelle Eingriffe am Wahlabend nötig. Hierzu gehört z.b. die Bereitstellung der Webserver im Internet oder die Reinitialisierung aller Systeme in einen Grundzustand, um so für definierte Ausgangsbedingungen zu sorgen. Eingriffe sind lediglich bei Fehlersituationen vorgesehen. Diese können sich sowohl auf Hardwarereparaturen wie auf Neukonfiguration von Systemen beziehen. So führt ein Ausfall eines der oben benannten Screening-Router zwar zu keinem Systemausfall, hat aber eine Halbierung der Serverleistung zur Folge. Um zügig zur Ausgangsleistung zurückzukehren, kann in diesem Fall ein funktionsfähiges und bereits eingebautes Reservesystem mit wenigen Handgriffen in Betrieb genommen werden. Für vergleichbare Tätigkeiten sind aus allen relevanten Funktionsbereichen Techniker in der Citkomm anwesend. Zur Koordination und Abstimmung dieser Kräfte sind Abteilungsleiter der zuständigen Bereiche anwesend. Da diese alle auch über profunde praktische IT-Kenntnisse verfügen, sind sie im Fehlerfall zusätzlich als Experten für spezifische Analyse- und Konfigurationsaufgaben einsetzbar. 8 Dieser Wert bezieht sich auf einen Navigationszugriff in der Hierarchiedarstellung der neuen WEP Anwendung (Auswahl eines anderen Knotens in der Hierarchiedarstellung). Die Betrachtung unterschiedlicher Ergebnisse innerhalb eines Knotens führen zu keinem wesentlichen Netzverkehr. Seite: 13 / 80

14 Am Wahlabend waren nachstehend aufgeführte Funktionen in der Citkomm zur Unterstützung des Wahlablaufes personell besetzt. Die möglicherweise hoch anmutende Anzahl der Mitarbeiter/innen gibt die Komplexität der Gesamtaufgabe am Wahlabend wieder. Dabei ist festzuhalten, dass jede Funktion ein genau umrissenes Aufgabenfeld hat, das am Abend überwacht und Instand gehalten werden muss. Hierbei sind auch Funktionen mit einbezogen, die nur für den Regelbetrieb erforderlich sind und mit dem Wahlabend nicht unmittelbar in Verbindung stehen. Da die Funktionen des Regelbetriebs am Wahlabend auch besondere Serviceanforderungen haben, weil in den Verwaltungen ebenfalls viele Unterstützungsfunktionen im Einsatz sind, ist dieser Aufwand sicher gerechtfertigt. Zu koordinativen Problemen kommt es in diesem Zusammenhang trotz der Mitarbeiteranzahl nicht, da der organisatorische Ablauf sich nicht von dem des Regelbetriebs unterscheidet. Im Gegenteil: Die meisten Personen befinden sich am Wahlabend auf einer Etage des Großraumbüros in Sichtweite, so dass eine Abstimmung auf kürzeren Wegen ablaufen kann, als im Regelbetrieb. Funktion Anzahl Administrative Aufgaben 7 Gesamtprojektleiter Wahlen 1 Pressesprecherin 1 Benutzersupport Call Center 3 Geschäftsführung 2 Technische Aufgaben 17 Projektleiter Netz, Server, Host 3 Operating Host/Server 1 Systemmonitoring / Leitstand WEP 1 Hostadministration 1 Serveradministration 2 Netzadministration 2 Entwicklung WEP (alt, neu) 3 Organisation EWA 2 Admin. Kundensysteme / Full Service 1 Admin. LAN / Telefonie 1 Gesamtsumme Administrativer Ablauf des Wahlabends Der wesentliche Teil dieses Dokumentes beschreibt den Ablauf des Abends aus einer technischen Sicht. Diese Darstellung muss im Lichte der administrativen und methodischen Maßnahmen am Wahlabend betrachtet werden. Viele Sachverhalte lassen sich im Nachhinein anders deuten und genauer untersuchen. Am Wahlabend stand die gesamte Betriebsmannschaft unter erheblichem Erfolgs- und vor allem Zeitdruck. Eine Vielzahl von Einzeleindrücken musste verarbeitet werden, ohne dass ein offensichtlicher Hinweis auf mögliche Ursachen bestand. So war über den ganzen Abend nicht wirklich klar, ob es sich um eine Hardwarestörung, einen Crackerangriff oder um ein Konfigurationsproblem handelte. Die Komplexität des Fehlerbildes deutete jedoch stark darauf hin, dass es sich vermutlich um einen Mehrfachfehler handelte. Die folgende Darstellung soll daher den Leser in die Situation des Abends versetzen, um so das Verständnis für die weiter unten dargestellten Maßnahmen zu vermitteln. Als gegen 17:30 Uhr die Server nicht mehr verlässlich erreichbar waren, geschah dies bei einer äußerst geringen Systemlast. Da alle relevanten Systeme der Citkomm in ein zentrales Systemüberwachungssystem eingebunden sind, ließ sich auf einen Blick feststellen, dass sich alle diese Systeme in einem spezifikationsgemäßen Zustand befanden. Gleichzeitig war eine Verbindung aus dem Internet und dem Extranet zu den Wahlservern nicht möglich. Kurz vor 18:00 Uhr erfolgte eine Besprechung mit allen Server- und Netzwerktechnikern, in der die Lage erörtert wurde. Eine klare Fehlerhypothese konnte zu diesem Zeitpunkt von Seite: 14 / 80

15 keinem Techniker abgegeben werden. Bis zu diesem Zeitpunkt waren keine Änderungen an der Konfiguration der Systeme vorgenommen worden, da in solchen Fällen alle technischen Änderungen mit dem anwesenden Geschäftsführer abgestimmt werden müssen. Diese Vorgehensweise soll absichern, dass nur koordinierte und im Team überdachte Änderungen vorgenommen werden. Gleichzeitig wird ein Mitarbeiter für derartige Fälle mit der Führung eines sog. Krisenbuches beauftragt. In ihm sind alle bekannten Symptome und Maßnahmen unmittelbar zu dokumentieren. Die Citkomm wendet zur Störbeseitigung typischerweise eine hypothesenbasierte Methodik zur Bewältigung derartigen Fehlersituation an. Dabei wird auf Basis der aktuellen Erkenntnislage eine sog. Fehlerhypothese aufgestellt, die nach Überzeugung des Analyseteams am wahrscheinlichsten als Ursache in Frage kommt. Darauf aufbauend werden dann konkrete Analyseaufgaben an alle Techniker verteilt, die diese Fehlerhypothesen verifizieren oder falsifizieren können. Dabei werden Hypothesen, die keine Systemveränderungen für die Validierung benötigen, bevorzugt. Weiterhin gilt die Regel immer nur eine Maßnahme bzw. Systemänderung nach der anderen durchzuführen und zu validieren, um Neben-, Seiteneffekte und falsche Schlussfolgerungen durch mehrere gleichzeitige Änderungen zu vermeiden. Im Rahmen der Besprechung wurde festgelegt, dass zunächst alle Webserver neu gestartet werden. Damit sollte noch einmal sichergestellt werden, dass alle Serversysteme in einem definierten Zustand für die weitere Analyse des Netzwerks waren. Falls dies keine Änderung zur Folge hätte, sollte von einem Verbindungsproblem ausgegangen werden. Um diese Hypothese zu verifizieren, wurden alle Verbindungsleitungen einem manuellen, logischen Test 9 unterzogen. Gegen 18:15 Uhr wurden die Ergebnisse der Leitungstests erörtert. Dabei ergab sich, dass alle Verbindungen grundsätzlich funktionierten. Lediglich die oben angesprochene Querverbindung wies rund 40% Paketverluste in Richtung des Screening-Routers PISA2 auf. PISA2 ist der Screening-Router für das durch die Fa. DOKOM versorgte Zugangssegment. 40% Paketverluste stellen einen kommunikationsbeeinträchtigenden Wert dar, der auf ein Hardwareproblem hindeutet. Um vorweg einen transienten 10 Fehler in PISA2 auszuschließen, sollte dieser neu gestartet werden. Falls diese Maßnahme keine Besserung mit sich brächte, sollte ein Hardwareproblem im Umfeld von PISA2 als Fehlerhypothese angenommen werden. Parallel dazu wurden die Kunden um 18:19 Uhr über die Probleme in Bezug auf die Erreichbarkeit der WEP informiert. Im Systemumfeld von PISA2 hätten jetzt systematisch Leitungen, Switch und Router erneuert werden müssen. Da diese Maßnahme einige Zeit in Anspruch genommen hätte, wurde entschieden, zunächst - auf der Basis der Fehlerhypothese - Maßnahmen zur Aufnahme des Betriebs zu ergreifen. Da alle Server mit jeweils zwei IP-Adressen im Internet publiziert wurden, wovon eine über die Querverbindung geführt wird, die zumindest symptomatisch den Netzverkehr beeinträchtigte, sollte diese Überkreuz-Kommunikation stillgelegt werden. Bis 18:40 wurden diese Maßnahmen stufenweise umgesetzt und in ihrer Wirkung analysiert. Parallel dazu zeigte der Produktivserver für die Kundenwebsites Probleme. Die Bewältigung dieses Problems wurde von einem über VPN zugeschalteten Mitarbeiter übernommen. Als Fehlerhypothese wurde gegen 19:00 Uhr vermutet, dass viele Webbrowser im Internet noch offene Verbindungen zu den Servern unterhielten. Um diese schnell und für die Systeme im Internet erkennbar zu trennen, wurden die Switches für die beiden Internet- Providerzugänge neu gestartet. Dabei wurde die Folge übersehen, dass diese Maßnahme 9 Hierbei kamen die Standardprogramme ping, traceroute, telnet und tcpdump zum Einsatz. 10 engl. vorübergehend, lat. transire vorbeigehen in der Informatik für zeitlich begrenzt in den Speicher geladene flüchtige Daten Seite: 15 / 80

16 auch die internen VPN-Verbindungen, d.h. die Emulationsverbindungen für die Wahlanwendung EWA kurzzeitig unterbrechen würde. Die operative Wahlanwendung EWA war daher für wenige Minuten im Extranet, d.h. für die kommunalen Wahlämter, nicht erreichbar. Kurz danach wurde die neue WEP-Anwendung vollständig gestoppt, um diese als Fehlerquelle auszuschließen. Innerhalb des Extranets funktionierten die Systeme jetzt ohne nennenswerte Probleme. Die Kunden wurden um 19:19 Uhr weiter über den aktuellen Stand der Bemühungen informiert. Gleichzeitig wurde die Bereitstellung der Anwendung im Extranet mitgeteilt. Gegen 19:30 Uhr zeigte sich, dass die Apache-Server nun Anfragen in einem nennenswerten Umfang beantworteten, ohne dass das zu einer nennenswerten Verbesserung der Problemlage im Internet führte. Offensichtlich gab es eine große Zahl von offenen Verbindungen, die weitere Zugriffe verhinderten. Dieses Phänomen passte auch zu den Problemen auf der Querverbindung, ohne dass dies zu einer konsistenten Fehlerhypothese führte. Da die Konfiguration der Apache-Server nur je 150 parallele Zugriffe gleichzeitig zuließ, wurde diese Grenze testweise bei einem Server hochgesetzt. Danach kam es zu einer spontanen Steigerung der Zugriffe auf diesen Server. Gegen 20:20 wurde diese Konfiguration auf alle Server verteilt. Mit dieser Maßnahme stand die WEP auch im Internet wieder zur Verfügung. Nachdem sich die Lage nun offensichtlich stabilisiert und das Betriebsteam Zutrauen zu der bestehenden Situation gewonnen hatte, wurden die Kunden über die Lösung der akuten Probleme um 20:55 informiert. In den folgenden Stunden wurde mit der weiteren Eingrenzung der Probleme begonnen. Dabei gelang es, eine Reihe von Symptomen weiter einzugrenzen. Im Gefolge dieser Maßnahmen wurde stufenweise das stillgelegte Segment wieder in das Gesamtsystem eingebunden, ohne dass es zu weiteren Problemen kam. Seite: 16 / 80

17 3. Systemüberblick Aufgrund der oben skizzierten Anforderungen und der bisher gemachten Erfahrungen setzt die Citkomm für die Darstellung der Wahlergebnisse auf dedizierte Serversysteme. Damit werden die Schnittstellen zur normalen Systemlandschaft der Citkomm reduziert und so viele mögliche Fehlerquellen von vornherein ausgeschlossen. Neben den für die reine Präsentation der Wahlergebnisse benötigten Webservern werden im Weiteren auch die Komponenten erwähnt, die für die Kommunikationsbeziehungen der Systeme, die Systemüberwachung der gesamten Wahlumgebung, die Erfassung der Wahlergebnisse, die Übermittlung und Aufbereitung der Daten an die Präsentationsanwendung erforderlich sind. Das Schaubild zeigt alle benötigten Elemente für die Bereitstellung der WEP: Seite: 17 / 80

18 3.1 Räumliche Trennung Für die Unterbringung der IT-Systeme verfügt die Citkomm über zwei unabhängige Gebäude. Die Infrastruktur für die WEP wird jeweils zur Hälfte auf die beiden Standorte verteilt. Jedes Gebäude verfügt über eine eigene, unabhängige Anbindung an das Internet. Der Zugriff durch die Administratoren ist über Remote-Konsolen und Management-Karten in den Serversystemen standortunabhängig jederzeit möglich. 3.2 Kommunikation Die Citkomm verfügt über zwei getrennte Internetanbindungen von je 100 Mbps, die beide aktiv für den Datenverkehr genutzt werden. Es werden providerabhängig IP-Adressen eingesetzt. Die Anbindung an die Infrastruktur der Citkomm erfolgt an zwei getrennten Standorten und ist bereits seit einigen Jahren im Einsatz. Hinter den Übergabepunkten der Provider Deutsche Telekom T-Systems (Telekom) und DOKOM21 (Dokom) werden die Kommunikationsdaten zunächst jeweils über einen Screening-Router (PISA1, PISA2) aufgenommen, der hauptsächlich drei Funktionen abdeckt: 1. Vorfilterung der Kommunikation zur Unterbindung unerwünschter Datenverbindungen 2. Shaping der Datenströme (Quality of service) 3. Automatische Umleitung des Datenverkehrs bei Ausfall eines Providers Für die Wahlen wird ein Traffic Shaping aktiviert, dass neben den stets priorisierten VPN- Tunneln zusätzlich die Web-Server mit einem Bandbreitenkontingent ausstattet, dass zur bevorzugten Nutzung auf den verfügbaren Provideranbindungen reserviert wird. Nicht benötige Bandbreiten werden bei dem seit Jahren eingesetzt Verfahren an übrige anstehende Kommunikationsverbindungen freigegeben. Sowohl die VPN-Gateways als auch die Web-Server sind damit sicher gegen eine volumenmäßige Leitungsüberlastung aufgrund der WEP geschützt. Bei der Kommunalwahl 2004 hat sich das Verfahren bewährt, da seinerzeit die zur Verfügung stehende 34 Mbps-Leitung vollständig durch die WEP ausgelastet wurde, ohne dass es in der VPN-Kommunikation zu Beeinträchtigungen gekommen wäre. Die Router agieren gegenüber den WEP-Servern weiterhin als Firewall. Da diese administrativ über ein anderes Interface erreicht werden, wird gegenüber dem Internet ausschließlich der Port 80 autorisiert. Das Potential an Angriffen auf die WEP-Server wird damit minimal gehalten. Für den Fall einer Providerstörung sind die PISA-Router über eine Querverbindung gekoppelt. Auf jedem PISA-Router sind Adressen in der Anzahl der im gegenüberliegenden WEP-Segement lokalisierten Server definiert, die auf die öffentlichen Adressen der eigentlichen Zielserver via NAT umgesetzt werden. Dieser Mechanismus funktioniert in beide Richtungen. Dem entsprechend ist an jedem Providerstrang für jeden WEP-Server ein IP- Eintrag definiert. Faktisch ist somit jeder WEP-Server über zwei öffentliche IP-Adressen aus dem Internet erreichbar. Die Distribution der IP-Adressen erfolgt über die zwei regulären öffentlichen DNS-Server der Citkomm (MOSKAU1, MOSKAU2). Je ein Gerät befindet sich auf jedem Providerstrang. Auf den DNS-Servern sind ausschließlich die IP-Adressen ihres lokalen Strangs definiert. Da der Zugriff im DNS-Protokoll zufällig auf einen der DNS-Server erfolgt, entsteht eine zufällige Lastverteilung, die einem statischen Load Balancing entspricht. Im Falle der Störung eines Providerstranges kann der dort lokalisierte DNS-Server nicht mehr erreicht werden. Dem entsprechend werden auch die an diesem Strang lokalisierten IP-Adressen nicht mehr herausgegeben, so dass automatisch eine Zugriffsumleitung für neue Anfragen auf den Seite: 18 / 80

19 verbleibenden Providerstrang erfolgt. Der Mechanismus arbeitet ohne Benutzereingriff und fängt Störungen ab der jeweiligen Providerleitung des jeweiligen Edge-Routers PISA des jeweiligen DNS-Servers Im Falle der Störung eines einzelnen Servers kann diese im DNS aus der Verteilung ausgenommen werden. Durch eine ttl von 60 sec ist dies vergleichsweise zeitnah möglich. Seite: 19 / 80

20 3.3 Datenfluss Nach Auszählung der Stimmen im Wahllokal werden die Wahlergebnisse der einzelnen Stimmbezirke durch die Sachbearbeiter der Kommunen in das Großrechnerverfahren EWA eingegeben. Der Zugriff auf den Großrechner der Citkomm erfolgt über die bewährte VPN- Infrastruktur der Citkomm und ist redundant ausgelegt. Die Datentransferrechner (DTR1 und DTR2) sind für die Übermittlung und Aufbereitung der Wahldaten an die Präsentationsserver zuständig. Seite: 20 / 80