Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Jetzt<br />
mit<br />
SMB3 für VMs<br />
und Storage<br />
UEFI Secure<br />
Boot und Linux<br />
<strong>ADMIN</strong><br />
IT-Praxis & Strategie<br />
Software Defined<br />
Networking<br />
Redo<br />
Backup & <strong>Recovery</strong><br />
03/2014 März<br />
<strong>Erste</strong> <strong>Hilfe</strong><br />
<strong>Disaster</strong> <strong>Recovery</strong><br />
Linux-<strong>Recovery</strong> mit Boot-CD<br />
Tipps zur Windows-Rettung<br />
Datenbank-<strong>Recovery</strong><br />
Hyper-V<br />
Schnelle Linux-VMs durch<br />
Integration Services<br />
CRIU<br />
Prozesse einfrieren und<br />
wieder auftauen<br />
HA-Proxy<br />
Loadbalancing<br />
mit SSL-Support<br />
Spanning Tree<br />
Ethernet ohne Schleifen<br />
www.admin-magazin.de<br />
Raspberry Pi<br />
Mini-PC mit FreeBSD<br />
D EUR 9,80<br />
A EUR 10,80 - BeNeLux EUR 11,25<br />
CH sfr 19,60 - E / I EUR 12,75<br />
4 196360 509805 03
Service<br />
Editorial<br />
3<br />
Es war einmal<br />
Liebe Leserinnen und Leser,<br />
Es war einmal ein fleißiger Programmierer, der lebte in einem fernen Land.<br />
Er setzte sich zum Ziel, ein Programm zu schreiben, das Computer überwachen<br />
sollte. Das taufte er NetSaint, später Nagios.<br />
Die Kunde von Nagios verbreitete sich rasch und so scharte der Programmierer<br />
bald ein Häuflein Mitstreiter um sich, das ihm zur Hand ging. Im Lauf<br />
der Jahre installierten immer mehr Anwender seine Software, immer mehr<br />
Freiwillige trugen Verbesserungen und Erweiterungen bei. Und bald traten<br />
landauf, landab auch Berater auf, die sich so manchen Dukaten damit verdienten,<br />
Nagios für andere einzurichten und anzupassen.<br />
Allmählich gewann der Programmierer den Eindruck, er habe da einen dicken Fisch an der Angel. Den<br />
wollte er nicht schwimmen lassen, es sei denn, er habe drei Wünsche frei. Und so rief er: „Mantje, Mantje,<br />
Timpe Te, Buttje, Buttje in der See.“ Und der Fisch kam angeschwommen und fragte, was er wolle. „Ach“,<br />
sagte der Programmierer, „ich habe nun meine ganze Freizeit in Nagios investiert, aber reich werden<br />
andere damit. Ich wünsche mir eine eigene Firma, die mir mein täglich Brot sichern soll.“ „Geh nur hin“,<br />
sagte der Fisch, „du hast sie schon.“<br />
Nach einer Weile kam dem Programmierer jedoch in den Sinn, ob er nicht einen noch viel größeren Reibach<br />
machen könnte, wenn es nur ihm allein erlaubt wäre, den Namen seiner Software im Munde zu führen.<br />
Den Webmastern aber, die Zusätze für Nagios hosteten, den Veranstaltern, die Nagios-Konferenzen<br />
ausrichteten, den Enthusiasten, die Nagios-Foren pflegten und den Programmierern, die Nagios-Plugins<br />
entwickelten, sollte das fortan verboten sein. Sie alle hatten ihn groß gemacht, doch nun hatten sie ihre<br />
Schuldigkeit getan. So ging er wieder ans Wasser und rief den Fisch. Der fragte, was er diesmal wolle.<br />
„Ich möchte, dass niemand mehr irgendetwas nach Nagios benennt. Wer es dennoch tut, soll wegen<br />
Markenrechtsverletzung vor den Kadi kommen.“ „Geh nur hin“, sagte der Fisch, „das hast du schon.“<br />
Wieder arbeitete der Programmierer eine Zeit zufrieden an seiner Software. Da fiel sein Blick auf die letzten<br />
Getreuen, die Plugins entwickelten und sie auf einer Webseite nagios-plugins.org anboten. Auch mit<br />
denen wollte er nun kurzen Prozess machen. Reden wollte er nicht. Also rief er den Fisch und das Wasser<br />
war ganz violett und grau. Und nachdem der Fisch zum dritten Mal von dannen geschwommen war, verbogen<br />
sich hinterrücks die DNS-Einträge für nagios-plugins.org auf einen Server, den nur der Programmierer<br />
kontrollierte. Und die ahnungslosen Plugin-Entwickler waren über Nacht ausgesperrt.<br />
Noch einmal war der Programierer eine kurze Zeit zufrieden, dann rief er den Fisch zum vierten Mal. Da<br />
war die See ganz schwarzgrau und das Wasser gärte. Und er sagte … Halt! Weiter ist das Märchen noch<br />
nicht geschrieben. Aber wir ahnen, wie es ausgehen wird. Im Märchen siegt ja oft die Gerechtigkeit.<br />
@ leserbriefe@admin-magazin.de www.facebook.com/adminmagazin www.twitter.com/admagz<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
Service<br />
4 Inhalt<br />
<strong>ADMIN</strong><br />
IT-Praxis & Strategie<br />
<strong>Erste</strong> <strong>Hilfe</strong>ab Seite 36<br />
n Login<br />
8 Bücher<br />
Ansible und SNMP.<br />
10 Branchen-News<br />
Neues von Software und Projekten.<br />
14 Admin-Story<br />
Systemverwaltung mit OpenLMI.<br />
n Netzwerk<br />
18 Spanning Tree Protocol<br />
Wie organisiert Spanning Tree ein<br />
Ethernet-Netzwerk?<br />
24 OpenNMS und OCS<br />
OCS-Informationen in Überwachung<br />
mit OpenNMS integrieren.<br />
32 HA-Proxy<br />
Passthrough und Offloading:<br />
HTTPS balancieren mit der nächsten<br />
HA-Proxy-Version 1.5.<br />
n Schwerpunkt<br />
36 Redo Backup<br />
Systeme vollständig sichern und<br />
wiederherstellen mit Redo Backup.<br />
40 Relax and Recover<br />
Rettungsmedien per Bash im<br />
laufenden System erzeugen.<br />
46 Windows-<strong>Disaster</strong><br />
<strong>Disaster</strong> <strong>Recovery</strong> mit Windows.<br />
52 Database <strong>Recovery</strong><br />
Backup und <strong>Recovery</strong> bei Datenbanken:<br />
Woran man denken sollte.<br />
Tree<br />
Bäume statt Schleifen im<br />
18Spanning<br />
Ethernet.<br />
Service<br />
3 Editorial<br />
4 Inhalt<br />
6 Heft-CD<br />
114 Impressum und <strong>Vorschau</strong><br />
Ausgabe 03-2014<br />
Admin<br />
www.admin-magazin.de
Service<br />
Inhalt<br />
5<br />
Auf Dateizugriffe automatisch<br />
64Incron<br />
reagieren.<br />
86Fedora<br />
Die neue Version der<br />
freien Red-Hat-Variante.<br />
Redo<br />
Backup & <strong>Recovery</strong><br />
Seite 6 und 36<br />
n Know-how<br />
58 Neutron<br />
OpenStack Neutron als Beispiel für<br />
eine SDN-Implementierung.<br />
64 Incron<br />
Dateien und Verzeichnisse mit<br />
Incron überwachen.<br />
68 CRIU<br />
Linux-Prozesse speichern und<br />
wieder herstellen mit CRIU.<br />
74 Cloud Orchestration<br />
Automatisierung in der Cloud: Alles<br />
über Orchestration.<br />
n Security<br />
80 UEFI Secure Boot<br />
UEFI Secure Boot und alternative<br />
Betriebssysteme.<br />
n Basics<br />
86 Fedora 20<br />
Das neue Fedora-Release im Test.<br />
90 <strong>ADMIN</strong>-Tipps<br />
Die monatlichen Praxis-Tipps der<br />
Redaktion.<br />
n Virtualisierung<br />
92 Hyper-V und SMB3<br />
Von der neuen SMB-Version profitiert<br />
vor allem Hyper-V.<br />
96 MS Linux Integration Services<br />
Linux-VMs unter Hyper-V mit den<br />
MS Linux Integration Services<br />
beschleunigen.<br />
n Programmieren<br />
100 Go-Entwicklung<br />
Goroutinen und Channels.<br />
n FreeX<br />
106 FreeBSD Raspberry Pi<br />
FreeBSD läuft auch auf dem<br />
Rasp berry PI.<br />
68CRIU<br />
Linux-Prozesse einfrieren,<br />
analysieren und migrieren.<br />
106Raspberry Pi<br />
So kommt BSD auf den<br />
populären Mini-Computer.<br />
Ausgabe 03-2014
6<br />
Service<br />
Heft-CD<br />
CD kaputt?<br />
Wir schicken Ihnen kostenlos eine Ersatz-CD<br />
zu. E-Mail genügt: info@admin-magazin.de<br />
Redo Backup 1.0.4<br />
Heft-CD<br />
Auf dem beiliegenden Datenträger finden Sie das Backup- und<br />
Restore-System Redo Backup. Ausführlicher Artikel auf S. 36<br />
n Info<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31687<br />
[1] Redo Backup: [http://redobackup.org]<br />
n <strong>Recovery</strong>-Live-CD basierend auf<br />
Ubuntu Linux.<br />
n Sicherung und Wiederherstellung<br />
ganzer Betriebssysteme.<br />
n Vereinfachte Benutzeroberfläche<br />
auf Basis von Openbox und<br />
ADeskBar.<br />
n Live-CD mit Partclone, GParted<br />
und Red Hat Disk Utility für Dateisysteme<br />
und Partitionen.<br />
Legen Sie einfach die CD ins Laufwerk<br />
ein und starten Sie den Rechner.<br />
Möglicherweise müssen Sie noch im<br />
BIOS die richtige Boot-Reihenfolge<br />
einstellen. Danach können Sie Redo<br />
Backup starten und Ihr System sichern<br />
oder wiederherstellen und die<br />
mitgelieferten Tools zur Analyse und<br />
Reparatur von Partitionen und Dateisystemen<br />
starten. n<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
8<br />
Login<br />
Bücher<br />
Galina Peshkova, 123RF<br />
Neue Bücher zu Ansible und zum Simple Network Management Protocol<br />
Vorgelesen<br />
Systemadministratoren erfahren alles über die automatische Serverpflege<br />
mit Ansible sowie über das Simple Network Management<br />
Protocol SNMP. Oliver Frommel, Carsten Schnober<br />
Ansible ist jung und hip: Das quelloffene<br />
Python-Tool administriert Rechner<br />
übers Netzwerk via SSH, ganz ohne<br />
die Installation weiterer<br />
Software. Der Verlag Packt<br />
Publishing hat mit »Ansible<br />
Configuration Management«<br />
von Daniel Hall ein<br />
englischsprachiges Buch<br />
herausgebracht, das einen<br />
Überblick über das Werkzeug<br />
gibt. Es ist das bisher<br />
einzige Buch des Informatikers,<br />
der als System administrator Ansible<br />
im Berufsalltag einsetzt.<br />
Der Autor hält sich nicht mit Exkursen<br />
auf und setzt voraus, dass die Leser<br />
mit den grundlegenden Konzepten der<br />
Linux-Administration vertraut sind und<br />
bereits das Netzwerk sowie Tools wie<br />
SSH passend konfiguriert haben. So<br />
kommt er direkt zum Ansible-Setup.<br />
Dabei spielt er typische Szenarien an<br />
realistischen Beispielen wie dem per<br />
Ansible automatisierten Setup von<br />
Datenbanken durch. Auf diese Weise<br />
erhält der Leser einen Einblick in die<br />
Ansible-übliche Vorgehensweise, aus<br />
den zweckgebundenen Modulen sogenannte<br />
Playbooks zu schreiben.<br />
n Ansible<br />
Daniel Hall<br />
Ansible Configuration Management<br />
Packt Publishing, 2013<br />
92 Seiten<br />
25,99 Euro<br />
ISBN: 978-1783280810<br />
Von überschaubaren Setups, die in<br />
Syntax und Aufbau der Playbooks<br />
einführen, geht es weiter zu komplexeren<br />
Anwendungen. Bei<br />
Schleifen und Bedingungen<br />
kommen Tricks und Design<br />
Patterns auch für größere<br />
Umgebungen zur Sprache. Das<br />
fünfte Kapitel geht abschließend<br />
auf die Entwicklung und<br />
Verwendung eigener Ansible-<br />
Module ein.<br />
Dem Buch gelingt es, mit anschaulichen<br />
Beispielen auf<br />
knapp 100 Seiten einen<br />
Überblick über die Möglichkeiten<br />
von Ansible zu<br />
geben. Die Möglichkeit,<br />
trotz geringen Umfangs<br />
auch speziellere Themen<br />
anzusprechen, verdankt<br />
es dem ebenfalls auf Übersichtlichkeit<br />
getrimmten<br />
Aufbau von Ansible.<br />
Akronymisch<br />
Wegen der niedrigen Auflagen sind<br />
viele Verlage dazu übergangen, ihre<br />
IT-Fachbücher nur noch „On Demand“<br />
zu drucken. So verhält es sich auch<br />
mit der neuen Auflage des Klassikers<br />
„SNMPv3, SNMPv2, SNMP and RMON 1<br />
and 2“ von William Stallings, das inhaltlich<br />
der dritten Auflage der Hardcover-<br />
Ausgabe entspricht.<br />
Der Inhalt ist mit dem Titel detailliert<br />
beschrieben, auch wenn der Abhandlung<br />
der Standards noch eine Mini-<br />
Einführung in Netzwerk-Monitoring<br />
vor ausgeht. Stallings verortet SNMP<br />
(Simple Network Management Protocol)<br />
zunächst im Kontext von TCP/IP. Im<br />
Detail geht er auf Funktion und Aufbau<br />
von MIBs sowie das SNMP-Protokoll<br />
ein. Dann diskutiert er die Motivation<br />
für die Einführung von RMON, bevor er<br />
im Detail die Spezifikation durchgeht.<br />
Auch bei den Erweiterungen SNMPv2/3<br />
und RMON 2 beschränkt sich der Autor<br />
darauf, die Spezifikation der Protokolle<br />
zu kommentieren. Konkrete Tipps<br />
zum praktischen Einsatz gibt er dabei<br />
nicht. Im Anhang des Buchs findet sich<br />
noch eine kurze Erläuterung des TCP/<br />
IP-Protokolls und der abstrakten Syntaxnotation<br />
ASN.1.<br />
Wer eine Anleitung zum praktischen<br />
Einsatz von SNMP und RMON<br />
sucht, wird von dem Buch enttäuscht<br />
sein. Es wird seinem<br />
Anspruch, unter anderem auch<br />
ein „definitive guide“ zu SNMP<br />
für „network administrators“<br />
zu sein, nicht gerecht – es sei<br />
denn der Netzwerk-Administrator<br />
möchte die Protokolle<br />
über den praktischen Einsatz<br />
hinaus im Detail verstehen. Eher kann<br />
Stallings’ Buch als Referenz für denjenigen<br />
dienen, der SNMP- oder RMON-<br />
Software implementieren und etwas<br />
mehr Informationen haben möchte, als<br />
in den RFCs enthalten ist. n<br />
n SNMPv3<br />
William Stallings<br />
SNMPv3, SNMPv2, SNMP and RMON 1<br />
and 2<br />
Addison Wesley, 2013<br />
640 Seiten<br />
57 Euro<br />
ISBN-13: 978-0321952028<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
10<br />
Login<br />
News<br />
Neue Software und Produkte<br />
Branchen-News<br />
BSI: 16 Millionen Online-Accounts gehackt<br />
Bei der Analyse von Bot-Netzen wurden laut des Bundesamts für Sicherheit<br />
in der Informationstechnik (BSI) insgesamt 16 Millionen Online-Identitäten<br />
entdeckt. Das BSI besitzt nun eine Liste dieser aus E-Mail-Adresse und Passwort<br />
bestehenden Accounts, die als Zugangsdaten für Mail-Konten, Online-<br />
Shops und andere Internetdienste dienen.<br />
Im Rahmen der gesetzlichen Warnpflicht bietet das BSI unter der Adresse<br />
[1] ein Online-Tool an, mit dem sich überprüfen lässt, ob sich die eigene<br />
Adres se unter den gehackten Accounts befindet. Nachdem man bestätigt<br />
hat, dass man der Besitzer der Adresse ist, bekommt man eine E-Mail vom<br />
BSI, die mit einem Code die Echtheit der Mail sicherstellt. Ist die Adresse<br />
nicht in der Liste vertreten, passiert nichts. Das BSI speichert die eingegebenen<br />
Adressen zur Verarbeitung zwischen, will sie aber nach der Prüfung<br />
wieder löschen.<br />
15 Millionen für Docker<br />
Die Firma hinter der Linux-Virtualisierungstechnologie<br />
Docker erhält von<br />
verschiedenen Geldgebern zusammen<br />
15 Millionen US-Dollar. Insgesamt wurden<br />
damit bereits 26 Millionen US-Dollar<br />
in die ursprünglich unter dem Namen<br />
dotCloud gegründete Firma investiert.<br />
Jetzt konzentriert sie sich unter dem Namen<br />
Docker auf die Entwicklung der unter<br />
einer Open-Source-Lizenz stehenden<br />
Virtualisierungstechnologie, die auf den<br />
Linux-Containern LXC beruhen.<br />
Im Vergleich zu Hypervisoren wie VMware<br />
oder KVM erlaubt LXC die vergleichsweise<br />
geringe Ressourcen erfordernde Virtualisierung<br />
einzelner Anwendungen. Docker<br />
stellt eine Infrastruktur bereit, die die<br />
Installation und Verwaltung von solchen<br />
Containern stark vereinfacht.<br />
Innerhalb kürzester Zeit hat Docker einen<br />
recht hohen Bekanntheits- und Beliebtheitsgrad<br />
erlangt und auch schnell prominente<br />
Helfer in der Open-Source- und<br />
Business-Welt gefunden. So hat Red Hat<br />
ein Backend für Docker geschrieben,<br />
das dessen Nutzung auch auf Linux-<br />
Distributionen erlaubt, die nicht über das<br />
Overlay-Dateisystem AuFS verfügen, das<br />
Docker bis dahin voraussetzte.<br />
Kühlschrank im Bot-Netz?<br />
Das Security-Unternehmen Proofpoint hat festgestellt, dass bei einer aktuellen Spamund<br />
Phishing-Attacke knapp 15 Prozent des Traffic nicht von PCs, Laptops und konventionellen<br />
Mobilgeräten stammt, sondern von gehackten Routern, Multimedia-Centern,<br />
Fernsehern und „mindestens einem Kühlschrank“. Dabei handle es sich möglicherweise<br />
um den ersten dokumentierten Angriff mit Beteiligung des Internet of Things, wie die<br />
zunehmende Vernetzung von Kleingeräten bezeichnet wird. Insgesamt hat Proofpoint<br />
im Rahmen des Angriffs 750 000 E-Mails registriert, von denen 100 000 nicht von konventionellen<br />
Rechnern stammen. Der Angriff ereignete sich im Zeitraum vom 23. Dezember<br />
2013 bis zum 6. Januar 2014. Dabei wurden von jeder einzelnen IP-Adresse nicht mehr<br />
als zehn Schad-E-Mails verschickt.<br />
„Bot-Netze sind schon ein großes Sicherheitsproblem,<br />
und das Auftreten von Thingbots macht<br />
die Sache noch schlimmer“, so David Knight, der<br />
General Manager von Proofpoints Abteilung für<br />
Informationssicherheit. „Viele dieser Geräte sind<br />
nur schlecht abgesichert und ihre Besitzer haben<br />
praktisch keine Möglichkeit, festzustellen, ob<br />
sich Malware darauf eingenistet hat, geschweige<br />
denn, sie zu entfernen.“<br />
Ob sich hinter dem von Proofpoint identifizierten<br />
Gerät allerdings wirklich ein Kühlschrank<br />
befindet, ist fraglich, denn konkrete Informationen<br />
dazu liefert die Firma nicht. Man sei auf<br />
einen Log in-Prompt „Welcome to your Fridge“<br />
gestoßen, was kaum der Realität eines Benutzer-<br />
Interfaces der wenigen auf dem Markt verfügbaren<br />
Geräte entsprechen dürfte. Außerdem ist die<br />
Frage offen, warum der angebliche Kühlschrank<br />
überhaupt übers Internet erreichbar ist. Oft ist es<br />
auch nur ein Scherz, ein Unix-System mit einem<br />
Fake-Prompt wie dem obigen auszustatten.<br />
Guilherme Martins, 123RF<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Login<br />
News<br />
11<br />
Linux 3.13 löst Iptables ab<br />
Mit Version 3.13 ist eine neue Version des Linux-Kernels erschienen.<br />
Darin löst das Tool Nftables das alte Firewall-Konfigurationswerkzeug<br />
Iptables ab. Das neue Framework bleibt vorerst<br />
mit Iptables abwärtskompatibel, das Iptables-Nftables-Werkzeugset<br />
konvertiert Iptables-Regeln direkt in Nftables-Bytecode.<br />
Es unterstützt sogar bislang von Iptables nicht unterstützte Features<br />
wie Benachrichtigungen bei Änderungen an der Firewall,<br />
inkrementelle Updates von Firewall-Regeln und das Ein- und<br />
Ausschalten einzelner Chains pro Tabelle.<br />
Neben Nftables erhöht Linux 3.13 die Lese- und Schreibgeschwindigkeit<br />
auf Speichergeräten im Hinblick auf SSD-Platten.<br />
Ein neues Design des Block-Device-Zugriffs basiert auf zwei<br />
separaten Warteschlangen für Lese- und Schreibvorgänge: Die<br />
erste nimmt pro CPU Zugriffsanfragen entgegen und gibt diese<br />
an eine eigene Warteschlange der Speicher-Hardware weiter.<br />
Diese Methode ermöglicht statt der bisher<br />
höchstens 800 000 Schreib- und Lesezugriffe<br />
pro Sekunde mehrere Millionen.<br />
Weiterhin spart die neue Ausgabe des<br />
Betriebssystem-Kernels mit der Power-Management-Unterstützung<br />
bei<br />
vielen AMD-Radeon-Grafikkarten<br />
Strom und erzielt damit auch<br />
bessere Performance durch die<br />
Möglichkeit, die Taktfrequenz<br />
umzuschalten.<br />
Weitere neue Features<br />
umfassen eine Schnittstelle<br />
für Secure Element,<br />
über das künftig Anwendungen<br />
Bezahlungen per<br />
NFC (Near Field Communication)<br />
abwickeln können, Performance-Verbesserungen bei<br />
NUMA-Zugriffen (Non-uniform Memory Access), SquashFS und<br />
weiteren Komponenten.<br />
FreeBSD 10.0 fertiggestellt<br />
Einige Wochen später als geplant haben die FreeBSD-Entwickler<br />
das neueste Release ihres Betriebssystems veröffentlicht [2].<br />
Anwender kommen in den Genuss einiger Neuerungen wie dem<br />
Compiler LLVM/Clang, der nun standardmäßig verwendet wird – der<br />
Gnu-Compiler GCC gehört nun nicht mehr zum Basissystem. Neu<br />
geschrieben wurden der iSCSI-Stack und das CARP-Subsystem, das<br />
redundante IP-Adressen für hochverfügbare Setups bereitstellt.<br />
Auch das ZFS-Dateisystem wurde verbessert. Es unterstützt nun für<br />
SSDs das TRIM-Kommando, das hilft, einen Performance-Abfall der<br />
Flash-Speicher bei längerer Nutzung zu verhindern. Zur Komprimierung<br />
von Daten beherrscht ZFS jetzt auch den LZ4-Algorithmus.<br />
Ein Algorithmus, der das erneute Berechnen von Check summen<br />
vermeidet und damit potenziell die Performance des Dateisystems<br />
verbessert, wurde vom Solaris-Fork Illumos übernommen.<br />
Im Bereich der Virtualisierung wartet FreeBSD mit einem von Grund<br />
auf neu entwickelten Typ-2-Hypervisor namens Beehyve auf. Für<br />
die Paravirtualisierung von I/O-Devices unterstützt Beehyve die von<br />
Linux bekannte VirtIO-Schnittstelle. Beehyve setzt einen Prozessor<br />
mit den Features VT und EPT voraus, über die moderne Intel- und<br />
AMD-Prozessoren verfügen. Jenseits der Virtualisierung bietet das<br />
neue FreeBSD-Release aber umfangreichen Support für ARM-Prozessoren<br />
und unterstützt beispielsweise auch den Raspberry Pi.<br />
Anzeige<br />
SDN: Oracle kauft Corente<br />
Wie die Firma Oracle bekanntgibt, wird sie den SDN-Anbieter<br />
(Software Defined Networking) Corente übernehmen. Damit<br />
will Oracle sein Cloud-Angebot durch WAN-Virtualisierung ergänzen,<br />
die Corente anbietet. Kunden sollen damit sicher auf<br />
Anwendungen zugreifen können, die in der Cloud zur Verfügung<br />
stehen. In den letzten Jahren hat Oracle mit Xsigo und Acme<br />
Packets bereits andere Anbieter von Netzwerk-Virtualisierungstechnologie<br />
übernommen.<br />
Software Defined Networking ist der kommende Trend, bei dem<br />
traditionelle Anbieter von Virtualisierungssoftware in Konkurrenz<br />
zu Herstellern von Netzwerk-Hardware wie Cisco und Juniper<br />
treten, die ihrerseits ebenfalls SDN-Technologien auf den<br />
Markt bringen oder einkaufen. Die Linux Foundation versucht<br />
unterdessen, mit dem OpenDaylight-Projekt ein Konsortium<br />
für die Standardisierung von Software Defined Networking zu<br />
etablieren.<br />
www.admin-magazin.de
12<br />
Login<br />
News<br />
Red Hat integriert freie Linux-Distribution CentOS<br />
Das Community-Projekt CentOS entwickelt seit zehn Jahren<br />
eine freie Version der Enterprise-Distribution Red Hat Enterprise<br />
Linux (RHEL). Die CentOS-Entwickler verwenden die<br />
dem Betriebssystem zugrunde liegenden freien Quellen und<br />
veröffentlichen meist wenige Tage bis Wochen nach Erscheinen<br />
einer neuen RHEL-Version ein freies Pendant. Red Hat<br />
Enterprise Linux ist hingegen nur mit einem kostenpflichtigen<br />
Support-Vertrag erhältlich.<br />
Wie Red Hat jetzt bekannt gegeben hat, integriert die Firma<br />
CentOS nun ins eigene Portfolio und will neue Technologien<br />
und Software-Versionen direkt in CentOS einbringen. Damit<br />
wird die Linux-Strategie der Firma zumindest vorerst dreigleisig:<br />
Red Hat Enterprise Linux richtet sich weiterhin mit<br />
langjährigem Support, garantierten Sicherheitsupdates und<br />
Fehlerkorrekturen, Rechtsschutz sowie Schulungsangeboten<br />
an Firmenkunden. CentOS soll der Community vor allem<br />
neue Cloud-, Storage-, Netzwerk- und Infrastrukturtechnologien<br />
nahebringen. Das ebenfalls freie Fedora soll daneben<br />
neue Technologien auf der ganzen Breite vom Kernel bis zum<br />
Desktop integrieren.<br />
Bislang nutzte Red Hat die freie Linux-Distribution Fedora als<br />
eine Art Experimentierfeld, in der die breite Entwickler- und<br />
Benutzer-Community neue Technologien kostenlos ausprobierte<br />
und durch ihr Feedback und eigene Patches verbesserte.<br />
Red Hat übernimmt diese daraufhin gegebenenfalls in<br />
RHEL. Wie Fedora und CentOS sich künftig unterscheiden,<br />
bleibt abzuwarten.<br />
Die Integration von CentOS ins Red-Hat-Ökosystem kann<br />
auch als Scheitern der bisherigen Strategie interpretiert<br />
werden, bei der Red Hat CentOS anscheinend eher als Dorn<br />
im Auge betrachtet hatte. So<br />
veröffentlichte die Firma ihre<br />
Kernel-Patches seit 2011 nicht<br />
mehr einzeln, sondern nur als<br />
impliziten Teil des Quellcodes. Die<br />
Umstellung zielte zwar vor allem auf ein Konkurrenzprodukt<br />
von Oracle auf Basis des Red-Hat-Codes ab, machte aber<br />
auch den CentOS-Entwicklern das Leben schwerer. CentOS-<br />
Entwickler berichteten in der Vergangenheit außerdem, dass<br />
Red Hat ihre Konten für die Plattform Red Hat Network (RHN)<br />
sperrte.<br />
CentOS-Hauptentwickler Karanbir Singh und andere Mitglieder<br />
des Entwicklungsteams arbeiten nach Medienberichten<br />
nun direkt für Red Hat. Singhs Pläne für die nahe Zukunft<br />
von CentOS sehen vor, den Entwicklungsprozess offener<br />
zu gestalten, etwa durch die Einrichtung eines öffentlichen<br />
Git-Repositories mit dem gesamten CentOS-Quellcode, die<br />
Möglichkeit, an themenspezifischen Arbeitsgruppen (Special<br />
Interest Groups) mitzuarbeiten und solche ins Leben zu rufen,<br />
die Erweiterung der Zusatzsoftware-Repositories, einen<br />
konkreten Release-Zeitplan sowie wöchentliche, öffentlich<br />
zugängliche Treffen des CentOS-Boards. Bisher scheiterte die<br />
öffentliche Entwicklung an den Rechten der Marke „Red Hat“.<br />
Red Hat erhofft sich von dem Schritt eine Festigung der Red-<br />
Hat-Community. Red Hats Technologiechef Brian Stevens<br />
sieht in der Integration von CentOS die Möglichkeit, wichtige<br />
neue Projekte wie OpenStack und Big-Data-Anwendungen<br />
einem größeren Publikum nahezubringen und Red Hat damit<br />
die Möglichkeit zu geben, solche Technologien als <strong>Erste</strong>r zu<br />
implementieren.<br />
Neuauflage von Linksys-Router WRT54G<br />
Die Firma Linksys hat einen Nachfolger<br />
des beliebten WLAN-Routers<br />
WRT54G vorgestellt. Das neue Modell<br />
WRT1900AC ähnelt äußerlich seinem<br />
Vorgänger, wurde aber im Design<br />
modernisiert. Das Gerät besitzt vier<br />
abnehmbare Antennen und einen<br />
eSATA-Port sowie Anschlüsse für USB<br />
2.0 und 3.0. Netzwerkseitig bringt der<br />
neue Router Gigabit-Ports für LAN und<br />
den Internet-Uplink mit. Auch beim<br />
WLAN unterstützt der WRT1900AC mit<br />
dem Standard IEEE 802.11ac Gigabit-<br />
Bandbreiten.<br />
Nach eigener Aussage trägt Linksys<br />
mit der Neuauflage des Routers auch<br />
den vielfachen Wünschen von Kunden<br />
Rechnung, die gerne den alten Router<br />
in einer modernisierten Ausgabe gesehen<br />
hätten. Beliebt war er unter anderem,<br />
weil er sich gut zur Entwicklung<br />
von Firmware auf Linux-Basis eignete.<br />
In dieser Hinsicht gibt sich Linksys offen<br />
und unterstützt Open-Source-Projekte<br />
wie DD-WRT, OpenWRT und Tomato,<br />
deren Custom-Firmware zur Beliebtheit<br />
des Vorgängers beigetragen hatten.<br />
Im Frühjar 2014 soll es ein erstes<br />
Firmware-Image von OpenWRT für den<br />
neuen Router geben. Kosten soll das<br />
Gerät etwa 300 US-Dollar.<br />
www.admin-magazin.de
IBM-Hauptspeicherlösung für Big Data<br />
IBM hat die sechste Generation der Enterprise-X-Architektur für Intel-x86-Prozessor-basierte<br />
IBM-System-x- und PureSystems-Server angekündigt. Sie bietet<br />
wesentliche Verbesserungen in Leistung und Wirtschaftlichkeit für Analytik- und<br />
Cloud-Aufgaben. Integrierter eXFlash-Memory-Channel-Speicher – eine branchenweite<br />
Neuheit – bietet bis zu 12,8 TByte schnellen Flash-Speicher nahe am Prozessor.<br />
Das erhöht die Anwendungsleistung durch die kürzeste derzeit verfügbare<br />
Systemschreib latenzzeit, die besonders für Analytik-Anwendungen essenziell<br />
ist. Besonders Datenbankoperationen profitieren und die Speicherkosten sinken<br />
durch die Reduzierung oder sogar Abschaffung von externen SAN/NAS-Speichereinheiten.<br />
Mit einem modularen, skalierbarem Design, das mehrere Generationen an CPUs<br />
unterstützen soll, fallen die Anschaffungskosten im Vergleich zu Konkurrenzprodukten<br />
bis zu 28 Prozent geringer aus. Das autonome, selbstheilende CPU- und<br />
Speichersystem maximiert außerdem die Betriebszeit von Anwendungen, indem<br />
es potenzielle Ausfälle identifiziert und vorher Gegenmaßnahmen ergreift.<br />
Die Servermodelle mit der neuen Architektur umfassen derzeit das System x3850<br />
X6 mit vier Sockeln, das System x3950 X6 mit acht Sockeln und die skalierbaren<br />
IBM-Flex-System-x880-Rechenknoten. IBM kündigt ebenso den System x3650 M4<br />
BD-Storage Server an, einen Rack-Server mit zwei Sockeln, der bis zu 14 Laufwerke<br />
mit bis zu 56 Terabyte an High-Density-Speicher unterstützt. Es bietet eine um bis<br />
zu 46 Prozent höhere Leistung als vorherige, vergleichbare IBM-System-x-Server<br />
und ist ideal geeignet für verteiltes Scale-out von Big-Data-Workloads.<br />
n Info<br />
Neueste nachrichten<br />
immer auf<br />
www.admin-magazin.de<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31688<br />
[1] BSI-Test: [https://www.sicherheitstest.bsi.de/]<br />
[2] Neues in FreeBSD 10:<br />
[https://wiki.freebsd.org/WhatsNew/FreeBSD10]
14<br />
Login<br />
Admin-Story<br />
Management mit OpenLMI<br />
Polyglotter<br />
Manager<br />
yadvigagr, 123RF<br />
Der versierte Linux-Admin verwaltet<br />
seine Systeme mittels<br />
Shell-Skripten. Für komplexe<br />
Aufgaben kommen andere<br />
Skript-Interpreter wie Python<br />
und Perl zum Einsatz. Mit Open-<br />
LMI steht nun eine neue Methode<br />
zur Verwaltung von Linux-Systemen<br />
zur Verfügung – sie basiert<br />
sogar auf einem offenen Industrie-Standard.<br />
Thorsten Scherf<br />
Die meisten Administratoren haben<br />
sich im Lauf der Zeit ihre eigenen Toolboxen<br />
aus Skripten zusammengestellt.<br />
Mit deren <strong>Hilfe</strong> und etwas SSH-Magie<br />
wird dann der ausufernde System-Zoo<br />
in Schach gehalten. Neue Software<br />
oder Funktionen erfordern es jedoch<br />
immer wieder, diese Toolbox anzupassen<br />
und auf den neuesten Stand<br />
zu bringen. Einsteiger haben es aber<br />
oft schwer, sich überhaupt auf neuen<br />
Systemen zurechtzufinden – gerade<br />
auch dann, wenn der eigene System-<br />
Zoo eine Vielzahl von unterschiedlichen<br />
Linux-Derivaten enthält. Eine<br />
einheitliche Methode und Schnittstelle<br />
zur Verwaltung der Systeme wäre also<br />
wünschenswert.<br />
OpenLMI stellt eine solche Schnittstelle<br />
zur Verfügung. Das Kürzel steht für<br />
Open Linux Management Infrastructure<br />
und basiert auf einem offenen Industrie-Standard.<br />
Struktur im Management<br />
Das Framework stellt eine Vielzahl von<br />
Low-Level-Funktionen zur Verfügung,<br />
mit denen sich unterschiedliche Aufgaben<br />
auf einem System ausführen<br />
lassen – lokal wie auch remote. Ob es<br />
sich hierbei um ein Bare-Metal- oder<br />
ein virtualisiertes System handelt,<br />
spielt erst mal keine Rolle. Zu den<br />
möglichen Aufgaben zählen dabei die<br />
Konfiguration des Betriebssystems und<br />
dessen Komponenten, die Verwaltung<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Login<br />
Admin-Story<br />
15<br />
zuständigen CIM-Provider weiterreicht.<br />
Die Provider decken dabei bestimmte<br />
Aufgabenbereiche ab. Beispielsweise<br />
existieren CIM-Provider für Netzwerk,<br />
Speicher, System-Services, Software,<br />
Monitoring, Benutzer und so weiter.<br />
Die XML-Dokumente eines Clients beschreiben<br />
die Art der Aufgabe, die von<br />
einem CIM-Provider – also auf dem zu<br />
verwaltenden System – durchzuführen<br />
ist. Die Dokumente werden anhand von<br />
Skripten oder Meta-Kommandos auf<br />
der Client-Seite erzeugt. Die Provider<br />
(auch CIM-Agenten genannt) auf einem<br />
System sind dann dafür verantwortlich,<br />
dass die gewünschten Aufgaben<br />
entsprechend durchgeführt werden.<br />
Die Agenten können dabei von einer<br />
Vielzahl von Herstellern zur Verfügung<br />
gestellt werden. [2] beschreibt die Anforderungen,<br />
die bei der Entwicklung<br />
eines CIM-Agenten zu beachten sind.<br />
Auf den Clients existieren eine Vielzahl<br />
unterschiedlicher Interfaces,<br />
die über den CIM-Object-Manager<br />
mit den Agenten auf den Servern<br />
kommunizieren können. Es gibt ein<br />
High-Level-Kommandozeilentool, eine<br />
programmierbare LMI-Shell sowie APIs<br />
für unterschiedliche Sprachen (Python,<br />
C/C++, Java), sodass Admins ihre LMI-<br />
Skripte in einer dieser Sprachen entwickeln<br />
können. Zur Kommunikation<br />
zwischen Client und Servern sollte auf<br />
den Servern der Port 5989 (»wbem‐htvon<br />
System-Services, das Management<br />
und Monitoring von Hardware und die<br />
Software-Verwaltung, um nur einige zu<br />
nennen.<br />
OpenLMI basiert dabei auf einem<br />
DMTF-Standard (Distributed Management<br />
Task Force) mit dem Namen<br />
WBEM (Web-Based Enterprise Management)<br />
(siehe [1]). Der Standard setzt<br />
sich aus verschiedenen Komponenten<br />
zusammen und beschreibt eine Reihe<br />
von Technologien zur einheitlichen Verwaltung<br />
von Computer-Systemen. Eine<br />
der verwendeten Komponenten nennt<br />
sich CIM (Common Information Model)<br />
und beschreibt in einer Art Schema<br />
typische Objekte, die auf einem Computer-System<br />
zum Einsatz kommen<br />
(Hardware, Software, Benutzer, Konfigurations-Subsysteme<br />
und so weiter).<br />
Überlicherweise wird der Begriff CIM<br />
jedoch nicht nur für das Schema eines<br />
Objekts verwendet, sondern bezieht<br />
sich auch auf die eingesetzten Tools<br />
und Technologien.<br />
Das OpenLMI-Framework setzt sich<br />
aus einem CIM-Client und vielen CIM-<br />
Servern zusammen. Der Client stellt in<br />
diesem Zusammenhang ein Management-System<br />
dar, das via XMLRPC mit<br />
einem CIM-Object-Manager (CIMOM)<br />
– manchmal auch Object-Broker genannt<br />
– mit dem CIM-Server spricht.<br />
Der Client versendet dabei CIM-/XML-<br />
Dokumente, die der CIMOM an die<br />
Abbildung 1: OpenLMI basiert auf einem Management-System<br />
(CIM-Client) und den zu verwaltenden<br />
Systemen (CIM-Server).<br />
tps«) geöffnet sein. Über diesen läuft<br />
die gesicherte Verbindung zwischen<br />
den Client-Interfaces und dem Object-<br />
Broker auf den Servern.<br />
Installation<br />
OpenLMI ist seit Fedora 18 in den<br />
Standard-Repositories der Distribution<br />
enthalten. Ich empfehle jedoch,
16<br />
Login<br />
Admin-Story<br />
n Info<br />
Fedora 20 und die darin enthaltenen<br />
Pakete einzusetzen. Im letzten Jahr<br />
gab es gravierende Änderungen an der<br />
OpenLMI-Software, sodass es unbedingt<br />
sinnvoll ist, die neueste Version<br />
einzusetzen. Für andere Distributionen<br />
steht unter [3] der OpenLMI-Quellcode<br />
zur Verfügung. Auf den zu verwaltenden<br />
Server-Systemen sind der OpenLMI-<br />
Object-Broker OpenPegasus sowie die<br />
gewünschten OpenLMI-Agenten zu<br />
installieren:<br />
yum install tog‐pegasus openlmi‐U<br />
providers openlmi‐storage openlmi‐U<br />
networking openlmi‐powermanagement U<br />
openlmi‐service openlmi‐account<br />
Das SBLIM-Projekt [4] stellt ebenfalls<br />
viele CIM-Provider zur Verfügung. Viele<br />
davon sind im Fedora-Software-Repository<br />
enthalten und lassen sich mittels<br />
Yum installieren.<br />
Da Server und Client über eine gesicherte<br />
Verbindung kommunizieren,<br />
wird im Rahmen der Installation des<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31691<br />
[1] Oliver Frommel, Standards fürs Netzwerk- und<br />
System-Management, <strong>ADMIN</strong> 01/2014:<br />
[http:// www. admin‐magazin. de/ Das‐Heft/<br />
2014/ 01/ Standards‐fuers‐Netzwerk‐und‐Syst<br />
em‐Management]<br />
[2] CIM-Provider-Howto: [https:// fedorahosted.<br />
org/ openlmi/ wiki/ CimProviderHowto]<br />
[3] OpenLMI-Quellcode:<br />
[http:// www. openlmi. org/ development]<br />
[4] SBLIM-CIM-Provider: [http:// sourceforge. net/<br />
apps/ mediawiki/ sblim]<br />
[5] OpenLMI-Skripte:<br />
[http:// pythonhosted. org/ openlmi‐scripts/]<br />
n Autor<br />
Thorsten Scherf arbeitet als Principal Consultant für<br />
Red Hat EMEA. Er ist oft als Vortragender auf Konferenzen<br />
anzutreffen. Wenn ihm neben der Arbeit und<br />
Familie noch Zeit bleibt, nimmt er gerne an Marathonläufen<br />
teil.<br />
OpenLMI-Object-Broker ein selbstsigniertes<br />
X.509-Zertifikat erzeugt. Hierfür<br />
ist das Skript »/usr/share/Pegasus/<br />
scripts/genOpenPegasusSSLCerts«<br />
verantwortlich. Das Zertifikat lässt<br />
sich nach der Installation des Servers<br />
mittels »openssl x509 ‐in /etc/Pegasus/<br />
server.pem ‐noout ‐text« ansehen. In<br />
produktiven Umgebungen ist es natürlich<br />
ratsam, ein Zertifikat von einer<br />
Certificate Authority (CA) ausstellen<br />
zu lassen. Hierfür kann beispielsweise<br />
FreeIPA zum Einsatz kommen. Auf<br />
dem Client- beziehungsweise Management-System<br />
ist dann entweder das<br />
selbst signierte oder CA-Zertifikat zur<br />
Verfügung zu stellen und entsprechend<br />
einzubinden:<br />
# scp server:/etc/Pegasus/server.pemU<br />
/etc/pki/ca‐trust/source/anchors/U<br />
remote‐ server.pem<br />
# update‐ca‐trust<br />
Fehlt dieser Schritt, so ist auf den<br />
Clients die Zertifikats-Verifizierung zu<br />
deaktivieren, wovon ich jedoch ausdrücklich<br />
abrate. Neben dem Zertifikat<br />
wurde als Teil der Installation ebenfalls<br />
ein Benutzer »pegasus« erzeugt. Dieser<br />
kann für authentifizierte Zugriffe auf<br />
den Server zum Einsatz kommen. Hierfür<br />
ist für den Benutzer jedoch mittels<br />
»passwd pegasus« zuerst ein Passwort<br />
zu setzen. Schließlich bleibt noch der<br />
Object Broker auf dem Server zu starten:<br />
# systemctl start tog‐pegasus.service<br />
Auf dem Client sollte für erste Tests die<br />
OpenLMI-Shell oder das Kommandozeilentool<br />
lmi zum Einsatz kommen.<br />
Diese installiert man mittels:<br />
# yum install openlmi‐toolsU<br />
openlmi‐scripts<br />
Die OpenLMI-Shell basiert auf Python<br />
und kann sowohl interaktiv wie auch im<br />
Batch-Mode verwendet werden. Jede<br />
CIM-/XML-Anweisung wird über einen<br />
sicheren HTTPS-Kanal an den Object<br />
Broker auf den Servern gesendet und<br />
dort von den zuständigen CIM-Agenten<br />
verarbeitet. Um die Arbeit mit der<br />
Shell zu vereinfachen, wandelt diese<br />
einfach jedes OpenLMI-Objekt in ein<br />
Python-Objekt um. Wer etwas Python<br />
beherrscht, kann somit sehr schnell<br />
OpenLMI-Skripte schreiben. Eine Anleitung<br />
findet sich unter [5].<br />
Wer etwas schneller ans Ziel kommen<br />
möchte, greift auf das CLI-Tool »lmi«<br />
zurück. Dieses arbeitet mit Meta-Kommandos,<br />
die auf den OpenLMI-Client-<br />
Bibliotheken aufsetzen. Diese kann<br />
man ebenfalls aus dem Fedora-Repository<br />
heraus auf den Clients beziehungsweise<br />
dem Management-System installieren:<br />
»yum install openlmi-scripts-*«.<br />
Das folgende Beispiel zeigt, wie sich ein<br />
beliebiger systemd-Service auf einem<br />
CLI-Server mithilfe des Tools »lmi« von<br />
einem zentralen Management-System<br />
aus steuern lässt:<br />
# lmi ‐h fedora.virt.tuxgeek.de U<br />
service show httpd.service | grep Status<br />
Status=OK<br />
# lmi ‐h fedora.virt.tuxgeek.de U<br />
service stop httpd.service<br />
# lmi ‐h fedora.virt.tuxgeek.de serviceU<br />
show httpd.service | grep Status<br />
Status=Stopped<br />
Genauso einfach lassen sich auch die<br />
Software-Pakete eines Systems mittels<br />
lmi verwalten. Diesmal im interaktiven<br />
Modus:<br />
# lmi ‐h fedora.virt.tuxgeek.de<br />
lmi> sw install zsh<br />
lmi> sw list pkgs zsh<br />
NEVRA<br />
Summary<br />
zsh‐0:5.0.2‐6.fc20.x86_64 PowerfulU<br />
interactive shell<br />
Konfigurationsoptionen, wie beispielsweise<br />
der Benutzername und das Passwort<br />
zur Authentifizierung am Object<br />
Broker, liest das Tool aus der globalen<br />
Datei »/etc/openlmi/lmi.conf« aus. Wie<br />
üblich können Benutzer eine eigene<br />
»~/.lmirc« anlegen.<br />
Rund um OpenLMI ist mittlerweile eine<br />
aktive Community entstanden. Wer Gefallen<br />
an dem Management-Framework<br />
gefunden hat, findet unter [3] Hinweise<br />
dazu, wie man sich an der Weiterentwicklung<br />
beteiligen kann. (ofr) n<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
germina, 123RF<br />
Wie organisiert Spanning Tree ein Ethernet-Netzwerk?<br />
Der Baum im Netzwerk<br />
Ethernet ist so beliebt, weil es einfach funktioniert und nicht viel kostet. Doch die Seite des Administrators sieht<br />
etwas komplizierter aus: Damit das Netzwerk rundläuft, muss er wichtige Entscheidungen treffen und den Spanning<br />
Tree planen. Hannes Kasparick<br />
Spanning Tree ist eins der grundlegenden<br />
Protokolle in Ethernet-<br />
Netzwerken. Es sorgt dafür, dass keine<br />
Netzwerkschleifen (Loops) entstehen,<br />
denn durch einen Broadcast-Sturm<br />
führen sie innerhalb kürzester Zeit zur<br />
Überlastung eines Netzwerksegments.<br />
Ethernet-Frames haben im Gegensatz<br />
zu IP-Paketen keine maximale Lebensdauer<br />
(Time to Live, TTL) und bewegen<br />
sich deshalb potenziell unendlich lange<br />
im Kreis.<br />
Das Spanning-Tree-Protokoll erreicht<br />
die Schleifenfreiheit, indem es bestimmte<br />
Verbindungen zwischen<br />
Switches deaktiviert. Abbildung 1 zeigt<br />
drei Beispiele (A, B, C) für Netzwerktopologien,<br />
die ohne die Blockade einiger<br />
Switchports durch Spanning Tree<br />
zum Zusammenbruch des Netzwerks<br />
führen würden.<br />
n Rollen und Zustände der Switchports<br />
In einem Spanning Tree nimmt jeder Port eines Switches eine von vier<br />
möglichen Rollen ein:<br />
n Root Port: aktiver Switchport, dessen Upstream in Richtung Root<br />
Bridge zeigt. Jeder Switch besitzt höchstens einen Root Port.<br />
n Designated Port: aktiver Port, der weg von der Root Bridge<br />
(Downstream) zeigt.<br />
n Alternate Port (nur bei Rapid Spanning Tree): Zeigt ebenfalls zur Root<br />
Bridge, ist aber nicht aktiv (»Blocked«).<br />
n Backup Port (nur bei Rapid Spanning Tree): Verbindung zu einem anderen<br />
Switch, der über einen anderen Switchport günstiger erreicht<br />
werden kann; ebenfalls nicht aktiv (»Blocked«).<br />
Neben den beschriebenen Rollen gibt es vier Zustände, die ein Port<br />
nacheinander einnimmt: »Blocking«, »Listening«, »Learning« und »Forwarding«.<br />
Im zusätzlichen Zustand »Disabled« verwirft ein Port sämtliche<br />
Pakete. Das gilt auch in den ersten drei genannten Zuständen; in<br />
ihnen empfängt und verarbeitet ein Port ausschließlich sogenannte<br />
BPDUs (Bridge Protocol Data Units), die Informationen über das Netz<br />
und den Spanning Tree transportieren. In den Zuständen »Listening«<br />
und »Learning« überträgt ein Port solche Pakete auch weiter, in letzterem<br />
lernt er dazu die Adressen anderer Netzwerkteilnehmer. Nur im<br />
»Forwarding«-Modus schließlich leitet ein Port darüber hinaus auch<br />
Datenpakete weiter.<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Netzwerk<br />
Spanning Tree<br />
19<br />
Variante A in Abbildung 1 bringt technisch<br />
keinen Vorteil und entsteht normalerweise<br />
nur aus Unachtsamkeit,<br />
meist über mehrere Switches hinweg.<br />
Die Varianten B und C hingegen sind<br />
oft gewünscht, um die Bandbreite<br />
zwischen zwei Switches zu vergrößern<br />
(Variante B), beziehungsweise um eine<br />
Redundanz für den Fall eines Kabelausfalls<br />
durch äußere Einflüsse – beispielsweise<br />
Bauarbeiten zwischen zwei<br />
Gebäuden – zu erreichen (Variante C).<br />
Die Blockade durch Spanning Tree in<br />
Variante B hebt die Bandbreitenbündelung<br />
zunächst auf.<br />
Die Switch-Hersteller haben verschiedene,<br />
teils zueinander inkompatible<br />
Lösungen entwickelt, etwa »Ether-<br />
Channel«, »PortChannel«, »virtual<br />
PortChannel« (Cisco) und »Trunk« (HP).<br />
Diese Technologien bündeln mehrere<br />
physische Ethernet-Verbindungen zu einer<br />
logischen (Variante D in Abbildung<br />
1). Der Spanning Tree nimmt diese<br />
logische Verbindung beispielsweise als<br />
eine 2- GBit-Verbindung statt als zwei<br />
separate 1-GBit-Verbindungen wahr<br />
und blockiert daher keine der beiden.<br />
Variante C lässt sich durch diese Technologien<br />
allerdings nicht optimieren.<br />
Hier empfiehlt sich der Einsatz einer<br />
anderen physischen Verkabelung, die<br />
die Dreiecksverbindung zwischen den<br />
Switches ersetzt.<br />
Für jedes VLAN, also ein logisches<br />
Netz werksegment, wird ein eigener<br />
Spanning Tree berechnet. Dieser Artikel<br />
beschränkt sich deshalb auf ein VLAN.<br />
Das Spanning-Tree-Protokoll existiert<br />
heute hauptsächlich in den Ausprägungen<br />
»Rapid Spanning Tree« (RST) und<br />
»Rapid per VLAN Spanning Tree« oder<br />
»Multiple Spanning Tree« (MST), da die<br />
ursprüngliche Form des Spanning Trees<br />
zu hohen Konvergenzzeiten und damit<br />
in komplexen Topologien zu Ausfällen<br />
von 30 bis 50 Sekunden führt.<br />
Wahlen ohne Demokratie<br />
Die Berechnung des Spanning Trees erfolgt<br />
in drei wesentlichen Schritten:<br />
n Wahl der Root Bridge,<br />
n Wahl der Root Ports,<br />
n Wahl der Designated Ports.<br />
Es gibt verschiedene Rollen und Zustände<br />
(siehe Kasten „Rollen und<br />
A B C D<br />
Abbildung 1: Das Spanning-Tree-Protokoll verhindert Schleifen in Netzwerktopologien.<br />
Zustände“), die ein Switchport einnehmen<br />
kann. Die Variante Rapid Spanning<br />
Tree fasst »Disabled«, »Blocking« und<br />
»Listening« zu »Discarding« zusammen.<br />
Damit Spanning Tree die Gesamttopologie<br />
berechnen kann, wird zunächst<br />
die »Root Bridge« gewählt. Sie bildet<br />
den Referenzpunkt des gesamten<br />
Spanning Tree und berechnet die Pfade<br />
und Einstellungen des Baums. Die Wahl<br />
der Root Bridge erfolgt aufgrund der<br />
»Bridge-ID«, die sich aus drei Bestandteilen<br />
zusammensetzt:<br />
n Bridge Priority<br />
n System-ID-Extension<br />
n MAC-Adresse<br />
Campus<br />
Core<br />
Die Bridge Priority liegt zwischen 0 und<br />
61440 und ist in Schritten von 4096<br />
konfigurierbar. Die System-ID und die<br />
MAC-Adresse sind nicht frei wählbar;<br />
MAC-Adressänderungen sind zwar möglich,<br />
aber nicht empfohlen. Je höher<br />
der Wert der Bridge Priority liegt, desto<br />
weniger kommt der entsprechende<br />
Switch als Root Bridge in Frage. Ein<br />
Switch mit der Bridge Priority 0 übernimmt<br />
höchstwahrscheinlich die Root<br />
Bridge, es sei denn, ein weiterer Switch<br />
im Netz hat ebenfalls diesen Wert.<br />
Sollte mehr als ein Switch die gleiche<br />
minimale Bridge Priority besitzen,<br />
geben System-ID-Extension und MAC-<br />
DataCenter<br />
Core<br />
Layer 3 Grenze<br />
DataCenter<br />
Aggregation /<br />
Distribution<br />
DataCenter<br />
Access<br />
Abbildung 2: Die Root Bridge eines Netzwerks sollte in der Aggreations-/Distributionsebene Platz<br />
finden.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
20<br />
Netzwerk<br />
Spanning Tree<br />
Switch A<br />
Root Bridge<br />
Switch D<br />
Switch C<br />
Switch B<br />
Abbildung 3: Hat der neue Switch D eine niedrigere<br />
Bridge-Priority als Switch A…<br />
Switch A<br />
Switch D<br />
Root Bridge<br />
Switch C<br />
Switch B<br />
Abbildung 4: … ändert Spanning Tree die Netzwerktopologie.<br />
Switch 1 Switch 2<br />
BLK 19 DP<br />
RP<br />
BLK<br />
RP<br />
19 19<br />
19<br />
Adresse den Ausschlag bei der Wahl zur<br />
Root Bridge. Dabei gewinnt der Kandidat<br />
mit den niedrigsten Werten. <strong>Erste</strong>re<br />
entspricht der VLAN-Nummer.<br />
Bei den MAC-Adressen unterbieten<br />
ältere Switches oft ihre aktuellen Nachfolger,<br />
da viele Hersteller sie aufsteigend<br />
vergeben. Dadurch besteht die<br />
Gefahr, dass der älteste und potenziell<br />
schwächste Switch zur Root Bridge<br />
wird. Da Spanning-Tree-Berechnungen<br />
in großen Netzen aufwendig ausfallen,<br />
sollte hingegen ein möglichst leistungsfähiger<br />
Switch die Rolle der Root Bridge<br />
übernehmen.<br />
Design-Guides der Hersteller empfehlen,<br />
die Root Bridge in der Aggregations-<br />
bzw. Distributionsebene zu platzieren,<br />
um kurze Konvergenzzeiten bei<br />
Ausfällen zu erreichen (Abbildung 2).<br />
Auf Cisco-Switches erfolgt die Konfiguration<br />
der Bridge Priority mittels<br />
»spanning‐tree vlan VLAN priority« oder<br />
alternativ mit dem Root-Bridge-Makro<br />
»spanning‐tree vlan VLAN root [primary<br />
| secondary]«. Es konfiguriert die Priorität<br />
automatisch anhand der aktuell<br />
im Netz vorhandenen Root Bridge,<br />
läuft aber nur einmalig beim Aufruf und<br />
nicht dauerhaft im Hintergrund.<br />
Putsch gegen die Root Bridge<br />
Der Austausch der Informationen über<br />
die Spanning-Tree-Topologie zwischen<br />
verschiedenen Switches erfolgt über<br />
sogenannte BPDUs (Bridge Protocol<br />
Data Unit). Grundsätzlich sendet und<br />
empfängt jeder Switchport BPDUs.<br />
Diese Eigenschaft bietet allerdings Angreifern<br />
die Möglichkeit, die Topologie<br />
auszulesen und mit gefälschten BPDUs<br />
zu verändern. Gegenmaßnahmen heißen<br />
BPDU-Guard und -Filter (siehe Kasten<br />
„BPDU-Guard und -Filter“).<br />
Auch nachdem die Root Bridge gewählt<br />
und der gesamte Spanning Tree aktiv<br />
ist, können weitere Switches dem<br />
Netzwerk beitreten, beispielsweise bei<br />
der Installation eines neuen Stockwerk-<br />
Switches. Hat eins der neuen Geräte<br />
eine niedrigere Bridge Priority, würde<br />
es dann zur neuen Root Bridge. Das<br />
zöge allerdings eine Änderung der gesamten<br />
Netzwerktopologie und damit<br />
möglicherweise suboptimale Pfade sowie<br />
Performance-Engpässe nach sich.<br />
Schutz gegen eine versehentliche oder<br />
auch böswillige Änderung der Root<br />
Bridge bietet der Root Guard [1].<br />
Abbildung 3 zeigt eine Ausgangslage,<br />
in der Switch D zum Netzwerk hinzukommt.<br />
Unterbietet dessen Bridge Priority<br />
aus einem der genannten Gründe<br />
die der bisherigen Root Bridge, ändert<br />
sich die Topologie daraufhin wie in Abbildung<br />
4.<br />
Um diese Umstellung zu verhindern,<br />
konfiguriert man den Root Guard auf<br />
dem in Richtung Switch D weisenden<br />
Port von Switch C. Das Feature deaktiviert<br />
den betreffenden Switchport,<br />
sobald er eine BPDU mit einer zu niedrigen<br />
Bridge Priority empfängt.<br />
Kosten, Kosten, Kosten<br />
Beim Betrieb des Netzwerks stehen<br />
neben der Zuweisung der Root Bridge<br />
weitere Berechnungen an. Bei der Wahl<br />
der Root Ports und der Designated<br />
Ports, spielen die Verbindungskosten<br />
eine wichtige Rolle. Die Spanning-Tree-<br />
Standardkosten für unterschiedliche<br />
Bandbreiten stellt Tabelle 1 dar. Die<br />
vordefinierten Werte führen allerdings<br />
dazu, dass eine 40- und eine<br />
100-GBit-Verbindung die gleichen<br />
Spanning-Tree-Kosten ergeben wie<br />
auch ein PortChannel aus zwei 10-GBit-<br />
DP DP<br />
12<br />
DP<br />
RP DP<br />
Switch 3 Switch 4<br />
Root Bridge<br />
Abbildung 5: Bei 100-MBit-Leitungen zwischen allen<br />
Ports ergeben sich für alle Wegkosten Werte von 19,<br />
außer für die gebündelten Leitungen zwischen den<br />
Switches 3 und 4.<br />
n Tabelle 1: Verbindungskosten<br />
Bandbreite<br />
Kosten<br />
10 MBit/s 100<br />
16 MBit/s 62<br />
100 MBit/s 19<br />
200 MBit/s 12<br />
622 MBit/s 6<br />
1 GBit/s 4<br />
10 GBit/s 2<br />
20+ GBit/s 1<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Netzwerk<br />
Spanning Tree<br />
21<br />
Verbindungen, bei dem sich die Kosten<br />
aus der Gesamtbandbreite aller zusammengefügten<br />
Verbindungen berechnet.<br />
Um in solchen Situationen detaillierter<br />
zu reagieren, sind die Spanning-Tree-<br />
Verbindungskosten falls nötig pro Port<br />
einzeln konfigurierbar.<br />
Abbildung 5 stellt eine Beispieltopologie<br />
aus vier 100-MBit-Switches<br />
dar, in der Switch 4 die Root Bridge<br />
übernimmt. Da alle Verbindungen eine<br />
Geschwindigkeit von 100 MBit pro Sekunde<br />
haben, belaufen sich die Kosten<br />
für jeden Port gemäß Tabelle 1 auf 19.<br />
Die einzige Ausnahme bildet der Port-<br />
Channel zwischen Switch 3 und Switch<br />
4, der in Summe 200 MBit pro Sekunde<br />
und damit einen Kostenwert von 12<br />
vorweist.<br />
Aus diesen Kosten ergibt sich, dass<br />
der Root Port (in der Abbildung abgekürzt<br />
als RP) von Switch 1 in Richtung<br />
Switch 3 zeigt. Der gegenüberliegende<br />
Switchport wird zum Designated Port<br />
(abgekürzt als DP), weil die Kosten auf<br />
diesem Weg nur 31 (19+12) betragen,<br />
auf dem Weg über Switch 2 jedoch 38<br />
(19+19). Gäbe es zwischen Switch 3 und<br />
Switch 4 keinen PortChannel, ergäben<br />
sich zwei gleich teure Wege von Switch<br />
1 zur Root Bridge (Switch 4). Dann<br />
würden zur Berechnung des Weges die<br />
Bridge-IDs herangezogen, wobei die<br />
niedrigere ID den Ausschlag gibt.<br />
Alle Switchports der Root Bridge<br />
(Switch 4) sind Designated Ports,<br />
ebenso wie alle Ports, die einem Root<br />
Port gegenüberliegen. Bei der Verbindung<br />
zwischen Switch 1 und Switch 2<br />
erfolgt die Bestimmung der Port-Rollen<br />
– die möglichen Optionen lauten hier<br />
Designated und Blocked – durch die<br />
Wegkosten zur Root Bridge. Bei Switch<br />
2 betragen sie 19, bei Switch 1 hingegen<br />
31. Somit werden die Ports zwischen<br />
Switch 1 und 2 zu Blocked beziehungsweise<br />
Designated Ports. Dies gilt analog<br />
auch für die Verbindung zwischen den<br />
Switches 2 und 3: Die Wegkosten von<br />
Switch 3 zur Root Bridge betragen 12,<br />
deshalb wird der Port Richtung Switch<br />
2 zum Designated Port.<br />
Aus der beschriebenen Spanning-Tree-<br />
Berechnung ergeben sich in Abbildung<br />
5 die Blockaden zwischen den Switches<br />
1 und 2 sowie zwischen 2 und 3. Die<br />
Kommunikation zwischen 1 und 2 erfolgt<br />
deshalb über den Umweg über die<br />
Switches 3 und 4.<br />
Die in Abbildung 5 gezeigte Topologie<br />
demonstriert, dass die Position der<br />
Root Bridge im Netzwerk eine wichtige<br />
Rolle spielt. Dies gilt auch für Spanning-Tree-Weiterentwicklungen,<br />
die die<br />
Zahl blockierter Switchports minimieren.<br />
Denn neben den optimalen Wegen<br />
gilt es auch die Notwendigkeit eventueller<br />
Spanning-Tree-Neuberechnungen<br />
bei Switch-Ausfällen zu bedenken,<br />
die für optimale Geschwindigkeit ein<br />
möglichst leistungsfähiger Switch ausführen<br />
sollte.<br />
Weitere Gefahren<br />
Scott Hogg, Technologiechef der Netzwerktechnikfirma<br />
GTRI, beschreibt in<br />
seinem Blog [2] weitere häufige Fehler<br />
im Zusammenhang mit Spanning-Tree-<br />
Konfigurationen. Einer davon betrifft<br />
nicht beachtete Größenbegrenzungen<br />
eines Spanning Trees, also der maximalen<br />
Anzahl hintereinandergeschalteter<br />
Switches. Im Idealfall verhindert eine<br />
sternförmige Verkabelung hinterein-<br />
FHRP passiv<br />
AGG1<br />
ACC1<br />
IP Core<br />
FHRP aktiv<br />
AGG2<br />
ACC2<br />
Layer 3<br />
Grenze<br />
Abbildung 6: Der ursprüngliche Spanning-Tree-<br />
Algorithmus führt in diesem Setup zu einem suboptimalen<br />
Pfad vom Server zum Gateway.<br />
AGG1<br />
IP Core<br />
AGG<br />
AGG2<br />
Layer 3<br />
Grenze<br />
n BPDU-Guard und ‐Filter<br />
n BPDU-Guard deaktiviert einen Switchport, sobald er ein BPDU-Paket empfängt. Die<br />
Ursache kann in einem Angriff oder im unerlaubten Anschließen eines Switches liegen.<br />
Optional aktiviert der BPDU-Guard einen abgeschalteten Switchport mit einem<br />
Timer nach Ablauf einer gewissen Zeit automatisch wieder. BPDU-Guard sollte auf<br />
jedem Access-Switchport konfiguriert sein. Das geschieht im Interface mit »spanning‐tree<br />
bpduguard enable« oder global mit »spanning‐tree portfast bpduguard<br />
default«.<br />
n BPDU-Filter verhindert, dass ein Switch BPDUs über einen Switchport verschickt.<br />
Auch dieses Feature sollte auf jedem Access-Port aktiviert sein mit »spanning‐tree<br />
bpdu‐filter enable« im Interface oder global mit »spanning‐tree portfast bpdufilter<br />
default«.<br />
ACC1<br />
ACC<br />
ACC2<br />
Abbildung 7: Multichassis-Etherchannel fasst<br />
Switch es und Netzwerkverbindungen zu logischen<br />
Einheiten zusammen.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
22<br />
Netzwerk<br />
Spanning Tree<br />
RACK 1<br />
VLAN 100<br />
VMotion<br />
VM<br />
RACK 2<br />
VLAN 100<br />
IP Core<br />
RACK 3<br />
VLAN 103<br />
RACK 4<br />
VLAN 104<br />
Abbildung 8: Virtuelle Umgebungen schaffen auch fürs Netzwerk neue Herausforderungen.<br />
RACK 1<br />
VLAN 100<br />
VLAN 101<br />
VLAN 102<br />
VMotion<br />
VM<br />
IP Core<br />
RACK 2<br />
VLAN 100<br />
VLAN 101<br />
VLAN 102<br />
RACK 3<br />
VLAN 100<br />
VLAN 101<br />
VLAN 102<br />
Layer 3<br />
Grenze<br />
Abbildung 9: Der Trill-Standard und Ciscos FabricPath-Protokoll erlauben<br />
die Aggregation von Netzwerkverbindungen.<br />
Layer 3<br />
Grenze<br />
andergehängte Switches vollständig,<br />
aber dies ist beispielsweise bei einem<br />
Campus mit mehreren Gebäuden oft<br />
unmöglich.<br />
Eine weitere grundsätzliche Schwäche<br />
von Spanning Tree besteht darin, dass<br />
der Algorithmus beim Ausbleiben von<br />
BPDUs auf einem Port davon ausgeht,<br />
dass daran kein Switch angeschlossen<br />
ist. Doch dieser Schluss ist potenziell<br />
falsch und Fehlkonfigurationen oder<br />
Software-Fehler führen so möglicherweise<br />
dazu, dass es trotzdem zu Schleifen<br />
im Netzwerk kommt.<br />
Eine mögliche Ursache für ausbleibende<br />
BPDUs liegt in einem Hardware-<br />
Fehler. Bei Glasfaserverbindungen kann<br />
einer der beiden Kanäle Schaden nehmen,<br />
sodass die Verbindung zwar weiterhin<br />
BPDUs empfangen, aber nicht<br />
senden kann. Gegen diese Probleme im<br />
Layer 1 des Netzwerkschichtenmodells<br />
hilft die »Unidirectional Link Detection«<br />
(UDLD) [4]. Diese Methode ergänzt der<br />
»LoopGuard« [3], der Software-Bugs<br />
mit der gleichen Folge aufspürt.<br />
Dem Trugschluss, aus dem Spanning<br />
Tree aus dem Ausbleiben eingehender<br />
BPDUs folgert, es sei kein Switch angeschlossen, begegnet<br />
außerdem die »Bridge Assurance«. Diese Technik sollte deshalb<br />
auf allen Switchports, die eine Verbindung zu anderen<br />
Switches herstellen, aktiviert sein. Ausnahmen bilden verschiedene<br />
Ausprägungen von Multichassis-Etherchannels,<br />
beispielsweise ist Bridge Assurance nicht für Ciscos »virtual<br />
PortChannels« (vPC) empfohlen.<br />
Damals und heute<br />
In älteren Ethernet-Netzwerken ist eine Topologie wie in Abbildung<br />
6 denkbar. Darin hat Spanning Tree im Layer-2-Bereich<br />
die Hälfte aller Links deaktiviert und der Server (unten) nutzt<br />
nur eine von zwei Verbindungen. Die Rolle der Root Bridge<br />
übernimmt der Switch AGG1. Er bildet mit AGG2 die Grenze<br />
zwischen Layer 2 und Layer 3, die beiden heißen deshalb<br />
Layer-3-Switches, obwohl laut des OSI-Schichtenmodells ein<br />
Switch in Layer 2 arbeitet. Auf den beiden Layer-3-Switches<br />
läuft ein »First Hop Redundancy Protocol« (FHRP), entweder<br />
mit dem offenen Standard VRRP oder beispielsweise über<br />
Ciscos proprietäres Pendant HSRP. Das Protokoll ist allerdings<br />
nur auf AGG2 aktiv. Der »First Hop« ist das IP-Standard-Gateway<br />
des Servers.<br />
Das Problem des suboptimalen Weges der IP-Pakete vom<br />
Server zum Gateway (AGG2) in Abbildung 6 entsteht, weil aufgrund<br />
der durch Spanning Tree blockierten Verbindungen alle<br />
gerouteten Pakete den Umweg über AGG1 nehmen. Um das<br />
Problem zu beheben, müsste im Beispiel entweder AGG2 die<br />
Root Bridge übernehmen, oder das FHRP-Protokoll auf AGG1<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Netzwerk<br />
Spanning Tree<br />
23<br />
aktiviert werden. In einer komplexeren<br />
Topologie fallen die Auswirkungen einer<br />
solchen ungünstig platzierten Root<br />
Bridge wie in Abbildung 6 oft noch wesentlich<br />
gravierender aus.<br />
Non-Blocking-Architektur<br />
Aufgrund der hohen Port-Preise und<br />
Performance-Anforderungen bei Data-<br />
Center-Switches ist das Blockieren von<br />
Links durch Spanning Tree generell<br />
nicht wünschenswert. Deshalb bieten<br />
verschiedene Hersteller Abhilfe, um<br />
mehrere physische Verbindungen zwischen<br />
zwei Switches oder zwischen<br />
einem Switch und einem Server zu<br />
jeweils einer logischen Verbindung<br />
zusammenzufassen (Abbildung 7). Einige<br />
Lösungen ermöglichen sogar die<br />
Zusammenfassung von mehr als zwei<br />
Switches.<br />
Die Aggregations-Switches AGG1 und<br />
AGG2 verhalten sich in Abbildung 7<br />
nun wie ein großer Switch AGG und die<br />
beiden Access-Switches ACC1 und ACC2<br />
bilden den logischen Switch ACC. Dafür<br />
sorgt beispielsweise die »Multichassis<br />
Etherchannel«-Technik. Das Betriebssystem<br />
des Servers fasst wiederum<br />
die beiden Verbindungen zu ACC1 und<br />
ACC2 zu einer logischen Verbindung<br />
zusammen (»Netzwerk-Bonding«), sodass<br />
die volle Bandbreite zur Verfügung<br />
steht. Letzteres ermöglicht beispielsweise<br />
das »Link Aggregation Control<br />
Protocol« (LACP).<br />
Skalierbarkeit von Layer 2<br />
Die in Abbildung 7 dargestellte Topologie<br />
skaliert grundsätzlich gut, allerdings<br />
ergeben sich in großen Netzen<br />
einige neue Herausforderungen durch<br />
die Möglichkeiten der Virtualisierung.<br />
Abbildung 8 zeigt eine Beispieltopologie.<br />
Rack 1 und Rack 2 verwenden darin<br />
das gleiche VLAN, was die Migration<br />
einer virtuellen Maschine von Rack 1 in<br />
Rack 2 im laufenden Betrieb erlaubt,<br />
etwa mit VMotion von VMWare. Andererseits<br />
steht pro Rack häufig nur ein<br />
VLAN zur Verfügung, um auch bei einer<br />
großen Anzahl virtueller Maschinen die<br />
Broadcast-Domäne möglichst klein zu<br />
halten – wie bei den Racks 3 und 4.<br />
Neben der genannten Einschränkung<br />
bei der Mobilität virtueller Maschinen<br />
bildet bei Multichassis-Etherchannel<br />
die Beschränkung auf zwei Switch-<br />
Paare einen limitierenden Faktor. Dazu<br />
kommt die teils lange Konvergenzzeit<br />
von Spanning Tree, auch wenn sie mit<br />
Rapid Spanning Tree kürzer als im ursprünglichen<br />
Protokoll ausfällt. Sind<br />
mehrere hundert VLANs im Einsatz,<br />
dauert die Neuberechnung des Spanning<br />
Tree beim Ausfall der Root Bridge<br />
dennoch etwas.<br />
Um diesen Herausforderungen zu begegnen,<br />
erlauben einige proprietäre<br />
Protokolle Topologien wie in Abbildung<br />
9. Das Fundament dafür legt der offizielle<br />
IETF-Standard Trill (Transparent<br />
Interconnection of Lots of Links). Er<br />
ermöglicht »Equal Cost Multipathing«<br />
auch in Layer-2-Netzwerken, statt wie<br />
zuvor nur in Layer-3-Netzen.<br />
Auch das Cisco-eigene FabricPath<br />
basiert auf Trill, bietet aber erweiterte<br />
Möglichkeiten. So lernt bei FabricPath<br />
jeder Switch nur die MAC-Adressen, die<br />
er wirklich benötigt – in klassischen<br />
Layer-2-Netzen und bei Trill hingegen<br />
speichert jeder Switch alle MAC-Adressen.<br />
Die verkleinerten Adresstabellen<br />
führen bei FabricPath zu einer besseren<br />
Performance und vermeiden, dass<br />
Switches an die Speichergrenzen ihrer<br />
Hardware stoßen.<br />
Alle Verbindungen zwischen den einzelnen<br />
Switches in Abbildung 9 werden<br />
beim Einsatz von Cisco-Geräten im<br />
Fabric Path-Modus betrieben, aktiviert<br />
wird dieser durch den Befehl<br />
»switchport mode fabricpath«. Das<br />
»Fabric Short est Path First«-Protokoll<br />
bewerkstelligt das Layer-2-Routing<br />
und verwendet im Hintergrund wiederum<br />
IS-IS (»Inter mediate System to<br />
Intermediate System«). Der Einfluss<br />
von Spanning Tree endet an dieser<br />
Stelle – es handelt sich nicht mehr um<br />
Ethernet-Verbindungen, sondern um<br />
bloßes FabricPath.<br />
Die Verbindung zu klassischen Ethernet-Switches<br />
ist aber weiterhin möglich.<br />
An der Schnittstelle betritt Spanning<br />
Tree wieder die Bühne. Es betrachtet<br />
die gesamte FabricPath-Instanz wie<br />
einen einzigen großen Switch, wird<br />
dabei aber nicht durch den FabricPath<br />
hindurch propagiert. Alle FabricPath-<br />
Switches mit Verbindung zu einem<br />
n Info<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31639<br />
[1] Root Guard: [http:// www. cisco. com/ en/ US/<br />
tech/ tk389/ tk621/ technologies_tech_note-<br />
09186a00800ae96b. shtml]<br />
[2] Scott Hogg: „9 Common Spanning Tree Mistakes“<br />
(englisch): [http:// www. networkworld.<br />
com/ community/ blog/ 9‐common‐spanningtree‐mistakes]<br />
[3] Cisco LoopGuard: [http:// www. cisco. com/ en/<br />
US/ tech/ tk389/ tk621/ technologies_tech_note09186a0080094640.<br />
shtml]<br />
[4] Unidirectional Link Detection (UDLD):<br />
[http:// www. cisco. com/ en/ US/ tech/<br />
tk389/ tk621/ technologies_tech_note-<br />
09186a008009477b. shtml]<br />
[5] Link Aggregation Control Protocol:<br />
[http:// www. cisco. com/ en/ US/ docs/ ios/<br />
12_2sb/ feature/ guide/ gigeth. html]<br />
[6] Rapid Spanning Tree: [http:// www. cisco. com/<br />
en/ US/ tech/ tk389/ tk621/ technologies_<br />
white_paper09186a0080094cfa. shtml]<br />
[7] Routing Bridges (RBridges):<br />
[http:// tools. ietf. org/ html/ rfc6325]<br />
Ethernet-Switch erhalten die gleiche<br />
Bridge Priority, empfohlen ist der Wert<br />
8192.<br />
Der Anschluss eines Servers ans Fabric-<br />
Path-Netzwerk erfolgt über Ethernet.<br />
Die Switchports für Server sind entsprechend<br />
als Ethernet-Ports konfiguriert<br />
und nicht als FabricPath-Ports.<br />
VLANs, die über FabricPath transportiert<br />
werden sollen, konfiguriert der Befehl<br />
»mode fabricpath« als FabricPath-<br />
VLANs.<br />
Fazit<br />
Spanning Tree bildet einen grundlegenden<br />
Bestandteil eines Ethernet-Netzwerks.<br />
Seine Konfiguration erfordert<br />
deshalb große Sorgfalt, um auch im<br />
Fehlerfall die Stabilität des Netzwerks<br />
zu garantieren. (csc) n<br />
n Autor<br />
Hannes Kasparick ist Solution-Designer für Rechenzentrumsinfrastruktur<br />
und Virtualisierung. Im Urlaub<br />
erkundet er fremde Länder.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
Netzwerk<br />
24 OpenNMS und OCS<br />
Kheng Ho Toh, 123RF<br />
OCS-Informationen in die Überwachung mit OpenNMS integrieren<br />
Automatisch<br />
überwacht<br />
Wer große IT-Umgebungen effizient verwalten will, muss automatisieren. Das bedingt oft die Integration<br />
verschiedener Komponenten über Anwendungsgrenzen hinweg. Dieser Beitrag beschreibt, wie sich Informationen<br />
aus dem Hard- und Software-Inventar von OCS in das Netzwerk-Monitoring mit OpenNMS<br />
automatisch überführen lassen. Ronny Trommer, Markus Neumann<br />
Zunächst lohnt ein kurzer Blick auf die<br />
an dieser Lösung beteiligten Komponenten<br />
OCS und OpenNMS. Wofür sind<br />
sie gut und woher kommen sie?<br />
OCS<br />
Mit OCS Inventory NG (OCS) steht Netzwerk-<br />
und System-Administratoren eine<br />
Anwendung zur Hard- und Software-<br />
Inventarisierung zur Verfügung, die ein<br />
französisches Team unter der GPL 2 in<br />
Perl und PHP entwickelt. Hinter den<br />
Entwicklern steht das Unternehmen<br />
FactorFX, das kommerziellen Support<br />
und Training anbietet.<br />
OCS bedient sich bei der Inventarisierung<br />
eines Software-Agenten, der für<br />
Linux, Unix, Windows, OS X sowie für<br />
Android-Betriebssysteme verfügbar ist.<br />
Für Netzwerkkomponenten steht ein<br />
SNMP-basierter Discovery-Mechanismus<br />
zur Verfügung. Der Agent sammelt<br />
Informationen über:<br />
n logische Laufwerke und Partitionen,<br />
n detaillierte Informationen vom Betriebssystem,<br />
n installierte Programme,<br />
n angeschlossene Monitore.<br />
Die gesammelten Daten speichert eine<br />
MySQL-Datenbank. Die Systeme lassen<br />
sich im Inventar kategorisieren und<br />
damit organisieren. Ein SOAP-Web-<br />
Service macht die OCS-Inventardaten<br />
für andere Anwendungen verfügbar.<br />
OpenNMS<br />
Die Netzwerk-Management-Plattform<br />
OpenNMS entwickelt überwiegend<br />
ein amerikanisch-europäisches Team<br />
unter der GPL v3+ in Java. Im Projekt<br />
gibt es keine Unterscheidung zwischen<br />
freier Community- und proprietärer<br />
Enterprise-Version. Das Unternehmen<br />
The OpenNMS Group Inc. bietet kommerzielles<br />
Training, Support und Entwicklung<br />
an.<br />
Der Schwerpunkt der Anwendung<br />
liegt beim Fehler- und Performance-<br />
Monitoring. Als Plattform steht ein umfangreiches<br />
Provisionierungssystem zur<br />
Verfügung. Es kann unterschiedliche<br />
externe Datenquellen einbinden. Diese<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Netzwerk<br />
OpenNMS und OCS<br />
25<br />
Aufgaben übernimmt in OpenNMS der<br />
Prozess »provisiond«. So lassen sich<br />
beispielsweise DNS-Zonen und virtuelle<br />
Maschinen aus VMwares vCenter [1]<br />
automatisch in das Monitoring überführen<br />
und synchronisieren.<br />
Die Daten gelangen in einem XML-Format<br />
mittels HTTP zu OpenNMS. Die Zuweisung<br />
von Monitoren etwa für HTTP,<br />
SMTP, IMAP und JDBC ist auf mehreren<br />
Wegen möglich. Entweder erkennen<br />
Service-Detektoren diese Dienste automatisch<br />
oder sie lassen sich manuell<br />
zuweisen. Eine Mischung aus beiden<br />
Varianten ist ebenfalls möglich. Um<br />
Systeme automatisch zu kategorisieren<br />
oder um festzulegen, von welchen<br />
Netzwerkschnittstellen Leistungsdaten<br />
zu erfassen sind, lassen sich Richtlinien<br />
(Policies) nutzen. Damit ein Einsatz in<br />
größeren Umgebungen möglich ist,<br />
wurde OpenNMS auf einer ereignisbasierten<br />
Architektur aufgebaut.<br />
Verbindungen schaffen<br />
Wer OCS benutzt, hat umfangreiche<br />
Informationen von Server-Systemen<br />
in einem zentralen Inventar zur Verfügung,<br />
die auch für das Monitoring sehr<br />
nützlich wären. Modellbezeichnungen<br />
oder Seriennummern, die von den OCS-<br />
Agenten ermittelt wurden, können im<br />
Falle einer Störung in einer Benachrichtigung<br />
durch OpenNMS dem Administrator<br />
hilfreiche Informationen liefern.<br />
Häufig befinden sich in OCS allerdings<br />
auch Systeme, die für das Monitoring<br />
nicht relevant sind, beispielsweise Arbeitsstationen<br />
oder Systeme, die noch<br />
in der Entwicklungsumgebung stecken.<br />
Will man nun Systeme über OCS kontrolliert<br />
und automatisch in das Monitoring<br />
mit OpenNMS überführen, bietet<br />
sich ein Aufbau an, wie ihn Abbildung 1<br />
skizziert.<br />
Die Installation der OCS-Agenten sorgt<br />
dafür, dass das OCS die später zu<br />
überwachenden Systeme überhaupt<br />
registriert. Neue Server-Systeme befinden<br />
sich zur Vorbereitung in der<br />
speziellen Umgebung Development. Im<br />
vorliegenden Beispiel sind Systeme in<br />
dieser Umgebung für das Monitoring in<br />
OpenNMS uninteressant und werden<br />
nur im OCS-Inventar aufgeführt. Bevor<br />
Server-Systeme in den Produktivbe-<br />
trieb gehen, testet man<br />
sie in einer Staging-<br />
Umgebung. Falls dort<br />
irgendwelche Störungen<br />
auftreten, wird<br />
das Entwicklungsteam<br />
informiert. Meldungen<br />
über Störungen<br />
bei Systemen aus der<br />
Produktivumgebung<br />
sollen in das Network<br />
Operation Center gelangen.<br />
Das Monitoring<br />
interessiert sich lediglich<br />
für die Systeme in<br />
Staging und Produktion.<br />
Um zu zeigen, wie<br />
Monitoring-Profile<br />
für spezielle Server<br />
realisierbar sind, unterscheidet<br />
dieses Beispiel<br />
zwischen Mail-,<br />
Web- und Datenbank-<br />
Servern. Es geht davon<br />
aus, dass OpenNMS [2]<br />
in der stabilen Version<br />
1.12.3 und OCS in der<br />
Version 2.1RC1 [3] auf<br />
einem CentOS-6.5-<br />
Server installiert sind.<br />
Zusammenspiel der<br />
Komponenten<br />
Neben den beiden Anwendungen<br />
OpenNMS und OCS ist der OpenNMS<br />
Integration Server (OIS) nötig. Er extrahiert<br />
das OCS-Datenmodell, transformiert<br />
die Daten in das OpenNMS-Node-<br />
Datenmodell und lässt sich flexibel<br />
erweitern. Auf der einen Seite werden<br />
über die SOAP-Schnittstelle von OCS<br />
die Daten eingelesen und auf der anderen<br />
Seite die Daten mittels HTTP im<br />
Abbildung 1: Szenario für die Integration von OCS Inventory und<br />
OpenNMS.<br />
XML-Format für Provisiond in OpenNMS<br />
bereitgestellt. Bei der Transformation<br />
können bestimmte Regeln und Bedingungen<br />
ausgewertet und angewendet<br />
werden. Ein Standardverhalten ist im<br />
OIS bereits definiert, es bezieht sich<br />
auf die Netzwerkschnittstellen und<br />
Inventarinformationen. Damit sich der<br />
Ablauf wie in Abbildung 1 beschrieben<br />
realisieren lässt, muss der Admin drei<br />
selbstdefinierte Attribute in OCS anlegen<br />
und vom OIS auswerten lassen.<br />
In Abbildung 2 wird gezeigt, welche Attribute<br />
zur Steuerung des Monitoring in<br />
Abbildung 2: Überführen eines OCS-Computers in eine OpenNMS-Requisition.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
26<br />
Netzwerk<br />
OpenNMS und OCS<br />
n Listing 1: »global.properties«<br />
01 ### start an http server that provides access to<br />
requisition files<br />
02 driver = http<br />
03 host = 127.0.0.1<br />
04 port = 8000<br />
05 <br />
06 ### file run to create a requisition file in<br />
target<br />
07 #driver = file<br />
08 #target = /tmp/<br />
OpenNMS zum Zuge kommen. Die OCS-<br />
Attribute haben folgende Bedeutung:<br />
Monitored: Legt fest, ob das System für<br />
das Monitoring relevant ist.<br />
Environment: Legt fest, in welcher Umgebung<br />
sich das System befindet.<br />
Purpose: Legt fest, welche Aufgaben<br />
der Server durchführt.<br />
Für jeden Verwendungszweck wird eine<br />
OpenNMS-Datenquelle (Requisition)<br />
angelegt. Sie legt fest, welche spezifischen<br />
Service-Detektoren für einen<br />
Web-, Mail- und Datenbank-Server<br />
nötig sind. Zusätzlich bildet OpenNMS<br />
die Umgebung über Surveillance-<br />
Categories ab. Sie erlauben später<br />
die Zuordnung von unterschiedlichen<br />
n Listing 2: »requisition.properties«<br />
01 ### SOURCE ###<br />
02 ## connect to ocs and read computers<br />
03 source = ocs.computers<br />
04 <br />
05 ## OCS SOURCE PARAMETERS ##<br />
06 ocs.url = http://192.168.30.112<br />
07 ocs.username = SOAP_USER<br />
08 ocs.password = mypass<br />
09 ocs.checksum = 4099<br />
10 ocs.tags = Server<br />
11 ocs.accountinfo = MONITORED.Monitored PURPOSE.<br />
Webserver<br />
12 <br />
13 ### MAPPER ###<br />
14 ## Run the default mapper for computers<br />
15 mapper = default.ocs.computers<br />
16 <br />
17 ## Run a custom mapper script<br />
18 #mapper = script<br />
19 #script = mapper.groovy<br />
20 <br />
21 ### CATEGORIES ###<br />
22 categoryMap = categorymap.properties<br />
Benachrichtigungspfaden für das Netzwerk<br />
Operation Center oder das Entwicklungsteam.<br />
SOAP aktivieren<br />
Bei einer Installation von OCS sind zwei<br />
Schritte notwendig: Im ersten Schritt<br />
aktiviert man den SOAP-Web-Service<br />
und im zweiten Schritt legt man die benutzerdefinierten<br />
Attribute an. Um den<br />
SOAP-Web-Service zu aktivieren, ist die<br />
Perl-Umgebungsvariable in der Datei<br />
»/etc/httpd/conf.d/z‐ocsinventory‐server.conf«<br />
auf diese Weise zu bearbeiten:<br />
# === WEB SERVICE (SOAP) SETTINGS ===<br />
PerlSetEnv OCS_OPT_WEB_SERVICE_ENABLED 1<br />
Die Web-Service-Schnittstelle ist mit<br />
einer Basic-Authentication gegen eine<br />
Benutzerdatei konfiguriert. Um die<br />
Benutzerdatei zu erzeugen, führt der<br />
Admin das Kommando<br />
htpasswd ‐c /etc/httpd/APACHE_AUTH_U<br />
USER_FILE SOAP_USER<br />
aus. Im nächsten Schritt werden die<br />
benutzerdefinierten Attribute für die<br />
OCS-Computer angelegt.<br />
Benutzerdefinierte Attribute<br />
anlegen<br />
Die Beschreibung orientiert sich an<br />
Abbildung 3. Im Hauptmenü unter<br />
»Administrative Data« (1) werden die<br />
Attribute angelegt. Dazu muss in der<br />
Auswahlbox (2) »computers« markiert<br />
sein. Über die Registerkarte (3) »New<br />
data« werden die Felder mit den entsprechenden<br />
Datentypen hinzugefügt.<br />
Das Ergebnis sollte dann wie in (4) dargestellt<br />
aussehen.<br />
Um die erzeugten Felder mit Auswahlmöglichkeiten<br />
zu versehen, muss die<br />
Detailansicht eines bereits inventarisierten<br />
Computers aufgerufen werden.<br />
Nun lassen sich die angelegten Attribute<br />
wie in Abbildung 4 bearbeiten.<br />
Mit dem Plus-Symbol (1) wird der Dialog<br />
zum Hinzufügen eines Attributs<br />
angezeigt. Mit »New Data« (2) werden<br />
dann die Umgebungen »Development«,<br />
»Stage« und »Production« erzeugt. Für<br />
die Umgebungen sollte man die Attribute<br />
wie in der Tabelle (3) anlegen.<br />
Für jeden weiteren neuen Server lässt<br />
sich über diese drei Auswahlfelder steuern,<br />
wie sie in OpenNMS im Monitoring<br />
zu behandeln sind. Die Anpassungen<br />
in OCS sind abgeschlossen und der<br />
Admin kann sich der Konfiguration des<br />
OpenNMS Integration Server (OIS) und<br />
OpenNMS selbst widmen.<br />
Installation des Integration-<br />
Servers<br />
Die Installation des OIS kann über die<br />
OpenNMS-Yum- und -Debian-Repositories<br />
erfolgen. Der Java-Quellcode<br />
steht ebenfalls zur Verfügung und kann<br />
selbst übersetzt werden. Die Installationsvarianten<br />
sind im OpenNMS-Wiki<br />
zur OCS-Integration [4] beschrieben.<br />
In diesem Beispiel ist der OIS auf demselben<br />
Server wie OpenNMS installiert.<br />
Der Server lauscht auf der lokalen Adresse<br />
127.0.0.1 auf Port TCP/8000 und<br />
Abbildung 3: <strong>Erste</strong>llen der Attribute zur Steuerung des OpenNMS-Imports.<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Netzwerk<br />
OpenNMS und OCS<br />
27<br />
stellt die Daten der zu importierenden<br />
Server im XML-Format bereit. Den Aufbau<br />
der Konfigurationsdateien des OIS<br />
zeigt Abbildung 5.<br />
Die Verzeichnisse »ocs‐dbserver«,<br />
»ocs‐mailserver« und »ocs‐webserver«<br />
repräsentieren die Konfiguration für die<br />
OpenNMS-Requisition wie in Abbildung<br />
2 skizziert. Die grundlegende Funktion<br />
des OIS wird in der Datei »global.properties«<br />
wie in Listing 1 beschrieben.<br />
Der Parameter »driver« gibt an, dass<br />
ein HTTP-Output erwartet wird. Mit<br />
»host« und »port« lässt sich festlegen,<br />
auf welcher Netzwerkschnittstelle und<br />
welchem Port auf eingehende Verbindungen<br />
gelauscht werden soll.<br />
In dem Unterverzeichnis »ocs‐webserver«<br />
liegt eine Datei »requisition.properties«,<br />
die wie in Listing 2 aufgebaut<br />
ist. Hier wird festgelegt, von welchem<br />
OCS-Server die Daten geholt werden<br />
sollen. Der OCS-Server ist in unserem<br />
Beispiel unter 192.168.30.112 erreichbar<br />
und die SOAP-Schnittstelle kann<br />
mit dem Benutzer »SOAP_USER« und<br />
dem Passwort »mypass« angesprochen<br />
werden.<br />
Der Parameter »ocs.accountinfo« legt<br />
fest, dass für die Requisition »ocs‐webserver«<br />
lediglich OCS-Computer auszuwählen<br />
sind, die »Monitored« und als<br />
Abbildung 4: So lassen sich die Standardwerte für benutzerdefinierte<br />
Attribute festlegen.<br />
Verwendungszweck<br />
»Webserver« gesetzt<br />
haben. Für Mail- und<br />
Datenbank-Server wird<br />
ebenfalls ein entsprechendes<br />
Verzeichnis<br />
angelegt. In der jeweiligen<br />
»requisition.<br />
properties« wird der<br />
Parameter für »ocs.<br />
accountinfo« entsprechend<br />
des Verwendungszwecks<br />
»Mailserver«<br />
und »Datenbankserver«<br />
angepasst.<br />
Der Parameter »mapper«<br />
legt fest, welche<br />
Inventarinformationen<br />
von OCS in OpenNMS<br />
zu überführen sind.<br />
Falls das Standardverfahren<br />
nicht genügt,<br />
lässt sich ein eigenes Groovy-Skript<br />
angeben, dass die Daten zuordnet. In<br />
diesem Beispiel ist das unnötig.<br />
Der letzte Parameter »categoryMap«<br />
definiert eine Datei, in der die Umgebung<br />
(Environment) der OpenNMS-Surveillance-Category<br />
zugewiesen wird. Im<br />
vorliegenden Szenario wird definiert,<br />
dass die Umgebungen für »Production«<br />
und »Stage« auf gleichnamige Surveillance-Categories<br />
in OpenNMS zuzuweisen<br />
sind. Die Datei »categoryMap.<br />
properties« sieht für Mail-, Web- und<br />
Datenbank-Server identisch aus:<br />
ENVIRONMENT.Production=Production<br />
ENVIRONMENT.Stage=Stage<br />
Der OIS stellt unter der URL [http://<br />
localhost:8000/ ocs‐webserver] die Ser-<br />
n Listing 3: »provisiond‐configuration.xml«<br />
01 <br />
02 <br />
10 <br />
11 <br />
22 <br />
23 <br />
24 0 0 0 * * ? *<br />
25 <br />
26 <br />
27 <br />
28 <br />
29 0 0 0 * * ? *<br />
30 <br />
31 <br />
32 <br />
33 <br />
34 0 0 0 * * ? *<br />
35 <br />
36 <br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
28<br />
Netzwerk<br />
OpenNMS und OCS<br />
Abbildung 7: Auswahl von Service-Detektoren für Web-Server.<br />
Abbildung 5: Die Struktur der Konfigurationsdateien<br />
des OpenNMS-Integration-Servers.<br />
ver entsprechend der Konfiguration aus<br />
dem Verzeichnis »ocs‐webserver« zum<br />
Import zur Verfügung. Der Pfad »/ocswebserver«<br />
entspricht hier dem angelegten<br />
Verzeichnis im Dateisystem.<br />
Entsprechend erhält man unter den<br />
Pfaden »/ocs‐dbserver« sowie<br />
»/ocs‐mailserver« kategorisierte Mailund<br />
Datenbank-Server aus OCS. Die<br />
Konfiguration des Integration-Servers<br />
ist abgeschlossen und im nächsten<br />
Schritt wird OpenNMS für die automatische<br />
Synchronisation eingerichtet.<br />
Import mit Provisiond<br />
Um die Systeme in OpenNMS automatisch<br />
zu importieren und gegen OCS<br />
Abbildung 6: Vorbereiten der Requisition in OpenNMS für den automatischen Import.<br />
abzugleichen, wird der Daemon Provisiond<br />
von OpenNMS konfiguriert. Dazu<br />
ist im Verzeichnis »/opt/opennms/etc«<br />
die Datei »provisiond‐configuration.<br />
xml« wie in Listing 3 zu bearbeiten. Relevant<br />
sind hier die Abschnitte der Requisition-Definition<br />
(»requisition‐def«).<br />
Für Mail-, Web- und Datenbank-Server<br />
gibt es jeweils einen entsprechenden<br />
Eintrag. Er sorgt dafür, dass in<br />
OpenNMS jeweils eine Requisition für<br />
Web-, Mail- und Datenbank-Server entsteht.<br />
Jede Requisition konfiguriert das<br />
Verhalten für das Monitoring. Listing 3<br />
legt ebenfalls fest, dass täglich um null<br />
Uhr, Mail-, Web- und Datenbank-Server<br />
von einem lokalen OIS über Port 8000<br />
synchronisiert werden.<br />
Der nächste Schritt legt die drei Requisitions<br />
in der OpenNMS-Weboberfläche<br />
an. Dazu wählt der Administrator im<br />
Hauptmenü den Punkt »Admin« und<br />
anschließend »Manage Provisioning<br />
Requisitions« aus. Über das Eingabefeld<br />
legt er die drei Requisitions<br />
»ocs‐webserver«, »ocs‐mailserver« und<br />
»ocs‐dbserver« wie in Abbildung 6 an.<br />
Um ein Profil zu erzeugen, das bestimmt,<br />
wie die Systeme beim Import<br />
zu behandeln sind, konfiguriert man<br />
die Service-Detektoren (Detectors)<br />
für jede Requisition. Dazu gibt man<br />
unter »Requisition Edit« (1) an, welche<br />
Service-Detektoren anzuwenden sind.<br />
Nach dem Anlegen einer Requisition<br />
werden einfach alle zur Verfügung<br />
stehenden Service-Detektoren zugeordnet.<br />
Es ist daher sinnvoll, nur die<br />
Service-Detektoren auszuwählen, die<br />
für Mail-, Web- und Datenbank-Server<br />
passen. Abbildung 7 zeigt, dass für<br />
Web-Server nur die Service-Detektoren<br />
ICMP, HTTP, HTTPS und SNMP in der<br />
Konfiguration behalten und alle anderen<br />
gelöscht wurden. In der Gruppe der<br />
Mail- und Datenbank-Server werden<br />
relevante Service-Detektoren wie zum<br />
Beispiel SMTP, IMAP, POP3 und JDBC-<br />
Detektoren ausgewählt.<br />
Die Konfiguration hat zur Folge, dass<br />
OpenNMS beim Import aus OCS prüft,<br />
ob beispielsweise HTTP oder HTTPS<br />
über das Netzwerk von dem zu importierenden<br />
Server verfügbar sind. Falls<br />
ja, werden die Services automatisch<br />
zugeordnet und automatisch ins Monitoring<br />
überführt.<br />
Weiterhin können unter »Foreign<br />
Source Definition Edit« (2) für eine<br />
Requisition Richtlinien (Policies) festgelegt<br />
werden. Sie bestimmen, wie<br />
beim Import mit der Leistungsdatenerfassung<br />
umgegangen oder ob eine<br />
regelbasierte Kategorisierung der Systeme<br />
vorgenommen werden soll. Für<br />
das vorliegende Beispiel ist das jedoch<br />
nicht relevant. Weiterführende Informationen<br />
zu Richtlinien finden sich im<br />
OpenNMS-Wiki im Provisioning Users<br />
Guide [5].<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Netzwerk<br />
OpenNMS und OCS<br />
29<br />
Benachrichtigungen<br />
Bis hierher wurde eine automatische<br />
Synchronisation zwischen OCS und<br />
OpenNMS konfiguriert. Dabei kann<br />
OCS kontrollieren, welche Server in<br />
OpenNMS automatisch zu importieren<br />
sind. In OpenNMS wird über die<br />
Requisition ein Monitoring-Profil bestehend<br />
aus Service-Detektoren für<br />
Web-, Mail- oder Datenbank-Server<br />
angewendet. Außerem braucht man<br />
noch Benachrichtigungen für das NOCund<br />
Entwicklungsteam. Um Mails zu<br />
versenden, muss OpenNMS mit einem<br />
Mailserver kommunizieren. Die Grundkonfiguration<br />
zum Mailversand sind im<br />
OpenNMS-Wiki im Abschnitt Notification<br />
Tutorial [6] detailliert beschrieben.<br />
Beim Import hatten wir bereits festgelegt,<br />
dass das OCS-Attribut »Environment«<br />
als gleichnamige Surveillance-<br />
Category den OpenNMS-Nodes zuzuweisen<br />
ist. Diese Surveillance-Category<br />
verwenden wir jetzt als Benachrichtigungsfilter.<br />
In OpenNMS werden die beiden Teams<br />
Entwicklung und NOC über Gruppen<br />
abgebildet. Jeder der beiden Gruppen<br />
sind entsprechende OpenNMS-<br />
Benutzer des Teams zugeordnet. Die<br />
Kontaktinformation – darunter die E-<br />
Mail-Adresse des OpenNMS-Benutzers<br />
– lassen sich für die Benachrichtigung<br />
nutzen. Die Einrichtung der OpenNMS-<br />
Benutzer und -Gruppen zeigt Abbildung<br />
8. Sie lässt sich über die Weboberfläche<br />
im Administrationsbereich »Admin |<br />
Configure Users, Groups and On‐Call<br />
Roles« durchführen.<br />
Abbildung 9: Anlegen des Benachrichtigungspfades für das NOC.<br />
Der nächste Schritt erstellt zwei Pfade<br />
für die Benachrichtigung. Das geschieht<br />
im Administrationsbereich der Weboberfläche<br />
unter »Admin | Configure<br />
Notifications | Configure Destination<br />
Paths«. Dort werden zwei Pfade – wie<br />
in Abbildung 9 unter Punkt (1) gezeigt –<br />
erzeugt. Der neu erstellte Pfad wird<br />
bearbeitet und als Ziel wird die Benutzergruppe<br />
NOC ausgewählt.<br />
Die Konfiguration »Initial Delay« (2)<br />
legt fest, wie lange eine Benachrichtigung<br />
bei einer aufgetretenen Störung<br />
zurückgehalten wird, bevor OpenNMS<br />
die E-Mail an die Gruppe versendet.<br />
Beim Bearbeiten des Pfades ist darauf<br />
zu achten, dass als Benachrichtigungskommando<br />
der Wert »javaEmail« (4)<br />
ausgewählt ist.<br />
Im letzten Schritt wird die eigentliche<br />
Benachrichtigung konfiguriert.<br />
Jede Störung erzeugt ein Ereignis in<br />
OpenNMS. Ereignisse werden durch<br />
einen Bezeichner – die UEI – identifiziert.<br />
Für dieses Beispiel konfiguriert<br />
der Admin eine Benachrichtigung für<br />
ein »nodeLostService«-Ereignis. Das<br />
wird erzeugt, wenn beispielsweise<br />
ein Server über das Netzwerk mittels<br />
ICMP noch erreichbar ist, jedoch ein<br />
Service wie HTTP nicht mehr reagiert.<br />
Dazu wird über das Hauptmenü im<br />
Administrationsbereich unter »Admin |<br />
Configure Notification | Configure Event<br />
Abbildung 8: OpenNMS-Benutzer und -Gruppen für die Benachrichtigung.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
30<br />
Netzwerk<br />
OpenNMS und OCS<br />
n Info<br />
Notifications« die Benachrichtigung für<br />
»nodeLostService« bearbeitet. Danach<br />
wird angezeigt, für welchen Ereignis-<br />
Bezeichner (UEI) die Benachrichtigung<br />
angelegt wurde. Der Admin bestätigt<br />
die Vorauswahl mit »Next« und wird<br />
daraufhin aufgefordert, anzugeben, für<br />
welche Systeme und Services die Benachrichtigung<br />
gelten soll.<br />
Abbildung 10 zeigt unter Punkt (1), welcher<br />
Filter für die Produktivumgebung<br />
eingetragen wird. Die hier gezeigte<br />
Regel »catincProduction« verwendet<br />
das Prefix »catinc«. Dieses Prefix steht<br />
für „category include“ und ist equivalent<br />
zu »categoryname == 'Production'«.<br />
Wichtiger Hinweis: Leerzeichen<br />
und deutsche Umlaute sollte man in<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31829<br />
[1] Christian Pape and Ronny Trommer, Durchleuchtet:<br />
VMware-Monitoring mit OpenNMS.<br />
<strong>ADMIN</strong>-<strong>Magazin</strong> 2/2013, S. 98.<br />
[2] OpenNMS-Installation: [http:// www. opennms.<br />
org/ wiki/ Tutorial_Installation]<br />
[3] OCS: [http:// wiki. ocsinventory‐ng. org/ index.<br />
php/ Documentation:Server]<br />
[4] OCS-Integration: [http:// www. opennms. org/<br />
wiki/ OCS_Integration]<br />
[5] Provisioning: [http:// www. opennms. org/ w/<br />
images/ c/ ca/ ProvisioningUsersGuide. pdf]<br />
[6] Notifications: [http:// www. opennms. org/<br />
wiki/ Tutorial_Notifications]<br />
[7] Puppet: [http:// puppetlabs. com]<br />
[8] Chef: [http:// www. getchef. com]<br />
[9] OpenNMS-Conference:<br />
[http:// www. opennms. eu]<br />
Surveillance-Categories vermeiden. Die<br />
Filter und Regelauswertungen können<br />
an manchen Stellen Probleme verursachen.<br />
Mit der Auswahl »Validate rule<br />
results« lässt sich anzeigen, auf welche<br />
Systeme die Filterregel anzuwenden<br />
sind. Der Assistent wird dann durch<br />
Auswählen von »Skip results validation«<br />
fortgesetzt.<br />
Die Abbildung 10 zeigt unter Punkt (2),<br />
dass sich die Bezeichnung von »node-<br />
LostService« auf »NOC: nodeLostService«<br />
geändert hat. Damit sieht man in<br />
der Benutzeroberfläche, dass diese Benachrichtigung<br />
für das NOC-Team gedacht<br />
ist. Unter »Choose a Path« wählt<br />
man den zuvor angelegten Benachrichtigungspfad<br />
»NOC‐Team« aus.<br />
Falls gewünscht, kann der eigentliche<br />
Benachrichtigungstext hier geändert<br />
werden. Ein Textgerüst kann mit Variablen<br />
wie zum Beispiel »%nodelabel%«<br />
gefüllt werden. Diese Variablen füllen<br />
sich dann bei einer Störung mit Werten<br />
für ein konkretes System. Sicherheitshalber<br />
sollte man überprüfen, dass die<br />
Benachrichtigung unter »Admin | Notification<br />
Status« auf »On« gesetzt ist. Es<br />
könnten auch einzelne Benachrichtigungen<br />
deaktiviert sein. Deshalb sollte<br />
man unter dem Punkt »Admin | Configure<br />
Notifications | Configure Event Notifications«<br />
den Punkt »NOC: nodeLost-<br />
Service« aktivieren. Für die Benachrichtigung<br />
an das Entwicklungsteam wird<br />
eine zweite Benachrichtigung für das<br />
Ereignis »nodeLostService« nach dem<br />
gleichen Schema erzeugt. Wie in Abbildung<br />
10 dargestellt, ist als Filterregel<br />
lediglich »catincStage« einzutragen.<br />
Für die Benachrichtigung selbst ist<br />
als Name »Dev: nodeLostService« verwendbar.<br />
Zum Schluss wird noch der<br />
Zielpfad für die Benachrichtigung auf<br />
»Development‐Team« gesetzt.<br />
Fazit<br />
Das Zusammenspiel der beiden Anwendungen<br />
OCS und OpenNMS zeigt, dass<br />
freie Anwendungen sehr gut von offenen<br />
Schnittstellen profitieren können.<br />
Über das hier demonstrierte Beispiel<br />
hinaus wäre es unter anderem auch<br />
denkbar, beim Ausrollen der beteiligten<br />
Systeme mit Puppet [7] oder Chef<br />
[8] die OCS-Attribute bereits bei der<br />
Installation der OCS-Agenten setzen zu<br />
lassen.<br />
Wer interessiert ist, Anwendungsfälle<br />
wie den hier vorgestellten direkt mit<br />
anderen Anwendern und Entwicklern<br />
zu besprechen, der ist auf der<br />
OpenNMS User Conference [9] vom 8.<br />
bis 11. April 2014 an der Universität in<br />
Southampton herzlich willkommen. Es<br />
werden dort neben vielen Anwendern<br />
von OpenNMS auch etliche Entwickler<br />
von OCS Inventory und OpenNMS<br />
anwesend sein und Rede und Antwort<br />
stehen. (jcb) n<br />
n Autoren<br />
Die Autoren Ronny Trommer und Markus Neumann<br />
sind Gründungsmitglieder des gemeinnützigen Vereins<br />
OpenNMS Foundation Europe. Die Entwicklung<br />
wurde im OpenNMS-Projekt im Rahmen des Google<br />
Summer of Code 2013 initiiert und von Markus<br />
Neumann als Mentor begleitet. Ronny Trommer ist<br />
nebenberuflich als Dozent im Fachbereich Angewandte<br />
Informatik an der Hochschule Fulda mit dem<br />
Schwerpunkt Integrated Networking tätig.<br />
Abbildung 10: Benachrichtigungsfilter und Ziel auswählen.<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
32<br />
Netzwerk<br />
HA-Proxy<br />
tiero, 123RF<br />
Passthrough und Offloading: HTTPS balancieren mit HA-Proxy 1.5<br />
Verschlüsselte Last<br />
HA-Proxy verteilt die Besucherströme vielgenutzter Webseiten auf verschiedene Server; die nächste Version<br />
optimiert auch verschlüsselte Verbindungen. Zu den Nutzern des Loadbalancer zählen unter anderem<br />
die extrem häufig frequentierten Seiten Twitter, Stack Overflow, Reddit und Tumblr. Charly Kühnast<br />
n Autor<br />
Bei womöglich zehntausend gleichzeitigen<br />
Zugriffen auf eine Webseite<br />
muss sich die Last möglichst geschickt<br />
auf mehrere Server verteilen. Für die<br />
optimale Nutzung der vorhandenen<br />
Hardware sorgt HA-Proxy [1]. HTTP-<br />
Server stoßen allerdings beim Einsatz<br />
von SSL-verschlüsselten Verbindungen<br />
schneller an ihre Grenzen, denn jede<br />
Ent- und Verschlüsselung erfordert<br />
zusätzliche Rechenleistung. An dieser<br />
Stelle legt die in Entwicklung befind-<br />
Charly Kühnast stieg in den frühen 90ern von IBM-<br />
Mainframes auf Linux um und ist Sysadmin in einem<br />
niederrheinischen Rechenzentrum. Seine Freizeit<br />
verbringt er als Aushilfslehrer in verschiedenen<br />
Hochschulen, als Autor für Medialinx und Galileo<br />
Press, im Dojo und – am liebsten – in der Küche.<br />
liche HA-Proxy-Version 1.5 mit neuen<br />
Features nach.<br />
Bisher unterscheiden Loadbalancer wie<br />
HA-Proxy nicht wesentlich zwischen<br />
HTTPS- und unverschlüsselten HTTP-<br />
Verbindungen. Sie leiten die geschützten<br />
Anfragen per SSL-Passthrough<br />
ungerührt an die passenden Webserver<br />
weiter. Für HA-Proxy genügt dafür die<br />
recht übersichtliche Konfiguration in<br />
Listing 1.<br />
HTTP mit oder ohne S?<br />
Der größte Unterschied zwischen HTTPund<br />
HTTPS-Balancing besteht in der<br />
Zeile »mode tcp« (unter »https_frontend«),<br />
während bei der unverschlüsselten<br />
Variante »mode http« zum Einsatz<br />
kommt. Im letzteren Modus nutzt<br />
HA-Proxy die HTTP- Header-Daten, um<br />
Balancing-Entscheidungen zu treffen.<br />
Die beiden mit »stick« beginnenden<br />
Zeilen im Abschnitt »backend« sorgen<br />
dafür, dass ein Client immer auf<br />
demselben Webserver landet. Diese<br />
Zuordnungen merkt sich HA-Proxy in<br />
einer eigenen Tabelle, der sogenannten<br />
Stick-Table.<br />
Das Schlüsselwort »check« in der<br />
Server-Definition bewirkt, dass HA-<br />
Proxy die Backend-Server zyklisch auf<br />
Lebenszeichen prüft. Zusätzlich steht<br />
hierfür die »httpchk«-Option zur Verfügung.<br />
Sie bleibt in der noch aktuellen<br />
Version 1.4 von HA-Proxy dem unverschlüsselten<br />
HTTP-Verkehr vorbehalten,<br />
die finale Version 1.5 wird sie auch<br />
in Verbindung mit SSL erlauben.<br />
Eingeschaltet wird die erweiterte Prüfung<br />
im einfachsten Fall mit »option<br />
httpchk«. HA-Proxy sendet dann einen<br />
vollständigen HTTP-Request an den<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Netzwerk<br />
HA-Proxy<br />
33<br />
Backend-Server (»OPTIONS /«) und<br />
betrachtet ihn als gesund, wenn er eine<br />
Antwort mit den Statuscodes »2xx«<br />
oder »3xx« zurückbekommt. Sowohl<br />
die Request-Methode als auch die URL<br />
lassen sich anpassen:<br />
option httpchk HEAD /<br />
option httpchk OPTIONS /documents/all/<br />
Die erste Zeile ersetzt die Default-<br />
Methode »OPTIONS« durch »HEAD«. Die<br />
zweite verwandelt die Standard-URL<br />
»/« in »/documents/all«.<br />
Im Normalfall laufen die Lebenszeichen<br />
über HTTP 1.0 ab, aber HTTP 1.1 ist<br />
auch erlaubt. Dazu ist das »Host«-Feld<br />
erforderlich, das man beginnend mit<br />
der Zeichenfolge »\r\n« an die Protokollversion<br />
anhängt:<br />
option httpchk HEAD U<br />
HTTP/1.1\r\nHost:\ www<br />
SSL-Offloading<br />
Das grundlegende Problem beim<br />
HTTPS-Balancing besteht in der zusätzlichen<br />
Last auf den Backend-Servern,<br />
denn SSL ist rechenintensiv – die<br />
Server können nicht so viele Clients<br />
bedienen wie ohne SSL. Für dieses Problem<br />
hat die in Entwicklung befindliche<br />
Version 1.5 von HA-Proxy eine Lösung<br />
an Bord: SSL-Offloading oder SSL-Termination.<br />
Die neue HA-Proxy-Version<br />
bringt unter anderem die Möglichkeit<br />
mit, die Verschlüsselung von SSL-<br />
Verbindungen schon am Loadbalancer<br />
zu terminieren, sodass dieser mit den<br />
Backend-Webservern nur noch HTTP<br />
spricht. Das entlastet die Webserver<br />
vom Zeit- und Ressourcen-intensiven<br />
Ver- und Entschlüsseln. Sofern die<br />
Hardware des Balancers mitspielt,<br />
erzielt diese Methode deutliche Geschwindigkeitsvorteile.<br />
SSL-Offloading ermöglicht beim Kompilieren<br />
des Quellcodes die Option<br />
»USE_OPENSSL=1«. Fertig geschnürte<br />
Pakete stehen für einige populäre<br />
Linux-Distributionen ebenfalls bereit,<br />
darunter Debian [2], Ubuntu [3] sowie<br />
OpenSuse und Suse Linux Enterprise<br />
Server (SLES) [4]. Listing 2 zeigt die für<br />
SSL-Offloading abgewandelte Konfiguration.<br />
Im Abschnitt »frontend« fällt auf, dass<br />
die »bind«-Zeile jetzt Informationen<br />
über das SSL-Zertifikat enthält. Für<br />
einen SSL-Offloading-Test genügt an<br />
dieser Stelle das von OpenSSL für<br />
Testzwecke mitgelieferte Snakeoil-Zertifikat.<br />
Wenn alles richig funktioniert,<br />
tauscht man es durch ein korrektes<br />
Zertifikat aus. In die unter »bind« angegebene<br />
PEM-Datei gehören sowohl das<br />
Serverzertifikat als auch der zugehörige<br />
private Schlüssel, sie werden darin aneinandergehängt:<br />
#~ cat /etc/ssl/certs/ssl‐cert‐snakeoilU<br />
.pem /etc/ssl/private/ssl‐cert‐U<br />
snakeoil.key > /etc/haproxy/snakeoil.pem<br />
Abbildung 1: Die HA-Proxy-Statistik demonstriert die Stickiness: Alle Verbindungen des<br />
untersuchten Clients landen auf dem Server »web2«.<br />
Im Abschnitt »backend« sind die Server<br />
nun von ihrer SSL-Last befreit und lauschen<br />
auf Port 80.<br />
Außerdem kümmern sich nun Cookies<br />
um die sogenannte Stickiness, die<br />
Zuordnung eines Clients zu einem bestimmten<br />
Server. Kommt die Anfrage<br />
n Listing 1: HA-Proxy mit SSL-Passthrough<br />
01 global<br />
02 log /dev/log local0<br />
03 log /dev/log local1 notice<br />
04 <br />
05 maxconn 1000<br />
06 daemon<br />
07 user haproxy<br />
08 group haproxy<br />
09 <br />
10 defaults<br />
11 log global<br />
12 mode tcp<br />
13 option httplog<br />
14 option dontlognull<br />
15 timeout server 5s<br />
16 timeout connect 5s<br />
17 timeout client 5s<br />
18 errorfile 400 /etc/haproxy/errors/400.http<br />
19 errorfile 403 /etc/haproxy/errors/403.http<br />
20 errorfile 408 /etc/haproxy/errors/408.http<br />
21 errorfile 500 /etc/haproxy/errors/500.http<br />
22 errorfile 502 /etc/haproxy/errors/502.http<br />
23 errorfile 503 /etc/haproxy/errors/503.http<br />
24 errorfile 504 /etc/haproxy/errors/504.http<br />
25 <br />
26 frontend https_frontend<br />
27 bind *:443<br />
28 mode tcp<br />
29 option httpclose<br />
30 option forwardfor<br />
31 reqadd X‐Forwarded‐Proto:\ https<br />
32 default_backend httpserver<br />
33 <br />
34 listen stats :2000<br />
35 mode http<br />
36 stats enable<br />
37 stats hide‐version<br />
38 stats realm Haproxy\ Statistics<br />
39 stats uri /<br />
40 stats auth admin:secret<br />
41 <br />
42 backend httpserver<br />
43 mode tcp<br />
44 balance roundrobin<br />
45 stick‐table type ip size 200k expire 60m<br />
46 stick on src<br />
47 server web1 10.0.0.1:443<br />
48 server web2 10.0.0.2:443<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
34<br />
Netzwerk<br />
HA-Proxy<br />
n Info<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31735<br />
[1] HA-Proxy: [http:// haproxy. 1wt. eu/]<br />
[2] HA-Proxy-1.5-Debian-Pakete: [http:// packages.<br />
debian. org/ de/ experimental/ haproxy]<br />
[3] HA-Proxy-1.5-Ubuntu-Pakete:<br />
[https:// launchpad. net/ ~vbernat/ +archive/<br />
haproxy‐1. 5]<br />
[4] HA-Proxy-1.5-Suse-Pakete: [http:// www.<br />
rpmseek. com/ rpm‐pl/ haproxy‐1. 5. html]<br />
eines Clients ohne passenden Cookie<br />
am Balancer an, fügt HA-Proxy einen<br />
»SERVERID«-Cookie in die Antwort ein,<br />
der den Namen des Servers enthält,<br />
etwa »web1«. Bei der nächsten Verbindung<br />
vom gleichen Client – dieses Mal<br />
mit Cookie – weiß HA-Proxy, zu welchem<br />
Server es die Anfrage schicken<br />
soll. Dieser Trick erspart dem Loadbalancer<br />
die Pflege einer Stick-Table.<br />
Listing 3 zeigt einen Ausschnitt der<br />
HA-Proxy-Debugging-Ausgabe mit der<br />
Ausgabe des Cookies.<br />
Vor dem Start steht schließlich eine<br />
Syntaxprüfung der Konfigurationsdatei<br />
an:<br />
#~ haproxy ‐c ‐f /etc/haproxy.cfg<br />
Antwortet HA-Proxy mit der Meldung<br />
»Configuration file is valid«, steht der<br />
ausgewogenen Lastverteilung kaum<br />
etwas im Wege. Beim Aufruf der HTTPS-<br />
Adresse beschwert sich der Browser<br />
zwar noch über das zum Testen<br />
verwendete, aber wertlose Snakeoil-<br />
Zertifikat, dem die vertrauenswürdige<br />
Signatur fehlt. Nach dem Abnicken dieser<br />
Warnung funktioniert aber alles wie<br />
gewünscht: Client und Loadbalancer<br />
unterhalten sich per HTTPS, Balancer<br />
und Webserver per HTTP. Die Statistik<br />
(siehe Abbildung 1) zeigt die Stickiness<br />
auf: Die eingehenden Verbindungen<br />
eines Clients landen alle auf Server<br />
»web2«, während der Server »web1«<br />
auf neue Clients wartet. (csc) n<br />
n Listing 2: HA-Proxy mit SSL-Offloading<br />
01 global<br />
02 log /dev/log local0<br />
03 log /dev/log local1 notice<br />
04 <br />
05 maxconn 1000<br />
06 daemon<br />
07 user haproxy<br />
08 group haproxy<br />
09 <br />
10 defaults<br />
11 log global<br />
12 mode http<br />
13 option httplog<br />
14 option dontlognull<br />
15 timeout server 5s<br />
16 timeout connect 5s<br />
17 timeout client 5s<br />
18 errorfile 400 /etc/haproxy/errors/400.http<br />
19 errorfile 403 /etc/haproxy/errors/403.http<br />
20 errorfile 408 /etc/haproxy/errors/408.http<br />
21 errorfile 500 /etc/haproxy/errors/500.http<br />
22 errorfile 502 /etc/haproxy/errors/502.http<br />
23 errorfile 503 /etc/haproxy/errors/503.http<br />
24 errorfile 504 /etc/haproxy/errors/504.http<br />
25 <br />
26 frontend https_frontend<br />
27 bind *:443 ssl crt /etc/haproxy/snakeoil.pem<br />
28 mode http<br />
29 option httpclose<br />
30 option forwardfor<br />
31 reqadd X‐Forwarded‐Proto:\ https<br />
32 default_backend httpserver<br />
33 <br />
34 listen stats :2000<br />
35 mode http<br />
36 stats enable<br />
37 stats hide‐version<br />
38 stats realm Haproxy\ Statistics<br />
39 stats uri /<br />
40 stats auth admin:secret<br />
41 <br />
42 backend httpserver<br />
43 mode http<br />
44 balance roundrobin<br />
45 cookie SERVERID insert indirect nocache<br />
46 server web1 10.0.0.1:80 check cookie web1<br />
47 server web2 10.0.0.2:80 check cookie web2<br />
n Listing 3: HA-Proxy-Output mit Cookie-Vergabe<br />
01 0000000e:stats.clireq[0008:ffff]: GET / HTTP/1.1<br />
02 0000000e:stats.clihdr[0008:ffff]: Host: 10.0.0.150:2000<br />
03 0000000e:stats.clihdr[0008:ffff]: Connection: keep‐alive<br />
04 0000000e:stats.clihdr[0008:ffff]: Authorization: Basic YWRtaW46c2VjcmV0<br />
05 0000000e:stats.clihdr[0008:ffff]: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8<br />
06 0000000e:stats.clihdr[0008:ffff]: User‐Agent: Mozilla/5.0 (X11; Linux x86_64) Ubuntu Chromium/31.0.1650.63<br />
07 0000000e:stats.clihdr[0008:ffff]: Accept‐Encoding: gzip,deflate,sdch<br />
08 0000000e:stats.clihdr[0008:ffff]: Accept‐Language: de‐DE,de;q=0.8,en‐US;q=0.6,en;q=0.4<br />
09 0000000e:stats.clihdr[0008:ffff]: Cookie: SERVERID=web2<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Methee Wongwuttikomjorn, 123RF<br />
Systeme vollständig sichern und wiederherstellen mit Redo Backup<br />
Sicherer Kreislauf<br />
Redo Backup sichert komplette Festplatten übers Netzwerk oder lokal. Im Vordergrund stehen dabei eine<br />
einfache Bedienung und hohe Zuverlässigkeit in vielfältigen Einsatz-Szenarien. Thomas Zeller<br />
n Redo-Backup-Live-CD<br />
Die Redo-Backup-Entwickler stellen unter [5] eine<br />
ausführliche Schritt-für-Schritt-Anleitung für die <strong>Erste</strong>llung<br />
einer eigenen Live-CD zur Verfügung. Basis<br />
für die dort beschriebene Vorgehensweise ist Ubuntu<br />
12.04 (Precise Pangolin) und ADeskBar Version 0.4.3.<br />
Letzteres ist der Python-/GTK-basierende Applikationsstarter<br />
für Openbox, auf dem das vereinfachte<br />
Startmenü von Redo Backup basiert.<br />
Nach Aussage der Entwickler eignen sich auch<br />
neuere Ubuntu-Releases als Basis für eine eigene<br />
Live-CD – allerdings wächst dadurch die Größe der<br />
Image-Datei. Dafür ersetzt man den in der Anleitung<br />
genannten Versionsnamen »precise« durch den eines<br />
neueren Ubuntu-Release. Das Ubuntu-Wiki listet sie<br />
unter [6] vollständig auf.<br />
Bare Metal: Redo Backup sichert alle<br />
auf einem Rechner vorhandenen<br />
Daten, inklusive Bootmanager und<br />
Betriebssystem. Im Ernstfall stellt es so<br />
den alten Zustand vollständig wieder<br />
her und die Arbeit geht sofort weiter.<br />
Was ist Redo Backup<br />
Redo Backup [1] ist eine auf Ubuntu<br />
Linux basierende Live-CD zur einfachen<br />
Sicherung und Wiederherstellung kompletter<br />
Festplatten inklusive sämtlicher<br />
Partitionen und des Master Boot Records<br />
(MBR). Das zu Redaktionsschluss<br />
aktuelle Release 1.0.4 liegt diesem Heft<br />
bei. Es basiert auf Ubuntu 12.04.1 (LTS),<br />
verwendet als Desktop allerdings den<br />
Fenstermanager Openbox und liefert<br />
nur die für den Einsatz als Backup- oder<br />
Rettungssystem erforderlichen Applikationen<br />
mit.<br />
Redo Backup ist sofort einsatzbereit,<br />
nachdem die 250 MByte große Image-<br />
Datei auf CD gebrannt ist. Für die<br />
Sicherung virtueller Maschinen lässt<br />
sie sich auch direkt als virtuelles CD-<br />
Laufwerk einbinden. Auf diese Weise<br />
ermöglicht eine virtuelle Maschine, die<br />
vom CD-Image bootet, auch im laufenden<br />
System einen ersten Blick auf das<br />
Backup-System.<br />
Was Redo Backup kann...<br />
Redo Backup vereint die Vorteile eines<br />
verlässlichen Betriebssystems mit umfangreicher<br />
Hardware-Unterstützung<br />
auf einer Live-CD und die Vorzüge des<br />
Partitionswerkzeugs Partclone [2]. Für<br />
letzteres stellt Redo Backup ein stark<br />
vereinfachtes, grafisch bedienbares<br />
Frontend bereit (siehe Abbildung 1).<br />
Der Hauptanwendungsfall von Redo<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
<strong>Disaster</strong>-<strong>Recovery</strong><br />
Redo Backup<br />
37<br />
Abbildung 1: Die Benutzeroberfläche von Redo Backup beschränkt<br />
sich aufs Wesentliche.<br />
Abbildung 2: Redo kann Images auf lokal angeschlossene Datenträger,<br />
Samba-Shares und FTP-Server sichern.<br />
dem Partitionen an, löscht, formatiert<br />
sie und verändert ihre Größe.<br />
Doch der eigentliche Zweck von Redo<br />
Backup bleibt die vollständige Wiederherstellung<br />
von Systemen, zum<br />
Beispiel nach einem Platten-Crash,<br />
Viren- oder Malware-Befall oder anderen<br />
Katastrophen. Doch gibt es – neben<br />
den erwähnten Vorzügen der Live-CD<br />
mit ihren Rettungstools – mindestens<br />
zwei weitere attraktive Einsatzmöglichkeiten:<br />
Die Virtualisierung physikalischer<br />
Systeme, auch P2V (physical-tovirtual)<br />
genannt, und die Übertragung<br />
virtueller Maschinen auf physikalische<br />
Hardware (V2P) (Abbildung 3).<br />
...und was nicht<br />
Da das Hauptaugenmerk<br />
von Redo Backup<br />
auf einer möglichst<br />
einfachen Sicherungsund<br />
Wiederherstellungsprozedur<br />
liegt,<br />
bleiben andere Administrationsfeatures<br />
außen vor. Die größte<br />
Einschränkung von<br />
Redo Backup besteht<br />
darin, dass es nur<br />
komplette Datenträger,<br />
nicht aber individuelle<br />
Partitionen sichert.<br />
Damit fehlt auch die<br />
Möglichkeit, inkrementelle<br />
oder differenzielle<br />
Sicherungen anzule-<br />
Backup ist also das Sichern auf beziehungsweise<br />
das Wiederherstellen von<br />
diesen Medientypen (Abbildung 2):<br />
n Lokale Datenträger wie Festplatten<br />
und SSDs,<br />
n per USB angeschlossene Speichermedien,<br />
n SMB-/CIFS-Freigaben,<br />
n FTP-Shares.<br />
Redo Backup sichert nur Bereiche<br />
der Festplatte, die tatsächlich Daten<br />
enthalten und spart per Kompression<br />
Speicherplatz. Das Backup-Ziel darf<br />
deshalb kleiner ausfallen als die zu<br />
sichernde Festplatte, solange es genügend<br />
Platz für die tatsächlich vorhandenen<br />
Daten bereitstellt.<br />
Da Redo Backup von einem Live-<br />
Medium bootet und einige zusätzliche<br />
Werkzeuge an Bord hat, eignet es sich<br />
neben dem Backup auch für Reparaturarbeiten<br />
am Dateisystem. So enthält<br />
der Werkzeugkasten neben Dateimanager,<br />
Bildbetrachter, Terminal,<br />
Texteditor und Browser auch das Red<br />
Hat Disk Utility. Es mountet, löscht, erstellt<br />
und überprüft Dateisysteme und<br />
fertigt Benchmarks an.<br />
Mit Baobab steht daneben ein Werkzeug<br />
zur grafischen Darstellung der<br />
Datenträgerbelegung zur Verfügung,<br />
Photoreq und Testdisk sind für die Wiederherstellung<br />
versehentlich gelöschter<br />
Dateien zuständig. Drivereset löscht<br />
bei Bedarf Datenträger komplett und<br />
setzt sie auf ihren Auslieferungszustand<br />
zurück. Mit GParted legt man außergen;<br />
auch die Wiederherstellung einzelner<br />
Dateien ist unmöglich. Das Ziel<br />
für die Rücksicherung darf außerdem<br />
nicht kleiner sein als der Sicherungsdatensatz.<br />
Leider erzeugt Redo Backup weder<br />
verschlüsselte Backups noch sichert es<br />
über SSH. Eine weitere Einschränkung<br />
betrifft Rechner mit UEFI-Secure-Boot:<br />
Da die aktuelle Version der Redo-<br />
Backup-Live-CD noch auf Ubuntu<br />
12.04.1 LTS basiert, muss man für<br />
ihren Einsatz Secure Boot im BIOS abschalten.<br />
Dieses Problem schafft das<br />
nächste Update von Redo Backup voraussichtlich<br />
aus der Welt, da Ubuntu<br />
seit Version 12.04.2 kompatibel mit<br />
Secure Boot ist [3]. Wer nicht solange<br />
Abbildung 3: Die Redo-Backup-Live-CD enthält essenzielle Werkzeuge<br />
zur Datenträger- und Partitionsverwaltung sowie zur Datenrettung.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
38<br />
<strong>Disaster</strong>-<strong>Recovery</strong><br />
Redo Backup<br />
n Info<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31890<br />
[1] Redo Backup: [http:// sourceforge. net/<br />
projects/ redobackup/ files/ latest/ download/]<br />
[2] Partclone: [http:// partclone. org/]<br />
[3] UEFI unter Ubuntu: [https:// help. ubuntu. com/<br />
community/ UEFI]<br />
[4] Unetbootin:<br />
[http:// unetbootin. sourceforge. net/]<br />
[5] Redo-Backup-Wiki: [http:// sourceforge. net/ p/<br />
redobackup/ wiki/ Home/]<br />
[6] Ubuntu-Release-Namen: [https:// wiki. ubuntu.<br />
com/ DevelopmentCodeNames]<br />
n Autor<br />
Thomas Zeller ist IT-Consultant<br />
und beschäftigt sich seit über 15<br />
Jahren mit IT-Sicherheit und Open<br />
Source. Er ist Autor beziehungsweise<br />
Co-Autor der Bücher Open-<br />
VPN kompakt und Mindmapping<br />
mit Freemind. Im richtigen Leben<br />
ist er IT-Unternehmer und Geschäftsführer<br />
eines IT-Systemhauses.<br />
Dort verantwortet er unter<br />
anderem den Geschäftsbereich<br />
IT- Sicherheit.<br />
warten möchte, erstellt sich eine eigene<br />
Redo-Live-CD (siehe Kasten „Redo-<br />
Backup-Live-CD“).<br />
Loslegen mit Redo Backup<br />
Gleichwohl bietet Redo Backup auch<br />
bei anderen Admin-Arbeiten <strong>Hilfe</strong>stellung.<br />
Die aufs Wesentliche reduzierte<br />
Benutzeroberfläche schafft in stressigen<br />
Situationen einen Überblick und<br />
ist etwa bei der telefonischen Unterstützung<br />
für Laien ohne Blick auf deren<br />
Bildschirm hilfreich.<br />
Wem der Start der Live-CD zu lange<br />
dauert, der überträgt das Redo Backup-<br />
Image auf einen USB-Stick. Die Entwickler<br />
empfehlen dafür Unetbootin<br />
[4], alternativ liefert die Live-CD mit<br />
dem Ubuntu Startup Disk Creator aber<br />
auch ein eigenes Werkzeug für diesen<br />
Zweck mit.<br />
Nachdem der Rechner von der Live-CD<br />
oder einem USB-Medium gebootet hat,<br />
startet Redo Backup automatisch die<br />
GUI zum Sichern und Wiederherstellen<br />
der im Gerät eingebauten Datenträger.<br />
Leider bietet die grafische Oberfläche<br />
keine Möglichkeit, die Tastaturbelegung<br />
auf Deutsch umzustellen. Doch<br />
gerade wegen der häufigen Verwendung<br />
von Zeichen wie »/« in Pfadangaben<br />
wird dies schnell lästig. Wer die<br />
US-Tastatur nicht ohnehin verinnerlicht<br />
hat, aktiviert deshalb mit dem Kommando<br />
»setxkbmap de« die deutsche<br />
Tastenbelegung.<br />
Wer weiterhin die Ausgabe von Redo<br />
Backup im Detail verfolgen möchte,<br />
startet das Backup-Programm im<br />
Terminal mit »redobackup«. Die weitere<br />
Bedienung erklärt sich indes von<br />
selbst: »Backup« sichert den vollständigen<br />
Datenträger inklusive aller Partitionen<br />
und Master Boot Record auf eine<br />
lokal angeschlossene USB-Festplatte,<br />
ein Netzlaufwerk oder auf einen FTP-<br />
Server. »Restore« stellt von diesen<br />
Quellen ein zuvor angelegtes Backup<br />
wieder her. Das funktioniert über die<br />
GUI zuverlässig und einfach, aber je<br />
nach Umfang der Sicherung nehmen<br />
sowohl Backup als auch Wiederherstellung<br />
mehrere Stunden in Anspruch.<br />
Eine typische Windows-7-Standard-<br />
Installation mit Office lässt sich ohne<br />
umfangreiche Daten dagegen schon in<br />
wenigen Minuten sichern und wiederherstellen.<br />
Fazit<br />
Redo Backup zielt mit seiner aufs Wesentliche<br />
reduzierten Benutzeroberfläche<br />
auch auf weniger versierte Anwender.<br />
Es verzichtet auf manche Features<br />
wie die Sicherung einzelner Dateien<br />
zugunsten seiner präzise und zuverlässig<br />
erledigten Hauptaufgabe: <strong>Disaster</strong><br />
<strong>Recovery</strong>. (csc) n<br />
n Alternativen zu Redo Backup<br />
Admins, die flexiblere Möglichkeiten zur Sicherung oder Wiederherstellung<br />
von Datenträgern benötigen, finden nachfolgend eine Auswahl<br />
alternativer Imaging-Backup-Werkzeuge:<br />
Free und Open Source:<br />
n Clonezilla: Auf Debian basierende Live-CD mit textbasierter Menüführung.<br />
Klont und sichert einzelne Partitionen oder komplette Datenträger<br />
und stellt sie wieder her.<br />
n G4L: Vormals »Ghost for Linux« sichert ganze Datenträger, einzelne<br />
Partitionen und einzelne Dateien. Textbasierte Menüführung, sichert<br />
auch auf SSHFS.<br />
n Partimage: Sichert Datenträger oder Partitionen via SSL übers Netzwerk<br />
mit eigenem Server und Client. Keine Unterstützung für Ext4<br />
und Btrfs. Stellt auch einzelne Dateien aus den Images wieder her.<br />
n Mondo Rescue: <strong>Disaster</strong>-<strong>Recovery</strong>-Lösung, die Backups vollständiger<br />
Datenträger erstellt und auf CD oder DVDs verteilt. Eine Boot-CD<br />
stellt mit diesen Backup-CDs einen Rechner vollständig wieder her.<br />
n Partclone [2]: Kommandozeilenwerkzeug zum Sichern und Wiederherstellen<br />
benutzter Partitionsblöcke.<br />
n Trinity Rescue Kit (TRK): Live-CD und Rettungssystem mit textbasierter<br />
Menüführung, insbesondere zur Wiederherstellung von Windows-<br />
Systemen unter anderem mit Passwort-<strong>Recovery</strong> und Viren-Scanner.<br />
n SystemRescueCD: Live-System mit zahlreichen Rettungswerkzeugen,<br />
verwendet Partimage zum Sichern von Festplatten und Partitionen.<br />
Kommerzielle Systeme:<br />
n Partedmagic: Seit August 2013 kostenpflichtig; Live-CD mit grafischen<br />
Tools für Partitionierung, Cloning, Datenrettung und Löschen<br />
von Daten.<br />
n Acronis True Image: Disk-Imaging für Windows- und Linux-Server<br />
mit optionaler Datensicherung in die Cloud.<br />
n Symantec Ghost Solution Suite: Client-Server-Modell mit zentraler<br />
Konsole für die Image-Verwaltung.<br />
n Paragon Festplattenmanager Premium: Disk-Imaging für Windows<br />
Server mit WinPE-Rettungsumgebung.<br />
n Storagecraft Shadowprotect: Umfangreiches Disk-Imaging-Werkzeug;<br />
nur für Windows-Systeme.<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Olha Shtepa, 123RF<br />
Relax and Recover<br />
Entspann Dich<br />
Relax and Recover (ReaR) erzeugt aus einem laufenden System ein passendes Rettungsmedium und<br />
eignet sich nebenbei auch als Migrationstool. Dieser Beitrag zeigt allen, die das interessante Bash-Tool<br />
nicht kennen, was sie verpasst haben. Thomas Drilling<br />
Ein regelmäßig durchgeführtes Backup<br />
gehört trotz Verfügbarkeit von Imaging-<br />
Lösungen und dem zunehmenden<br />
Einsatz von Virtualisierungstechnologien<br />
zum Pflichtprogramm für alle Unternehmen.<br />
Fatalerweise wähnen sich<br />
gerade kleine Unternehmen angesichts<br />
einer vorhandenen Backup-Lösung<br />
nicht selten in trügerischer Sicherheit.<br />
Selbst wer den potenziellen Ernstfall<br />
sogar personell und finanziell einplant,<br />
unterschätzt häufig die tatsächlichen<br />
Folgen.<br />
Abgesehen davon, dass vorhandene<br />
Backup-Medien turnusmäßig in<br />
Stichproben auf Ihre Lesbarkeit und<br />
Verwendbarkeit geprüft werden sollten,<br />
müssen Unternehmen auch den<br />
gesamten Workflow für den <strong>Recovery</strong>-<br />
Prozess im Vorfeld testen und im Ernstfall<br />
beherrschen. Selbstverständlich<br />
muss für den Ernstfall auch sofort<br />
einsetzbare Ersatz-Hardware vorhanden<br />
oder schnell beschaffbar sein, was<br />
nicht selbstverständlich ist, es sei denn,<br />
das Unternehmen setzt bereits auf<br />
Virtualisierung. In jedem Fall stehen im<br />
Ernstfall je nach Unternehmensgröße<br />
Stunden bis Tage an Handarbeit an, sogar<br />
wenn ein Daten-Backup vorhanden,<br />
vollständig integer und aktuell ist.<br />
Folgen des Ernstfalls<br />
So muss zum Beispiel beim Ersatzsystem<br />
mit möglichst identischer Hardware<br />
das Partitions-Layout oder die<br />
Konfiguration eines RAID-Verbundes<br />
dem Zustand vor dem Crash entsprechen.<br />
War der Patch-Level vor dem<br />
Crash auf dem aktuellen Stand und ist<br />
die Kernel-Version des neu installierten<br />
Systems noch die gleiche, genügt<br />
meist eine Basis-Installation des neuesten<br />
Images und eine anschließende<br />
Aktualisierung. War das gecrashte<br />
System nicht auf aktuellem Patch-Level<br />
oder eine Menge Software von Hand<br />
installiert, sind Probleme ebenfalls<br />
vorprogrammiert. Wer bloß von einem<br />
Backup der Benutzerdaten sein System<br />
rekonstruieren möchte, kann durchaus<br />
mit Schwierigkeiten rechnen. Eine Lösung<br />
für <strong>Disaster</strong> <strong>Recovery</strong> hilft, diese<br />
Problem zu umgehen.<br />
Das ReaR-Projekt [1] hat seinen Anfang<br />
im Jahr 2006 als Kooperation zwischen<br />
dem Berliner Open-Source-Consultant<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
<strong>Disaster</strong>-<strong>Recovery</strong><br />
ReaR<br />
41<br />
und Linux-Enthusiasten Schlomo Schapiro<br />
und Gratien D’Haese, dem Autor<br />
von »mkcdrec«. Im Laufe der Zeit kamen<br />
mit Dag Wieers und Jeroen Hoekx<br />
zwei weitere Maintainer hinzu, die bis<br />
heute sehr aktiv sind. Schlomo Schapiro<br />
kümmert sich im Projekt aktuell<br />
um architektonische Fragen und ist<br />
sich für Lobbyarbeit sowie die gesamte<br />
Kommunikation in Deutschland verantwortlich.<br />
Als Berliner arbeitet Schlomo<br />
zudem aktiv am Linuxtag mit und organisiert<br />
dort den Stand des Yadt- und<br />
des ReaR-Projekts, die beide seit 2008<br />
regelmäßig in Berlin vertreten sind.<br />
Professionell<br />
Dass inzwischen eine Reihe von Consultants<br />
wie etwa der Berliner Peer Heinlein<br />
Geld mit dem Consulting zu ReaR<br />
verdienen, zeigt, dass es sich beim<br />
ReaR-Projekt um eine professionelle<br />
und ernsthafte Angelegenheit handelt.<br />
In puncto Desaster-<strong>Recovery</strong> gibt es<br />
jedenfalls keine vergleichbare freie<br />
Lösung. Wie aktiv das Projekt ist, zeigt<br />
auch ein Blick auf Github [2]. Demnach<br />
arbeiten derzeit 17 Beitragende an der<br />
unter der GPL stehenden und in Bash<br />
geschriebenen Software mit.<br />
Ferner zeigte sich im Laufe unseres<br />
Tests, dass das Rear-Team in der Lage<br />
ist, via Mailingliste und Github-Issues<br />
Support mit einer Reaktionszeit innerhalb<br />
eines Tages zu leisten, was vermutlich<br />
eher Regel als Ausnahme ist.<br />
Darüber hinaus bieten die ReaR-Macher<br />
wie erwähnt auch kommerziellen<br />
Support an. Sogar eine beauftragte,<br />
individuelle Entwicklung weiterer Funktionen<br />
ist laut Aussage der Projektverantwortlichen<br />
möglich. Davon profitiert<br />
auch die Anwendergemeinschaft.<br />
So haben laut Auskunft von Schlomo<br />
Schapiro bis heute eine beachtliche Anzahl<br />
kommerzieller Kunden das Projekt<br />
mit ihren Anforderung indirekt ebenfalls<br />
weitergebracht.<br />
ReaR wird sogar von einigen Anwendern<br />
als Provisionierungswerkzeug verwendet.<br />
Hierbei stellt ReaR ein »Golden<br />
Master Image« wieder her, das dann<br />
von einem Post-<strong>Recovery</strong>-Skript angepasst<br />
wird, wozu die Option »POST_RE-<br />
COVERY_SCRIPT« zum Einsatz kommt,<br />
die sich die Fähigkeit der aktuellen<br />
ReaR-Versionen zunutze macht, das<br />
Backup an das Zielsystem anpassen zu<br />
können.<br />
ReaR als Migrationstool<br />
Seit Version 1.7 unterstützt ReaR dank<br />
Udev-Unterstützung neben rein physischen<br />
Szenarien auch diverse Arten<br />
vom Virtuellen ins Reale und umgekehrt.<br />
Somit stellen auch geänderte<br />
Festplatten-Controller oder Netzwerk-<br />
Interfaces kein Problem mehr dar.<br />
ReaR lädt die erforderlichen Treiber<br />
automatisch und nimmt die notwendigen<br />
Änderungen an der Initrd vor.<br />
Auf diese Weise lässt sich ReaR außer<br />
als Bare-Metal-<strong>Recovery</strong>-Lösung auch<br />
als universelles Migrationswerkzeug<br />
missbrauchen, etwa zum Virtualisieren<br />
physischer Server (P2V).<br />
n Migration mit ReaR<br />
Wie beschrieben eignet sich ReaR auch gut als<br />
Migrations-Werkzeug, denn bei aktuellen Versionen<br />
(ab 1.7, [9]) muss die Wiederherstellung nicht mehr<br />
zwangsläufig auf der gleichen Hardware erfolgen.<br />
Diese Funktionalität wurde erstmals in einem Projekt<br />
realisiert, das Schlomo Schapiro gemeinsam mit<br />
Heinlein Support für einen Großkunden entwickelt<br />
hatte, war aber von Anfang an geplant und ist seit<br />
der Version 1.7 standardmäßig in ReaR enthalten.<br />
Dabei baut ReaR das Rescue-Medium mit sämtlichen<br />
vorhandenen Treibern auf und passt das wiederhergestellte<br />
System selbstständig an die geänderte<br />
Hardware an. Das geht sogar so weit, dass ReaR<br />
auch geänderte Netzwerkkarten einschließlich eines<br />
Wegfalls von Bonding bei einer P2V-Migration, abweichende<br />
Storage-Szenarien mit ihren jeweiligen<br />
Treibern (zum Beispiel IDE zu SATA, SATA auf CCISS,<br />
von oder zu RAID und so weiter) und ein geändertes<br />
Festplattenlayout erkennt.<br />
Bei relativ einfachen Szenarien, bei denen zum<br />
Beispiel vor- wie nachher nur ein NIC und eine HD<br />
existiert, funktioniert das Ganze vollautomatisch.<br />
Bei komplexeren Migrationen fragt ReaR beim <strong>Recovery</strong>,<br />
was es tun soll. In der Dokumentation [10] sind<br />
exem plarisch eine Reihe von Mapping-Dateien verfügbar,<br />
mit deren <strong>Hilfe</strong> sich auch größere Migrationen<br />
weitgehend automatisieren lassen. Laut Auskunft<br />
der Entwickler nutzt ein Großkunde diese Funktionalität,<br />
um mehrere tausend physische Server in einem<br />
Rutsch nahezu vollautomatisch zu virtualisieren.<br />
n Tabelle 1: Backup-Lösungen<br />
Software<br />
GNU-Tar auf NAS-Share oder Bandlaufwerk<br />
Rsync auf NAS-Share oder lokales Gerät<br />
Rsync über Netzwerk<br />
Rsync Backup Made Easy<br />
Bacula<br />
Bareos<br />
SEP SESAM<br />
IBM Tivoli Storage Manager<br />
HP Data Protector<br />
Symantec NetBackup<br />
Duplicity/Duply<br />
CommVault Galaxy 5, 6 und 7<br />
EMC Networker (ehemals Legato)<br />
ReaR-Option<br />
BACKUP=NETFS, BACKUP_PROG=tar<br />
BACKUP=NETFS, BACKUP_PROG=rsync<br />
BACKUP=RSYNC – im Unterschied zu BACKUP=NETFS wird hierbei nichts gemountet. Statdessen<br />
arbeitet Rsync hier direkt mit dem Rsync-Protokoll, sofern vorhanden mit SSH.<br />
BACKUP=RBME<br />
BACKUP=BACULA<br />
BACKUP=BAREOS<br />
BACKUP=SESAM<br />
BACKUP=TSM<br />
BACKUP=DP<br />
BACKUP=NBU<br />
BACKUP=DUPLICITY (noch experimentell)<br />
BACKUP=GALAXY<br />
BACKUP=NSR<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
42<br />
<strong>Disaster</strong>-<strong>Recovery</strong><br />
ReaR<br />
Abbildung 1: Fedora 19 bringt die aktuelle ReaR-Version 1.15 von Haus aus mit.<br />
ReaR beherrscht aber auch virtual-tophysical<br />
(V2P) und virtual-to-virtual<br />
(V2V), womit auch der Rückweg des<br />
Restaurierens aus einer virtuellen<br />
Maschine auf einen physischen Server<br />
oder der Wechsel von einer bestehenden<br />
Virtualisierungslösung zu einer<br />
anderen möglich ist. ReaR unterstützt<br />
KVM, Xen und VMware. Weitere Einzelheiten<br />
dazu sind im Kasten „Migration<br />
mit ReaR“ zu finden.<br />
Abbildung 2: Das ISO-Image landet im Normalfall auch im Backup.<br />
Was ReaR macht<br />
ReaR ist eine echte <strong>Disaster</strong>-<strong>Recovery</strong>-<br />
Lösung, die aus einem laufenden<br />
Linux-System ein Rettungsmedium für<br />
den Ernstfall erzeugt. Fällt eine Hardwarekomponente<br />
aus oder muss sie<br />
aus anderen Gründen ausgetauscht<br />
werden, kann der Administrator das<br />
Ersatzsystem von diesem Rettungsmedium<br />
booten und sein System vollautomatisch<br />
in den Ursprungszustand versetzen<br />
– inklusive des Partitionierens<br />
und Formatierens der Festplatten, des<br />
Zurückspielens sämtlicher Daten und<br />
des Installierens des Bootloaders.<br />
ReaR differenziert dabei aus den beschriebene<br />
Gründen strikt zwischen<br />
den Funktionsbereichen <strong>Recovery</strong> und<br />
Backup, wobei eine initiale vollständige<br />
Sicherung des geschützten Systems<br />
die Grundlage ist. Im Idealfall stellt<br />
ReaR die Daten aus einem vorhandenen<br />
Backup wieder her und arbeitet<br />
dazu mit vielen Backup-Lösungen<br />
zusammen, darunter Bacula/Bareos,<br />
SEP SESAM, Tivoli Storage Manager, HP<br />
Data Protector, Symantec NetBackup,<br />
CommVault Galaxy und EMC/Legator<br />
Networker. Weitere Einzelheiten zu den<br />
unterstützten Backup-Werkzeugen einschließlich<br />
etwaiger Konfigurationsparameter<br />
sind Tabelle 1 zu entnehmen.<br />
Ist keine Backup-Lösung vorhanden,<br />
kümmert sich ReaR selbst via Tar<br />
oder Rsync um eine Sicherung, zum<br />
Beispiel auf einer NFS-Freigabe oder<br />
einem USB-Device. Mit der Backup-<br />
Unterstützung kann die sonst bei<br />
<strong>Disaster</strong>-Revory-Lösungen obligatorische<br />
doppelte Datensicherung entfallen.<br />
ReaR sorgt stets automatisch<br />
für das Wiederherstellern der jeweils<br />
neusten Daten. ReaR schreckt auch vor<br />
komplexen Konfigurationen mit Netzwerk-Bonding,<br />
Software-RAID, LVM-<br />
Partitionsschemata und exotischen<br />
Dateisystemen nicht zurück und bootet<br />
den restaurierten Server, als wäre nie<br />
etwas passiert.<br />
Test-Setup<br />
Für ein praktisches Test-Setup haben<br />
wir drei Szenarien durchgespielt, die<br />
sich auch für eigene Experimente<br />
aufdrängen, wobei wir uns als Backup-<br />
Lösung auf die Fähigkeiten von ReaR<br />
(Tar/Rsync) verlassen haben. Im ersten<br />
Setup haben wir via Tar auf eine<br />
NFS-Freigabe unseres NAS gesichert<br />
und das System anschließend von CD<br />
wiederhergestellt. Die mit einer etwas<br />
komfortableren, zentral verwalteten<br />
Rsync-Variante RBME [3] erstellten<br />
Backups können – von ReaR über das<br />
Netz gemountet – direkt wiederhergestellt<br />
werden; ein Szenario, das wir<br />
praktisch nicht durchgespielt haben.<br />
Admins kleiner Umgebungen und<br />
Heimanwender dürften sich eher mit<br />
einem Setup identifizieren, bei dem für<br />
Backup und <strong>Recovery</strong> ein USB-Storage<br />
zum Einsatz kommt. Hierbei lässt sich<br />
ein System auch im mobilen Einsatz<br />
relativ flexibel auf einem mitgeführten<br />
USB-Stick oder einer USB- beziehungsweise<br />
eSATA-Festplatte sichern, die<br />
dann auch gleichzeitig als bootfähiges<br />
<strong>Disaster</strong>-<strong>Recovery</strong>-Medium dient.<br />
Ferner haben wir ReaR in einem dritten<br />
Setup verwendet, um eine VMware-VM<br />
auf Virtualbox zu migrieren und dabei<br />
bewusst recht unterschiedliche Hardware<br />
konfiguriert. Was die Betriebssysteme<br />
angeht, ist zurzeit lediglich etwas<br />
Vorsicht mit Fedora 20 [4] und Open-<br />
Suse 12.3 geboten. Übrigens erstellt<br />
ReaR für absolut jedes System sein<br />
persönliches Bootmedium.<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
<strong>Disaster</strong>-<strong>Recovery</strong><br />
ReaR<br />
43<br />
Loslegen mit ReaR<br />
Das ReaR-Projekt stellt fertige Pakete<br />
für so ziemlich alle wichtigen Distributionen<br />
zur Verfügung. Fedora bringt<br />
von Haus aus ReaR-Pakete mit. Hier<br />
findet sich eine ältere Version 1.12 im<br />
Fedora-Repository sowie eine aktuelle<br />
ReaR-Version 1.15 in Fedora-Updates.<br />
CentOS-Nutzer finden ReaR im EPEL-<br />
Repo. Suse Linux Enterprise enthält<br />
zwar ReaR-Pakete, allerdings nur in<br />
einer älteren Version. Auch in Open-<br />
Suse ist ReaR in der Version 1.14 [5]<br />
zu finden, allerdings gab es im Test<br />
Probleme mit der Installation. Suse hat<br />
übrigens sogar ein YaST-Modul [6] für<br />
ReaR gebaut. Wir haben im ersten Test-<br />
Setup ein bewährtes Fedora-19-System<br />
verwendet (Abbildung 1).<br />
Soll das Desaster-<strong>Recovery</strong> von einem<br />
physischen Medium aus erfolgen,<br />
kann der Systemverwalter jetzt das<br />
gewünschte Sicherungsmedium vorbereiten,<br />
seinen USB-Stick mit einer passenden<br />
Ext2/3/4- oder Btrfs-Partition<br />
versehen und bootfähig machen. Muss<br />
er dabei keine Rücksicht auf bestehende<br />
Daten nehmen, kann er auch<br />
das komfortabel mit ReaR erledigen:<br />
/usr/sbin/rear format /dev/sdX<br />
ReaR erwartet lediglich eine Bestätigung,<br />
dass es das Medium vollständig<br />
überschreiben darf und versieht es<br />
mit der Bezeichnung »REAR‐000«.<br />
Danach oder bei Szenarien ohne USB-<br />
Bootmedien geht es ans Bearbeiten der<br />
Konfigurationsdatei »/etc/rear/local.<br />
conf«. Dazu kann sich der Systemverantwortliche<br />
beispielsweise an der<br />
komplett kommentierten Beispieldatei<br />
»/usr/share/rear/conf/default.conf«<br />
entlanghangeln. Die Manpage zu ReaR<br />
liefert alle benötigten Informationen.<br />
Darüber hinaus gibt es gute Dokumentation<br />
und ein etwas ausführlicheres<br />
User-Guide [7].<br />
Einfaches Setup<br />
Im Großen und Ganzen dreht sich die<br />
gesamte Konfiguration nur um zwei<br />
wesentliche Parameter: »OUTPUT=«<br />
legt die bevorzugte Boot-Methode<br />
fest und »BACKUP=« die gewünschte<br />
Backup-Strategie. Mit »OUTPUT=USB«<br />
beispielsweise sorgt<br />
der Systemverwalter<br />
dafür, dass ReaR den<br />
Rescue-Kernel und<br />
die Rescue-Initrd auf<br />
das angegebene USB-<br />
Medium schreibt und<br />
dort den Bootloader<br />
entsprechend konfiguriert.<br />
Alternativen für die anderen<br />
skizzierten Szenarien<br />
wären beispielsweise<br />
»OUTPUT=ISO«,<br />
»OUTPUT=PXE« oder<br />
»OUTPUT=RAMDISK«.<br />
Mit »OUTPUT=RAM-<br />
DISK« gibt ReaR nur<br />
den Kernel und die Initramfs<br />
aus, der Admin<br />
kümmert sich um die<br />
weitere Verarbeitung.<br />
In der Default-Einstellung<br />
legt ReaR das fertige<br />
ISO-Image in einer<br />
Datei unter »/var/lib/<br />
rear/output« ab, wofür<br />
»OUTPUT_URL=file://«<br />
verantwortlich ist.<br />
Generell versucht ReaR<br />
je nach verwendeter<br />
Backup-Strategie das<br />
Bootmedium auch im Backup mit abzulegen.<br />
Bei TSM wird zum Beispiel das<br />
Bootmedium durch einen Aufruf der<br />
Backup-Software mit in die Sicherung<br />
übernommen. Verwendet der Admin<br />
das per Default auf Tar eingestellte<br />
Backup-Verfahren in Verbindung mit<br />
dem Parameter »BACKUP_URL« zum<br />
Angeben des Backup-Targets (zum<br />
Beispiel ein NFS-Share), landet das<br />
ISO-Image also automatisch auch dort<br />
(Abbildung 2).<br />
Hier ist es wesentlich besser aufgehoben,<br />
denn »/var/lib/rear/output« würde<br />
im Ernstfall nicht mehr nur Verfügung<br />
stehen. Abweichend von diesem Verhalten,<br />
lässt sich mit »OUTPUT_URL=«<br />
aber auch ein anderes Ziel für das<br />
Image angeben. Zur Wahl stehen etwa<br />
»fish«, »ftp(s)«, »http(s)«, »rsync« und<br />
»sshfs«.<br />
Die Backup-Strategie gibt »BACKUP=«<br />
an, wobei ReaR mit »BACKUP=NETFS«<br />
automatisch Tar benutzt. Mit<br />
Abbildung 3: Der Simulationsmodus von ReaR.<br />
»BACKUP_PROG_CRYPT_ENABLED=1«<br />
klappt das auch verschlüsselt. Eine<br />
Alternative zu Tar ohne Einsatz eines<br />
externen Backup-Programms ist beispielsweise<br />
»BACKUP=RSYNC«. Alternativ<br />
legt »BACKUP=REQUESTRESTORE«<br />
fest, dass ReaR nicht automatisch ein<br />
Backup anfertigt, sondern den Nutzer<br />
danach fragt. Ebenso lässt sich mit<br />
»BACKUP=EXTERNAL« eine individuelle<br />
Backup-Strategie einbeziehen.<br />
Backup auf NFS oder CIFS<br />
Wurde das Backup-Verfahren auf<br />
»NETFS« gesetzt, gibt »BACKUP_URL=«<br />
das gewünschte Backup-Ziel an, zum<br />
Beispiel ein USB-Device oder eine NFSbeziehungsweise<br />
CIFS-Freigabe:<br />
BACKUP_URL=nfs://NFS‐Server/U<br />
Freigabe/Pfad ...<br />
ReaR legt dann unterhalb von »NFS‐Server/Freigabe/Pfad«<br />
einen Ordner mit<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
44<br />
<strong>Disaster</strong>-<strong>Recovery</strong><br />
ReaR<br />
n Info<br />
dem Namen des Clients an. Es funktioniert<br />
aber auch eine Datei auf der lokalen<br />
Festplatte, ein Tape-Device oder<br />
eine Samba-Freigabe:<br />
BACKUP_URL=file:///Verzeichnis/U<br />
Pfad/<br />
BACKUP_URL=tape:///dev/nst0, ...<br />
BACKUP_URL=cifs://Samba‐Server/U<br />
Freigabe/Pfad..<br />
Soll ReaR sich per CIFS/Samba authentifizieren,<br />
legt der Admin eine entsprechende<br />
Datei »/etc/rear/.cifs_credentials«<br />
an, auf die er aus »/etc/rear/local.<br />
conf« mit<br />
BACKUP_OPTIONS="cred=/etc/rear/U<br />
.cifs_credentials"<br />
verweist und darin Werte für »username«,<br />
»password« und »domain«<br />
einträgt.<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31695<br />
[1] ReaR-Projekt-Seite:<br />
[http:// relax‐and‐recover. org]<br />
[2] ReaR auf Github: [https:// github. com/ rear/<br />
rear/ commits/ master]<br />
[3] RBME: [https:// github. com/ schlomo/ rbme]<br />
[4] Git-Issue Fedora:<br />
[https:// github. com/ rear/ rear/ issues/ 346]<br />
[5] ReaR in OpenSuse: [http:// software. opensuse.<br />
org/ package/ rear]<br />
[6] YaST-Modul für Suse: [http:// software.<br />
opensuse. org/ package/ yast2‐rear]<br />
[7] ReaR-User-Guide: [https:// github. com/<br />
rear/ rear/ blob/ master/ doc/ user‐guide/<br />
03‐configuration. txt]<br />
[8] SEP-SESAM-Support:<br />
[http:// wiki. sep. de/ wiki/ index. php/ <strong>Disaster</strong>_<br />
<strong>Recovery</strong>_for_Linux_3. 0_en]<br />
[9] ReaR-1.15-Release-Notes: [http://<br />
relax‐and‐recover. org/ documentation/<br />
release‐notes‐1‐15]<br />
[10] Aktueller ReaR-Vortrag: [http:// www.<br />
slideshare. net/ schlomo/ brainshare‐2010‐slcels306‐linux‐disaster‐recovery‐made‐easy]<br />
Wer »OUTPUT=USB« mit »BACKUP_<br />
URL=usb://...« kombiniert, kann sowohl<br />
das Backup als auch das Rescue-Image<br />
auf das gleiche USB-Device schreiben,<br />
was für den Ad-hoc-Einsatz sehr nützlich<br />
ist, weil man in einem Rutsch ein<br />
bootfähiges Wiederherstellungsmedium<br />
erhält, vorausgesetzt, es steht<br />
genügend Platz zur Verfügung:<br />
BACKUP_URL=usb:///dev/GerätU<br />
/Label/REAR‐000<br />
ReaR legt per Default ein Voll-Backup<br />
an. Alternativ stehen eine Reihe von<br />
»EXCLUDE«-Optionen zum Eingrenzen<br />
des gewünschten Backup-Umfangs zur<br />
Verfügung. So lassen sich beispielsweise<br />
mit<br />
AUTOEXCLUDE_PATH=( /media )<br />
gezielt gemountete Verzeichnisse, wie<br />
etwa Netzwerkfreigaben oder gemountete<br />
externe Partitionen, vom Backup<br />
ausnehmen. Dagegen schließt<br />
AUTOEXCLUDE_DISKS=y<br />
sämtliche Festplatten und Partitionen<br />
vom Backup aus, die nicht von gemounteten<br />
Dateisystemen in Anspruch<br />
genommen werden. Genauso einfach<br />
lassen sich mit<br />
AUTOEXCLUDE_AUTOFS=..<br />
sämtliche Automounter-Pfade ausschließen.<br />
Wer zunächst nur das Rescue-Image<br />
anlegen und testen will, startet ReaR<br />
dann mit »rear mkrescue«. Genauso ist<br />
es möglich, nur das Backup mit »rear<br />
mkbackuponly« anzuschieben.<br />
Im Normalfall wird der Administrator<br />
beides in einen Rutsch erledigen wollen,<br />
was auch der beschriebenen Kernfunktionalität<br />
von ReaR entspricht.<br />
Schweigsam<br />
Da für den Einsatz in Cronjobs optimiert,<br />
zeigt ReaR im Regelfall nichts an.<br />
»rear ‐v« aktiviert den Verbose-Modus.<br />
Übrigens zeigt ReaR mit »rear ‐s« (Simulationsmodus)<br />
zunächst nur an,<br />
was es tun würde. Hierbei zeigt sich<br />
der modulare Aufbau von ReaR. Eigene<br />
Erweiterungen lassen sich so einfach<br />
an der richtigen Stelle einklinken. Dazu<br />
muss man nur ein passend benanntes<br />
Shell-Skript im gewünschten Pfad ablegen<br />
(Abbildung 3).<br />
Weitere Optionen für den ReaR-Start<br />
listet die Manpage. Hier finden sich<br />
auch alle verfügbaren »BACKUP«- und<br />
»OUTPUT«-Targets. Danach sollte es<br />
möglich sein, vom Rescue-Image zu<br />
booten und ReaR stellt von diesem und<br />
gegebenenfalls von einem vorhandenen<br />
Backup-Medium vollautomatisch<br />
das gesamte System wieder her.<br />
Was noch geht<br />
Neben den beschriebenen Standard-<br />
Funktionen kann ReaR aber noch<br />
einiges mehr. So kann sich der Admin<br />
beispielsweise die Ergebnisdateien (unter<br />
anderem auch das ISO-Image) per<br />
Mail schicken lassen. Auf diese Weise<br />
steht ein sehr sicherer Oneway-Übertragungskanal<br />
zur Verfügung, um das<br />
<strong>Recovery</strong>-Image vom zu schützenden<br />
System herunter zu bekommen.<br />
Im Übrigen ist das Design des <strong>Recovery</strong>-Images<br />
mit Passwörtern, privaten<br />
Schlüsseln und so weiter kein großes<br />
Geheimnis – vielleicht mit Ausnahme<br />
der Authentifizierung für kommerzielle<br />
Backup-Clients, die man aber etwa bei<br />
IBM Tivoli Storage Manager deaktivieren<br />
kann. So muss das <strong>Recovery</strong>-Image<br />
nicht besonders geschützt werden,<br />
sondern stellt lediglich die Integrität<br />
sicher. Ferner ist ReaR dank des modularen<br />
Designs sehr einfach erweiterbar.<br />
Im Übrigen kommt ReaR gut mit (U)EFI<br />
zurecht und unterstützt auch Itaniumund<br />
PowerPC-Systeme.<br />
Fazit<br />
Obwohl seit 2006 entwickelt, ist das<br />
außergewöhnliche <strong>Recovery</strong>-Tool vielen<br />
Admins unbekannt. Möglicherweise<br />
wird das Programm auch unterschätzt<br />
oder aufgrund der Tatsache, dass die<br />
Software aus Bash-Skripten basiert,<br />
nicht als professionell wahrgenommen.<br />
Dabei ist ReaR sehr professionell. Das<br />
gilt sowohl für den Code selbst als auch<br />
für das Projekt, das Ökosystem und den<br />
Entwicklungshintergrund. Die Realisierung<br />
über Bash-Skripte, die meist nicht<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
<strong>Disaster</strong>-<strong>Recovery</strong><br />
ReaR<br />
45<br />
länger als eine Bildschirmseite sind,<br />
sorgt nebenbei auch für die einfache<br />
Handhabung. Der Rest spielt sich in<br />
den wenigen Konfigurationsdateien ab<br />
(siehe Tabelle 2).<br />
Dank gut gewählter Voreinstellungen<br />
ist die Konfiguration bei kleineren Projekten<br />
oder einzelnen Servern in der<br />
Tat sehr einfach und belohnt mit einem<br />
sehr hohen Automatisierungsgrad,<br />
erlaubt aber bei komplexen Szenarien<br />
auch das Einbeziehen sehr individueller<br />
Details. Offenbar finden aber auch<br />
Kenner der Software die zahlreichen<br />
Highlights der Software erst, wenn sie<br />
sich eingehender mit ReaR beschäftigen<br />
und sich mit der Funktionsweise<br />
auseinandersetzen.<br />
Das Besondere an ReaR liegt im modularen<br />
Design, der sehr einfachen<br />
Erweiterbarkeit und der Benutzerfreundlichkeit.<br />
Die Firma SEP hat ReaR<br />
sogar als Ersatz für das eigene <strong>Disaster</strong>-<br />
<strong>Recovery</strong>-Tool auserkoren und für die<br />
erforderliche SESAM-Unterstützung in<br />
ReaR gesorgt. Einzelheiten finden sich<br />
in der offiziellen Dokumentation zu<br />
SEP SESAM [8]. Damit ist SEP der erste<br />
kommerzielle Hersteller, der sich offen<br />
zu ReaR bekennt. (ofr) n<br />
n Tabelle 2: Dateien<br />
Datei/Verzeichnis<br />
/usr/sbin/rear<br />
/etc/rear/local.conf<br />
/etc/rear/site.conf<br />
/var/log/rear/<br />
/tmp/rear<br />
/usr/share/rear<br />
/usr/share/rear/conf/default.conf<br />
Funktion<br />
Rear-Tool<br />
Systemspezifische Konfigurationsdatei<br />
Site-spezifische Konfigurationsdatei. Wird nicht per Default angelegt. Kann über andere Deployment-Tools oder<br />
aus anderen RPM-/Debian-Paketen bereitgestellt werden.<br />
Log-Dateien<br />
Temporäres Arbeitsverzeichnis. Muss nach einem Fehler manuell gelöscht werden.<br />
Alle Skript-Komponenten<br />
Kommentierte Standardkonfiguration mit sämtlichen verfügbaren Parametern, die der Admin nach Bedarf in<br />
»local.conf« oder »site.conf« kopieren kann. Hier finden sich unter anderem auch sämtliche »EXCLUDE«-Optionen<br />
zum exakten Festlegen des gewünschten Backup-Umfangs.
Lisa Young, 123RF<br />
<strong>Disaster</strong>-<strong>Recovery</strong> für Windows-Server<br />
Fensterreparatur<br />
Um Windows-Server zu reparieren, gibt es einige Möglichkeiten. Dieser Artikel geht sie durch und verrät<br />
auch, wie man Active Directory und Exchange wiederherstellt. Thomas Joos<br />
Startet ein Server nicht mehr, ist wohlüberlegtes,<br />
aber schnelles Handeln<br />
gefragt. Es gibt einige Möglichkeiten,<br />
Windows-Server schnell und einfach<br />
wieder zum Laufen zu bringen – oder<br />
auch vollends unbrauchbar zu machen.<br />
Generell ist es empfehlenswert, sich in<br />
Testumgebungen auf den Ernstfall vorzubereiten.<br />
Wer mit den Möglichkeiten<br />
vertraut ist, kann im Notfall den Server<br />
schneller wiederherstellen.<br />
Dieser Beitrag zeigt, wie Sie Probleme<br />
mit Windows beheben, wenn das Betriebssystem<br />
nicht mehr startet. Die<br />
Anleitungen sind mit Windows Server<br />
2012 R2 getestet, die meisten Einstellungen<br />
funktionieren auch in den Vorgängerversionen<br />
und mit Windows 7/8.<br />
Dabei erfahren Sie, wie Sie komplette<br />
Server wiederherstellen, virtualisierte<br />
Umgebungen auf Basis von Windows<br />
reparieren und auch Spezialdienste<br />
wie Active Directory wieder zum Laufen<br />
bekommen.<br />
Bootmanager versagt den<br />
Dienst<br />
Startet ein Server nicht mehr, kann<br />
die Ursache dafür auch ein defekter<br />
Bootmanager sein. Ihn können<br />
Sie reparieren, wenn Sie mit einer<br />
Windows-Server-DVD booten und die<br />
Computerreparaturoptionen aufrufen.<br />
In der Befehlszeile stehen verschiedene<br />
Möglichkeiten zur Verfügung, um einen<br />
defekten Bootmanager zu reaktivieren.<br />
Der Befehl »bootrec /fixmbr« schreibt<br />
den Master Boot Record neu an den Anfang<br />
der Festplatte. Mit »bootrec<br />
/scanos« lassen Sie die Betriebssysteme<br />
anzeigen, die aktuell nicht im<br />
Bootmanager eingetragen sind. Der<br />
Befehl »bootrec /rebuildbcd« trägt die<br />
gefundenen Systeme wieder in den<br />
Bootmanager ein. Mit »bootrec /fixboot«<br />
erstellen Sie den Bootmanager<br />
»Bootmgr« neu.<br />
Weitere Befehle, um den Bootmanager<br />
zu reparieren, sind »bootsect /nt60<br />
SYS« und »bootsect /nt60 ALL«. Die<br />
Befehle in diesem Abschnitt können<br />
Sie direkt hintereinander in die Befehlszeile<br />
eingeben. Natürlich ist das<br />
nur sinnvoll, wenn der Bootmanager<br />
nicht mehr funktioniert. Startet der<br />
Server, bricht dann aber ab, ist nicht<br />
der Bootmanager defekt, sondern das<br />
Betriebssystem.<br />
Windows bootet, startet aber<br />
nicht mehr<br />
Manchmal passiert es, dass Windows<br />
nach der Aktualisierung von Treibern<br />
nicht mehr korrekt funktioniert oder<br />
abstürzt. Das gilt für den Server wie für<br />
den Client. In manchen Fällen werden<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
<strong>Disaster</strong>-<strong>Recovery</strong><br />
Windows retten<br />
47<br />
Systemdateien von Windows so zerstört,<br />
dass Windows zwar noch startet,<br />
aber dennoch Fehler erscheinen oder<br />
einige Funktionen nicht mehr richtig<br />
gestartet werden können.<br />
In diesem Fall können Sie entweder zu<br />
einem Systemwiederherstellungspunkt<br />
zurückgehen oder die Computerreparaturoptionen<br />
der Installations-DVD<br />
aufrufen. Wollen Sie Systemdateien<br />
im laufenden Betrieb reparieren, öffnen<br />
Sie eine Eingabeaufforderung mit<br />
Administratorrechten und rufen den<br />
Befehl »sfc /scannow« auf. Windows<br />
scannt wichtige Systemdateien und<br />
stellt sie wieder her, wenn Probleme<br />
auftreten.<br />
Arbeitsspeicher und<br />
Festplatten testen<br />
Windows-Rechner lösen Bluescreens<br />
aus, wenn Hardware im Rechner defekt<br />
ist, zum Beispiel der Arbeitsspeicher.<br />
Deshalb ist es empfehlenswert, vor<br />
einer Software-Reparatur den Speicher<br />
zu testen (Abbildung 1). Um die Ursache<br />
für Bluescreens herauszufinden,<br />
ist die Software BlueScreenView [1]<br />
hilfreich. Das Tool muss nicht installiert<br />
werden und lässt sich auch von einem<br />
USB-Stick aufrufen.<br />
Windows Server 2012 R2 ist standardmäßig<br />
so eingestellt, dass nach einem<br />
Bluescreen der Server automatisch<br />
neu startet. Erscheint der Bluescreen<br />
nach jedem Start, landet der Server in<br />
einer Schleife. Die möglichen Einstellungen,<br />
wie sich Windows nach einem<br />
Bluescreen verhalten soll, finden Sie<br />
unter »Systemsteuerung | System«<br />
und »Sicherheit | System | Erweiterte<br />
Systemeinstellungen«. Klicken Sie im<br />
Abschnitt »Starten und Wiederherstellen«<br />
auf die Schaltfläche »Einstellungen«<br />
(Abbildung 2). Zunächst sollten<br />
Sie die Option »Automatisch Neustart<br />
durchführen« deaktivieren. Über »Debuginformationen<br />
speichern« wählen<br />
Sie aus, welche Art von Informationen<br />
das Betriebssystem speichern soll. Am<br />
besten ist die Variante »Automatisches<br />
Speicherabbild« oder »Kleines Speicherabbild«<br />
geeignet. BlueScreenView<br />
analysiert die Datei »memory.dmp«, die<br />
Windows mit dem Bluescreens erzeugt.<br />
Vermuten Sie einen Fehler auf der<br />
Festplatte, zum Beispiel<br />
wegen klickender<br />
Geräusche und Einträgen<br />
in der Windows-<br />
Ereignisanzeige<br />
(»Windows‐Protokolle<br />
| System«), sollten Sie<br />
die Festplatte und das<br />
Dateisystem testen.<br />
Geben Sie in der Eingabeaufforderung<br />
mit<br />
Administratorrechten<br />
»chkdsk /f /r« ein. Weitergehende<br />
Tests von<br />
Festplatten nehmen<br />
zum Beispiel die kostenlosen Seatools<br />
von Seagate vor. Das Programm testet<br />
die meisten Festplatten auf Fehler,<br />
nicht nur die von Seagate hergestellten.<br />
Sie finden die Seatools und weitere<br />
Informationen zum Retten von<br />
Festplatten auf der Seite [2]. Western<br />
Digital bietet mit Data Lifeguard auf [3]<br />
ebenfalls ein solches Tool an, das auch<br />
als Windows-Anwendung zur Verfügung<br />
steht. Hitachi stellt seine Drive-Fitness-<br />
Tools als ISO-Datei auf der Seite [4] zur<br />
Verfügung.<br />
Kompletten Server<br />
wiederherstellen<br />
Um Windows Server 2012 R2 auf Basis<br />
einer vollständigen Sicherung wiederherzustellen,<br />
müssen Sie nicht auf<br />
Dritthersteller-Software setzen. Wenn<br />
Sie die Windows-Server-Sicherung<br />
über den Server-Manager installieren<br />
und den kompletten Server auf einen<br />
externen Datenträger sichern, können<br />
Sie diesen auf Basis dieser Sicherung<br />
vollständig wiederherstellen.<br />
Um die Windows-Server-Sicherung verwenden<br />
zu können, installieren Sie sie<br />
über den Server-Manager. In Windows<br />
Server 2012 R2 gibt es dazu das Feature<br />
»Windows Server‐Sicherung«. Nach der<br />
Installation starten Sie die Sicherung<br />
über das Menü »Tools« im Server-Manager<br />
mit »Windows Server‐Sicherung«.<br />
Alternativ können Sie auf der Startseite<br />
nach »wbadmin.msc« suchen.<br />
Das Progamm führt eine vollständige<br />
blockbasierte Sicherung der Datenträger<br />
durch. Microsoft empfiehlt zur<br />
Sicherung einen externen Datenträger,<br />
der durch das Sicherungsprogramm<br />
Abbildung 1: Vor einer Reparatur sollten Sie den Arbeitsspeicher eines<br />
Servers testen.<br />
automatisch formatiert wird, sodass<br />
alle bisher darauf gespeicherten Daten<br />
verloren gehen. Einen neuen Auftrag<br />
erstellen Sie über »Aktion | Sicherungszeitplan«.<br />
Bei der benutzerdefinierten<br />
Sicherung wählen Sie aus, welche<br />
Partitionen gesichert werden sollen<br />
(Abbildung 3).<br />
Für Skripte oder Core-Server übernimmt<br />
das Befehlszeilentool »Wbadmin«<br />
die Verwaltung der Sicherungen.<br />
Die wichtigsten Funktionen sind:<br />
n »Wbadmin get versions« zeigt Informationen<br />
über die verfügbaren<br />
Sicherungen an.<br />
n »Wbadmin get status« zeigt den Status<br />
einer laufenden Sicherung oder<br />
Wiederherstellung an.<br />
Abbildung 2: Das Startverhalten von Windows bei<br />
Bluescreens können Sie in der Systemsteuerung<br />
festlegen.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
48<br />
<strong>Disaster</strong>-<strong>Recovery</strong><br />
Windows retten<br />
Abbildung 3: Mit der Datensicherung in Windows Server 2012 R2 können<br />
Sie einen Server vollständig sichern und auch wiederherstellen.<br />
n »Wbadmin start systemstaterecovery«<br />
stellt den Systemstatus wieder<br />
her.<br />
n »Wbadmin start sysrecovery/systemstatebackup«<br />
startet eine vollständige<br />
Systemsicherung, die in den<br />
Computerreparaturoptionen über<br />
die Installations-DVD von Windows<br />
Server 2012 R2 wiederhergestellt<br />
werden kann.<br />
n »wbadmin start backup ‐allCritical<br />
‐backuptarget:Zielfestplatte ‐quiet« –<br />
mit »‐quiet« muss die Eingabe nicht<br />
bestätigt werden – die Sicherung<br />
beginnt dann sofort.<br />
Mit dem folgenden Befehl werden alle<br />
hinterlegten Partitionen in die Sicherung<br />
eingeschlossen:<br />
wbadmin start backup ‐include:U<br />
Partition1:,...,PartitionN U<br />
‐backuptarget:Zielfestplatte: ‐quiet<br />
Die Partitionen werden durch Komma<br />
ohne Leerzeichen voneinander getrennt.<br />
Abbildung 4: Sie können einen Windows-Server auf<br />
Basis der Windows-Sicherung und der Installations-<br />
DVD vollständig wiederherstellen.<br />
Statt mit Wbadmin<br />
können Sie die Datensicherung<br />
auch in der<br />
Powershell steuern.<br />
Der Befehl »Get‐Command<br />
‐Module WindowsServerbackup«<br />
zeigt in Windows Server<br />
2012 R2 die passenden<br />
Commandlets an.<br />
Haben Sie auf dem<br />
Server eine vollständige<br />
Datensicherung<br />
erstellt, können Sie<br />
damit den kompletten<br />
Server wiederherstellen,<br />
falls dieser zum Beispiel nicht mehr<br />
starten kann.<br />
Dazu muss der Datenträger mit der<br />
Sicherung mit dem Server verbunden<br />
und dieser mit der Windows-Server-<br />
2012-R2-DVD gebootet werden.<br />
Auf der Startseite des Installations-Assistenten<br />
klicken Sie auf »Weiter«. Auf<br />
der nächsten Seite wählen Sie »Computerreparaturoptionen«<br />
aus. In den<br />
Systemwiederherstellungsoptionen<br />
wählen Sie die Option zur Wiederherstellung<br />
einer Systemabbildsicherung<br />
aus. Dazu klicken Sie auf »Problembehandlung«<br />
und »Systemimage‐Wiederherstellung«<br />
(Abbildung 4).<br />
Bare-Metal-Restore auf neuer<br />
Hardware<br />
Windows Server 2008 R2 und Windows<br />
Server 2012/2012 R2 unterstützen die<br />
Wiederherstellung einer Systemsicherung<br />
auch auf anderer Hardware. Sie<br />
können im Assistenten auswählen, auf<br />
Basis welcher Sicherung Sie den Server<br />
wiederherstellen wollen. Wichtig ist<br />
dazu, dass Sie die Bare-Metal-Restore-<br />
Möglichkeit bei der Sicherung ausgewählt<br />
haben (Abbildung 5).<br />
Über »Datenträger ausschließen« wählen<br />
Sie die Datenträger aus, die nicht<br />
wiederhergestellt werden sollen, weil<br />
diese zum Beispiel Daten enthalten,<br />
aber keine Betriebssystemdateien.<br />
Mit »Treiber installieren« lassen sich<br />
wichtige Treiber integrieren, die für die<br />
Wiederherstellung benötigt werden. In<br />
den Optionen unter »Erweitert« legen<br />
Sie fest, dass der Server automatisch<br />
nach der Wiederherstellung neu starten<br />
und Datenträger auf Defekte überprüfen<br />
soll.<br />
Active Directory sichern und<br />
wiederherstellen<br />
Die Sicherung von Active Directory erfolgt<br />
zusammen mit der Sicherung von<br />
anderen wichtigen Systemkomponenten<br />
eines Servers. Bei dieser Sicherung,<br />
die auch durch das Windows-eigene<br />
Datensicherungsprogramm durchgeführt<br />
werden kann, werden alle Daten,<br />
die Active Directory benötigt, ebenfalls<br />
gesichert. Aktivieren Sie bei der Sicherung<br />
die Optionen »Systemstatus« und<br />
»System‐reserviert«, damit notwendige<br />
Daten zur Wiederherstellung von<br />
Active Directory mitgesichert werden.<br />
Auch die Bare-Metal-Daten sollten Sie<br />
sichern lassen. Um eine Wiederherstellung<br />
durchzuführen, starten Sie<br />
zunächst den Domänencontroller neu<br />
und drücken direkt nach dem Start die<br />
Taste [F8], bis das Bootmenü erscheint.<br />
Achten Sie aber darauf, dass sich die<br />
Datei, welche die Datensicherung enthält,<br />
lokal auf dem Server befindet,<br />
da sie zur Wiederherstellung benötigt<br />
wird.<br />
Wählen Sie in den Bootoptionen den<br />
Menüpunkt »Verzeichnisdienstwiederherstellung«<br />
aus; anschließend startet<br />
Windows. Melden Sie sich bei der<br />
Anmeldung mit dem Kennwort des Verzeichnisdienstwiederherstellungsmodus<br />
an. Nachdem Sie sich angemeldet<br />
haben, können Sie die Wiederherstellung<br />
durchführen. Es ist auch möglich,<br />
den Verzeichnisdienstwiederherstellungsmodus<br />
über eine RDP-Sitzung oder<br />
mit einem Befehl an der lokalen Konsole<br />
in der Befehlszeile zu aktivieren.<br />
Soll ein Domänencontroller beim<br />
nächsten Mal mit dem Verzeichnisdienstwiederstellungsmodus<br />
gestartet<br />
werden, geben Sie den Befehl »bcdedit<br />
/set safeboot dsrepair« ein. Befindet<br />
sich der Server im Verzeichnisdienstwiederherstellungsmodus,<br />
startet er<br />
mit dem Befehl »bcdedit /deletevalue<br />
safeboot« beim nächsten Mal wieder<br />
normal. So ersparen Sie sich das Drücken<br />
der Taste [F8], wenn Sie sich zum<br />
Beispiel nicht direkt an der Konsole<br />
befinden. Mit dem Befehl »shutdown t 0<br />
‐r« wird der Server dann im konfigurier-<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
<strong>Disaster</strong>-<strong>Recovery</strong><br />
Windows retten<br />
49<br />
ten Modus neu gestartet. Das Betriebssystem<br />
muss in der gleichen Version<br />
wie vor dem Ausfall installiert sein.<br />
Der Weg, einen Domänencontroller einfach<br />
neu in die Domäne aufzunehmen,<br />
statt eine Datensicherung zu verwenden,<br />
ist oft schneller und sauberer. Bereinigen<br />
Sie aber vor der erneuten Aufnahme<br />
in eine Domäne unbedingt die<br />
Metadaten von Active Directory, damit<br />
sichergestellt ist, dass keine veralteten<br />
Daten in Active Directory die erneute<br />
Heraufstufung des Domänencontrollers<br />
verhindern.<br />
Bereinigung von Active<br />
Directory<br />
Wird ein Domänencontroller aus Active<br />
Directory entfernt, sollten Sie einige<br />
Vorbereitungen treffen, damit die Anwender<br />
durch seinen Ausfall nicht betroffen<br />
sind. Stellen Sie sicher, dass der<br />
Domänencontroller nicht als bevorzugter<br />
oder alternativer DNS-Server von<br />
einem anderen Rechner der Domäne<br />
verwendet wird (auch nicht als DNS-<br />
Weiterleitungsserver).<br />
Entfernen Sie – falls möglich – vor der<br />
Herabstufung den DNS-Dienst von<br />
diesem Domänencontroller. Haben Sie<br />
DNS entfernt, überprüfen Sie auf einem<br />
anderen DNS-Server in den Eigenschaften<br />
der DNS-Zone, dass der Server auf<br />
der Registerkarte »Namenserver« nicht<br />
mehr aufgeführt wird. Entfernen Sie<br />
aber nicht den Hosteintrag des Servers,<br />
da er für die Herabstufung noch benötigt<br />
wird.<br />
Stellen Sie sicher, dass der Domänencontroller<br />
nicht an irgendeiner Stelle<br />
als Domänencontroller explizit eingetragen<br />
ist, zum Beispiel auf einem<br />
Linux-Server oder einem Exchange-<br />
Server. Entfernen Sie dann alle Active-<br />
Directory-abhängigen Dienste wie<br />
VPN, Zertifikatsstelle oder andere<br />
Programme, die nach der Herabstufung<br />
nicht mehr funktionieren werden.<br />
Verschieben Sie vor der Herabstufung<br />
zuerst alle FSMO-Rollen auf andere<br />
Server.<br />
Wenn es sich bei diesem Server um<br />
einen globalen Katalog handelt, konfigurieren<br />
Sie einen anderen Server als<br />
globalen Katalog und entfernen Sie im<br />
Snapin »Active Directory‐Standorte‐<br />
und ‐Dienste« unter »Sites | Standort<br />
des Servers | Servername | Eigenschaften«<br />
der NTDS-Settings den Haken bei<br />
»Globaler Katalog«.<br />
Um einen Domänencontroller herunterzustufen,<br />
verwenden Sie am<br />
besten das Powershell-Commandlet<br />
»Uninstall‐ADDSDomainController«<br />
(Abbildung 6). Sie müssen mindestens<br />
noch das lokale Kennwort des Administrators<br />
über den Befehl festlegen.<br />
Dieses müssen Sie als Secure-String in<br />
der Powershell definieren. Die Syntax<br />
dazu lautet:<br />
Uninstall‐ADDSDomainController U<br />
‐LocalAdministratorPassword (Read‐HostU<br />
‐Prompt Kennwort ‐AsSecureString)<br />
Mit »Get‐Help Uninstall‐ADDSDomain-<br />
Controller« erhalten Sie mehr Informationen<br />
zu dem Befehl.<br />
Wenn Sie einen Domänencontroller,<br />
der die Verbindung mit dem Active Directory<br />
verloren hat, nicht neu installieren<br />
wollen, können Sie Active Directory<br />
trotz fehlender Verbindung entfernen.<br />
Verwenden Sie in diesem Fall zusätzlich<br />
die Option »‐force«. Die Metadaten von<br />
Active Directory enthalten alle Einträge<br />
und Servernamen, die zu Active Directory<br />
gehören. Wenn ein Domänencontroller<br />
ausfällt oder erzwungen aus dem<br />
Active Directory entfernt wird, sollten<br />
die Metadaten nachträglich bereinigt<br />
werden.<br />
Für diese Bereinigung benötigen Sie<br />
das Befehlszeilentool »Ntdsutil« (Abbildung<br />
7). Um die Metadaten von Active<br />
Directory zu bereinigen, starten Sie zunächst<br />
»Ntdsutil« in der Eingabeaufforderung<br />
und geben »metadata cleanup«<br />
ein, gefolgt von »connections«. Verbinden<br />
Sie sich per »connect to server<br />
Domänencontroller« mit dem Domain<br />
Controller und geben Sie »quit« ein, um<br />
wieder zum Menü »metadata cleanup«<br />
zurückzugelangen.<br />
Geben Sie »select operation target« und<br />
»list domains« ein, dann sehen Sie alle<br />
Abbildung 5: Im Assistenten zur Wiederherstellung<br />
wählen Sie den Sicherungssatz aus, auf dessen Basis<br />
die Sicherung den Server wiederherstellen soll.<br />
Domänen der Gesamtstruktur. Wählen<br />
Sie mit »select domain Nummer der Domäne«<br />
die Nummer der Domäne aus,<br />
von der Sie einen Domänencontroller<br />
entfernen wollen. Mit »list sites« erhalten<br />
Sie alle Standorte der Gesamtstruktur,<br />
von denen Sie einen mit »select site<br />
Nummer des Standorts« auswählen.<br />
Über »list servers in site« sehen Sie alle<br />
Domänencontroller, die diesem Standort<br />
zugeordnet sind. Der Befehl »select<br />
server Nummer des Servers« entfernt<br />
einen Server aus der Domäne.<br />
Geben Sie »quit« ein, um wieder zum<br />
Menü »metadata cleanup« zurückzukehren.<br />
Mit »remove selected server«<br />
wird der Server nach einer Bestätigung<br />
entfernt.<br />
Nachdem die Metadaten von Active<br />
Directory bereinigt wurden, sollten Sie<br />
noch die Einträge im DNS aufräumen.<br />
Entfernen Sie alle SRV-Records, in<br />
denen noch der alte Server steht, aus<br />
der DNS-Zone der Domäne. Danach<br />
können Sie das Computerkonto des<br />
Servers löschen. Löschen Sie das Konto<br />
aus der OU »Domain Controllers« im<br />
Snapin »Active Directory‐Benutzer und<br />
‐Computer«.<br />
Im nächsten Schritt müssen Sie den Domänencontroller<br />
noch aus dem Standort<br />
löschen, dem er zugeordnet war.<br />
Abbildung 6: Domänencontroller lassen sich auch in der Powershell herunterstufen.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
50<br />
<strong>Disaster</strong>-<strong>Recovery</strong><br />
Windows retten<br />
Abbildung 7: Funktioniert ein Domänencontroller nicht mehr, entfernen<br />
Sie ihn aus der Domäne und installieren ihn neu. Das geht meistens<br />
schneller als eine Wiederherstellung.<br />
Abbildung 8: Mit der Windows-Server-Sicherung können Sie auch<br />
Exchange-Datenbanken wiederherstellen.<br />
n Info<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31697<br />
[1] BlueScreenView: [http:// www. nirsoft. net/<br />
utils/ blue_screen_view. html]<br />
[2] Seatools: [http:// www. seagate. com/ www/<br />
de‐de/ support/ downloads/ seatools]<br />
[3] Data Lifeguard Diagnostic: [http:// support.<br />
wdc. com/ product/ download. asp?<br />
groupid=810& sid=3& lang=en]<br />
[4] Drive-Fitness-Tools: [http:// www.<br />
hgst. com/ support/ index‐files/<br />
simpletech‐legacy‐downloads# DFT]<br />
Verwenden Sie dazu<br />
das Snapin »Active<br />
Directory‐Standorte<br />
und ‐Dienste«. Navigieren<br />
Sie zum Standort<br />
des Domänencontrollers,<br />
wählen Sie<br />
im zugehörigen Kontextmenü<br />
den Befehl<br />
»Löschen« aus oder<br />
drücken Sie die [Entf]-<br />
Taste. Überprüfen Sie<br />
als nächstes in den<br />
NTDS-Settings jedes<br />
Domänencontrollers in<br />
Active Directory, ob der<br />
Domänencon troller<br />
noch als Replikationspartner<br />
eingetragen<br />
ist, und entfernen Sie<br />
in diesem Fall die Verbindung.<br />
Reparieren der<br />
AD-Datenbank<br />
Unter manchen<br />
Umständen kann es<br />
vorkommen, dass<br />
die Active-Directory-<br />
Datenbank nicht mehr<br />
funktioniert. Bevor Sie<br />
einen Domänencontroller<br />
neu installieren,<br />
können Sie versuchen, die AD-Datenbank<br />
zu reparieren. Starten Sie dazu<br />
den Server im Verzeichnisdienstwiederherstellungsmodus<br />
und rufen Sie<br />
»Ntdsutil« auf. Geben Sie »activate instance<br />
ntds« ein, dann »files«; es startet<br />
die »file maintenance«. Dort geben Sie<br />
»integrity« ein und verlassen mit »quit«<br />
die »file maintenance«.<br />
Die Datenbankanalyse startet der<br />
Befehl »semantic database analysis«.<br />
Einen ausführlichen Report schaltet<br />
»verbose on« ein. Geben Sie »go fixup«<br />
ein, dann startet das Tool die Diagnose<br />
und repariert auf Wunsch die<br />
Datenbank. Verlassen Sie im Anschluss<br />
Ntdsutil und starten Sie den Domänencontroller<br />
neu.<br />
Exchange-Datensicherung<br />
Sichern Sie Exchange 2013 mit dem<br />
internen Sicherungs-Assistenten in<br />
Windows Server 2008 R2/2012, sichert<br />
das Programm auch die Exchange-Datenbanken.<br />
Das Sicherungsprogramm<br />
unterstützt auch die Onlinesicherung<br />
der Exchange-Datenbanken. Während<br />
der Sicherung führt das Sicherungsprogramm<br />
eine Konsistenzprüfung<br />
der Exchange-Dateien durch. Erst bei<br />
einer Wiederherstellung können Sie die<br />
Exchange-Datenbanken auswählen.<br />
Eine Wiederherstellung starten Sie im<br />
Sicherungsprogramm über das Menü<br />
»Aktion«. Auch hier führt ein Assistent<br />
durch die einzelnen Schritte der Wiederherstellung.<br />
Wählen Sie den lokalen<br />
Server für die Wiederherstellung aus.<br />
Während der Wiederherstellung hebt<br />
der Sicherungs-Assistent die Bereitstellung<br />
der Datenbank, die Sie wiederherstellen,<br />
selbstständig auf und stellt<br />
diese nach der Sicherung wieder bereit.<br />
Legen Sie das Datum sowie die Uhrzeit<br />
der wiederherzustellenden Sicherung<br />
fest und wählen Sie als »Wiederherstellungstyp«<br />
die Option »Anwendungen«<br />
aus (Abbildung 8).<br />
Auf der nächsten Seite muss bei »Anwendungen«<br />
die Option »Exchange«<br />
aufgelistet sein. Dann ist sichergestellt,<br />
dass eine Exchange-taugliche Sicherung<br />
vorhanden ist. Klicken Sie auf »Details<br />
anzeigen«, um sich die gesicherten<br />
Exchange-Datenbanken anzeigen zu<br />
lassen.<br />
Handelt es sich bei der Sicherung um<br />
die aktuelle Version der Sicherung,<br />
erscheint das Kontrollkästchen »Keine<br />
Rollforward‐Wiederherstellung der<br />
Anwendungsdatenbanken ausführen«.<br />
Für eine Rollforward-Wiederherstellung<br />
benötigen Sie Transaktionsprotokolle,<br />
die nach der Sicherung erstellt wurden.<br />
Diese schreibt Exchange anschließend<br />
in die Datenbank, um die Wiederherstellung<br />
zu vervollständigen. Aktivieren<br />
Sie die Option »Am ursprünglichen<br />
Speicherort wiederherstellen«, stellt<br />
das Sicherungsprogramm alle gesicherten<br />
Datenbanken am Ursprungsort<br />
wieder her.<br />
Nach der Wiederherstellung können<br />
Sie die Datendateien in eine Wiederherstellungsdatenbank<br />
integrieren und<br />
danach manuell wieder an ihren ursprünglichen<br />
Speicherort verschieben<br />
oder einzelne Daten aus der Sicherung<br />
herstellen. (ofr) n<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Dmitry Kalinovsky, 123RF<br />
Backup und <strong>Recovery</strong> bei Datenbanken: Woran man denken sollte<br />
Rettungsübung<br />
Datenbank-Backups sind mittlerweile Standard. Doch um nach einem Crash rasch wieder zu einem<br />
stabilen Produktivbetrieb zurückzukehren, muss das <strong>Disaster</strong> <strong>Recovery</strong> sorgfältig geplant und eingeübt<br />
sein. Sonst besteht die Gefahr, dass Wichtiges vergessen wird. Pierre Strohmeier<br />
n Autor<br />
Gerade in einer größeren Umgebung<br />
stellt die vollständige Wiederherstellung<br />
einer Datenbank oft eine Herausforderung<br />
dar, die zudem nicht wenig<br />
Zeit beansprucht. Die richtige Planung<br />
des Datenbank-Backups ist dabei ein<br />
wesentlicher Faktor, um Zeit zu sparen<br />
und die Kosten einer ungeplanten<br />
Peter Strohmeier arbeitet als Datenbankadministrator<br />
für PostgreSQL bei der 25th-floor de Pretis<br />
& Helmberger KG, einem seit 2004 existierenden<br />
Full-Service-Dienstleister für komplexe IT-Lösungen<br />
basierend auf Open-Source-Technologien mit Sitz in<br />
der österreichischen Hauptstadt Wien.<br />
Downtime zu minimieren. Unabhängig<br />
von der Hardware spielen die folgenden<br />
Fragen eine wichtige Rolle bei der<br />
Planung des Backups:<br />
n Wie stark belastet das Backup das<br />
System?<br />
n Wie lange dauert ein vollständiges<br />
Backup?<br />
n Wie groß darf der Datenverlust maximal<br />
sein (<strong>Recovery</strong> Point Objective<br />
– RPO)?<br />
n Wie lange dauert ein <strong>Recovery</strong>? Wie<br />
lange darf ein System oder Prozess<br />
stillstehen (<strong>Recovery</strong> Time Objective<br />
– RTO)?<br />
n Was muss neben Standard-Backups<br />
noch beachtet werden?<br />
n Wie validiere ich die Vollständigkeit<br />
und Funktionsweise nach der Wiederherstellung?<br />
n Wie sicher ist die gewählte Backup-<br />
Variante?<br />
Qual der Wahl<br />
Um Datenverlust und Systembelastung<br />
entgegenzuwirken, ist vor allem die<br />
richtige Wahl der Backup-Variante ausschlaggebend.<br />
Je nach Anwendungsfall<br />
muss man sich entscheiden, ob man<br />
physische oder logische Backups bevorzugt<br />
oder auch beides zeitgleich<br />
benutzen möchte. Grundlegend unterscheiden<br />
sich die beiden Varianten<br />
vor allem in der Größe und Dauer der<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
<strong>Disaster</strong>-<strong>Recovery</strong><br />
Datenbank-<strong>Recovery</strong><br />
53<br />
jeweiligen Backups. Gerade das ist<br />
meist ausschlaggebend dafür, wie viel<br />
I/O und Netzwerklast durch das Backup<br />
verursacht wird.<br />
Beim physischen Ansatz werden die<br />
Daten von den Platten blockweise auf<br />
ein Sicherungsmedium kopiert (Binary<br />
Backup). Diese Backup-Variante benötigt<br />
nicht zwangsweise eine Verbindung<br />
zur Datenbank und belastet das System<br />
anders als ein logisches Backup.<br />
Wichtig: Werden physische Backups<br />
bei laufender Datenbank angefertigt,<br />
sind sie zwangsläufig nicht konsistent.<br />
Um bei der Wiederherstellung zu einem<br />
konsistenten Stand zu gelangen, muss<br />
der Datenbank bekannt sein, welche<br />
Änderungen während und nach dem<br />
Backup angefallen sind. Diese Information<br />
speichern Datenbanken üblicherweise<br />
in Logdateien, die ebenfalls archiviert<br />
werden (Beispiele: PostgreSQL,<br />
SQLite – WAL (Write-Ahead-Log), Oracle<br />
– Redo Logs). Bei der Wiederherstellung<br />
werden die archivierten Logdateien<br />
eingespielt, wodurch letztendlich ein<br />
konsistenter Stand erreicht wird. Die<br />
Wiederherstellung kann auch nur bis zu<br />
einem bestimmten Zeitpunkt erfolgen<br />
(Point-In-Time-<strong>Recovery</strong>, PITR) – das ist<br />
vor allem bei Benutzerfehlern ein wichtiges<br />
Mittel, um Daten zu retten.<br />
Diese Möglichkeit ist oft auch die<br />
Grundlage für Standby-Datenbanken,<br />
die kontinuierlich im <strong>Recovery</strong>-Modus<br />
laufen und die anfallenden Logdateien<br />
immer wieder einlesen (Abbildung 1).<br />
Generell gilt: Umso mehr dieser Änderungen<br />
eingespielt werden müssen,<br />
desto länger dauert es, den gewünschten<br />
Datenstand zu erreichen.<br />
Logische Backups haben dagegen<br />
den Vorteil, dass damit auch partielle<br />
Backups möglich sind, bei denen zum<br />
Beispiel nur bestimmte Tabellen gesichert<br />
werden. Beim logischen Backup<br />
werden generell anstelle von Plattensektoren<br />
Datenbankobjekte mit ihrem<br />
Inhalt und relationalem Zusammenhang<br />
gesichert. Zudem werden im Gegensatz<br />
zu physischen Backups keine<br />
Indexdaten archiviert, sondern nur die<br />
Statements, die zum Anlegen der Indizes<br />
notwendig sind – was Backups zwar<br />
wesentlich kleiner macht, aber beim<br />
Wiederherstellen viel Zeit kostet.<br />
Abbildung 1: Standby-Datenbanken führen die Logs ihrer Master-Datenbank kontinuierlich nach.<br />
Bei Datenbanksystemen mit Multiversion<br />
Concurrency Control (MCC<br />
oder MVCC) kann sich im Laufe der Zeit<br />
unverwendeter Platz in der Datenbank<br />
ansammeln (Bloat oder Garbage genannt).<br />
Die Wiederherstellung größerer<br />
Datenbanken profitiert daher oftmals<br />
von logischen Backups, weil bei ihnen<br />
große Teile dieses unverwendeten<br />
Platz es nicht gesichert werden. Physische<br />
Backups, die genaue 1:1-Kopien<br />
des Originals sind, beziehen diesen<br />
Platz dagegen ein.<br />
Eine weitere Überlegung betrifft inkrementelle<br />
Backups. Man unterscheidet<br />
dabei zwischen differenziellen- und<br />
kumulativen Backups. Differenzielle<br />
Backups bauen seit dem letzten Voll-<br />
Backup beziehungsweise dem letzten<br />
differenziellen Backup aufeinander auf<br />
(Abbildung 2), wogegen kumulative<br />
Backups sämtliche Änderungen seit<br />
dem letzten Voll-Backup enthalten.<br />
Hierbei wird das Backup mit wachsendem<br />
Zeitabstand immer umfangreicher,<br />
allerdings braucht man dafür nur<br />
das jüngste aufzubewahren (Abbildung<br />
3). Inkrementelle Backups wirken sich<br />
auch wesentlich auf die Wiederherstellungsdauer<br />
aus, da man im Falle eines<br />
Crashs zuerst ein Voll-Backup und anschließend<br />
sämtliche inkrementellen<br />
Backups bis zum gewünschten Zeitpunkt<br />
einspielen muss.<br />
Jedes Datenbanksystem verfolgt beim<br />
Thema Backup unterschiedliche Ansätze.<br />
PostgreSQL [1] bringt beispielsweise<br />
erst ab Version 9.1.X das »pg_<br />
basebackup«-Tool mit, das physische<br />
Backups und Replikation erleichtert,<br />
kennt jedoch noch keine Umsetzung<br />
von inkrementellen oder differenziellen<br />
Backups. Bei Oracle [2] hingegen kann<br />
man via RMAN (Oracles <strong>Recovery</strong> Manager)<br />
sowohl Voll-Backups als auch<br />
inkrementelle Backups ziehen.<br />
Replikation bei Datenbanken<br />
Um mehr Ausfallsicherheit zu erzielen,<br />
gibt es auch die Möglichkeit der<br />
kontinuierlichen (synchronen oder<br />
asynchronen) Datenbank-Replikation.<br />
Manche Systeme erlauben es, eine<br />
Standby-Datenbank etwa über die<br />
zuvor erwähnten Logdateien auf aktuellem<br />
Stand zu halten. Eine so aufgesetzte<br />
Standby-Datenbank befindet<br />
sich ununterbrochen im Wiederherstellungsmodus<br />
und versucht dauerhaft<br />
einlaufende Änderungen bei sich nachzuziehen.<br />
Hot-Standby-Instanzen können darüber<br />
hinaus verwendet werden, um<br />
lesende Prozesse (etwa ein Reporting<br />
oder wiederum Backups) auszulagern<br />
und somit I/O- und CPU-Last zu verteilen,<br />
sprich eine Art von Loadbalancing<br />
zu erreichen.<br />
Falls es zu einem Problem bei der<br />
Master-Instanz kommen sollte, kann<br />
man später die Standby-Datenbank<br />
zum Master ernennen (promoten)<br />
und erspart sich dadurch das erneute<br />
Aufsetzen einer Datenbank samt Wiederherstellung<br />
der Daten, woraus eine<br />
große Zeitersparnis resultieren kann.<br />
Allerdings besteht der nächste logische<br />
Schritt dann natürlich darin, wieder<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
54<br />
<strong>Disaster</strong>-<strong>Recovery</strong><br />
Datenbank-<strong>Recovery</strong><br />
Änderungen<br />
Änderungen<br />
Tag 3<br />
Tag 2<br />
Tag 1<br />
Voll-<br />
Backup<br />
eine Standby-Instanz aufzusetzen,<br />
damit die neu ernannte Master-Instanz<br />
nicht die komplette Schreib- und Leselast<br />
verarbeiten muss. Daraus lässt sich<br />
ableiten, dass Standby-Systeme auch<br />
Hardware-seitig hierfür ausgelegt sein<br />
müssen, die komplette anfallende Systemlast<br />
zu schultern.<br />
Im Zuge eines Failovers müssen auch<br />
die eingehenden Verbindungen auf die<br />
mittlerweile als Master-Instanz betriebene<br />
ehemalige Standby-Datenbank<br />
umgeleitet werden. Dies kann sowohl<br />
via Cluster-Manager (etwa via Pacemaker<br />
[3] und Corosync [4]), aber auch<br />
mit Bordmitteln und/oder Middleware<br />
passieren.<br />
Im Falle eines versehentlich abgesetzten<br />
Statements – etwa eines UPDATE<br />
ohne WHERE-Klausel oder eines TRUN-<br />
CATE am falschen Host – kann es zu einer<br />
unangenehmen Situation kommen,<br />
wenn das Statement das Standby-<br />
System erreicht hat, bevor das Problem<br />
Tag 3<br />
Tag 2<br />
Tag 1<br />
Voll-<br />
Backup<br />
Differenzielle Backups<br />
differenziell<br />
T1<br />
Kumulative Backups<br />
kumulativ<br />
(T1)<br />
differenziell<br />
T2<br />
differenziell<br />
T1<br />
erkannt wurde. In diesem Fall würde<br />
der Fehler die Daten auf beiden Seiten<br />
korrumpieren. Aus diesem Grund kann<br />
es sinnvoll sein, eine zeitlich versetzte<br />
Standby-Datenbank zu verwenden, die<br />
Änderungen erst nach einer bestimmten<br />
Zeit verarbeitet.<br />
Vor allem synchrone Replikation kann<br />
das System aber auch schwer belasten.<br />
Auf der Netzwerkseite kann das<br />
Replizieren der Datenbankänderungen<br />
einen beachtlichen Teil der verfügbaren<br />
Bandbreite beanspruchen. Die Belastung<br />
kann hier sehr variieren, je nachdem<br />
wie viel in die Datenbank geschrieben<br />
wird. Auch die Query-Performance<br />
kann darunter leiden, wenn nach<br />
jedem COMMIT gewartet werden muss,<br />
bis alle Standby-Instanzen die Änderungen<br />
bei sich nachgezogen haben<br />
und auf einem synchronen Stand sind.<br />
Dies ist zwar bei asynchronen Setups<br />
nicht der Fall, jedoch sollte man bedenken,<br />
dass dort die Standby-Datenbank<br />
kumulativ<br />
(T1+T2)<br />
differenziell<br />
T3<br />
differenziell<br />
T2<br />
differenziell<br />
T1<br />
kumulativ<br />
(T1+T2+T3)<br />
differenziell<br />
T3<br />
differenziell<br />
T2<br />
differenziell<br />
T1<br />
Voll-<br />
Backup<br />
Daten Tag 1 Tag 2 Tag 3 <strong>Recovery</strong><br />
Abbildung 2: Das Prinzip differenzieller Backups: Beim <strong>Recovery</strong> muss man alle Vorläufer in richtiger<br />
Reihenfolge einspielen. Dafür bleibt jedes Backup klein.<br />
kumulativ<br />
(T1+T2+T3)<br />
Voll-<br />
Backup<br />
Daten Tag 1 Tag 2 Tag 3 <strong>Recovery</strong><br />
Abbildung 3: So funktionieren kumulative Backups: Sie wachsen stetig, dafür braucht man immer<br />
nur das Letzte.<br />
gegebenenfalls keinen aktuellen Datenstand<br />
bereitstellt und zeitlich zurückliegt.<br />
Das wiederum kann auf Seiten<br />
der Applikation zu Ungereimtheiten<br />
und Problemen führen.<br />
Oracle bietet hier als Feature den<br />
Oracle RAC (Oracle Real Application<br />
Cluster [5]), der sowohl Connection<br />
Pooling und Failover als auch Loadbalancing<br />
im Cluster-Umfeld ermöglicht.<br />
Oracle Active Data Guard [6] ist ebenso<br />
weit verbreitet.<br />
Bei PostgreSQL kann man ein physisches<br />
Backup unter anderem via »pg_<br />
basebackup« (ab Version 9.1.X) herstellen<br />
und auch eine Standby-Datenbank<br />
sowie eine Streaming-Replication<br />
damit einrichten [7]. Mit einer Middleware<br />
wie PgBouncer [8] oder Pgpool-<br />
II [9] ist auch Connection Pooling/<br />
Failover möglich. Für Multimaster- und<br />
Multislave-Systeme können hier Tools<br />
wie Bucardo [10] oder Postgres-XC [11]<br />
verwendet werden. MySQL bietet unter<br />
anderem im Enterprise-Umfeld MySQL-<br />
Replication [12] als auch MySQL-Cluster<br />
[13]. Eine Alternative wäre hier der<br />
Tungsten Replicator [14]. Zudem kann<br />
man auch auf Percona und deren Percona<br />
XtraDB Cluster (Dropin-Re placement<br />
zu InnoDB/MySQL [15]) samt<br />
Percona XtraBackup ausweichen.<br />
Backup everything?<br />
Unabhängig von der gewählten<br />
Backup-Variante sollte man sich vergewissern,<br />
was alles notwendig ist, um<br />
nach einem Crash mit möglichst geringem<br />
Datenverlust in möglichst kurzer<br />
Zeit wieder in Produktion gehen zu<br />
können. In Standard-Backups von Datenbanken<br />
muss nicht zwingend alles<br />
Notwendige für eine komplette Wiederherstellung<br />
enthalten sein!<br />
Bei PostgreSQL landen beispielsweise<br />
Konfigurationsdateien wie »postgresql.<br />
conf« (Hauptkonfiguration), »pg_hba.<br />
conf« und »pg_ident.conf« (Client-<br />
Authentifizierung), die relevant für das<br />
Datenbanksystem sind, weder in logischen<br />
noch automatisch in physischen<br />
Backups. Bei physischen Backups<br />
hängt es davon ab, ob die Dateien im<br />
Basis-Verzeichnis liegen, was wiederum<br />
abhängig davon ist, wie PostgreSQL<br />
installiert wurde.<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
<strong>Disaster</strong>-<strong>Recovery</strong><br />
Datenbank-<strong>Recovery</strong><br />
55<br />
Betreibt man sowohl Produktions- als<br />
auch Entwicklungsumgebungen im<br />
gleichen Cluster, liegt es durchaus<br />
nahe, den klassischen Ansatz zu verfolgen<br />
und Backups via »pg_dump« zu<br />
ziehen, um nur den Produktionsstand<br />
zu sichern und um das Backup nicht<br />
unnötig zu vergrößern.<br />
Unvollständige Sicherung<br />
Im Falle eines Crashs kann dann jedoch<br />
leicht Wichtiges vergessen oder<br />
nicht bedacht werden. Etwa, dass<br />
»pg_dump« keine globalen Objekte<br />
sichert (Rollen/User, Dictionaries und<br />
so weiter). Generell werden in so einem<br />
Backup nur datenbankbezogene<br />
Elemente gespeichert, aber einige im<br />
Backup enthaltene Teile könnten auf<br />
globale Elemente zugreifen wollen, die<br />
im <strong>Recovery</strong> fehlen (Shared Objects,<br />
Extensions und so weiter).<br />
Um solche Fälle auszuschließen, sollte<br />
man im Vorhinein einige Vorkehrungen<br />
treffen. Mit pg_dumpall [16] und der<br />
Option »‐‐globals‐only« lassen sich<br />
Rollen und User sichern. Die resultierende<br />
Datei muss eigens gespeichert<br />
werden. Generell muss man sich auf<br />
die Gegebenheiten des verwendeten<br />
Datenbanksystems einstellen, Oracle<br />
unterscheidet sich diesbezüglich sehr<br />
von PostgreSQL und MySQL.<br />
Man sollte sichergehen, dass sämtliche<br />
in den Konfigurationsdateien definierte<br />
Pfade im <strong>Recovery</strong>-System vorhanden<br />
sind und/oder entsprechende Anpassungen<br />
treffen. Denn es kann schnell zu<br />
schwerwiegenden Problemen führen,<br />
wenn etwa Tablespaces nicht verwendet<br />
oder angelegt werden können.<br />
Auch nicht gesetzte Kernel-Parameter<br />
sind oft der Grund dafür, warum sich<br />
eine Datenbank nach dem <strong>Recovery</strong><br />
nicht starten lässt. Möglicherweise<br />
steht dadurch dann zum Beispiel zu<br />
wenig Shared Memory zur Verfügung.<br />
Umständlich kann es auch werden,<br />
wenn die Datenbank in einem falschen<br />
oder unpassenden Locale/Encoding<br />
aufgesetzt wurde.<br />
Konfigurationsdateien, die nicht in den<br />
Backups enthalten sind, können mittels<br />
Tools wie »svn«, »git« und »etckeeper«<br />
[17] versioniert werden. Dadurch lassen<br />
sich zwei Fliegen mit einer Klappe<br />
schlagen, denn die Dateien werden<br />
nicht nur gesichert, sondern die Anpassungen<br />
können durch die Versionierung<br />
zeitlich verfolgt werden.<br />
Ein wichtiger Punkt ist auch, vergleichbare<br />
(oder im besten Fall: die gleiche)<br />
Hardware für das wiederhergestellte<br />
System zu verwenden. Die für das<br />
neue Datenbanksystem verwendete<br />
Software-Version sollte außerdem<br />
nicht allzusehr von der des Originals<br />
abweichen. Vor allem bei physischen<br />
Backups können unterschiedliche Datenbankversionen<br />
schnell zu Inkompatibilitäten<br />
führen. Verwendet man logische<br />
Backups, sollte sich zwar zwischen
56<br />
<strong>Disaster</strong>-<strong>Recovery</strong><br />
Datenbank-<strong>Recovery</strong><br />
n Info<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31742<br />
[1] PostgreSQL: [http:// www. postgresql. org]<br />
[2] Oracle: [http:// www. oracle. com/<br />
technetwork/ database/ features/ availability/<br />
rman‐overview‐096633. html]<br />
[3] Pacemaker: [http:// clusterlabs. org]<br />
[4] Corosync:<br />
[http:// corosync. github. io/ corosync]<br />
[5] RAC: [http:// www. oracle. com/ us/ products/<br />
database/ options/ real‐application‐clusters/<br />
overview/ index. html]<br />
[6] Oracle Active Data Guard:<br />
[http:// www. oracle. com/ technetwork/<br />
database/ features/ availability/<br />
dataguardoverview‐083155. html]<br />
[7] PostgreSQL-HA: [http:// www. postgresql. org/<br />
docs/ current/ static/ high‐availability. html]<br />
[8] PgBouncer: [http:// pgfoundry. org/ projects/<br />
pgbouncer]<br />
[9] Pgpool-II: [http:// www. pgpool. net)]<br />
[10] Bucardo: [http:// bucardo. org/ wiki/ Bucardo]<br />
[11] Postgres-XC: [http:// sourceforge. net/ projects/<br />
postgres‐xc]<br />
[12] MySQL-Replication: [http:// www. mysql. com/<br />
products/ enterprise/ replication. html]<br />
[13] MySQL-Cluster: [http:// dev. mysql. com/ doc/<br />
index‐cluster. html]<br />
[14] Tungsten Replicator: [https:// code. google.<br />
com/ p/ tungsten‐replicator/]<br />
[15] Percona XtraDB Cluster: [http:// www. percona.<br />
com/ software/ percona‐xtradb‐cluster]<br />
[16] Pg_dumpall: [http:// www. postgresql. org/<br />
docs/ current/ static/ app‐pg‐dumpall. html]<br />
[17] Etckeeper:<br />
[https:// github. com/ joeyh/ etckeeper]<br />
[18] Oracle-Backup verifizieren: [http:// docs. oracle.<br />
com/ cd/ B28359_01/ backup. 111/ b28270/<br />
rcmvalid. htm]<br />
[19] PgTAP:<br />
[http:// pgtap. org/ documentation. html]<br />
[20] Oracle-Ausführungspläne verwalten:<br />
[http:// docs. oracle. com/ cd/ B28359_01/<br />
server. 111/ b28274/ optplanmgmt. htm]<br />
[21] Pg_statements: [http:// www. postgresql. org/<br />
docs/ current/ static/ pgstatstatements. html]<br />
[22] Pg_stat_plans: [https:// github. com/<br />
2ndQuadrant/ pg_stat_plans]<br />
Minor-Upgrades nichts Grundlegendes<br />
ändern, aber vor einem Umstieg auf<br />
die nächste Major-Version, sollte man<br />
(gerade im Falle von <strong>Disaster</strong> <strong>Recovery</strong>)<br />
kein Risiko eingehen. Zumindest muss<br />
der Umstieg zuvor ausführlich getestet<br />
worden ein.<br />
Recovern üben<br />
Um wirklich auf Nummer sicher zu<br />
gehen, sollte (zumindest einmal) ein<br />
komplettes <strong>Disaster</strong> <strong>Recovery</strong> mit dem<br />
Aufsetzen der Datenbank übungshalber<br />
geplant, durchgespielt und dokumentiert<br />
werden. Schließlich ist nichts<br />
unangenehmer, als erst im Ernstfall<br />
festzustellen, dass doch nicht alles<br />
Notwendige bedacht wurde und man<br />
nun entweder vor einem inkonsistenten<br />
oder neuen Datenbank-Setup<br />
steht oder es gar nicht erst zum Laufen<br />
bekommt. Regelmäßige Übungen und<br />
Testläufe helfen hier sehr!<br />
Mit Letzteren testet man gleichzeitig<br />
Backups: Fehlen Inhalte? Sind womöglich<br />
Blöcke defekt? Oracle bietet<br />
in diesem Kontext zur Überprüfung<br />
von Backups auf defekte Blöcke oder<br />
fehlende Dateien etliche Optionen via<br />
Oracle RMAN [18].<br />
Nach einer erfolgreichen Inbetriebnahme<br />
des Datenbanksystems samt<br />
Wiederherstellung der Daten steht immer<br />
noch die Frage im Raum, ob alles<br />
wieder normal läuft und voll funktionsfähig<br />
ist. Gerade das ist meist gar nicht<br />
so einfach zu beantworten …<br />
Monitoring hilft<br />
<strong>Erste</strong> Ansätze bietet ein genaues I/Ound<br />
CPU-Load-Monitoring des Servers,<br />
wobei man hier die aktuellen Werte mit<br />
den Werten des zuvor vorhandenen<br />
Setups vergleichen sollte. Bestenfalls<br />
kann man sogar auf ein Test-Setup zurückgreifen,<br />
das produktionsnahe Situationen<br />
simulieren oder reproduzieren<br />
kann. Auch Unit-Tests der Applikationen,<br />
die die Datenbank verwenden,<br />
und Tools zum Testen der Datenbank<br />
an sich – wie PgTAP [19] – sind oft sehr<br />
wertvoll, sofern sie gefahrlos auf ein<br />
Produktionssystem angewendet werden<br />
können. Automatisiertes Monitoring<br />
der Datenbanklogs (wie des Oracle<br />
Alert Log) sollte man generell nutzen<br />
und natürlich gerade in solchen Situationen<br />
genau beachten.<br />
Zudem empfiehlt es sich unbedingt,<br />
nach jeder Wiederherstellung auch<br />
interne Statistiken der Datenbank zu<br />
überprüfen und gegebenenfalls zu<br />
aktualisieren. Sie werden oft für Query-<br />
Planer verwendet, um den effizientesten<br />
Weg für die Ausführung eines Statements<br />
zu kalkulieren. Via PL/PGSQL-<br />
Packages bei Oracle (»DBMS_STATS«)<br />
oder etwa »ANALYZE« bei PostgreSQL<br />
lassen sich interne Informationen zu<br />
Tabellen und Indizes neu sammeln und<br />
Statistiken auf den neuesten Stand<br />
bringen.<br />
Zusätzlich zu Query-Plänen sollten<br />
auch durchschnittliche Query-Laufzeiten<br />
genauer unter die Lupe genommen<br />
werden (»EXPLAIN«, »EXPLAIN PLAN«<br />
und ähnliche Kommandos), denn es<br />
könnte durchaus der Fall sein, dass<br />
sich hier etwas geändert hat. Verliert<br />
beispielsweise ein Index oder eine Tabelle<br />
nach dem Wiederherstellen etwas<br />
an Größe (Bloat), so kann es durchaus<br />
sein, dass der Query-Planer einen anderen<br />
Weg vorschlägt und lieber einen<br />
anderen Index in Betracht zieht oder<br />
sogar dazu tendiert, stattdessen gleich<br />
die gesamte Tabelle zu lesen. Das kann<br />
sich gravierend auf die Laufzeiten auswirken.<br />
Je komplexer die Query, umso<br />
eher kann sich die Ausführung ändern.<br />
Datenbank-Tools, die Statistiken über<br />
Query-Laufzeiten und/oder ‐Pläne<br />
führen, können hierbei sehr hilfreich<br />
sein. Bei manchen Datenbanken sind<br />
sie von Haus aus integriert. Oracle<br />
bietet beispielsweisde diverse Tools,<br />
um SQL-Pläne zu managen [20]. Auch<br />
PostgreSQL liefert zusätzliche Informationen<br />
über Query-Laufzeiten (»pg_<br />
stat_statements« [21]) und ‐Pläne [22]<br />
via Extensions. Letztendlich darf man<br />
auch nicht vergessen, dass neu aufgesetzte<br />
Systeme eine gewisse Anlaufzeit<br />
brauchen, um wieder warm zu werden.<br />
So kann es durchaus etwas dauern,<br />
bis alle heißen Daten wieder im RAM<br />
gelandet sind.<br />
Zusammenfassend lässt sich nur sagen:<br />
Umso öfter Backups wiederhergestellt<br />
und getestet werden, desto kleiner ist<br />
das Risiko einer ungeplanten Downtime.<br />
(jcb) n<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
58<br />
Know-how<br />
Neutron<br />
OpenStack Neutron als Beispiel für eine SDN-Implementierung<br />
Maschen knüpfen<br />
Im Fahrwasser der Cloud bahnen sich Technologien wie OpenFlow und Open vSwitch den Weg zu einer<br />
breiten Nutzerbasis. OpenStack Neutron zeigt, wie brauchbares SDN aussehen kann. Martin Loschwitz<br />
Wer sich in den letzten Monaten mit<br />
der IT-Szene beschäftigt hat, der trifft<br />
neben der allgegenwärtigen Wolke<br />
immer häufiger auch auf andere Themen,<br />
die quasi im Rahmen der Cloud<br />
groß werden. Eines davon ist Software<br />
Defined Networking, kurz SDN. Hinter<br />
diesem etwas sperrigen Begriff verbirgt<br />
sich eine relativ simple Idee: Statische<br />
Netzwerkkonfigurationen, wie sie in<br />
IT-Setups typischerweise zur Anwendung<br />
kommen, funktionieren in Clouds<br />
mehr schlecht als recht, verhindern<br />
manchmal sogar, dass sich die Cloud-<br />
Software effektiv nutzen lässt. Indem<br />
die gesamte Netzwerkkonfiguration<br />
per Software definiert wird, lassen sich<br />
Einschränkungen umgehen, die aus<br />
der Verknüpfung der Konfiguration mit<br />
physischen Geräten herrühren. SDN ist<br />
derweil nicht die einzige Technik, bei<br />
der Software Hardware ablöst: Auch<br />
das Software Defined Storage ist derzeit<br />
im Aufwind.<br />
Implizite Netzwerk-<br />
Annahmen<br />
Um die Motivation hinter Software<br />
Defined Networking gerade im Kontext<br />
von OpenStack oder jeder anderen<br />
Cloud-Umgebung zu verstehen, hält<br />
man sich zuerst vor Augen, welche<br />
impliziten Annahmen im Hinblick auf<br />
IT-Netzwerke meist von vornherein<br />
vorhanden sind. Drei Faktoren spielen<br />
eine Rolle:<br />
n Klassische Netzwerke müssen nicht<br />
besonders gut in die Breite skalieren<br />
– oft haben sogar einzelne Kunden<br />
ihre eigenen Switche, auch wenn sie<br />
diese selbst nicht wirklich auslasten<br />
können.<br />
n Klassische Netzwerke unterliegen<br />
einer zentralen Verwaltung: der Anbieter<br />
nimmt auf Zuruf des Kunden<br />
spezifische Konfigurationsänderungen<br />
vor, sodass der Kunde das nicht<br />
selbst machen muss.<br />
n Klassische Netzwerke sind in der<br />
Entwicklung ihrer Größe und des<br />
generierten Traffics vorhersagbar,<br />
sodass eine langfristige Planung<br />
möglich ist.<br />
Zusammen haben diese drei Annahmen<br />
zu typischen Netzwerk-Designs<br />
in der IT geführt. Einzelne Kunden<br />
haben entweder ihren eigenen Switch<br />
oder sind – zur Gewährleistung von<br />
Sicherheit – in einem separaten VLAN<br />
am Switch untergebracht. Mehrere vorhandene<br />
Switche sind gegebenenfalls<br />
sternförmig konfiguriert, die zentrale<br />
Verwaltung erfolgt durch den Anbieter,<br />
wobei die Planung der einzelnen Netzwerktopologien<br />
durchaus den jeweiligen<br />
Kunden überlassen sein kann.<br />
Reality-Check<br />
Für Clouds funktioniert keine der drei<br />
Annahmen. Das geht schon damit los,<br />
dass in einer Cloud alle Hypervisor-<br />
Hosts zwangsläufig gleichberechtigt<br />
sein sollten, damit jeder Hypervisor-<br />
Host die VMs jedes Kunden betreiben<br />
kann; ein solches System macht auch<br />
VLANs sehr unkomfortabel. Überdies<br />
wollen Anbieter durch die Installation<br />
einer Cloud-Software dafür<br />
sorgen, dass Kunden<br />
sich in Form eines<br />
Service-<br />
Portals selbst die Dienste buchen<br />
können, die sie brauchen. Ein neuer<br />
Kunde muss also in der Lage sein, sich<br />
anzumelden und sofort in der eigenen<br />
Netzwerkumgebung VMs zu starten,<br />
ohne dass dafür das Eingreifen eines<br />
Admins notwendig ist. Diese Anforderung<br />
kegelt VLANs endgültig aus dem<br />
Spiel. Schließlich ist die Entwicklung<br />
von Cloud-Netzwerken praktisch kaum<br />
sinnvoll vorhersagbar. Denn ein neuer<br />
Kunde, der etliche Terabyte Traffic pro<br />
Monat produziert, kann sich jederzeit<br />
anmelden, ohne das vorher anzukündigen<br />
– der Cloud-Anbieter tut gut daran,<br />
auf solche Szenarien vorbereitet zu<br />
sein.<br />
SDN zur <strong>Hilfe</strong><br />
Die Motivation hinter dem Einsatz von<br />
Software Defined Networking ist für<br />
die meisten Unternehmen, dass sich<br />
mit SDN-Umgebungen die genannten<br />
Nachteile klassischer Netzwerke um-<br />
Evgeniya Uvarova, 1123RF
Know-how<br />
Neutron<br />
59<br />
gehen lassen. Das wichtigste Wort im<br />
SDN-Kontext ist Entkopplung: Komponenten<br />
der Netzwerk-Infrastruktur – besonders<br />
die Switche – verlieren dabei<br />
alle Management-Aufgaben.<br />
Praktisch betrifft das vor allem VLANs:<br />
Switche nutzen keine VLANs mehr, sondern<br />
werden zu bloßen Packet-Forwardern<br />
ohne spezifische Zusatzaufgabe.<br />
Aus der Sicht des Switches befinden<br />
sich alle angeschlossenen Hypervisor-<br />
Hosts auf der gleichen Ebene, etwaige<br />
Sicherheitsvorkehrungen wickelt die<br />
SDN-Software selbst ab. Auch ist die<br />
SDN-Implementierung verantwortlich<br />
dafür, die Netzwerktopologien der in<br />
der Cloud vorhandenen Nutzer voneinander<br />
zu trennen und den Nutzern<br />
zugleich die Möglichkeit zu geben, ihre<br />
Netzwerke selbst zu verwalten. Grundlage<br />
für dieses System ist freilich, dass<br />
die SDN-Technologie sowie die verwendete<br />
Cloud-Umgebung grundsätzlich<br />
eng miteinander verbunden und integriert<br />
sind.<br />
Ein vorzügliches Beispiel für diese<br />
Art der Implementierung ist Neutron,<br />
die zentrale SDN-Komponente von<br />
OpenStack. Neutron kümmert sich<br />
im OpenStack-Kontext um alles, was<br />
irgendwie mit Netzwerken zu tun hat,<br />
also um die Netzwerktopologien einzelner<br />
Cloud-Kunden genauso wie um die<br />
Verbindung der VMs untereinander im<br />
Hintergrund. Auch DHCP- und Routing-<br />
Dienste fallen in den Aufgabenbereich<br />
der Netzwerkkomponente. Schon aus<br />
dieser Beschreibung ist ersichtlich,<br />
dass Neutron sehr komplex ist und<br />
nicht zufällig ist Neutron auch jene<br />
Komponente, die für künftige Open-<br />
Stack-Admins mit Abstand am schwersten<br />
zu durchblicken ist.<br />
Der Neutron-Server<br />
Grundsätzlich ist Neutron modular aufgebaut<br />
und das in mehrfacher Hinsicht.<br />
Den Anfang macht der Neutron-Server:<br />
Er ist quasi das Hirn der Lösung und im<br />
Hintergrund dafür verantwortlich, die<br />
Netzwerkkonfiguration zu speichern.<br />
Er ist auch die erste Anlaufstelle für<br />
alle anderen Neutron-Komponenten<br />
auf den anderen Hosts innerhalb der<br />
Cloud – wollen diese eine Ãnderung<br />
am Netzwerk vornehmen, so geht das<br />
nur durch den Neutron-Server. Für sich<br />
genommen ist die Komponente freilich<br />
nutzlos, denn ohne eine spezifische<br />
Netzwerktechnologie erfüllt sie keinen<br />
Zweck.<br />
An dieser Stelle kommen die Plugins<br />
ins Spiel, die sich im Neutron-Server<br />
laden lassen (Abbildung 1). Ein Plugin<br />
erweitert den Neutron-Server um die<br />
Fähigkeit, ganz konkrete Handlungsanweisungen<br />
für eine spezifische SDN-<br />
Technologie zu erzeugen. Das Plugin ist<br />
auch der Teil des Neutron-Servers, der<br />
die spezifischen Einträge für die Netzwerkkonfiguration<br />
im Hintergrund in<br />
einer Datenbank anlegt.<br />
Standardmäßig setzt Neutron auf<br />
Open vSwitch, aber es existieren viele<br />
Plugins für andere SDN-Technologien,<br />
beispielsweise für VMWares NXS [1] –<br />
eine Liste von unterstützten Plugins<br />
findet sich unter [2]. Aktuelle Neutron-<br />
Versionen erlauben es sogar, über das<br />
sogenannte Multi-Layer-Framework<br />
mehrere Plugins zur gleichen Zeit zu<br />
betreiben. Das Plugin läuft zusammen<br />
mit dem Server in der Regel auf dem<br />
Host, der innerhalb der Cloud als<br />
»Cloud-Controller« designiert ist.<br />
Den Cloud-Controller zeichnet eine<br />
spezifische Eigenschaft aus: Er selbst<br />
betreibt keine virtuellen Maschinen,<br />
sondern ist nur eine Instanz, die alle<br />
anderen Cloud-Rechner steuert und<br />
kontrolliert. Das stellt das System vor<br />
ein simples Problem: Wie kommen<br />
Netzwerkanweisungen vom Cloud-<br />
Controller auf die Knoten innerhalb der<br />
Wolke, damit sie dort wie gewünscht<br />
funktionieren?<br />
Die Neutron-Agents<br />
Dafür zeichnen die Neutron-Agents<br />
verantwortlich. Konkret lassen sich drei<br />
Problemfelder ausmachen:<br />
n Die Kommunikation einzelner VMs<br />
untereinander muss sicher funktionieren.<br />
Weil in OpenStack grundsätzlich<br />
jede VM jedes Kunden auf<br />
jedem Host laufen können muss,<br />
VLANs aber nicht zum Einsatz kommen,<br />
muss es für VM1 von Kunde 1<br />
am Host A einen Weg geben, mit der<br />
VM2 auf Host B sicher zu reden.<br />
n Die Kommunikation einzelner VMs<br />
mit der Außenwelt, vorrangig dem<br />
Internet: Auch hier muss sichergestellt<br />
sein, dass die VMs der Kunden<br />
voneinander völlig abgeschottet<br />
sind.<br />
n Das DHCP-Problem: Weil jeder<br />
Kunde sich grundsätzlich seine<br />
Netze selbst nach eigenem Gutdünken<br />
definieren kann, muss es eine<br />
zentrale Instanz geben, die jede<br />
Kunden-VM mit einer spezifischen<br />
DHCP-IP ausstattet.<br />
Für jedes der drei Probleme gibt es in<br />
OpenStack einen sogenannten Agent.<br />
Agents sind grundsätzlich die Gegenstücke<br />
zu Plugins: Sie laufen auf den<br />
Hosts innerhalb der Cloud und setzen<br />
dort Netzwerkbefehle so um, wie das<br />
Plugin im Neutron-Server es vorgibt.<br />
Neutron unterscheidet dabei zwischen<br />
Agents, die im Hinblick auf ein Plugin<br />
spezifisch sind – beispielsweise den<br />
Open-vSwitch-Agent – und generischen<br />
Abbildung 1: Der Neutron-Server lädt ein<br />
Plugin, das verantwortlich dafür ist, die<br />
Datenbank im Hintergrund zu verwalten –<br />
verräterische Spuren von OVS finden sich<br />
im Beispiel (Open vSwitch).<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
60<br />
Know-how<br />
Neutron<br />
Abbildung 2: Der Lohn der Arbeit: Auf einem Hypervisor-Knoten ist der GRE-Tunnel gut zu erkennen,<br />
der zum Netzwerkknoten hinführt.<br />
Agents, die mit allen Neutron-Plugins<br />
funktionieren. Der Plugin-spezifische<br />
Agent läuft in der Regel auf jedem Host<br />
mit Ausnahme des Cloud-Controllers,<br />
während die generischen Agents meist<br />
nur auf einigen ausgewählten Hosts<br />
arbeiten.<br />
Im konkreten Beispiel von Open<br />
vSwitch ist das genau so: Der Neutron-<br />
Open-vSwitch-Agent läuft auf allen<br />
Hypervisor-Hosts – und zudem auf<br />
n Listing 1: Tenant-spezifische Netzwerke in Neutron<br />
dem Netzwerkknoten, den fast alle<br />
OpenStack-Konzepte derzeit vorsehen.<br />
Er hat eine maßgebliche Aufgabe: Zwischen<br />
den einzelnen Hosts baut er GRE-<br />
Tunnel im Stil eines MESH-Netzwerkes<br />
auf. Spezifische VMs werden mit virtuellen<br />
Netzwerkkarten gestartet, die (über<br />
Umwege) in diese GRE-Tunnel durchgeleitet<br />
werden. Open vSwitch kümmert<br />
sich um die Sicherheit: Vereinfacht<br />
ausgedrückt sind jene GRE-Tunnel die<br />
01 root@alice:~# neutron net‐list<br />
02 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+<br />
03 | id | name | subnets<br />
04 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+<br />
05 | 1f0da5f2‐e356‐47e2‐a1b8‐dd22d262487c | ext‐net |<br />
06 19971fb7‐32ce‐4b0e‐906c‐b68e3658741d 192.168.144.0/24 |<br />
07 | b08bb789‐7d7c‐4b92‐9f34‐33dafd73d5e9 | admin‐net |<br />
08 ebf41bb0‐9611‐4d3e‐9d2a‐63d18506fb51 10.5.5.0/24 |<br />
09 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+<br />
10 root@alice:~# neutron net‐show admin‐net<br />
11 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+<br />
12 | Field | Value |<br />
13 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+<br />
14 | admin_state_up | True |<br />
15 | id | b08bb789‐7d7c‐4b92‐9f34‐33dafd73d5e9 |<br />
16 | name | admin‐net |<br />
17 | provider:network_type | gre |<br />
18 | provider:physical_network | |<br />
19 | provider:segmentation_id | 1 |<br />
20 | router:external | False |<br />
21 | shared | False |<br />
22 | status | ACTIVE |<br />
23 | subnets | ebf41bb0‐9611‐4d3e‐9d2a‐63d18506fb51 |<br />
24 | tenant_id | 013a0318db1f44fd81f315e8b943acbd |<br />
25 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+<br />
virtuellen Switche und die NICs der VMs<br />
die dazugehörigen Ports.<br />
Open vSwitch selbst ist bekanntlich<br />
im Wesentlichen ein Frontend für<br />
OpenFlow, und über OpenFlow-Tags<br />
sorgt Neutron qua Open vSwitch dafür,<br />
dass eine Trennung von Paketen auf<br />
Kundenebene stattfindet. Was über die<br />
Netzwerkkarte der VM1 vom Kunden 1<br />
auf Host A in den GRE-Tunnel geht, ist<br />
also mit einem Tag versehen, das nur<br />
entsprechend getaggte Interfaces auf<br />
anderen Hypervisor-Hosts ebenfalls<br />
zu Gesicht bekommen (Abbildung 2).<br />
Anhand des OSI-Layer-Modells wird<br />
deutlich, dass hier im Grunde ein virtueller<br />
Layer 2 in einem physischen Layer<br />
3 gebaut wird. Die Plugin-spezifischen<br />
Agents heißen in OpenStack deshalb<br />
oft auch L2-Agents.<br />
Zu den L2-Agents gesellt sich der DHCP-<br />
Agent zusammen mit dem L3-Agent.<br />
Wie bereits erwähnt ist es mittlerweile<br />
durchaus üblich, einen separaten<br />
Knoten für die Netzwerkdienste einer<br />
OpenStack-Cloud abzustellen; der<br />
Netzwerkknoten hat die Aufgabe, sämtliche<br />
VMs mit der Außenwelt zu verbinden<br />
und auch dafür zu sorgen, dass neu<br />
gestartete VMs eine passende IP per<br />
DHCP erhalten. Darum kümmern sich<br />
die beiden genannten Agents.<br />
Der Netzwerkknoten<br />
Doch wie funktioniert diese Technik genau<br />
und welche Komponenten sorgen<br />
auf dem Netzwerkknoten für die reibungslose<br />
Funktion? Soviel vorab: Ein<br />
L2-Agent läuft selbstverständlich auch<br />
auf dem Netzwerkknoten. Denn damit<br />
VMs über den Netzwerkknoten mit der<br />
Außenwelt kommunizieren können,<br />
gelten natürlich die gleichen Bedingungen<br />
wie für die Kommunikation der VMs<br />
untereinander. Über den Draht zu den<br />
Hypervisor-Systemen wandern auch<br />
die DHCP-Antworten: Für jedes Tenant-<br />
Netzwerk startet der DHCP-Agent auf<br />
dem Netzwerkknoten eine Instanz von<br />
»dnsmasq« [3] mit einer entsprechend<br />
präparierten Konfiguration. Weil User<br />
beim Starten einer VM festlegen müssen,<br />
mit welchem virtuellen Netz die<br />
VM verbunden sein soll, landet ein<br />
DHCP-Request von einer VM über den<br />
GRE-Tunnel zwischen dem Hypervisor-<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Know-how<br />
Neutron<br />
61<br />
Abbildung 3: Network Namespaces haben eine eigenständige Netzwerkkonfiguration; die System-<br />
NICs sehen sie nicht.<br />
Host und dem Netzwerkknoten beim<br />
passenden »dnsmasq« und bekommt<br />
eine entsprechende Antwort. Ganz ähnlich<br />
funktioniert auch der Ablauf bei der<br />
sogenannten Layer-3-Kommunikation,<br />
also mit der Außenwelt.<br />
Was in der Theorie simpel klingt, hat in<br />
der Praxis allerdings einen gewaltigen<br />
Pferdefuß. Damit Kunden wirklich ihre<br />
Netzwerktopologien selbst festlegen<br />
können, anstatt auf eine zentrale<br />
Verwaltung angewiesen zu sein, ist<br />
es zwingend notwendig, dass jeder<br />
Kunde grundsätzlich jedes Netz nutzen<br />
kann. Kunde 1 muss also das Netz<br />
192.168.0.0/24 genauso nutzen können<br />
wie Kunde 2. Solange Netzwerk-Traffic<br />
nur zwischen den Hypervisor-Hosts<br />
passiert, ist das – den OpenFlow-Tags<br />
sei Dank – auch kein größeres Problem.<br />
Auf dem Knoten, der für das Netzwerk<br />
verantwortlich zeichnet, entsteht jedoch<br />
ein großes Problem: Wenn aus<br />
zwei unterschiedlichen GRE-Tunneln<br />
Pakete aus dem genannten Netzwerk<br />
ankommen, die beide über die gleiche<br />
externe Netzwerkkarte an die Außenwelt<br />
verschickt werden sollen, muss<br />
der Netzwerkknoten die Pakete trennen<br />
können. Der Open-vSwitch-Agent<br />
in OpenStack Neutron setzt dafür auf<br />
Namespaces (Abbildung 3).<br />
Namespaces sind eine Kernel-Funktion,<br />
die in unterschiedlichen Varianten<br />
daherkommt; innerhalb eines Namespaces<br />
sind Prozesse „eingesperrt“,<br />
sehen den Rest des Systems also<br />
nicht. Im Grunde sind sie eine Art<br />
»chroot« – sie stehen für PIDs genauso<br />
zur Verfügung wie für Netzwerke. Ein<br />
Prozess, der in einem Network Namespace<br />
gestartet wird, sieht also nicht<br />
die Netzwerkkarten des Systems,<br />
sondern lediglich die innerhalb dieses<br />
Namespaces existierenden Devices.<br />
Diesen Umstand macht sich Neutron<br />
zunutze: Für jedes interne sowie für<br />
jedes externe Netzwerk existiert auf<br />
dem Netzwerkknoten jeweils ein spezifischer<br />
Namespace. In den Namespaces<br />
landen die Pakete, die zuvor den Netzwerkknoten<br />
über die GRE-Tunnel erreicht<br />
haben. Sie befinden sich also von<br />
Anfang an „am richtigen Ort“, sodass<br />
der Netzwerkknoten Pakete zuordnen<br />
kann. Damit ein Kundennetzwerk Zugriff<br />
auf die Außenwelt hat, muss der<br />
Kunde der Cloud zudem eine Verbindung<br />
zwischen dem externen Netzwerk<br />
und dem internen DHCP-Netz schaffen,<br />
um eine Brücke zu bauen. Indem der<br />
Anbieter ein eventuell vorhandenes, externes<br />
Netz entsprechend fragmentiert<br />
und Kunden die einzelnen Fragmente<br />
zur Verfügung stellt, sorgt er also für<br />
echte Freiheit der Kunden in Sachen<br />
Netzwerktopologie.<br />
Externe IP-Adressen<br />
Technisch betrachtet sorgt der L3-<br />
Agent über SNAT-Regeln in den<br />
Iptables-Einträgen der einzelnen<br />
Network Namespaces für die externe<br />
Verbindung (Abbildung 4). Nicht unter<br />
den Tisch fallen soll bei dieser Gele-
62<br />
Know-how<br />
Neutron<br />
Namespace auf dem Netzwerkknoten<br />
an und erstellt eine DNAT-Regel, die die<br />
Pakete von der externen IP auf die interne<br />
DHCP-IP der Ziel-VM umleitet.<br />
Skalierbarkeit<br />
Die grundlegenden Funktionen von<br />
Neutron sind damit im Grunde erläutert<br />
– wer ob der Idee eines separaten<br />
Netzwerkknotens an ein künstliches<br />
Nadelöhr denkt, sei beruhigt: DHCPund<br />
L3-Agents können mehrmals im<br />
Netz vorhanden sein, allerdings kommt<br />
dem Admin in einem solchen Setup<br />
die Aufgabe zu, die Zuständigkeit einzelner<br />
Agent-Instanzen für spezisiche<br />
Tenant-Netzwerke per manuellem<br />
Konfigurationseintrag festzulegen (Listing<br />
1). Zukünftige Neutron-Versionen<br />
sollen Abhilfe schaffen, indem sie jeden<br />
Hypervisor-Knoten zum dynamischen<br />
Netzwerkknoten machen, der externe<br />
Verbindungen für genau die VMs ermöglicht,<br />
die eben auf ihm laufen.<br />
Abbildung 4: Innerhalb der Network Namespaces setzt der L3-Agent SNAT-Regeln, um VMs die<br />
Kommunikation mit der Außenwelt zu ermöglichen.<br />
n Info<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31828<br />
[1] Das VMWare-NSX-Plugin:<br />
[http:// www. openstack. org/ summit/<br />
openstack‐summit‐hong‐kong‐2013/<br />
session‐videos/ presentation/ under‐the‐hoo<br />
d‐network‐virtualization‐with‐openstack‐ne<br />
utron‐and‐vmware‐nsx]<br />
[2] Liste aller Plugins:<br />
[https:// wiki. openstack. org/ wiki/ Neutron]<br />
[3] DNSmasq: [http:// www. thekelleys. org. uk/<br />
dnsmasq/ doc. html]<br />
n Autor<br />
Martin Gerhard Loschwitz arbeitet als Principal<br />
Consultant bei hastexo. Er beschäftigt sich dort intensiv<br />
mit den Themen HA, Distributed Storage und<br />
OpenStack. In seiner Freizeit pflegt er Pacemaker für<br />
Debian.<br />
genheit auch die zweite vom L3-Agent<br />
übernommene Aufgabe, nämlich VMs<br />
über externe IP-Adressen von außen erreichbar<br />
zu machen. Der L3-Agent nutzt<br />
auch hierfür die Namespaces. Es wäre<br />
aus mehreren Gründen unklug, müssten<br />
Nutzer externe IP-Adressen in ihren<br />
VMs von Hand konfigurieren. Denn<br />
einerseits werden manche Benutzer<br />
gar nicht wissen, wie sie das anstellen<br />
sollen, und andererseits müsste dann<br />
in der Cloud-Umgebung eine statische<br />
Konfiguration vorhanden sein, die die<br />
jeweilige externe IP bis zur VM durchroutet.<br />
Das skaliert in einer größeren Wolke<br />
aber schon deshalb nicht, weil Kunden<br />
VMs nicht immer dauerhaft benötigen,<br />
sondern öffentliche IPs eventuell schon<br />
nach kurzer Zeit zurückgeben, damit<br />
sie sie nicht länger bezahlen müssen.<br />
Neutron behilft sich mit einem Trick:<br />
Kunden können sich per Web-Interface<br />
externe IPs aus einem vom Admin einmal<br />
definierten Netz reservieren und<br />
sie dann einer VM mittels Mausklick<br />
zuweisen. Der L3-Agent legt die IP dann<br />
automatisch im passenden Network<br />
Fazit<br />
OpenStack Neutron ist ein faszinierendes<br />
Beispiel dafür, wie sich aus dem<br />
eher theoretischen Thema SDN ein<br />
praktischer Ansatz formen lässt. Ab<br />
Werk setzt Neutron auf Open vSwitch<br />
und damit auch auf OpenFlow. Die<br />
Funktionen, die OpenFlow für Open-<br />
Stack bereitstellt, genügen dabei<br />
völlig, um die in typischen Netzwerkinfrastrukturen<br />
zu findenden Hilfskonstruktionen<br />
wie VLANs zu ersetzen.<br />
Als besondere Dreingabe bekommen<br />
Kunden in gut geplanten Setups mit<br />
Neutron freie Hand über ihre eigene<br />
Netzwerktopologie in der Cloud, sodass<br />
der Cloud-Anbieter sich nicht mehr<br />
selbst um das Thema kümmern muss.<br />
Hinzu kommt, dass Neutron längst<br />
nicht am Ende der Feature-Fahnenstange<br />
ist: Insbesondere die Havana-<br />
Version hat zahlreiche neue Features<br />
wie die VPNaaS- und FWaaS-Agents,<br />
die On-Demand-VPN und Firewalling<br />
auf Zuruf komfortabel ermöglichen.<br />
Das LBaaS-Plugin (Loadbalancer as a<br />
Service) konfiguriert einen HA-Proxy,<br />
der eingehenden Traffic auf mehrere<br />
VMs weiterleitet. Ein Blick auf Neuigkeiten<br />
zu Neutron lohnt sich also allemal.<br />
(jcb) n<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
watchara rojjanasain, 123RF<br />
Dateien und Verzeichnisse mit Incron überwachen<br />
Kontrolldatei<br />
Incron liefert eine einfache Möglichkeit, Befehle und Skripte durch Dateisystem-Events auszulösen. So<br />
verschickt das System beispielsweise automatisch E-Mails, wenn neue Dokumente vorliegen. Paul C. Brown<br />
Wer unter Linux ein Kommando starten<br />
möchte, sobald ein bestimmtes<br />
Ereignis eintritt, braucht nicht umständlich<br />
Log-Dateien auszulesen oder<br />
regelmäßige Anfragen zu schicken. Das<br />
Werkzeug Incron setzt auf das Kernel-<br />
Subsystem Inotify [1], um auf Ereignisse<br />
zu reagieren, die das Dateisystem<br />
betreffen, beispielsweise beim Öffnen,<br />
<strong>Erste</strong>llen oder Löschen einer Datei,<br />
einem Zugriff auf ein Verzeichnis oder<br />
einer Veränderung von Attributen.<br />
Der Name Incron erinnert absichtlich<br />
an das Standardwerkzeug Cron. Während<br />
sich Incron allerdings an Dateisys-<br />
n Die Wurzeln von Incron<br />
Der Zusatz »In« in Incron stammt von »Inode«. Diese<br />
Datenstruktur enthält die Details jeder Datei und<br />
jedes Verzeichnisses im Dateisystem, etwa den physischen<br />
Speicherort auf der Platte, die Größe und den<br />
Besitzer.<br />
Von Inode leitet sich auch der Name von Inotify ab,<br />
dem Subsystem des Linux-Kernels, auf dem Incron<br />
basiert. Es beobachtet Dateien und Verzeichnisse<br />
und benachrichtigt bei Änderungen auf Anfrage<br />
Anwendungen aller Art. Beispielsweise zeigt ein<br />
grafischer Dateimanager ein Symbol für einen neu<br />
erstellten Ordner im aktuellen Verzeichnis direkt an,<br />
auch wenn ein anderes Programm diesen erzeugt<br />
hat. Die Gnome- und KDE-Dateimanager Nautilus<br />
beziehungsweise Dolphin setzen auf Inotify, wie auch<br />
einige Texteditoren, die mit Inotify feststellen, ob ein<br />
anderer Benutzer oder ein anderes Programm eine<br />
Datei zwischenzeitlich verändert hat.<br />
temereignissen orientiert, startet Cron<br />
Jobs auf Basis von Zeitpunkten.<br />
Nur wenige Distributionen installieren<br />
Incron standardmäßig, die meisten<br />
halten es aber in ihren Repositories für<br />
die Installation mit dem Paketmanager<br />
vor. Wer die Quellen begutachten und<br />
kompilieren möchte, findet sie auf der<br />
Projekt-Homepage [1].<br />
Die zentrale Komponente von Incron<br />
bildet der Daemon »incrond«. Er startet<br />
Programme gemäß den Einträgen in<br />
der benutzerspezifischen Incron-Job-<br />
Tabelle »incrontab«, die man analog<br />
zu Cron mit dem Befehl »incrontab ‐e«<br />
editiert. Dabei kommt der in der Umgebungsvariablen<br />
»$EDITOR« eingetragene<br />
Texteditor zum Einsatz.<br />
Je nach Distribution verlangt Incron<br />
eine explizite Erlaubnis. Dafür trägt<br />
man die gewünschten Benutzer – ein<br />
Name je Zeile – in die dafür zuständige<br />
Incron-Konfigurationsdatei ein, standardmäßig<br />
»/etc/incron.allow«.<br />
Jeder Incron-Auftrag besteht aus drei<br />
Spalten und steht – wiederum wie bei<br />
Cron – in einer eigenen Zeile. Die drei<br />
Teile eines Incron-Jobs lauten:<br />
n Pfad: das zu beobachtende Verzeichnis<br />
oder eine Datei<br />
n Maske: die zu registrierenden Ereignisse<br />
(siehe Tabelle 1)<br />
n Befehl: der auszuführende Befehl<br />
oder ein Shell-Skript<br />
Eine Zeile in der Incrontab-Datei sieht<br />
beispielsweise so aus:<br />
/home/$USER/my_dir U<br />
IN_CREATE /home/$USER/bin/hello.sh<br />
Es gilt zu beachten, dass es sich bei<br />
Incron nicht um einen Bash-Interpreter<br />
handelt. Deshalb empfiehlt sich die<br />
Verwendung eines Shell-Skripts, um<br />
beispielsweise die Ausgabe eines Befehls<br />
umzuleiten. In der Befehlsspalte<br />
einer Incrontab-Zeile interpretiert<br />
Incron nur den Befehl und seine Parameter.<br />
Folgt eine Umleitung wie »>>logfile«,<br />
erkennt Incron das ebenfalls als<br />
Befehlsargument; dass es ungültig ist,<br />
interessiert das Programm nicht.<br />
Des Weiteren gilt wie bei Cron, dass<br />
Incron die »$PATH«-Variable des Benutzers<br />
nicht kennt. Deshalb sollte die Angabe<br />
des Befehls unter Angabe seines<br />
vollständigen Pfades erfolgen.<br />
Um auf die durch Inotify ausgelösten<br />
Ereignisse gezielt zu reagieren, hält<br />
Incron die Variablen (Wildcards) aus<br />
Tabelle 2 vor. Die Ausdrücke beginnen<br />
mit dem »$«-Zeichen; um das Dollar-<br />
Symbol selbst zu verwenden, dient der<br />
Ausdruck »$$«.<br />
Der folgende Eintrag in der Incrontab<br />
ruft das Skript »hello.sh« mit dem Namen<br />
der Datei als Argument auf, die das<br />
Ereignis »IN_CREATE« ausgelöst hat:<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Know-how<br />
Incron<br />
65<br />
/home/paul/my_dir IN_CREATE U<br />
/home/paul/bin/hello.sh $#<br />
Automatischer Apache<br />
Als praktisches Beispiel startet Incron<br />
etwa einen Server neu, sobald sich<br />
dessen Konfigurationsdatei verändert<br />
hat. Die folgende Zeile startet den Apache-Webserver<br />
mittels Init-Skript neu,<br />
sobald sich die Konfigurationsdatei verändert<br />
hat (siehe Abbildung 1):<br />
Abbildung 1: Der Apache-Webserver protokolliert einen durch Incron ausgelösten Neustart.<br />
/etc/apache2/apache2.conf IN_MODIFY U<br />
/etc/init.d/apache2 restart<br />
Allerdings verwendet der Apache-<br />
Webserver üblicherweise verschiedene<br />
Konfigurationsdateien für seine<br />
zahlreichen Module. Der folgende<br />
Incrontab-Eintrag löst deshalb einen<br />
Neustart aus, sobald ein Benutzer<br />
eine neue Datei im Unterverzeichnis<br />
»conf.d« anlegt, das unter Debian die<br />
Apache-Konfigurationsdateien enthält;<br />
bei anderen Distributionen weicht der<br />
Verzeichnisname allerdings ab:<br />
n Tabelle 1: Ereignisse<br />
Ereignisname<br />
Allgemeine Ereignisse<br />
IN_ACCESS<br />
IN_ATTRIB<br />
IN_CLOSE_WRITE<br />
IN_CLOSE_NOWRITE<br />
IN_CLOSE<br />
IN_CREATE<br />
IN_DELETE<br />
IN_DELETE_SELF<br />
IN_MODIFY<br />
IN_MOVE_SELF<br />
IN_MOVED_FROM<br />
IN_MOVED_TO<br />
IN_MOVE<br />
IN_OPEN<br />
Spezielle Ereignisse<br />
IN_ALL_EVENTS<br />
IN_DONT_FOLLOW<br />
IN_ONESHOT<br />
IN_ONLYDIR<br />
Wildcard-Ereignisse<br />
IN_NO_LOOP<br />
Bedeutung<br />
/etc/apache2/conf.d/ IN_CREATE U<br />
/etc/init.d/apache2 restart<br />
Bei anderen Linux-Varianten käme hier<br />
etwa das Verzeichnis »/etc/apache2/<br />
conf‐enabled« infrage. Außerdem<br />
verwenden SysV-Init-basierte Distributionen<br />
den Befehl »service apache2<br />
restart«, um den Webserver neu zu<br />
starten.<br />
Sollen neben neu angelegten Dateien<br />
auch Veränderungen an bestehenden<br />
Files den Server-Neustart auslösen,<br />
reiht man die beiden Ereignisse mit<br />
Zugriff (Lesen).<br />
Metadaten geändert (Berechtigungen, Zeitstempel, erweiterte<br />
Attribute).<br />
Zum Schreiben geöffnete Datei geschlossen.<br />
Nicht zum Schreiben geöffnete Datei geschlossen.<br />
Geöffnete Datei wird geschlossen.<br />
Datei oder Verzeichnis in beobachtetem Verzeichnis erstellt.<br />
Datei oder Verzeichnis in beobachtetem Verzeichnis gelöscht.<br />
Beobachtete Datei oder Verzeichnis gelöscht.<br />
Datei in beobachtetem Verzeichnis verändert.<br />
Beobachtete Datei oder Verzeichnis verändert.<br />
Datei aus beobachtetem Verzeichnis verschoben.<br />
Datei in beobachtetes Verzeichnis verschoben.<br />
Datei in oder aus beobachtetem Verzeichnis verschoben.<br />
Datei geöffnet.<br />
Irgendein Ereignis.<br />
Symbolischen Links nicht folgen.<br />
Datei oder Verzeichnis nur für ein Ereignis beobachten.<br />
Angegebenen Pfad nur dann beobachten, wenn es ein Verzeichnis<br />
ist.<br />
Beobachten unterbrechen, sobald ein Ereignis ausgelöst worden<br />
ist, bis der entsprechende Befehl beendet ist (verhindert<br />
Endlosschleifen).<br />
Kommas getrennt aneinander, denn ein<br />
Pfad darf nur einmal in der Incrontab-<br />
Datei auftauchen:<br />
/etc/apache2/conf.d/ IN_CREATE,U<br />
IN_CLOSE_WRITE /etc/init.d/apache2 U<br />
restart<br />
Die separate Behandlung der Verzeichnisse<br />
»/etc/apache2« und des Unterverzeichnisses<br />
»conf.d« in den vorhergehenden<br />
Beispielen lässt sich übrigens<br />
nicht einfach umgehen. Incrontab bietet<br />
keine Möglichkeit, ein Verzeichnis<br />
rekursiv zu überwachen.<br />
Gegen die Unendlichkeit<br />
Das sogenannte Wildcard-Ereignis »IN_<br />
NO_LOOP« verhindert, dass ein Event<br />
in einem Verzeichnis zu einer endlosen<br />
Kette weiterer Ereignisse führt.<br />
Typischer Anwendungsfall ist eine<br />
Konfiguration, in der eine Log-Datei<br />
die Änderungen in einem Verzeichnis<br />
protokolliert:<br />
Verzeichnis IN_CLOSE_WRITE U<br />
log_changes $#<br />
Das Kommando »log_changes« im Beispiel<br />
schreibt den Namen der veränderten<br />
Datei in eine Log-Datei. Liegt diese<br />
im selben Verzeichnis, würde der dem<br />
Protokoll hinzugefügte Eintrag wiederum<br />
ein Änderungsereignis auslösen.<br />
n Tabelle 2: Wildcards<br />
Ausdruck Bedeutung<br />
»$@« Name des beobachteten Verzeichnisses<br />
»$#« Name der Datei, die das Ereignis ausgelöst<br />
hat<br />
»$%« Ereignisbezeichnung<br />
»$&« Numerisches Ereignissymbol<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
66<br />
Know-how<br />
Incron<br />
n Info<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31737<br />
[1] Incron: [http:// inotify. aiken. cz/ ?<br />
section=incron& page=about]<br />
Gegen eine solche Endlosschleife hilft<br />
»IN_NO_LOOP«. Es setzt den Eintrag<br />
außer Kraft, bis der Befehl »log_changes«<br />
abgeschlossen ist:<br />
Verzeichnis IN_CLOSE_WRITE,U<br />
IN_NO_LOOP log_changes $#<br />
Stiller Alarm<br />
Incron lässt sich auch als Hinweisgeber<br />
verwenden, um Zugriffe auf die Dateien<br />
eines bestimmten Verzeichnisses zu<br />
protokollieren. Ein Skript vermerkt im<br />
folgenden Beispiel jeden Zugriff auf ein<br />
bestimmtes Verzeichnis unter Angabe<br />
der Zugriffsart mithilfe des »$%«-Operators:<br />
/home/$USER/Dokumente IN_ACCESS,U<br />
IN_CLOSE_WRITE access_control.sh $%<br />
Hierbei dient der Name des Ereignisses<br />
(»$%«) als Argument für das Beispiel-<br />
Skript »access_control.sh«.<br />
Incrontab dynamisch<br />
Ein weiteres Praxisbeispiel verwendet<br />
Incron, um Benutzer über neue Dateien<br />
in einem Arbeitsverzeichnis zu benachrichtigen.<br />
Es enthält beispielsweise die<br />
Warteschlange des Mitarbeiters, in der<br />
er neue Dokumente vorfindet, die er zu<br />
bearbeiten hat. Incron befreit ihn von<br />
der lästigen Pflicht, den Ordner regelmäßig<br />
auf Neuigkeiten zu überprüfen.<br />
Eine Schwierigkeit besteht in diesem<br />
Szenario: Die Dokumente sollen in eine<br />
Ordnerstruktur unterhalb des Arbeitsverzeichnisses<br />
eingegliedert werden,<br />
etwa ein Unterordner für jedes Jahr<br />
und darunter ein weiterer für jeden<br />
Monat. Wie erwähnt bietet Incron allerdings<br />
keine Möglichkeit, Ordner rekursiv<br />
zu überwachen. Um nicht für jedes<br />
Verzeichnis einen einzelnen Eintrag in<br />
der Incrontab erstellen zu müssen, erledigt<br />
dies das Skript »makeIncrontab.<br />
sh« aus Listing 2.<br />
Der Trick besteht darin, die Incron-<br />
Tabelle automatisch zu bearbeiten,<br />
und nicht mit dem interaktiven Editor<br />
(»incrontab ‐e«) . Die Incrontab-Dateien<br />
liegen unter »/var/spool/incron/«. Für<br />
jeden Benutzer hält das Programm eine<br />
eigene Datei vor, benannt nach dessen<br />
Usernamen. Als Ausgangspunkt für das<br />
beschriebene Beispiel erstellt zunächst<br />
Root für jeden Mitarbeiter manuell<br />
einen Eintrag in seiner Incrontab mit<br />
»sudo incrontab ‐e«:<br />
n Listing 1: Automatisch generierte Incrontab-Datei für Benutzer »joe«<br />
/home/joe/lm75 IN_CREATE send_mail.sh address@admin.com joe@editor.com $# $@<br />
/home/joe/lm76 IN_CREATE send_mail.sh address@admin.com joe@editor.com $# $@<br />
/home/joe/shell02 IN_CREATE send_mail.sh address@admin.com joe@editor.com $# $@<br />
/home/joe/uu04 IN_CREATE send_mail.sh address@admin.com joe@editor.com $# $@<br />
/home/joe IN_CREATE U<br />
/usr/local/bin/makeIncrontab.sh $@<br />
/home/jane IN_CREATE U<br />
/usr/local/bin/makeIncrontab.sh $@<br />
/home/jed IN_CREATE U<br />
/usr/local/bin/makeIncrontab.sh $@<br />
...<br />
Das erfordert zwar weiterhin etwas<br />
Handarbeit, aber nur beim Hinzufügen<br />
und Entfernen einzelner Mitarbeiter.<br />
Incrontab überwacht nun das Home-<br />
Verzeichnis jedes Mitarbeiters und ruft<br />
»makeIncrontab.sh« (Listing 2) auf, sobald<br />
darin ein neues Unterverzeichnis<br />
angelegt wird.<br />
Das Skript »makeIncrontab.sh« nimmt<br />
einen Benutzernamen als Argument<br />
entgegen – ausgelesen mit »$@« – und<br />
löscht bereits existierende Incrontab-<br />
Dateien. Das bringt den Vorteil mit<br />
sich, dass zuvor angelegte Regeln für<br />
eventuell nicht mehr bestehende Verzeichnisse<br />
automatisch verschwinden.<br />
Danach iteriert »makeIncrontab.sh«<br />
über alle Unterverzeichnisse im Home-<br />
Verzeichnis des angegebenen Benutzers.<br />
Für jedes davon erzeugt es einen<br />
neuen Incrontab-Eintrag. Sobald einem<br />
dieser Verzeichnisse eine neue Datei<br />
hinzugefügt wird, ruft es das Skript<br />
»send_mail.sh« auf.<br />
Die E-Mail-Adresse des Benutzers<br />
entnimmt das Skript der Datei ».emailaddress«<br />
im Home-Verzeichnis, die<br />
zu diesem Zweck natürlich existieren<br />
muss. Daneben verwendet »makeIncrontab.sh«<br />
das Skript »send_mail.sh«,<br />
um in diesem Beispiel eine E-Mail an<br />
den Benutzer zu senden. Listing 1 zeigt<br />
eine Incrontab-Datei als mögliches Ergebnis<br />
des Vorgangs. (csc) n<br />
n Listing 2: »makeIncrontab.sh« erzeugt eine Incrontab<br />
01 #!/bin/bash<br />
02<br />
03 # Der Benutzername wird aus dem überwachten<br />
04 # Verzeichnis ausgelesen ($@) und von<br />
05 # Incron als erstes Argument ($1)<br />
06 # übergeben.<br />
07<br />
08 # Die Benutzer‐Incrontab löschen:<br />
09 rm /var/spool/incron/`echo $1|cut ‐d / ‐f 3`<br />
10<br />
11 # Über den Inhalt des Home‐Verzeichnisses iterieren:<br />
12 for i in $1/*<br />
13 do<br />
14<br />
15 # ... Für jedes Verzeichnis eine<br />
16 # Incron‐Regel (ignoriere Dateien).<br />
17 if [ ‐d $i ]<br />
18 then<br />
19 echo "$i IN_CREATE send_mail.sh address@admin.com `cat<br />
$1/.emailaddress`" '$# $@' >> /var/spool/incron/`echo $1|cut ‐d /<br />
‐f 3`<br />
20 fi<br />
21 done<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
68<br />
Know-how<br />
CRIU<br />
Valentyn Volkov Volkov, 123RF<br />
Linux-Prozesse speichern und wiederherstellen mit CRIU<br />
Auf Eis gelegt<br />
Einfrieren und Auftauen: Was bei Pizza normal ist, erledigt bei Linux-Prozessen CRIU. Tim Schürmann<br />
Manche Wartungsarbeiten lassen<br />
sich nur dann vornehmen, wenn keine<br />
Produktiv-Software mehr läuft. Doch<br />
Admins können Prozesse nicht nach<br />
Gutdünken beenden, sonst droht<br />
Datenverlust; zeitaufwendige Berechnungen<br />
müssten von vorne beginnen.<br />
Abhilfe schafft auf Linux-Systemen das<br />
kleine Werkzeug Checkpoint/Restore In<br />
Userspace, kurz CRIU genannt.<br />
CRIU friert den aktuellen Zustand eines<br />
Prozesses ein und sichert ihn auf der<br />
Festplatte. Später lässt sich der Prozess<br />
wieder zum Leben erwecken und<br />
arbeitet dann an der Stelle weiter, an<br />
der CRIU ihn eingefroren hat. Bei virtuellen<br />
Maschinen heißt dieses Konzept<br />
Snapshots.<br />
Das Konservieren hilft nicht nur bei<br />
Wartungsarbeiten. Angehaltene Prozesse<br />
lassen sich auch auf andere<br />
Rechner verschieben und laufen dort<br />
weiter. Diese Live-Migration hilft beispielsweise<br />
beim Loadbalancing: Dreht<br />
ein Rechner gerade Däumchen, transferiert<br />
man einen Prozess per Skript<br />
dorthin. Des Weiteren lassen sich verdächtig<br />
agierende Prozesse einfrieren<br />
und auf einem anderen System in Ruhe<br />
analysieren. Bindet man CRIU in die<br />
Startskripte des Systems ein, sichert es<br />
Prozesse beim Herunterfahren automatisch<br />
und bringt sie beim nächsten<br />
Systemstart zurück in den Speicher. Auf<br />
diese Weise stellt man nicht nur den<br />
Zustand vor dem Ausschalten wieder<br />
her, sondern verkürzt auch den Boot-<br />
Vorgang.<br />
Nümmerchen<br />
Die erste CRIU-Version erschien vor<br />
nicht einmal zwei Jahren. Von der aktuellen<br />
Version 1.1 lag bei Redaktionsschluss<br />
nur der erste Release Candidate<br />
vor; bei Erscheinen dieses <strong>ADMIN</strong>-<br />
<strong>Magazin</strong>s sollte CRIU 1.1 jedoch zur<br />
Verfügung stehen. Dennoch basieren<br />
die folgenden Ausführungen auf dem<br />
Release Candidate. Ältere Versionen<br />
sammelt das Release-Archiv unter [2].<br />
CRIU arbeitet zwar vollständig im<br />
Userspace, stellt aber mehrere Anforderungen<br />
ans laufende System. Zunächst<br />
funktioniert das Programm nur<br />
auf Systemen mit ARM- oder x86_64-<br />
Architektur, in letztem Fall muss auch<br />
ein 64-Bit-Linux laufen. Des Weiteren<br />
verlangt CRIU einen Linux-Kernel ab<br />
Version 3.11. Aktuelle Desktop-Distributionen<br />
erfüllen diese Bedingung, die<br />
auf Servern beliebten Linux-Varianten<br />
Debian 7 und CentOS 6.5 jedoch nicht.<br />
Der Einsatz von CRIU auf diesen Systemen<br />
setzt deshalb ein Kernel-Upgrade<br />
voraus.<br />
Der laufende Kernel muss außerdem<br />
die von CRIU verlangten Funktionen<br />
bereitstellen. Tabelle 1 führt die beim<br />
Kernel-Kompilieren zu aktivierenden<br />
Einstellungen auf. Liegt ein fertiger<br />
Kernel vor, prüft CRIU dessen Kompatibilität<br />
mit »criu check«.<br />
Aufgrund der detaillierten Ansprüche<br />
an den Betriebssystemkern stellten die<br />
CRIU-Entwickler in der Vergangenheit<br />
eigens einen passenden Kernel bereit.<br />
Da Linux in Version 3.11 jedoch alle<br />
notwendigen Funktionen mitbringt,<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Know-how<br />
CRIU<br />
69<br />
fällt diese Notwendigkeit weg und der<br />
Einsatz alter CRIU-Kernel empfiehlt<br />
sich nicht mehr.<br />
Erfüllt der Kernel alle Voraussetzungen,<br />
muss zudem Googles Protocol-<br />
Buffers-Bibliothek her [3, 4], die in den<br />
Repositories der meisten Distributionen<br />
bereitsteht. Neben der Bibliothek<br />
selbst benötigt man die zugehörigen<br />
Entwicklungspakete, die C-Bindings<br />
und den Protobuf-C-Compiler. Unter<br />
Ubuntu und Debian heißen die entsprechenden<br />
Pakete »libprotobuf‐c0‐dev«<br />
und »protobuf‐c‐compiler«, auf anderen<br />
Distributionen ähnlich.<br />
CRIU greift außerdem auf Iproute2 zurück,<br />
das mindestens in Version 3.5.0<br />
von August 2012 vorliegen muss. Auch<br />
dieses Werkzeug haben die meisten<br />
aktuellen Distributionen an Bord. Falls<br />
nicht, wie im Fall von Debian 7, gibt es<br />
den Quellcode unter [5].<br />
Testlauf<br />
Um CRIU zu übersetzen, benötigt man<br />
nach dem Download der Quellen [1]<br />
nur noch das Make-Werkzeug und einen<br />
C-Compiler. Nach dem Entpacken<br />
des Archivs und dem Kompilieren mit<br />
»make« ist eine systemweite Installation<br />
des Werkzeugs weder vorgesehen<br />
noch notwendig.<br />
Bevor man die ersten Prozesse schockfrostet,<br />
empfiehlt sich ein CRIU-Test.<br />
Dazu initiiert man als Benutzer Root<br />
auf der Kommandozeile<br />
diesen Befehl:<br />
criu check ‐‐ms<br />
Am Ende sollte CRIU<br />
die Meldung »Looks<br />
good« auswerfen<br />
(siehe Abbildung 1). Andernfalls verrät<br />
das Werkzeug, welche Funktion fehlt.<br />
Ältere Versionen des Tools hießen übrigens<br />
noch »crtools«, deshalb beziehen<br />
sich manche im Internet kursierende<br />
Anleitungen noch auf diesen Befehlsnamen.<br />
Der nächste Testschritt folgt im CRIU-<br />
Unterverzeichnis<br />
»test«. Dort ruft man<br />
als Root das Skript<br />
»zdtm.sh« auf. Diese<br />
Test-Suite startet mehrere<br />
Prozesse und friert<br />
sie probeweise ein. Ein<br />
kompletter Durchlauf<br />
benötigt einige Minuten,<br />
während derer das<br />
System immer wieder<br />
einfrieren kann. Bei<br />
einem Problem bricht<br />
die Test-Suite ab und<br />
nennt die Quelle. Nach<br />
erfolgreichem Durchlauf<br />
erscheint nur das<br />
Resultat des letzten<br />
Tests (Abbildung 2).<br />
Abbildung 1: Meldet CRIU »Looks good«, bietet der Kernel alle vom<br />
Werkzeug benötigten Funktionen.<br />
Sandmann<br />
Um nach erfolgreichen Tests einen<br />
Prozess einzufrieren, benötigt CRIU<br />
lediglich dessen Prozess-ID und einen<br />
Speicherort. Der folgende Befehl<br />
sichert den Prozess mit der PID 2238<br />
im Unterverzeichnis »checkpoint« des<br />
User-Home-Ordners:<br />
Abbildung 2: Die Test-Suite prüft, ob das System alle Voraussetzungen<br />
für den Betrieb von CRIU erfüllt.<br />
n Tabelle 1: Notwendige Kernel-Funktionen<br />
Variable<br />
CONFIG_EMBEDDED<br />
CONFIG_EXPERT<br />
CONFIG_EVENTFD<br />
CONFIG_EPOLL<br />
CONFIG_CHECKPOINT_RESTORE<br />
CONFIG_NAMESPACES<br />
CONFIG_PID_NS<br />
CONFIG_FHANDLE<br />
CONFIG_INOTIFY_USER<br />
CONFIG_IA32_EMULATION<br />
CONFIG_UNIX_DIAG<br />
CONFIG_INET_DIAG<br />
CONFIG_INET_UDP_DIAG<br />
CONFIG_PACKET_DIAG<br />
CONFIG_NETLINK_DIAG<br />
CONFIG_MEM_SOFT_DIRTY<br />
Im Konfigurationsmenü zu aktivieren unter<br />
General setup | Embedded system<br />
General setup | Configure standard kernel features (expert users)<br />
General setup | Configure standard kernel features (expert users) | Enable eventfd() system call<br />
General setup | Configure standard kernel features (expert users) | Enable eventpoll support<br />
General setup | Checkpoint/restore support<br />
General setup | Namespaces support<br />
General setup | Namespaces support | PID Namespaces<br />
General setup | open by fhandle syscalls<br />
File systems | Inotify support for userspace<br />
Executable file formats | Emulations | IA32 Emulation<br />
Networking support | Networking options | Unix domain sockets | UNIX: socket monitoring interface<br />
Networking support | Networking options | TCP/IP networking | INET: socket monitoring interface<br />
Networking support | Networking options | TCP/IP networking | INET: socket monitoring interface | UDP: socket<br />
monitoring interface<br />
Networking support | Networking options | Packet socket | Packet: sockets monitoring interface<br />
Networking support | Networking options | NETLINK: socket monitoring interface<br />
Processor type and features | Track memory changes<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
70<br />
Know-how<br />
CRIU<br />
Abbildung 3: Der »top«-Prozess mit der ID 2238 lässt sich erst mit dem<br />
Parameter »‐‐shell‐job« dumpen.<br />
criu dump ‐‐images‐dir ~/checkpoint U<br />
‐‐tree 2238<br />
Hinter »criu« folgt immer zunächst die<br />
auszuführende Aktion, in diesem Fall<br />
erstellt es eine Sicherung – Dump oder<br />
Image genannt. Hinter »‐‐images‐dir«<br />
oder »‐D« steht das Verzeichnis, hinter<br />
»‐‐tree« oder »‐t« die Prozess-ID. CRIU<br />
benötigt für sämtliche Aktionen Root-<br />
Rechte.<br />
Das Einfrieren schlägt jedoch fehl,<br />
wenn sich der zu speichernde Prozess<br />
Ressourcen mit dem Eltern- oder einem<br />
anderen Prozess teilt. Dann bricht CRIU<br />
sicherheitshalber den Vorgang ab. Bei<br />
in einer Shell gestarteten Prozessen<br />
lässt sich eine solche Ressourcenteilung<br />
oft nicht vermeiden, zur Lösung<br />
gibt es drei Möglichkeiten: Entweder<br />
man verschiebt einen<br />
Prozess in den<br />
Hintergrund, startet<br />
ihn in einer separaten<br />
Session oder übergibt<br />
CRIU den zusätzlichen<br />
Parameter »‐‐shell‐job«<br />
(Abbildung 3):<br />
criu dump ‐D ~/checkpoint ‐t 2238 U<br />
‐‐shell‐job<br />
Im Zielverzeichnis – im Beispiel heißt es<br />
»~/checkpoint« – legt CRIU für einen gesicherten<br />
Prozess mehrere Dateien an.<br />
Jede von ihnen enthält den Zustand<br />
einer vom Prozess genutzten Ressource<br />
(Abbildung 4). Bereits vorhandene Dateien<br />
überschreibt CRIU ohne Warnung.<br />
Nach dem es ihn gesichert hat, beendet<br />
CRIU den Prozess. Dessen letzte<br />
Ausgabe landet gegebenenfalls unformatiert<br />
im Terminal wie in Abbildung 5.<br />
Der CRIU-Parameter »‐‐leave‐running«<br />
sorgt dafür, dass CRIU den gespeicherten<br />
Prozess weiterlaufen lässt.<br />
Reanimation<br />
Der folgende Befehl weckt einen gespeicherten<br />
Prozess<br />
wieder auf:<br />
criu restore ‐D U<br />
~/checkpoint U<br />
‐‐restore‐detached<br />
Der Parameter »‐‐restore‐detached«<br />
sorgt<br />
dafür, dass sich CRIU<br />
nach der Wiederherstellung beendet.<br />
Der reanimierte Prozess besitzt dann<br />
Init als Elternprozess und trägt die<br />
gleiche Prozess-ID wie beim Einfrieren.<br />
Ist diese PID inzwischen anderweitig<br />
vergeben, bricht die Restauration mit<br />
einem Fehler ab. Abhilfe schafft die Option<br />
»--name spaces« oder »-n« . Damit<br />
erhält der Task vom System eine neue<br />
PID und behält seine alte nur intern in<br />
einem virtuellen Prozessnamensraum.<br />
Hat man den Prozess mit »‐‐shell‐job«<br />
gesichert, ist dieser Parameter auch bei<br />
der Wiederherstellung notwendig (Abbildung<br />
6). Der Prozess startet dann in<br />
der Shell, in der man »criu« aufgerufen<br />
hat. Zudem dauert es unter Umständen<br />
einen kurzen Moment, bis der Prozess<br />
tatsächlich die Arbeit aufnimmt.<br />
Bei der Wiederherstellung bleibt die<br />
Sicherung im Verzeichnis »checkpoint«<br />
erhalten. Man kann den Prozess folglich<br />
jederzeit erneut an derselben Stelle<br />
wiederbeleben.<br />
Um den gespeicherten Prozess auf<br />
einem anderen System aufzuwecken,<br />
kopiert man das komplette Verzeichnis<br />
mit der Sicherung auf den anderen<br />
Rechner und reanimiert dort den<br />
Prozess mit »criu restore«. Die neue<br />
Umgebung muss jedoch mit der alten<br />
übereinstimmen und die benötigten<br />
Dateien in den gleichen Verzeichnispfaden<br />
enthalten. Idealerweise handelt<br />
es sich beim neuen System um einen<br />
Klon. Oder ein verteiltes Dateisystem<br />
wie NFS stellt die Dateien bereit. In<br />
jedem Fall sollten Administratoren die<br />
Live-Migration testweise durchspielen,<br />
Abbildung 4: CRIU gewährt Einblick in den Inhalt eines gespeicherten<br />
Prozesses.<br />
Abbildung 5: Vom CRIU-gesicherten »top«-Prozess verbleibt die letzte<br />
Ausgabe auf dem Terminal.<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Know-how<br />
CRIU<br />
71<br />
um fehlenden Bibliotheken, Konfigurationsdateien<br />
und Dokumenten auf die<br />
Spur zu kommen.<br />
Vorausschauend<br />
CRIU bietet die Möglichkeit, die Sicherung<br />
eines Prozess vorzubereiten und<br />
dabei zu beschleunigen. Dazu dient der<br />
CRIU-Parameter »pre‐dump«:<br />
criu pre‐dump ‐t 2369 ‐D U<br />
~/checkpoint/pre<br />
Der Prozess läuft danach normal weiter.<br />
Ein erneuter Aufruf des Befehls<br />
aktualisiert die Vorsicherung jederzeit<br />
(Abbildung 7). Bei der eigentlichen<br />
Sicherung verweist man dann mit dem<br />
Parameter »‐‐prev‐images‐dir« aufs<br />
Pre-Dump:<br />
criu dump ‐t 2369 ‐D ~/checkpoint/dump U<br />
‐‐prev‐images‐dir ../pre<br />
Der Parameter »‐‐prev‐images‐dir«<br />
erwartet einen Verzeichnispfad relativ<br />
zum mit »‐D« angegebenen Speicherort.<br />
Im obigen Beispiel landet die Vorsicherung<br />
unter »~/checkpoint/pre«, die<br />
eigentliche Sicherung unter »~/checkpoint/dump«.<br />
Die Wiederherstellung<br />
funktioniert wie bei jedem Dump:<br />
Sparsame<br />
Wiederholung<br />
Wer von einem Prozess<br />
mehrfach einen<br />
Schnappschuss anlegen<br />
möchte, spart Zeit<br />
und Speicherplatz mit<br />
einer inkrementellen<br />
Sicherung. Dazu erstellt<br />
man einen ersten<br />
Dump wie gehabt,<br />
lässt den Prozess aber<br />
mit dem Parameter<br />
»‐‐leave‐running« weiterlaufen:<br />
criu dump ‐t 2334 U<br />
‐D ~/checkpoint/1/U<br />
‐‐leave‐running U<br />
‐‐track‐mem<br />
Die erste Sicherung wandert hier ins<br />
Verzeichnis »~/checkpoint/1/«. Mit dem<br />
Parameter »‐‐track‐mem« lässt CRIU<br />
den Kernel den Hauptspeicherbereich<br />
des Prozesses beobachten. Dessen Informationen<br />
beschleunigen eine zweite<br />
Sicherung:<br />
criu dump ‐t 2334 ‐D ~/checkpoint/2/U<br />
‐‐leave‐running ‐‐track‐mem U<br />
‐‐prev‐images‐dir ../1/<br />
Abbildung 6: Die Wiederherstellung eines mit »‐‐shell‐job« gespeicherten<br />
Prozesses scheitert ohne Nennung des Grundes, wenn dieser<br />
Parameter fehlt.<br />
Abbildung 7: Eine Vorsicherung mit »pre‐dump« beschleunigt den<br />
Speicherprozess.<br />
wobei man das Verzeichnis wieder<br />
relativ zu dem hinter »‐D« definierten<br />
Ort angibt. Nach dem gleichen Prinzip<br />
erstellt man weitere Sicherungen. Beim<br />
letzten Dump lässt man die Parameter<br />
»‐‐leave‐running« und »‐‐track‐mem«<br />
weg und beendet damit den Prozess.<br />
Die anschließende Wiederherstellung<br />
erfolgt wie zuvor:<br />
criu restore ‐D ~/checkpoint/2/ U<br />
‐‐restore‐detached<br />
criu restore ‐D ~/checkpoint/dump U<br />
‐‐restore‐detached<br />
Hier verrät »‐‐prev‐images‐dir« den<br />
Speicherort der ersten Sicherung,<br />
Ein Verzeichnis enthält im Normalfall<br />
eine komplette Sicherung. Auf Wunsch
72<br />
Know-how<br />
CRIU<br />
n Fernsteuerung<br />
»criu« lässt sich auch als Daemon starten und dann<br />
über passende RPC-Aufrufe fernsteuern:<br />
criu service ‐‐daemon ‐o logdatei.txt<br />
»‐‐daemon« startet CRIU als einen solchen, »‐o«<br />
nennt den Namen der Log-Datei, in die CRIU seine<br />
Ausgaben schreibt. Auf RPC-Anfragen wartet das<br />
Werkzeug dann am Unix-Socket »SOCK_SEQPACKET«<br />
unter »/var/run/criu‐service.socket«. Dort geben<br />
Client-Programme Nachrichten in Form des CRIU-<br />
RPC-Protokolls ab. Deren detaillierten Aufbau führt<br />
das CRIU-Wiki unter [6] auf, Beispielprogramme für C<br />
und Python liegen im CRIU-Quellcodeverzeichnis unter<br />
»test/rpc«. C-Programmierer verwenden alternativ<br />
die Bibliothek »libcriu«, die Wrapper-Funktionen<br />
für die entsprechenden RPC-Aufrufe [7] anbietet.<br />
n Info<br />
spart CRIU Platz, indem es nur die seit<br />
dem letzten Dump geschehenen Änderungen<br />
speichert. Dazu dient das Deduplikationsfeature<br />
mit dem Parameter<br />
»--auto‐dedup«:<br />
criu dump ‐t 2334 ‐D ~/checkpoint/2/U<br />
‐‐leave‐running ‐‐track‐mem U<br />
‐‐prev‐images‐dir ../1/ ‐‐auto‐dedup<br />
CRIU löscht jetzt alle überflüssigen<br />
Daten in der vorherigen Sicherung,<br />
nicht aber in der neuen! Unter »~/<br />
checkpoint/2« landet folglich ein kompletter<br />
Dump, unter »~/checkpoint/1«<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31815<br />
[1] CRIU: [http:// criu. org/]<br />
[2] Release-Archiv: [http:// criu. org/ Releases]<br />
[3] Google Protocol Buffers:<br />
[http:// code. google. com/ p/ protobuf/]<br />
[4] C-Bindings für Googles Protocol Buffers:<br />
[http:// code. google. com/ p/protobuf‐c/]<br />
[5] Iproute2: [https:// www. kernel. org/ pub/ linux/<br />
utils/ net/ iproute2/]<br />
[6] CRIU-RPC: [http:// criu. org/ RPC]<br />
[7] libcriu: [http:// criu. org/ C_API]<br />
[8] Unterstützte Programme: [http:// criu. org/<br />
What_software_is_supported]<br />
[9] Einfrieren von TCP-Verbindungen:<br />
[http:// criu. org/ TCP_connection]<br />
verbleiben nur die Unterschiede zur<br />
zweiten Sicherung. Liegen bereits inkrementelle<br />
Sicherungen vor, reduziert<br />
die Aktion »dedup« diese nachträglich<br />
auf die Unterschiede:<br />
criu dedup ‐D ~/checkpoint/2/<br />
Stolperfallen<br />
Das Einfrieren und Auftauen von Prozessen<br />
funktioniert noch nicht mit<br />
jedem Prozess. Die CRIU-Entwickler<br />
führen unter [8] eine kurze Liste offiziell<br />
unterstützter Software, die Programme<br />
wie Make und GCC, Tar, Git,<br />
Apache, MySQL, SSH und MongoDB<br />
umfasst. Grundsätzlich nicht einfrieren<br />
lassen sich Prozesse, die gerade auf<br />
Hardware-Geräte zugreifen, egal ob es<br />
sich dabei um Block- oder Character-<br />
Devices handelt. Das hat zwei Gründe:<br />
Die genaue Funktionsweise des Geräts<br />
bleibt CRIU verborgen und beim Wiederherstellen<br />
eines Prozesses könnte<br />
das Gerät fehlen.<br />
Da CRIU die gleichen Schnittstellen<br />
wie ein Debugger verwendet, friert das<br />
Werkzeug außerdem keine Prozesse<br />
ein, die bereits der Beobachtung durch<br />
STrace oder GDB unterliegen. Des<br />
Weiteren sichert CRIU keine Prozesse,<br />
die einen Lock auf eine Datei besitzen,<br />
denn CRIU kann hier nicht feststellen,<br />
ob nicht doch noch einem anderen Prozess<br />
der Zugriff auf die entsprechende<br />
Datei gestattet ist. Der optionale Parameter<br />
»‐‐file‐locks« zwingt CRIU jedoch,<br />
den Lock mitzusichern. Des Weiteren<br />
kommt CRIU in Version 1.1 mit dem<br />
Dateisystem Btrfs nicht zurecht, die<br />
Entwickler arbeiten hier jedoch an einer<br />
Lösung.<br />
Außerdem können sich nach der Wiederherstellung<br />
des Prozesses einige<br />
Werte verändert haben, etwa die IDs<br />
der Mount-Points und die der Sockets<br />
sowie die Startzeit des Prozesses. »cat<br />
/proc/1234/stat« enthüllt letztere Information<br />
beispielsweise für einen Prozess<br />
mit der ID 1234 im Feld 22.<br />
Ins Netz gegangen<br />
Programme, die über eine TCP-Verbindung<br />
kommunizieren, konserviert<br />
CRIU mithilfe des Linux-Kernels. Dabei<br />
schließt es den betroffenen Socket und<br />
blockiert mit einer zusätzlichen Firewall-Regel<br />
die TCP-Verbindung. CRIU<br />
stellt so sicher, dass die Verbindung im<br />
selben Zustand wie beim Speichern<br />
verbleibt. Diese Firewall-Regel muss<br />
deshalb bei der Wiederherstellung des<br />
Prozesses noch in der Netfilter-Table<br />
stehen.<br />
Um den Umgang mit einer TCP-Verbindung<br />
auszulösen, übergibt man CRIU<br />
beim Sichern und Wiederherstellen<br />
den Parameter »‐‐tcp‐established«. Ein<br />
so konservierter Prozess lässt sich nur<br />
genau ein Mal wiederbeleben. Jeder<br />
weitere Versuch scheitert, weil sich die<br />
TCP-Verbindung dann in einem anderen<br />
Zustand befindet. Das CRIU-Wiki<br />
beschreibt die technischen Hintergründe<br />
im Detail unter [9].<br />
CRIU friert nicht nur den Prozess<br />
selbst ein, sondern sicherheitshalber<br />
auch immer dessen Kind- sowie alle<br />
abhängigen Prozesse. Sprechen zwei<br />
Programme über eine Pipe oder einen<br />
Unix-Socket miteinander, legt CRIU<br />
folglich beide gleichzeitig aufs Eis.<br />
In manchen Situationen kann CRIU<br />
jedoch nur einen der beiden Prozesse<br />
einfrieren; dann verweigert CRIU die<br />
Arbeit mit der Fehlermeldung »external<br />
socket is used error«. Über den Parameter<br />
»‐‐ext‐unix‐sk« beim Sichern<br />
und Wiederherstellen lässt sich CRIU<br />
dennoch überreden, zumindest einen<br />
Prozess zu sichern. Beim Wiederherstellen<br />
muss man dann allerdings dafür<br />
sorgen, dass die Gegenstelle bereits<br />
existiert.<br />
Fazit<br />
CRIU bietet äußerst nützliche Funktionalität,<br />
doch angesichts des Zustands<br />
der aktuellen Programmversion ist<br />
beim Produktiveinsatz Vorsicht geboten.<br />
Sie funktioniert zwar, doch wiederbelebte<br />
Programme stürzen gelegentlich<br />
ab. Umfangreiche Vorabtests mit<br />
dem geplanten Setup sind also eine unabdingbare<br />
Voraussetzung. Die CRIU-<br />
Entwicklung schreitet aber in schnellen<br />
Schritten voran und wer Prozesse<br />
einfrieren und migrieren möchte, sollte<br />
CRIU im Auge behalten. Weiterführende<br />
Informationen, einschließlich der hinter<br />
CRIU stehenden Techniken, liefert<br />
das umfangreiche Wiki [1]. (csc) n<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
74<br />
Know-how<br />
CloudFormation<br />
Jan Rose, Fotolia<br />
Automatisierung in der Cloud: Alles über Orchestration<br />
Orchesterprobe<br />
Automatisierung etabliert sich im IT-Umfeld allerorten, auch – oder gerade – in der Cloud. Hier heißt das<br />
Schlagwort: Orchestrierung. Martin Loschwitz<br />
Wann ist Arbeit eigentlich effizient?<br />
Die meisten werden Arbeit dann für<br />
effizient halten, wenn sich durch möglichst<br />
geringen Einsatz möglichst viel<br />
Ertrag erzielen lässt – freilich ohne dass<br />
die Qualität des Produktes leidet und<br />
man so Kunden (oder Arbeitgeber) vergrault.<br />
In der IT gilt seit geraumer Zeit<br />
Automatisierung als ein willkommenes<br />
Werkzeug, um diesem Ziel ein gutes<br />
Stück näher zu kommen. Die Grundidee<br />
besteht darin, regelmäßige Aufgaben<br />
automatisch zu erledigen, statt einen<br />
Mitarbeiter damit zu beschäftigen,<br />
damit der sie manuell ausführt. Mittlerweile<br />
existiert eine stattliche Anzahl<br />
gut funktionierender Werkzeuge für<br />
allgemeine Automatisierungsaufgaben:<br />
Man denke an Puppet, Chef oder Ansible<br />
– sie alle buhlen um die Gunst der<br />
Nutzer.<br />
Im IT-Umfeld haben sich gerade<br />
Service-Provider die Automatisierung<br />
zunutze gemacht, speziell auch solche,<br />
die Cloud-Services anbieten. Schließlich<br />
können sich Anwender in einer<br />
gut geplanten öffentlichen Wolke nach<br />
Herzenslust selbst bedienen und brauchen<br />
den Service-Provider bloß noch<br />
dann persönlich in Anspruch zu nehmen,<br />
wenn mal etwas schief läuft. Aus<br />
Provider-Sicht sind Clouds insofern ein<br />
Segen, denn sie erlauben dem eigenen<br />
Personal an sinnvollen Neuerungen<br />
statt an den ewig gleichen Routineaufgaben<br />
zu arbeiten.<br />
Automatisierung auf Blech<br />
Was für Anbieter paradiesisch klingt,<br />
ist für Anwender zunächst nicht ganz<br />
so erfreulich. Denn die meisten liebgewonnenen<br />
Automatisierungswerkzeuge<br />
tun in der Cloud nicht gar so gut ihren<br />
Dienst. Das liegt an den verschiedenen<br />
Konzepten, die physikalischen und virtuellen<br />
Systemen quasi inhärent sind:<br />
Ein physischer Server ist ein definiertes<br />
Stück Hardware, das in der Regel für<br />
einen spezifischen Zweck angeschafft<br />
und auch eingesetzt wird. Hat der Server<br />
es erstmal ins Rack geschafft, bleibt<br />
er in der Regel dort.<br />
Für die Automatisierung ergeben sich<br />
hieraus gleich mehrere Konsequenzen.<br />
In einem Virtualisierungs-Framework<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Know-how<br />
CloudFormation<br />
75<br />
Abbildung 1: In OpenStack zeichnet Heat für die Orchestrierung verantwortlich. Der Dienst besteht aus einer Processing-Engine und verschiedenen<br />
APIs, die sowohl Amazons CFN-Format als auch das native Heat-Format HOT verstehen.<br />
lässt sich ein physischer Server statisch<br />
behandeln; anhand der MAC-Adressen<br />
seiner Netzwerkkarten lässt er sich<br />
über PXE automatisiert installieren,<br />
und über Puppet, Chef oder eine der<br />
diversen anderen Lösungen verpasst<br />
ihm der Anbieter eine spezifische Konfiguration.<br />
Ganz anders sieht es mit virtuellen<br />
Maschinen aus, die Cloud-Kunden als<br />
Bestandteil ihrer Infrastruktur verwenden.<br />
Zunächst sind Cloud-VMs häufig<br />
volatil: Einmal aus einem vorgebauten<br />
Image gestartet, verschwinden sie<br />
unter Umständen schon bald wieder,<br />
wenn sie nicht mehr benötigt werden.<br />
Fällt eine aus, ist sie leicht zu ersetzen.<br />
Reparieren lohnt sich hier in der Regel<br />
also nicht.<br />
Hinzu kommt, dass sich VMs kaum<br />
sinnvoll mit den üblichen Konfigurationswerkzeugen<br />
automatisieren lassen.<br />
Auf der einen Seite werden Puppet,<br />
Chef & Co. ja immer erst dann aktiv,<br />
wenn die VM schon läuft; sie helfen<br />
dem Benutzer aber nicht dabei, eine<br />
große Menge benötigter VMs zu starten.<br />
Denkbar wäre zu Testzwecken eine<br />
Webserver-Farm, auf der sich die neue<br />
Version einer Website austesten lässt.<br />
Und es wäre zwar technisch möglich,<br />
jeder manuell gestarteten VM mit<br />
Puppet & Co. eine spezifische Aufgabe<br />
zuzuteilen, doch ist es eher mühsam,<br />
für 20 gestartete VMs jeweils einen<br />
Puppet-Eintrag anzulegen und sie dann<br />
mittels Puppet-Agent entsprechend zu<br />
verarzten.<br />
macht und deutlich besser auf Cloud-<br />
Verhältnisse zugeschnitten ist. Über die<br />
AWS-CloudFormation managen Admins<br />
VMs in ihrer Wolke effizient und schnell.<br />
Das Prinzip gefiel selbst den Open-<br />
Stack-Entwicklern so gut, dass sie eine<br />
CloudFormation-Engine auch für ihr<br />
Projekt bauten, die mit Amazons Version<br />
sogar kompatibel ist (Abbildung 1).<br />
Im Folgenden vermittelt dieser Artikel<br />
einen Eindruck der Orchestrierungsmöglichkeiten<br />
in privaten und öffentlichen<br />
Clouds auf Grundlage von AWS-<br />
CloudFormation – die AWS-Version und<br />
die OpenStack-Komponente sind dabei<br />
mit Blick auf grundlegende Funktionen<br />
ebenbürtig.<br />
Voraussetzung für eine funktionierende<br />
Orchestrierung sind im Wesentlichen<br />
die Funktionen, die Clouds ohnehin<br />
schon zur Verfügung stellen. Denn<br />
das sich ein Nutzer am webbasierten<br />
Service-Portal einloggen und eine VM<br />
starten kann, ist ja durchaus auch ohne<br />
Orchestrierung kein Problem. In aller<br />
Regel genügt es, den gewünschten<br />
VM-Typ im Hinblick auf die virtuelle<br />
Hardware sowie das gewünschte Betriebsystem<br />
auszuwählen. Nach einem<br />
abschließenden Klick und ein paar<br />
Sekunden Wartezeit steht das neue<br />
System bereits zur Verfügung. Etwaige<br />
Sonderwünsche sind auch möglich – so<br />
ist es kein Problem, eine VM direkt von<br />
persistentem Speicher zu starten oder<br />
ihr nach dem Starten eine öffentliche IP<br />
zuzuteilen, damit sie aus dem Internet<br />
erreichbar ist.<br />
Es soll also keineswegs der Eindruck<br />
entstehen, Orchestrierung erfinde all<br />
diese Funktionen neu; ganz im Gegenteil:<br />
Orchestrierung zielt darauf ab, die<br />
Automatisierung à la Cloud<br />
Effektive Automatisierung in der Wolke<br />
bedingt also ein anderes Vorgehen als<br />
fürs Blech. Amazon hat sich als Vorreiter<br />
im Cloud-Segment quasi eine<br />
eigene Lösung gestrickt, die aus Automatisierung<br />
kurzerhand Orchestrierung<br />
Abbildung 2: Mittels des »template‐validate«-Befehls von Heat können die Autoren von Templates<br />
diese auf syntaktische Korrektheit hin überprüfen.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
76<br />
Know-how<br />
CloudFormation<br />
vorhandene Funktionalität automatisch<br />
nutzbar zu machen. Technisch<br />
gelöst ist das sowohl bei Amazon als<br />
auch bei OpenStack Heat – der Orchestrierungslösung<br />
von OpenStack – über<br />
eine sogenannte Template-Engine.<br />
CloudFormation<br />
Benutzer verfüttern an diese Engines<br />
Textdateien (Templates), die in einer<br />
spezifischen Syntax Befehle enthalten;<br />
die Template-Engine setzt die Befehle<br />
um und führt über die Cloud-Funktionen<br />
die gewünschten Aktionen aus (Listing<br />
1 enthält ein Beispiel-Template).<br />
Spannend ist dabei insbesondere die<br />
Frage, wie umfassend die jeweilige<br />
Template-Engine die angebotenen<br />
Funktionen der Cloud unterstützt, denn<br />
nicht jede Funktion lässt sich automatisch<br />
auch zum Teil von Orchestrierungs-Templates<br />
machen. Nur wenn<br />
die Policy es zulässt, ist eine bestimmte<br />
Aufgabe in der Cloud auch tatsächlich<br />
automatisierbar.<br />
Im AWS-Kontext steht freilich die<br />
CloudFormation-Engine von Amazon<br />
mitsamt der dazugehörigen Template-<br />
Syntax im Fokus der Anwender. Im Web<br />
ist häufig nur von CFN-Templates die<br />
Rede, wenn es um den Amazon-Dienst<br />
geht. De facto ist CloudFormation auch<br />
die Engine mit den meisten Features.<br />
Gekrönt wird der Dienst von einer ausführlichen<br />
Dokumentation, die jede<br />
einzelne Funktion im Detail erläutert<br />
und in den Kontext anderer Funktionen<br />
stellt.<br />
OpenStack Heat<br />
Die Amazon-Engine bringt den anderen<br />
Anbietern von öffentlichen oder auch<br />
privaten Wolken freilich gar nichts;<br />
wer eine eigene Cloud betreibt und<br />
das mit OpenStack tut, hat allerdings<br />
Glück: Seit OpenStack Havana (2013.2)<br />
ist Heat fester Bestandteil der Cloud-<br />
Umgebung – und Heat unterstüzt eine<br />
große Menge der Funktionen (Abbildung<br />
2), die CloudFormation ebenfalls<br />
besitzt. Ein Umbau der Templates<br />
ist dafür nicht nötig, denn Heat kann<br />
CloudFormation-Templates wie auch<br />
Templates im eigenen Format (HOT,<br />
Heat Orchestration Template) lesen<br />
und interpretieren. Die Entwickler weisen<br />
auf ihrer Homepage [1] zwar darauf<br />
hin, dass Heat noch keine Feature-Parität<br />
mit CFN erreicht hat, die wichtigen<br />
Funktionen sind aber samt und sonders<br />
vorhanden – nicht zuletzt auch deshalb,<br />
weil die Schaffung eines eigenen<br />
Template-Formats für Heat anfangs gar<br />
nicht vorgesehen war. Und selbst HOT<br />
orientiert sich syntaktisch sehr stark an<br />
den Amazon-Vorgaben; ein HOT-Template<br />
lässt sich meist sehr leicht so umbauen,<br />
dass auch CFN damit zurecht<br />
kommt. Umgekehrt gilt das auch. Der<br />
einzige zu bemerkende Unterschied ist<br />
die Tatsache, dass CFN-Templates XMLbasiert<br />
sind, während das HOT-Format<br />
auf JSON setzt.<br />
n Listing 1: Amazon-CloudFormation-Template (Teil 1)<br />
Orchestrierte VMs verwalten<br />
Der Fantasie der Autoren sind im Hinblick<br />
auf Orchestrierungsmöglichkeiten<br />
im Grunde keine Grenzen gesetzt;<br />
durchaus üblich ist es, über ein Template<br />
eine Reihe von virtuellen Maschinen<br />
gleichzeitig zu starten. Das bringt<br />
das Problem mit sich, dass die VM-<br />
Situation schnell unübersichtlich wird.<br />
Deshalb setzen die Template-Engines<br />
von Amazon und OpenStack auf Stacks:<br />
Sämtliche durch einen einzelnen Template-Aufruf<br />
gestartete VMs gehören zu<br />
einem Stack, der anschließend separat<br />
administriert werden kann. Will man<br />
also die zuvor im Beispiel gestarteten<br />
Test-VMs schlagartig wieder beenden,<br />
01 {<br />
02 "AWSTemplateFormatVersion" : "2010‐09‐09",<br />
03 <br />
04 "Description" : "AWS CloudFormation Sample Template EC2InstanceSample: Create<br />
05 an Amazon EC2 instance running the Amazon Linux AMI. The AMI is chosen based<br />
06 on the region in which the stack is run. This example uses the default<br />
07 security group, so to SSH to the new instance using the KeyPair you enter, you<br />
08 will need to have port 22 open in your default security group. **WARNING**<br />
09 This template an Amazon EC2 instances. You will be billed for the AWS<br />
10 resources used if you create a stack from this template.",<br />
11 <br />
12 "Parameters" : {<br />
13 "KeyName": {<br />
14 "Description" : "Name of an existing EC2 KeyPair to enable SSH access to<br />
15 the instance",<br />
16 "Type": "String",<br />
17 "MinLength": "1",<br />
18 "MaxLength": "255",<br />
19 "AllowedPattern" : "[\\x20‐\\x7E]*",<br />
20 "ConstraintDescription" : "can contain only ASCII characters."<br />
21 }<br />
22 },<br />
23 <br />
24 "Mappings" : {<br />
25 "RegionMap" : {<br />
26 "us‐east‐1" : { "AMI" : "ami‐7f418316" },<br />
27 "us‐west‐1" : { "AMI" : "ami‐951945d0" },<br />
28 "us‐west‐2" : { "AMI" : "ami‐16fd7026" },<br />
29 "eu‐west‐1" : { "AMI" : "ami‐24506250" },<br />
30 "sa‐east‐1" : { "AMI" : "ami‐3e3be423" },<br />
31 "ap‐southeast‐1" : { "AMI" : "ami‐74dda626" },<br />
32 "ap‐southeast‐2" : { "AMI" : "ami‐b3990e89" },<br />
33 "ap‐northeast‐1" : { "AMI" : "ami‐dcfa4edd" }<br />
34 }<br />
35 },<br />
36 <br />
37 "Resources" : {<br />
38 "Ec2Instance" : {<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Know-how<br />
CloudFormation<br />
77<br />
so ginge das alleine dadurch, den entsprechenden<br />
Stack herunterzufahren.<br />
Stacks können durchaus noch mehr: So<br />
lässt sich bei Amazon festlegen, dass<br />
die Cloud die Zahl der zu einem Stack<br />
gehörenden VMs konstant halten soll.<br />
Selbst wenn in einem solchen Szenario<br />
dann ein Hypervisor-Host ausfiele und<br />
verschiedene VMs des Stacks mit in<br />
den Abgrund reißen würde, kümmerte<br />
sich die Cloud danach selbst darum,<br />
dass neue VMs nachgestartet werden.<br />
Hier ist einer der großen Unterschiede<br />
zwischen Amazon und OpenStack<br />
erkennbar, denn Heat kann einen<br />
Stack zumindest derzeit noch nicht so<br />
umfangreich und wirksam gegen Ausfälle<br />
schützen. Die Entwickler arbeiten<br />
n Listing 1: Amazon-CloudFormation-Template (Teil 2)<br />
allerdings bereits an passenden Features,<br />
die vermutlich Teil der nächsten<br />
OpenStack-Release alias Icehouse sein<br />
werden.<br />
39 "Type" : "AWS::EC2::Instance",<br />
40 "Properties" : {<br />
41 "KeyName" : { "Ref" : "KeyName" },<br />
42 "ImageId" : { "Fn::FindInMap" : [ "RegionMap", { "Ref" : "AWS::Region"<br />
43 }, "AMI" ]},<br />
44 "UserData" : { "Fn::Base64" : "80" }<br />
45 }<br />
46 }<br />
47 },<br />
48 <br />
49 "Outputs" : {<br />
50 "InstanceId" : {<br />
51 "Description" : "InstanceId of the newly created EC2 instance",<br />
52 "Value" : { "Ref" : "Ec2Instance" }<br />
53 },<br />
54 "AZ" : {<br />
55 "Description" : "Availability Zone of the newly created EC2 instance",<br />
56 "Value" : { "Fn::GetAtt" : [ "Ec2Instance", "AvailabilityZone" ] }<br />
57 },<br />
58 "PublicIP" : {<br />
59 "Description" : "Public IP address of the newly created EC2 instance",<br />
60 "Value" : { "Fn::GetAtt" : [ "Ec2Instance", "PublicIp" ] }<br />
61 },<br />
62 "PrivateIP" : {<br />
63 "Description" : "Private IP address of the newly created EC2 instance",<br />
64 "Value" : { "Fn::GetAtt" : [ "Ec2Instance", "PrivateIp" ] }<br />
65 },<br />
66 "PublicDNS" : {<br />
67 "Description" : "Public DNSName of the newly created EC2 instance",<br />
68 "Value" : { "Fn::GetAtt" : [ "Ec2Instance", "PublicDnsName" ] }<br />
69 },<br />
70 "PrivateDNS" : {<br />
71 "Description" : "Private DNSName of the newly created EC2 instance",<br />
72 "Value" : { "Fn::GetAtt" : [ "Ec2Instance", "PrivateDnsName" ] }<br />
73 }<br />
74 }<br />
75 }<br />
CFN-Templates im Detail<br />
Welche Möglichkeiten haben Autoren,<br />
um eigene CFN-Templates zu entwickeln<br />
und so das Starten spezifischer<br />
Stacks zu vereinfachen? Jedes CFN-<br />
Template folgt einer gewissen Grundstruktur.<br />
Das Beispiel in Listing 1 macht<br />
deutlich, dass zunächst die Version<br />
des CFN-Standards anzugeben ist, der<br />
das Template folgt (ähnlich wie bei<br />
anderen Dokumenttypen gibt es auch<br />
von CFN mehrere Releases, sodass die<br />
Versionsangabe dazu dient, die Kompatibilität<br />
mit der konkreten Version<br />
einer Template-Engine sicherzustellen).<br />
Danach folgt eine kurze Beschreibung<br />
des Templates. Die Beschreibung besteht<br />
aus frei wählbarem Text und wird<br />
später auch bei den Eigenschaften des<br />
Stacks angezeigt, sobald mit dem Template<br />
ein solcher gestartet worden ist.<br />
Dann folgen die Parameter, über die<br />
sich spezifische Eigenschaften eines<br />
Stacks steuern lassen (Abbildung 3). Parameter<br />
gibt es in unterschiedlichen Varianten,<br />
den spezifischen Typ legt das<br />
gleichnamige Feld („Type“) fest. Strings<br />
geben Cloud-Nutzern die Option, beliebige<br />
Zeichenketten an das Template<br />
zu liefern; sie sind die am häufigsten<br />
benutzten Parameter. Das Listing 1<br />
zeigt, wie sich Parameter einsetzen lassen:<br />
Über sie bestimmt das Template<br />
beispielsweise die Hardware-Konfiguration<br />
der VM („InstanceType“) und<br />
den Namen des SSL-Schlüssels, den die<br />
neuen VMs mit auf den Weg bekommen<br />
(„KeyPairName“). Zudem lassen sich<br />
auch spezifische Parameter für Images<br />
bestimmen, die dann direkt an die VMs<br />
weitergegeben werden und dort zu entsprechenden<br />
Effekten führen.<br />
Mappings definieren benutzerspezifische<br />
Daten unter allgemeinen Labels.<br />
Beim Starten von VMs in Amazon ist<br />
es beispielsweise üblich, die Region,<br />
in der die VM laufen soll, mit anzugeben<br />
– genauso wie den Kernel, den<br />
das System verwendet. Durch die<br />
Mappings der standardisierten Ortsbeschreibungen<br />
wie „eu-west-1“ auf eine<br />
Architektur und einen Kernel („64“ :<br />
„ami-534a2d52“) legen Admins bereits<br />
im Template fest, welches Image und<br />
welcher Kern für welche Region zum<br />
Einsatz kommt. Unbedingt festlegen<br />
muss der Admin das aber im Template<br />
nicht; stattdessen kann er Nutzern<br />
auch die Wahl lassen, selbst ein geeignetes<br />
Image beim Starten eines Stacks<br />
auszuwählen.<br />
Ressoucenbedarf<br />
Der wichtigste Abschnitt im ganzen<br />
Template ist zweifellos der Abschnitt,<br />
der mit »Resources« betitelt ist.<br />
Denn der legt fest, welche Dienste<br />
die Engine beim Starten eines Stacks<br />
in OpenStack aufruft. Von zentraler<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
78<br />
Know-how<br />
CloudFormation<br />
Abbildung 3: Auch im Dashboard ist die Heat-Integration bereits vorhanden; der Stack erlaubt<br />
beim Starten die detaillierte Angabe vieler Parameter.<br />
n Info<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31827<br />
[1] Heat-Website: [https:// wiki. openstack. org/<br />
wiki/ Heat]<br />
[2] CFN-Dokumentation: [http:// aws. amazon.<br />
com/ de/ documentation/ cloudformation/]<br />
[3] HOT-Template-Format: [http:// docs.<br />
openstack. org/ developer/ heat/ template_<br />
guide/ hot_guide. html]<br />
n Autor<br />
Martin Gerhard Loschwitz arbeitet als Principal<br />
Consultant bei hastexo. Er beschäftigt sich dort intensiv<br />
mit den Themen HA, Distributed Storage und<br />
OpenStack. In seiner Freizeit pflegt er Pacemaker für<br />
Debian.<br />
Bedeutung ist an dieser Stelle insbesondere<br />
»AWS:EC2:Instance«, das<br />
eine neue virtuelle Maschine startet.<br />
Anwender können bei diesem Vorgang<br />
Metadaten angeben, welche die VMs<br />
per HTTP-Request anschließend vom<br />
Cloud-Metadaten-Server abfragen. Metadaten<br />
sind im Cloud-Kontext ein sehr<br />
wichtiges Werkzeug – interpretiert die<br />
VM sie wie gewünscht, dann lässt sich<br />
über Metadaten das Verhalten von VMs<br />
noch steuern, nachdem sie gebootet<br />
wurden.<br />
Am Ende des Templates findet sich<br />
der »Outputs«-Absatz; dieser legt fest,<br />
welche Eigenschaften des Stacks die<br />
Template-Engine für die einzelnen VMs<br />
exponiert, also gesondert anzeigt und<br />
beispielsweise auch abfragbar macht.<br />
Im vorliegenden Beispiel lassen sich<br />
alle Features, die der Admin den VMs<br />
beim Start mit auf den Weg gegeben<br />
hat, zu jedem späteren Zeitpunkt über<br />
die Engine auch wieder in Erfahrung<br />
bringen.<br />
Das dargestellte Template würde<br />
schließlich Windows-Instanzen starten;<br />
es handelt sich allerdings nur um ein<br />
generisches Beispiel und nahezu jede<br />
andere Kombination wäre denkbar.<br />
Auch geht das Beispiel nicht auf die<br />
Möglichkeiten ein, die sowohl Amazon<br />
als auch OpenStack Heat sonst noch so<br />
bieten: Wer in VMs mit Linux spezifische<br />
Pakete nach dem Booten installieren<br />
möchte, kann über einen entsprechenden<br />
Absatz im Template beliebige<br />
Shell-Befehle ausführen. Das ist nicht<br />
selten deutlich komfortabler als die<br />
Arbeit mit dem Metadaten-Server.<br />
Auch die zuvor bereits erwähnten<br />
Skalierbarkeitsparameter wertet das<br />
Beispiel nicht aus – für die wäre im<br />
Template ebenfalls ein eigener Absatz<br />
fällig. Auch im »Resources«-Absatz sind<br />
Erweiterungen fast beliebig denkbar;<br />
CFN stellt viele Funktionen zur Verfügung,<br />
darunter eine, die einer neu<br />
gestarteten VM direkt eine öffentliche<br />
IP-Adresse umhängt – oder die festlegt,<br />
welches Tenant-Netz ein zu startender<br />
Stack verwenden soll. Eine umfassende<br />
Übersicht über die in CFN vorgesehenen<br />
Funktionen und Parameter bietet<br />
die AWS-CFN-Dokumentation auf [2].<br />
Die meisten der dort vorgestellten Befehle<br />
funktionieren auch in Heat, das<br />
eine eigene Dokumentation unter [3]<br />
anbietet.<br />
Fazit<br />
Orchestrierung füllt die Lücke, die Automatisierungswerkzeuge<br />
in der Cloud<br />
nicht schließen konnten. Wer den<br />
Einsatz von Ressourcen in einer Cloud<br />
plant oder selbst eine Cloud betreibt,<br />
der sollte sich mit dem Thema Orchestrierung<br />
jedenfalls sehr genau befassen.<br />
Kein anderer Ansatz ist effizienter, um<br />
in der Praxis Arbeitsschritte einzusparen.<br />
Der vorliegende Artikel kann die<br />
Vielfalt der Optionen im Orchestrierungskontext<br />
nur andeuten, de facto<br />
sind die Möglichkeiten nahezu unbeschränkt.<br />
Und neue Features kommen<br />
stetig hinzu, sowohl bei Amazon als<br />
auch bei OpenStack Heat. Langweilig<br />
wird die Sache in nächster Zeit jedenfalls<br />
nicht. (jcb) n<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Expert Panel<br />
Mobile Enterprise<br />
10.–14.03.2014<br />
Mobility-Trends der Unternehmens-IT<br />
Tägliches Vortragsprogramm<br />
Themenhighlights:<br />
Vorträge und Podiumsdiskussionen zu Mobile Strategy, Mobile Device Management,<br />
Mobile Security, Mobile Lösungen zu CRM / ERP / BI / Office, Service, Instandhaltung,<br />
Logistik, Softwareentwicklung & Systemintegration, u.v.m.<br />
www.cebit.de/de/mobile-enterprise<br />
Powered by<br />
Presented by<br />
pluspol.de<br />
Marketing Kommunikation Internet
80<br />
Security<br />
UEFI-Secure-Boot<br />
Eugenio Marongiu, 123RF<br />
UEFI-Secure-Boot und alternative Betriebssysteme<br />
Einlasskontrolle<br />
Ist es ein nützliches Sicherheitsfeature oder ein Mechanismus, um freie Betriebssysteme auszubremsen?<br />
An UEFI-Secure-Boot scheiden sich die Geister. Aber wie schwierig ist es wirklich, in einer UEFI-Umgebung<br />
ein gängiges Linux zu booten? Hendrik Schwartke, Ralf Spenneberg<br />
Für das Booten eines Computers war<br />
in der Vergangenheit das BIOS zuständig:<br />
Es übernahm die Initialisierung<br />
und den Start des Betriebssystems.<br />
Viele moderne Rechner verwenden<br />
aber inzwischen anstelle des BIOS die<br />
UEFI-Firmware. Das Unified Extensible<br />
Firmware Interface (UEFI) unterstützt<br />
eine einfache Erweiterung der Firmware<br />
durch unterschiedlichste Module.<br />
Dazu gehören zum Beispiel ein<br />
eingebettetes Netzwerkmodul für die<br />
Fernwartung, Module für Digital Rights<br />
Management und die BIOS-Emulation<br />
mit dem Compatibility Support Module<br />
(CSM). UEFI kennt zudem einen Secure-<br />
Boot-Mechanismus. Die Secure-Boot-<br />
Technologie prüft in diesem Fall, ob der<br />
Bootloader mit einem kryptographischen<br />
Schlüssel signiert ist, den eine<br />
in der Firmware enthaltene Datenbank<br />
autorisiert. Durch die Kontrolle der Signatur<br />
des Bootloaders, des Kernels und<br />
möglicherweise weiteren Userspace-<br />
Codes wird die Ausführung unsignierter<br />
Software unterbunden.<br />
Windows 8 ist das erste Betriebssystem,<br />
das diese Funktion nutzt. Damit<br />
kann es die Ausführung von Schadcode<br />
verhindern. Allerdings kann der Eigentümer<br />
des Rechners nun nicht mehr frei<br />
entscheiden, welches Betriebssystem<br />
er installieren kann.<br />
UEFI-Secure-Boot<br />
UEFI-Secure-Boot validiert den Bootvorgang.<br />
Die UEFI-Spezifikation 2.3<br />
definiert dafür die folgenden Komponenten<br />
und Verfahren:<br />
n eine Programmierschnittstelle für<br />
den Zugriff auf kryptographisch<br />
geschützte UEFI-Variablen im Flash-<br />
Speicher,<br />
n ein Format zum Speichern von<br />
X.509-Zertifikaten in UEFI-Variablen,<br />
n ein Verfahren zur Validierung des<br />
Bootloaders und der Treiber mithilfe<br />
von AuthentiCode-Signaturen,<br />
n einen Mechanismus für den Widerruf<br />
(Revocation) kompromittierter Zertifikate<br />
und Signaturen.<br />
UEFI-Secure-Boot unterscheidet die in<br />
Tabelle 1 aufgelisteten Schlüssel (Abbildung<br />
1).<br />
Des Weiteren beschreibt die Spezifikation<br />
zwei Modi, in denen sich Secure<br />
Boot befinden kann. Der <strong>Erste</strong> ist der<br />
Setup Mode. Eine UEFI-Firmware, deren<br />
Secure-Boot-Implementierung in<br />
diesem Modus betrieben wird, schützt<br />
die Zertifikatsspeicher nicht vor Manipulation.<br />
Es ist insbesondere möglich,<br />
aus einem laufenden Betriebssystem<br />
heraus Zertifikate als auch Hashes in<br />
die UEFI-Zertifikatsspeicher einzufügen<br />
oder zu entfernen. Dieser Modus dient<br />
primär zur Einrichtung von Secure<br />
Boot.<br />
Zweitens existiert der User Mode.<br />
Befindet sich eine Secure-Boot-Implementierung<br />
im User Mode, so ist eine<br />
Manipulation der Zertifikatsspeicher<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Security<br />
UEFI-Secure-Boot<br />
81<br />
nur sehr eingeschränkt möglich. Insbesondere<br />
sind Änderungen ohne<br />
Authentifizierung aus einem laufenden<br />
Betriebssystem nicht mehr durchführbar.<br />
Zur Veränderung des db- oder<br />
dbx-Zertifikatsspeichers ist eine Autorisierung<br />
mittels des privaten Schlüssels<br />
eines im KEK-Speicher hinterlegten<br />
Zertifikats nötig. Zur Änderung des<br />
KEK- und PK-Speichers bedarf es hingegen<br />
des privaten Schlüssels des hinterlegten<br />
Plattform-Key-Zertifikats.<br />
Der Wechsel vom User Mode in den<br />
Setup Mode ist zum einen durch das<br />
Entfernen des Plattform Keys möglich.<br />
Dies setzt die Kenntnis des privaten<br />
Schlüssels des installierten Plattform<br />
Keys voraus. Alternativ kann mittels<br />
des UEFI-Setups in den Setup Mode gewechselt<br />
werden. Dabei ist der Zugang<br />
zur Hardware und gegebenenfalls die<br />
Kenntnis von Kennwörtern zur Nutzung<br />
des Setups Voraussetzung.<br />
UEFI-Secure-Boot verhindert nicht die<br />
Installation von Malware oder die Modifikation<br />
des Bootloaders, sondern stellt<br />
dessen Vertrauenswürdigkeit während<br />
des Bootvorgangs sicher. Kann die<br />
Vertrauenswürdigkeit nicht festgestellt<br />
werden, so wird das Booten unterbunden<br />
(vereinfacht in Abbildung 2).<br />
Secure Boot mit Windows<br />
Microsoft unterstützt Secure Boot ab<br />
Windows 8. Jedoch ist Secure Boot<br />
keine zwingende Voraussetzung für die<br />
Funktionstüchtigkeit des Betriebssystems.<br />
Ältere Microsoft-Betriebssysteme<br />
können auf einem System mit aktiver<br />
Secure-Boot-Funktion nicht eingesetzt<br />
n Tabelle 1: Secure-Boot-Keys<br />
Schlüssel<br />
Platform Key (PK)<br />
Key Exchange Key (KEK)<br />
Autorisierte DB (db)<br />
Nicht autorisierte DB (dbx)<br />
werden, weil Microsoft für diese noch<br />
keine signierten Bootloader bereitstellt.<br />
Hardware-Hersteller, die ihre Systeme<br />
mit dem Windows-8-Logo ausstatten<br />
möchten, müssen jedoch UEFI-Secure-<br />
Boot unterstützen und diese Funktion<br />
im Auslieferungszustand aktivieren.<br />
Daher müssen diese Systeme auch<br />
über das notwendige Schlüsselmaterial<br />
in der UEFI-Firmware verfügen.<br />
Hierzu gehört mindestens das<br />
Microsoft-Windows-Production-PCA-<br />
2011-Zertifikat, das von Microsoft für<br />
die Signatur eigener Produkte genutzt<br />
wird. Die Hardware-Hersteller dürfen<br />
weitere Microsoft-Zertifikate – wie das<br />
Microsoft-Corporation-UEFI-CA-2011-<br />
Zertifikat – und eigene Zertifikate in<br />
den UEFI-Speicher ablegen.<br />
UEFI-Secure-Boot wird bisher hauptsächlich<br />
auf Client-Systemen eingesetzt.<br />
Zukünftige Microsoft-Betriebssysteme<br />
werden diese Technologie jedoch<br />
wahrscheinlich auch auf Serversystemen<br />
zur Verfügung stellen oder deren<br />
Nutzung sogar erzwingen.<br />
Secure Boot mit Linux<br />
Um Secure Boot auch mit anderen Betriebssystemen<br />
nutzen zu können, stehen<br />
grundsätzlich drei Möglichkeiten<br />
zur Verfügung:<br />
n Signieren der eigenen Bootloader<br />
durch Microsoft.<br />
n Hinterlegen eines eigenen KEK-<br />
Schlüssels durch den Hardware-Hersteller.<br />
Offenbar verfügt jedoch kein<br />
weiterer Betriebssystemanbieter<br />
über die entsprechende politische<br />
Funktionen<br />
Meist ein Schlüssel des Hardware-Herstellers (OEM), PK erlaubt<br />
die Manipulation der KEK, nur ein einziger PK möglich.<br />
Mehrere Zertifikate möglich, unterschiedliche Schlüssel für<br />
unterschiedliche OS-Anbieter möglich, zum Beispiel: Microsoft<br />
KEK CA; KEK erlaubt die Manipulation der db und<br />
dbx.<br />
Mehrere Zertifikate und Hashes möglich, zum Beispiel: Microsoft<br />
Windows Production CA; zur Identifizierung von vertrauenswürdigem<br />
Code.<br />
Mehrere Zertifikate oder Hashes möglich; zur Identifizierung<br />
von kompromittiertem Code oder Schadcode.<br />
Abbildung 1: Diese Schlüssel können am Secure-<br />
Boot-Prozess beteiligt sein.<br />
Marktmacht, um die Hardware-<br />
Hersteller flächendeckend von der<br />
Installation weiterer KEK-Schlüssel<br />
überzeugen zu können.<br />
n Erzeugen eines eigenen Platform<br />
Key (PK) und Hinterlegen in der<br />
UEFI-Firmware. Durch den Austausch<br />
des Platform Keys wird ein<br />
Zugriff auf alle weiteren Zertifikatsspeicher<br />
möglich. Das Ersetzen eines<br />
Platform Keys bedingt jedoch physischen<br />
Zugang zum System.<br />
Alle von uns untersuchten Betriebssysteme,<br />
die Secure Boot unterstützen,<br />
schlagen den ersten Weg ein. Damit ist<br />
die Installation ihrer Bootloader auf<br />
einem System mit aktivem Secure Boot<br />
und installierten Microsoft-Schlüsselmaterial<br />
möglich. Hierzu bietet Microsoft<br />
einen Signaturdienst an, der<br />
ursprünglich nur für die Signatur von<br />
UEFI-Treibern vorgesehen war. Er<br />
wurde auch auf alternative Bootloader<br />
von Drittanbietern erweitert. Dazu sendet<br />
der Drittanbieter seinen Bootloader<br />
an Microsoft. Die Firma prüft den<br />
Bootloader und sendet ihn mit einer<br />
AuthentiCode-Signatur zurück. Die<br />
Signatur bestätigt nicht den Urheber,<br />
sondern lediglich die Unversehrtheit<br />
des Bootloaders.<br />
Die Signatur erfolgt mit dem Zertifikat<br />
Microsoft Corporation UEFI CA 2011.<br />
Daher ist die Funktionsfähigkeit des<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
82<br />
Security<br />
UEFI-Secure-Boot<br />
Bootloaders nicht auf jeder Hardware<br />
garantiert, denn dieses Zertifikat muss<br />
nach Microsoft-Spezifikation nicht installiert<br />
sein.<br />
Durch das Signieren des Bootloaders<br />
durch Microsoft bestehen grundsätzlich<br />
zwei Gefahren bei dem Einsatz in der<br />
Produktion:<br />
n Microsoft kann das Zertifikat widerrufen.<br />
Würde das Zertifikat durch<br />
Software-Updates in die Revocation-<br />
Abbildung 2: So läuft der Secure-Boot-Vorgang ab. Kann sich der<br />
Bootloader nicht als vertrauenswürdig ausweisen, wird das System<br />
nicht gestartet.<br />
Lists in der UEFI-Firmware gelangen,<br />
erlaubt die Firmware die Nutzung<br />
des entsprechenden Bootloaders<br />
nicht mehr.<br />
n Die Signatur ist nur für eine bestimmte<br />
Zeit gültig. Die UEFI-<br />
Firmware kann den signierten<br />
Bootloader nach Ablauf der Signatur<br />
ablehnen und den Bootvorgang abbrechen.<br />
Wird nicht erneut signiert,<br />
kann das System nicht mehr booten.<br />
Shim<br />
Beim abgesicherten Booten<br />
mithilfe des Signierdienstes<br />
von Microsoft<br />
wird typischerweise der<br />
Bootloader Shim eingesetzt.<br />
Bei Shim handelt<br />
es sich um einen einfach<br />
strukturierten Open-<br />
Source-Bootloader. Er<br />
startet indirekt Bootloader,<br />
die nicht von<br />
Microsoft signiert sind.<br />
Shim kann somit als<br />
Bindeglied zwischen der<br />
von Microsoft geprägten<br />
Secure-Boot-Umgebung<br />
und Betriebssystemen<br />
Dritter eingesetzt werden<br />
(Abbildung 3).<br />
Ermöglicht wird dies unter<br />
anderem durch eine<br />
öffentlich zugängliche<br />
Shim-Version, die von<br />
Microsoft mittels des<br />
Zertifikats Microsoft Corporation<br />
UEFI CA 2011<br />
signiert ist. Aufgrund dieser<br />
Signatur kann Shim<br />
von allen untersuchten<br />
Hardwareplattformen<br />
mittels des jeweiligen<br />
Standardschlüsselmaterials<br />
mit aktivierten<br />
Secure Boot gestartet<br />
werden. Ferner installieren<br />
einige Linux-Systeme<br />
wie etwa Ubuntu 13.04<br />
und Fedora 19 alternative<br />
Versionen von Shim,<br />
die ebenfalls von Microsoft<br />
signiert sind.<br />
Shim überprüft die<br />
Signatur des nächsten<br />
Bootloaders, der zu laden ist. Das<br />
Schlüsselmaterial für diese Verifizierung<br />
kann hierbei aus drei Quellen<br />
stammen:<br />
n Den UEFI-Zertifikatsspeichern db<br />
und dbx,<br />
n der Machine Owner Key List (Mok-<br />
List): einem Shim-eigenen Zertifikatsspeicher,<br />
n einem im Shim-Binary hinterlegten<br />
Zertifikat oder Hash.<br />
Die MokList kann sowohl Zertifikate als<br />
auch Hashes speichern. Die Nutzung<br />
von Zertifikaten bedingt die Signierung<br />
des zweiten Bootloaders. Die MokList<br />
wird zwar ebenso wie die UEFI-spezifischen<br />
Zertifikatsspeicher im NVRAM<br />
der UEFI-Firmware gespeichert, sie ist<br />
jedoch zumindest während des Bootvorgangs<br />
typischerweise ohne Authentifizierung<br />
modifizierbar.<br />
Weil sich Zertifikate direkt in der Binärdatei<br />
von Shim hinterlegen lassen,<br />
kann der Verifizierungsvorgang unabhängig<br />
vom Inhalt der Zertifikatsspeicher<br />
sein. Diesen Weg wählen die<br />
Linux-Distributionen Ubuntu 13.04 und<br />
Fedora 19.<br />
Ist die Verifizierung des zweiten Bootloaders<br />
– typischerweise Grub2 – erfolgreich,<br />
so wird er ausgeführt. Schlägt<br />
sie dagegen fehl, so wird die zu Shim<br />
gehörende Anwendung MokManager<br />
aufgerufen. Der MokManager ermöglicht<br />
es dem Anwender, interaktiv<br />
Zertifikate oder Hashes in die MokList<br />
einzufügen und somit die Ausführung<br />
des zweiten Bootloaders zu erlauben.<br />
Analyse<br />
Da die Secure-Boot-Technologie<br />
weitreichende Auswirkungen auf die<br />
Installation von alternativen Betriebssystemen<br />
in Stand-Alone- und Dual-<br />
Boot-Umgebungen hat, haben die<br />
Autoren des vorliegenden Artikels die<br />
Möglichkeiten und Probleme in diesen<br />
Umgebungen analysiert.<br />
<strong>Erste</strong>s Ziel war die Analyse der in der<br />
UEFI-PreBoot-Umgebung hinterlegten<br />
Module, Schlüssel und Variablen<br />
und ihren Einfluss auf den Start des<br />
Betriebssystems. Betrachtungsgegenstand<br />
waren je eine 64-Bit-x86-<br />
kompatible Plattform der Hersteller HP,<br />
Dell, Lenovo und Medion. Anschließend<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Security<br />
UEFI-Secure-Boot<br />
83<br />
wurde die Einflussmöglichkeit des<br />
Eigentümers einer solchen Hardware-<br />
Plattform auf das durch Secure Boot<br />
kontrollierte Bootverfahren untersucht.<br />
Hierbei standen besonders die folgenden<br />
Fragen im Vordergrund:<br />
n Kann der Anwender Secure Boot<br />
deaktivieren?<br />
n Kann der Anwender alternatives<br />
Schlüsselmaterial in der UEFI-Firmware<br />
hinterlegen?<br />
n Welche Möglichkeiten bietet der<br />
Hardware-Hersteller für die Modifikation<br />
des Schlüsselmaterials?<br />
Darüber hinaus wurde untersucht,<br />
inwieweit sich die Betriebssysteme<br />
Windows 8 Pro, Red Hat Enterprise<br />
Linux 6.4, Ubuntu 13.04, Debian 7.1.0<br />
und Fedora 19 bei aktivem Secure Boot<br />
installieren und nutzen lassen. Gegebenenfalls<br />
wurden Anpassungsschritte<br />
erarbeitet, um das jeweilige Betriebssystem<br />
zusammen mit Secure Boot<br />
benutzen zu können.<br />
Abschließend wurde der Einsatz<br />
von Secure Boot in einer Dual-Boot-<br />
Umgebung bestehend aus Windows<br />
8 Pro und Debian 7.1.0 untersucht.<br />
Hier wurde unter anderem analysiert,<br />
wie Änderungen an der Secure-Boot-<br />
Konfiguration durch ein Betriebssystem<br />
unterbunden werden können und wie<br />
ausgeschlossen werden kann, dass sich<br />
die Betriebssysteme untereinander<br />
beeinflussen.<br />
Hardware-Plattformen<br />
Alle untersuchten Systeme ermöglichen<br />
die Veränderung der Zertifikatsspeicher,<br />
die dem Secure-Boot-Vorgang<br />
zugrunde liegen. Dazu ist aber oft zusätzliche<br />
Software nötig, etwa die unter<br />
einer freien Lizenz stehenden EFI-Tools.<br />
Mittels des UEFI-Setups können bei<br />
allen Systemen die ursprünglich vom<br />
Hersteller ausgelieferten Schlüssel in<br />
den Zertifikatsspeicher geladen werden<br />
und so in den vom Hersteller definierten<br />
Ausgangszustand versetzt werden.<br />
Auch ermöglicht das UEFI-Setup in<br />
allen Fällen den Wechsel in den Setup-<br />
Mode und somit eine anschließende<br />
Modifizierung der Zertifikatsspeicher.<br />
Das gezielte Einfügen oder Entfernen<br />
einzelner Zertifikate oder Hashes<br />
mithilfe des UEFI-Setups ermöglichte<br />
jedoch nur das System von Dell. Bei<br />
allen Rechnern war es aber zumindest<br />
möglich, die Zertifikatsspeicher im<br />
Setup Mode mittels der EFI-Tools zu<br />
modifizieren.<br />
Darüber hinaus boten alle Systeme die<br />
Möglichkeit, Secure Boot zu deaktivieren.<br />
Ferner lieferten alle Hersteller der<br />
untersuchten Systeme die durch die<br />
Windows Hardware Certification Requirements<br />
vorgeschriebenen Zertifikate<br />
einschließlich des optionalen Zertifikats<br />
Microsoft Corporation UEFI CA<br />
2011 mit. Einige Hersteller installierten<br />
darüber hinaus eigene Zertifikate.<br />
Die auf der EFI-Partition vorinstallierte<br />
Software beschränkt sich im Wesentlichen<br />
auf Diagnose-Software der Hersteller.<br />
Auf allen zur Verfügung gestellten Systemen<br />
ist der Anwender somit in der<br />
Lage, auf die Secure-Boot-Funktionalität<br />
Einfluss zu nehmen. Er kann Secure<br />
Boot deaktivieren, in den Setup Modus<br />
versetzen und eigenes Schlüsselmaterial<br />
laden. Hierzu kann er teilweise<br />
die Werkzeuge aus dem UEFI-Setup<br />
nutzen. In den meisten Fällen muss<br />
jedoch auf weitere Werkzeuge, wie zum<br />
Beispiel die EFI-Tools, zurückgegriffen<br />
werden.<br />
Praxistest<br />
Um zu überprüfen, inwieweit aktuelle<br />
Betriebssysteme unter Nutzung von<br />
Secure Boot auf den ausgewählten<br />
Hardware-Plattformen lauffähig sind,<br />
wurden sie auf jeder Plattform testweise<br />
installiert. Es wurde ferner überprüft,<br />
ob das System nach der Installation<br />
ordnungsgemäß startet und somit<br />
grundsätzlich funktionstüchtig ist.<br />
Sofern das jeweilige Betriebssystem<br />
Secure Boot unterstützt, haben wir<br />
dessen Umsetzung analysiert. Ist<br />
eine Unterstützung von Secure Boot<br />
nicht gegeben, so wurden zusätzliche<br />
Schritte geprüft, die das System bei aktivem<br />
Secure Boot einsetzbar machen.<br />
Hierbei steht die Funktionstüchtigkeit<br />
im Vordergrund. Auf eine weitergehende<br />
Beurteilung wird verzichtet. Die<br />
getesteten Betriebssysteme sind:<br />
n Microsoft Windows 8 Pro<br />
n Red Hat Enterprise Linux 6.4<br />
n Ubuntu 13.04<br />
Abbildung 3: So läuft das Booten ab, wenn der Open-<br />
Source-Bootloader Shim im Spiel ist.<br />
n Debian 7.1.0<br />
n Fedora 19<br />
n FreeBSD 9.2<br />
Ergebnisse<br />
Trotz der relativ neuen Technik und der<br />
umfangreichen Spezifikation arbeitet<br />
Secure Boot auf allen untersuchten<br />
Plattformen mit den eingesetzten Betriebssystemen<br />
zusammen. Das Starten<br />
einer signierten UEFI-Anwendung wie<br />
etwa eines Bootloaders funktioniert,<br />
sofern das entsprechende Zertifikat in<br />
dem db-Zertifikatsspeicher der UEFI-<br />
Firmware enthalten ist. Auch wird der<br />
Start einer solchen Anwendung verweigert,<br />
sofern kein passendes Zertifikat in<br />
diesem Zertifikatsspeicher vorhanden<br />
ist. Ebenso funktioniert die Verifikation<br />
von UEFI-Anwendungen anhand von<br />
Hashes problemlos.<br />
Ferner ist die Installation und der Betrieb<br />
der Betriebssysteme Windows 8<br />
Pro, Ubuntu 13.04 und Fedora 19 bei<br />
aktiviertem Secure Boot möglich. Die<br />
ebenfalls untersuchten Betriebssys-<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
84<br />
Security<br />
UEFI-Secure-Boot<br />
teme Red Hat Enterprise Linux 6.4,<br />
FreeBSD 9.2 und Debian 7.1.0 unterstützen<br />
Secure Boot nicht und werden<br />
daher bei deaktiviertem Secure Boot<br />
installiert. Sie lassen sich jedoch mit<br />
relativ geringem Aufwand so modifizieren,<br />
dass sie auch bei aktivem Secure<br />
Boot laufen können.<br />
Bei der Integration von Secure Boot<br />
und dem daraus resultierenden Gewinn<br />
an Sicherheit gibt es jedoch gravierende<br />
Unterschiede. Ebenso ist der<br />
Sicherheitsgewinn bei dem Einsatz von<br />
Ubuntu 13.04 gering. Zwar werden die<br />
Bootloader verifiziert, eine effektive<br />
Überprüfung des Kernels samt seiner<br />
Module findet jedoch nicht statt.<br />
Im Gegensatz hierzu findet bei Fedora<br />
19 nicht nur eine Verifikation der Bootloader,<br />
sondern auch des Kernels und<br />
seiner Module statt.<br />
FreeBSD plant eine ähnliche Umsetzung,<br />
wie sie bereits Fedora nutzt.<br />
Wenngleich Windows 8 Pro ebenfalls<br />
eine Überprüfung des Bootloaders<br />
und des Kernels durchführt, ist eine<br />
Beurteilung der Effektivität der Schutzmaßnahmen<br />
erheblich schwieriger als<br />
bei den untersuchten Linux-Systemen.<br />
Grund ist hierfür hauptsächlich das<br />
komplexe Vorgehen zur Verifikation von<br />
nachträglich zu ladenden Kernelkomponenten<br />
wie zum Beispiel Treibern.<br />
Microsoft setzt hier zur Erkennung von<br />
Schadsoftware auf eine Zusammenarbeit<br />
des Kernels mit Anti-Malware-<br />
Produkten.<br />
Die Effektivität der Schutzfunktionen<br />
hängt daher ganz erheblich von der<br />
Qualität des eingesetzten Produktes<br />
ab. Auch wird die von Microsoft neu<br />
eingeführte ELAM-Technik im Rahmen<br />
dieser Arbeit auf Grund ihrer Komplexität<br />
nicht bewertet. Ferner bieten die<br />
nachfolgend für Debian 7.1.0 aufgeführten<br />
Änderungen, die analog für<br />
Red Hat Enterprise 6.4 und FreeBSD<br />
9.2 durchgeführt werden können, nur<br />
einen geringen Sicherheitsgewinn. Die<br />
Ergebnisse dieser Tests sind in Tabelle 2<br />
zusammengefasst.<br />
Mit eigenen Schlüsseln<br />
Im Folgenden wird gezeigt, wie Debian<br />
7.1.0 in einer Dual-Secure-Boot-Umgebung<br />
neben Windows 8 Pro installiert<br />
und konfiguriert werden kann. Das<br />
Debian-System soll hierbei unabhängig<br />
von den Zertifikaten der Firma<br />
Microsoft bei aktivem Secure Boot betriebsfähig<br />
sein. Die Betriebsfähigkeit<br />
von Windows 8 Pro soll hierdurch nicht<br />
beeinträchtigt werden. Keines der beiden<br />
Systeme soll die UEFI-Zertifikatsspeicher<br />
modifizieren können.<br />
Sofern die Installation der Betriebssysteme<br />
erfolgreich abgeschlossen ist,<br />
muss der Bootloader des Debian-Systems<br />
signiert oder dessen Hash in den<br />
db-Zertifikatsspeicher eingetragen werden.<br />
Das hätte aber einen wesentlichen<br />
Nachteil: Kommt es zu einem Update<br />
des Bootloaders, so fehlt diesem eine<br />
gültige Signatur beziehungsweise der<br />
Hash wird ungültig. Dadurch würden<br />
nachfolgende Bootvorgänge scheitern.<br />
Aus diesem Grund wird ein Secure-<br />
Boot-Preloader genutzt, der durch die<br />
Befehle aus Listing 1 installiert wird.<br />
Im Anschluss hieran wird der Secure-<br />
Boot-Loader signiert. Dazu dient das<br />
Werkzeug »sbsign«, das zu der Werkzeugsammlung<br />
»sbsigntools« gehört.<br />
Durch Ausführung des Befehls<br />
sbsign ‐‐key db.key ‐‐cert db.pem.crtU<br />
/boot/efi/EFI/debian/U<br />
secure‐boot‐preloader.efi<br />
wird der Secure-Boot-Loader signiert.<br />
Hierbei wird davon ausgegangen, dass<br />
der private Schlüssel, der zur Signierung<br />
von UEFI-Anwendungen verwendet<br />
werden soll, in der Datei »db.key«<br />
enthalten ist und dass das zugehörige<br />
Zertifikat in der Datei »db.pem.crt« vorliegt.<br />
Der Signierungsschritt sollte zur<br />
Sicherheit des privaten Schlüssels nicht<br />
auf dem betroffenen System selbst,<br />
sondern in einer sicheren Arbeitsumgebung<br />
stattfinden.<br />
Nach erfolgreicher Einrichtung des<br />
Bootloaders werden die Zertifikatsspeicher<br />
der UEFI-Firmware gezielt<br />
modifiziert. Die Modifikation wird mittels<br />
der EFI-Tools durchgeführt. Hierzu<br />
wird das zugehörige USB-Image zum<br />
Beispiel mithilfe des Kommandos »dd«<br />
auf einen USB-Stick übertragen. Im<br />
Anschluss wird sowohl das Zertifikat<br />
Microsoft Windows Production PCA<br />
2011 als auch die zum eigenen Schlüsselmaterial<br />
zugehörigen Schlüssel (PK,<br />
KEK, db) in ein Format umgewandelt,<br />
das von der UEFI-Firmware verarbeitet<br />
werden kann. Dazu dient der Befehl<br />
»cert‐to‐efi‐sig‐list«, der Bestandteil der<br />
EFI-Tools ist.<br />
Nun wird das Secure-Boot-System der<br />
zu konfigurierenden Plattform über das<br />
UEFI-Setup in den Setup Mode versetzt,<br />
um die Modifikationen der Zertifikatsspeicher<br />
durchführen zu können. Das<br />
genaue Vorgehen hierzu ist plattformspezifisch.<br />
Hiernach wird von dem vorbereiteten<br />
USB-Stick gebootet. Mittels der sich öffnenden<br />
UEFI-Shell wird durch Eingabe<br />
der folgenden Befehle das Werkzeug<br />
»keytool« gestartet. Es stellt eine rudimentäre<br />
textbasierte Oberfläche zur<br />
Modifikation der UEFI-Zertifikatsspeicher<br />
zur Verfügung:<br />
n Tabelle 2: Testresultate<br />
Windows 8 Pro Red Hat Enterprise<br />
Linux 6.4<br />
Debian<br />
7.1.0<br />
FreeBSD<br />
9.2<br />
Ubuntu<br />
13.04<br />
Fedora<br />
19<br />
Wird Secure Boot im Betrieb unterstützt? Ja Nein Nein Nein Ja Ja<br />
Wird Secure Boot bei der Installation unterstützt?<br />
Ja Nein Nein Nein Ja Ja<br />
Ist eine nachträgliche Unterstützung - Ja Ja Ja - -<br />
durch Shim möglich?<br />
Effektiver Umfang der Verifikationskette Bootloader,<br />
Kernel (bedingt)<br />
Shim Shim Shim Shim, Grub Shim, Grub2, Kernel,<br />
Kernelmodule<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Security<br />
UEFI-Secure-Boot<br />
85<br />
fs0:<br />
cd EFI<br />
cd BOOT<br />
KEYTOOL.EFI<br />
Über den Menüpunkt »Edit Keys« wird<br />
ein Untermenü geöffnet, welches es<br />
ermöglicht, die Zertifikatsspeicher PK,<br />
KEK, db, dbx und MokList wie folgt zu<br />
modifizieren:<br />
MokList: Alle eventuell vorhandenen<br />
Zertifikate und Hashes entfernen.<br />
db: Alle eventuell vorhandenen Zertifikate<br />
und Hashes entfernen, Zertifikat<br />
Microsoft Windows Production PCA<br />
2011 einfügen. Eigenes Zertifikat zur<br />
Sig nierung von UEFI-Anwendungen einfügen.<br />
Alternativ kann auch ein Hash<br />
des Bootloaders eingefügt werden.<br />
dbx: Keine Änderungen notwendig.<br />
KEK: Alle eventuell vorhandenen Zertifikate<br />
und Hashes entfernen, eigenes<br />
Zertifikat des KEK einfügen.<br />
PK: Zertifikat des eigenen Plattform-<br />
Keys einsetzen.-<br />
Hierbei ist zu beachten, dass die Modifikation<br />
des PK-Zertifikatsspeichers<br />
der letzte Arbeitsschritt sein muss, da<br />
durch das Einbringen eines Plattform-<br />
Keys der Setup Mode verlassen und in<br />
den User Mode gewechselt wird. Eine<br />
nachträgliche Manipulation der Zertifikatsspeicher<br />
ist dann nur noch über<br />
signierte Updates oder durch Löschen<br />
des Plattform-Keys mithilfe des UEFI-<br />
Setups möglich. Nach diesem Schritt<br />
kann Debian bei aktiviertem Secure<br />
Boot gestartet werden.<br />
Fazit<br />
Abschließend lässt sich festhalten,<br />
dass die UEFI-Implementierungen der<br />
untersuchten Plattformen in Bezug<br />
auf die Umsetzung von Secure Boot –<br />
soweit dies dieser Artikel untersucht<br />
hat – getreu der Spezifikation funktionieren.<br />
Das durch Microsoft im Rahmen<br />
des Windows Hardware Certification<br />
Program vorgeschriebene Zertifikat<br />
Microsoft Windows Production PCA<br />
2011 wie auch das optionale Zertifikat<br />
Microsoft Corporation UEFI CA 2011<br />
liefern alle untersuchten Hardware-<br />
Plattformen aus. Insbesondere durch<br />
Letzteres wird die Funktionstüchtigkeit<br />
von Betriebssystemen, die nicht von<br />
Microsoft bereitgestellt werden, bei<br />
aktiviertem Secure Boot grundsätzlich<br />
ermöglicht.<br />
Des Weiteren unterstützen viele aktuelle<br />
Betriebssysteme wie Windows<br />
8 Pro, Ubuntu 13.04 und Fedora 19<br />
Secure Boot bereits. Die typische<br />
Installation dieser Systeme erzeugt<br />
einen mehr oder weniger umfassenden<br />
Schutz durch Secure Boot. Die<br />
untersuchten Betriebssysteme, welche<br />
Secure Boot von Haus aus nicht unterstützen,<br />
konkret Debian 7.0.1 und Red<br />
Hat Enterprise Linux 6.4, können mit<br />
geringem Aufwand auf allen untersuchten<br />
Hardware-Plattformen bei aktiviertem<br />
Secure Boot lauffähig gemacht<br />
werden.<br />
Secure Boot besitzt das Potenzial, ein<br />
System effektiv vor unautorisierten<br />
Manipulationen zu schützen und die<br />
Sicherheit des Systems deutlich zu erhöhen.<br />
Wenngleich für einen umfassenden<br />
Schutz eines IT-Systems weitere<br />
Maßnahmen erforderlich sind und es<br />
einige Herausforderungen bei der Einführung<br />
von Secure Boot gibt, ermöglicht<br />
Secure Boot dem Eigentümer die<br />
Hoheit über sein IT-System zu bewahren.<br />
Dabei bieten sich dem Anwender<br />
bei handelsüblichen IT-Plattformen in<br />
der Regel keine alternativen Methoden<br />
zur Absicherung des Bootprozesses,<br />
die ähnlich effektiv eingesetzt werden<br />
könnten.<br />
Eine weitere Stärke von Secure Boot<br />
ist, dass der Eigentümer des IT-Systems<br />
entscheiden kann, welche konkreten<br />
Schutzmaßnahmen er für das jeweilige<br />
System umsetzt. Dadurch ist es ihm<br />
möglich, das Verhältnis des Arbeitsaufwandes<br />
zum erzielten Sicherheitsgewinn<br />
zu optimieren. Darüber hinaus<br />
kann er individuelle Sicherheitslösungen<br />
erstellen.<br />
Ein wesentlicher Nachteil des Einsatzes<br />
von Secure Boot besteht darin,<br />
dass zwingend UEFI verwendet werden<br />
muss. Mit Blick auf die Sicherheit<br />
UEFI-kompatibler Firmware gibt es<br />
bislang noch wenig praktische Erfahrung.<br />
Es besteht also durchaus die<br />
gefahr, dass ein potenzieller Sicherheitsgewinn,<br />
der durch Secure Boot<br />
ermöglicht wird, durch (gewollte und<br />
ungewollte) Implementierungsfehler<br />
n Listing 1: Preloader erstellen<br />
01 # <strong>Erste</strong>llen der Konfigurationdatei des<br />
Secure‐Boot‐Preloaders<br />
02 cat
Fedora 20 angeschaut<br />
Schrittmacher<br />
Denis Babenko, 123RF<br />
Die neueste Fedora-Version „Heisenbug“ lag nur wenige Tage nach dem offiziellen zehnten Geburtstag<br />
gerade noch rechtzeitig unterm Weihnachtsbaum. Radikale Umbauten erlauben Fedora-Nutzern einen<br />
Blick in eine mögliche Linux-Zukunft. Dabei ist ein näherer Blick auf den Technologie-Vorreiter nicht nur<br />
für Red-Hat-Admins empfehlenswert. Thomas Drilling<br />
Fedora 20 (Heisenbug) ist dem nach<br />
einem Unfall im Juli verstorben Red-<br />
Hat-Entwickler Seth Vidal gewidmet.<br />
Es ist zwar nicht die Linux-Distribution<br />
mit der größten Verbreitung, sie<br />
spielt aber eine wichtige Rolle im<br />
Linux-Ökosystem, denn keine andere<br />
Linux-Variante bietet mit jedem neuen<br />
Release so viele neue Technologien. Fedora<br />
ist aber nicht nur ein Testbett für<br />
Red Hat Enterprise Linux, sondern setzt<br />
in der Regel wichtige Impulse für die<br />
gesamte Branche. Admins und System-<br />
Integratoren sollten daher einen Blick<br />
auf die neue Fedora-Version [1] werfen,<br />
insbesondere was die Funktionen aus<br />
den Bereichen Server, Cloud und Virtualisierung<br />
betrifft.<br />
Fedora 20 lässt sich in verschiedenen<br />
Varianten beziehen, etwa als Installations-DVD,<br />
als installierbare Live-CD<br />
mit Standard-Gnome-Desktop sowie in<br />
Form verschiedener Live-Medien und<br />
in den Spin-Varianten mit KDE-, LXDEsowie<br />
XFCE-Desktop. Ferner stehen alle<br />
Versionen in der vollständigen Repo-<br />
Übersicht zur Verfügung – seit Fedora<br />
19 übrigens auch als virtuelle Images<br />
im Raw- und QCOW2-Format, die sich<br />
unter anderem direkt in RHEV, Virtual-<br />
Box, AWS und OpenStack verwenden<br />
lassen.<br />
Desktop und<br />
Paketverwaltung<br />
Fedora 20 bootet dank Systemd, bei<br />
dem im Gegensatz zum klassischen<br />
Sys-V-Init sämtliche Prozesse soweit<br />
möglich gleichzeitig starten, sehr zügig.<br />
Wie bei Red Hat Enerprise Linux und<br />
Fedora üblich ist SELinux aktiviert.<br />
Das spürt man im Alltag zwar nicht,<br />
Admins, die sich erstmals mit Fedora<br />
befassen, sollten die Tatsache aber im<br />
Hinterkopf behalten. Dank eines Diagnosewerkzeugs<br />
für SELinux und eines<br />
entsprechenden Indikator-Applets<br />
lassen sich Probleme mit SELinux aber<br />
recht einfach lösen und zwar nicht nur<br />
durch das simple Abschalten von SELinux<br />
oder einen Wechsel in den Permissive<br />
Mode.<br />
Standard-Desktop von Fedora 20 ist<br />
Gnome 3.10, was hier nicht weiter<br />
thematisiert werden soll, weil die Benutzeroberfläche<br />
für Admins eine untergeordnete<br />
Rolle spielt und sich die<br />
Desktop-Umgebungen Gnome Classic<br />
Mode, KDE 4.11, LXDE 0.5.5, XFCE 4.10<br />
oder Openbox 3.5.2 ohnehin wahlweise<br />
im Zuge der Installation oder später<br />
aus den Paketquellen problemlos installieren<br />
lassen. Erwähnenswert ist<br />
aber in diesem Zusammenhang, dass<br />
Fedora in Gnome 3.10 auf ein neues,<br />
ebenfalls auf »packagekit« basierendes,<br />
grafisches Software-Verwaltungswerkzeug<br />
setzt. Im Stil von Ubuntus<br />
Software-Center soll es Einsteigern<br />
das Suchen, Installieren und Entfernen<br />
von Anwendungen erleichtern<br />
und stellt dabei nicht mehr Pakete,<br />
sondern Software in den Mittelpunkt.<br />
Nach dem Debüt in Fedora 20 soll der<br />
neue Software-Installer Gnome-weiter<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Basics<br />
Fedora 20<br />
87<br />
Standard werden. Gleichzeitig wurden<br />
die bisherigen Frontends zu »gnomepackagekit«,<br />
»gpk‐update‐viewer« und<br />
»gpk‐application« entfernt. Sie lassen<br />
sich bei Bedarf aber zurückholen.<br />
DNF löst künftig Yum ab<br />
Für Admins interessanter ist, dass sich<br />
das Fedora-Team wie Vorbild Red Hat<br />
schrittweise vom Kommandozeilenwerkzeug<br />
Yum zugunsten des DNF-<br />
Paketmanagers [2] zu lösen versucht<br />
(Abbildung 1). Der wurde in Fedora 20<br />
von Version 0.3 auf 0.4.10 aktualisiert<br />
und hat nach Ansicht der Fedora-<br />
Entwickler inzwischen funktional das<br />
Leistungsniveau von Yum erreicht. Ob<br />
und wann DNF aber tatsächlich zum<br />
Default-Paketmanager in Fedora wird,<br />
hängt letztlich von der Nutzer-Akzeptanz<br />
ab. In Fedora 20 ist DNF jedenfalls<br />
erstmals parallel zu Yum installiert und<br />
das Fedora-Team ruft ausdrücklich zum<br />
Testen auf.<br />
ARM-Support<br />
Das Fedora-Team hat in Fedora 20 zudem<br />
ARM zu einer der Primär-Architekturen<br />
gemacht, was schlicht bedeutet,<br />
dass die ARM-Version erstmals im ganz<br />
normalen Rahmen der Fedora-Entwicklung<br />
parallel und weitgehend zeitgleich<br />
zu den x86-Varianten vorangetrieben<br />
wurde, sodass die ARM-Installationsmedien<br />
vom Start weg alternativ zum<br />
Download erhältlich sind. Die ARM-<br />
Architektur steht zudem auch in virtuellen<br />
Maschinen zur Verfügung, wenn der<br />
Admin dazu den Standard-Libvirt-Stack<br />
aus KVM/Qemu, Virsh oder Virt-Manager<br />
verwendet und funktioniert dank<br />
der ARM-CPU-Emulation von Qemu in<br />
Fedora 20 [3] sehr gut, nachdem die<br />
Entwickler entsprechende Bugs beseitigt<br />
haben.<br />
Die ARM-Version von Fedora 20 ist für<br />
ARMv7hl kompiliert und unterstützt<br />
damit unter anderem die ARM-Plattformen<br />
Highbank, Pandaboard, Trimslice<br />
und Versatile Express. Die Fedora-<br />
Entwickler arbeiten aber auch an einer<br />
Portierung für die ARMv8-Architektur<br />
mit 64-Bit-ARM-Befehlssatz AArch64.<br />
Ob es bereits von Fedora 20 eine 64-Bit-<br />
ARM-Version geben wird, ist noch nicht<br />
entschieden.<br />
Abbildung 1: Unter den vielen Neuerungen sind die aktualisierte Version 0.4.10 des DNF-Paketmanagers<br />
und der überarbeitete Virt-Manager mit Support für Live-Snapshots interessant.<br />
Virtualisierung<br />
Ferner erlaubt der Libvirt-Client in Fedora<br />
20 das Setzen von Zugriffsregeln<br />
für sämtliche von Libvirt verwalteten<br />
Objekte und API-Aufrufe, wodurch<br />
sich sämtliche Client-Verbindungen<br />
auf einen definierten Satz von Regeln<br />
und Privilegien limitieren lassen. Dazu<br />
stehen drei Access-Level zur Verfügung:<br />
»Unauthenticated access« wird initial<br />
für sämtliche Verbindungen verwendet<br />
(Default) und entspricht dem bisherigen<br />
Verhalten. Darüber hinaus gibt es<br />
in Fedora 20 zwei weitere Access-Level:<br />
»Unrestricted access«, das vollen Zugriff<br />
auf alle API-Operationen erlaubt<br />
und »Restricted« für Read-Only-Access.<br />
Damit können Admins ab sofort<br />
Zugriffsregeln für die beiden neuen<br />
Access-Level definieren.<br />
Zugriffskontrolle in Libvirt<br />
Jeder API-Aufruf in Libvirt erhält damit<br />
einen Satz an Zugriffsregeln, die gegen<br />
jedes verwendete Objekt validiert<br />
werden. Eine umfangreiche Dokumentation<br />
der neuen Policy-Kit-basierten<br />
Zugriffskontrolle in Libvirt steht sowohl<br />
auf der Libvirt-Projektseite [4] als<br />
auch im Fedora-Wiki [5] zur Verfügung.<br />
Erwähnenswert ist in diesem Zusammenhang<br />
auch, dass das Anlegen und<br />
Verwalten von Snapshots mit dem<br />
Virt-Manager viel komfortabler und<br />
einfacher funktioniert, wenn Images im<br />
QCOW2-Format verwendet werden.<br />
Ausstattung für Admins und<br />
Entwickler<br />
Fedora 20 bringt darüber hinaus zum<br />
ersten mal auch Pakete zum Betrieb<br />
der Apache Hadoop-Plattform 2.2<br />
mit. Außerdem ist OpenStack in der<br />
aktuellen Version Havana an Bord.<br />
Ferner steht für das Ausführen von<br />
Java-EE-7-Anwendungen jetzt WildFly<br />
8 als Anwendungsserver zur Verfügung.<br />
Der Name steht neuerdings für die<br />
Community-Version von JBoss. WildFly<br />
8 läuft laut Red Hat besonders schnell<br />
und kommt dank optimierter Speicherverwaltung<br />
mit vergleichsweise wenig<br />
Speicher aus.<br />
Fedora 20 eignet sich auch hervorragend<br />
als Entwicklungsplattform. So<br />
finden sich im Standard-Lieferumfang<br />
neben Ruby on Rails 4.0 auch Perl 5.18<br />
und die C++-Bibliothek Boost 1.54.0.<br />
Für System-Integratoren und Entwickler<br />
ebenfalls interessant: Die schemafreie,<br />
hochperformante, dokumentenorientierte<br />
Open-Source-Datenbank<br />
MongoDB wurde in Fedora 20 auf die<br />
Version 2.4 mit integrierter Volltextsuche<br />
aktualisiert. Außerdem unterstützt<br />
MongoDB 2.4 sogenannte »wider array<br />
of geospatial indexes« und verfügt über<br />
eine Reihe von Sicherheitserweiterun-<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
88<br />
Basics<br />
Fedora 20<br />
Abbildung 2: Der neue Network-Manager ist komfortabler,<br />
einfacher zu handhaben und funktioniert mit<br />
»nmcli« auch von der Kommandozeile.<br />
n Info<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31840<br />
[1] Fedora 20:<br />
[http:// docs. fedoraproject. org/ en‐US/<br />
Fedora/ 20/ html/ Release_Notes/ index. html]<br />
[2] DNF testen:<br />
[https:// lists. fedoraproject. org/ pipermail/<br />
users/ 2013‐December/ 443694. html]<br />
[3] Virt-ARM: [https:// fedoraproject. org/ wiki/<br />
Changes/ Virt_ARM_on_x86]<br />
[4] Libvirt-Access-Control:<br />
[http:// libvirt. org/ aclpolkit. html]<br />
[5] Libvirt-Access-Control Fedora: [https://<br />
fedoraproject. org/ wiki/ Changes/ Virt_ACLs]<br />
[6] Thomas Drilling, Active Directory mit freier<br />
Software, <strong>ADMIN</strong> 01/2014: [http:// www.<br />
admin‐magazin. de/ Das‐Heft/ 2014/ 01/ Active‐<br />
Directory‐mit‐freier‐Software/]<br />
[7] Thorsten Scherf, Der System Security Services<br />
Daemon, <strong>ADMIN</strong> 03/2012: [http:// www.<br />
admin‐magazin. de/ Das‐Heft/ 2012/ 03/ Der‐Sy<br />
stem‐Security‐Services‐Daemon]<br />
[8] Neuer Network-Manager: [http://<br />
fedoraproject. org/ wiki/ Changes/<br />
NetworkManagerCLIAddConnection]<br />
[9] Fedora-20-Release-Notes: [http:// docs.<br />
fedoraproject. org/ en‐US/ Fedora/ 20/<br />
html/ Release_Notes/ sect‐Release_<br />
Notes‐Changes_for_Sysadmin. html]<br />
[10] Systemd 205 – Neue Unit-Typen: [http:// lists.<br />
freedesktop. org/ archives/ systemd‐devel/<br />
2013‐July/ 011679. html]<br />
gen. Darüber hinaus bringen der seit<br />
Längerem in Fedora enthaltene und<br />
auch von Red Hat favorisierte, auf Identity-Management<br />
spezialisierte, freie<br />
Verzeichnisdienst FreeIPA [6] sowie der<br />
»System Security Services Daemon«<br />
(SSSD) [7] eine Reihe von Verbesserungen<br />
im Bereich der Active-Directory-<br />
Integration mit. Apropos Samba: Der<br />
SSSD-Daemon spendiert Fedora 20<br />
auch ID-Mappings für CIFS-Freigaben.<br />
Ferner haben die Fedora-Entwickler die<br />
Unterstützung für TrueCrypt mit »systemd‐cryptsetup«<br />
auch auf Systemd<br />
und damit den Boot-Prozess ausgeweitet,<br />
sodass eine einfache Authentifizierung<br />
beim Boot-Prozess möglich ist.<br />
Neu in Fedora 20 ist eine Infrastruktur<br />
zum gemeinsamen Verwenden von<br />
Zertifikaten für verschiedene Krypto-<br />
Bibliotheken. Das macht das mehrfache<br />
Verwalten unterschiedlicher<br />
Zertifikate für die verschiedenen Verschlüsselungstools<br />
obsolet. Außerdem<br />
haben in Fedora 20 die Unterverzeichnisse<br />
in »/usr/share/doc« keine Versions<br />
nummern mehr, sondern nutzen<br />
nur noch den Paketnamen.<br />
Unter der Haube<br />
Fedora 20 verwendet beim Installieren<br />
von den Standard-Installationsmedien<br />
mit Ausnahme von »netinstall« noch<br />
einen Kernel 3.11.10-301. Ein aktualisierter<br />
Kernel 3.12.6-300 rutscht aber<br />
gleich mit dem ersten System-Update<br />
nach. Als zentrale C-Systembibliothek<br />
fungiert die Glibc 2.18.<br />
Vollständig überarbeitet wurde der Network-Manager<br />
(Abbildung 2). Er erlaubt<br />
jetzt auch das Hinzufügen, Entfernen<br />
und Ändern von Netzwerken mithilfe<br />
des Befehls »nmcli« auf der Kommandozeile<br />
[8] und unterstützt Bonding<br />
und Bridging. Für die Bluetooth-Unterstützung<br />
kommt die neue BlueZ-Version<br />
5 zum Einsatz. Fedora 20 installiert<br />
zudem erstmals kein Sendmail mehr,<br />
weil die Fedora-Entwickler der Ansicht<br />
sind, dass ein Mail Transfer Agent bei<br />
den meisten Nutzern überflüssig ist.<br />
Das sieht für Administratoren freilich<br />
anders aus, allerdings installieren die<br />
in der Regel ohnehin lieber Postfix, der<br />
sich beim Aufruf kompatibel zu Sendmail<br />
verhält.<br />
Ohne Syslog-Daemon<br />
Fedora 20 installiert im Zuge der Aktualisierung<br />
auf Systemd 208 jetzt auch<br />
keinen Syslog-Daemon Rsyslog mehr.<br />
Der ist laut Fedora-Team obsolet, weil<br />
sich der Journald aus dem Systemd-<br />
Paket um das Protokollieren von Ereignissen<br />
kümmern kann.<br />
Admins müssen damit etwas umdenken,<br />
wenn sie Rsyslog nicht einfach<br />
wieder installieren, was problemlos<br />
möglich ist. Äquivalente Lösungen zum<br />
Auswerten der in Fedora 20 standardmäßig<br />
nicht mehr enthaltenen »/var/<br />
log/messages« bietet das Kommando<br />
»journalctl«. So ersetzt etwa »journalctl«<br />
ein »cat /var/log/messages«.<br />
Eine Alternative zu »tail ‐f /var/log/messages«<br />
ist »journalctl ‐f «. Weitere Alternativen<br />
nennt das Fedora-Team in den<br />
Release-Notes [9]. Dank Systemd 208<br />
dürfen sich Fedora-Admins im Rahmen<br />
der Ressourcen-Steuerung via Cgroups<br />
auch mit zwei neuen Unit-Typen<br />
»scopes« und »slices« auseinandersetzen,<br />
die mit der Systemd-Version 205<br />
im Sommer letzten Jahres eingeführt<br />
wurden – Details dazu finden sich in der<br />
Produktankündigung zu Systemd 205<br />
[10] sowie im Changelog.<br />
Fazit<br />
Ein rundes Zwanziger-Release – und<br />
das passend zum zehnten Geburtstag<br />
des Projektes – deutet auf einen ganz<br />
großen Wurf hin. Dass Fedora 20 keiner<br />
ist, sondern ein solides, evolutionäres<br />
Update mit gegenüber Fedora 19 überschaubarer<br />
Anzahl an Neuerungen, hat<br />
zwei Gründe. Bei Fedora gibt es keine<br />
herausragenden Versionen, etwa mit<br />
LTS-Support, denn diese Rolle kommt<br />
ja ohnehin schon Red Hat Enterprise<br />
Linux zu.<br />
Zudem machen Rolling Releases bei einer<br />
Trendsetter-Distribution wie Fedora<br />
ebenfalls keinen Sinn, denn in diesem<br />
Punkt spielt Fedora per Definition ohnehin<br />
an vorderster Front.<br />
Basis für das kommende Red Hat Enterprise<br />
Linux 7, das vor wenigen Wochen<br />
in einer ersten Beta-Version 7 erschienen<br />
ist, soll im Wesentlichen Fedora<br />
19 sein, das sich auch in unseren Langzeittests<br />
als sehr stabil und zuverlässig<br />
erwiesen hat. (ofr) n<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Admin-mAGAZin<br />
im JAhres-Abo<br />
Praktisch anwendbares Wissen und ausführliche<br />
Hintergrundberichte für alle IT-Administratoren<br />
von Linux, Unix und Windows.<br />
NEU!<br />
Ab sofort<br />
monatlich<br />
ihre vorteile<br />
• 12 Ausgaben im Jahr Frei Haus<br />
• Erhalten Sie ihre Ausgabe<br />
schon vor dem offiziellen<br />
Verkaufstermin<br />
• Hintergrund-Wissen für alle<br />
Admins und IT-Entscheider<br />
• inklusive <strong>ADMIN</strong>-Specials<br />
(unter anderem zu IPv6 und SSD)<br />
JETZT ZUgrEifEN<br />
UNd übEr 15% SpArEN!<br />
Jetzt abonnieren:<br />
www.admin-magazin.de/abo<br />
(Printabo 99,90 Euro, digitales Abo nur 89,90 Euro)<br />
• Telefon 07131 / 2707 274 • Fax 07131 / 2707 78 601 • E-Mail: abo@admin-magazin.de •
pzaxe, 123RF<br />
90<br />
Basics<br />
<strong>ADMIN</strong>-Tipps<br />
Die Tipps des Monats<br />
<strong>ADMIN</strong>-Tipps<br />
Pavel Ignatov, 123RF<br />
Hier finden Sie eine Auswahl der im wöchentlichen <strong>ADMIN</strong>-Newsletter erscheinenden Praxistipps.<br />
n Augenschonend arbeiten<br />
Tipps zur Ergonomie am Computer gibt es eine Menge. Um die kleinen<br />
Tools zur Schonung der Handgelenke soll es aber heute nicht gehen. Und<br />
auch nicht um die richtige Position des Monitors, die Genickstarre und Rückenschmerzen<br />
verhindert. Das kleine Programm, das wir heute vorstellen,<br />
färbt den Bildschirm passend zur Tageszeit ein und will damit vor allem<br />
besseren Schlaf ermöglichen.<br />
Nach der Theorie der Macher von f.lux [1] sind Monitore so ausgelegt, dass<br />
sie farblich wie Tageslicht erscheinen. Starrt man nun auch abends und die<br />
halbe Nacht auf gleißende Anzeigen, kann dies zu Schlafstörungen führen,<br />
wie eine ganze Reihe von Studien belegen, die die f.lux-Website aufführt.<br />
Als Gegenmittel passt f.lux die Farbtemperatur des Bildschirms an die aktuelle<br />
Tageszeit an. Das funktioniert im Sommer wie im Winter zuverlässig:<br />
Der Benutzer muss nur seinen Standort eingeben, den Rest erledigt das<br />
Programm. f.lux gibt es für Windows, OS X und Linux, wobei die kürzlich erschienene<br />
neue Windows-Version die meisten Features besitzt, etwa einen<br />
speziellen Modus zum Filmeschauen, der die augenschonende Farbdarstellung<br />
eine Zeit lang deaktiviert.<br />
n Rettung mit LVM<br />
Bei der Rettung eines kaputten Linux-Systems hat sich<br />
eine Chroot-Umgebung schon tausendfach bewährt.<br />
Bootet man von einer beliebigen Linux-DVD, die in<br />
eine Shell führt, muss das Dateisystem des zerschossenen<br />
Linux nur gemountet werden, dann gelangt<br />
man mittels »chroot« in eine Umgebung, in der man<br />
beispielsweise den Grub-Installer neu ausführen kann –<br />
eventuell sind noch Bind-Mounts für die Proc-, Sys- und<br />
Dev-Dateisysteme nötig, aber das ist eine andere Geschichte.<br />
Schwieriger wird das Mounten, wenn es statt klassischer<br />
Partitionen eine Aufteilung mit dem Logical<br />
Volume Manager (LVM) gibt, was bei vielen Linux-Distributionen<br />
die Standard-Einstellung ist. Hier gilt es erst<br />
einmal die Volumes zu finden, bevor man die passende<br />
mounten und dann mit der Wiederherstellung fortfahren<br />
kann. Die Volume Groups gibt der folgende Befehl<br />
aus:<br />
# lvm vgscan ‐v<br />
Als nächstes aktiviert dieser Befehl sie:<br />
# lvm vgchange ‐a y<br />
Die logischen Volumes lassen sich dann so anzeigen:<br />
# lvm lvs ‐‐all<br />
LV VG Attr LSize Pool U<br />
Origin Data% Move Log Copy% Convert<br />
LogVol00 vg_centhost ‐wi‐ao‐‐‐ 297,60g<br />
Schließlich bleibt nur noch, das Logical Volume am gewünschten<br />
Ort zu mounten:<br />
# mount /dev/vg_centhost/LogVol00 /mnt/<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Basics<br />
Admin-Tipps<br />
91<br />
n Ärger mit Disk-UUIDs<br />
Wer nachträglich die Größe einer Linux-<br />
Partition verändern möchte, kann ein<br />
blaues Wunder erleben. Will man nach<br />
dem Booten einer Live-CD wie GParted<br />
etwa die Größe der ersten Partition<br />
ändern, dann geht das nur, wenn man<br />
die nachfolgenden Partitionen für das<br />
Tmpfs und Swap kurzzeitig entfernt.<br />
Soweit kein großes Problem, denn die<br />
sind schnell wieder angelegt und mit<br />
den richtigen Signaturen versehen.<br />
Die Schwierigkeiten treten erst dann<br />
auf, wenn man das alte System wieder<br />
booten möchte, denn beim Neupartitionieren<br />
haben die Partitionen neue<br />
UUIDs bekommen. Eine bekannte<br />
Fehlerquelle ist die Datei »/etc/fstab«,<br />
die statt Partitionsnamen auf manchen<br />
Distributionen die UUIDs der Partitionen<br />
zum Mounten verwendet. Mit einer<br />
Bootdisk oder in einer Rettungs-Shell<br />
ist dieses Problem jedenfalls recht<br />
schnell gelöst.<br />
Auf manchen Linux-Distributionen,<br />
etwa Fedora 19, ist das Problem aber<br />
subtiler: Die UUIDs der Disk sind tief im<br />
System verankert, etwa mit dem Systemd<br />
beziehungsweise Udev, die über<br />
die UUID etwa das Swap-Device ausfindig<br />
machen. Klappt das nicht, startet<br />
der Rechner auch nicht:<br />
Starting Dracut Emergency Shell...<br />
Warning: /dev/disk/by‐uuid/.... does U<br />
not exist<br />
Generating "/run/initramfs/sosreportU<br />
.txt"<br />
Entering emergency mode. Exit the U<br />
shell to continue.<br />
Type "journalctl" to view system logs<br />
Die Schwierigkeit liegt darin, dass Dracut<br />
beim <strong>Erste</strong>llen der initialen RAM-<br />
Disk (initramfs) die UUIDs des Swap-<br />
Devices gespeichert<br />
hat. Nun gibt es zwei<br />
Auswege: entweder per<br />
Hand der Partition die<br />
alte UUID vergeben, die<br />
auch beim fehlgeschlagenen<br />
Boot-Vorgang zu<br />
sehen ist. Mühsam ist<br />
dabei nur, sie von Hand<br />
abzutippen, denn in der<br />
Rettungskonsole gibt es<br />
typischerweise kein simples<br />
Cut-and-Paste. Außerdem<br />
muss man dazu<br />
das Tool »mkswap« verwenden,<br />
denn »tune2fs«,<br />
über das man normalerweise<br />
Partitions-UUIDs<br />
setzt, funktioniert bei Swap-Partitionen<br />
nicht:<br />
mkswap ‐U 6220f21b‐32f8‐40ac‐ac8d‐U<br />
f82e112568f8 /dev/sda2<br />
Der andere Weg besteht darin, mit Dracut<br />
die initiale RAM-Disk neu zu schreiben.<br />
Zuerst legt man in der Rettungs-<br />
Shell ein Verzeichnis an, um das Root-<br />
Dateisystem zu mounten. Dann mountet<br />
man die Pseudodateisysteme des<br />
Kernels, die auch im später folgenden<br />
Chroot zur Verfügung stehen sollen:<br />
mkdir /mnt<br />
mount /dev/sda1 /mnt<br />
mount ‐o bind /proc /mnt/proc<br />
mount ‐o bind /sys /mnt/sys<br />
mount ‐o bind /dev /mnt/dev<br />
chroot /mnt<br />
Nun bleibt nur noch, mit Dracut das<br />
Init ramfs neu zu schreiben. Weil es<br />
die Datei schon gibt, ist der Schalter<br />
»‐‐force« dazu obligatorisch:<br />
dracut ‐‐regenerate‐all ‐‐force<br />
Wenn man nun die Chroot-Umgebung<br />
wieder verlässt und das System rebootet,<br />
sollte es wie gewohnt starten.<br />
n Info<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31694<br />
[1] f.lux - software to make your life better:<br />
[http://justgetflux.com/]<br />
neue Tipps im Newsletter<br />
Jede Woche erscheint in unserem Newsletter ein neuer <strong>ADMIN</strong>-Tipp. Eine Sammlung aller Tipps<br />
finden Sie im Archiv der <strong>ADMIN</strong>-Tipps unter [http:// www. admin‐magazin. de/ News/ Tipps/].<br />
Den Newsletter können Sie unter [http:// www. admin‐magazin. de/ newsletter] abonnieren.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
92<br />
Virtualisierung<br />
SMB 3<br />
Vladimir Kramin, 123RF<br />
Hyper-V mit dem SMB-3-Protokoll<br />
Flotter Feger<br />
Microsoft hat mit dem Server Message Block 3 (SMB 3) in Windows Server 2012 und Windows Server 2012<br />
R2 zahlreiche Verbesserungen eingeführt. Vom schnelleren und stabileren Zugriff auf Netzwerk-Storage<br />
profitiert vor allem Hyper-V. Wir zeigen, was es mit diesen Neuerungen auf sich hat. Thomas Joos<br />
Das SMB-Protokoll ist vor allem als<br />
Grundlage für das Datei-Sharing unter<br />
Windows bekannt und im Zusammenhang<br />
mit Samba auch Linux-Benutzern<br />
ein Begriff. Windows 8.1 und Windows<br />
Server 2012 R2 beherrschen das neuen<br />
SMB-3-Protokoll, das gegenüber der<br />
alten Version über zahlreiche Vorzüge<br />
verfügt. Es wurde zwar bereits mit Windows<br />
Server 2012 eingeführt, aber in<br />
Windows Server 2012 R2 noch einmal<br />
verbessert. Der schnelle Zugriff auf<br />
Netzwerk-Storage kommt vor allem<br />
Enterprise-Anwendungen zugute, etwa<br />
dem SQL Server und den virtuellen<br />
Festplatten von Hyper-V.<br />
Die Festplatten von virtuellen Servern<br />
können mit Windows Server 2012 R2<br />
auch im Netz gespeichert sein, zum<br />
Beispiel auf Dateifreigaben oder auf<br />
iSCSI-Zielen.<br />
Speichert man große Dateien wie die<br />
Festplatten virtueller Server dateibasiert<br />
im Netzwerk, ergeben sich einige<br />
Vorteile gegenüber der blockbasierten<br />
Speicherung. So lassen sich solche<br />
Dateien insbesondere einfacher verwalten.<br />
Das gilt vor allem, wenn sie<br />
auf Dateifreigaben gespeichert sind,<br />
da hier externe Verwaltungswerkzeuge<br />
wegfallen und Workflows zur Verwaltung<br />
nicht verändert werden müssen.<br />
Windows Server 2012 R2 erlaubt die<br />
Verwendung von VHDX-Dateien als<br />
iSCSI-Ziel. Auf diesem Weg können<br />
Hyper-V-Hosts ihre Daten auf iSCSI-<br />
Festplatten speichern, die dann wiederum<br />
mit SMB 3 angebunden sind.<br />
VHDX-Dateien sind außerdem wesentlich<br />
robuster und erlauben eine Größe<br />
von bis zu 64 TByte.<br />
SMB 3 kann auf virtuellen Servern in<br />
Clustern die SMB-Sitzungen von Serverdiensten<br />
und Anwendersitzungen weiterreichen.<br />
Wenn ein virtueller Server<br />
zwischen Cluster-Knoten verschoben<br />
wird, bleiben die Sitzungen aktiv; die<br />
Anwender- und Serverdienste werden<br />
bei diesem Vorgang nicht voneinander<br />
getrennt. Das heißt, neben der höheren<br />
Leistung und besserer Verfügbarkeit<br />
unterstützt SMB 3 auch Hochverfügbarkeit.<br />
Neues in SMB 2.0 und 2.1<br />
SMB wurde seinerzeit von IBM entwickelt<br />
und von Microsoft über den LAN-<br />
Manager in Windows Mitte der 1990er<br />
integriert. Microsoft hat SMB 1.0 angepasst<br />
und bei der Internet Engineering<br />
Task Force (IETF) eingereicht. Außerdem<br />
wurde SMB in CIFS (Common Internet<br />
File System) umbenannt.<br />
Microsoft hat gleich nach der Übernahme<br />
von SMB von IBM mit der Verbesserung<br />
von SMB begonnen. In die<br />
Versionen 2.0 von Windows Vista und<br />
die Version 2.1 von Windows 7 und Windows<br />
Server 2008 hat Microsoft einige<br />
Verbesserungen integriert. Seit Version<br />
2.0 verwendet Microsoft nicht mehr die<br />
Bezeichnung CIFS, da die ursprünglichen<br />
Erweiterungen nur für SMB 1.0<br />
entwickelt wurden. Bei SMB 2.0 spielen<br />
diese keine Rolle mehr.<br />
SMB 2.1 bietet vor allem Leistungsverbesserungen<br />
auch für sehr schnelle<br />
Netzwerke im 10-Gigabit-Bereich. Die<br />
Version unterstützt größere Übertragungseinheiten<br />
(Maximum Transmission<br />
Units, MTU). Außerdem wurde die<br />
Energieeffizienz auf den Clients verbessert.<br />
Clients ab SMB 2.1 können auch<br />
mit aktivierten SMB-Verbindungen in<br />
den Energiesparmodus wechseln.<br />
Verbesserungen in SMB 3.0 sind zum<br />
Beispiel TCP Windows Scaling und Beschleunigungen<br />
im WLAN. Zusätzlich<br />
hat Microsoft die Verbindung zwischen<br />
Client und Server sowie den Cache auf<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Virtualisierung<br />
SMB 3<br />
93<br />
Transparent Failover<br />
erlaubt zum Beispiel,<br />
dass Clients sich mit<br />
einem Dateiserver in<br />
einer Clusterumgebung<br />
verbinden können.<br />
Wenn der virtuelle<br />
Datei-Server auf einen<br />
anderen Cluster-Knoten<br />
verschoben wird,<br />
bleiben die Verbindungen<br />
zu den Clients dennoch<br />
aktiv. In der aktuellen Version von<br />
SMB werden offene SMB-Verbindungen<br />
ebenfalls auf den neuen Knoten umgeleitet<br />
und bleiben aktiv. Der Vorgang ist<br />
für Clients und Hyper-V-Hosts vollkommen<br />
transparent.<br />
Wenn virtuelle Festplatten auf Dateifreigaben<br />
in einem Cluster gespeichert<br />
sind, brechen Serverdienste beim<br />
Verschieben der Serverdienste nicht<br />
mehr ab. Ebenfalls neu in SMB 3.0 ist<br />
SMB Multichannel, bei dem die Bandbreite<br />
von mehreren Netzwerkadaptern<br />
zwischen SMB-3-Clients und SMB-3-<br />
Servern zusammengefasst wird. Dies<br />
eröffnet vor allem zwei Vorteile: Die<br />
Bandbreite wird für erhöhten Durchsatz<br />
auf mehrere Links verteilt. Zusätzlich<br />
bietet die Technik höhere Fehlertoleranz,<br />
wenn einmal eine Verbindung<br />
ausfällt. Die Technik funktioniert ähnlich<br />
wie Multipath I/O (MPIO) für iSCSIund<br />
Fibre-Channel-Netzwerke.<br />
SMB Scale Out verwendet Cluster<br />
Shared Volumes (CSV) für den parallelen<br />
Zugriff auf Dateien über alle<br />
Knoten in einem Cluster. Das erhöht<br />
die Leistung und die Skalierbarkeit von<br />
Serverdiensten, da alle Knoten beteiligt<br />
sind. Die Technologie arbeitet parallel<br />
zu Funktionen wie Transparent Failover<br />
und Multichannel.<br />
Zusätzliche SMB-Leistungsindikatoren<br />
erlauben die Messung der Nutzung<br />
und Auslastung von Dateifreigaben,<br />
einschließlich Durchsatz, Latenz und<br />
IOPS-Management-Reporting. Die<br />
neuen Zähler in der Leistungsüberwachung<br />
von Windows Server 2012 und<br />
Windows Server 2012 R2 unterstützen<br />
die Messung für Client und Server, sodass<br />
die Analyse von beiden Enden der<br />
SMB-3.0-Verbindung möglich ist. Diese<br />
neuen Technologien sind für die Prodem<br />
Client verbessert und optimiert.<br />
Mit der neuen Pipeline-Funktion können<br />
Server mehrere Anforderungen<br />
in die Warteschlange schreiben und<br />
parallel abarbeiten. Diese neue Technik<br />
ähnelt den Buffer Credits in der Fibre-<br />
Channel-Technologie.<br />
Microsoft hat in der aktuellen Version<br />
die Datenbreite auf 64 Bit erweitert.<br />
Das ermöglicht Blockgrößen von mehr<br />
als 64 KByte, was die Übertragung großer<br />
Dateien, etwa virtueller Festplatten<br />
oder Datenbanken, beschleunigt.<br />
Außerdem hat Microsoft die Verbindungen<br />
zwischen Client und Server optimiert.<br />
Das verhindert Verbindungsabbrüche<br />
in unzuverlässigen Netzwerken<br />
wie WLANs oder WAN-Umgebungen.<br />
Neuerungen in SMB 3.0<br />
In Windows Server 2012 hat Microsoft<br />
mit der Version 2.2 von SMB weitere<br />
Verbesserungen integriert. Später<br />
wurden diese Neuerungen als so weitreichend<br />
eingestuft, dass die Version<br />
nachträglich auf 3.0 erhöht wurde. Eine<br />
neue Funktion in SMB 3.0 sind zum<br />
Beispiel die serverbasierten Work loads.<br />
Diese unterstützen Hyper-V und Datenbanken<br />
mit SQL Server 2012/2014.<br />
Hyper-V für SMB beherrscht jetzt UNC-<br />
Pfade als Speicherort von Steuerdateien<br />
virtueller Server. Auch virtuelle<br />
Festplatten können jetzt UNC-Pfade<br />
verwenden, also Dateien direkt im<br />
Netzwerk speichern. Einfach ausgedrückt<br />
heißt das, dass der Speicherort<br />
von virtuellen Festplatten ab Windows<br />
Server 2012 aus einem Universal-<br />
Naming-Convention-Pfad (UNC)<br />
bestehen darf. Sie müssen keinen Laufwerksbuchstaben<br />
mehr verwenden<br />
oder Netzwerklaufwerke umleiten. Es<br />
besteht zum Beispiel jetzt die Möglichkeit,<br />
die Daten auch über einen Dienstnamen<br />
anzusprechen, nicht mehr<br />
ausschließlich über einen physischen<br />
Servernamen wie bei normalen Laufwerksbuchstaben.<br />
SMB 3.0 im Enterprise<br />
SMB 3.0 ist wesentlich robuster, leistungsstärker,<br />
besser skalierbar und<br />
bietet mehr Sicherheit als seine Vorgänger.<br />
Das ist vor allem für große<br />
Umgebungen ein wichtiger Punkt. SMB<br />
Abbildung 1: Virtuelle Festplatten von Servern lassen sich mit einem<br />
Assistenten verschieben.<br />
blemsuche von Leistungsproblemen<br />
und die Sicherstellung des stabilen Datenzugriffs<br />
im Netzwerk praktisch.<br />
Die neue SMB-Verschlüsselung erlaubt<br />
es, die Daten von SMB-Verbindungen zu<br />
verschlüsseln. Diese Technologie ist nur<br />
beim gemeinsamen Einsatz von SMB-<br />
3.0-Clients und ‐Servern aktiv. Wenn<br />
Sie parallel ältere Clients mit SMB 2.0<br />
und SMB 1.0 einsetzen, wird die Verschlüsselung<br />
deaktiviert.<br />
RDMA und Hyper-V<br />
Normalerweise wird bei jeder Aktion,<br />
bei der ein Serverdienst wie Hyper-V<br />
Daten über das Netzwerk sendet, zum<br />
Beispiel bei einer Live-Migration, der<br />
Prozessor belastet. Das liegt daran,<br />
dass der Prozessor Datenpakete für<br />
das Netzwerk erstellen und berechnen<br />
muss. Dazu braucht er wiederum Zugriff<br />
auf den Arbeitsspeicher des Servers.<br />
Ist das Paket zusammengestellt,<br />
leitet der Prozessor es zu einem Zwischenspeicher<br />
auf die Netzwerkkarte<br />
weiter. Hier warten die Pakete auf die<br />
Übertragung und werden dann von der<br />
Netzwerkkarte zum Zielserver oder Client<br />
gesendet. Wenn Datenpakete beim<br />
Server eintreffen, findet der gleiche<br />
Vorgang statt. Diese Vorgänge sind bei<br />
großen Datenmengen, die zum Beispiel<br />
bei der Übertragung virtueller Server<br />
mit der Live-Migration anfallen, sehr<br />
zeit- und rechenintensiv.<br />
Die Lösung für diese Probleme trägt<br />
die Bezeichnung Direct Memory Access<br />
(DMA). Einfach ausgedrückt können die<br />
verschiedenen Systemkomponenten,<br />
zum Beispiel Netzwerkkarten, direkt<br />
auf den Arbeitsspeicher zugreifen, um<br />
Daten zu speichern und Berechnungen<br />
durchzuführen. Dadurch werden der<br />
Prozessor entlastet sowie Warteschlan-<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
94<br />
Virtualisierung<br />
SMB 3<br />
Abbildung 2: Der Status beim Verschieben von virtuellen Festplatten ist<br />
im Hyper-V-Manager zu sehen.<br />
gen und Vorgänge deutlich verkürzt.<br />
Das wiederum erhöht die Geschwindigkeit<br />
des Betriebssystems und der verschiedenen<br />
Serverdienste wie Hyper-V.<br />
Remote Direct Memory Access (RDMA)<br />
ist eine Erweiterung dieser Technologie<br />
um Netzwerkfunktionen. Die Technik<br />
erlaubt die Übertragung des Arbeitsspeicherinhalts<br />
auf einen anderen<br />
Server im Netzwerk sowie den direkten<br />
Zugriff von Windows Server 2012/2012<br />
R2 auf den Arbeitsspeicher eines anderen<br />
Servers. Microsoft hat RDMA bereits<br />
in Windows Server 2012 integriert, aber<br />
in Windows Server 2012 R2 verbessert<br />
und direkt in Hyper-V integriert. Windows<br />
Server 2012/2012 R2 kann die<br />
Technologie automatisch nutzen, wenn<br />
zwei Server mit Windows Server 2012/<br />
2012 R2 im Netzwerk kommunizieren.<br />
RDMA erhöht den Datendurchsatz im<br />
Netzwerk deutlich und verringert die<br />
Latenz bei der Datenübertragung. Auch<br />
das spielt bei der Live-Migration eine<br />
wichtige Rolle.<br />
In Windows Server 2012 R2 können<br />
Cluster-Knoten auf den Arbeitsspeicher<br />
des anderen Cluster-Knotens während<br />
einer Live-Migration zugreifen und auf<br />
diesem Weg extrem schnell virtuelle<br />
Server im laufenden Betrieb durch die<br />
Live-Migration übertragen. Zusätzlich<br />
beherrscht Hyper-V in Windows Server<br />
2012 R2 bei der Live-Migration auch<br />
die Komprimierung der Daten. Diese<br />
neue Technik und die RDMA-Funktion<br />
beschleunigen Hyper-V in schnellen<br />
Netzwerken noch einmal deutlich.<br />
Interessant ist auch das Data Center<br />
Bridging in Windows Server 2012 R2,<br />
das Techniken implementiert, um Datenverkehr<br />
in sehr großen Netzwerken<br />
zu steuern. Beherrschen die eingesetzten<br />
Netzwerkadapter die Funktion Converged<br />
Network Adapter (CNA), können<br />
auf diesem Weg Daten auf Basis von<br />
iSCSI-Datenträger oder RDMA-Techniken<br />
besser genutzt werden – und zwar<br />
zwischen verschiedenen Datenzentren.<br />
Zusätzlich lässt sich auch die Bandbreite<br />
begrenzen, die diese Technologie<br />
nutzt.<br />
Für eine schnelle Kommunikation zwischen<br />
Servern auf Basis von Windows<br />
Server 2012 R2 – vor allem auf Cluster-<br />
Knoten – müssen die Netzwerkkarten<br />
RDMA unterstützen. Sinnvoll ist der<br />
Einsatz vor allem bei sehr großen Datenmengen,<br />
zum Beispiel wenn man<br />
Windows Server 2012/2012 R2 als NAS-<br />
Server, also als iSCSI-Ziel, verwendet<br />
und dort Datenbanken von SQL Server<br />
2012/2014 speichert. Eingeschränkt<br />
kann auch SQL Server 2008 R2 diese<br />
Funktion nutzen, allerdings weder Windows<br />
Server 2008 R2 noch ältere Versionen<br />
von Microsoft SQL Server.<br />
Hyper-V im Netzwerk optimal<br />
betreiben<br />
Sind im Unternehmen mehrere Hyper-<br />
V-Hosts auf Basis von Windows Server<br />
2012 R2 im Einsatz, können sie, wie<br />
erwähnt, mit der neuen Multichannel-<br />
Funktion parallel auf die Daten zugreifen.<br />
Im Einsatz ist diese Technologie<br />
zum Beispiel, wenn die virtuellen Festplatten<br />
von virtuellen Servern nicht auf<br />
dem Hyper-V-Host liegen, sondern auf<br />
Freigaben im Netzwerk.<br />
Die Technologie beschleunigt den<br />
Datenverkehr zwischen Hyper-V-Hosts<br />
und virtuellen Servern und sichert virtualisierte<br />
Serverdienste auch gegen<br />
den Ausfall eines einzelnen SMB-Kanals<br />
ab. Dazu ist weder die Installation eines<br />
Rollendienstes notwendig noch eine<br />
Konfiguration. Alle Vorteile sind bereits<br />
Out-of-the-Box in Windows Server 2012<br />
R2 integriert.<br />
Um diese Funktionen optimal zu nutzen,<br />
müssen die Netzwerkadapter<br />
schnell genug sein. Microsoft empfiehlt<br />
die Installation eines 10-GBit-Adapters<br />
oder den Einsatz von mindestens zwei<br />
1-GBit-Adaptern. Für diese Technik<br />
lässt sich auch die Teamfunktion von<br />
Netzwerkkarten in Windows Server<br />
2012 R2 nutzen. Der Server-Manager<br />
kann Netzwerkadapter zu Teams zusammenfassen,<br />
auch<br />
wenn die Treiber<br />
dies nicht unterstützen.<br />
Auch diese<br />
Teams unterstützen<br />
den SMB-Verkehr.<br />
SMB Direct ist zwischen Servern mit<br />
Windows Server 2012 R2 ebenfalls<br />
automatisch aktiviert. Damit diese<br />
Technologie zwischen Hyper-V-Hosts<br />
eingesetzt werden kann, müssen die<br />
eingebauten Netzwerkadapter die<br />
RDMA-Funktion (Remote Direct Memory<br />
Access) unterstützen und extrem<br />
schnell sein. Am besten sind Karten für<br />
iWARP, Infiniband und RDMA over Converged<br />
Ethernet (RoCE) geeignet.<br />
Speicher-Migration<br />
In Windows Server 2012 R2 gibt es die<br />
Möglichkeit, den Speicherort von virtuellen<br />
Festplatten auf Hyper-V-Hosts zu<br />
ändern. Diesen Vorgang können Sie im<br />
laufenden Betrieb der virtuellen Server<br />
vornehmen. Klicken Sie dazu im Hyper-<br />
V-Manager mit der rechten Maustaste<br />
auf den virtuellen Server, dessen Festplatten<br />
Sie verschieben wollen, und<br />
wählen Sie im Menü »Verschieben«<br />
aus, dann im Assistenten »Speicher<br />
des virtuellen Computers verschieben«<br />
(Abbildung 1).<br />
Im Assistenten bestimmen Sie, ob Sie<br />
nur die Konfigurationsdaten des virtuellen<br />
Servers oder auch die virtuellen<br />
Festplatten verschieben wollen. Außerdem<br />
wählen Sie den Ordner aus, in<br />
dem Hyper-V die Daten des Computers<br />
speichern soll. Während des Vorgangs<br />
läuft der virtuelle Server weiter. Sie sehen<br />
den Status des Vorgangs im Hyper-<br />
V-Manager (Abbildung 2). Während des<br />
Verschiebens der Daten werden die<br />
Anwender nicht vom virtuellen Server<br />
getrennt. Der komplette Vorgang läuft<br />
komplett transparent ab.<br />
Sie können neben Konfiguration,<br />
Snapshots und den virtuellen Festplatten<br />
auch Smart-Paging-Dateien<br />
getrennt speichern. Smart Paging soll<br />
verhindern, dass sich virtuelle Server<br />
nicht mehr starten lassen, weil der gesamte<br />
verfügbare Arbeitsspeicher bereits<br />
zugewiesen ist. Nutzen Sie Dynamic<br />
Memory, besteht die Möglichkeit,<br />
dass andere Server auf dem Host den<br />
gesamten Arbeitsspeicher nutzen.<br />
Die Funktion Smart Paging erlaubt<br />
virtuellen Servern, beim Neustart<br />
Teile der Festplatte des Hosts als Arbeitsspeicher<br />
zu nutzen. Auch diesen<br />
Bereich können Sie daher getrennt<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Virtualisierung<br />
SMB 3<br />
95<br />
verschieben. Nach dem erfolgreichen<br />
Start wird der Festplattenplatz wieder<br />
freigegeben und der virtuelle Server<br />
erhält durch Dynamic Memory wieder<br />
seinen Speicher.<br />
Live-Migration mit SMB<br />
Seit Windows Server 2012 ist es auch<br />
möglich, die Live-Migration auf Hyper-<br />
V-Hosts ohne Cluster zu nutzen und<br />
virtuelle Maschinen zwischen Hyper-V-<br />
Hosts zu replizieren, ohne diese clustern<br />
zu müssen. Ebenfalls neu ist die<br />
Möglichkeit, die virtuellen Festplatten<br />
eines Servers per Live-Migration zu<br />
verschieben. Das heißt, die virtuellen<br />
Server selbst bleiben auf dem aktuellen<br />
Host, nur der Speicherort der Dateien<br />
ändert sich. So können Sie zum Beispiel<br />
die Dateien auf eine Freigabe verschieben.<br />
In Windows Server 2012 R2 hat<br />
Microsoft die Funktionen weiter verbessert:<br />
Speichern Sie Daten im Netzwerk,<br />
profitieren diese Dienste von SMB 3.<br />
Bei Hyper-V-Replica replizieren Sie virtuelle<br />
Server inklusive aller Festplatten<br />
auf andere Server – ebenfalls im laufenden<br />
Betrieb. Als Verbindung ist kein<br />
gemeinsamer Datenträger notwendig,<br />
da auch die virtuellen Festplatten repliziert<br />
werden. In Windows Server<br />
2012 konnten Sie das Synchronisierungsintervall<br />
nur bis zu minimal fünf<br />
Minuten einstellen. Windows Server<br />
2012 R2 bietet die Möglichkeit, alle<br />
30 Sekunden die Daten zwischen den<br />
Hosts replizieren zu lassen. Auf der anderen<br />
Seite lässt sich jetzt das Replikationsintervall<br />
auf bis zu 15 Minuten ausdehnen.<br />
Die Replikation findet über das<br />
Dateisystem und das Netzwerk mit SMB<br />
statt, ein Cluster ist nicht notwendig.<br />
Die Replikationen lassen sich manuell,<br />
automatisiert und nach einem Zeitplan<br />
ausführen (Abbildung 3).<br />
Live-Migration ohne Cluster<br />
Für eine Live-Migration ohne Cluster<br />
klicken Sie mit der rechten Maustaste<br />
auf den virtuellen Server, den Sie verschieben<br />
wollen und wählen Sie im<br />
Kontextmenü die Option »Verschieben«.<br />
Anschließend wählen Sie auf der<br />
Seite »Verschiebungstyp auswählen«<br />
die Option »Virtuellen Computer verschieben«.<br />
Danach suchen Sie den Zielcomputer<br />
aus, auf den Sie den Rechner<br />
verschieben wollen.<br />
Im nächsten Fenster können Sie die<br />
Live-Migration noch genauer spezifizieren.<br />
Sie haben die Möglichkeit, verschiedene<br />
Daten des virtuellen Servers<br />
in unterschiedliche Ordner im Netzwerk<br />
zu verschieben. Oder Sie bewegen alle<br />
Daten des Servers inklusive der virtuellen<br />
Festplatten in einen gemeinsamen<br />
Ordner (Abbildung 4). Liegt die virtuelle<br />
Festplatte eines virtuellen Servers auf<br />
einer Freigabe, können Sie auch nur die<br />
Konfigurationsdateien zwischen den<br />
Hyper-V-Hosts verschieben.<br />
Diesen Vorgang können Sie auch skripten.<br />
Öffnen Sie dazu auf dem Quellserver<br />
eine Powershell-Sitzung und geben<br />
Sie den folgenden Befehl ein:<br />
Move‐VM Virtueller Server ZielserverU<br />
‐IncludeStorage ‐DestinationStoragePath U<br />
Lokaler Pfad auf dem Zielserver<br />
Um Hyper-V mit Live-Migration in einem<br />
Cluster zu betreiben, erstellen Sie<br />
den Cluster und aktivieren die Cluster<br />
Shared Volumes. Windows legt dann<br />
auf der Betriebssystempartition im<br />
Ordner »ClusterStorage« Daten ab.<br />
Diese liegen aber nicht tatsächlich<br />
auf der Festplatte »C:« des Knotens,<br />
sondern auf dem gemeinsamen Datenträger,<br />
dessen Abruf auf den Ordner<br />
»C:\ClusterStorage« umgeleitet ist.<br />
Der Datenträger kann sich auch auf<br />
einem virtuellen iSCSI-Datenträger in<br />
Windows Server 2012 R2 befinden. Die<br />
VHDX-Dateien der VMs liegen in diesem<br />
Ordner und stehen daher allen Knoten<br />
gleichzeitig zur Verfügung.<br />
Cluster in Windows<br />
Server 2012 R2 beherrschen<br />
Dynamic<br />
I/O. Wenn die Datenverbindung<br />
eines<br />
Knotens ausfällt,<br />
kann der Cluster den<br />
Datenverkehr, der für<br />
die Kommunikation<br />
zu den virtuellen Computern<br />
notwendig ist,<br />
automatisch über die<br />
Leitungen des zweiten<br />
Knotens routen, ohne<br />
Abbildung 3: Virtuelle Server kann man inklusive der<br />
Festplatten zwischen Hyper-V-Hosts replizieren.<br />
dazu ein Failover durchführen zu müssen.<br />
Sie können einen Cluster so konfigurieren,<br />
dass die Cluster-Knoten den<br />
Netzwerkverkehr zwischen den Knoten<br />
und zu den CSV priorisieren.<br />
Fazit<br />
Windows Server 2012 R2 und Hyper-V<br />
sind beide darauf ausgelegt, Daten<br />
zentral auf Freigaben im Netzwerk zu<br />
speichern. Allerdings müssen Sie hier<br />
auch die Leistung der verwendeten<br />
Komponenten beachten. Die Netzwerkadapter,<br />
die Server-Hardware und alle<br />
Netzwerkgeräte sowie natürlich die<br />
Verkabelung im Unternehmen müssen<br />
die neuen Funktionen auch unterstützen.<br />
(ofr) n<br />
n Autor<br />
Thomas Joos ist freiberuflicher IT-Consultant und<br />
seit über 25 Jahren in der IT tätig, unter anderem für<br />
Daimler, die Commerzbank und Microsoft. Neben<br />
seinen Projekten schreibt er praxisnahe Fachbücher<br />
und Fachartikel rund um Windows und andere<br />
Microsoft-Themen. Sein Blog ist unter [http://<br />
thomasjoos. wordpress. com] zu finden.<br />
Abbildung 4: Statt einzelner Festplatten lassen sich auch komplette<br />
Server zwischen Hyper-V-Hosts verschieben.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
Galina Peshkova, 123RF<br />
Linux-VMs unter Hyper-V mit Linux Integration Services beschleunigen<br />
Durchs Fenster<br />
Die Linux Integration Services virtualisieren Linux in Hyper-V-Umgebungen schnell und effizient. Nirmal Sharma<br />
Mit Hyper-V gelang Microsoft der Anschluss:<br />
Als die Firma 2008 die Gefahr<br />
erkannte, in Sachen Virtualisierungsund<br />
Cloud-Dienste ins Hintertreffen zu<br />
geraten, brachte sie Hyper-V auf den<br />
Markt. Anfänglich unterstützte es nur<br />
Windows-Systeme, aber die Redmon-<br />
n Unterstützte Betriebssysteme<br />
Microsoft unterstützt momentan die folgenden Distributionen<br />
als virtuelle Linux-Gastmaschinen auf<br />
Hyper-V-Servern:<br />
n Red Hat Enterprise Linux 5.5-5.9, 6.0-6.4, x86 und<br />
x64<br />
n CentOS 5.5-5.9, 6.0-6.4, x86 und x64<br />
n Suse Linux Enterprise Server 10 mit Service Pack<br />
4, SLES 11 mit Service Packs 1-3<br />
n Open Suse 12.1<br />
n Ubuntu 12.04-13.10<br />
n Oracle Linux 6.4<br />
Benutzer von Red Hat Enterprise Linux und CentOS<br />
in Versionen älter als 5.6 benötigen weiterhin Linux<br />
Integration Services Version 2.1.<br />
der merkten schnell, dass sie ohne Linux-Unterstützung<br />
einen großen Anteil<br />
des IT-Markts nicht bedienen konnten.<br />
2009 folgte deshalb ein einfacher Treiber<br />
für Linux-Gastmaschinen (Kasten<br />
„Unterstützte Betriebssysteme“).<br />
Linux Integration Services<br />
Die Basisfunktionalität genügte allerdings<br />
nicht: Microsoft entwickelte in<br />
der Folge die Linux Integration Services<br />
(LIS) als Antwort auf die Nachfrage<br />
nach besserer Performance und Integration<br />
von Linux-Systemen auf einem<br />
Hyper-V-Server. LIS ist das Pendant zu<br />
den VMware-Tools für virtuelle Maschinen<br />
auf einem VMware-ESX-Server.<br />
Ein Linux-Gast läuft auf Hyper-V auch<br />
ohne die Linux Integration Services,<br />
aber die LIS-Tools verschaffen eine<br />
effizientere und umfassende Virtualisierung<br />
sowie eine bessere Integration<br />
in die Hyper-V-Verwaltung fürs Monitoring,<br />
Management und Verteilen<br />
virtueller Linux-Systeme. LIS setzt auf<br />
ein System aus Treibern und Diensten<br />
auf dem Host- und auf dem Gastsystem.<br />
Deswegen müssen die passenden<br />
Pakete auch auf letzterem installiert<br />
werden; manche Distributionen stellen<br />
diese schon bereit.<br />
Die LIS-Treiber verbessern die allgemeine<br />
Performance der virtuellen<br />
Linux-Maschinen, indem sie den direkten<br />
Zugriff auf die Hardware des Hosts<br />
ermöglichen. Die VMBus-Komponente<br />
beschleunigt das System, indem sie eine<br />
zusätzliche Kommunikationsschicht<br />
zwischen Gast und Host aus dem Weg<br />
räumt. Die Dienste hingegen erledigen<br />
spezifische Aufgaben. Der LIS-Zeitsynchronisierungsdienst<br />
hält zum Beispiel<br />
die Uhr einer virtuellen Linux-Maschine<br />
im Einklang mit der des Hyper-V-Hosts.<br />
LIS-Treiber<br />
Die Linux Integration Services enthalten<br />
die folgenden Treiber:<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Virtualisierung<br />
Linux Integration Services<br />
97<br />
Abbildung 1: Eine Hyper-V-Virtualisierung mit einem Windows-Gast, einem virtuellen Linux-System<br />
mit LIS und einem ohne LIS.<br />
muniziert. Das ermöglicht das Modul<br />
»hv_netsvc«.<br />
n Hyper-V Balloon: Virtuelle Windows-<br />
Maschinen unterstützten dynamische<br />
Speicherzuweisung durch eine<br />
Kombination aus der sogenannten<br />
Balloon-Technik und dem Hinzufügen<br />
und Entfernen von RAM im laufenden<br />
Betrieb. Seit Red Hat Enterprise<br />
Linux 6.4 steht ein einfacher<br />
Balloon-Treiber für die dynamische<br />
Speicherverwaltung mit dem Modul<br />
»hv_balloon« auch unter Linux zur<br />
Verfügung. Er entfernt Speicher<br />
dynamisch von einer virtuellen<br />
Maschine. Allerdings fehlt die Möglichkeit,<br />
im laufenden Betrieb neuen<br />
Speicher zuzuweisen.<br />
n Hyper-V-Funktionen ohne LIS<br />
n VMBus: Ein Kommunikationskanal<br />
zwischen virtuellen Linux-Maschinen<br />
und dem Hypervisor. Diese Komponente<br />
spielt eine wichtige Rolle bei<br />
der Performance-Verbesserung von<br />
Linux-Gastmaschinen. VMBus gehört<br />
zu den zentralen Kommunikationsmodulen<br />
von Hyper-V; fehlt dieser<br />
Treiber, operiert eine Linux-Maschine<br />
im weniger effizienten Emulationsmodus.<br />
Auf der Linux-Seite implementiert<br />
das »hv_vmbus«-Modul<br />
die VMBus-Funktionalität.<br />
n VSP und VSC: Gast- und Host-System<br />
kommunizieren miteinander über<br />
zusammengehörige Paare aus Treibern:<br />
Virtueller Service-Provider<br />
(VSP) und Virtueller Service-Client<br />
(VSC). VSPs laufen auf dem Host-<br />
System und warten auf Anfragen<br />
von den zugehörigen VSCs auf den<br />
Clients. Hyper-V kennt vier Typen<br />
von VSP- und VSC-Treibern: Netzwerk,<br />
Grafik, Speicher und Eingabegeräte<br />
(HID); allerdings fehlt bei LIS<br />
die Unterstützung für Grafik-VSCs.<br />
Die VSPs laufen stets in der Elternoder<br />
Root-Partition des Hyper-V-<br />
Hosts, während die VSCs in virtuellen<br />
Linux-Clients mit installierten<br />
Linux Integration Services laufen.<br />
Dazwischen steht der VMBus-<br />
Kommunikationskanal, über den<br />
die VSCs mit ihren zugehörigen VSPs<br />
kommunizieren.<br />
n SCSI-Treiber: Virtuelle Linux-Maschinen<br />
greifen über LIS auf einzelne<br />
oder mehrere SCSI-Controller mit<br />
realen und virtuellen Festplatten<br />
(VHD) zu. Dafür zeichnet in Linux das<br />
Modul »hv_storsvc« verantwortlich.<br />
n IDE-Treiber: LIS unterstützt über das<br />
Modul »ata_piix« den Zugriff auf IDE-<br />
Controller.<br />
n VMBus-Netzwerk-Controller: Einer<br />
virtuellen Maschine auf einem Hyper-V-Server<br />
stehen zwei Arten von<br />
Netzwerkadaptern zur Verfügung:<br />
»Legacy« für die Rückwärtskompatibilität<br />
mit herkömmlichen Linux-<br />
Netzwerktreibern sowie VMBus-<br />
Netzwerk-Controller. Die letzteren<br />
setzen die Linux Integration Services<br />
zwingend voraus. Sie verwenden<br />
den Netzwerk-VSC, der direkt mit<br />
dem Netzwerk-VSP des Hosts komn<br />
Maustreiber: Mit dem »hid_hyperv«-<br />
Modul steht Linux-Gastsystemen unter<br />
Hyper-V volle Mausunterstützung<br />
zur Verfügung.<br />
LIS-Dienste<br />
Neben den genannten Treibern sorgen<br />
die Linux Integration Services für die<br />
folgenden Dienste:<br />
n Zeitsynchronisierung: Der<br />
»Timesync«-Dienst hält die Uhr einer<br />
virtuellen Linux-Maschine auf dem<br />
Stand des Hyper-V-Hosts.<br />
n Gast-Shutdown: Der »shutdown«-<br />
Befehl im Hyper-V-Manager oder im<br />
System Center Virtual Machine Manager<br />
(SCVMM) fährt eine virtuelle<br />
Maschine herunter.<br />
Neben den Treibern und Diensten stellen die Linux Integration Services weitere Hyper-V-Funktionen<br />
zur Verfügung:<br />
n Live-Migration: Dieses Hyper-V-Feature verschiebt virtuelle Maschinen von einem Host auf einen<br />
anderen, ohne ihn anzuhalten.<br />
n Jumbo-Frames: Linux-Gastmaschinen verwenden Ethernet-Frames mit einer über die vom Ethernet-Standard<br />
vorgesehenen Größe von 1518 Byte. Die zusätzliche Kapazität (Payload) erlaubt<br />
höhere Datenübertragungsraten.<br />
n VLAN-Tagging und ‐Trunking: Administratoren versehen virtuelle Netzwerkadapter mit einer oder<br />
mehreren VLAN-IDs. Diese Netzwerkadapter heißen VMBus-Netzwerkadapter; sie stehen einer<br />
Gastmaschine erst nach der Installation der Linux Integration Services zur Verfügung.<br />
n Symmetrisches Multiprozessorsystem (SMP): Die von LIS unterstützten Linux-Distributionen verwenden<br />
mehrere virtuelle Prozessoren in einer virtuellen Maschine. Ihre Anzahl ist nur durch den<br />
Hyper-V-Server begrenzt.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
98<br />
Virtualisierung<br />
Linux Integration Services<br />
Abbildung 2: Unter Linux zeigt der Befehl »modinfo«, ob die LSI-Module<br />
installiert sind.<br />
Abbildung 3: Die LIS-Module in der Initramfs-Konfigurationsdatei<br />
»modules«.<br />
n Heartbeat: Mit dieser Funktion überprüft<br />
der Virtualisierungsserver regelmäßig,<br />
ob eine virtuelle Maschine<br />
noch läuft und reagiert. Ihr Status<br />
erscheint sowohl im Hyper-V-Manager<br />
als auch im SCVMM.<br />
n Datenaustausch: Informationen<br />
über laufende virtuelle Linux-<br />
Maschinen gelangen über den Datenaustauschdienst<br />
(Data Exchange<br />
Service) zum Host. Bei unterstützten<br />
Linux-Maschinen übermittelt diese<br />
Komponente Informationen wie die<br />
Prozessorarchitektur, Kernel-Version,<br />
Domain-Namen, die IPv4- und<br />
IPv6-Adressen sowie die LIS-Version.<br />
Zuständig dafür ist das »hv_utils«-<br />
Modul.<br />
Ein Dienst fehlt in der Liste: Den Client-<br />
Dienst Volume Shadow Copy Service<br />
(VSS) zum <strong>Erste</strong>llen von Snapshots<br />
im laufenden Betrieb gibt es nicht<br />
für Linux-Gastmaschinen. Der Kasten<br />
„Hyper-V-Funktionen ohne LIS“ listet<br />
Features auf, die auch ohne LIS-Treiber<br />
und ‐Dienste zur Verfügung stehen.<br />
LIS gibt Vollgas<br />
Eine virtuelle Linux-Maschine auf einem<br />
Hyper-V-Server weiß nicht, ob ihre<br />
Hardware physisch oder nur virtuell<br />
existiert. Auch in einer virtuellen Umgebung<br />
senden die Betriebssystemkomponenten<br />
Hardware-Zugriffe deshalb<br />
über native Treiber; an dieser Stelle<br />
schaltet sich die Virtualisierungsschicht<br />
ein. Sie fängt Hardware-Zugriffe im<br />
Rahmen der Geräte-Emulation ab. Die<br />
entsprechende Komponente stellt deshalb<br />
stets eine zusätzliche Kommunikationsschicht<br />
zwischen den virtuellen<br />
Maschinen und der Hardware dar.<br />
Microsoft bietet in den Linux Integration<br />
Services spezielle Komponenten<br />
an, um diese zusätzliche Schicht zu<br />
umgehen: Die erwähnten VMBus- sowie<br />
VSP- und VSC-Komponenten verwalten<br />
und beschleunigen so die meisten Gerätezugriffe.<br />
Per Bus vom Client zum Host<br />
Jede Anfrage, die ein VSC in einer virtuellen<br />
Linux-Maschine generiert, empfängt<br />
zunächst der VMBus-Treiber, der<br />
sie weiterleitet. VMBus funktioniert also<br />
als Vermittler zwischen den VSC- und<br />
den VSP-Komponenten.<br />
Abbildung 1 zeigt drei Arten von virtuellen<br />
Maschinen: Einen Windows-Gast,<br />
ein virtuelles Linux-System mit installierten<br />
Linux Integration Services und<br />
ein Linux-System ohne LIS. Der Haupt–<br />
unterschied zwischen den beiden Li-<br />
Abbildung 4: Die LIS-Module werden beim Systemstart geladen.<br />
Abbildung 5: »lsmod« zeigt die LSI-Module an.<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Virtualisierung<br />
Linux Integration Services<br />
99<br />
nux-Gästen besteht darin, dass VMBus<br />
und die VSP- und VSC-Komponenten<br />
nur dem System mit LIS zur Verfügung<br />
stehen.<br />
Jeder Hardware-Zugriff erfolgt über die<br />
Root-Partition des Hyper-V-Servers. Wie<br />
schnell dessen Virtualisierungstreiber<br />
die Zugriffsanfragen beantworten,<br />
hängt von den sendenden Komponenten<br />
ab: Eine Emulation wie ganz rechts<br />
in Abbildung 1, also ohne LIS, verwendet<br />
die nativen Treiber der virtuellen<br />
Maschine für einen Zugriff. Dass Hyper-<br />
V diese Zugriffe abfangen muss, erhöht<br />
die Antwortdauer.<br />
Mit LIS kommt es hingegen zu einem<br />
sogenannten synthetischen Request<br />
durch eine VSC-Komponente des Gastsystems.<br />
So landet der Zugriff direkt in<br />
der Hyper-V-Root-Partition, die ihn an<br />
den entsprechenden VSP weiterleitet.<br />
Die folgenden Befehle in einem Linux-<br />
Gastsystem geben Auskunft darüber,<br />
ob die entsprechenden Module installiert<br />
sind (Abbildung 2):<br />
modinfo hv_netvsc<br />
modinfo hv_storvsc<br />
modinfo hv_vmbus<br />
LIS aufsetzen<br />
Viele Linux-Distributionen enthalten<br />
inzwischen LIS-Unterstützung. Auch bei<br />
ihnen muss sie jedoch vor der Benutzung<br />
aktiviert werden. Die folgenden<br />
Schritte zeigen das Vorgehen beispielhaft<br />
anhand von Ubuntu 12.04; bei<br />
anderen Distributionen kommt es teilweise<br />
zu abweichenden Dateinamen.<br />
Zunächst fügt man die folgenden<br />
LIS-Module mit einem Editor der<br />
»modules«-Datei unter »/etc/initramfs‐tools«<br />
hinzu (Abbildung 3):<br />
hv_vmbus<br />
hv_storvsc<br />
hv_blkvsc<br />
hv_netvsc<br />
Dieser Befehl erzeugt eine neue Initramfs<br />
mit den LIS-Modulen:<br />
sudo update‐initramfs ‐u<br />
Nach einem Neustart stehen die LIS-<br />
Module zur Verfügung (Abbildung 4). Ob<br />
das geklappt hat, lässt sich mit »lsmod«<br />
überprüfen; die »hv«-Module sollten<br />
dann wie in Abbildung 5 in den System-<br />
Logs auftauchen.<br />
Maßgeschneidert<br />
Bei Linux-Distributionen ohne eingebaute<br />
LIS-Unterstützung beginnt die<br />
Installation mit dem Download der<br />
LSI-ISO-Datei von [1], »LinuxICv34.iso«<br />
für die derzeit aktuelle Version 3.4. Sie<br />
enthält RPM-Pakete und Shell-Skripte<br />
für die Installation. Zudem aktualisiert<br />
sie auf Red Hat Enterprise Linux und<br />
CentOS in den Versionen 5.7, 5.8 und<br />
6.0 bis einschließlich 6.3 bestehende<br />
LIS-Installationen.<br />
Nun hängt man die ISO-Datei als CD<br />
in die gewünschte virtuelle Maschine<br />
ein. Darin manövriert man ins zur<br />
n Info<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31734<br />
[1] Download Linux Integration Services 3.4:<br />
[http:// www. microsoft. com/ de‐de/<br />
download/ details. aspx? id=34603]<br />
Distribution passende Verzeichnis,<br />
etwa »RHEL57« für Red Hat Enterprise<br />
Linux oder CentOS 5.7. Die dort vorliegenden<br />
Shell-Skripte »install.sh«<br />
beziehungsweise »install‐rhel‐57.sh«<br />
und »‐58.sh« für RHEL und CentOS<br />
5.7 und 5.8 starten die Installation.<br />
Nach einem anschließenden Neustart<br />
helfen wieder die Kommandos »lsmod«<br />
und »modinfo«, den Erfolg zu überprüfen.<br />
Das Skript »Upgrade.sh« aktualisiert<br />
bestehende LIS-Installationen. Es liegt<br />
in den Verzeichnissen »RHEL6012« und<br />
»RHEL63« für Installationen von Red<br />
Hat Enterprise Linux oder Centos 6.0<br />
bis 6.2 beziehungsweise 6.3 vor.<br />
Die Deinstallation der Linux Integration<br />
Services erfolgt durch das Entfernen<br />
der »hyper‐v«-Pakete, etwa mit »rpm<br />
‐e kmod‐microsoft‐hyper‐v‐3.4‐1<br />
microsoft‐hyper‐v‐3.4«, wobei die Paketnamen<br />
mit der LIS-Version variieren<br />
können; Debian-basierte Distributionen<br />
verwenden statt »rpm« wie gewohnt<br />
»apt‐get«. (csc) n<br />
n Fehler und Einschränkungen<br />
Einigen Einschränkungen unterliegen Linux-Systeme auf Microsofts<br />
Hyper-V-Hosts nach wie vor:<br />
n Eine VHDX-Datei mit Ext3 zu formatieren, funktioniert nur bis zu einer<br />
bestimmten Blockgröße zuverlässig. Als Lösung reduziert man die<br />
Blockgröße der virtuellen Festplatten auf ein MByte oder weniger<br />
oder verwendet das Ext4-Dateisystem.<br />
n Ältere Linux-Varianten, etwa Red Hat Enterprise Linux bis Version 6.0,<br />
unterstützen nur Festplatten mit einer Sektorengröße bis zu 2048<br />
Byte. Mit diesen funktionieren die ab Windows Server 2012 verfügbaren<br />
Platten mit einer Blockgröße von 4096 Byte nicht.<br />
n Virtuelle Maschinen mit Ubuntu 12.04 funktionieren nicht immer problemlos<br />
mit einem herkömmlichen Netzwerkadapter. Die Verwendung<br />
virtueller Hyper-V-Netzwerkadapter löst dieses Problem.<br />
n Damit alle virtuellen Laufwerke in einem Gastsystem sichtbar sind,<br />
müssen die Bezeichner von SCSI-Laufwerken mit »0« beginnen.<br />
n Um einen Fehler im Linux-Kernel zu umgehen, setzt man bei der<br />
Verwendung von mehr als sieben virtuellen Prozessoren die Option<br />
»numa=off« in der Konfigurationsdatei »boot.cfg« des Grub-Bootloaders<br />
im Gastsystem. Dieselbe Option ist auch beim Einsatz von mehr<br />
als 30 GByte Arbeitsspeicher notwendig.<br />
n Entfernt man die Linux Integration Services von einer virtuellen<br />
Maschine mit mehr als einem virtuellen Prozessor, funktioniert das<br />
Herunterfahren dieser Maschine erst nach dem Deaktivieren des<br />
»irqbalance«-Dienstes wieder.<br />
n Den LIS-RPM-Paketen fehlt eine digitale Signatur: Wer sie unter Red<br />
Hat Enterprise Linux mit »rpm ‐K« überprüft, erhält die Meldung<br />
KEYS ARE NOT OK.<br />
n Der Dienst SCVMM 2008 stürzt in virtuellen Maschinen mit LIS-Komponenten<br />
v3.1 für Hyper-V ab. Behoben wird dies durch das Abschalten<br />
des KVP-Daemons im Linux-Gastsystem.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
happystock, 123RF<br />
Programmieren mit Go<br />
Kanalisiert<br />
Viele klassische Programmieraufgaben lassen sich in Go mit wenigen Zeilen Code erledigen. Besonders<br />
elegant ist die parallele Verarbeitung von Tasks mit Goroutinen. Oliver Frommel<br />
Der Workshop in der letzten <strong>ADMIN</strong>-<br />
Ausgabe hat vorgeführt, wie man mit<br />
wenigen Zeilen Go-Code ein kleines<br />
Programm schreibt, das unter Linux<br />
die laufenden Prozesse auflistet [1]. Die<br />
Funktionalität ist rudimentär, aber das<br />
Projekt hat gezeigt, wie man mit Go auf<br />
Dateien und Verzeichnisse zugreift, Unicode<br />
verarbeitet sowie Schleifen und<br />
Funktionen verwendet. Verbesserungsmöglichkeiten<br />
gibt es noch viele, aber<br />
es ist nicht übermäßig sinnvoll, die<br />
Funktionalität des Linux-eigenen »ps«<br />
bis ins Letzte nachzuprogrammieren.<br />
In der letzten Version hat das Beispielprogramm<br />
»lap« für jeden Prozess<br />
aus der UID den Benutzernamen über<br />
die Funktion »user.LookupId()« der<br />
n Listing 1: »usermap«<br />
01 if val, ok := usermap[procData.uid]; ok {<br />
02 procData.user = val<br />
03 } else {<br />
04 user, _ := user.LookupId(procData.uid)<br />
05 procData.user = user.Username<br />
06 usermap[procData.uid] = user.Username<br />
07 }<br />
Go-Standardbibliothek ermittelt. Weil<br />
typischerweise jeder Benutzer eine<br />
Reihe von Prozessen besitzt, kommt es<br />
hier zu einer Menge unnötiger Lookups.<br />
Je nachdem, wie das Betriebssystem<br />
die dafür nötige Funktion »getpwuid()«<br />
implementiert, führt das wiederum zu<br />
vielen Zugriffen auf das Dateisystem.<br />
Deshalb ist hier ein Cache sinnvoll,<br />
der die Zuordnung von der UID zum<br />
Benutzernamen speichert und für den<br />
sich eine Map als Datenstruktur anbietet.<br />
Das Go-Keyword hierfür lautet<br />
»map«, wobei der Schlüssel in eckigen<br />
Klammern steht, gefolgt vom Wert. Das<br />
Builtin »make« initialisiert die Map und<br />
reserviert initial etwas Speicherplatz:<br />
var usermap map[string]string<br />
usermap = make(map[string]string)<br />
Um die Map als Cache für den Benutzer-Lookup<br />
zu verwenden, überprüft<br />
man zuerst, ob sich der gesuchte Wert<br />
schon in der Map befindet. Fehlt er,<br />
schlägt die Funktion »user.LookupId()«<br />
ihn nach und speichert ihn fürs nächste<br />
Mal in der Map. Etwas ungewöhnlich<br />
gestaltet sich die Überprüfung, ob der<br />
Wert schon in der Map steckt. Es gibt<br />
nämlich keine spezielle Funktion dafür<br />
wie in anderen Programmiersprachen<br />
(etwa »hasKey()«), sondern man versucht<br />
den Wert direkt auszulesen und<br />
überprüft dann den gleichzeitig zurückgegebenen<br />
Fehlercode. Packt man den<br />
Aufruf in eine If-Abfrage, geht das in<br />
einer Zeile, und man hat anschließend<br />
gleich den Wert aus der Map, wenn es<br />
ihn gibt:<br />
if val, ok := mymap[key]; ok {<br />
...<br />
Hier wird der Variablen »val« der Hash-<br />
Wert zugewiesen (sofern vorhanden)<br />
und »ok« der Error-Code, den die If-<br />
Abfrage nach dem Semikolon prüft.<br />
Diese Kombination von Zuweisung und<br />
Bedingung ist typisch für Go-Code und<br />
wird als „comma ok“-Idiom bezeichnet.<br />
Der komplette Code-Abschnitt für<br />
das »lap«-Tool ist in Listing 1 zu sehen.<br />
Weiteres Optimierungspotenzial birgt<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
Programmieren<br />
Go<br />
101<br />
das Auslesen der Proc-Dateien, das<br />
beim aktuellen Entwicklungsstand<br />
des Tools noch sequenziell abläuft.<br />
Prinzipiell sind solche Annahmen mit<br />
Vorsicht zu genießen: Man sollte vor<br />
jeder Optimierung erst mit einem Profiler<br />
oder anderen Tools untersuchen,<br />
in welchen Abschnitten ein Programm<br />
wirklich viel Zeit verbringt. So würde<br />
die Parallelisierung von Dateizugriffen<br />
im Normalfall wohl kaum zu einer<br />
Beschleunigung führen, weil der Massenspeicher<br />
(etwa eine Festplatte)<br />
dann der Flaschenhals wäre. Unter<br />
Umständen kann es sogar zu einer<br />
Verschlechterung der Performance<br />
kommen, wenn durch unbedachte Parallelisierung<br />
vorhandene Cache-Effekte<br />
zunichte gemacht werden.<br />
Virtuelle Dateien<br />
Im Beispielfall ist die Situation ein bisschen<br />
anders, weil es sich bei den Proc-<br />
Dateien nur um virtuelle Files handelt,<br />
die der Kernel zur Verfügung stellt, also<br />
ist die Parallelisierung nicht vollkommen<br />
sinnlos. Riesige Performance-<br />
Gewinne lassen sich hier im Normalfall<br />
dennoch nicht erzielen, da die Prozessliste<br />
nicht besonders lang ist, aber der<br />
Fall taugt als Beispiel für die parallele<br />
Verarbeitung in Go.<br />
Zur parallelen Verarbeitung von Aufgaben<br />
bietet Go mit den Goroutinen<br />
ein eigenes Konstrukt an, das ein<br />
Zwischending zwischen Thread und<br />
Prozess darstellt. Eine Goroutine teilt<br />
den Speicher und damit die Variablen<br />
mit dem Hauptprogramm und gegebenenfalls<br />
anderen Goroutinen, was die<br />
Kommunikation vereinfacht. Goroutinen<br />
sind leichter zu handhaben als<br />
Threads, somit weniger fehleranfällig<br />
zu programmieren und verbrauchen<br />
auch noch weniger Ressourcen. Im einfachsten<br />
Fall ist nichts anderes zu tun,<br />
als dem Aufruf einer Funktion ein »go«<br />
voranzustellen:<br />
go doSomeThing();<br />
Damit führt das Programm die Funktion<br />
»doSomeThing()« in einer Goroutine<br />
aus und fährt mit der Ausführung<br />
fort. Wer in einer Goroutine Text ausgibt,<br />
bekommt davon eventuell nichts<br />
zu sehen, weil das Hauptprogramm<br />
vorher fertig ist. Das ist natürlich nicht<br />
im Sinne der Erfinder, die deshalb auch<br />
Synchronisationsmöglichkeiten vorgesehen<br />
haben.<br />
n Listing 2: Channels<br />
01 func sayHello(c chan int) {<br />
02 fmt.Printf("hello")<br />
03 c
102<br />
Programmieren<br />
Go<br />
Abbildung 1: Parallelisiert: Am Ende schreibt die Funktion<br />
das Ergebnis in einen Channel.<br />
n Info<br />
Es gibt die bekannten Mutex-Locks<br />
und Waitgroups, aber der einfachste<br />
und passendste Mechanismus zur<br />
Synchronisation von Goroutinen sind<br />
Channels, die ähnlich funktionieren wie<br />
Unix-Pipes und zur Kommunikation<br />
zwischen Goroutinen vorgesehen sind.<br />
Buffered Channels blockieren bei Leseund<br />
Schreiboperationen nicht (solange<br />
noch Platz ist), ungepufferte Channels<br />
aber schon, weshalb sie sich zur Synchronisation<br />
eignen. Ein Beispiel ist in<br />
Listing 2 zu sehen.<br />
Die Main-Funktion erzeugt mit »make«<br />
einen Channel für Integer-Werte, der<br />
in der folgenden Zeile an die Funktion<br />
»sayHello()« übergeben wird. Weil die<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31823<br />
[1] Oliver Frommel, Programmieren in Go, <strong>ADMIN</strong><br />
2/2014, S. 100: [http:// www. admin‐magazin.<br />
de/ Das‐Heft/ 2014/ 02/ Programmieren‐in‐Go]<br />
[2] Google I/O 2012 – Go Concurrency Patterns:<br />
[http:// www. youtube. com/ watch?<br />
v=f6kdp27TYZs]<br />
Funktion mit »go« als Goroutine<br />
aufgerufen wird, fährt die<br />
Main-Funktion mit der Verarbeitung<br />
fort. Das nun folgende<br />
Statement »
<strong>ADMIN</strong><br />
InklusIve:<br />
IT-Praxis & Strategie<br />
Debian-Version 7.2<br />
JAhRes-DVD 2013<br />
ALLe ArTIkeL des JAHres Auf eINer dVd<br />
INHALT<br />
■ Artikel zu Storage, Backup,<br />
Security, Monitoring,<br />
Virtualisierung u.v.m.<br />
■ Zum Lesen am Bildschirm<br />
oder Ausdrucken: PDF und<br />
HTML-Format<br />
■ Search Engine für<br />
Artikel-Volltext-Suche<br />
Jetzt gleich bestellen!<br />
www.admin-magazin.de/DVD2013 oder 089 - 99 34 11 - 00
Special Conference:<br />
Open Source *<br />
* Früher: Forum Open Source<br />
10.–14.03.2014<br />
In Halle 6!<br />
Tägliches Vortragsprogramm<br />
Hintergrundinformationen aus erster Hand<br />
Themenhighlights:<br />
Automation / Konfigurationsmanagement, Security / Privacy,<br />
Cloud Computing / Virtualisierung, Treiber / Kernel, ARM-Architektur<br />
Auf der Bühne: Hochkarätige Vertreter der Open-Source-Szene, u.a.<br />
Klaus Knopper,<br />
KNOPPER.NET<br />
Jon „maddog“ Hall,<br />
Linux International<br />
Peer Heinlein,<br />
Heinlein Support GmbH<br />
Änderungen vorbehalten.<br />
Powered by<br />
Presented by<br />
www.cebit.de/de/open-source<br />
pluspol.de<br />
Marketing Kommunikation Internet<br />
Sponsored by
freeX<br />
Einführung<br />
105<br />
Sonderteil<br />
Auf der folgenden Seite startet der regelmäßige<br />
FreeX-Sonderteil des <strong>ADMIN</strong>-<strong>Magazin</strong>s. Hier finden<br />
Sie Know-how-Artikel und Workshops von erfahrenen<br />
Autoren aus der langen Tradition der FreeX.<br />
FreeBSD auf Raspberry Pi....................106<br />
Der kleine Rechner auf ARM-Basis ist ein Riesenrenner.<br />
Statt des Standard-OS auf Linux-Basis<br />
lässt sich darauf auch FreeBSD installieren.<br />
ika747, 123RF<br />
www.admin-magazin.de Admin Ausgabe 03-2014
106<br />
freeX<br />
FreeBSD auf dem Raspberry Pi<br />
liv Friis-larsen, 123RF<br />
Raspberry PI<br />
Himbeere mit Sahne<br />
Ein FreeBSD-System auf einem Raspberry Pi ist eine interessante Alternative zu den bekannten Linux-<br />
Systemen. Die Installation geht nicht ganz so leicht von der Hand, aber man wird mit einem äußerst stabilen<br />
System belohnt. Das <strong>ADMIN</strong>-<strong>Magazin</strong> führt durch den Prozess. Jürgen Dankoweit<br />
Der Raspberry Pi kann praktisch alles.<br />
Als preiswerter Einplatinencomputer<br />
in der Größe einer Kreditkarte hat sich<br />
das Gerät der Raspberry-Pi-Foundation<br />
schnell zum Publikumsliebling gemausert<br />
– nicht nur unter Freunden<br />
der vielen eigens angepassten Linux-<br />
Distributionen, sondern auch unter<br />
jenen des ebenfalls freien FreeBSD-<br />
Betriebssystems [1].<br />
Die wichtigste Komponente der Platine<br />
bildet das auf dem Raspberry Pi sitzende<br />
Ein-Chip-System von Broadcom.<br />
Es enthält einen 700-Megahertz-ARM-<br />
Prozessor sowie je nach Modell 256<br />
oder 512 MByte Arbeitsspeicher. Man<br />
spricht von einem System-on-a-Chip<br />
(SoC), da es die drei Komponenten<br />
Mikroprozessor, Grafikprozessor,<br />
Arbeitsspeicher und ein paar Peripheriebausteine<br />
vereint (siehe Abbildung<br />
1). Eine echte Festplattenschnittstelle<br />
fehlt dem Taschencomputer leider.<br />
Stattdessen kommen SD- oder MMC-<br />
Speicherkarten zum Einsatz. Darüber<br />
hinaus lassen sich am USB-Port externe<br />
Festplatten und USB-Sticks betreiben,<br />
allerdings nicht als Bootmedium.<br />
Tabelle 1 zeigt die Ausstattungen der<br />
beiden erhältlichen Modelle A und B im<br />
Detail.<br />
Der Raspberry Pi bietet eine frei programmierbare<br />
Schnittstelle, bekannt<br />
als General Purpose Input/Output<br />
(GPIO). Sie ermöglicht es Programmierern,<br />
ihrer Fantasie freien Lauf<br />
zu lassen, indem sie Leuchtdioden,<br />
Sensoren, Displays und andere Geräte<br />
darüber ansteuern. Lediglich Apparaturen<br />
mit hohem Schaltstrom sollte man<br />
nicht anschließen, denn diese könnte<br />
die GPIO beschädigen.<br />
Das System-on-a-Chip bietet sechs<br />
GPIOs, aber für Anwender ist vor allem<br />
eine interessant. Der auf der Platine<br />
mit P1 bezeichnete Anschluss lässt<br />
sich über eine Pfostenleiste mit 26 Pins<br />
ansteuern. Einige davon eignen sich<br />
als SPI (Serial Peripheral Interface)<br />
beziehungsweise I2C (Inter-Integrated<br />
Circuit). Diese von Motorola respektive<br />
Philips entwickelten Schnittstellen<br />
kommen in der Messtechnik zum<br />
Einsatz und bieten so vor allem für<br />
Anwendungen in dieser Richtung Potenzial.<br />
Revision 2 des Raspberry hat<br />
eine weitere GPIO-Schnittstelle mit der<br />
Bezeichnung P6 eingeführt. Sie bietet<br />
die Möglichkeit, den Raspberry zurückzusetzen<br />
oder zu starten, nachdem er<br />
heruntergefahren wurde.<br />
Zur Steuerung der GPIOs existieren Bibliotheken<br />
in zahlreichen Programmiersprachen.<br />
Ihre Portierung für FreeBSD<br />
läuft allerdings noch, danach steht<br />
auch dieses Betriebssystem für messtechnische<br />
Projekte bereit.<br />
Um die direkte Anbindung einer Kamera<br />
und eines LC-Displays kümmern<br />
sich ein CSI- (Camera Serial Interface)<br />
und ein DSI-Anschluss (Display Serial<br />
Interface). Für das CSI ist seit Mai<br />
2013 eine Kamera mit einer Auflösung<br />
von fünf Megapixel erhältlich; unter<br />
FreeBSD steuert diese der Treiber<br />
»bktr(4)« an. Ein passendes Display für<br />
den DSI-Anschluss befindet sich zwar<br />
in Entwicklung, allerdings steht der Er-<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
freeX<br />
FreeBSD auf dem Raspberry Pi<br />
107<br />
scheinungstermin noch nicht fest.<br />
Die Raspberry-Betriebssysteme werden<br />
in sogenannte Tiers kategorisiert.<br />
Bei FreeBSD handelt es sich um eine<br />
Tier-2-Plattform. Das bedeutet, dass<br />
sich Tools und Kernel-Quelltexte in<br />
der Entwicklungsphase befinden. Das<br />
Betriebssystem eignet sich durchaus<br />
für Produktiveinsätze, aber Installation<br />
und Upgrade laufen nicht ganz so flüssig<br />
von der Hand.<br />
Karten austeilen<br />
Der FreeBSD-Bootvorgang auf dem<br />
Raspberry Pi setzt eine SD-Karte mit<br />
mindestens 4 GByte Speicherplatz und<br />
zwei passend präparierten Slices voraus.<br />
Slices heißen die BSD-Pendants<br />
zu den unter Windows und Linux als<br />
Partitionen bezeichneten Abschnitten,<br />
während unter BSD die im Slice enthaltenen,<br />
mit Buchstaben gekennzeichneten<br />
Segmente Partitionen heißen.<br />
Das erste Slice besteht aus einem<br />
bootfähigen FAT32- oder FAT16-Dateisystem.<br />
Beim Raspberry enthält nicht<br />
wie bei PCs üblich ein Flash-ROM die<br />
Firmware, sondern sie befindet sich im<br />
ersten Slice auf der SD-Speicherkarte<br />
(siehe Abbildung 2).<br />
Die Firmware eines Raspberry Pi enthält<br />
die folgenden Dateien:<br />
n Der Phase-3-Bootloader »start_<br />
cd.elf« kommt zum Zug, wenn der<br />
für die GPU reservierte Speicher<br />
weniger als 32 MByte Kapazität<br />
aufweist (»gpu_mem=16«). Dabei<br />
handelt es sich um eine abgespeckte<br />
Version der Programmdatei »start.<br />
elf«.<br />
n Die Dateien »fixup.dat« und »fix up_<br />
cd.dat« enthalten den Programmcode,<br />
der den Speicher zwischen<br />
GPU und CPU aufteilt. Sie kommen<br />
in der dritten Phase des Bootvorgangs<br />
zum Einsatz. »fixup_cd.dat«<br />
wird wiederum für GPU-Speichergrößen<br />
von 16 MByte benötigt.<br />
n Bei dem File »boot.scr« handelt es<br />
sich um ein Skript, das aus der Datei<br />
»boot_ubl.txt« ins Binärformat übertragen<br />
wurde und das zu ladende<br />
Betriebssystem definiert. Im Fall<br />
von FreeBSD entspricht es dem an<br />
den Raspberry Pi angepassten Bootloader<br />
»ubldr«. Dieses Tool lädt in<br />
LAN<br />
USB<br />
Audio<br />
Kamera<br />
CSI<br />
LAN-Chip<br />
der Folge den Betriebssystemkern<br />
von FreeBSD.<br />
n Die Datei »devtree.dat« enthält alle<br />
verwendeten Gerätetreiber.<br />
Das zweite Slice enthält schließlich das<br />
gewünschte Betriebssystem selbst,<br />
also FreeBSD. Um zu verstehen, wie<br />
man FreeBSD bootfähig auf der Speicherkarte<br />
installiert, folgt zunächst<br />
eine genauere Betrachtung des Bootvorgangs.<br />
Mit der Kirche ums Kreuz<br />
Der erste außergewöhnliche Schritt<br />
beim Booten des Raspberry Pi besteht<br />
darin, dass der Grafikprozessor (GPU)<br />
vor dem Mikroprozessor startet. Sobald<br />
der kleine Rechner mit Strom versorgt<br />
wird, startet ein Miniprogramm, das<br />
bei der Herstellung des Chips ins ROM<br />
gebrannt wurde. Es aktiviert zunächst<br />
das Boot-Slice der SD-Karte. Diesen Abschnitt<br />
des Bootprozesses nennt man<br />
First Stage und das Programm im ROM<br />
entsprechend Phase-1-Bootloader oder<br />
First Stage Bootloader. Darüber erhält<br />
das System Zugriff auf den Phase-2-<br />
Bootloader oder Second Stage Bootloader,<br />
zu dessen Programmcode die<br />
Datei »bootcode.bin« gehört.<br />
Weil Mikroprozessor und Arbeitsspeicher<br />
an dieser Stelle immer noch nicht<br />
aktiviert sind, übernimmt die GPU<br />
den weiteren Bootvorgang. Dazu lädt<br />
HDMI<br />
GPU, CPU,<br />
RAM<br />
Video<br />
(FBAS)<br />
Reset<br />
Abbildung 1: Die Bausteine und Anschlüsse eines Raspberry Pi, Modell B.<br />
GPIO<br />
das System den Programmcode aus<br />
»bootcode.bin« in den Cache der GPU<br />
und führt ihn aus. Erst jetzt wird der<br />
Arbeitsspeicher aktiviert und die GPU<br />
liest die Datei »start.elf« von der Speicherkarte.<br />
Sie steht für den Third Stage<br />
Bootloader oder Phase-3-Bootloader.<br />
Es handelt sich dabei um die Firmware<br />
des Grafikprozessors.<br />
Der jetzt folgende dritte Schritt ist der<br />
wichtigste während der gesamten<br />
Initialisierungsphase. Der Third Stage<br />
Bootloader enthält Programmcode,<br />
der die Aufteilung des Arbeitsspeichers<br />
zwischen GPU und CPU vornimmt und<br />
anschließend die Konfigurationsdatei<br />
»config.txt« verarbeitet.<br />
Im letzten Schritt wird die CPU initialisiert.<br />
Dazu lädt die GPU das Betriebssystem<br />
für den Mikroprozessor gemäß<br />
des Parameters »kernel=« in der Datei<br />
»config.txt« und aktiviert die CPU.<br />
Bei FreeBSD lädt der Phase-3-Bootloader<br />
die Datei »uboot.img«. Dabei<br />
handelt es sich um ein Betriebssystem<br />
für die CPU; es fährt in diesem Fall also<br />
das FreeBSD-System hoch. Abbildung 4<br />
illustriert den Bootvorgang.<br />
Die Kompilierung von FreeBSD für den<br />
Raspberry Pi geschieht unter einem<br />
existierenden FreeBSD-Host-System.<br />
Dabei spielt es keine Rolle, ob dieses<br />
nativ oder in einer virtuellen Umgebung<br />
installiert ist. Mit der stabilen Ver-<br />
Betriebsspannung<br />
Display<br />
DSI<br />
SD-Card<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
108<br />
freeX<br />
FreeBSD auf dem Raspberry Pi<br />
sion 10 ist man auf der sicheren Seite,<br />
nur etwas abenteuerlustigere Raspberry-Besitzer<br />
weichen auf die momentan<br />
unter »CURRENT« firmierende Version<br />
11 aus.<br />
Für die Installation legt man auf dem<br />
Host-System als Root ein separates<br />
Verzeichnis an. Das verhindert, dass<br />
sich Dateien des Hosts mit den für den<br />
Raspberry kompilierten vermischen;<br />
andernfalls käme es spätestens bei der<br />
Aktualisierung des Host-Systems zum<br />
Chaos.<br />
$ su root<br />
# mkdir /home/raspberry<br />
# cd /home/raspberry<br />
Damit FreeBSD auf dem Raspberry<br />
bootet, benötigt man außerdem den<br />
Bootloader:<br />
# fetch http://www.dankoweit.de/U<br />
Downloads/Raspberry/U<br />
freebsd‐uboot‐20140101.tar.gz<br />
Seit FreeBSD 9.2 kommt für die Verwaltung<br />
des Betriebssystem-Sourcecodes<br />
Subversion statt Csup zum Einsatz. Die<br />
Installation erfolgt – falls nicht ohnehin<br />
bereits geschehen – über die Paketverwaltung:<br />
# pkg_add ‐r subversion<br />
Alternativ holt man Subversion vom<br />
Portstree:<br />
# make ‐C /usr/ports/devel/subversion U<br />
install clean<br />
Der letzte Schritt in der Vorbereitungsphase<br />
betrifft das Anlegen eines Disk-<br />
Image für die SD-Karte. Es sollte mindestens<br />
512 MByte bemessen; besser<br />
sind 1024 MByte, damit Platz für den<br />
Portstree bleibt. Zunächst legt man<br />
mit »dd« eine leere Datei an, die das<br />
Kommando »mdconfig« dann in eine<br />
Memory Disk mit dem Treiber »md0«<br />
umwandelt:<br />
# dd if=/dev/zero of=./rpi.img bs=1m U<br />
count=1024<br />
# mdconfig ‐a ‐t vnode ‐f ./rpi.img U<br />
md0<br />
Da sich die Datei »./rpi.img« wie eine<br />
Festplatte verhält, lassen sich im folgenden<br />
Schritt die einzelnen Slices<br />
anlegen. Als Partitionierungsschema<br />
ist die Auswahl von MBR (Master Boot<br />
Record) zwingend notwendig, weil die<br />
Firmware des Raspberry nur damit zurecht<br />
kommt.<br />
Zuerst erstellt und formatiert man das<br />
Boot-Slice, auf das die Raspberry-Firmware<br />
kommt. Bei dessen Größe reichen<br />
32 MByte aus:<br />
# gpart create ‐s MBR md0<br />
# gpart add ‐s 32m ‐t '!12' md0<br />
# gpart set ‐a active ‐i 1 md0<br />
# newfs_msdos ‐L boot ‐F 16 /dev/md0s1<br />
Danach legt man das FreeBSD-Slice an<br />
und formatiert es ebenfalls. Es nimmt<br />
den gesamten restlichen Speicherplatz<br />
ein:<br />
# gpart add ‐t freebsd md0<br />
# gpart create ‐s BSD md0s2<br />
# gpart add ‐t freebsd‐ufs md0s2<br />
# newfs ‐U ‐j /dev/md0s2a<br />
Es folgt der Download der Quelltexte<br />
der gewünschten FreeBSD-Version. Der<br />
folgende Aufruf holt FreeBSD 10 aus<br />
dem Subversion-Repository:<br />
# svn co svn://svn.freebsd.org/base/U<br />
stable/10./fbsd<br />
Diese Eingabe holt alternativ FreeBSD<br />
»CURRENT«, also derzeit Version 11:<br />
# svn co svn://svn.freebsd.org/base/ U<br />
head ./fbsd<br />
In beiden Fällen landet der Quellcode<br />
im Unterverzeichnis »fbsd«, der Aufruf<br />
sollte deshalb aus dem anfangs eigens<br />
für diesen Zweck erstellten Verzeichnis<br />
»/home/raspberry« erfolgen.<br />
n Tabelle 1: Die Modellvarianten des Raspberry Pi<br />
Modell A<br />
Modell B<br />
Preis 25 bis 30 Euro 40 bis 45 Euro<br />
Größe<br />
85,60mm x 53,98mm x 17mm (Kreditkartengröße)<br />
System-on-Chip (SoC):<br />
Broadcom BCM2835<br />
Prozessor<br />
ARM1176JZF-S (700 MHz)<br />
Grafik<br />
Broadcom VideoCore IV<br />
Arbeitsspeicher (SDRAM) 256 MByte 512 MByte (ab November 2012)<br />
USB-2.0-Anschlüsse 1 2 (über integrierten Hub)<br />
Video<br />
FBAS (Cinch), HDMI<br />
Ton<br />
3,5-mm-Klinkenstecker (analog) oder HDMI (digital)<br />
Nicht flüchtiger Speicher<br />
Kartenleser für SD (SDHC und SDXC)/MMC/SDIO<br />
Netzwerk – 10/100-MBit-Ethernet-Controller<br />
(LAN9512 von SMSC)<br />
Schnittstellen<br />
Bis 17 GPIO-Pins, SPI, I2C, UART, EGL<br />
Echtzeituhr –<br />
Leistungsaufnahme 5 V, 500 mA (2,5 Watt) 5 V, 700 mA (3,5 Watt)<br />
Stromversorgung<br />
5-V-Micro-USB-Anschluss (Micro-B)<br />
Betriebssysteme GNU/Linux, BSD, RISC OS, Plan 9<br />
Speicherteilung<br />
Als nächstes steht die Zuweisung von<br />
Arbeitsspeicher an. GPU und CPU<br />
teilen sich das RAM, man berechnet<br />
also deren jeweiligen Anteil. Wie viel<br />
Speicher die GPU benötigt, hängt vom<br />
angedachten Anwendungsfall ab: Bei<br />
grafik intensiven Applikationen sollte<br />
man ihr 64 oder 128 MByte reservieren,<br />
bei textlastigem Betrieb genügen 16<br />
oder 32 MByte. Die Differenz vom insgesamt<br />
verfügbaren Speicher, also je<br />
nach Modell 256 oder 512 MByte, ergibt<br />
das für die CPU verbleibende RAM. Der<br />
folgende Shell-Aufruf berechnet sie und<br />
gibt direkt den anschließend benötigten<br />
Hexadezimalwert aus. RPI und GPU<br />
stehen für die Gesamtgröße des Arbeitsspeichers<br />
und den für die GPU zu<br />
reservierenden Anteil, beide Angaben<br />
jeweils in MByte:<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
freeX<br />
FreeBSD auf dem Raspberry Pi<br />
109<br />
# printf "%X\n" $(((RPI‐U<br />
GPU)*1024*1024))<br />
Den so ermittelten Wert, trägt man in<br />
die Konfigurationsdatei »rpi.dts« im<br />
Verzeichnis »sys/boot/fdt/dts« ein. Darin<br />
sucht man diese Zeilen:<br />
memory {<br />
device_type = "memory";<br />
reg = ; /* 128 MByte */<br />
};<br />
Den vorgegebenen Wert »08000000«<br />
(128 MByte) ersetzt man durch den<br />
oben berechneten Hexadezimalwert.<br />
Um den Kernel des Betriebssystems anzupassen,<br />
findet man in »sys/arm/conf/<br />
RPI‐B« die passende Konfigurationsdatei.<br />
Unter [2] stellt der Autor ein funktionierendes<br />
Beispiel zur Verfügung.<br />
Grundsätzlich gilt aufgrund des im<br />
Vergleich zu modernen PCs sehr eingeschränkten<br />
Arbeitsspeichers, dass man<br />
nur wirklich notwendige Funktionen<br />
aktivieren sollte. Die Monitorausgabe<br />
über den HDMI-Anschluss aktiveren<br />
beispielsweise die folgenden Zeilen:<br />
device sc<br />
options SC_DFLT_FONT<br />
makeoptions SC_DFLT_FONT=cp850<br />
Außerdem kommentiert man diese<br />
Zeile aus:<br />
device vt<br />
Wer eine Maus an den Raspberry anschließen<br />
möchte, aktiviert den Treiber<br />
für USB-Mäuse:<br />
device ums<br />
Crosscompiling<br />
Nach der Konfiguration des gewünschten<br />
Kernels geht es nun zum Kompilieren.<br />
Da die Zielplattform eine andere<br />
als die des kompilierenden Systems ist,<br />
kommt Crosscompiling zum Einsatz.<br />
In diesem Beispiel läuft FreeBSD auf<br />
einem 32- oder 64-Bit-System von Intel<br />
oder AMD, während der Zielplattform<br />
Raspberry eine ARM-CPU zugrunde<br />
liegt. Deshalb setzt man zunächst die<br />
folgende Umgebungsvariable:<br />
SD-Card<br />
Boot-Block:<br />
512 Byte<br />
# export TARGET_ARCH=armv6<br />
Der nächste Befehl generiert die fürs<br />
Crosscompiling nötigen Tools wie Compiler<br />
und Linker:<br />
# make kernel‐toolchain<br />
Boot-Slice:<br />
512 Byte FAT16- oder FAT32-Slice:<br />
32MiB<br />
Nun erfolgt die Übersetzung des Kernels.<br />
Die Option »WITH_FDT=yes«<br />
ist hierbei nötig; sie aktiviert den<br />
Flatten ed Device Tree, über den der<br />
FreeBSD-Kernel den einzelnen Geräten<br />
Treiber zuweist.<br />
# make KERNCONF=RPI‐B WITH_FDT=yes U<br />
buildkernel<br />
Dieser Schritt dauert je nach Hardware<br />
etwa eine halbe Stunde. Es folgt der<br />
gleiche Prozess fürs Userland, der noch<br />
etwa viermal soviel Zeit in Anspruch<br />
nimmt:<br />
# make MALLOC_PRODUCTION=yes buildworld<br />
Ist die Kompilierung fehlerfrei durchgelaufen,<br />
ermittelt der folgende Befehl<br />
die restlichen Umgebungsvariablen für<br />
die spätere Installation:<br />
# buildenv=`make buildenvvars | U<br />
sed 's/MACHINE_ARCH=armv6/MACHINE_U<br />
ARCH=arm/'`<br />
Nun geht es weiter mit dem Raspberryspezifischen<br />
Bootloader:<br />
# cd sys/boot<br />
# eval $buildenv make MK_NAND=no U<br />
BOOTCODE.BIN, START.ELF,<br />
CONFIG.TXT, UBOOT.IMG,<br />
BOOT.SCR, DEVTREE.DAT<br />
FreeBSD-Slice:<br />
bootloader<br />
boot/kernel/kernel<br />
sbin/init, /etc/rc.conf<br />
restliches Betriebssystem<br />
UFS2-Slice:<br />
mind. 512 MiB<br />
Abbildung 2: Einteilung einer SD-Karte für den Einsatz von FreeBSD auf dem Raspberry Pi.<br />
UBLDR_LOADADDR=0x2000000 clean obj all<br />
# cd /home/raspberry/fbsd<br />
Installation<br />
Damit ist der langwierigste Teil der<br />
Arbeit abgeschlossen. Der folgende Installationsvorgang<br />
verlangt dennoch<br />
die gleiche Sorgfalt wie die zurückliegenden<br />
Schritte. Man hängt als erstes<br />
das Firmware-Slice ein und kopiert den<br />
Bootloader und die Device-Datenbank<br />
darauf:<br />
# mount ‐t msdosfs /dev/md0s1 /mnt<br />
# tar ‐C /mnt ‐xvzf /home/raspberry/U<br />
freebsd‐uboot‐20140101.tar.gz<br />
# cp ‐iv /usr/obj/arm.armv6/home/U<br />
raspberry/ fbsd/sys/boot/arm/uboot/U<br />
ubldr /mnt/<br />
# cp ‐iv /usr/obj/arm.armv6/home/U<br />
raspberry/ fbsd/sys/RPI‐B/rpi.dtb U<br />
/mnt/devtree.dat<br />
Weiterhin editiert man die Konfiguration,<br />
damit sowohl CPU als auch GPU<br />
die Geräte korrekt ansprechen:<br />
device_tree=devtree.dat<br />
device_tree_address=0x100<br />
disable_commandline_tags=1<br />
gpu_mem_512=GPUMEM<br />
gpu_mem_256=GPUMEM<br />
Der Platzhalter GPUMEM definiert die<br />
zuvor ermittelte Speichergröße für die<br />
GPU. Die Parameter »gpu_mem_512«<br />
und »gpu_mem_256« repräsentieren<br />
einen Raspberry Pi mit 512 MByte beziehungsweise<br />
256 MByte physischen<br />
Arbeitsspeicher.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
110<br />
freeX<br />
FreeBSD auf dem Raspberry Pi<br />
Abbildung 3: Eine Remote-Sitzung per SSH an einem Raspberry Pi mit<br />
FreeBSD »CURRENT«.<br />
An dieser Stelle weicht die offizielle<br />
Dokumentation ab, sie legt zu diesem<br />
Zweck den Parameter »gpu_mem«<br />
nahe. Das <strong>ADMIN</strong>-<strong>Magazin</strong> hat im Test<br />
jedoch herausgefunden, dass in der<br />
Realität nur die Angabe »gpu_mem_<br />
(512|256)« die RAM-Größe korrekt<br />
einstellt.<br />
Das Boot-Slice hängt man anschließend<br />
aus und mountet das zweite Slice.<br />
Dort installiert man das Betriebssystem<br />
nebst Kernel:<br />
# umount /mnt<br />
# mount /dev/md0s2a /mnt<br />
# make KERNCONF=RPI‐B DESTDIR=/mnt U<br />
installkernel<br />
# make DESTDIR=/mnt DB_FROM_SRC=1 U<br />
installworld distribution<br />
Damit sind die Installationsarbeiten<br />
abgeschlossen, es fehlen nur noch<br />
einige Einstellungsoptionen. Zunächst<br />
ergänzt man die Konfiguration des<br />
Kernel-Bootloaders in »/mnt/boot/loader.rc«.<br />
Damit der Kernel den Flattened<br />
Device Tree findet, teilt man ihm die<br />
Einsprungadresse mit:<br />
fdt addr 0x100<br />
Des Weiteren muss der Kernel wissen,<br />
von welchem Device er booten soll.<br />
Dafür ist die Filesystem-Tabelle in<br />
»/mnt/etc/fstab« zuständig. Da außerdem<br />
meistens das »proc«-Filesystem<br />
benötigt wird, trägt man dieses gleich<br />
mit ein:<br />
/dev/mmcsd0s2a / ufs U<br />
rw,noatime 1 1<br />
procfs /proc procfs rwU<br />
0 0<br />
Der Treiber »/dev/<br />
mmcsd0« spricht die<br />
Speicherkarte an.<br />
Das Suffix »s2a« bedeutet,<br />
dass es sich<br />
um das zweite Slice<br />
und die Partition »a«<br />
handelt. Das mit UFS<br />
formatierte Medium<br />
wird zum Schreiben<br />
und Lesen (»rw«) ins<br />
Root-Directory »/«<br />
gemountet. Um die<br />
Schreibgeschwindigkeit nicht auszubremsen,<br />
wird der Zeitstempel des<br />
Zugriffs (Access Time) an dieser Stelle<br />
nicht protokolliert (»noatime«).<br />
Nun überarbeitet man die zentrale<br />
FreeBSD-Konfiguration in »/mnt/etc/<br />
rc.conf«. Die Netzwerkkonfiguration per<br />
DHCP gestaltet sich einfach:<br />
hostname="raspberry.your.domain"<br />
ifconfig_ue0="DHCP"<br />
Ohne DHCP-Server setzt man die Standardroute<br />
manuell; ansonsten bliebe<br />
der Raspberry im Netz unerreichbar:<br />
ifconfig_ue0="IP‐Adr netmask Netzmaske"<br />
defaultrouter="DefRouter"<br />
Die Platzhalter IP‐Adr und Netzmaske<br />
stehen für die IPv4-Adresse und Netzmaske<br />
des Subnetzes. Mit DefRouter<br />
gibt man die Adresse des Default-<br />
Routers an, über den sämtliche Datenpakete<br />
laufen. Zusätzlich konfiguriert<br />
man die Namensauflösung in »/mnt/<br />
etc/resolv.conf«:<br />
nameserver DNS‐Adr<br />
In »/mnt/etc/hosts« muss zudem diese<br />
Zeile stehen:<br />
RPI‐Adr raspberry.heim.netz raspberry<br />
Schließlich aktiviert man noch zwei<br />
essenzielle Tools: Den Secure-Shell-<br />
Daemon »sshd« und den NTP-Client.<br />
Letzterer ist wichtig, da der Raspberry<br />
keine batteriegestützte Echtzeituhr besitzt,<br />
er benötigt deshalb nach jedem<br />
Neustart wieder die korrekte Uhrzeit.<br />
Diese Information holt er vom Zeitserver<br />
mit der IP-Adresse NTP‐Adr:<br />
sshd_enable="YES"<br />
ntpdate_enable="YES"<br />
ntpdate_hosts="NTP‐Adr"<br />
Abschließend schaltet man das Speichern<br />
von Dump-Files ab:<br />
dumpdev="NO"<br />
Damit man nach dem ersten Start die<br />
Möglichkeit hat, sich am System als<br />
Root-User zu authentifizieren, fügt man<br />
in der Konfiguration des SSH-Daemons<br />
»/mnt/etc/ssh/sshd_config« diese Zeile<br />
hinzu:<br />
PermitRootLogin yes<br />
Man deaktiviert weiterhin den Authentifizierungsprozess<br />
in »/mnt/etc/pam.d/<br />
sshd«, indem man die folgende Zeile<br />
auskommentiert.<br />
auth required pam_unix.so no_warn U<br />
try_first_pass<br />
Stattdessen kommt die folgende Zeile<br />
hinzu:<br />
auth required pam_permit.so<br />
Abschließend setzt man die korrekte<br />
Zeitzone. Für Mitteleuropa erledigt das<br />
diese einfache Kopieraktion:<br />
# cp ‐iv /mnt/usr/share/zoneinfo/ U<br />
Europe/Berlin /mnt/etc/localtime<br />
Die anderen Zeitzonendefinitionen<br />
liegen auch im Verzeichnis »/mnt/usr/<br />
share/zoneinfo/« und kommen bei Bedarf<br />
auf die gleiche Weise zum Einsatz.<br />
Auf die Karte!<br />
Abschließend kopiert man jetzt das<br />
fertige Image auf die Speicherkarte. In<br />
der hier vorgestellten Installation und<br />
dem zugrunde liegenden System repräsentiert<br />
»/dev/da0« die Speicherkarte;<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
freeX<br />
FreeBSD auf dem Raspberry Pi<br />
111<br />
das Device kann bei anderen Systemen<br />
abweichen:<br />
# umount /mnt<br />
# mdconfig ‐d ‐u md0<br />
# dd if=/root/rpi.img of=/dev/da0 bs=1m<br />
Stapellauf<br />
Nachdem man die Speicherkarte in den<br />
Slot gesteckt und die Stromversorgung<br />
an den Raspberry Pi angeschlossen<br />
hat, startet der Bootvorgang. Man<br />
sieht auf dem Monitor die von FreeBSD<br />
bekannten Boot meldungen. Die grüne<br />
Leuchtdiode bleibt dunkel, da der<br />
FreeBSD-Kernel sie ignoriert.<br />
Gelegentlich stoppt ein Bootvorgang<br />
mit einer Fehlermeldung, derzufolge<br />
das Boot-Slice fehlt. Das liegt in der<br />
Regel daran, dass manche SD-Karten<br />
nicht fehlerfrei mit dem Controller des<br />
Raspberry harmonieren. Meist klappt<br />
es beim zweiten Bootversuch.<br />
Nach dem ersten Login per SSH reaktiviert<br />
man als erstes die bei der Grundkonfiguration<br />
ausgeschalteten Sicherheitsvorkehrungen.<br />
Root sollte sich<br />
dann nicht mehr per SSH anmelden<br />
dürfen, stattdessen legt man für diesen<br />
Zweck einen gewöhnlichen Benutzer<br />
an, beispielsweise »pi« (Abbildung 3):<br />
# mkdir ‐p /home/pi<br />
# pw group add users ‐g 1001<br />
# pw user add pi ‐s/bin/tcsh ‐d /home/U<br />
pi ‐g users ‐G wheel<br />
# passwd ‐l pi<br />
Nun empfiehlt es sich, den Speicherplatz<br />
auf dem Betriebssystem-Slice zu<br />
vergrößern, damit auch zusätzliche<br />
Tools darauf Platz finden. »gpart« zeigt<br />
die aktuelle Partitionierung an; in den<br />
ersten beiden Spalten finden sich die<br />
Größenangaben:<br />
# gpart show mmcsd0<br />
=> 1 15564799 mmcsd0 MBR (7.4G)<br />
1 8 ‐ free ‐ (4.0K)<br />
9 65529 1 !12 [active] (32M)<br />
65538 983034 2 freebsd (480M)<br />
1048572 14516228 ‐ free ‐ (6.9G)<br />
Das Slice mit Nummer 2 vom Typ<br />
»freebsd« enthält das Betriebssystem<br />
und wird wie folgt bearbeitet:<br />
# gpart resize ‐i 2 mmcsd0<br />
mmcsd0 resized<br />
# gpart show mmcsd0<br />
=> 1 15564799 mmcsd0 MBR (7.4G)<br />
1 8 ‐ free ‐ (4.0K)<br />
9 65529 1 !12 [active] (32M)<br />
65538 15499260 2 freebsd (7.4G)<br />
15564798 2 ‐ free ‐ (1.0K)<br />
Nach dieser Aktion startet man das<br />
System neu und lässt sich danach die<br />
aktuelle Slice-Tabelle anzeigen:<br />
# gpart show<br />
=> 1 15564799 mmcsd0 MBR (7.4G)<br />
1 8 ‐ free ‐ (4.0K)<br />
9 65529 1 !12 [active] (32M)<br />
65538 15499260 2 freebsd (7.4G)<br />
15564798 2 ‐ free ‐ (1.0K)<br />
=> 0 15499260 mmcsd0s2 BSD (7.4G)<br />
0 983034 1 freebsd‐ufs (480M)<br />
983034 14516226 ‐ free ‐ (6.9G)<br />
Wichtig ist hierbei das Slice mit dem<br />
Namen »mmcsd0s2«, das an die neue<br />
Verteilung angepasst werden muss:<br />
# gpart resize ‐i 1 mmcsd0s2<br />
mmcsd0s2a resized<br />
Zur Kontrolle hilft ein Blick auf die Ausgabe<br />
des folgenden Kommandos:<br />
# gpart show mmcsd0s2<br />
=> 0 15499260 mmcsd0s2 BSD (7.4G)<br />
0 15556606 1 freebsd‐ufs (7.4G)<br />
15556606 8182 ‐ free ‐ (4M)<br />
Zum Schluss werden die neu hinzugekommenen<br />
Blöcke formatiert:<br />
# growfs /<br />
[...]<br />
OK to grow filesystem on /dev/mmcsd0s2a,<br />
mounted on /, from 480MB to 7.4GB?<br />
[Yes/No] Yes<br />
super‐block backups (for fsck ‐b #) at:<br />
983232, [...], 15483072<br />
Nach Abschluss dieser Tätigkeiten startet<br />
man zur Sicherheit den Raspberry<br />
neu und beobachtet die Ausgabe auf<br />
dem Monitor. Wie bei anderen Systemen<br />
gilt hier, dass ein geordneter<br />
Shutdown vor dem Kappen der Stromversorgung<br />
für die Konsistenz des<br />
Datei systems notwendig ist:<br />
# shutdown ‐h now<br />
Über ein Powermanagement-System<br />
wie APM oder ACPI verfügt der Raspberry<br />
Pi übrigens nicht, deshalb kann<br />
er sich nach dem System-Shutdown<br />
nicht per Software ausschalten. Ohne<br />
angeschlossenen Bildschirm bleiben<br />
nur zwei Möglichkeiten: Entweder man<br />
wartet nach dem Befehl zum Herunterfahren<br />
etwa zehn Minuten, bevor man<br />
das Gerät ausschaltet, oder man hängt<br />
das Dateisystem als nur lesbar (Read<br />
Only) ein. Dazu ändert man den Eintrag<br />
in »/etc/fstab« von<br />
/dev/mmcsd0s2a / ufs rw,noatime 1 1<br />
zu<br />
/dev/mmcsd0s2a / ufs ro,noatime 1 1<br />
Bei dieser Konfiguration kann das System<br />
allerdings keine Protokolle mehr<br />
ins Verzeichnis »/var/log/« schreiben.<br />
Abhilfe schafft die Möglichkeit, die Systemprotokolle<br />
stattdessen übers Netz<br />
auszuliefern. In der Datei »/etc/rc.conf«<br />
fügt man zu diesem Zweck die folgende<br />
Zeile ein:<br />
SD-Card<br />
Bootsektor<br />
Boot-Slice<br />
BOOTCODE.BIN<br />
START.ELF<br />
CONFIG.TXT<br />
UBOOT.IMG<br />
FreeBSD-Slice<br />
FreeBSD-Kernel<br />
Raspberry Pi<br />
SoC<br />
GPU<br />
CPU<br />
Abbildung 4: Schematische Darstellung des Bootvorgangs<br />
eines Raspberry Pi.<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
112<br />
freeX<br />
FreeBSD auf dem Raspberry Pi<br />
syslogd_enable="YES"<br />
Nun trägt man das Zielsystem in der<br />
Syslogd-Konfiguration ein und kommentiert<br />
alle anderen darin enthaltenen<br />
Zeilen aus:<br />
*.* @Zielsystem<br />
Der Syslog-Daemon des Zielsystems<br />
muss die vom Raspberry eingehenden<br />
Protokolle allerdings explizit akzeptieren.<br />
Handelt es sich dabei ebenfalls um<br />
ein FreeBSD-System, sorgt dafür dieser<br />
Eintrag in »/etc/rc.conf«. Bei Linux-Systemen<br />
erfolgt die Konfiguration etwa in<br />
»/etc/rsyslog.conf« oder dem Verzeichnis<br />
»/etc/rsyslog.d/«:<br />
syslogd_enable="YES"<br />
syslogd_flags="‐a $netzwerk/$maske ‐4 \<br />
‐b ${adr_syslog}"<br />
Administrative Aufgaben<br />
Nach der nun abgeschlossenen Installation<br />
und Grundkonfiguration von<br />
FreeBSD bietet der Raspberry Pi eine<br />
gute Ausgangsbasis für weitere Projekte<br />
mit diesem Rechnersystem. Die<br />
Vielzahl portierter Anwendungen legt<br />
das Fundament für vielfältige Einsatzmöglichkeiten.<br />
Wie immer unter FreeBSD stehen auch<br />
auf dem Raspberry-System Softwarepakete<br />
zum Selbstkompilieren oder<br />
bereits übersetzte zur Wahl. <strong>Erste</strong>res<br />
erleichtert der Portstree, indem er die<br />
Abhängigkeiten automatisch auflöst.<br />
Bei der für die Raspberry-Plattform ohnehin<br />
überschaubaren Auswahl fertiger<br />
Softwarepakete empfiehlt sich deshalb<br />
diese Methode.<br />
Für die Portstree-Installation meldet<br />
man sich zunächst wieder am Raspberry<br />
an und wechselt zum Root-User.<br />
Danach holt man im Verzeichnis »/<br />
usr/« per FTP das Tar-File mit der Ports-<br />
Struktur:<br />
# su root<br />
# cd /usr<br />
# fetch ftp://ftp.freebsd.org/pub/U<br />
FreeBSD/ports/ports/ports.tar.gz<br />
# tar ‐xzvf ports.tar.gz<br />
Portstree inklusive<br />
Alternativ bietet es sich an, den Portstree<br />
bereits während der Image-Konfiguration<br />
auf die SD-Karte zu laden und<br />
zu entpacken. Das erfolgt in ähnlicher<br />
Weise wie zuvor, aber erst nachdem<br />
das Betriebssystem im Raspberry-<br />
Image gespeichert ist:<br />
# cd /mnt/usr<br />
# fetch ftp://ftp.freebsd.org/pub/U<br />
FreeBSD/ports/ports/ports.tar.gz<br />
# tar ‐xzvf ports.tar.gz<br />
Der große Vorteil dieser Methode liegt<br />
darin, dass sie eine Menge Zeit spart,<br />
weil die Host-Maschine üblicherweise<br />
mehr Rechenleistung bietet als der rechenschwache<br />
Raspberry Pi. Allerdings<br />
fällt dafür das Image größer aus, man<br />
sollte mindestens 200 MByte einplanen.<br />
Fensterln mit FreeBSD<br />
Die Hardware des Raspberry Pi stellt<br />
einen leistungsfähigen Grafikprozessor<br />
und einen HDMI-Port zum Anschluss<br />
eines Monitors oder anderer Videokomponenten<br />
zur Verfügung. Um diese zu<br />
nutzen, liegt es nahe, Xorg zu installieren.<br />
Desktop-Umgebungen wie Gnome<br />
oder KDE fallen aufgrund der begrenzten<br />
Speicherkapazität jedoch aus. Der<br />
Window-Manager TWM bietet eine angemessenere<br />
grafische Umgebung.<br />
Die Installation von Xorg verläuft auf<br />
dem Raspberry etwas anders als auf<br />
einem klassischen Desktop-System.<br />
Derzeit passen die Entwickler den gesamten<br />
Portstree auf das Zielsystem<br />
FreeBSD-ARM an; noch kommt es aber<br />
vereinzelt zu Fehlern beim Kompilie-<br />
n Listing 1: »xorg.conf« für den Raspberry Pi<br />
01 Section "Files"<br />
02 EndSection<br />
03 <br />
04 Section "Module"<br />
05 Load "dbe"<br />
06 Disable "dri"<br />
07 Disable "dri2"<br />
08 Disable "glx"<br />
09 SubSection "extmod"<br />
10 Option "omit xfree86‐dga"<br />
11 EndSubSection<br />
12 EndSection<br />
13 <br />
14 Section "ServerFlags"<br />
15 Option "AIGLX" "false"<br />
16 Option "NoAccel" "True"<br />
17 Option "NoDRI" "True"<br />
18 Option "DRI" "False"<br />
19 Option "DRI2" "False"<br />
20 EndSection<br />
21 <br />
22 Section "InputDevice"<br />
23 Identifier "Keyboard1"<br />
24 Driver "kbd"<br />
25 EndSection<br />
26 <br />
27 Section "InputDevice"<br />
28 Identifier "Mouse1"<br />
29 Driver "mouse"<br />
30 Option "Protocol" "auto"<br />
31 Option "Device" "/dev/sysmouse"<br />
32 EndSection<br />
33 <br />
34 Section "Monitor"<br />
35 Identifier "Monitor"<br />
36 Mode "1024x600"<br />
37 DotClock 25.175<br />
38 HTimings 1024 1048 1148 1200<br />
39 VTimings 600 610 620 700<br />
40 EndMode<br />
41 EndSection<br />
42 <br />
43 Section "Device"<br />
44 Identifier "Generic FB"<br />
45 Driver "scfb"<br />
46 Option "NoAccel" "True"<br />
47 EndSection<br />
48 <br />
49 Section "Screen"<br />
50 Identifier "Screen"<br />
51 Device "Generic FB"<br />
52 Monitor "Monitor"<br />
53 DefaultDepth 16<br />
54 SubSection "Display"<br />
55 Depth 16<br />
56 Modes "1024x600"<br />
57 EndSubsection<br />
58 EndSection<br />
59 <br />
60 Section "ServerLayout"<br />
61 Identifier "layout"<br />
62 Screen 0 "Screen" 0 0<br />
63 InputDevice "Mouse1" "CorePointer"<br />
64 InputDevice "Keyboard1" "CoreKeyboard"<br />
65 EndSection<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
freeX<br />
FreeBSD auf dem Raspberry Pi<br />
113<br />
ren – Bug-Reports helfen den Programmierern,<br />
Fehler schneller zu finden und<br />
auszuräumen.<br />
Um Xorg unfallfrei auf einem Raspberry<br />
zu installieren, steht an erster Stelle<br />
unbedingt die Aktualisierung des Portstrees,<br />
um alle notwendigen Patches zu<br />
erhalten. Zudem sollte man den direkten<br />
Zugriff auf die Grafikhardware per<br />
DRI (Direct Rendering Infrastructure)<br />
ausschalten. Das erledigt diese Zeile in<br />
der Datei »/etc/make.conf«:<br />
WITHOUT_DRI=yes<br />
Das anschließende Kompilieren nimmt<br />
wieder viel Zeit in Anspruch. Anschließend<br />
erfolgt die manuelle Xorg-Konfiguration.<br />
Listing 1 zeigt eine funktionierende<br />
Version von »/etc/X11/xorg.<br />
conf«. Von besonderem Interesse sind<br />
die Abschnitte »ServerFlags« und »Module«.<br />
Auch hier ist die Deaktivierung<br />
der DRI-Unterstützung nötig, damit<br />
Xorg startet. Außerdem aktiviert man<br />
den Grafiktreiber im Abschnitt »Device«<br />
mit diesen Einträgen:<br />
Driver "scfb"<br />
Option "NoAccel" "True"<br />
Entfernter Bildschirm<br />
Wem es zu lange dauert, bis Xorg<br />
kompiliert ist, dem bietet Remote-X<br />
eine Alternative. Dabei erfolgt die<br />
Bildschirm ausgabe statt auf dem<br />
Raspberry-Monitor übers Netzwerk.<br />
Möchte man beispielsweise Xclock auf<br />
dem Raspberry starten und auf einem<br />
anderen Rechner anzeigen – andere<br />
grafische Programme funktionieren auf<br />
die gleiche Weise –, installiert man zunächst<br />
das Programm selbst aus dem<br />
entsprechenden Portstree-Verzeichnis:<br />
# cd /usr/ports/x11‐clocks/xclock<br />
# make install clean<br />
Die Authentifizierung setzt außerdem<br />
die Installation von Xauth für die<br />
Authentifizierung des verwendeten X-<br />
Clients voraus:<br />
# cd /usr/ports/x11/xauth<br />
# make install clean<br />
Abbildung 5: Das Xclock-Fenster rechts stammt vom Raspberry, gestartet via SSH (links).<br />
Die folgende Zeile in der Konfiguration<br />
des SSH-Servers auf dem Raspberry,<br />
»/etc/ssh/sshd_config«, aktiviert das X-<br />
Forwarding. Damit landen alle X11-Protokoll-Tokens<br />
durch einen verschlüsselten<br />
Tunnel automatisch auf dem SSH-<br />
Client-System. Damit das klappt, muss<br />
übrigens auch die Namensauflösung<br />
funktionieren.<br />
X11Forwarding yes<br />
Die Client-Seite benötigt die Tools<br />
Xauth und Xhost sowie einen Display-<br />
Manager (XDM, GDM oder KDM). Des<br />
Weiteren ergänzt man die Konfiguration<br />
des SSH-Clients um die folgenden<br />
Angaben:<br />
Host *<br />
ForwardAgent yes<br />
ForwardX11 yes<br />
XAuthLocation /usr/bin/xauth<br />
ForwardX11Trusted yes<br />
Es folgt der Aufruf von Xhost auf dem<br />
Client, damit dieser die Daten der X11-<br />
Applikationen des Raspberry annimmt:<br />
$ xhost +IP‐Adresse Raspberry<br />
Meldet man sich anschließend mit »ssh<br />
pi@raspberry X11‐Applikation« auf dem<br />
Raspberry an, erscheint auf dem Desktop<br />
des Clients ein Fenster mit der auf<br />
dem kleinen Rechner gestarteten X11-<br />
Anwendung. Abbildung 5 zeigt dies am<br />
Beispiel von Xclock.<br />
Zur Anwendung<br />
Der FreeBSD-Raspberry bietet viele<br />
Anwendungsmöglichkeiten, vom einfachen<br />
Router, bei Bedarf mit Paketfilter,<br />
über einen TOR-Anonymisierungsproxy<br />
bis zum Viren-Scanner und Spam-Filter<br />
für Windows-Netzwerke. (csc) n<br />
n Info<br />
Weiterführende Links und<br />
Informationen zu diesem<br />
Artikel finden Sie unter:<br />
www.admin-magazin.de/qr/31584<br />
[1] FreeBSD: [http:// www. freebsd. org]<br />
[2] Homepage des Autors mit Kernelkonfiguration<br />
und Images: [http:// www. dankoweit. de/<br />
FreeBSD/ hp_freebsd_raspberry. html]<br />
[3] FreeBSD Installieren – Konfigurieren – Administrieren,<br />
J. Dankoweit (Hrsg.), C&L-Verlag<br />
[4] FreeBSD-Handbuch: [http:// www. freebsd. org/<br />
doc/ de_DE. ISO8859‐1/ books/ handbook/]<br />
[5] FreeBSD-Entwickler-Handbuch:<br />
[http:// www. freebsd. org/ doc/ de/ books/<br />
developers‐handbook/]<br />
[6] Raspberry Pi: [http:// www. raspberry. org]<br />
[7] Raspberry-Pi-Dokumentation:<br />
[http:// www. raspberrypi. org/ technical‐helpand‐resource‐documents]<br />
www.admin-magazin.de<br />
Admin<br />
Ausgabe 03-2014
114<br />
Service<br />
Impressum und <strong>Vorschau</strong><br />
n Impressum ISSN 2190-1066<br />
<strong>ADMIN</strong>-<strong>Magazin</strong> eine Publikation der Medialinx AG<br />
Redaktionsanschrift Putzbrunner Straße 71<br />
81739 München<br />
Tel.: 0 89 / 99 34 11-0<br />
Fax: 0 89 / 99 34 11-99 oder -96<br />
Internet<br />
www.admin-magazin.de<br />
E-Mail<br />
redaktion@admin-magazin.de<br />
Geschäftsleitung Brian Osborn (Vorstand), bosborn@medialinx-gruppe.de<br />
Hermann Plank (Vorstand), hplank@medialinx-gruppe.de<br />
Chefredakteure<br />
Oliver Frommel (V. i. S. d. P.),<br />
ofrommel@admin-magazin.de (ofr)<br />
Jens-Christoph Brendel<br />
jbrendel@admin-magazin.de (jcb)<br />
Redaktion<br />
News/Report<br />
Ulrich Bantle (Ltg.), ubantle@medialinx-gruppe.de (uba)<br />
Mathias Huber, mhuber@medialinx-gruppe.de (mhu)<br />
Software/Programmieren Carsten Schnober, cschnober@medialinx-gruppe.de (csc)<br />
Kristian Kißling, kkissling@medialinx-gruppe.de (kki)<br />
Security/Networking Markus Feilner, mfeilner@medialinx-gruppe.de (mfe)<br />
Thomas Leichtenstern, tleichtenstern@medialinx-gruppe.de (tle)<br />
Ständige Mitarbeiter David Göhler (Schlussredaktion), Tim Schürmann, Claudia Thalgott<br />
Produktionsleitung<br />
Grafik<br />
Abo-Infoseite<br />
Abonnenten-Service<br />
Christian Ullrich, cullrich@medialinx-gruppe.de<br />
Judith Erb (Design und Layout)<br />
Titel: Judith Erb, Ausgangsgrafik: spectral, 123RF<br />
www.admin-magazin.de/abo<br />
Gudrun Blanz (Teamleitung)<br />
abo@admin-magazin.de<br />
Tel.: 07131/27 07 274, Fax: 07131/27 07 78 601<br />
Preise Print Deutschland Österreich Schweiz Ausland EU<br />
Einzelheft € 9,80 € 10,80 Sfr 19,60 (siehe Titel)<br />
Mini-Abo (3 Ausgaben) € 9,80 € 10,80 Sfr 19,60 (siehe Titel)<br />
Jahres-DVD (Einzelpreis) € 14,95 € 14,95 Sfr 18,90 € 14,95<br />
Jahres-DVD (zum Abo 1 ) € 6,70 € 6,70 Sfr 8,50 € 6,70<br />
Jahresabo € 99,90 € 109,90 Sfr 159,90 € 129,90<br />
Preise Digital Deutschland Österreich Schweiz Ausland EU<br />
Heft-PDF Einzelausgabe € 9,80 € 9,80 Sfr 10,71 € 9,80<br />
DigiSub (12 Ausgaben) € 89,90 € 89,90 Sfr 129,50 € 89,90<br />
DigiSub (zum Printabo) € 12,— € 12,— Sfr 12,— € 12,—<br />
HTML-Archiv (zum Abo 1 ) € 48,— € 48,— Sfr 48,— € 48,—<br />
Preise Kombiabos<br />
Profi-Abo 2 € 181,90 € 198,90 Sfr 235,90 € 219,90<br />
1<br />
nur erhältlich in Verbindung mit einem Jahresabo Print oder Digital<br />
2<br />
mit Linux-<strong>Magazin</strong>-Abo und beiden Jahres-DVDs<br />
Schüler- und Studenten-Ermäßigung: 20 Prozent gegen Vorlage eines Schülerausweises oder einer<br />
aktuellen Immatrikulationsbescheinigung. Der aktuelle Nachweis ist bei Verlängerung neu zu erbringen.<br />
Andere Abo-Formen, Ermäßigungen im Ausland etc. auf Anfrage.<br />
Adressänderungen bitte umgehend mitteilen, da Nachsendeaufträge bei der Post nicht für<br />
Zeitschriften gelten.<br />
Pressemitteilungen info@admin-magazin.de<br />
Anzeigen/Repräsentanz Es gilt die Anzeigenpreisliste vom 01.01.2013<br />
National<br />
Pressevertrieb<br />
Druck<br />
Petra Jaser<br />
Tel.: 089 / 99 34 11 24, Fax: 089 / 99 34 11 99<br />
E-Mail: pjaser@medialinx-gruppe.de<br />
Michael Seiter<br />
Tel.: 089 / 99 34 11 23, Fax: 089 / 99 34 11 99<br />
E-Mail: mseiter@medialinx-gruppe.de<br />
MZV, Moderner Zeitschriften Vertrieb GmbH<br />
Breslauer Straße 5, 85386 Eching<br />
Tel.: 089 / 31906-0, Fax: 089 / 31906-113<br />
Vogel Druck und Medienservice GmbH<br />
97204 Höchberg<br />
Der Begriff Unix wird in dieser Schreibweise als generelle Bezeichnung für die Unix-ähnlichen Betriebssysteme<br />
verschiedener Hersteller, zum Beispiel Eurix (Comfood), Ultrix (Digital Equipment), HP/UX (Hewlett-<br />
Packard) oder Sinix (Siemens) benutzt, nicht als die Bezeichnung für das Trademark von X/Open. Linux ist ein<br />
eingetragenes Marken zeichen von Linus Torvalds und wird in unserem Markennamen mit seiner Erlaubnis<br />
verwendet. Alle anderen Marken sind Eigentum der jeweiligen Inhaber. Eine Haftung für die Richtigkeit von<br />
Veröffentlichungen kann trotz sorgfältiger Prüfung durch die Redaktion vom Verlag nicht übernommen<br />
werden. Mit der Einsendung von Manu s kripten gibt der Verfasser seine Zustimmung zum Abdruck im <strong>ADMIN</strong>-<br />
<strong>Magazin</strong>. Für unverlangt ein gesandte Manuskripte kann keine Haftung übernommen werden. Die Redaktion<br />
behält sich vor, Artikel zu kürzen. Das Exklusiv- und Verfügungsrecht für angenommene Manuskripte liegt beim<br />
Verlag. Es darf kein Teil des Inhalts ohne ausdrückliche schriftliche Genehmigung des Verlags in irgendeiner<br />
Form vervielfältigt oder verbreitet werden. Copyright © 1994–2014 Medialinx AG<br />
n Autoren dieser Ausgabe<br />
Paul Brown Kontrolldatei 64<br />
Jürgen Dankoweit Himbeere mit Sahne 106<br />
Thomas Drilling Entspann Dich 40<br />
Thomas Drilling Schrittmacher 86<br />
Thomas Joos Fenster-Reparatur 46<br />
Thomas Joos Flotter Feger 92<br />
Hannes Kasparick Der Baum im Netzwerk 18<br />
Charly Kühnast Verschlüsselte Last 32<br />
Martin Loschwitz Maschen knüpfen 58<br />
Martin Loschwitz Orchesterprobe 74<br />
Thorsten Scherf Polyglotter Manager 14<br />
Tim Schürmann Narkosemittel 68<br />
Nirmal Sharma Durchs Fenster 96<br />
Ralf Spenneberg Einlasskontrolle 80<br />
Pierre Strohmeier Rettungsübung 52<br />
Ronny Trommer Automatisch überwacht 24<br />
Thomas Zeller Sicherer Kreislauf 36<br />
n Inserentenverzeichnis<br />
1&1 Internet AG http://www.einsundeins.de 9<br />
<strong>ADMIN</strong> http://www.admin-magazin.de 89, 103<br />
ConSol Software GmbH http://www.consol.de 11<br />
Fernschule Weber GmbH http://www.fernschule-weber.de 29<br />
hostNET Medien GmbH http://www.hostnet.de 2<br />
Linux-Hotel http://www.linuxhotel.de 13<br />
Linux-<strong>Magazin</strong> http://www.linux-magazin.de 71, 115<br />
M-Promotion http://www.poland-it.pl 67<br />
Medialinx AG http://www.medialinx-gruppe.de 79, 104<br />
Medialinx IT-Academy http://www.medialinx-academy.de 45, 55, 101<br />
outbox AG http://www.outbox.de 35<br />
PlusServer AG http://www.plusserver.de 17, 31, 39, 51, 57, 63<br />
ppedv http://www.visualstudio1.de 15<br />
Strato AG http://www.strato.de 116<br />
Thomas Krenn AG http://www.thomas-krenn.com 7<br />
WHD.global 2013 http://www.worldhostingdays.com 73<br />
Windows Phone User http://www.windows-phone-user.de 61<br />
Einem Teil dieser Ausgabe liegt eine Beilage der Firma HACKATTACK IT SECURITY GmbH<br />
(http://www.hackattack.com) bei. Wir bitten unsere Leser um freundliche Beachtung.<br />
n <strong>Vorschau</strong>: <strong>ADMIN</strong> 04/2014 erscheint am 13. März 2014<br />
watchara rojjanasain, 123RF<br />
Netzwerk-Dateisysteme<br />
Wohin mit den ganzen Daten?<br />
Will man sie netzwerkweit<br />
speichern, bieten sich neben<br />
den Klassikern NFS und Samba<br />
auch jede Menge Alternativen<br />
an. Mit interessanten Features<br />
für zuverlässiges Storage im<br />
Netz liefern sich GlusterFS und<br />
Ceph ein spannendes Rennen.<br />
Hybrid-Speicher<br />
im Test<br />
Festplatte oder SSD – das<br />
erfordert die schwierige Entscheidung<br />
zwischen großen<br />
Kapazitäten und schnellen<br />
Zugriffsgeschwindigkeiten.<br />
Hybrid-Speicher sollen dieses<br />
Dilemma auflösen. Wir testen,<br />
wie gut ihnen das gelingt.<br />
arcoss, 123RF<br />
Ausgabe 03-2014 Admin www.admin-magazin.de
<strong>ADMIN</strong> und Linux-<strong>Magazin</strong><br />
am Apple Newsstand!<br />
Jetzt NEU!<br />
Jetzt GRATIS<br />
testen!<br />
Alternativ finden Sie alle Titel der Medialinx AG auch bei:<br />
PagePlace, iKiosk, OnlineKiosk und Leserauskunft