Neu im NETWAYS Online-Shop – Stromleisten von Gude

gude-logo_neuNeben der Überwachung von Temperatur und Luftfeuchtigkeit, bietet der deutsche Hersteller Gude auch Stromleisten an, die für die unterschiedlichsten Anforderungen genutzt werden können.
Ob Schuko (z.B. Gude 8310 PDU) oder IEC13 (z.B. Gude 8310_1 PDU) Stecker – beide Varianten bietet Gude in verschiedenen Produkten an. Viele der Steckdosenleisten sind zudem von Haus aus in ein 19“-Rack einbaubar (u.a. Gude Expert PDU Basic 8110).
Wer sich jetzt fragt, wozu man Steckdosenleisten von Gude braucht – nun, die Leisten messen den Stromverbrauch, die Spannung, Frequenzen und vieles mehr. Hierzu sei erwähnt, dass die meisten Steckdosen über zwei Energiezähler verfügen (z.B. Gude 8310 PDU). D.h. es gibt einen Messwert seit Inbetriebnahme der Leisten, sowie einen weiteren der auch wieder zurückgesetzt werden kann, um z.B. die Daten von einem bestimmen Zeitraum zu sammeln.
Ein weiteres Highlight ist dann noch die Abfragemöglichkeit der Messdaten über SNMP(v1/v2), die dann in eine Monitoring Lösung wie z.B. Icinga eingebunden werden können. Einige der Stromleisten bieten sogar die Möglichkeit, einzelne Ports per SNMP SET abzuschalten oder zu aktivieren, was in einigen Situationen sicherlich eine wertvolle Funktion ist (z.B. Gude Expert Power Control 8210/8211).
Wer jetzt noch die Luftfeuchtigkeit und/oder die Temperatur mit einem Sensor, der direkt an den Stromleisten hängt, messen will, kann z.B. auf die Gude Expert Power Control 8090 (Temperatur) oder auf die Gude Expert PDU Basic 8111 (Temperatur / Hybrid) zurückgreifen.
Das Setup der einzelnen Steckdosenleisten ist ebenfalls sehr einfach und schnell erledigt. Hier bietet Gude die Software GBL_Conf für Windows und gblc für Linux kostenlos zum Download an.
Haben Sie Interesse an anderen Produkten für Ihre Überwachung?
Dann besuchen Sie einfach unseren NETWAYS Online-Shop.
Für einen persönlichen Kontakt sowie Fragen, stehen wir Ihnen ebenfalls sehr gerne zur Verfügung – nutzen Sie hierfür einfach unser Kontaktformular, schreiben Sie uns eine E-Mail oder rufen Sie uns an! Alle Details zum Shop-Kontakt finden Sie hier.

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Nginx als lastverteilter Bild Konverter

Der bekannte Webserver nginx, auf dem ca. 6% aller Webseiten des Internets laufen und der auch noch Reverse Proxy- und pop3/imap Proxyserver sein kann,  hat noch eine andere, oft wenig beachtete Möglichkeit. Mit Hilfe seines Image Filters ist es möglich, ihn als lastverteilten Lieferanten für Bilder zu benutzen, die er on-the-fly in andere Größen skalieren kann.

1. Lastverteilung

Nginx kann von Haus aus Anfragen an andere Webserver verteilen. Hierzu definiert man zuerst einen Upstream Server.

upstream cache_group {
server :8888 weight=100;
server 127.0.0.1:8888 weight=1;
}

Im vhost der die ersten Anfragen annimmt, definiert man dass der Webserver zuerst schaut, ob er das optimierte Bild schon hat, bzw. wenn das Original gefordert wird dieses sofort ausliefert.

server {
       listen   80;
       server_name mein_Server;
       location = /favicon.ico {
               #empty_gif;
               return 204;
       }
       location / {
               root                    /var/www/images;
               rewrite "^\/(50|100|150|200|250|300|350)\/(.*)\.(jpg|png)$" /$1/$2.$3 break;
               rewrite "^\/(.*)\.(jpg|png)" /$1.$2 break;
               error_page              404 = @cache;
       }
       location @cache {
               internal;
               proxy_pass              http://cache_group;
               proxy_store             on;
               proxy_store_access      user:rw  group:rw  all:r;
               proxy_temp_path         /var/www/temp;
               root                    /var/www/images;
       }
}

Falls der Server das Bild nicht findet schaut er, statt die error_page 404 auszugeben, in der cache_group nach. Hier greift die bei Upstream eingerichtete Gewichtung der Server. Nginx wird 100mal so oft auf dem zweiten Image Server suchen wie auf sich selbst. Wenn das Bild auch auf dem anderen Server nicht gefunden wird, wird es dort generiert. Das sorgt natürlich dafür, dass der erste Server entlastet wird. Das Verzeichnis /var/www sollte ein gemeinsames Share sein, damit das generierte Bild auch beiden Servern zur Verfügung steht.
Die im vhost eingestellten rewrite Regeln sind nötig, um unterscheiden zu können, welche Größe des Bildes angefordert wird, bzw. ob einfach das Original benutzt wird. Ruft der Client http://mein_Server/300/testbild.jpg ab bekommt er das Bild aus /var/www/images/300/testbild.jpg. Bei http://mein_Server/testbild.jpg greift die untere rewrite Regel und er kommt auf /var/www/images/testbild.jpg

2. Bildoptimierung

Der vhost für den Cache sieht folgendermaßen aus:

server {
        listen 8888;
        server_name mein_Server;
        location / {
                root                    /var/www/images/;
                error_page              404 = @local_image;
        }
        location @local_image {
                internal;
                proxy_pass              http://local_group_image;
                proxy_store             on;
                proxy_store_access      user:rw  group:rw  all:r;
                proxy_temp_path         /var/www/temp;
                root                    /var/www/images;
        }

Von hier aus springt er, falls das Bild dort nicht finden kann in den Image teil.
Hierfür muss man zunächst noch einen Upstream angeben:

upstream local_group_image {
        server 127.0.0.1:7777;
}

Und anschließend den vhost inklusive Imagefilter und Sicherheitscheck (es sollen nur die Größen erstellt werden, die wir vorher angeben) erstellen. Der Sicherheitscheck funktioniert durch den Regex in der Location Direktive.

server {
        listen 7777;
        server_name mein_Server;
        location ~ "\/(50|100|150|200|250|300|350)\/.*\.(png|jpg)$" {
                root    /var/www/images/;
                rewrite "^\/(50|100|150|200|250|300|350)\/(.*)\.(jpg|png)$" /$2.$3 break;
                image_filter resize $1 $1;
                image_filter_buffer 6M;
                image_filter_jpeg_quality 95;
        }
}

Jetzt sollte alles so funktionieren, wie wir uns das vorstellen. Das Konstrukt ist natürlich noch um weitere Server erweiterbar. Auch zusätzliche Aufgaben, wie z.B. SSL oder andere Bild Formate sind schnell integriert. Wen man so weit ist, wie hier beschrieben, hat man eine skalierbare, stabile und leicht gewichtige Lösung die mit ein wenig Mehrarbeit auch Ausfallsicher ist.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.