Contents
Ausgangspunkt
betroffene Geräte:
gesamt: ca. 20 Geräte
Das Ziel ist ein dezentrales Monitoring, welches folgende Punkte möglichst gut erfüllt
- dezentral
- es gibt optimalerweise mehr als eine "zentrale" Instanz
- erweiterbar
- zusätzliche Knoten und Server sind einfach einfügbar
- effizient
- auch auf schwacher Hardware (WRT) sinnvoll lauffähig
- vielleicht unabhängig von OLSRd
Software
Distributed Monitoring im Sinne von ganglia/collectd kann in zwei Modi verwendet werden
- unicast
- alle potentiellen Server-Adressen müssen auf jedem Gerät eingetragen werden (damit auch Abhängigkeit von OLSRd)
- multicast
Collectd
Vorteile:
- sehr geringer CPU- und Speicheroverhead
- Event-basierte Benachrichtigung
Nachteile:
- kein dediziertes Frontend
Pakete der Version 4.8.3 für OpenWRT Kamikaze 7.09 (x86) und Whiterussian RC6 (mipsel) bzw. die darauf basierende Freifunk-Firmware, sowie dazu passende Patches sind auf dem Download-Server zu finden.
Ganglia
Vorteile:
- unterstützt logische Gruppierungen
- Verwendung häufiger Übertragungsstandards
- fertiges Frontend
Nachteile:
- eigentlich für Cluster entwickelt und unterstützt daher auch Funktionen, die in diesem Fall nicht benötigt/erwünscht sind.
Multicast
Eine wichtige Vorabbedingung für die Verwendung von Multicast ist die Eignung des verwendeten Switch. Zum Glück unterstützt der Nortel Baystack 5510-48T (Standort/Spektral) IGMP-snooping für IGMPv1 und IGMPv2. Alle anderen Geräte sind entweder direkt verbunden oder haben eine (L2) transparente Verbindung zueinander.
Um mit dem Switch zusammenarbeiten zu können, muß daher auf den angeschlossenen Geräten folgendes eingerichtet werden, da der Linux Kernel je nach Version auch IGMPv3 unterstützt.
sysctl net/ipv4/conf/<interface>/force_igmp_version=2
Unter Linux können im MFC (multicast forwarding cache) zwar statische Einträge angelegt werden (z.B. mit smcroute), aber es sind nur (S,G)-Einträge und keine (*,G)-Einträge möglich.
- funktioniert in einer Broadcast-Domain. Dies würde bedeuten, daß der Multicast-Verkehr über eine (Linux-)Bridge weitergeleitet werden muß. (z.B. mit ebtables ausschließlich auf Multicast-Verkehr reagieren)
- funktioniert mit mehreren Broadcast-Domains, wenn ein Multicast-fähiger Router dazwischen ist. Dies kann auf mehreren Wegen erreicht werden.
- neue Firmware mit
- Kernel-Unterstützung für Multicast-Routing (MROUTE)
OpenWRT default - ab Kamikaze 8.09.2 bzw. rev. (generic-2.4) "18312" oder rev. (generic-2.6) 2.6.21, 2.6.25, 2.6.30 "16044" bzw. für 2.6.31, 2.6.32 "16713"
- auch mit ff-luci der Freifunk Firmware auf Basis von Kamikaze
- selber bauen
- Routing-Daemon (auch für forwarding!!)
smcroute - statische Multicast forwarding Einträge müssen für jeden upstream Host eingetragen werden
- igmpproxy
- leitet die IGMP-Nachrichten der "interessierten" Geräte weiter und legt entsprechende MROUTE_Cache-Einträge an. Wie verhält er sich mit upstream und downstream?
- Kernel-Unterstützung für Multicast-Routing (MROUTE)
- collectd-Patch (=collectd als Routing-Daemon verwenden)
- Patch notwendig und jede collectd-Instanz muß alle Nachrichten der anderen auf Duplikate überprüfen.
- ganglia (gmond)
- kann out-of-the-box auf verschiedenen Interfaces Multicast-Traffic senden/empfangen, aber offenbar nur innnerhalb eines Clusters.
- IPv6 = neue Firmware oder zusätzliches Kernel-Modul
- IPv6 Kernel-Unterstützung (auch ohne Multicast-Routing)
- Multicast Routing-Daemon (mrd6)
- olsr-bmf (OLSR Multicast forwarding plugin)
- Damit aber sicher Abhängigkeit von OLSRd und es hat einen eher experimentellen Status
- neue Firmware mit
Legende:
- Alphanumerische oder punktuelle Gliederung
entweder/oder (XOR)
- Numerische Gliederung
und (AND)
- bereits verfügbar
-
- bereits implementiert
-