Select Page

NETWAYS Blog

WLAN Analyse mit Mac OS X Boardmitteln

Durch immer mehr WLAN Hotspots im Umkreis des eigenen Hotspots häufen sich oftmals die Verbindungsprobleme. Der Grund hierfür sind oftmals nicht der schlechte Empfang sondern Geräte die als Störer mit in das eigene Frequenzband funken. Im 2,4GHz Standard gibt es lediglich 3 Kanäle die genug Abstand in MHz zueinander haben, so dass es keine Störung des eigenen Kanals gibt. Das Problem ist jedoch, dass man Hotspots der Nachbarn oder angrenzenden Firmen selber nicht auf seine Vorstellungen konfigurieren kann, um eine bestmögliche Kanalwahl aller betroffenen Geräte steuern zu können. Eine gute Alternative ist, den stärksten Sender zu suchen und den gleichen Kanal zu wählen, damit sich die Geräte untereinander einigen können. Besser man geht auf eine Frequenz, die keiner nutzt. Aktuell gibt es im 5GHz Standard die Chance der einzigste im Umkreis zu sein. Falls nicht gibt es zumindest die Chance einen Kanal bzw. eine Frequenz zu erwischen, die einem allein zur Verfügung steht. Mit der Verbreitung von 5GHz tauglicher Hardware wird die Chance natürlich auch immer geringer.
Für eine entsprechende Analyse der Gegebenheiten im aktuellen Umkreis kann man mit den Boardmitteln von Mac OS X, die wirklich sehr versteckt zu finden sind, gut gearbeitet werden.
Mit gedrückter “alt”-Taste auf das WLAN-Symbol und anschließend die Diagnose öffnen. Es öffnet sich ein Assistent, der ignoriert werden kann. Im Menu “Fenster” können dann die verschiedensten Tools geöffnet werden. Interessant sind für oben beschriebenes Szenario die Programme “Scan” und “Leistung”.
Scan zeigt die aktuellen Netze mit gewähltem Frequenzbereich und -breite. Zudem den Received Signal Strength Indicator (RSSI) und die Stärke des Störsignals aus denen man den Signalrauschabstand ableiten kann.
Das Fenster Leitung stellt das ganze zusätzlich mit Hilfe eines sich aktualisierenden Graphen dar. Was sehr hilfreich werden kann, sobald man Räume oder Stockwerke wechselt und dessen Umgebung analysieren möchte.
WLAN-Leistung

Sebastian Saemann
Sebastian Saemann
CEO Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

Viva la Revolución?

Docker ist in aller Munde und erfährt derzeit einen riesen Hype um sich. Es wird teilweise gar von „Revolution“ gesprochen. Doch ist das ganze wirklich so revolutionär? Die Lager in der DevOps Community sind sich hierüber nicht ganz einig und sind teilweise gespalten. Die eingesetzten Technologien aus denen Docker besteht sind eigentlich nicht neu und werfen den Mehrwert, den man in der letzten Zeit durch Configuration Management Tools wie Puppet, Chef etc. gewonnen hat, teilweise wieder zurück. Im wesentlichen besteht Docker aus einer Container-Virtualisierung, einem Copy on Write Filesystem bzw. Overlay Filesystem, einem Repository, einer Versionsverwaltung und einer mächtigen API. Das ganze zusammengeschnürt und einfach zu steuern und zu verwenden ist dann Docker.
 
Die Plattform verfolgt den Continious Integration Gedanken mit der man kontinuierlich Änderungen, möglichst automatisiert mit einer Kette an Tests, in die Produktion ausrollt. Der Workflow sieht im einfachsten Fall vor, dass man ein Image startet, Änderungen an diesem Image durchführt und diese dann als „commit“ speichert. Aus diesem kann man wiederum weitere Instanzen klonen und kann sie, sollte etwas nicht wie gewünscht funktionieren, wieder auf einen älteren Stand zurückrollen.
 
Wie immer und auch bei anderen Lösungen birgt Docker nicht nur Vorteile. Technisch gibt es einige Herausforderungen und Probleme die bei der Integration in die Produktion früher oder später auftauchen werden. (Noch) keine Möglichkeit Disk I/O zu limitieren, kein Quota auf AUFS, keine persistenten Anwendungsdaten, keine vollständige Isolation, dynamische Hostnames, Loadbalancing um nur einige zu nennen. Neben technischen Herausforderungen gibt es außerdem das Workflow Dilemma, das sich wie schon erwähnt teilweise mit den Config Management Tools beißt und deshalb auch die Lager spaltet.
 
Der richtige Weg ist aber wohl mehr eine Glaubensfrage oder am ehesten dem Use-Case gezollt. Jedes Unternehmen hat eigene Anforderungen und muss diese gegen den „Docker-Workflow“ evaluieren. Die bereits existierenden Schwierigkeiten, die es in einer automatisierten Umgebung und Continious Integretion gibt, löst Docker deshalb auch nicht, aber es zeigt einen interessanten alternativen Weg auf. Die Antwort auf die ursprüngliche Frage der revolutionären Ansätze und des Umdenkens, kann wohl erst in einigen Jahren gegeben werden nachdem Erfahrungen gemacht wurden und man den tatsächlichen Einfluss bewerten kann. Mehr zum Thema und Docker erfährt man bei uns in den Trainings.

Sebastian Saemann
Sebastian Saemann
CEO Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

Mesos

Mit Mesos hat das Apache Projekt ein Cluster-Manager geschaffen, der sich um das Ausführen verteilter Applikationen kümmert.
Der Mehrwert ist, dass mit dem Framework ein Standard geschaffen werden soll, der das komplexe “Rad neu erfinden” für solche Zwecke abgeschafft werden soll und auf bereits funktionierende Software gesetzt werden kann. Ein Beispiel ist z.B. das managen eines Quorum in einem Cluster. Jeder Clusterstack wie Pacemaker/Corosync etc. hat seine eigene Logik. Mesos setzt hierfür auf das ebenfalls aus dem Hause Apache stammende Zookeeper. Das wiederum kann dann modular für Mesos, SolR, eigene Entwicklungen usw. genutzt werden.
Was macht jetzt Mesos? Mesos besteht aus mind. einem Master und einem Slave. Der Master verteilt Jobs oder Anwendungen und die Slaves führen diese aus. Die Slaves melden außerdem regelmäßig ihre aktuelle Auslastung, so dass der Mesos-Master weiß wohin er die neuen Aufgaben verteilen soll. In dieses Konstrukt kann sich ein weiteres Framework, dass für die unterschiedlichsten Zwecke verwendet werden kann, registrieren. Es gibt die wildesten Frameworks genannt Marathon, Aurora, Chronos und viele mehr. Jedes nutzt als Basis Mesos, aber eben für seine eigenen Zwecke.
Chronos ist z.B. für das Ausführen von zeitgesteuerten Jobs entwickelt worden. Also ein Crond, nur eben, dass die Cronjobs nicht nur auf einem Host sondern auf vielen ausgeführt werden können. Mit Marathon werden Commands oder ganze Anwendungen am laufen gehalten. Einmal gestartet, sorgt es dafür dass es immer mind. xmal gestartet ist. Ein Job kann z.B. ein “/usr/sbin/apachectl -d /etc/apache2 -f apache2.conf -e info -DFOREGROUND”. Das setzt natürlich die installierte Software auf dem Slave voraus, also Apache2.
Noch abstrakter geht es indem man Mesos konfiguriert einen externen containerizer zu nutzen: Docker. Obiges Beispiel würde also nicht auf dem Slave direkt gestartet werden, sondern ein Docker Container starten und in diesem das Command ausführen. Betrieben werden kann das ganze auf physischen oder in virtuellen Servern oder beidem.
Wozu man so etwas verwenden kann muss man letztendlich selbst entscheiden. Die Lösung verfolgt den SaaS/PaaS Ansatz und stellt im wesentlichen Hardwareressourcen aus einem Pool(IaaS) zur Verfügung und bietet Bibliotheken, Frameworks und APIs um sie zu steuern. Das Buzzword nennt sich ganz allgemein Cloudcomputing 🙂
Für Docker werden wir übrigens noch dieses Jahr Schulungen anbieten.

Sebastian Saemann
Sebastian Saemann
CEO Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

Virtualisierung stoppen!

Trotz der provokativem Überschrift werde ich einer der letzten sein, der dafür plädiert weniger zu virtualisieren – ganz im Gegenteil. In Zeiten von IaaS, PaaS, SaaS geht eigentlich nichts ohne Virtualsierung. Ob Vollvirtualsierung, Paravirtualisierung oder Container-based-Virtualisierung die Möglichkeiten sind nahezu grenzenlos, die aufsetzenden Frameworks unzählig.
In produktiven Umgebungen mit hoher und unterschiedlichster Workload und viel gemeinsam genutzten Infrastrukturkomponenten bzw. Ressourcen ist es deshalb umso wichtiger einzelne virtuelle Maschinen oder Container zu “stoppen” besser gesagt zu drosseln. Natürlich kann man mit mehr Hardware aufkeimende Engpässe entsprechend ausdehnen. Oft sind aber kleine und ungewollte Verhalten der Auslöser für querschießende Prozesse, die parallel ausgeführte Maschinen beeinflussen und somit die Qualität des generellen Services beeinflussen.
Drosseln kann man u.a. CPU Zeit, Memory, IO auf Blockdevices, IO auf NICs. Wie immer gibt es mehrere Möglichkeiten entsprechende Limits zu setzen. Pauschal lässt sich mit cgroups über die Virtualsierungstechnologien hinweg gut und effizient drosseln. Für KVM bzw. Qemu sind die eingebauten Features die effizientesten. Beim aktiven Drosseln muss der CPU des Hosts entsprechend arbeiten und ist laut IBM hier einen Tick effizienter bei Qemu-capped im Vergleich zu cgroup-capped.
KVM Prozesse können mit libvirt auch zur Laufzeit gedrosselt werden. Die Bandbreite der ersten Festplatte einer KVM-VM würde man mit Hilfe von virsh wie folgt auf 10MB/s und 50iops drosseln:
virsh blkdeviotune $virshid $name --live $total_bytes_sec $total_iops_sec
virsh blkdeviotune 123 vda --live 10240000 50

Das Cloud-Computing Framework OpenNebula wird in seiner nächsten Version ebenfalls Funktionen zur Drosselung bereitstellen.
Wem das alles zu umständlich ist, nutzt einfach das folgende funktionierende aber nicht ganz ernstgemeinte Command:
while true; do kill -STOP $ID; sleep 1; kill -CONT $ID; done

Sebastian Saemann
Sebastian Saemann
CEO Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

ZFS Replikation mit zrep

Das Dateisystem ZFS wurde ursprünglich von der Firma “Sun Microsystems” entwickelt, die dann später bekanntermaßen von Oracle gekauft wurde. Das sind jetzt keine wirklichen Neuigkeiten und ZFS ist auch nicht neu, aber immer noch in seinen Bereichen das Maß der Dinge. Auf Linux muss man allerdings wegen Lizenzschwierigkeiten von Haus aus darauf verzichten und sich mit dem FUSE Modul oder dem zfsonlinux Kernel Modul Abhilfe schaffen. Für Linux steht ja schon seit langem BTRFS in den Startlöchern, was aber bis heute noch nicht als stable markiert ist.
ZFS ist ein Copy on Write Filesystem, das durch ein reiches Feature Set glänzen kann. Unter anderem unterstützt es Snapshots und kann diese Snapshots inkrementell versenden, um einen Datenzustand als Backup oder für höhere Verfügbarkeit auf einen weiteren Server vorhalten zu können. Das ganze ist denkbar einfach:
zfs snapshot tank/myzfs@1hourago
zfs snapshot tank/myzfs@now
zfs send -I tank/myzfs@1hourago tank/myzfs@now | ssh server2.domain zfs receive tank/myzfsbackup
Die drei Befehle erzeugen zwei Snapshots die dann dann mit “zfs send” inkrementell von “1hourago” bis “now” an den “server2” gesendet und dort empfangen werden. Die Schwierigkeit besteht jetzt darin, Snapshots auch wieder zu löschen und dafür zu sorgen, dass die Snapshots aufeinander aufbauen.
Hierfür gibt es ein KSH Script mit dem Namen zrep. Zrep sorgt sich genau darum und kann noch viel mehr. Neben dem initialen synchronisieren und dem Handling der Snapshots kann mit zrep auch auf den zweiten Server im Fehlerfall geschwenkt werden. Während des Schwenks werden die Filesysteme auf beiden Seiten readonly gesetzt, der letzte Zustand gesynced und anschließend läuft die Replikation in die andere Richtung weiter.
Mehr Informationen zu zrep findet man auf der Website zu dem Projekt.

Sebastian Saemann
Sebastian Saemann
CEO Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.