Grid Monitoring beim CERN mit Elastic
English version available here.
Das Worldwide LHC Computing Grid (WLCG) [1] ist ein globales Projekt, an dem über 170 Rechenzentren in 42 Ländern beteiligt sind. Insgesamt werden über eine halbe Million Prozessorkerne verwendet und nationale und internationale Grid-Infrastrukturen vernetzt. So erhält eine Gemeinschaft von über 10.000 Physikern nahezu Echtzeitzugriff auf Daten des Large Hadron Collider (LHC), wobei täglich etwa zwei Millionen Jobs ausgeführt werden.
Mission & Vorgeschichte
Die Mission des WLCG-Projekts ist es, globale Rechenressourcen zum Speichern, Verteilen und Analysieren der ca. 30 Petabyte-Daten bereitzustellen, die vom Large Hadron Collider (LHC) im CERN an der Grenze von Frankreich zur Schweiz erzeugt werden. Das Erreichen dieses Ziels erfordert momentan über 300 Petabyte Plattenspeicher und 200 Petabyte Bandspeicher.
Das WLCG Grid-Monitoring-Team im CERN ist dafür verantwortlich, Werkzeuge und Dienste bereitzustellen, welche die Überwachung und das Verstehen der komplexeren WLCG-Infrastruktur ermöglichen. Ohne dieses Verständnis wäre eine effiziente Nutzung des Systems unmöglich. Das Team hat mehrere Anwendungen entwickelt, um die Überwachungsdaten abzurufen, anzuzeigen und zu analysieren. Die verschiedenen Anwendungen sind für die unterschiedlichen Zielgruppen angepasst: umfassende Ansichten für das Management, detaillierte Ansichten für Service-Administratoren und Einzelanwender und anschauliche Ansichten für die Öffentlichkeit. Die meisten dieser Anwendungen basieren auf Webservern und relationalen Datenbanken. Erst vor Kurzem erforderten das gesteigerte Volumen und die wachsende Komplexität der Überwachungsdaten den Wechsel auf eine brandneue Technologie.
Im nächsten Abschnitt werden die drei Überwachungsaufgaben beschrieben, die wir als Pilotanwendungen für unsere Elasticsearch-Evaluierung verwenden. Sie decken verschiedene Bereiche der Rechenaktivitäten in der WLCG-Infrastruktur ab: Zugriff auf Daten und deren Verteilung, Datenverarbeitung und Zustand und Performance von Diensten. Es gibt dedizierte Dashboards für jeden Bereich.
Die WLCG-Datenerfassung
Die bei den WLCG-Experimenten gesammelten Daten werden an mehreren Standorten repliziert. Dadurch erhöht sich ihre Verarbeitungsgeschwindigkeit, und es ist eine Ausfallsicherung vorhanden, falls ein Standort vorübergehend nicht verfügbar ist. Im Durchschnitt werden jeden Tag 25 Millionen Dateien mit einer Durchschnittsgeschwindigkeit von 10 GB/s übertragen. Das WLCG Transfers Dashboard, das in Abbildung 1 zu sehen ist, verwendet mehrere Filter für Zeit, Experimente, Länder und Standorte und ermöglicht so die Erstellung detaillierter Ansichten der Datenbewegungen.
Abbildung 1. WLCG Transfers Dashboard [2]
Die von den LHC-Detektoren erfassten Rohdaten müssen verarbeitet werden. Dann stehen sie den Physikern für ihre Analysen zur Verfügung. Darüber hinaus werden auch viele Simulationsdaten erzeugt, die mit den Daten aus den LHC-Detektoren verglichen werden. Alle Daten werden innerhalb der WLCG-Infrastruktur verteilt. Die Anwendung Job Monitoring Dashboard, die in Abbildung 2 gezeigt wird, verfolgt den Status der Verarbeitung, Analyse und Simulation von Daten. Im Durchschnitt werden über 2 Millionen Aufgaben täglich und jederzeit ca. 250.000 Aufgaben gleichzeitig ausgeführt – verteilt auf über 170 Standorte.
Abbildung 2. CMS Job Monitoring-Anwendung [3]
Schließlich bietet jeder Standort verschiedene Dienste, die fortlaufend getestet werden, um Probleme schnellstmöglich zu finden. Insgesamt gibt es über tausend Kennzahlen, anhand derer bestimmt wird, ob die Dienste und Standorte ordnungsgemäß funktionieren. Das Site Status Board, das in Abbildung 3 zu sehen ist, speichert, zeigt und kombiniert all diese Kennzahlen. Die Kennzahlen sind in verschiedenen Detailgraden, von Minuten bis hin zu Jahren, verfügbar. Eine Kennzahl zeigt beispielsweise, ob alle 60 Minuten eine Datei im Speicherdienst geschrieben werden kann. Eine andere Kennzahl liefert die jährliche Speichermenge, die der Standort für das Projekt bereitstellt.
Relationale Datenbank → Elasticsearch
Die aktuellen Anwendungen in diesen drei Bereichen nutzen das Experiment Dashboard Framework [5]. Die Web-Frontends nutzen Open Source-Javascript-Bibliotheken wie jQuery, DataTables und Highcharts. Auf dem Server werden Apache, Python und relationale Datenbanken verwendet. Um den steigenden Umfang und die wachsende Komplexität zu bewältigen, prüfen wir Elasticsearch als Alternative zu relationalen Datenbanken.
Das Team hat bereits Produktionserfahrung mit Elasticsearch gesammelt. Insbesondere der Messaging-Service [6] verwendet Elasticsearch zur Statusüberwachung. Im Moment gibt es über zwei Milliarden Dokumente. Es wurde ein Kibana-Dashboard eingeführt, das aus Sicherheitsgründen den Service-Managern vorbehalten ist. Die Informationen werden auch in eine Esper-Engine [7] gefüttert, die bei Problemen Alarmmeldungen erzeugt.
Wir haben unseren Weg mit Elasticsearch 2013 mit einer Prüfung von Elasticsearch 0.90.0 begonnen. Die Performance der Schreib- und Leseoperationen war vielversprechend. Gleichzeitig stand das Fehlen der Multifield Gruppierung einer vollständigen Migration im Weg [8].
Die Prüfung wurde mit Elasticsearch 1.x wieder aufgenommen, um die Nutzung von Elasticsearch in den folgenden drei Bereichen zu verstärken:
- Datenübertragungsvorgänge zwischen den Standorten
- Aufgabenverarbeitung
- Statusüberwachung für Standorte und Dienste.
Zukünftige Elastic-Projekte im CERN
Wir prüfen momentan, wie wir noch mehr von den Elasticsearch-Komponenten profitieren können. Die aktuelle Prüfung umfasst mehrere voneinander unabhängige Aspekte:
- Einsatz von Logstash zum Einfügen von Daten in den Cluster
- Einsatz eines einzigen Elasticsearch-Clusters für alle verschiedenen Anwendungsfälle, und dabei sicherstellen, dass die Autorisierung aller Parteien gewährleistet werden kann
- Beschreibung der verschiedenen Arten von Dokumenten und Indizes, die für die jeweilige Anwendung erforderlich sind
- Prüfung von Kibana für die Visualisierung. Dieser Bereich hat eine niedrigere Priorität, da das Team bereits die notwendigen Web-Schnittstellen implementiert hatte und das Hauptaugenmerk auf der Modifikation der Web-Schnittstellen liegt, sodass diese aus Elasticsearch auslesen können.
Obwohl es noch zu früh für ein abschließendes Urteil ist, kann ich bereits sagen, dass wir sehr positive Erfahrungen mit Elasticsearch gemacht haben und unsere Prüfung fortsetzen werden.
LITERATURHINWEISE
1. http://wlcg.web.cern.ch
2. http://dashb-wlcg-transfers.
3. http://dashb-cms-job.cern.ch/
4. http://dashb-ssb.cern.ch
5. http://dashboard.cern.ch
6. http://mig.web.cern.ch/mig
7. http://www.espertech.com/esper
8. http://iopscience.iop.org/article/10.1088/1742-6596/513/3/032048
Pablo Saiz ist ein Informatiker aus Spanien, der seit 15 Jahren bei CERN arbeitet. In dieser Zeit war er an vielen Projekten mit Bezug auf Distributed Computing für das WLCG (Worldwide LHC Computing Grid) beteiligt. Er war leitender Entwickler und Projektleiter für AliEn, der ALICE-Umgebung im GRID. AliEn ist das von ALICE (einem der LHC-Experimente) verwendete System zur Verteilung von Daten und Arbeitslast an die über siebzig Standorte, die am Experiment teilnehmen. Aktuell leitet er ein Team, das für die Überwachung der vom WLCG verwendeten Anwendungen zuständig ist. Das Team liefert Anwendungen, mit denen Datenverteilung, Aufgabenbearbeitung und Service-Status überwacht werden können. Pablo ist der Hauptentwickler von Tools wie dem Site Status Board (SSB) und dem Service Availability Monitoring (SAM3).
Hier geht's zu Pablo's Elastic{ON} Tour München Talk.