Eine Einfüh­rung in OpenNMS und Newts

Bis zur OpenNMS Version 16 wurden Perfor­mance-Daten (wie zum Beispiel CPU-Auslas­tung oder Auslas­tung von Netz­werk­in­ter­faces) in “RRD-Dateien” abge­legt. Dabei wurde jede Perfor­mance-Metrik (einzelne Metriken konnten zu Gruppen zusam­men­ge­fasst werden) pro Node/Interface in einer eigenen RRD-Datei gespei­chert. In der Stan­dard­kon­fi­gu­ra­tion werden die Werte in einem Inter­vall von fünf Minuten durch OpenNMS abge­fragt; inner­halb dieses Inter­valls mussten alle RRD-Dateien geöffnet, der neu erho­bene Wert gespei­chert und die Datei anschlie­ßend wieder geschlossen werden. Diese Vorge­hens­weise sorgte vor allem in Umge­bungen mit einer großen Anzahl an über­wachten Geräten für eine hohe I/O-Last und führte zu Engpässen in der Perfor­mance. In der OpenNMS-Version 17 wurde mit “Newts” eine neue Möglich­keit geschaffen, Perfor­mance-Daten abzu­legen. Hier werden die Daten in der NoSQL-Daten­bank “Apache Cassandra” gespei­chert, die sich über mehrere Nodes (Server) verteilen kann.
Im Folgenden soll der Aufbau einer Single-Node-Instal­la­tion von Cassandra und die Konfi­gu­ra­tion von OpenNMS zur Verwen­dung von Newts beschrieben werden. Für die Beispiel­kon­fi­gu­ra­tion 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.

Instal­la­tion von Apache Cassandra

Zunächst muss die benö­tigte Soft­ware herun­ter­ge­laden werden. Diese ist (Stand Januar 2016):

Wurde das Oracle Java JDK als tar.gz Archiv herun­ter­ge­laden, kann es einfach durch Entpa­cken (zum Beispiel unter /opt) instal­liert 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 instal­liert. Nun kann die Instal­la­tion von Apache Cassandra erfolgen. Die Soft­ware kann von der Website als .tar.gz-Archiv bezogen werden. Wahl­weise werden durch die DataStax-Commu­nity auch fertige Debian- und RPM-Packages bereit­ge­stellt. Diese Anlei­tung beschreibt die Instal­la­tion 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

Konfi­gu­ra­tion

Nach dem Entpa­cken sollte vor dem ersten Start von Cassandra die Konfi­gu­ra­tion durch­ge­führt werden, indem die Datei <Cassandra-Home>/conf/cassandra.yaml editiert wird. Folgende Para­meter sollten hierbei ange­passt werden:

cluster_name: 'Newts Cluster'
#rpc_address: localhost
rpc_interface: eth0

Mit dem Para­meter cluster_name wird ein Name für das Cassandra-Cluster vergeben. Über die Para­meter rpc_address und rpc_interface wird eine IP (Para­meter rpc_address) oder ein Netz­werk­in­ter­face (Para­meter rpc_interface) ange­geben, über die bzw. das Cassandra Daten­bank­ab­fragen entge­gen­nimmt. Dabei darf entweder der Para­meter rpc_address oder der Para­meter  rpc_interface gesetzt werden, nicht aber beide. Die Konfi­gu­ra­tion wird benö­tigt, damit die OpenNMS-Instal­la­tion später Daten­bank­ab­fragen absetzen kann.

Start und Stop

Nach Abschluss der Konfi­gu­ra­tion 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 Vorder­grund - die Ausgabe sollte nun auf Zeilen, die “ERROR” order “WARN” enthalten, über­prüft werden.
Mit folgendem Befehl kann Apache Cassandra wieder gestoppt werden:

pkill -f CassandraDaemon

Um Start und Stop zu auto­ma­ti­sieren, kann folgendes Init-Skript verwendet werden, das als /etc/init.d/cassandra auf dem System abge­legt 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 Umge­bungs­va­ria­blen wie zum Beispiel JAVA_HOME korrekt zu setzen, sollte zusätz­lich die Datei /etc/default/cassandra mit folgendem Inhalt ange­legt werden:

JAVA_HOME=/opt/java
export JAVA_HOME

Konfi­gu­ra­tion von OpenNMS

OpenNMS in Version 17 verwendet stan­dard­mäßig als Backend RRD-Dateien, um Perfor­mance Daten zu spei­chern. Um das Backend zu ändern, müssen einige Einstel­lungen in der OpenNMS Konfi­gu­ra­ti­ons­datei <OpenNMS-Home>/etc/opennms.properties vorge­nommen werden. Folgende Einstel­lungen sollten ange­passt 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 Para­meter org.opennms.timeseries.strategy wird zunächst das Backend fest­ge­legt. Mit den Para­me­tern org.opennms.newts.config wird dann der Zugriff auf das Cassandra Cluster konfi­gu­riert. Unter host­name wird eine oder mehrere durch Komma getrennte Cassandra Node(s) einge­geben. In unserem Fall ist das der Server 172.16.3.32, den wir oben konfi­gu­riert haben. Daneben können Cassandra Keyspace und Port für die Kommunikation defi­niert werden. Erfor­dert Cassandra eine Authen­ti­fi­zie­rung, können Benut­zer­name und Pass­wort hinter­legt werden. In unserem Beispiel haben wir bisher die Authen­ti­fi­zie­rung für Cassandra noch nicht einge­richtet. Die Para­meter für die Authen­ti­fi­zie­rung bereiten wir deshalb vor, lassen sie aber noch auskommentiert.
Das Newts-Schema muss nun zunächst auf dem Cassandra-Cluster instal­liert werden. Dies geschieht durch die Ausfüh­rung des folgenden Skripts:

<OpenNMS-Home>/bin/newts init

In der aktu­ellen Version von OpenNMS wird bei der Ausfüh­rung des Newts Init-Skripts - entgegen dem in opennms.properties konfi­gu­riertem Cassandra Host - local­host verwendet. Dies ist ein bekannter Bug, ein Work­around ist in NMS-8051 beschrieben. In OpenNMS Version 17.0.1 ist der Bug behoben. Das Newts Init-Skript unter­stützt in der aktu­ellen Version noch keine Authen­tif­zie­rung an Cassandra (siehe NMS-8064). Die Imple­men­tie­rung ist für OpenNMS Version 17.0.1 geplant. Die Einrich­tung der Cassandra-Authen­ti­fi­zie­rung wird daher erst nach der Newts-Initia­li­sie­rung durchgeführt.

Cassandra Zugriff absichern

Nachdem das Newts-Schema auf dem Cassandra Cluster instal­liert ist, kann nun auch der Zugriff auf die Daten­bank abge­si­chert werden. Hier ändert man die Cassandra Konfi­gu­ra­ti­ons­datei <Cassandra-Home>/conf/cassandra.yaml wie folgt:

authenticator: PasswordAuthenticator
authorizer: CassandraAuthorizer

Nach einem Neustart von Cassandra ist der Zugriff auf die Daten­bank nur noch mit Benut­zer­name und Pass­wort möglich.
Den Zugriff auf die Daten­bank erhält man mit dem Client Tool <Cassandra-Home>/bin/cqlsh mit der Angabe eines Hosts. Als Default-Benut­zer­namen und -Pass­wort 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öglich­keit, Daten­bank­ab­fragen in der Cassandra Query Language (CQL) abzu­setzen, die an SQL ange­lehnt ist. Eine genaue Doku­men­ta­tion dazu findet sich hier.
Per CQL kann man nun das Pass­wort für den Stan­dard-Admin­be­nutzer 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 abge­si­chert. Nun kann auch die in OpenNMS bereits vorbe­rei­tete Authen­ti­fi­zie­rung akti­viert werden. Hierzu muss die OpenNMS Konfi­gu­ra­ti­ons­datei <OpenNMS-Home>/etc/opennms.properties ange­passt werden, indem die Kommen­tar­zei­chen der bereits vorbe­rei­teten Zeilen entfernt werden:

org.opennms.newts.config.username=opennms
org.opennms.newts.config.password=secret1234

OpenNMS kann nun gestartet werden, um die Perfor­mance-Daten in Cassandra abzulegen.

Erster Test

In einem ersten kurzen Test in einer Umge­bung mit ca. 500 über­wachten Geräten und ca. 8.000 SNMP-Inter­faces, für die Daten gesam­melt wurden, war deut­lich zu sehen, wie sich die I/O-Wait des Systems deut­lich nach unten verrin­gert hat. Gerade in größeren Umge­bungen mit mehreren tausend über­wachten Geräten wird der Einsatz von OpenNMS mit Newts einen großen Perfor­mance-Vorteil bringen. In der aktu­ellen OpenNMS-Version 17.0.0 gibt es noch einige Einschrän­kungen, die mit der nächsten Version 17.0.1 behoben werden sollen. Neben den oben beschrie­benen Problemen mit dem Newts Init-Skript gibt es aktuell noch Probleme mit dem NRTGra­phing unter Newts (siehe NMS-8038), die für die Version 17.0.1 bereits behoben sind. Auch eine Über­nahme der in RRD-Dateien gespei­cherten Daten ist aktuell noch nicht möglich. Hierfür ist ein Migra­ti­ons­tool in Arbeit, das voraus­sicht­lich auch in Version 17.0.1 enthalten sein wird (siehe HZN-344).

Weiter­füh­rende Dokumentation

Weitere Hilfe und Anlei­tungen findet man in folgenden Dokumentationen:

Weiter­ge­hende Fragen zu OpenNMS beant­worten wir Ihnen natür­lich auch gerne persön­lich - spre­chen Sie uns einfach an!

Schreibe einen Kommentar

Cookie Einstellungen
Diese Website verwendet Cookies, um die bestmögliche Funktionalität zu gewährleisten. Mehr lesen

Akzeptiere alle Cookies Speichern