snom asterisk portal

Seit Freitag ist das neue snom Asterisk Portal online, bei dem wir nicht ganz unbeteiligt waren ;-)

Grundsätzlich sind da alle Feinheiten im Zusammenspiel zwischen snom Voice Over IP Telefonen und Asterisk 1.2 (+BRISTUFF) und Asterisk 1.4 beschrieben. Es ist also quasi die Referenz für die Zusammenarbeit von snom phones (300, 320, 360, 370 sowie M3) und Asterisk.

Feedback ist gerne willkommen!

CIPHWALL BUSINESS IPSEC

Fürs Protokoll:


CIPHWALL BUSINESS ( 7x 1GBit/s NICs ):

IPSEC, Blowfish SHA1: 904 MBit/s Throughput.


Langsam sind unsere Produkte also definitv nicht ;)

Bezugsquellen gibt es bei unserem Vertrieb (vertrieb@ciphron.de) oder (05 11) 59 02 54 - 70.

check_hcb100 - Nagios prüft Blankom Kabelnetz Kopfstelle

Nagios ist zwar nur eine Überwachungssoftware, aber die Bandbreite an verschiedenen Diensten und Anwendungen, welche man damit im Auge behalten kann, ist enorm. Heute stellen wir ein eher exotisches Szenario vor. Das Beispiel zeigt sehr schön wie einfach es ist fast beliebige Geräte einzubinden.

Ein Kabelnetzbetreiber aus der Region wollte seine Kopfstellen der Firma Blankom aus der Ferne überwachen und dabei so wenig Aufwand wie möglich betreiben. Außerdem sollte es möglich sein im Fehlerfall ein manuelles Failover von einer Komponente durchzuführen. Eine Kopfstelle empfängt ein TV Signal über DVB-T/S, IP oder ein terristisches Signal und speist es in ein Kabelnetz ein.

Sie besteht aus mehreren Transmittermodulen und einem Controllermodul. Alle Module sind über einen Bus verbunden. Das Signal ins Kabelnetz wird durch alle Module geschliffen. Wenn ein Modul kaputt geht, fallen die entsprechenden Sender aus, aber alle anderen Module laufen uneingeschränkt weiter. Das Controllermodul spricht IP und der Hersteller Blankom hat für uns SNMP in die Firmware eingebaut.

Um das Monitoring Gerätes zu bewerkstelligen haben wir ein kleines Nagios Plugin entwickelt. Es kann die Temperatur und die Position und den Status der Kassetten/Module auf dem Bus überwachen.

Der Typ ist wichtig, damit bei einem Austausch einer defekten Kassette keine Fehler durch ein falsches Modell unbemerkt bleiben. Damit auch mit dem Setup nicht vertraute Servicetechniker den einen Hardwaretausch durchführen können haben wir Nagvis mit einem Foto der Kopfstelle verwendet. Durch rote bzw grüne Lampen wird jeweils der Status der Kassetten signalisiert.

Für die Failoverfunktionalität haben wir eine zusätzliche Kassette als Reserve in alle Kopfstellen verbaut. Der Nagiosserver hält die Konfiguration aller Kassetten. Im Fehlerfall taucht ein Failoverbutton auf der Grafik im Nagvis auf. Beim Klicken wird die Konfig der ausgefallenen Kassette auf die Reservekassette kopiert. Damit kann der Service aus der Ferne wieder hergestellt werden und der Servicetechniker kann den Hardwaretausch ohne Zeitdruck am nächsten Arbeitstag vornehmen.

Falls jemand selber eine Kopfstelle herumstehen hat und das Plugin ausprobieren möchte kann er es auf unserer Website im Downloadbereich finden. Damit SNMP funktioniert sind allerdings noch ein paar kleine Einstellungen in der Kopfstelle nötig. Hilfe gibts entweder direkt bei Blankom oder auch sehr kompetent bei uns :-).

PGPool-II als Loadbalancer und HA Lösung für Postgres

Im Netz findet man eine Menge verstreuter Informationen über PGPool. Es gibt eine Dokumentation, aber sie reißt viele Funktionen nur an und lässt Einsteiger an vielen Stellen im Dunkeln. Es hat mich eine Menge Mühe gekostet die Software wie gewünscht zum Laufen zu bringen. Gerade das Aufsetzen von der Online Recovery Scripte hat sich sehr in die Länge gezogen, weil Funktion, Aufrufszeitpunkt und -ort nicht klar dokumentiert sind. Aus diesem Grund schreibe ich heute ein kleines Howto über PGPool-II.

Als erstes braucht man ein Hostsystem für PGPool. Wir hatten zuerst OpenBSD im Auge, weil es über hervorragende Routing und TCP Loadbalancing Funktionen verfügt. Neben Postgres brauchten wir auch Loadbalancing für HTTP. Compilieren lässt sich PGPool wenn man ein paar Ports installiert hat und es funktioniert auch. Allerdings hatten wir später Versionsprobleme beim Onlinerecovery. Aus diesem Grund haben wir unsere Loadbalancer unser Ubuntu Linux aufgesetzt. Von den Packeten aus dem Repository raten wir allerdings ab, weil sie mittelmäßig veraltet sind. Kompilieren war unter Ubuntu relativ einfach.

Die Configuration in der pgpool.conf ist relativ gut dokumentiert. Im Grunde reicht es die IPs und Ports der Postgres Nodes einzutragen und PGPool funktioniert erstmal. Doch dann kommt die Wahl des Modes. Hier stehen verschiedene Modi zur Verfügung. In welcher Kombination sie Funktionieren lässt sich der Matrix im pgpool readme entnehmen.

Da es in unseren Applikationen wenig Schreiblast und viel Leselast gibt, haben wir uns für den Replication Mode entschieden. Wie man der Matrix im Readme entnehmen kann, ist im Replication Mode auch Loadbalancing möglich.

Alle SELECT Querys werden vom PGPool gleichmäßig auf alle Nodes aufgeteilt und die Last sinkt dadurch signifikant. Schreibende Querys wie z.b. INSERT, UPDATE oder DELETE werden auf allen Nodes ausgeführt. Es ist hier wichtig, dass sie deterministisch sind, also überall zum gleichen Ergebnis führen. Ansonsten kann es passieren, dass die Datenbanken inkonsistent werden. Besondere Vorsicht ist bei Funktionen wie NOW() oder RAND() geboten.

Aufpassen muss man auch bei Stored Procedures. Da mit einem SELECT Query aufgerufen werden hält der PGPool sie für lesende Abfragen. Das ist allerdings nicht immer der Fall. Als Lösung bietet es sich an bei schreibenden Stored Procedures den Kommentar /* NO LOADBALANCING */ zu schreiben.

Damit wird der Query auf allen Nodes ausgeführt. Der Preis für die Möglichkeit keinen Master Server zu haben darin besteht, dass man sich selber darum kümmern muss, dass alle Server immer in sync bleiben.

Da stellt sich die Frage was man anstellen muss damit Server in syncron werden. Im Postgres gibt es eine Funktion namens PTR - Point in Time Recovery. Diese macht sich PGPool zu nutze und automatisiert den Vorgang in drei kleinen Scripten die leider kaum dokumentiert sind. Dabei ist es wichtig dass alle Postgres Server untereinander Daten kopieren können. Außerdem müssen drei C Stored Procedures auf jedem Postgres Server installiert sein.

Online Recovery läuft nun in zwei Stufen ab. Stage1 - Checkpoint auf dem Master Server. Intern hat PGPool einen Master Server, aber prinzipiell sind alle Nodes gleichberechtigt. Danach wird das WAL (Write Ahead Log) gestartet und alle Daten zum Degraded Node kopiert.

Nun wartet PGPool, dass keine Verbindungen mehr zu einer Datenbank bestehen. In Stage 2 wird der Postgres Prozess auf dem neuen Node gestartet und stellt alle Transactions nach dem Checkpoint wieder her. Die letzten WAL Logs werden mit dem Befehl in der recovery.conf vom Master geholt. Dieser Prozess geht in der Regel sehr schnell. Danach ist der Node (wieder) Teil des Clusters und wird wie alle anderen Postgres Instancen behandelt.

Damit Online Recovery funktioniert ist es wichtig, dass kein anderer PGPool läuft. Ansonsten wartet PGPool vor Beginn von Stage2 bis zum Timeout, da PGPool die Verbindungen zu den Datenbanken in der Regel nicht beendet. Um den Datentransfer zwischen den Nodes zu ermöglichen bietet sich ssh pub-key Authentification an. Alternativ funktioniert auch ein gemeinsames SAN, NFS oder Samba Freigaben. Natürlich sollte man versuchen alle Rechner so homogen wie möglich zu halten, denn man weiß vorher nicht unbedingt von wo nach wo Online Recovery kopiert.

check_nt_wrapper - Prozessüberwachung Windows

Wer im Nagios Prozesse unter Windows überwachen will kommt um check_nt nicht herum. Allerdings funktioniert das Überprüfen von Programmen die nicht als Dienst unter Windows registriert sind nicht wie von unseren Kunden gewünscht. Wenn ein nicht registrierter Prozess nicht läuft dann meldet check_nt nur Warning statt Critical. Das mag Gründe haben, ist aber nicht sehr praktisch.

Damit es möglich ist Backupprogramme o.ä., die nicht als Dienst laufen im Nagios sicher zu eskalieren haben wir ein kleines Wrapper Plugin geschrieben, welches aus jeder Warning ein Critical macht. Sicher kein Kunstwerk, aber es tut seinen Dienst :-). Herunterladen kann man es wie immer in der Ciphron Downloadsektion.

BSI stellt Entwurf für Notfallmanagement online

Die Publikationen des Bundesamts für Sicherheit in der Informationstechnik (BSI) sind im Allgemeinen ja sehr gut. Auch der Entwurf des neusten Werks, BSI-Standard 100-4 Notfallmanagement, scheint da keine Ausnahme zu sein.

Nach einer detaillierteren Sichtung werde ich hier mal meine Meinung dazu posten.

(sh)

check_pix - Nagios checkt Cisco Pix Switches

Einer unserer Kunden wollte den Status seiner Cisco Pix überwachen. Im Internet gibt es viele Perl Scripts, die Router checken können. Allerdings waren sie entweder nicht flexibel genug oder funktionierten mit unseren pix nicht. Wir benutzen wie bei vielen Geräten check_snmp_int um den Traffic auf den Interfaces abzufragen. Weiterhin gibt es ein exzellentes check_pix_failover, welches den Status von pix Verbünden über die virtuelle IP testet.

Unser Plugin ist in der Lage die Anzahl der offenen Verbindungen zu überprüfen und ab bestimmten Schwellwerten zu eskalieren. Zusätzlich kann es benutz werden und freien Speicher überwachen. Zuletzt kann es die Load für 5 sek, 60 sek und 5 min checken.

Das Plugin findet ihr wie immer in unserer Downloadsektion.