Seite wählen

NETWAYS Blog

Weekly Snap: From Cluster IPs & Intermapper Tips to Virtual Windows XP Mode & New Course Venues

19 – 23 December bid all a Merry Christmas, with handy ideas for network monitoring, simplifying cluster source IP, using Windows XP on Windows 7 and new training course locations.
Martin S started by sharing his secret for fast network troubleshooting: Intermapper displays information on the structure, status, data transfer volumes, available bandwidth and potential network problems in real-time on a network map, via SNMP.
Markus N then announced new NETWAYS training venues for 2012. Alongside courses in Nuremberg, “Icinga Availability Monitoring” is now offered in Düsseldorf and “Puppet Configuration Management” in Zurich. “Nagios Availability Monitoring” and “SLA Reporting” classes will now be held at a second Nuremberg venue, at the Park Inn Hotel. What hasn’t changed however, is our training course content and concept – intensive knowledge transfer in small groups, in a casual and hands-on environment.
Following on, Ansgar explained how to run old programs on Windows 7 in XP mode with the help of Windows Virtual PC. As long as the hardware can support the extra virtualization load, both Windows XP mode and Virtual PC can be easily downloaded and installed, alongside the desired, old programs. Thanks to the “seamless mode” and ability to access Windows 7 files, this virtual solution is makes using older applications with the XP look and feel, a breeze.
As a final Xmas contribution, Carsten showed how to change the source address of a cluster with Pacemaker. As he found the existing OCF Resource agent script, known as IPsrcaddr to be somewhat unreliable, Carsten wrote and shared his own. Once his resource agent, IPsrcaddr2 is filed in the right place, configuration of Corosync/Pacemaker a one-liner. It can then be used to set the source IP address of Icinga checks. This is handy in a two-node cluster, as the cluster IP can be used as opposed to setting both IPs in the firewall or NRPE daemons.

Weekly Snap: Load balancing with Cluster IP, PHP memory tracking with Memtrack, new ACKP SensorProbe & Pgpool 2

26 – 30 September bid summer farewell with load balancing and PHP tips, the arrival of a new AKCP sensor probe, and developments in the MySQL – PostgreSQL realm.
Bernd bemoaned recent news from Oracle of new extensions for MySQL Enterprise. As announced in the Oracle blog, a new Enterprise Scalability Extension will join the ranks of the Enterprise High Availability and Enterprise Security modules. This follows the trend to offer much needed extensions for large environments only to commercial users, which can alienate the MySQL user community into the arms of competitor software such as PostgreSQL.
Sebastian continued on this thread to look at PostgreSQL replication with Pgpool-II. A third party middleware between PGSQL client and server, Pgpool complements PostgreSQL’s streaming replication (as of version 9) by managing the failover between master and slave. Features include connection pooling, replication, load balancing, limit exceeding connections and parallel queries. More information can be found in both Pgpool 2 and PostgreSQL’s documentation.
Lennart then looked at load balancing on Linux minus the load balancer. With Cluster IP of Netfilter, extensive clusters with multiple nodes can be built by using a common IP address on all nodes. This way, all nodes can respond to the same address. To avoid confusion in ARP querying, Cluster IP uses a Multicast MAC for the cluster IP addresses, so that incoming packets are received by participating nodes. It also uses a hash to distinguish between source IPs or ports etc, ensuring that nodes only answer queries relevant to them.
Following on, Marius shared his tip for monitoring memory capacity in PHP. The PECL extension Memtrack, tracks PHP memory usage and assists in troubleshooting, by enabling deviations in the logs to be detected.
Last but not least, hardware man Martin announced the arrival of AKCP Sensor Probe 4 to our online store. The much awaited device comes with 4 sensor ports in an AKCP Sensor Probe 8-like casing, making it perfect for a 19 inch rack. The AKCP Sensor Probe 4 features Cat 5 sensor connection for many different sensors, simple installation and configuration, Icinga and Nagios plugins, SNMP Trap messaging, 100Mbit network connection and a web interface to send email alerts.

Einfache Lastverteilung unter Linux ohne Loadbalancer

Wer eine einfache und robuste Methode zur Lastverteilung seines Netztraffics sucht, wird bei netfilter fündig. Mit dem Target CLUSTERIP lässt sich auf einfachste Weise ein mehrere Knoten umfassender Cluster aufbauen. Zum Verfahren: Es findet eine gemeinsame IP-Adresse auf allen Knoten Verwendung und wird dort auch aufgesetzt, so dass nun alle Knoten auf diese Adresse antworten könnten. Da dies natürlich zu Verwirrungen bei ARP-Anfragen vom anfragenden Host bzw. Router führt, verwendet CLUSTERIP eine Multicast MAC für die Cluster-IP-Adresse. D.h. eingehende Pakete werden auf allen beteiligten Knoten empfangen. Damit nun aber nicht jeder Knoten auf die Anfrage antwortet, verwendet CLUSTERIP einen Hash über wahlweise die Source-IP, Source-IP und -Port oder Source-IP,-Port und Destination-Port, um zu entscheiden, ob er auf die Anfrage antworten darf. Somit ist auch keine Kommunikation der Knoten untereinander nötig, um zu entscheiden wer der „richtige“ Knoten ist.
Hier nun ein kleines Beispiel, eines Webclusters, bestehend aus den beiden Knoten node1 und node2. Es reichen jeweils zwei Kommandos aus, den Cluster zu erzeugen.
Kommandos auf node1:
root@node1# iptables -A INPUT -i eth1 -d 192.168.56.20 -p tcp –dport 80 -j CLUSTERIP –new –hashmode sourceip –clustermac 01:23:45:67:89:AB –total-nodes 2 –local-node 1
root@node1# ifconfig eth1:0 192.168.56.20/24 up
Analog ist auf node2 mit
root@node2# iptables -A INPUT -i eth1 -d 192.168.56.20 -p tcp –dport 80 -j CLUSTERIP –new –hashmode sourceip –clustermac 01:23:45:67:89:AB –total-nodes 2 –local-node 2
root@node2# ifconfig eth1:0 192.168.56.20/24
die Konfiguration abgeschlossen. Die Destination-Adresse ist die geimeinsame IP, wir verwenden in diesem Beispiel nur die Source-IP als Hash. Da in diesem Beispiel auf beiden Konten das gleiche Interface eth1 werwendet wird, unterscheiden sich die beiden Befehle lediglich in der Option  –local-node, welche die „Position“ im Cluster bestimmt bzw. um den wievielten Knoten es sich handelt. Dies kann nun auch mit
root@node1# cat /proc/net/ipt_CLUSTERIP/192.168.56.20
dem Kernel entnommen werden. Hier steht also drin, für was der jeweilige Host zuständig ist. Möchte man nun z.B. node1 aus dem Cluster herausnehmen, muss man dies über eine Konfiguration auf beiden Hosts vornehmen.
root@node1# echo „-1“ > /proc/net/ipt_CLUSTERIP/192.168.56.20
root@node2# echo „+1“ > /proc/net/ipt_CLUSTERIP/192.168.56.20

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.