Bis zur OpenNMS Version 16 wurden Performance-Daten (wie zum Beispiel CPU-Auslastung oder Auslastung von Netzwerkinterfaces) in „RRD-Dateien“ abgelegt. Dabei wurde jede Performance-Metrik (einzelne Metriken konnten zu Gruppen zusammengefasst werden) pro Node/Interface in einer eigenen RRD-Datei gespeichert. In der Standardkonfiguration werden die Werte in einem Intervall von fünf Minuten durch OpenNMS abgefragt; innerhalb dieses Intervalls mussten alle RRD-Dateien geöffnet, der neu erhobene Wert gespeichert und die Datei anschließend wieder geschlossen werden. Diese Vorgehensweise sorgte vor allem in Umgebungen mit einer großen Anzahl an überwachten Geräten für eine hohe I/O-Last und führte zu Engpässen in der Performance. In der OpenNMS-Version 17 wurde mit „Newts“ eine neue Möglichkeit geschaffen, Performance-Daten abzulegen. Hier werden die Daten in der NoSQL-Datenbank „Apache Cassandra“ gespeichert, die sich über mehrere Nodes (Server) verteilen kann.
Im Folgenden soll der Aufbau einer Single-Node-Installation von Cassandra und die Konfiguration von OpenNMS zur Verwendung von Newts beschrieben werden. Für die Beispielkonfiguration werden zwei Linux-Maschinen verwendet:
- OpenNMS Server: 172.16.3.33
- Cassandra Node: 172.16.3.32
Die unten stehenden Schritte wurden mit OpenNMS Horizon 17.0.0 und Cassandra 2.2.4 getestet.
Installation von Apache Cassandra
Zunächst muss die benötigte Software heruntergeladen werden. Diese ist (Stand Januar 2016):
- Oracle Java JDK oder OpenJDK in Version 7 oder 8
- Stable Version von Apache Cassandra (aktuell: 2.2.4)
Wurde das Oracle Java JDK als tar.gz Archiv heruntergeladen, kann es einfach durch Entpacken (zum Beispiel unter /opt) installiert werden. Dies geschieht mit folgendem Befehl:
cd /opt tar -xzvf jdk-8u65-linux-x64.tar.gz mv jdk1.8.0_65 java
Das Oracle Java JDK ist damit unter /opt/java installiert. Nun kann die Installation von Apache Cassandra erfolgen. Die Software kann von der Website als .tar.gz-Archiv bezogen werden. Wahlweise werden durch die DataStax-Community auch fertige Debian- und RPM-Packages bereitgestellt. Diese Anleitung beschreibt die Installation des .tar.gz-Archivs. Zunächst muss das Archiv unter /opt entpackt werden:
cd /opt tar -xzvf apache-cassandra-2.2.4-bin.tar.gz mv apache-cassandra-2.2.4 cassandra
Konfiguration
Nach dem Entpacken sollte vor dem ersten Start von Cassandra die Konfiguration durchgeführt werden, indem die Datei <Cassandra-Home>/conf/cassandra.yaml editiert wird. Folgende Parameter sollten hierbei angepasst werden:
cluster_name: 'Newts Cluster' #rpc_address: localhost rpc_interface: eth0
Mit dem Parameter cluster_name wird ein Name für das Cassandra-Cluster vergeben. Über die Parameter rpc_address und rpc_interface wird eine IP (Parameter rpc_address) oder ein Netzwerkinterface (Parameter rpc_interface) angegeben, über die bzw. das Cassandra Datenbankabfragen entgegennimmt. Dabei darf entweder der Parameter rpc_address oder der Parameter rpc_interface gesetzt werden, nicht aber beide. Die Konfiguration wird benötigt, damit die OpenNMS-Installation später Datenbankabfragen absetzen kann.
Start und Stop
Nach Abschluss der Konfiguration kann Apache Cassandra nun das erste Mal gestartet werden. Dies geschieht durch Eingabe der folgenden Befehle:
JAVA_HOME=/opt/java export JAVA_HOME <Cassandra-Home>/bin/cassandra -f
Damit startet Cassandra im Vordergrund – die Ausgabe sollte nun auf Zeilen, die „ERROR“ order „WARN“ enthalten, überprüft werden.
Mit folgendem Befehl kann Apache Cassandra wieder gestoppt werden:
pkill -f CassandraDaemon
Um Start und Stop zu automatisieren, kann folgendes Init-Skript verwendet werden, das als /etc/init.d/cassandra auf dem System abgelegt werden muss:
#! /bin/sh
### BEGIN INIT INFO
# Provides: cassandra
# Required-Start: $remote_fs $time
# Required-Stop: umountnfs $time
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Apache Cassandra
# Description: NoSQL database
### END INIT INFO
#
# Author: Michael Batz <michael.batz@nethinks.com>
#
NAME=cassandra
DAEMON=/opt/cassandra/bin/cassandra
PIDFILE=/var/run/cassandra.pid
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0
# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
do_start()
{
$DAEMON -p $PIDFILE > /dev/null
}
do_stop()
{
kill `cat $PIDFILE`
}
case "$1" in
start)
do_start
;;
stop)
do_stop
;;
restart|force-reload)
$0 stop
$0 start
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|rotate|restart|force-reload}" >&2
exit 3
;;
esac
:
Um einige Umgebungsvariablen wie zum Beispiel JAVA_HOME korrekt zu setzen, sollte zusätzlich die Datei /etc/default/cassandra mit folgendem Inhalt angelegt werden:
JAVA_HOME=/opt/java export JAVA_HOME
Konfiguration von OpenNMS
OpenNMS in Version 17 verwendet standardmäßig als Backend RRD-Dateien, um Performance Daten zu speichern. Um das Backend zu ändern, müssen einige Einstellungen in der OpenNMS Konfigurationsdatei <OpenNMS-Home>/etc/opennms.properties vorgenommen werden. Folgende Einstellungen sollten angepasst werden:
org.opennms.timeseries.strategy=newts org.opennms.rrd.storeByForeignSource=true org.opennms.newts.config.hostname=172.16.3.32 org.opennms.newts.config.keyspace=newts org.opennms.newts.config.port=9042 #org.opennms.newts.config.username=opennms #org.opennms.newts.config.password=secret1234
Mit dem Parameter org.opennms.timeseries.strategy wird zunächst das Backend festgelegt. Mit den Parametern org.opennms.newts.config wird dann der Zugriff auf das Cassandra Cluster konfiguriert. Unter hostname wird eine oder mehrere durch Komma getrennte Cassandra Node(s) eingegeben. In unserem Fall ist das der Server 172.16.3.32, den wir oben konfiguriert haben. Daneben können Cassandra Keyspace und Port für die Kommunikation definiert werden. Erfordert Cassandra eine Authentifizierung, können Benutzername und Passwort hinterlegt werden. In unserem Beispiel haben wir bisher die Authentifizierung für Cassandra noch nicht eingerichtet. Die Parameter für die Authentifizierung bereiten wir deshalb vor, lassen sie aber noch auskommentiert.
Das Newts-Schema muss nun zunächst auf dem Cassandra-Cluster installiert werden. Dies geschieht durch die Ausführung des folgenden Skripts:
<OpenNMS-Home>/bin/newts init
In der aktuellen Version von OpenNMS wird bei der Ausführung des Newts Init-Skripts – entgegen dem in opennms.properties konfiguriertem Cassandra Host – localhost verwendet. Dies ist ein bekannter Bug, ein Workaround ist in NMS-8051 beschrieben. In OpenNMS Version 17.0.1 ist der Bug behoben. Das Newts Init-Skript unterstützt in der aktuellen Version noch keine Authentifzierung an Cassandra (siehe NMS-8064). Die Implementierung ist für OpenNMS Version 17.0.1 geplant. Die Einrichtung der Cassandra-Authentifizierung wird daher erst nach der Newts-Initialisierung durchgeführt.
Cassandra Zugriff absichern
Nachdem das Newts-Schema auf dem Cassandra Cluster installiert ist, kann nun auch der Zugriff auf die Datenbank abgesichert werden. Hier ändert man die Cassandra Konfigurationsdatei <Cassandra-Home>/conf/cassandra.yaml wie folgt:
authenticator: PasswordAuthenticator authorizer: CassandraAuthorizer
Nach einem Neustart von Cassandra ist der Zugriff auf die Datenbank nur noch mit Benutzername und Passwort möglich.
Den Zugriff auf die Datenbank erhält man mit dem Client Tool <Cassandra-Home>/bin/cqlsh mit der Angabe eines Hosts. Als Default-Benutzernamen und -Passwort verwendet man cassandra. Folgender Befehl startet den cqlsh-Client in der Beispiel-Umgebung:
./bin/cqlsh 172.16.3.32 -u cassandra -p cassandra
Auf der Konsole gibt es nun die Möglichkeit, Datenbankabfragen in der Cassandra Query Language (CQL) abzusetzen, die an SQL angelehnt ist. Eine genaue Dokumentation dazu findet sich hier.
Per CQL kann man nun das Passwort für den Standard-Adminbenutzer cassandra ändern und einen Benutzer für den Zugriff von OpenNMS setzen. Dafür sind folgende CQLs nötig:
ALTER USER cassandra WITH PASSWORD 'secret4321'; CREATE USER opennms WITH PASSWORD 'secret1234'; GRANT ALL PERMISSIONS ON KEYSPACE newts TO opennms;
Der Zugriff auf Cassandra ist nun abgesichert. Nun kann auch die in OpenNMS bereits vorbereitete Authentifizierung aktiviert werden. Hierzu muss die OpenNMS Konfigurationsdatei <OpenNMS-Home>/etc/opennms.properties angepasst werden, indem die Kommentarzeichen der bereits vorbereiteten Zeilen entfernt werden:
org.opennms.newts.config.username=opennms org.opennms.newts.config.password=secret1234
OpenNMS kann nun gestartet werden, um die Performance-Daten in Cassandra abzulegen.
Erster Test
In einem ersten kurzen Test in einer Umgebung mit ca. 500 überwachten Geräten und ca. 8.000 SNMP-Interfaces, für die Daten gesammelt wurden, war deutlich zu sehen, wie sich die I/O-Wait des Systems deutlich nach unten verringert hat. Gerade in größeren Umgebungen mit mehreren tausend überwachten Geräten wird der Einsatz von OpenNMS mit Newts einen großen Performance-Vorteil bringen. In der aktuellen OpenNMS-Version 17.0.0 gibt es noch einige Einschränkungen, die mit der nächsten Version 17.0.1 behoben werden sollen. Neben den oben beschriebenen Problemen mit dem Newts Init-Skript gibt es aktuell noch Probleme mit dem NRTGraphing unter Newts (siehe NMS-8038), die für die Version 17.0.1 bereits behoben sind. Auch eine Übernahme der in RRD-Dateien gespeicherten Daten ist aktuell noch nicht möglich. Hierfür ist ein Migrationstool in Arbeit, das voraussichtlich auch in Version 17.0.1 enthalten sein wird (siehe HZN-344).
Weiterführende Dokumentation
Weitere Hilfe und Anleitungen findet man in folgenden Dokumentationen:
Weitergehende Fragen zu OpenNMS beantworten wir Ihnen natürlich auch gerne persönlich – sprechen Sie uns einfach an!
