ADMIN Magazin Datenbanken (Vorschau)

GPT: Partitionsschema Cgroups: Mit Linux Rechner- 389: LDAP und
für Terabyte-Festplatten Ressourcen kontrollieren Active Directory
ADMIN
Netzwerk & Security
Auf CD:
06 2011
Nov. – Dez.
Datenbanken
11.10
Server
11.10
Server-Ausgabe
16 zum gleichen Preis!
Seiten mehr Inhalt
Know-how und Tests
Wer ist schneller, MySQL oder PostgreSQL?
NoSQL-Datenbanken im Überblick
RAM erklärt
Wie funktionieren
Speicherchips?
Virtualisierung
Grafisches Management
von VMs mit Archipel
High Availability
n iSCSI-HA-Cluster
n Troubleshooting
Groupware
Zarafa in den Univention
Corporate Server integriert
Programmieren
Skripten mit Python
und Ruby
www.admin-magazin.de
D EUR 9,80
A EUR 10,80 - BeNeLux EUR 11,25
CH sfr 19,60 - E / I EUR 12,75
4 196360 509805 06

Kinderstube der Revolution
Editorial
Kindertage der
Revolution
Liebe Leserinnen und Leser,
am Anfang gab es Strom, aber noch kein Netz. Elektrizität musste man exakt
dort produzieren, wo sie verbraucht werden sollte. Und so lieferten viele kleine
Generatoren Strom für elektrifizierte Inseln. Zuerst hauptsächlich für Lampen,
bald aber auch schon für Motoren. Das war ein riesiger Fortschritt: Elektrisches
Licht brauchte im Unterschied zur Gasbeleuchtung keinen Laternenanzünder
mehr, rußte nicht, verursachte nicht so schnell Brände. Elektromotoren konnte
man am Einsatzort platzieren, ihre Energie erhielten sie durch überall verlegbare
Kabel – so sparte man die verlustreiche und anfällige Transmission, mit der man
in der Dampf- und Wasserkraft-Zeit die Energie über gigantische Konstruktionen
aus Riemen und Gestängen leiten musste.
Trotzdem fehlte in den Anfangsjahren der Elektrifizierung, als etwa Westinghouse und Tesla die Weltausstellung
1893 in Chicago mit mehr als 200 000 eigens angefertigten Glühlampen spektakulär illuminierten, noch
das meiste, was uns heute selbstverständlich ist. Es gab keine Steckdosen, Sicherungen oder Stromzähler. Den
Wettlauf mit dem Gleichstrom (Edison) hatte der Wechselstrom erst mit dieser Ausstellung gewonnen, auf der
30 Millionen Menschen das Lichtermeer bewunderten. Auch große Kraftwerke existierten noch nicht.
Die kamen aber bald. Denn es zeigte sich rasch, dass sie Strom sehr viel wirtschaftlicher zu erzeugen vermochten
als einzelne Generatoren. Beispielsweise weil man sie dort errichten konnte, wo Wasserkraft verfügbar
war oder wo sich Kohle fördern ließ. Sie konnten Lastspitzen besser abfedern und eine höhere Versorgungssicherheit
garantieren. Auch verfügten sie über die nötige Kapazität, um ganze Städte zu versorgen. So setzten
sie sich dank ihrer wirtschaftlichen Überlegenheit durch, und mit ihnen entstand in allen Industrieländern das
Wechselstromnetz.
Eine ähnliche Situation erleben wir heute: Wir rechnen noch in Inseln, wissen aber schon, dass riesige zentralisierte
Data Center viel wirtschaftlicher wären. Die nennen wir Cloud und bauen ihnen gerade eine Infrastruktur,
über die ihre Leistungen überall abrufbar werden. Die Steckdosen und Sicherungen werden eben erfunden, aber
erste Vorzeigeprojekte lassen sich schon bestaunen. Genau wie zu Beginn des Siegeszugs der Elektrifizierung
fehlen noch Standards – die Netzspannung ist europaweit auch erst seit 1987 normiert. Genau wie damals sind
wir uns bewusst, dass wir am Anfang einer Revolution stehen. Aber wie zum Ende des 19. Jahrhunderts können
wir die Folgen noch nicht gänzlich überblicken. Wir wissen nur: Sie werden gravierend sein. Auch und gerade für
Administratoren.
@ leserbriefe@admin-magazin.de
www.facebook.com/adminmagazin www.twitter.com/admagz
www.admin-magazin.de
Admin
Ausgabe 06-2011
3

SErvice
ADMIN
Netzwerk & Security
Inhalt
06/2011
Welche freie Datenbank ist
schneller? MySQL oder PostgreSQL?
Die Antwort auf S. 40.
48NoSQL
Der neue Trend bei
Datenbanken fürs Web
im ausführlichen Grundlagenartikel.
Login
Netzwerk
Schwerpunkt: Datenbanken
8 Branchen-News
Neues von Firmen und Projekten.
16 Vorgelesen
Bücher über PostgreSQL und Virtualbox.
18 Admin-Story
Tagebuch eines IT-Nomaden.
22 Leserbriefe
Kommentare und Meinungen.
28 Hyper-V-Netz optimieren
Netzwerkoptimierung bei Microsofts
Virtualisierungsplattform.
34 LDAP und Active Directory
Ein virtuelles Directory mit dem Fedora
389 Directory Server aufsetzen.
40 PostgreSQL vs. MySQL
Benchmarks zeigen, wie
viel geschicktes Tuning
der Open-Source-Datenbanken
bringt.
48 NoSQL
Technische Grundlagen, Klassifikation
und ein Überblick über freie NoSQL-
Datenbanken.
24 Think Twice
Open Source: doppelte Arbeit oder
Wahlfreiheit?
26 Interview
Nagios-Gründer Ethan
Galstad über das
eigene Projekt und die
Konkurrenz.
Service
3 Editorial
4 Inhalt
6 Heft-CD
130 Impressum und Vorschau
Test
58 Windows Server 8
Eine Vorschau auf die kommende
Version des Windows-Servers.
62 Archipel
Virtualisierungsmanagement mit
grafischer Oberfläche.
4 Ausgabe 06-2011 Admin www.admin-magazin.de

Inhalt
Service
90Cgroups
Ressourcenkontrolle
unter Linux
auf der Basis von Prozessen, Benutzern,
Gruppen und so weiter.
122Python
Ein gut gefüllter
Werkzeugkasten
für alle Skriptaufgaben.
114RAM
Funktion und Typen
von Speicherbausteinen
im Detail erklärt.
Security
68 LXC
Prozesse eingesperrt: Container-
Virtualisierung mit LXC mit Ubuntu
10.04.
70 Überwiegend heiter?
Überlegungen zur Sicherheit beim
Cloud-Computing.
Basics
109 GPT-Partitionen
Terabyte-Festplatten partitionieren.
114 RAM demystified
Wie funktionieren Speicherbausteine?
118 Windows-Tuning
Mit freien Tools die Performance messen.
Programmieren
122 Python
Einführung in die Skriptsprache und
eine Kurzvorstellung nützlicher Module.
126 RVM
Mehrere Ruby-
Versionen gleichzeitig
verwalten.
Know-how
72 Performance-Simulation
Was wäre wenn? Mathematische
Lastsimulation mit Perl.
90 Cgroups
Feingranulare Ressourcenkontrolle
mit Linux.
102 High-Availability-Serie, Teil 5
Troubleshooting beim hochverfügbaren
Cluster.
84 High-Availability-Serie, Teil 4
Hochverfügbares iSCSI-Storage.
94 Zarafa mit Univention
Die Groupware in den Univention
Corporate Server integrieren.
Mehr Infos auf Seite 6
11.10
Oneiric Ocelot
11.10
Server
www.admin-magazin.de
Admin
Ausgabe 06-2011
5

SErvice
Heft-CD
Heft-CD
Auf dem beiliegenden Datenträger finden Sie die Server-Ausgabe
der neuesten Ubuntu-Version 11.10 „Oneiric Ocelot“:
◗ 64-Bit-Version für AMD 64 und Intel EM 64 T.
◗ Linux-Kernel 3.0.
◗ Virtualisierung mit KVM und Xen (Preview).
◗ Cloud-Support durch Open Stack und die Ubuntu-Entwicklung
Juju.
◗ Viele Verbesserungen für Ext4, Btrfs, TCP u.v.m.
Legen Sie einfach die CD ins das Laufwerk ein und starten
Sie den Rechner. Möglicherweise müssen Sie noch im BIOS
die richtige Boot-Reihenfolge einstellen, damit das CD/
DVD-Laufwerk vor der Festplatte an die Reihe kommt. n
CD kaputt?
Wir schicken Ihnen kostenlos
eine Ersatz-CD zu, E-Mail genügt:
info@admin-magazin.de
Info
[1] Ubuntu 11.10 Release Notes:
[http://wiki.ubuntu.com/OneiricOcelot/ReleaseNotes]
[2] Cloud-Technologie in Ubuntu:
[http://cloud.ubuntu.com]
6 Ausgabe 06-2011 Admin www.admin-magazin.de

100%
SLA
Private Cloud
Lösungen
Erstellen Sie Ihr virtuelles
Datacenter in Sekundenschnelle
Einrichtungsgebühr
595 €
GESCHENKT
Erwecken Sie Ihre Projekte zum Leben, indem
Sie virtuelle Maschinen und Ressourcen hinzufügen
und passen Sie diese Infrastruktur in Echtzeit an
eine auf Ihre Bedürfnisse erweiterbare Infrastruktur
▪
inklusive VMware ® Funktionen zur sicheren und direkten
▪
Verwaltung Ihrer Ressourcen
100% Verfügbarkeit: OVH verpflichtet sich, Sie ab
der ersten Sekunde Nichtverfügbarkeit zu entschädigen
Ab
509, 90 €
inkl. MwSt./
Monat
Berechnen Sie Ihre Kosten und bestellen Sie direkt auf
unserer Website www.ovh.de/pcc oder kontaktieren Sie unsere
Berater unter der 0049 (0) 681 906 730
Sie finden unseren
Prospekt in dieser
Ausgabe
Neue Zertifizierung
Europas Webhoster Nr. 1
Quelle NetCraft – Juni 2011
Domains | E-Mails | Hosting | VPS | Server | Private Cloud | Cloud | SMS | Telefonie
OVH.DE

Login
News
+++ neueste Nachrichten immer auf http://www.admin-magazin.de +++++ neueste Nachrichte
Neue Software und Produkte
Branchen-News
Meego ist tot – es lebe Tizen
Die Linux Foundation hat eine neue Mobilplattform namens
Tizen angekündigt, die Meego ablöst. Intel und Samsung sind
die Hauptsponsoren des Linux-basierten Betriebssystems für
mobile Geräte. Tizen widmet sich vornehmlich Apps, die auf
HTML 5 basieren. Zudem will sich Tizen an die beim Mobile
World Congress im Frühjahr gegründete Wholesale Applications
Community (WAC) und deren Plattformvorgaben halten. Deshalb,
so Imad Sousou, Director von Intels Open Source Technology
Center an die Meego-Community, sei es nicht sinnvoll,
Meego weiterzuentwickeln. Tizen solle auch nicht nur eine
Web-Runtime für ein existierendes Linux-System wie Meego
sein, sondern mehr, so Sousou. Die Integration innerhalb der
Linux Foundation bleibe aber ungefähr gleich. Es gäbe wie bei
Meego ein Steuerungsgremium, es käme die gewohnte Infrastruktur
zum Einsatz, und Tizen [https://​www.​tizen.​org] sei Open
Source, schreibt Sousou in seinem Beitrag. In den nächsten
Monaten werde man den Meego-Nutzern und Entwicklern beim
Übergang zu Tizen unter die Arme greifen. Eine erste Tizen-
Version sei im ersten Quartal 2012 zu erwarten, heißt es vom
zuständigen Intel-Mann.
Intel selbst betont in einer Mitteilung die Geräteunabhängigkeit
der geplanten Plattform, die auf den Stärken von Meego und
Limo aufbaue. Beim Tizen-Projekt selbst ist von Meego nicht die
Rede. Smartphones, Tablets, Netbooks, In-Vehicle Infotainment
nebst TV-Geräten sind dort als Zielplattformen genannt. Das
von Intel und Nokia initiierte Meego hat damit einen kurzen
und erfolglosen Lebenszyklus hinter sich. Entsprechend enttäuscht
sind die Entwicklerstimmen beim Meego-Projekt.
Schuppentier: Shuttleworth tauft Ubuntu 12.04
DZUG wird Python Software Verband
Zur Tradition von Ubuntu-Releases gehört die Benennung der Version durch
Ubuntu-Gründer und ‐Finanzier Mark Shuttleworth. Für die 12.04, die nächste
Version mit Long Term Support (LTS), hat Shuttleworth in seinem Blog den Precise
Pangolin ausgewählt. Die Idee zum präzisen Pangolin, einem Schuppentier,
das sich von Ameisen und Termiten ernährt, kam Mark Shuttleworth bei einer
Tour durch die Kalahari, bei der er ein Pangolin verfolgte.
Wie Shuttleworth in seinem Blog [http://​www.​markshuttleworth.​com/​archives/​784]
schreibt, sei das Pangolin passend, weil es „präzise“ jeden Ameisenhügel
ansteuert und weil seine Schuppen ein Wunder an Detailreichtum und damit
schon ein Fashion Statement seien. Letzteres bezieht Shuttleworth auf
die hauseigene Desktopumgebung Unity, deren Design bisher aber nicht auf
ungeteilte Zustimmung gestoßen ist. Nicht zuletzt kann sich das Pangolin
hervorragend schützen und so auch den Angriffen von Löwen standhalten.
Diese Eigenschaften seien für Ubuntu LTS ebenfalls zutreffend, weshalb er
die Alternativen Perspicacious Panda, Predatory Panther, Peccable Peccary,
Pawky Python, Perfidious Puku und Porangi Packhorse verworfen habe.
Die Codenamen
der Ubuntu-Releases
folgen dem Alphabet,
die nächste
Version bekommt
ein Wappentier mit
„Q“. Gerade eben
erschien Ubuntu
11.10 mit dem Namen
Oneiric Ocelot.
Precise Pangolin
ist für April
Namenspatron von Ubuntu 12.04 LTS: das Schuppentier, hier in einer
Abbildung von Hubert Ludwig, Schul-Naturgeschichte 1891.
2012 anvisiert.
Die deutschsprachige Zope User Group (DZUG
e.V.) öffnet sich für vielfältige Python-Projekte
und ändert ihren Namen zu „Python Software
Verband“. Das hat die Mitgliederversammlung
einstimmig auf der ersten Deutschen Python-
Konferenz [http://​de.​pycon.​org/​2011/​home] beschlossen,
die vom 4. bis 9. Oktober in Leipzig stattfand.
Der Verband möchte die Interessen von Python-
Anwendern in Deutschland, Österreich und der
deutschsprachigen Schweiz vertreten. Dabei
verstehe er sich als Dienstleister der vielgestaltigen
Community, teilt der erste stellvertretende
Vorsitzende Jan Ulrich Hasecke der Redaktion
mit: Die Organisation unterstützt Anwendergruppen
bei Veranstaltungen und bietet ihnen
eine technische Infrastruktur.
Daneben soll der Verband der Python-Community
als Marketingabteilung für die Programmiersprache
und ihre Anwendungen dienen.
Schließlich will die Vereinigung auch Lobbyarbeit
für den Python-Einsatz und Open- Source-
Software im Allgemeinen leisten und gegen Softwarepatente
eintreten.
Die Umbenennung muss noch ins Vereinsregister
eingetragen werden, als neue Domain ist
[http://python-verband.​de] in Vorbereitung. In der
Zwischenzeit gibt es weitere Informationen auf
der DZUG-Website [http://​www.​dzug.​org].
8 Ausgabe 06-2011 Admin
www.admin-magazin.de

n immer auf http://www.admin-magazin.de
Datenbank-Appliance von Oracle
Ab sofort ist eine neue Datenbank-Appliance von Oracle verfügbar,
die vor allem für kleinere und mittlere Unternehmen eine
günstige Alternative sein will.
Die Appliance besteht aus zwei geclusterten SunFire-Servern
unter Oracle Linux, auf denen eine vorinstallierte Oracle-
Datenbank 11g Release 2 läuft. Auch Storage und redundante
Netzwerkverbindungen sind bereits integriert und von zentraler
Stelle aus administrierbar. Die Leistungsfähigkeit des Clusters
lässt sich steigenden Bedürfnissen dadurch anpassen, dass per
Software sukzessive zwei bis 24 Cores freigeschaltet werden
können. Ein einzelner Serverknoten verfügt dabei über eine
6-Kern-Xeon-CPU X5675. Der Hauptspeicher ist bis 192 GByte
ausbaubar, der Plattenplatz kann maximal 12 TByte umfassen
(dreifach gespiegelt, 4 TByte nutzbar). Die Appliance soll sich
für OLTP-Workloads und Data Warehouses eignen.
IBM baut Smart Cloud aus
Bis Ende kommenden Jahres will IBM 200 Millionen Nutzer
dabei unterstützen, ihre Kernanwendungen in die neue IBM
SmartCloud zu verlagern.
Dazu baut IBM seine Offerten stark aus. Zu den erweiterten
Angeboten zählen unternehmensweit einsetzbare Platform-asa-Service-Lösungen,
Starter Kits für einen schnelleren Einsatz
privater Clouds, neue industriespezifische Cloud Services sowie
eine erhebliche Ausweitung des IBM SmartCloud-Ökosystems
für Cloud-Partner.
IBM reagiert damit auch auf die Ergebnisse eigener Studien,
denen zufolge sich in den nächsten drei Jahren die Zahl der
Firmen, die mehr als ein Cloud-Projekt eingeführt haben, auf
66 Prozent verdoppeln soll. Nach Meinung der im Rahmen der
Studie Befragten bestünden zwar noch große Herausforderungen
auf Gebieten wie Sicherheit, Zuverlässigkeit, Standards
und Kontrolle, dennoch erwarten 40 Prozent bis zum Jahr 2015
„substanzielle Veränderungen“.
Deutscher Speichermarkt wächst
Der deutsche Markt für Massenspeicher wird dieses Jahr um 2,5
Prozent zulegen. Das erwartet der Branchenverband BITKOM.
Auch für das nächste Jahr werden noch 5 Prozent Wachstum
prognostiziert. Motor der guten Entwicklung ist der Trend zu
immer größeren Datenmengen (Big Data). Beispiele reichen von
der automatischen Erfassung von RFID-Lesern in der Produktion
und Logistik bis zur Digitalisierung von Bildern, Musik und
Videos in HD oder 3D. Laut IDC verdoppelt sich dadurch das
Datenvolumen weltweit etwa alle 18 Monate. Diese Daten landen
schließlich auf Diskarrays und Tape Libraries und kurbeln
daher deren Umsatz entsprechend an. „Die rasant wachsenden
Datenmengen und der Nachholbedarf an Investitionen in IT-
Infrastruktur sorgen für ein anhaltendes Wachstum im Storage-
Markt“, sagte BITKOM-Vizepräsident Volker Smid.
www.admin-magazin.de
Virtuelle Server
Top-Performance zum Tiefpreis!
• bis zu 3 CPU-Kerne
• bis zu 8 GB RAM
• bis zu 95 GB Festplatte
• RAID-10-Datensicherheit
• 5.000 GB Traffic inklusive
• SSL-Zertifikat inklusive
• Root-Zugriff per SSH
• 100 % Backup-Speicher
• 99,9 % garantierte Verfügbarkeit
• 30 Tage Geld-zurück-Garantie
• auch als Managed Server erhältlich
• viele 64-Bit-Betriebssysteme nach Wahl
6 Monate
kostenlos
danach ab 12,99 €*
Jetzt kostenlos informieren unter:
080 0 638 2587
www.netclusive.de/linux
* Aktion „6 Monate kostenlos“ gilt bis 31.12.2011. Nach 6 Monaten regulärer monatlicher Grundpreis:
VPS L 12,99 €, VPS XL 16,99 €, VPS XXL 29,99 €. Die Mindestvertragslaufzeit beträgt wahlweise 12 Monate
(Aktion 6 Monate kostenlos entfällt) oder 24 Monate (6 Monate kostenlos). Abrechnung vierteljährlich. Einmalige
Einrichtungsgebühr 9,99 €. Alle Preise inkl. MwSt. Preisänderungen und Irrtümer vorbehalten.

Login
News
+++ neueste Nachrichten immer auf http://www.admin-magazin.de +++++ neueste Nachrichte
Wikipedia Italien bangt um Unabhängigkeit
Die Betreiber der Wikipedia Italien fürchten
um die weitere Existenz der freien
Online-Enzyklopädie. Das italienische
Parlament berät über ein Gesetz, das
Websites eine Korrektur innerhalb von
48 Stunden vorschreibt, wenn Persönlichkeitsrechte
verletzt werden.
Dass diese Vorgabe ohne richterliche
Begutachtung eines entsprechenden
Vorwurfs umgesetzt
werden soll, hält die Wikipedia in
Italien für eine Erschütterung der
Grundsätze einer unabhängigen
und freien Wissensdatenbank. Es
genüge, so schreibt die Wikipedia
[http://​it.​wikipedia.​org/​wiki/​Wikipedia:
Comunicato_4_​ottobre_2011/​de], dass
ein Betroffener diese Forderung
an die Websitebetreiber reiche.
Dass davon in Italien alle Websites
betroffen wären, und damit auch
jedes Blog ohne weitere Diskussion die
geforderte Korrektur umsetzen müsste,
halten die italienischen Wikipedianer für
nicht hinnehmbar und sehen darin einen
schwerwiegenden Eingriff in ihre Freiheit
und Unabhängigkeit.
Offener Brief statt Inhalte – Italiens Wikipedia sieht Existenz bedroht.
Beim fraglichen Gesetzesentwurf handelt
es sich laut Wikipedia um den Paragraph
29 des sogenannten „DDL intercettazioni“,
was mit Abhörmaßnahmen übersetzt
wird.
Eine Wikipedia, wie es sie derzeit in Italien
gäbe, sei damit nicht mehr denkbar.
Im Brief heißt es: „Die sich aus
Paragraph 29 ergebende Verpflichtung,
die Korrektur ohne
Recht auf Diskussion und Überprüfung
der Inhalte veröffentlichen
zu müssen, würde zu einer
inakzeptablen Beschneidung der
Freiheit und Unabhängigkeit der
Wikipedia führen, zur Beschädigung
der Prinzipien, auf denen
Wikipedia steht, ja letztlich zum
Ende des Projektes, wie wir es
bis heute kennen.“
Cloud-Zuwachs bei der Linux Foundation
Drei namhafte Open-Source-Firmen – Nebula, Eucalyptus und
Virtual Bridges – sind der Linux Foundation beigetreten. Damit
stärkt die Linux Foundation vor allem ihre Kompetenz in Sachen
Cloud-Computing. Das neue Mitglied Nebula entwickelt eine
Linux-basierte Hardware-Appliance für große Private Clouds.
Eucalyptus bietet ebenfalls unter Linux eine Infrastructure-asa-Service-Lösung.
Der Firmenchef und frühere MySQL AB-CEO
Marten Mickos ist überzeugt: Linux- und Open-Source-Hypervisors
sind die wichtigsten Bausteine von Clouds. Virtual Bridges
schließlich beschäftigt sich mit Desktop-Virtualisierung.
Mozillas Rückblick und Ausblick
Die Mozilla Foundation hat einen Jahresbericht für 2010 samt
einem Ausblick veröffentlicht.
Der im Web in vielen Sprachen verfügbare Bericht hält Rückschau
auf das vergangene Jahr und formuliert dabei Ziele für
die Zukunft von Mozillas Produkten wie etwa Firefox. Neben
dem Desktop soll der Browser in Zukunft auf möglichst vielen
Mobilgeräten laufen, schreibt das Projekt. Firefox Mobile für
Android sei ein erster Schritt in diese Richtung.
Mozilla hat mit der Mozilla Foundation und allen Tochtergesellschaften
im Jahr 2010 Einnahmen von 123 Millionen US-Dollar
erzielt, was ein Plus von rund 18 Prozent gegenüber 2009 darstelle,
heißt es in den Erläuterungen zum Jahresbericht [http://​
​www.​mozilla.​org/​de/​foundation/​annualreport/​2010/​faq/]. Der Löwenanteil
davon komme von den im Browser aufrufbaren Suchfunktionen,
also von Suchmaschinenbetreibern wie Google.
Als weitere Meilensteine des Jahres 2010 nennt der Bericht die
raschere Versionsabfolge sowie die Privacy-Funktion „Do Not
Track“, daneben Community-Aktivitäten in der Arabischen
Welt, Afrika und Indonesien.
Der Bericht schließt mit einer Video-Botschaft der Vorsitzenden
Mitchell Baker. Sie warnt vor der Protokollierung, Regulierung
und wirtschaftlichen Verwertung der Web-Nutzer und wirbt
dafür, das Web offen zu halten.
Mozillas Jahresbericht ist auf den Seiten der Stiftung in deutscher
Sprache zu finden. Die enthaltenen Web-Videos sind
allerdings auf Englisch.
Setzt auf Veränderung und Hoffnung: die Mozilla-Vorsitzende Mitchell Baker in
einem recht emotionalen Video-Ausblick auf die kommenden Jahre
10 Ausgabe 06-2011 Admin
www.admin-magazin.de

n immer auf http://www.admin-magazin.de
Microsoft stiftet Cloud-Preis
Microsoft lobt einen neuen „Cloud 4 Society Award“ aus, der
speziell Startups zugute kommen soll, die die Potenziale von
Cloud-Computing für die Gesellschaft erschließen.
Teilnehmen können junge Unternehmen, die mit ihrer Dienstleistung
oder ihrem Produkt maximal drei Jahre am Markt
sind und die Cloud-Lösung auf Basis von Windows Azure
entwickelt haben. Eine Fachjury bewertet eingereichte Projekte
anhand von Kriterien wie Grad der Innovation und Nutzen für
die Gesellschaft in den fünf Kategorien Bildung & Forschung,
Gesundheit & Umwelt, eGovernment, eCommerce sowie Social
& Entertainment. Fünf Finalisten präsentieren ihre Projekte
im Rahmen des Microsoft-Messe-Auftritts auf der CeBIT 2012
in Hannover. Aus ihren Reihen wird dann der Gewinner des
„Cloud 4 Society Awards“ ermittelt und auf der CeBIT ausgezeichnet.
Ihm winkt ein Preisgeld von 20 000 Euro.
TM
MobyDick
D i e Z u k u n f t der Telefonie
Mit der MobyDick Telefonanlage haben Sie alle Fäden selbst in
der Hand. Außerdem verbinden Sie die Features modernster
Telefonie mit den Vorteilen von Voice over IP.
Die Kommunikationslösung für Ihr
Unternehmen
Open-Source-Repository Berlios schließt
Das vor rund zehn Jahren vom Fraunhofer-Institut für Offene
Kommunikationssysteme (Fokus) entwickelte Projekt Berlin
Open Source kurz Berlios stellt zum Jahresende den Betrieb ein,
heißt es in einer Mitteilung auf der Webseite.
Gefördert wurde das Projekt Berlios durch das Bundesministerium
für Wirtschaft und Technologie und einige Geldgeber
aus der Industrie. Der Betreiber Fraunhofer Fokus nennt als
Kennzahlen, dass 2011 rund 4800 Projekte gehostet würden,
Berlios rund 50 000 registrierte Nutzern zähle sowie über 2,6
Millionen Downloads pro Monat verzeichne. Nun fehlt dem
Projekt die Anschlussfinanzierung, die Suche nach Sponsoren
sei ergebnislos verlaufen. Entwickler sollen ihre Projekte auf
andere Repositories umziehen, ein Leitfaden auf der Webseite
[http://​developer.​berlios.​de] hilft dabei.
HP und Ubuntu kooperieren bei Public Cloud
Bei der Open-Stack-Konferenz in Boston hat Canonical-
Geschäftsführerin Jane Silber im Oktober eine Zusammenarbeit
mit Hewlett-Packard bei Public-Cloud-Angeboten angekündigt.
HP hat sich demnach für Ubuntu als Basis für die Open-
Stack-Plattform entschieden und will Angebote für Entwickler,
ISVs und Firmen schnüren. Ubuntu, so wird Jane Silber im
Canonical-Blog zitiert, soll bei HPs Public-Cloud-Services als
Host- und Gastsystem zum Einsatz kommen. Derzeit sind die
Kooperationspartner mit dem Testen einer Betaversion befasst,
was allerdings nicht öffentlich geschieht. Herauskommen soll
dann eine skalierbare und sichere Lösung für Unternehmen
aller Größen.
Beide Partner setzten auf Open Source, so Jane Silber, und
beide engagieren sich in der Open-Stack-Community. Die inzwischen
bei Open Stack versammelten 117 Mitglieder stellten
ein Schwergewicht in der künftigen Entwicklung des Cloud
Computing dar, urteilt die Geschäftsführerin.
www.admin-magazin.de
Unified Communications:
Telefon
Video
VoiceMail
Präsenzmanager
Instantmessaging
FaxEmail Gateway
PrintFax Gateway
Conferencing
Mehr Informationen finden Sie unter:
http://www.pascom.net
http://community.pascom.net
NEU
Kostenlose
Community
Version
erhältlich
pascom
Netzwerktechnik GmbH & Co. KG
Berger Straße 42
94469 Deggendorf
Tel.: +49 991 27006 - 0

Login
News
© Nielsen
Android geht in den USA an die Spitze
Der Marktforscher Nielsen hat bei
seiner Smartphone-Erhebung im
August in den USA einen Anteil
von 43 Prozent für das Betriebssystem
Android gemessen. Auf die
vergangenen drei Monate gesehen
sieht der Marktanteil für Android
noch besser aus: 56 Prozent der
Smartphone-Käufer haben in diesem
Zeitraum auf Android-Handys
US-Markt der Smartphone-Systeme im August und
über drei Monate hinweg betrachtet.
gesetzt. Apple liegt mit 28 Prozent
auf Rang zwei, sowohl in der
August-Umfrage [http://​blog.​nielsen.​
​com/​nielsenwire/​online_mobile/​in‐usmarket‐new‐smartphone‐buyers‐increasingly‐embracing‐android/]
als auch
bei den Käufern im Dreimonatszeitraum.
RIMs Blackberry liegt
im August bei 18 Prozent, verliert
aber bei den Anschaffungen in den
vergangenen drei Monaten
extrem und verzeichnet dort
nur noch 9 Prozent.
Der Smartphone-Markt legt
in den USA insgesamt gegenüber
herkömmlichen
Handys zu. 43 Prozent der
Mobilfunkkunden in den
USA hatten im August ein
Smartphone. In den vergangenen
drei Monaten haben
sich demgegenüber 56
Prozent der Käufer für ein
Smartphone entschieden.
Heimkehr des Linux-Kernels
Linus Torvalds hat sein offizielles Git-Repository auf
Kernel.org wieder in Betrieb genommen. Aus Anlass
des Release Candidate 9 für die kommende Linux-
Version 3.1 hat der Kernel-Chef sein Repository unter
der alten Adresse auf Git.kernel.org aktualisiert. Gleichzeitig
erfuhr auch das in der Zwischenzeit verwendete
Github-Konto ein Update.
Der Release Candidate bringt laut Torvalds nur kleine
Verbesserungen: Fixes gab es beispielsweise im DRM-
Code für Radeon- und i915-Grafikchips, für Netzwerktreiber
sowie für das verteilte Dateisystem Ceph. Auch
der Sparc-Port erfuhr kleine Änderungen.
Daneben besitzt Linus nun einen stärkeren GPG-Schlüssel,
der bereits von mehr Parteien unterschrieben ist,
als es der alte je war. Damit nimmt er an der Sicherheitsstruktur
für Kernel.org teil, die H. Peter Anvin
und die anderen Admins nach dem Server-Einbruch
aufbauen. Wer den neuen Schlüssel importiert, kann
mit dem Kommando „git verify-tag“ die Signatur der
getaggten Kernel-Releases prüfen.
Die Bezugsquelle und den Fingerprint seines neuen
Schlüssels nennt Torvalds in der entsprechenden Mitteilung
an die Kernel-Mailingliste [https://​lkml.​org/​lkml/​
​2011/​10/​4/​451].
SmartOS verbindet Open Solaris und KVM
Die Firma Joyent hat das Betriebssystem SmartOS freigegeben,
das auf Open Solaris und der Linux-Virtualisierungslösung
KVM basiert. Als Code-Basis diente den Entwicklern der vom
Storage-Hersteller Nexenta initiierte Open-Solaris-Fork Illumos.
Darauf haben sie den Linux-Hypervisor KVM portiert, der als
leistungsfähige Virtualisierungstechnologie seit einiger Zeit etablierten
Lösungen wie Xen und VMware Konkurrenz macht.
Beispielsweise basiert auch Red Hats „Enterprise Virtualization“
auf KVM. SmartOS richtet sich an jeden Anwender, der einen
Server betreiben möchte, und wird laut FAQ von Joyent bereits
produktiv im eigenen Datacenter eingesetzt.
Einer der maßgeblichen Entwickler hinter SmartOS ist Bryan
Cantrill, der früher bei Sun an Solaris arbeitete, aber nach der
Übernahme durch Oracle das Unternehmen verließ. Er sieht großes
Potenzial darin, Schlüsseltechnologien wie ZFS und DTrace
von Solaris und KVM von Linux in einem fortschrittlichen Betriebssystem
zusammenzubringen. Diese Rolle soll nun Smart OS
übernehmen, das unter der CDDL lizenziert ist. In einem Blog-
Eintrag berichtet er von den Erfahrungen, die sein Team bei der
Portierung von KVM gemacht hat. Im Joyent-Blog [http://​smartos.​
​org/​blog/] sind einige Hinweise zu den Downloads sowie farbige
Grafiken über den bisherigen Zuspruch zu finden.
VMware Workstation 8 erschienen
Seit September 2011 ist Version 8 von VMware Workstation verfügbar,
die nach Angaben des Herstellers 50 neue Funktionen
enthält. Ein neues Feature erlaubt Anwendern von Workstation
8 beispielsweise, ihre VMs per Drag-and-Drop in VMware
vSphere zu verschieben. Die GUI wurde um einfachere Menüs,
Live-Miniaturansichten, verbesserte Einstellungsbildschirme
und eine neue VM-Bibliothek erweitert, die nach Vorstellung
von VMware eine „persönliche Cloud“ des Anwenders realisieren
sollen. Ein neues Sharing-Feature erlaubt es, virtuelle Maschinen
mit anderen Anwendern zu teilen, um beispielsweise
Teamarbeit zu ermöglichen. Neu ist auch die Unterstützung
von HD Audio mit 7.1 Surround Sound, USB 3 und Bluetooth-
Geräten und bis zu 64 GByte RAM.
VMware-Manager Chris Young kommentierte das Update mit
einem Seitenhieb auf das Desktop-Virtualisierungsprodukt von
Oracle: „Unser Team versteht die Bedürfnisse der Nutzer und
hat in Workstation 8 bedeutende Verbesserungen vorgenommen,
die es einfacher machen, über die „Virtual Box“ hinauszukommen.“
VMware Workstation 8 ist ab sofort zu einem Preis von 199
US-Dollar verfügbar. VMware Workstation 6.x und 7.x sind
weiterhin für 99 US-Dollar zu haben.
12 Ausgabe 06-2011 Admin
www.admin-magazin.de

News
Login
Univention prämiert Abschlussarbeiten
Wie schon in den letzten Jahren sucht der Linux-Distributor Univention auch 2012 wieder
Abschlussarbeiten, die sich mit Open Source auseinandersetzen. In diesem Jahr winkt
zusätzlich eine Sonderprämie in Höhe von 1000 Euro für eine Arbeit zum Thema „Cloud“.
Das mögliche thematische Spektrum reiche dabei von „Zielgruppen-orientierten Untersuchung
nützlicher Open-Source-Komponenten oder Anwendungen für Cloud-Anbieter über
betriebswirtschaftliche und juristische Analysen bis hin zu Software-Entwicklungen“.
Wer seine Abschlussarbeit einreichen möchte, kann sie bis zum 15. Februar 2012 per
E-Mail an [absolventenpreis@univention.​de]
schicken. Der Absolventenpreis solle die
„Verbreitung von Open Source Software
im professionellen Umfeld und die Entwicklung
von innovativen Ideen für freie
und quelloffene Anwendungen vorantreiben“,
sei aber interdisziplinär orientiert.
Eine Expertenjury, zu der auch Linux-
Magazin-Chefredakteur Jan Kleinert zählt,
entscheidet über die innovativsten und
besten Arbeiten. Die Preisverleihung findet
2012 auf dem Linuxtag in Berlin statt.
Weitere Informationen zu den Teilnahmebedingungen
finden sich unter [http://​www.​ „Eine Cloud-basierte Software-Plattform für den
Preisträger 2011: Andreas Wolke mit seiner Diplomarbeit
​absolventenpreis.​de].
Betrieb horizontal skalierbarer Web-Anwendungen“.
Neue RAIDs von Starline
Der Hersteller Starline hat zwei neue
Diskarrays einer neuen Generation
seiner easyRAID-Systeme vorgestellt.
Unter der Bezeichnung ERP12
beziehungsweise ERP16 sind zwei
neue Modelle erhältlich, die bis zu
3 TByte großen Platten in 6 GBit/​
s-SAS/​SAT-Technologie aufnehmen
können. Die Arrays unterstützen Festplattenverschlüsselung
sowie RAID-6
und verfügen über Snapshot- und Rollback-Funktionen.
Eine spezielle Host-
Software erlaubt zudem dynamisches
I/​O-Load-Balancing.
Beide Arrays können mit 3,5-, 2,5-Zoll-
Festplatten und SSDs auch gemischt
bestückt werden. Die Platten können
im laufenden Betrieb getauscht werden,
die Netzteile sind redundant,
der Controller nur einfach vorhanden.
Die Preise liegen zwischen 3300
und 4500 Euro (ohne Platten).
1. Lernen Sie!
Ja, „training-on-the-job“, oft praktiziert, aber nicht
überzeugend. Denn die Kollegen haben nie Zeit
für echte Erklärungen, außerdem werden „Neue“
sofort von dem vereinnahmt, was im Unternehmen
schon seit Ewigkeiten tradiert wird. Warum gibt's
seit 2000 Jahren Schulen und Universitäten?
„LERNEN“ ist eine vollwertige Tätigkeit, auf die
man sich konzentrieren muß, die man nicht 'mal
eben so nebenbei tun kann, und die immer auch
eine Prise „Erneuerung“ beinhalten sollte!
2. Ineffiziente Arbeit nicht akzeptieren!
Je spezialisierter Sie arbeiten, desto weniger
echte, fachliche Kollegen haben Sie in Ihrem eigenen
Unternehmen. Wir stellen deshalb Gruppen
zusammen, in denen Sie neben hilfsbereiten
Kollegen mit ähnlichen Kenntnissen an IHREM
Projekt arbeiten. Und ständig ist ein fachlicher Berater
anwesend.
„Guided Coworking“ nennen wir das, und es
könnte DIE Lösung für so manches Projekt sein,
das in Ihrer Firma „hakt“.
3. Hintergrund
Wer den riesigen OpenSource-Baukasten schnell
beherrschen muß, geht zu einer unserer über 100
Schulungen. Wer das bereits kann, aber schneller
mit seinen Projekten vorankommen will, der
kommt mit seiner Arbeit zum Guided Coworking.
Wir sind eine der erfolgreichsten Schulungseinrichtungen
im gesamten Bereich „OpenSource“
- sowohl für Admins, als auch für Entwickler.
Siehe www.linuxhotel.de

1&1 WEBHOSTING
INKLUSIVE: CLICK
Bei 1&1 treffen über 20 Jahre Webhosting-Erfahrung auf modernste Technik in deutschen Hochleistungs-
Rechenzentren. Mehr als 1.000 IT-Profis entwickeln unsere hochwertigen Lösungen permanent weiter.
Die 1&1 WebHosting-Pakete bieten alles, was Sie für Ihren professionellen Internetauftritt brauchen:
Ausgabe 08/11
✓ 65 kostenlos installierbare
Click & Build Applikationen
inklusive Software- und Sicherheits-Updates für Ihre Apps
✓ Marken-Design-Software
z. B. Adobe Dreamweaver ® , NetObjects Fusion ® 1&1 Edition
✓ Doppelte Sicherheit
paralleles Hosting Ihrer Website in zwei Hightech-
Rechenzentren an verschiedenen Orten
✓ 24h-Profi-Hotline
und kostenloser E-Mail-Support.
&
1&1 DUAL HOSTING
*
* 1&1 Dual Perfect, 6 Monate 0,– €/Monat, danach 9,99 €/Monat. 1&1 Perfect Shop 6 Monate 0,– €/Monat, danach 19,99 €/Monat. 1&1 Dynamic Cloud Server - Basis Konfiguration: 3 Monate 0,– €/Monat,
danach 39,99 €/Monat. Bei erweiterter Konfi guration ändert sich der Preis/Monat entsprechend der Systemerweiterung. 1&1 Click & Build Apps für Dynamic Cloud-Server nicht verfügbar.

& BUILD APPS!
WEBSITE: 1&1 DUAL
PERFECT
■ 6 DOMAINS INKLUSIVE
■ 5 GB Webspace
■ UNLIMITED Traffic
■ 20 FTP-Accounts
■ 10 MySQL-Datenbanken (je 1 GB)
■ UNLIMITED Click & Build Apps
(Auswahl aus 65 Applikationen)
6 MONATE FÜR
1&1 PERFECT
SHOP
■ 1.000 ARTIKEL
■ 100 Warengruppen
■ Marketing-Tools
■ PayPal
■ eBay-Tool
■ UNLIMITED Click & Build Apps
(Auswahl aus 65 Applikationen)
6 MONATE FÜR
1&1 DYNAMIC CLOUD
SERVER
■ NEU: Bis zu 6 CPU, bis zu 24 GB
Arbeitsspeicher und bis zu
800 GB Festplattenspeicher
jederzeit nach Bedarf einstellbar.
■ NEU: Management und Monitoring
Ihrer Server Dienste im Browser
oder per Mobile-App
3 MONATE AB
danach
9,99 €/Monat*
0,–€/Monat*
€/Monat*
0,–danach
19,99 €/Monat*
€/Monat*
0,–danach
39,99 €/Monat*
.de
nur 0,29 € /Monat*
.info
nur 0,29 € /Monat*
.com, .net,
.org, .eu, .at
nur 0,99 € /Monat*
0 26 02 / 96 91 0800 / 100 668
www.1und1.info
.de und .info Domain 1 Jahr 0,29 €/Monat, .com, .net, .org, .eu, .at Domain 1 Jahr 0,99 €/Monat, danach .de 0,49 €/Monat, .com, .net, .org, .eu 1,49 €/Monat, .at 1,99 €/Monat, .info 1,99 €/Monat.
Einmalige Einrichtungsgebühr 9,60 € (1&1 Dynamic Cloud Server 39,– €, Domains ohne Einrichtungsgebühr), 12 Monate Mindestvertragslaufzeit. Preise inkl. MwSt. Software wird zum Download bereitgestellt.

Login
Bücher
Bücher über PostgreSQL und Virtualbox
Vorgelesen
Zwei zweite Auflagen aktualisieren bewährte Ratgeber. Der erste beschäftigt
sich mit der neuesten Version der PostgreSQL-Datenbank, der zweite
bringt dem Leser die Virtualisierungsplattform Virtualbox näher.
Jens-Christoph Brendel, Oliver Frommel
Umfassende Dokumentation und zugleich
tägliche Referenz, das will die
neue, zweite Auflage von „PostgreSQL-
Administration“ sein, die der bekannte
PostgreSQL-Entwickler Peter Eisentraut
und sein Kollege, der Datenbank-Consultant
Bernd Helmle jetzt bei O’Reilly
herausgegeben haben. Und man kann
vorwegnehmen: Das Ziel wird erreicht.
Kleine Abstriche muss man sicherlich
in Punkto Vollständigkeit machen – gut
370 Buchseiten reichen nicht, um ein
so komplexes Produkt lückenlos abzuhandeln.
So widmen sich die Autoren
etwa beim Thema Tuning vorrangig der
SQL-Optimierung, was auch sicher das
effektivste Beschleunigungsverfahren ist
– wenn man es denn anwenden kann.
Wo aber eine Anwendung die Abfragen
erzeugt, die der Anwender nicht beeinflussen
kann, da blieben auf Datenbankseite
immer noch zahlreiche Stellschrauben
in Gestalt von beeinflussbaren und
geschwindigkeitsrelevanten Datenbankparametern,
auf die das Buch jedoch nur
am Rande eingeht.
Nichtsdestotrotz behandelt es bei jedem
Thema die wichtigsten Aspekte und folgt
in seinem Aufbau grob einer Art Datenbank-Lifecycle.
Der beginnt bei Installation
und Konfiguration, setzt sich bei
Wartung und Datensicherung fort, führt
weiter zum Monitoring, der Fehlerbehebung,
der Sicherheit und schließlich zum
schon erwähnten Performance-Tuning.
Kapitel 9 – Replikation und Hochverfügbarkeit
– profitiert am meisten von der
Neuauflage, behandelt es doch jetzt die
seit dem neuesten PostgreSQL-Release
9.0 eingebauten Replikationsmöglichkeiten
(Hot Standby). Daneben werden ausführlich
die Produkte Slony-I und Pgpool-
II vorgestellt, dazu der Connection Pool
PgBouncer und der Datenbank-Proxy PL/​
Proxy. Das letzte Kapitel gibt Hinweise
zur Hardwareauswahl für einen performanten
und sicheren Datenbankserver.
In allen Kapiteln gelingt es den Autoren,
die teils komplizierten Sachverhalte leicht
verständlich, gut lesbar und anhand zahlreicher
Beispiele darzustellen. Alles in
allem ein für PostgreSQL-Anwender sehr
empfehlenswertes Buch.
Virtualbox
Regelmäßig aktualisiert die Firma Oracle
seit der Übernahme von Sun ihr Virtualisierungsprodukt
Virtualbox, das als freie
Software wie auch als kommerzielles
Produkt mit einigen Zusatz-Features zur
Verfügung steht. Um mit der Entwicklung
Schritt zu halten, hat der Galileo-Verlag
sein Buch zu Virtualbox nun auf Version
4 der Software aktualisiert.
Schwerpunkt des auf den Praxiseinsatz
ausgerichteten Werkes ist die Desktopvirtualisierung
mit Virtualbox. Vom Betrieb
auf Servern rät der Autor Dirk Becker
eher ab, da das Programm seiner Meinung
nach die entsprechenden Eigenschaften
nicht besitze – auch wenn er in
jüngerer Zeit hinzugekommene Server-
Features am Rande erwähnt.
Auf den ersten 60 Seiten beschreibt der
Autor kursorisch die Geschichte und den
Aufbau von Computern und geht dann
auf die Entwicklung von Emulation und
Virtualisierung bis zum aktuellen Stand
der Technik ein. Ausführlich beschreibt
er die Installation von Virtualbox auf
unterschiedlichen Linux-Distributionen
sowie auf Windows.
Die Installation und Konfiguration von
Gastsystemen nimmt den größten Teil
des Buches ein, wobei Becker die meisten
Schritte sowohl in der Virtualbox-GUI als
auch auf der Kommandozeile unter Windows
und Linux demonstriert. Themen
wie Grafik-Beschleunigung und Audio-
Unterstützung führt er am Beispiel eines
Windows-7-Gasts vor. Fortgeschrittene
Features wie Sicherungspunkte, Management
von Image-Dateien sowie Migration
und Support sind wiederum für Anwender
aller Betriebssysteme von Interesse,
wenn auch das letzte Thema auf nur gut
zehn Seiten Platz finden muss.
Unterm Strich ist das Buch eine gute
Einführung in die Desktop-Virtualisierung
mit Virtualbox, insbesondere für
Endanwender. Erfahrene Administratoren
werden dem Buch jedoch wenig überraschende
Informationen entnehmen, insbesondere,
wenn sie Virtualbox auf dem
Server einsetzen wollen. (ofr) n
PostgreSQL-Administration
PostgreSQL-Administration
Peter Eisentraut, Bernd Helmle
O’Reilly 2011
2. Auflage
372 Seiten
34,90 Euro
ISBN: 978-3-89721-661-7
Virtualbox
Virtualbox
Dirk Becker
Galileo Computing 2011
2., aktualisierte Auflage
327 Seiten
29,90 Euro
ISBN 978-3-8362-1778-1
16 Ausgabe 06-2011 Admin www.admin-magazin.de

„Kennen Sie
unser Thomas
Krenn Wiki?“
Schauen Sie doch mal in unserem Thomas Krenn Wiki vorbei.
Hier finden Sie die neuesten Beiträge zu DDR-SDRAM und vieles mehr!
Werner Fischer,
Technical Specialist
MEHR ALS NUR EIN WIKI
• IT Know-how der Server-Experten
• Konkrete Problemlösungen
• Über 700 Artikel und Hintergrundinfos
zu Servertechnologien
• Installations- und Konfigurationsanleitungen
Beiträge unserer Experten unter:
www.thomas-krenn.com/tk_wiki
Thomas Krenn steht für Server made in Germany. Wir
assemblieren und liefern europaweit innerhalb von 24
Stunden. Unter www.thomas-krenn.com können Sie
Ihre Server individuell konfi gurieren.
Unsere Experten sind rund um die Uhr für Sie unter
+49 (0) 8551 9150-0 erreichbar
(CH: +49 (0) 848207970, AT +43 (0) 7282 20797-3600)
Made in Germany!
Verkauf erfolgt ausschließlich an Gewerbetreibende, Firmen, Freiberufler (Ärzte, Rechtsanwälte etc.), staatliche Institutionen und Behörden. Druckfehler, Irrtümer und Änderungen in Preis und Ausstattung vorbehalten.
Unsere Versandkosten richten sich nach Gewicht und Versandart. Genaue Preisangaben finden Sie unter: www.thomas-krenn.com/versandkosten. Thomas-Krenn.AG, Speltenbach-Steinäcker 1, D-94078 Freyung

Login
Admin-Story
Aus dem Tagebuch eines IT-Nomaden
Aufzucht
Große Systemlandschaften mithilfe von Cobbler und Spacewalk verwalten
– für viele Admins heute eine Selbstverständlichkeit. Was aber, wenn eine
solche Landschaft gerade erst im Aufbau ist? Dass hier nicht immer eine
Menge Handarbeit notwendig ist, zeigt mein Tagebuch-Bericht in diesem
Monat. Thorsten Scherf
© Pellocks, Fotolia
Das erste Meeting mit dem Kunden ist
gerade vorbei, und er sieht zufrieden
aus, aber doch nicht völlig überzeugt.
Vielleicht denkt er: „Kann der Kerl mit
dem roten Hut das wirklich halten, was
er da eben so vollmundig versprochen
hat? Schließlich geht es nicht nur um
eine Handvoll, sondern um mehrere
Hundert Systeme. Wie will der denn in
der kurzen Zeit alle Rechner installieren,
konfigurieren und mit unserer Software
versorgen?“
Listing 1: Systemeinstellungen
01 # cobbler system add ‐‐name=foo
‐‐profile=ksprofile‐devel‐rhel6 \
02 ‐‐hostname=foo.bar.de ‐‐macaddress=00:40:26:CA:10:DD
\
03 ‐‐kopts="stage=test app=www" ‐‐ksmeta="stage=test
app=www"
04 # cobbler system edit ‐‐name=foo ‐‐interface=eth0
‐‐mac=00:40:26:CA:10:DD \
05 ‐‐ip=192.168.0.1 ‐‐subnet=255.255.255.0
‐‐gateway=192.168.0.254 ‐‐static=1 \
06 ‐‐netboot‐enabled=Y
Zugegeben, die Anzahl der Maschinen
ist für den zur Verfügung stehenden
Zeitraum schon enorm, aber mithilfe des
Cobbler-XMLRPC-API sollte das Anlegen
der vielen System-Profile in der Cobbler-Datenbank
kein großes Problem
darstellen. Dank intensiver Gespräche
mit dem Kunden weiß
ich nun auch, welche Art von
Systemen er hat und wie diese
zu konfigurieren sind. Das
lässt sich eigentlich alles recht
leicht über eine passende Struktur
und ein ausgefeiltes Kickstart-
Profil im Spacewalk-Server lösen.
Zu dem Thema gibt es einen Artikel
im ADMIN-Magazin [1]. Also stellen die
vielen Cobbler-Systemeinträge wirklich
die größte Hürde dar. Zur Erinnerung:
Mithilfe dieser Systemeinträge ist Cobbler
in der Lage, für jedes System eine individuelle
PXE-Konfigurationsdatei zu generieren.
Dank sogenannter Snippets, die
später im Kickstart-Profil zum Einsatz
kommen, ist die Individualisierung eines
Systems bereits zu einem sehr frühen
Zeitpunkt möglich. Dies gilt beispielsweise
für das zu installierende Betriebssystem,
die Netzwerkkonfiguration und,
dank beliebiger Variablen, die sich als
Kernel-Argumente in Cobbler definieren
lassen, für eigentlich jede nur denkbare
Konfigurationseinstellung.
Mit ein bisschen Script-Foo kommen diese
Variablen dann während der Installation
zum Einsatz und passen das System den
eigenen Wünschen an. Ist ein solcher
Eintrag für einen Rechner erst einmal
erzeugt, ist der eigentlich nur noch zu
starten, um eine vollkommen automatisierte
Installation mittels PXE anzustoßen.
Die Aufgabe besteht jetzt darin,
diese Einträge erst einmal in die Cobbler-
Datenbank aufzunehmen. Ein klassischer
Aufruf hierfür sieht beispielsweise wie in
Listing 1 aus.
Alles kein Problem, wenn es sich nur um
ein paar Maschinen handelt, die notwendigen
Befehle sind schnell ausgeführt.
Was aber, wenn der Kunde gerne 1000
Maschinen installiert haben möchte?
1000 Einträge von Hand eingeben? Keine
angenehme Aufgabe. Ein Shell-Skript?
Klingt schon ganz gut, aber es geht noch
besser.
Cobbler bietet neben dem manuellen
Anlegen dieser Systemeinträge die
Möglichkeit, diese Aufgabe mittels einer
Python- oder XMLRPC-API zu automatisieren.
Welche der beiden Schnittstellen
man wählt, ist Geschmackssache.
Wegen einiger negativer Erlebnisse mit
der Python-API entscheide ich mich für
XMLRPC. XMLRPC ((Extensible Markup
Language Remote Procedure Call) ist vereinfacht
ausgedrückt ein standardisierter
Weg für Computerprogramme, sich über
ein Netzwerk auszutauschen und Daten
zu versenden und zu empfangen. Welche
Daten zu übertragen sind, das legen
verschiedene Methodenaufrufe fest. Über
das HTTP-Protokoll gelangen die Daten
dann – in XML-Form – an den anfragenden
Client. Praktisch jede moderne
Sprache bietet heute ein XML-Interface
an. Hier kommt der Einfachheit halber
Python zum Einsatz.
Einen ersten Einstieg zeigt Listing 2.
Neben dem obligatorischen Importieren
der »xmlrpclib«, erzeugt der Aufruf in
Zeile 2 ein Objekt zum Verbinden mit
dem Cobbler-Server. Zeile 3 erzeugt ein
18 Ausgabe 06-2011 Admin www.admin-magazin.de

Admin-Story
Login
passendes Token zum Login. Mit diesem
Token erhalten alle Spacewalk-Benutzer
automatisch Zugang zum Cobbler-Server.
Hierfür ist jedoch noch eine Anpassung
in »/etc/cobbler/settings« notwendig.
Dort ist die Anweisung »redhat_management_permissive«
auf 1 zu setzen. Zeile
4 gibt alle vorhandenen System-Einträge
aus.
Listing 3 zeigt ein etwas umfangreicheres
Beispiel. Hier gehe ich davon aus,
dass die Systeme mit allen notwendigen
Informationen wie beispielsweise IP-,
MAC-Adresse, Gateway und so weiter in
einer CSV-Datei aufgeführt sind. Diese
CSV-Datei schnappt sich das Python-
Script, steckt die einzelnen System-
Eigenschaften in ein Dictionary, ordnet
den einzelnen Dictionary-Keys den passenden
Wert zu und übergibt schließlich
alles an Cobbler. Das Ergebnis ist das
gleiche wie bei dem manuellen Aufruf
Listing 3: Systeminformationen
von Cobbler weiter oben. Mithilfe der
XMLRPC-API ist es ein Leichtes, die
ganze Systemlandschaft im Cobbler abzubilden.
Die notwendigen Systemkonfigurationsdateien
für den PXE-Server
erzeugt Cobbler dabei automatisch.
Nach ein paar Tests und manuellen Anpassungen
an den Kickstart-Dateien,
auf die Cobbler in den Systemeinträgen
verweist, sind alle Systeme schließlich
im Handumdrehen installiert. Und das
Beste daran ist: Cobbler ist freie Software,
die unter der GPL-Lizenz allen
zur Verfügung steht. Nach dem ganzen
Gerede über Cobbler [2] habe ich
nun doch glatt Appetit b ekommen.
Da ich mich dazu auch noch gerade in
den USA aufhalte, versuche ich nun also
erstmal ein Restaurant zu finden, in dem
es diese leckeren Teigkrusten mit Früchten
gibt, die wie die nützliche Software
heißen. Bis bald. (ofr)
n
Infos
[1] Thorsten Scherf, Linux-Systeme mit Spacewalk
verwalten, ADMIN 04/​2010, S. 74
[2] Cobbler-Rezept:
[http:// www. usa‐kulinarisch. de/ rezept/​
cobbler‐grundrezept/]
Der Autor
Thorsten Scherf arbeitet als Senior Consultant
für Red Hat EMEA. Er ist oft als Vortragender
auf Konferenzen anzutreffen. Wenn ihm neben
der Arbeit und Familie noch Zeit bleibt, nimmt
er gerne an Marathonläufen teil.
Listing 2: Basics
01 from xmlrpclib import *
02 conn = Server("http://spacewalk.tuxgeek.de/cobbler_
api")
03 token = conn.login(user, password)
04 print server.get_systems()
01 import os
02 import sys
03 from xmlrpclib import *
04
05 conn = Server("http://spacewalk.tuxgeek.de/cobbler_api")
06 token = conn.login(user, password)
07
08 cblr_systems = '/root/cobbler.csv'
09
10 if os.access(cblr_systems, os.F_OK):
11 print "Reading system configuration file %s" % cblr_systems
12 print
13 else:
14 print "The system configuration file %s does not exist,
aborting." % cblr_systems
15 print
16 sys.exit(1)
17
18 column_header = [ "name","os","eth0‐mac","stage","app","gateway",
"eth0‐ip","eth0‐mask","eth1‐mac","eth1‐ip","eth1‐mask" ]
19 system_dict = {}
20
21 f = open(cblr_systems, "r")
22 for line in f:
23 if line.startswith("#"):
24 continue
25 system_prop = line.split(",")
26 print "‐‐> Checking if system %s already exists:" % system_
prop[0]
27 for i,header in enumerate(column_header):
28 system_dict[header] = system_prop[i]
29
30 system_name=system_dict["name"]
31 dnsname = system_dict["name"] + ".tuxgeek.de"
32 ksprofile = "ksprofile‐devel‐" + system_dict["os"]
33
34 try:
35 sys_id = conn.get_system_handle(system_name, token)
36 except Fault, reason:
37 if reason.faultCode == 1:
38 print "+ System doesn't exist, will create it now"
39 pass
40 else:
41 print "* System already exists ‐ skipping "
42 print
43 continue
44
45 sys_id = conn.new_system(token)
46 conn.modify_system(sys_id, 'name', system_dict["name"], token)
47 conn.modify_system(sys_id, 'hostname', dnsname, token)
48 conn.modify_system(sys_id, 'gateway', system_dict["gateway"],
token)
49 conn.modify_system(sys_id, 'profile', ksprofile, token)
50 conn.modify_system(sys_id, 'netboot_enabled', True, token)
51 conn.modify_system(sys_id, 'kopts', { "stage" : system_
dict["stage"], "app" : system_dict["app"] }, token)
52 conn.modify_system(sys_id, 'kopts_post', { "stage" : system_
dict["stage"], "app" : system_dict["app"] }, token)
53 conn.modify_system(sys_id, 'modify_interface', {
54 "macaddress‐eth0" : system_dict["eth0‐mac"],
55 "ipaddress‐eth0" : system_dict["eth0‐ip"],
56 "static‐eth0" : True,
57 "staticroutes‐eth0" : system_dict["eth0‐routes"] }, token)
58 conn.modify_system(sys_id, 'modify_interface', {
59 "macaddress‐eth1" : system_dict["eth1‐mac"],
60 "ipaddress‐eth1" : system_dict["eth1‐ip"],
61 "static‐eth1" : True,
62 "staticroutes‐eth1" : system_dict["eth1‐routes"] }, token)
63 conn.save_system(sys_id, token)
64 print "+ System created"
65 print
66 f.close()
www.admin-magazin.de
Admin
Ausgabe 06-2011
19

Admin-Story
Login
passendes Token zum Login. Mit diesem
Token erhalten alle Spacewalk-Benutzer
automatisch Zugang zum Cobbler-Server.
Hierfür ist jedoch noch eine Anpassung
in »/etc/cobbler/settings« notwendig.
Dort ist die Anweisung »redhat_management_permissive«
auf 1 zu setzen. Zeile
4 gibt alle vorhandenen System-Einträge
aus.
Listing 3 zeigt ein etwas umfangreicheres
Beispiel. Hier gehe ich davon aus,
dass die Systeme mit allen notwendigen
Informationen wie beispielsweise IP-,
MAC-Adresse, Gateway und so weiter in
einer CSV-Datei aufgeführt sind. Diese
CSV-Datei schnappt sich das Python-
Script, steckt die einzelnen System-
Eigenschaften in ein Dictionary, ordnet
den einzelnen Dictionary-Keys den passenden
Wert zu und übergibt schließlich
alles an Cobbler. Das Ergebnis ist das
gleiche wie bei dem manuellen Aufruf
Listing 3: Systeminformationen
von Cobbler weiter oben. Mithilfe der
XMLRPC-API ist es ein Leichtes, die
ganze Systemlandschaft im Cobbler abzubilden.
Die notwendigen Systemkonfigurationsdateien
für den PXE-Server
erzeugt Cobbler dabei automatisch.
Nach ein paar Tests und manuellen Anpassungen
an den Kickstart-Dateien,
auf die Cobbler in den Systemeinträgen
verweist, sind alle Systeme schließlich
im Handumdrehen installiert. Und das
Beste daran ist: Cobbler ist freie Software,
die unter der GPL-Lizenz allen
zur Verfügung steht. Nach dem ganzen
Gerede über Cobbler [2] habe ich
nun doch glatt Appetit b ekommen.
Da ich mich dazu auch noch gerade in
den USA aufhalte, versuche ich nun also
erstmal ein Restaurant zu finden, in dem
es diese leckeren Teigkrusten mit Früchten
gibt, die wie die nützliche Software
heißen. Bis bald. (ofr)
n
Infos
[1] Thorsten Scherf, Linux-Systeme mit Spacewalk
verwalten, ADMIN 04/​2010, S. 74
[2] Cobbler-Rezept:
[http:// www. usa‐kulinarisch. de/ rezept/​
cobbler‐grundrezept/]
Der Autor
Thorsten Scherf arbeitet als Senior Consultant
für Red Hat EMEA. Er ist oft als Vortragender
auf Konferenzen anzutreffen. Wenn ihm neben
der Arbeit und Familie noch Zeit bleibt, nimmt
er gerne an Marathonläufen teil.
Listing 2: Basics
01 from xmlrpclib import *
02 conn = Server("http://spacewalk.tuxgeek.de/cobbler_
api")
03 token = conn.login(user, password)
04 print server.get_systems()
01 import os
02 import sys
03 from xmlrpclib import *
04
05 conn = Server("http://spacewalk.tuxgeek.de/cobbler_api")
06 token = conn.login(user, password)
07
08 cblr_systems = '/root/cobbler.csv'
09
10 if os.access(cblr_systems, os.F_OK):
11 print "Reading system configuration file %s" % cblr_systems
12 print
13 else:
14 print "The system configuration file %s does not exist,
aborting." % cblr_systems
15 print
16 sys.exit(1)
17
18 column_header = [ "name","os","eth0‐mac","stage","app","gateway",
"eth0‐ip","eth0‐mask","eth1‐mac","eth1‐ip","eth1‐mask" ]
19 system_dict = {}
20
21 f = open(cblr_systems, "r")
22 for line in f:
23 if line.startswith("#"):
24 continue
25 system_prop = line.split(",")
26 print "‐‐> Checking if system %s already exists:" % system_
prop[0]
27 for i,header in enumerate(column_header):
28 system_dict[header] = system_prop[i]
29
30 system_name=system_dict["name"]
31 dnsname = system_dict["name"] + ".tuxgeek.de"
32 ksprofile = "ksprofile‐devel‐" + system_dict["os"]
33
34 try:
35 sys_id = conn.get_system_handle(system_name, token)
36 except Fault, reason:
37 if reason.faultCode == 1:
38 print "+ System doesn't exist, will create it now"
39 pass
40 else:
41 print "* System already exists ‐ skipping "
42 print
43 continue
44
45 sys_id = conn.new_system(token)
46 conn.modify_system(sys_id, 'name', system_dict["name"], token)
47 conn.modify_system(sys_id, 'hostname', dnsname, token)
48 conn.modify_system(sys_id, 'gateway', system_dict["gateway"],
token)
49 conn.modify_system(sys_id, 'profile', ksprofile, token)
50 conn.modify_system(sys_id, 'netboot_enabled', True, token)
51 conn.modify_system(sys_id, 'kopts', { "stage" : system_
dict["stage"], "app" : system_dict["app"] }, token)
52 conn.modify_system(sys_id, 'kopts_post', { "stage" : system_
dict["stage"], "app" : system_dict["app"] }, token)
53 conn.modify_system(sys_id, 'modify_interface', {
54 "macaddress‐eth0" : system_dict["eth0‐mac"],
55 "ipaddress‐eth0" : system_dict["eth0‐ip"],
56 "static‐eth0" : True,
57 "staticroutes‐eth0" : system_dict["eth0‐routes"] }, token)
58 conn.modify_system(sys_id, 'modify_interface', {
59 "macaddress‐eth1" : system_dict["eth1‐mac"],
60 "ipaddress‐eth1" : system_dict["eth1‐ip"],
61 "static‐eth1" : True,
62 "staticroutes‐eth1" : system_dict["eth1‐routes"] }, token)
63 conn.save_system(sys_id, token)
64 print "+ System created"
65 print
66 f.close()
www.admin-magazin.de
Admin
Ausgabe 06-2011
19

Admin-Story
Login
passendes Token zum Login. Mit diesem
Token erhalten alle Spacewalk-Benutzer
automatisch Zugang zum Cobbler-Server.
Hierfür ist jedoch noch eine Anpassung
in »/etc/cobbler/settings« notwendig.
Dort ist die Anweisung »redhat_management_permissive«
auf 1 zu setzen. Zeile
4 gibt alle vorhandenen System-Einträge
aus.
Listing 3 zeigt ein etwas umfangreicheres
Beispiel. Hier gehe ich davon aus,
dass die Systeme mit allen notwendigen
Informationen wie beispielsweise IP-,
MAC-Adresse, Gateway und so weiter in
einer CSV-Datei aufgeführt sind. Diese
CSV-Datei schnappt sich das Python-
Script, steckt die einzelnen System-
Eigenschaften in ein Dictionary, ordnet
den einzelnen Dictionary-Keys den passenden
Wert zu und übergibt schließlich
alles an Cobbler. Das Ergebnis ist das
gleiche wie bei dem manuellen Aufruf
Listing 3: Systeminformationen
von Cobbler weiter oben. Mithilfe der
XMLRPC-API ist es ein Leichtes, die
ganze Systemlandschaft im Cobbler abzubilden.
Die notwendigen Systemkonfigurationsdateien
für den PXE-Server
erzeugt Cobbler dabei automatisch.
Nach ein paar Tests und manuellen Anpassungen
an den Kickstart-Dateien,
auf die Cobbler in den Systemeinträgen
verweist, sind alle Systeme schließlich
im Handumdrehen installiert. Und das
Beste daran ist: Cobbler ist freie Software,
die unter der GPL-Lizenz allen
zur Verfügung steht. Nach dem ganzen
Gerede über Cobbler [2] habe ich
nun doch glatt Appetit b ekommen.
Da ich mich dazu auch noch gerade in
den USA aufhalte, versuche ich nun also
erstmal ein Restaurant zu finden, in dem
es diese leckeren Teigkrusten mit Früchten
gibt, die wie die nützliche Software
heißen. Bis bald. (ofr)
n
Infos
[1] Thorsten Scherf, Linux-Systeme mit Spacewalk
verwalten, ADMIN 04/​2010, S. 74
[2] Cobbler-Rezept:
[http:// www. usa‐kulinarisch. de/ rezept/​
cobbler‐grundrezept/]
Der Autor
Thorsten Scherf arbeitet als Senior Consultant
für Red Hat EMEA. Er ist oft als Vortragender
auf Konferenzen anzutreffen. Wenn ihm neben
der Arbeit und Familie noch Zeit bleibt, nimmt
er gerne an Marathonläufen teil.
Listing 2: Basics
01 from xmlrpclib import *
02 conn = Server("http://spacewalk.tuxgeek.de/cobbler_
api")
03 token = conn.login(user, password)
04 print server.get_systems()
01 import os
02 import sys
03 from xmlrpclib import *
04
05 conn = Server("http://spacewalk.tuxgeek.de/cobbler_api")
06 token = conn.login(user, password)
07
08 cblr_systems = '/root/cobbler.csv'
09
10 if os.access(cblr_systems, os.F_OK):
11 print "Reading system configuration file %s" % cblr_systems
12 print
13 else:
14 print "The system configuration file %s does not exist,
aborting." % cblr_systems
15 print
16 sys.exit(1)
17
18 column_header = [ "name","os","eth0‐mac","stage","app","gateway",
"eth0‐ip","eth0‐mask","eth1‐mac","eth1‐ip","eth1‐mask" ]
19 system_dict = {}
20
21 f = open(cblr_systems, "r")
22 for line in f:
23 if line.startswith("#"):
24 continue
25 system_prop = line.split(",")
26 print "‐‐> Checking if system %s already exists:" % system_
prop[0]
27 for i,header in enumerate(column_header):
28 system_dict[header] = system_prop[i]
29
30 system_name=system_dict["name"]
31 dnsname = system_dict["name"] + ".tuxgeek.de"
32 ksprofile = "ksprofile‐devel‐" + system_dict["os"]
33
34 try:
35 sys_id = conn.get_system_handle(system_name, token)
36 except Fault, reason:
37 if reason.faultCode == 1:
38 print "+ System doesn't exist, will create it now"
39 pass
40 else:
41 print "* System already exists ‐ skipping "
42 print
43 continue
44
45 sys_id = conn.new_system(token)
46 conn.modify_system(sys_id, 'name', system_dict["name"], token)
47 conn.modify_system(sys_id, 'hostname', dnsname, token)
48 conn.modify_system(sys_id, 'gateway', system_dict["gateway"],
token)
49 conn.modify_system(sys_id, 'profile', ksprofile, token)
50 conn.modify_system(sys_id, 'netboot_enabled', True, token)
51 conn.modify_system(sys_id, 'kopts', { "stage" : system_
dict["stage"], "app" : system_dict["app"] }, token)
52 conn.modify_system(sys_id, 'kopts_post', { "stage" : system_
dict["stage"], "app" : system_dict["app"] }, token)
53 conn.modify_system(sys_id, 'modify_interface', {
54 "macaddress‐eth0" : system_dict["eth0‐mac"],
55 "ipaddress‐eth0" : system_dict["eth0‐ip"],
56 "static‐eth0" : True,
57 "staticroutes‐eth0" : system_dict["eth0‐routes"] }, token)
58 conn.modify_system(sys_id, 'modify_interface', {
59 "macaddress‐eth1" : system_dict["eth1‐mac"],
60 "ipaddress‐eth1" : system_dict["eth1‐ip"],
61 "static‐eth1" : True,
62 "staticroutes‐eth1" : system_dict["eth1‐routes"] }, token)
63 conn.save_system(sys_id, token)
64 print "+ System created"
65 print
66 f.close()
www.admin-magazin.de
Admin
Ausgabe 06-2011
19

Login
Leserbriefe
Leser-Feedback
Leserbriefe
Haben Sie Anregungen, Kritik oder Kommentare? Dann schreiben Sie
an [leserbriefe@admin‐magazin.​de]. Die Redaktion behält es sich vor, die
zuschriften und Leserbriefe zu kürzen. Sie veröffentlicht alle Beiträge
mit Namen, sofern der Autor nicht ausdrücklich Anonymität wünscht.
alexwhite, 123RF
Office 365 vs. Google Apps
05/​2011, S. 126: Eine Office Suite als
Webapp ist nicht nur für die Zusammenarbeit
eine feine Sache. Man kann
auf diesem Wege auch sehr elegant die
Querelen um inkompatible Dateiformate
umgehen. Mit den Google Apps
klappt das ganz hervorragend und zwar
zwischen allen Plattformen. Es kann einem
egal sein, welches System die anderen
verwenden. In diesem Punkt hat
der Artikel leider keine Klarheit gebracht.
Selbst wenn Office 365 zum Beispiel
auch im Firefox-Browser läuft, heißt es
noch lange nicht, dass es auch in Firefox
unter Linux läuft (zum Beispiel werben
Maxdome Player oder Silverlight damit,
Firefox zu unterstützen, tun dies aber
nicht unter Linux).
Es wurde zwar erwähnt, dass Desktop
Sharing und Telefonie nur unter Windows
funktionieren, aber generell kann
man aus dem Vergleich nicht ableiten,
welche Office Suite besser geeignet ist,
um die Zusammenarbeit zwischen Anwendern
zu erleichtern, die Windows-,
Linux- und Mac-OS-Clients gemischt verwenden.
Martin Runge (per E-Mail)
Sie haben recht, wir werden versuchen,
in Zukunft bei ähnlichen Fällen darauf
mehr zu achten. (Oliver Frommel)
PAC
03/​2011, S. 48: Im Artikel beschreiben
Sie die Möglichkeit, dass PAC lokal die
Admin-Passwörter der verwalteten Server
speichern kann, um diese dann bei Bedarf
Für Kommentare und Anregungen können Sie mit der Redaktion auch über die Facebook-Seite in Kontakt
treten, die Sie unter [http://​www.​facebook.​com/​adminmagazin] finden.
an Sudo weiterzugeben. Offensichtlich
erfolgt diese lokale Speicherung ohne besonderen
Schutz, denn ein Zugriff muss
nicht vorher über ein Master-Passwort
oder Ähnliches freigeschaltet werden. Sie
liegen also im Zweifelsfall auch jedem
Angreifer offen.
Die deutlich sicherere Lösung wäre,
auf den beteiligten Servern in »/ etc/
sudoers« eine Zeile wie »%admin
ALL=NOPASSWD: /usr/bin/apt‐get
update« einzutragen. Sudo fragt dann
für genau dieses eine Kommando gar
nicht erst nach einem Passwort, und das
Sicherheitsrisiko der lokalen Speicherung
desselben entfällt vollständig.
Bernd Strößenreuther (per E-Mail)
Netzwerk-Bonding
05/​2011, S. 30: Zum Ende des Artikels
„Netzwerk-Bonding mit Linux“ wird kurz
Bezug auf OpenBSD und Carp genommen.
Hier hätte man vielleicht noch erwähnen
können, dass mit »pfsync« neben
„active/​stand-by“ auch „active-active
stateful“ möglich ist. Was eine Downtime
und die Wahrscheinlichkeit eines
Paketverlusts doch ordentlich minimiert.
Siehe dazu die folgenden Links:
n [http://​www.​undeadly.​
​org/​cgi?​action=article&​
​sid=20090619100514]
n [http://​www.​kernel‐panic.​it/​
​openbsd/​carp/​carp4.​html#​carp‐4.​
​2.​2]
n [http://​www.​openbsd.​org/​papers/​
​pfsync_v5.​pdf]
Bernd Kohler (per E-Mail)
@ leserbriefe@admin-magazin.de
www.facebook.com/adminmagazin www.twitter.com/admagz
22 Ausgabe 06-2011 Admin www.admin-magazin.de

NUR 3,56€ *
pro vServer in der Customer Cloud
NEU: AB 10. NOVEMBER 2011
Endlich mit der Cloud
mal richtig sparen!
Die Private Cloud, die sich jedes Unternehmen leisten kann. Sparen Sie Ressourcen,
Manpower und Budget: Ab 15,45 €* pro Monat können Sie sich Ihre eigene Virtual- Core®
Customer Cloud ins Unternehmen holen und Ihre IT-Kapazitäten durch Virtualisierung so
flexibel wie noch nie gestalten.
6 Monate kostenlos testen unter www.virtual-core.de
* Preise inkl. MwSt.
Virtual-Core® ist eine eingetragene Marke der Firma KAMP Netzwerkdienste GmbH – www.kamp.de

Login
Think Twice
Effizienz versus Stabilität beim Software-Entwickeln
Vom Segen
der Doppelarbeit
Sind die zahlreichen Nagios-Ableger redundanter Software-Ballast und der Ausweis fehlender Effizienz in der
Open-Source-Entwicklung – oder im Gegenteil das Symptom einer gesunden Vielfalt? Jens-Christoph Brendel
Alles begann damit, dass wir uns wieder
einmal Monitoring-Software angesehen
haben. Zabbix, OpenNMS, natürlich Nagios,
aber auch seine vielen Ableger. Gut
ein Dutzend Projekte und Produkte haben
wir allein in der Sparte Nagios-Nachfahren
und Abkömmlinge gezählt. Lösungen,
die hauptsächlich das freie Nagios
und andere Open-Source-Komponenten
integ rieren wie Groundworks oder Open
IT-Cockpit, solche
© arogant, 123RF
lation, eine Art von Maschine. Der Preis
dieser Effizienz ist allerdings Anfälligkeit
– denn ohne Schädlingsbekämpfung
verwandelte sich leicht die ganze Kultur
in das Schlaraffenland eines Ungeziefers
oder Pilzes oder in Windbruch oder dürres
Ödland. Die Geschichte ist voll von
solchen Katastophen von der großen Hungersnot
infolge der irischen Kartoffelfäule
um die Mitte des 19. Jahrhunderts bis zu
40 Prozent Ertragsverlusten durch Pflanzenkrankheiten
in Entwicklungsländern
heute. Ein Gegenspieler der Effizienz ist
die Diversität. Die Artenvielfalt markiert
zugleich den Gegenpol zur Verletzlichkeit
der Monokultur. Ein Biotop aus lauter
unterschiedlichen Arten wäre sehr stabil,
denn was hier den einen gefährdet, ließe
den Nächsten kalt, und viele Mitspieler
könnten sich gegenseitig ersetzen. Dafür
müsste man es viel differenzierter bewirtschaften.
Wollte man der Stabilität wegen
die Verschiedenheit aber auf die Spitze
treiben, dann verwandelte sich auch dieser
Vor- in einen Nachteil: Die Widerstandskraft
würde mit Stagnation erkauft,
denn wo im Extremfall nur noch wenige
Individuen pro Art existierten, da wäre
Fortpflanzung wegen der zu geringen
Populationsdichte kaum mehr möglich.
Aus diesem Grund maximiert die Natur
weder die Effizienz noch die Diversität,
sondern strebt nach einem Gleichgewicht
beider Faktoren. So vielfältig wie möglich,
ohne dass es zu einem Stillstand
kommt, so effizient wie es geht, ohne zu
leicht verwundbar zu sein.
Dieser Gedanke lässt sich übertragen:
Eine vielfältige Software-Landschaft bietet
Alternativen für mancherlei Ansprüche
und wirkt einem Vendor Lock-In entdie
mehr eigenen Code einbringen wie
Centreon und wieder andere, die nur die
Architektur übernehmen, um auf dieser
Grundlage völlig neue Software zu entwickeln,
wie zum Beispiel Shinken.
Angesichts der Menge drängt sich allerdings
eine Frage geradezu auf: Sind das
nicht viel zu viele Anläufe auf dasselbe
Ziel? Ist das nicht reine Ressourcenvergeudung?
Wo könnten die Entwickler
stehen, wenn sie an einem Strang zögen,
statt jeweils ihr eigenes Süppchen zu kochen?
Kurz: Kann das effizient sein? Das
Nein muss einem auf der Zunge liegen.
Denn das Rad ein Dutzend Mal zu erfinden
führt zwangsläufig zu Dubletten
und Überschneidungen.
Doch ist Effizienz hier überhaupt
der richtige Maßstab?
Auf Anhieb übersetzt man
effizient mit wirtschaftlich,
und dann scheint außer
Frage zu stehen, dass
damit eine Grundvoraussetzung
bezeichnet
ist. Doch könnte das
nicht vorschnell gefolgert
sein? Manchmal
erhellt eine Analogie zu
scheinbar fernliegenden
Bereichen die Zusammenhänge.
Hier zum Beispiel
ein Blick auf natürliche
Ökosysteme.
Effizient – zumindest aus der
Sicht des menschlichen Nutzers
– sind etwa Monokulturen.
Alle Pflanzen lassen sich dort über
einen Kamm scheren, sei es bei Aussaat
oder Ernte, beim Düngen oder bei der Bewässerung:
Es reicht jeweils eine Kalku-
C
M
Y
CM
MY
CY
CMY
K
24 Ausgabe 06-2011 Admin www.admin-magazin.de

Think Twice
Login
getD_043_Magazine_Ad_3.ai 1 6/22/11 9:22 PM
letter, News, Mailinglisten, FAQ, Howtos,
Foren, Chats, Blogs, Dependancen
in sozialen Netzen und so weiter). Der
Umfang ist unterschiedlich – sehr ausgeprägt
ist der Service für Kunden etwa bei
Centreon oder OP5, etwas zurückhaltender
gerieren sich Neteye oder Open
IT-Cockpit – aber allen kann man das
Bemühen attestieren, eine lebendige
Community zu entwickeln.
Nagios und seine Nachfahren scheinen
also ein vielfältiges und stabiles Biotop
zu bilden, das etlichen Akteuren eine
Nische bietet, in der sie ihr Auskommen
finden. Darin tummeln sich sowohl Projekte,
die in erster Linie von kommerziellen
Interessen geleitet werden, als auch
solche, die den Open-Source- Gedanken
hochhalten und mehr oder weniger vom
Idealismus ihrer Entwickler leben. Was
funktioniert, hat recht. Es fände sich
wohl auch nur schwer eine Rechtfertigung
für eine Effizienzpolizei. Zumal das
Biotop ja insoweit sogar auch effizient
ist, als überall dasselbe Funktionsprinzip
und Architekturmodell
zum Einsatz kommt und
die für die Flexibilität einer
Nagios-Lösung so entscheidenden
Plugins sehr oft
ohne Änderungen nachnutzbar
sind.
Das Rad ist übrigens
im wirklichen Leben
tatsächlich mehrfach
erfunden worden. In
Mesopotamien und der
Induskultur, dem Alpenvorland,
im Nordkaukasus,
in Südpolen stößt
man unabhängig voneinander
um die Mitte des
4. Jahrtausends vor Christus
auf erste Räder und Karren.
Trotzdem handelt es sich dabei
um eine der größten technischen
Errungenschaften des Menschen
überhaupt.
n
IT-Admin? Computerfreak? Technikfan?
Dann schau rein bei getDigital.de, dem Shop mit Gadgets,
T-Shirts und Geschenken für Geeks und alle Computerfans!
USB Gadgets
USB Stressball
=C23,90
Drücken lässt
den Bildschirm
schrumpfen!
USB Webcam Raketenwerfer
Mit Webcam
und fernsteuerbar
per
Skype!
=C59,95
Tools für Nerds T-Shirts für Admins Vorteilsgutschein
USB Batterien
ab
=C16,95
Batterien sind am USB-Anschluss
aufladbar.
Anyloader
Lädt Handy und
Co. mit
Solarstrom.
=C34,95
=C= 34
Turning it off and on again
No.
Alternativ
geht
natürlich
auch diese
Antwort.
ab
=C14,90
Die
Standardantwort
im Support
ab
=C15,90
RFID Schutzhülle
=C4,95
Mit dem Gutscheincode
ITAM_TKKNRQ
gibt es für Leser des IT-Admin-
Magazins eine RFID Schutzhülle
kostenlos zur Bestellung dazu!
gegen. Gäbe es aber nur noch Programm-
Unikate, explodierten die Wartungs- und
Schulungskosten, gäbe es keinen Erfahrungsaustausch
zwischen den Anwendern
mehr, lohnte es für Dritte kaum,
Erweiterungen zu programmieren, müssten
jedoch andererseits die Software-
Preise in extreme Höhen schnellen. Aus
dieser Perspektive sollte man also eher
fragen: Markieren ein Dutzend Nagios-
Ableger eine gesunde Balance?
Sie scheinen zumindest überwiegend ihre
Nischen gefunden zu haben. Alle haben
Kunden, die meisten erreichen sie auch
über Partner, für die sie extra Programme
auflegen. Schon potenzielle Kunden
können mit einer Ausnahme überall kostenlose
Demoversionen herunterladen,
manchmal auch vorinstallierte Demos
via Internet ausprobieren. Mehr als die
Hälfte der Anbieter von Nagios-Nachfahren
offerieren Trainings, alle auf die eine
oder andere Weise Support und zusätzliche
Informationen (Referenzen, Newswww.getdigital.de

Login
Interview
Interview mit Nagios-Chefentwickler Ethan Galstad
Industriestandard
fürs Monitoring
Ende September fand im amerikanischen Saint Paul die erste Nagios World Conference, ausgerichtet von Nagios-
Erfinder und ‐Entwickler Ethan Galstad, statt. Er konnte mehr als 150 Teilnehmer aus aller Welt begrüßen und
fand am Rande der Konferenz Zeit für ein Gespräch mit dem ADMIN-Magazin. Christian Mies
Galstad präsentierte in seiner Keynote
Neuerungen zu Nagios im Open-Sourceund
kommerziellen Bereich, hauptsächlich
Erweiterungen bestehender Community-Projekte
wie Nagios Core Configuration
Management (NCCM), ein neues auf
PHP basierendes Webinterface oder ein
Addon für das Business Process
Monitoring. Die Rede war auch
von Entwicklungsarbeiten an
einem neuen Nagios-4-Kern,
aber Termine konnten dazu
nicht genannt werden. Daneben
will sich Galstads Firma
Nagios Ltd. künftig verstärkt
um Supportangebote auch für
die kostennlose Version bemühen.
Im Einzelnen antwortete
Ethan Galstad:
Welche neuen Features werden
gegenwärtig für Nagios
XI und Nagios entwickelt?
Galstad : Unser Team hat im
vergangenen Jahr viele neue
Entwicklungen veröffentlicht,
und in den nächsten Monaten
kommen noch einige hinzu. Da
ist zuerst die Nagios V-Shell,
eine neue PHP-GUI für Nagios,
die ohne CGIs auskommt. Mithilfe
von Ajax kann sie Daten
auf dem Bildschirm live updaten,
sie bietet Paging und einige Features
mehr. Erst kürzlich haben wir zudem die
Unterstützung für eine Lokalisierung hinzugefügt,
die Nagios für Anwender in der
ganzen Welt bessser handhabbar macht.
Seit ihrem Erscheinen gehört die V-Shell
zu den populärsten Nagios-Downloads.
Dann gibt es da unser neues Business
Process Intelligence-Addon, das es einfach
macht, Geschäftsprozesse mit Nagios
zu überwachen. BPI offeriert fortgeschrittene
Möglichkeiten für eine Gruppierung,
erweiterbare Prozess-Bäume
und eine einfache Konfiguration.
Der Nagios Core Config Manager (CCM)
ist ein neues Konfigurations-Frontend,
das wir auf der Grundlage der Erfahrungen
mit Nagios XI entwickelt haben.
Das Projekt begann als Überarbeitung
von NagiosQL, hat sich aber inzwischen
ausgeweitet und bietet Features, nach
denen viele Kunden lange suchten. Das
Projekt durchläuft im Moment eine eingeschränkte
Beta-Phase mit einigen Kunden,
sollte aber Ende des Jahres für alle
verfügbar sein.
In den nächsten zwei Monaten wird außerdem
ein neues Release der NDOUtils
erscheinen, das asynchrone
(nicht blockierende) Schreiboperationen
auf das Datenbank-Backend
erlaubt. Zudem
werden weitere Performanceverbesserungen
– besonders
für Datenbanken in großen
Umgebungen – Eingang in die
Codebasis finden.
NRDP ist eine neu entwickelte
Lösung für das Versenden und
Verarbeiten passiver Checks.
Es wurde als Ersatz für NSCA
entwickelt und transportiert
seine Daten im XML-Format
via HTTP, was seinen Einsatz
in Umgebungen erleichtert, die
mit Firewalls gesichert sind.
Perl- und PHP-Clients machen
es leicht, NRDP für verteiltes
Monitoring und die Integration
von Alarmen externer Applikationen
in Nagios einzusetzen.
Nagios Mobile ist ein neues
Frontend, dessen Veröffentlichung
für November geplant
ist. Es soll es für den Admin einfacher
machen, Alarme an jedem Ort zu managen,
an dem er sich gerade befindet.
Zu den neuesten Erweiterungen für Nagios
XI zählen neue Visualisierungs-Tools
wie Heatmaps und Alertstreams, fortgeschrittene
Reports und Exportmöglichkei-
26 Ausgabe 06-2011 Admin www.admin-magazin.de

ten dafür, bessere Optionen für verteiltes
Monitoring, Performanceverbesserungen,
eine LDAP-Integration und mehr. Außerdem
wurden neue Wizards entwickelt,
die es einfacher machen, eine Überwachung
von Active Directory, Exchange,
SQL Server, Oracle oder DB2 zu konfigurieren.
Wir beobachten weiter, dass eine wachsende
Anzahl von Kunden von Nagios
Core oder anderen Monitoringlösungen
zu Nagios XI migriert, was ein gesteigertes
Interesse an noch mehr neuen
Features weckt. So planen wir für kommende
Versionen zeitgesteuerte Reports,
weitere APIs und eine weiter verbesserte
Skalierbarkeit.
Außerdem arbeiten wir an einer API,
die es externen Applikationen möglich
machen soll, Kommandos an Nagios XI
oder Nagios Core zu schicken, an einen
SNMP Trap Manager und an „Nagios
Montage“, einen einfach verwendbaren,
paketierten Nagios Core mit den populärsten
Addons.
Das alles ist nur ein kleiner Ausschnitt
aus der Nagios-Entwicklung der letzten
Zeit. Allein im Jahr 2011 wurden über
600 verschiedene Addons, Plugins und
Projekte veröffentlicht.
Was denken Sie über Shinken, Icinga
und andere Forks?
Galstad : Es gibt mehrere Dutzend Reimplementierungen
in verschiedenen
Sprachen – einige kommerziell, andere
Open Source. Einige werden derzeit weiterentwickelt,
aber viele sind aufgrund
der mangelnden Nachhaltigkeit ihrer
Communities wieder eingestellt worden.
Sourceforge ist die Heimat Tausender
Projekte, die nach kurzer Zeit wieder
aufgegeben wurden.
Soweit ich sehe, befindet sich Shinken
noch in einer sehr frühen Entwicklungsphase
und ist wahrscheinlich zu jung,
um für Produktivumgebungen infrage zu
kommen. Bugs im Python-Code werden
seine Entwickler wohl noch einige Zeit
beschäftigen, während Bedenken wegen
der Skalierbarkeit das Projekt womöglich
von großen Umgebungen fernhalten
werden.
Icinga hat einige Fortschritte an verschiedenen
Fronten erzielt, aber es hat
viel weniger Addons und eine viel kleinere
Community als Nagios. Zusätzlich
scheint das Entwicklungsteam in den
letzten zwei Jahren eine hohe Fluktuation
gehabt zu haben, was es fraglich
macht, ob es auf lange Sicht die nötige
Beständigkeit erreicht.
Wenn Entwickler ein Projekt starten,
denken sie selten daran, wie es viele
Jahre überstehen kann. In den letzten
13 Jahren Nagios-Entwicklung habe ich
zahlreiche Herausforderungen kommen
sehen und überstanden, die andere längst
dazu gebracht hätten, ihr Projekt aufzugeben.
Was zeichnet Nagios gegenüber diesen
Forks aus?
Galstad : Organisationen vertrauen Nagios
wegen seiner Flexibilität, langen
Geschichte, der weltweiten Community
und der Fülle freier Addons. Deshalb gab
es mehr als drei Millionen neuer Nagios-
Installationen in den letzten 12 Monaten
weltweit. Deshalb ist Nagios heute der
wahre Industriestandard für das Monitoring.
Firmen ist es wichtig, sich für eine Lösung
zu entscheiden, die sich auf eine lange
Geschichte und eine aktive Community
stützen kann.
Nagios hat eine sehr viel größere Community
als andere Projekte, was Firmen
mehr Unterstützung, eine bessere
Dokumentation und mehr Addons verspricht,
wenn sie sich entschließen, Nagios
zu verwenden. Tausende Addons
wurden bereits für Nagios entwickelt.
Die meisten finden sich auf dem Web-
Portal Nagios Exchange [1]. Seit 2009
wurden etwa 1500 neue Projekte abgeschlossen,
darunter rund 600 allein im
Jahr 2011. Dahinter steht ein gewaltiger
Entwicklungsaufwand. Andere Projekte
kommen in dieser Beziehung nicht
einmal in die Nähe.
n
Der Autor
Christian Mies arbeitet als Senior Consultant
und Projektleiter für den Nagios-Spezialisten
it-novum. Er beschäftigt sich neben Nagios auch
mit Open IT-Cockpit, Prince2 oder ITIL v3 und
betreibt in seiner Freizeit engagiert Ausdauersport.
Infos
[1] Nagios Exchange:
[http:// exchange. nagios. org]
stark · schnell · innovativ
www.admin-magazin.de

Netzwerk
Hyper-V
© Kitch Bain, 123RF
Hyper-V-Netzwerkeinstellungen optimieren
Flusskontrolle
Bei Leistungsproblemen von virtuellen Servern unter Hyper-V liegt der
Flaschenhals oft im Netzwerkzugriff. Mit dem passenden Know-how können
Administratoren Optimierungen vornehmen, die die virtuellen Netzwerkverbindungen
deutlich beschleunigen. Thomas Joos
Die Version 3.0 von Hyper-V in Windows
Server 8 bietet zahlreiche Verbesserungen
im Netzwerkbereich, die zu höherer Performance
verhelfen. Beispiele dafür sind
der direkte Zugriff von virtuellen Maschinen
auf Hardwarefunktionen der Netzwerkkarte
oder eine bessere Steuerung
und Konfiguration von Netzwerkverbindungen.
Aber auch in der aktuellen Version
Hyper-V 2.0 in Windows Server 2008
R2 lassen sich Optimierungen durchführen,
die Netzwerkverbindungen von virtuellen
Servern deutlich beschleunigen.
Funktionsweise von Hyper-
V-Netzwerken
Damit virtuelle Server in Hyper-V-Netzwerken
auf das physische Netzwerk zugreifen
können, muss es eine Verbindung
zwischen dem virtuellen Server und der
physischen Netzwerkkarte des Hyper-V-
Hosts geben. Diese Verbindung bildet der
Hypervisor über einen virtuellen Netzwerkswitch
ab. Da sich die verschiedenen
virtuellen Server auf dem Hyper-
V-Host die physischen Netzwerkkarten
teilen müssen, kann es hier durchaus
zu Konflikten und Ressourcenengpässen
kommen. Die Verwaltung der Netzwerke
findet im Hyper-V-Manager über den Manager
für virtuelle Netzwerke statt (Abbildung
1). Hier können Sie drei Arten
von virtuellen Netzwerken erstellen:
n Externe virtuelle Netzwerke: Diese
Netzwerke erlauben eine Kommunikation
der virtuellen Server untereinander
und mit dem Rest des
Netzwerks. Bei diesen Verbindungen
sind die physischen Netzwerkkarten
eingebunden. Die Verbindung erfolgt
über einen virtuellen Switch, die den
Hyper-V-Host und die virtuellen Server,
welche die Verbindung nutzen,
mit dem Netzwerk verbinden. Sie können
im Hyper-V-Manager immer nur
ein externes Netzwerk pro verfügbarer
Netzwerkkarte erstellen. Interne virtuelle
Netzwerke können Sie allerdings
beliebig oft anlegen, da diese nicht mit
einer Netzwerkkarte verbunden sind,
sondern nur der internen Kommunikation
dienen.
n Interne virtuelle Netzwerke: Diese
Netzwerke erlauben lediglich die Kommunikation
der virtuellen Server untereinander
und mit dem physischen
Host, auf dem sie installiert sind. Die
Server können nicht mit dem Rest des
Netzwerks kommunizieren.
n Private virtuelle Netzwerke: Diese
Netzwerke erlauben lediglich eine
Kommunikation zwischen den virtuellen
Servern auf dem Host. Die Kommunikation
mit dem Host selbst ist
nicht möglich.
Sie sollten daher genau planen, welchen
Typ eines virtuellen Netzwerks die
einzelnen virtuellen Server benötigen.
Nicht immer sind externe Netzwerke
notwendig.
Grundsätzlich ist es empfehlenswert, einen
Netzwerkadapter auf jedem Hyper-
V-Host für die Verwaltung des Servers zu
verwenden, also nicht in die Hyper-V-
Konfiguration einzubinden. Sonst kann
28 Ausgabe 06-2011 Admin www.admin-magazin.de

Hyper-V
Netzwerk
den physischen
Netzwerkkarten
zu externen Netzwerken
zusammenfassen
und
den gewünschten
Servern zuweisen.
Grundlage für eine
schnelle Netzwerkkommunikation
ist
also zunächst die
optimale Planung
für den Einsatz der
physischen Netzwerkkarten.
Während Sie auf
dem Hyper-V-
Host die generelle
Struktur der Netzwerke
konfigurie-
Abbildung 1: Verwalten von Netzwerken im Hyper-V-Manager.
ren, legen Sie in
es sein, dass bei starker Belastung der
den Einstellungen
Netzwerkverbindung, zum Beispiel beim der einzelnen virtuellen Server fest, welche
Art von virtuellen Netzwerkkarten
Kopieren von Patches oder neuen Anwendungen
auf den Servern, die Leistung Sie für den Server verwenden wollen.
einiger virtueller Server einbrechen kann. Klicken Sie auf »Hardware hinzufügen«
Sie sollten also generell den Netzwerkverkehr
des Hyper-V-Hosts selbst vom vern, haben Sie die Möglichkeit, ver-
in den Einstellungen von virtuellen Ser-
Netzwerkverkehr der virtuellen Maschinen
trennen.
(Abbildung 2). Der Typ »Netzwerkkarte«
schiedene Netzwerkkarten zu integrieren
verwendet die Verbindung zwischen Hypervisor
und der physischen Netzwerk-
Auch für NAS und iSCSI
karte. Dieser Typ kann Netzwerkdaten
Diese Vorgehensweise ist auch bei der sehr schnell senden und empfangen. Die
Anbindung von Netzwerkspeicher, zum Kommunikation erfolgt über einen internen
Treiber in den virtuellen Maschinen,
Beispiel NAS oder iSCSI, empfehlenswert.
Auch hier sollten Sie für jede Verbindung
eine eigene Netzwerkkarte auf stellen. Daher sollten Sie darauf achten,
die die Integrationsdienste zur Verfügung
dem Hyper-V-Host zur Verfügung stellen, innerhalb der virtuellen Server die Integrationsdienste
aktiv zu halten bezie-
die nur für den Datenverkehr zum Datenspeicher
verwendet wird. Das heißt, hungsweise zu installieren.
schon außerhalb von Hyper-V können Der Typ »Ältere Netzwerkkarte« ist nur
Sie eine deutliche Leistungssteigerung sinnvoll, wenn Sie spezielle Server virtualisieren,
die nicht den neuen Typ
erreichen, wenn Sie dedizierte Netzwerkkarten
einsetzen.
verwenden können. Beispiel dafür sind
Diese Optimierung können Sie auch auf Server, die über das Netzwerk booten
die virtuellen Hyper-V-Server ausdehnen. sollen, etwa mit PXE. Ist der Typ »Netz-
Analysieren Sie, welche virtuellen Server
die meiste Netzwerkbandbreite verbrauchen
und stellen Sie solchen Servern eigene
Netzwerkkarten über virtuelle externe
Netzwerke zur Verfügung. Server,
die nur wenig Netzwerkbandbreite benötigen,
können Sie mit mehreren virtuellen
Netzwerken zusammenfassen. Eine
solche Zusammenfassung erreichen Sie
sehr einfach, indem Sie die entsprechen- Abbildung 2: Netzwerkkarten zu Servern hinzufügen.
werkkarte« für solche Server nicht geeignet,
verwenden Sie stattdessen Ȁltere
Netzwerkkarte«. Bei diesem Typ emuliert
Hyper-V einen Intel-21140-basierten
PCI-Fast-Ethernet-Adapter. Dieser Adapter
funktioniert auch ohne installierten
Treiber, bietet aber nicht die hohe Geschwindigkeit
des virtuellen Switches
zwischen Hypervisor und physischer
Netzwerkkarte. Für die Emulation muss
der Prozessor des Hyper-V-Hosts eigens
Rechenzeit aufwenden.
Netzwerkkarte übernimmt
Windows Server 2008 R2 unterstützt
TCP Chimney Offload. Bei dieser Technik
lassen sich Berechnungen für den Netzwerkverkehr
vom Prozessor zu den Netzwerkkarten
delegieren, was die Leistung
des Rechners für Anwendungen und im
Netzwerk erheblich beschleunigen kann.
Diese Funktion nutzt auch Hyper-V in
Windows Server 2008 R2. Damit diese
Technik ihre optimale Wirkung entfaltet,
müssen Sie sicherstellen, dass der
Hyper-V-Host und die einzelnen virtuellen
Maschinen für TCP Chimney Offload
konfiguriert sind. Die Einstellungen
dazu nehmen Sie in den Eigenschaften
der Netzwerkverbindungen auf dem Host
und den virtuellen Servern vor, sowie
direkt im Betriebssystem in der Befehlszeile
auf Host und virtuellen Servern.
Geben Sie auf dem Hyper-V-Host und den
virtuellen Servern, in denen Sie die Funktion
nutzen wollen, den Befehl »netsh
int tcp set global chimney=enabled«
ein. Um die Funktion zu deaktivieren,
verwenden Sie »netsh int tcp set global
Abbildung 3: Aktivieren von TCP Chimney Offload für
Netzwerkkarten.
www.admin-magazin.de
Admin
Ausgabe 06-2011
29

Netzwerk
Hyper-V
Abbildung 4: Verwaltung der virtuellen MAC-
Adressen in Hyper-V.
chimney=disabled«. Um sich generell die
Einstellungen anzeigen zu lassen, geben
Sie »netsh int tcp show global« ein. Auf
der Befehlszeile sehen Sie über »netstat
‐t«, ob die Abladung funktioniert.
Rufen Sie anschließend im Geräte-Manager
der virtuellen Server und des Hosts
die Eigenschaften der Netzwerkkarte auf,
für die Sie die Funktion aktivieren wollen.
Wechseln Sie auf die Registerkarte
»Erweitert« und suchen Sie nach der
Funktion »TCP‐Prüfsummenabladung«.
Stellen Sie sicher, dass »Rx & Tx‐aktiviert«
eingestellt ist (Abbildung 3).
Hyper-V im Cluster:
MAC-Adressen
Extrem wichtig sind die Einstellungen für
virtuelle MAC-Adressen in den Einstellungen
der virtuellen Netzwerkkarten.
Hier müssen Sie für die Livemigration,
beim Betrieb von Hyper-V im Cluster und
vor allem bei der Aktivierung des Betriebssystems
auf jeden Fall Einstellungen
vornehmen, da Sie ansonsten ständig die
Server neu aktivieren müssen. Außerdem
spielen diese Einstellungen in NLB-Clustern
mit Exchange Server 2010 und auch
für Sharepoint Server 2010 eine wichtige
Rolle, da die Kommunikation auch hier
von MAC-Adressen abhängt.
Verschieben Sie einen virtuellen Server
mit aktivierten dynamischen MAC-
Adressen im Cluster auf einen anderen
Host, ändert sich dessen MAC-Adresse
beim nächsten Start. Im MSDN-Beitrag
auf der Seite [1] finden Sie dazu umfangreiche
Informationen. Jeder Hyper-
V-Host verfügt über einen eigenen Pool
dynamischer MAC-Adressen. Welche
Adressen der Pool umfasst, sehen Sie im
Hyper-V-Manager über den Manager für
virtuelle Netzwerke im Bereich »MAC‐Adressbereich«
(Abbildung 4). Wenn sich
die MAC-Adresse eines virtuellen Servers
ändert, kann es sein, dass Sie das Betriebssystem
neu aktivieren müssen oder
ein virtueller NLB-Cluster nicht mehr
funktioniert. Microsoft beschreibt diesen
Fehler auf der Webseite [2] genauer. Aus
diesem Grund ist es sehr empfehlenswert,
die statische Zuordnung von MAC-Adressen
für virtuelle Server zu aktivieren.
Sie finden diese Einstellung im Bereich
»Netzwerkkarte« der einzelnen virtuellen
Server im Hyper-V-Manager.
In diesen Einstellungen können Sie auch
das Spoofing für Netzwerkkarten steuern.
Hyper-V kann genau unterscheiden,
welche Netzwerkdaten zu den einzelnen
Servern gesendet werden sollen und verwendet
dazu die MAC-Adresse des virtuellen
Servers. Das heißt, virtuelle Server
empfangen nur die Daten, die für ihre
MAC-Adresse gedacht sind.
Netzwerke und
Live-Migration
Wer einen Hyper-V-Cluster betreibt, sollte
auch dafür dedizierte Netzwerkverbindungen
verwenden, vor allem bei der
Live-Migration in Windows Server 2008
R2. Bei der Live-Migration lassen sich
virtuelle Computer von einem Host auf
einen anderen übertragen, ohne dass
Benutzer Daten verlieren oder von den
Servern getrennt werden. Die Server sind
während der Übertragung zwischen den
Cluster-Knoten weiterhin aktiv.
Der Start einer Livemigration kann entweder
über die Clusterkonsole erfolgen, per
Skript (auch Powershell) oder über den
System Center Virtual Machine Manager
(SCVMM) 2008 R2. Während des ganzen
folgenden Ablaufs läuft die VM uneingeschränkt
weiter, und Anwender können
ungestört mit dem virtuellen Server arbeiten.
Der Ablauf dabei ist Folgender:
n Beim Start baut der Quellserver eine
Verbindung zum Zielserver auf.
n Anschließend überträgt der Quellserver
die Konfiguration der virtuellen
Maschine auf den Zielserver.
n Der Zielserver erstellt auf Basis dieser
leeren Konfiguration eine neue VM,
die der zu verschiebenden VM entspricht.
n Nun überträgt der Quellserver die einzelnen
Seiten des Arbeitsspeichers zur
Ziel-VM mit einer Standardgröße von
etwa 4 KByte. Je schneller das Netzwerk,
desto schneller wird der Inhalt
des Arbeitsspeichers übertragen.
n Als Nächstes übernimmt der Zielserver
die virtuellen Festplatten des
Quellservers für die zu übertragende
virtuelle Maschine.
n Anschließend setzt der Zielserver die
virtuelle Maschine online.
n Zum Schluss wird der virtuelle Hyper-
V-Switch informiert, dass Netzwerkverkehr
jetzt zur MAC-Adresse des
Zielservers gesendet werden soll.
Damit die Übertragung funktioniert,
müssen die Hostsysteme in einem gemeinsamen
Cluster zusammengeschaltet
sein. Die Leistung der Netzwerkkarte
spielt dabei ebenfalls eine große Rolle.
Aus diesem Grund sind dedizierte Karten
hier besonders wichtig. Die Übertragung
ohne Cluster oder zwischen verschiedenen
Clustern funktioniert nicht. Die
VHD-Dateien müssen außerdem auf dem
gleichen gemeinsamen Datenträger (CSV)
liegen. Mit Hyper-V 3.0 in Windows 8
Server führt Microsoft Hyper-V-Replica
ein. Bei dieser Funktion können Hyper-
V-Hosts virtuelle Server asynchron replizieren,
ohne in einem Cluster laufen zu
müssen. Auch hier sollten Sie dedizierte
Netzwerkkarten verwenden.
Der große Unterschied zur Schnellmigration
in Hyper-V 1.0 (Windows
Server 2008) besteht darin, dass die
Maschinen während der Übertragung
durch Livemigration aktiv bleiben und
auch der Arbeitsspeicherinhalt zwischen
den Servern übertragen wird. Bei der
Schnellmigration deaktiviert Hyper-V die
Maschinen erst. Windows Server 2008
R2 beherrscht neben der Livemigration
auch weiterhin die Schnellmigration. Basis
der Technik ist ein Cluster mit Windows
Server 2008 R2. Daher können Sie
entweder die Enterprise-Edition und die
Datacenter-Edition von Windows Server
2008 R2 verwenden oder den kostenlosen
Microsoft Hyper-V-Server 2008 R2.
Ein Cluster mit Windows Server 2008
R2 lässt sich so konfigurieren, dass die
Cluster-Knoten den Netzwerkverkehr
zwischen den Knoten und zu den gemeinsamen
Datenträgern priorisieren.
Für einen schnellen Überblick, welche
Netzwerkeinstellungen der Cluster zur
Kommunikation mit dem Cluster Shared
Volume (CSV) nutzt, starten Sie eine
Powershell-Sitzung auf dem Server und
30 Ausgabe 06-2011 Admin www.admin-magazin.de

Hyper-V
Netzwerk
Abbildung 5: Konfigurieren der VLAN-Anbindung.
rufen das Cmdlet »Get‐ClusterNetwork«
auf. Allerdings funktioniert das Cmdlet
erst dann, wenn Sie die Befehle zur Clusterverwaltung
mit dem Befehl »Add‐Module
FailoverClusters« in die Powershell
integrieren. Sie sehen auch in der Verwaltungskonsole
des Clusters, welche Netzwerke
vorhanden sind und vom Server
genutzt werden können.
Hyper-V Network
Command Line
Mit dem kostenlosen Tool NVSPBIND [3]
können Administratoren, die Hyper-V auf
einem Core-Server betreiben, die einzelnen
Bindungen für Netzwerkprotokolle
auf den Netzwerkkarten der Hyper-V-Server
verwalten. Das Tool stammt von den
Hyper-V-Entwicklern und funktioniert
auf Core-Servern und für Hyper-V-Server
2008 sowie Hyper-V Server 2008 R2. Mit
NVSPSCRUB [4] können Sie alle Hyper-
V-Netzwerke und Verbindungen löschen.
Vor allem beim Betrieb von Hyper-V auf
Core-Servern ist das Tool hilfreich, wenn
der Hyper-V-Manager nicht zur Verfügung
steht. Folgende Optionen stehen für
»nvspscrub« zur Verfügung:
n /? zeigt die Hilfe an.
n /v löscht deaktivierte virtuelle Netzwerke.
n /p löscht Einstellungen der virtuellen
Netzwerke.
n /n löscht ein spezielles Netzwerk.
Virtuelle LANs (VLAN)
und Hyper-V
Hyper-V im Windows Server 2008 R2
unterstützt auch die Verwendung von
VLANs. Bei solchen Netzwerken lassen
sich Datenströme voneinander trennen,
um die Sicherheit und die Leistung zu
erhöhen. Die Technik muss aber direkt
im Netzwerk integriert sein. Switches
und Netzwerkkarten müssen zudem die
Funktion unterstützen. Dadurch lässt
sich zum Beispiel der Netzwerkverkehr
für die Verwaltung des Servers vom Netz-
werkverkehr der virtuellen Server trennen.
Damit die Anbindung funktioniert,
müssen Sie in den physischen Netzwerkkarten
der Hyper-V-Hosts in den erweiterten
Einstellungen der Netzwerkkarte
festlegen, zu welcher VLAN-ID die Karte
gehören soll.
Anschließend starten Sie im Hyper-V-
Manager den Manager für virtuelle Netzwerke
und wählen die Netzwerkverbindung
aus, die Sie an das VLAN anbinden
wollen. Auch hier geben Sie die entsprechende
VLAN-ID vor (Abbildung 5).
Dazu müssen Sie aber zunächst die Option
»Identifizierung virtueller LANs«
für das Verwaltungsbetriebssystem aktivieren.
Nachdem Sie die ID angegeben
haben, fließt der Datenverkehr von dieser
Verbindung über die entsprechende
ID. Auch interne Netzwerke in Hyper-V
unterstützen die VLAN-Konfiguration.
Zusätzlich lassen sich auch virtuelle
Server an VLANs binden. Dazu müssen
Sie in den Einstellungen der virtuellen
Server über die Eigenschaften der virtuellen
Netzwerkkarten
ebenfalls die VLAN-ID
angeben.
Wollen Sie, dass ein
virtueller Server mit
mehreren VLANs kommunizieren
kann, fügen
Sie dem Server einfach
mehrere virtuelle
Netzwerkkarten hinzu
und konfigurieren das
entsprechende VLAN.
Durch diese durchgehende
Unterstützung
von VLANs können
Sie bei entsprechend
kompatiblen Switches
zum Beispiel Testumgebungen
aufbauen
oder Hyper-V-Hosts
logisch voneinander
trennen, auch wenn
diese im selben Netzwerk
konfiguriert sind.
(ofr/​cth)
n
Infos
[1] Hyper-V and Dynamic
MAC Address ­
Regeneration: ­
[http://​­blogs.​­msdn.​
­com/​­b/​­virtual_pc_guy/​­archive/​­2010/​­05/​­14/​hyper‐v‐and‐dynamic‐mac‐address‐regeneration.​­aspx]
[2] Windows Server 2008 Hyper-V virtual
machines generate a Stop error when NLB
is configured or when the NLB cluster does
not converge as expected: ­
[http://​­support.​­microsoft.​­com/​­kb/​­953828/​
­en‐us]
[3] NVSPBIND: ­
[http://​­blogs.​­technet.​­com/​­b/​­virtualization/​
­archive/​­2010/​­01/​­26/​­hyper_2d00_v‐network
‐command‐line‐tool‐nvspbind‐now‐availabl
e‐externally.​­aspx]
[4] NVSPSCRUB: ­
[http://​­code.​­msdn.​­microsoft.​­com/​
­nvspscrub]
Der Autor
Thomas Joos ist freiberuflicher IT-Consultant
und seit über 20 Jahren in der IT tätig. Neben
seinen Projekten schreibt er praxisnahe Fachbücher
und Fachartikel rund um Windows und
andere Microsoft-Themen. Online trifft man ihn
unter [http://​­thomasjoos.​­spaces.​­live.​­com].
CouchDB
Das Praxisbuch
304 S., 2011, 34,90 €
» www.GalileoComputing.de/2462
Admin-Know-how
Linux Hochverfügbarkeit
454 S., 2011, 49,90 €
» www.GalileoComputing.de/1999
MySQL
aktuell zur Version 5.5 und 5.6
750 S., 2011, mit DVD, 49,90 €
» www.GalileoComputing.de/2533
www.GalileoComputing.de
Linux-Server
Bestseller!
815 S., 2011, 49,90 €
» www.GalileoComputing.de/2205
www.admin-magazin.de
Wissen, wie’s geht.

Netzwerk
LDAP und AD
© Paul Cowan, 123RF
Ein virtuelles Directory mit dem Fedora 389 Directory Server aufsetzen
Auf der Liste
Wie man Linux mithilfe des Fedora 389 Servers in mehrere Active-Directory-Domänen integriert und dabei
Chaining und Pass-Through-Authentication nutzt. Alex Davies, Alessandro Orsaria
Geht es nur um eine einfache Betriebssystemumgebung,
ist es relativ leicht,
ein Identity-Management-System aufzusetzen.
Kommen aber mehrere Betriebssysteme
ins Spiel, werden die Dinge sehr
schnell komplizierter. Dieser Artikel zeigt,
wie man Linux-Clients in eine Umgebung
mit mehreren Domänen des Active Directory
(AD) integriert.
Das Problem kennt verschiedene Lösungen
(siehe dazu den Kasten „Identity-
Management-Lösungen“), von denen
sich der vorliegende Beitrag auf den Fedora
389 Directory Server (389 DS) konzentriert.
Das ist ein hoch skalierbarer
LDAP-Server mit vielen fortgeschrittenen
Features einschließlich Multi-Master-
Replikation, Synchronisierung von Usern
und Gruppen mit dem Active Directory
und der Fähigkeit, andere LDAP-Verzeichnisse
zu virtualisieren.
mit den voneinander verschiedenen Namens-Kontexten
»dc=foo, dc=example,
dc=local« beziehungsweise »dc=bar,
dc=example, dc=local«. Das Ziel ist,
SSH-User zu authentifizieren, deren Benutzername
und Passwort in den Active
Directory-Servern gespeichert sind.
Um die User-Einträge der beiden AD-Server
in einem einzigen Repository zusammenzuführen
(was für die meisten Linux-
Clients Voraussetzung einer erfolgreichen
Suche ist), benutzen wir den Fedora 389
Directory Server. Obwohl es für den 389
DS ein Plugin zum Synchronisieren von
Usern aus einem AD gibt, wollen wir
hier einen anderen Weg verfolgen und
die Chaining sowie die Pass-Through-
Authentication nutzen. Das eröffnet uns
C
M
Y
CM
MY
CY
CMY
K
Architektur
Abbildung 1 gibt einen Überblick über
die Architektur, um die es in diesem
Beitrag geht. Wie man sieht, sind zwei
Windows-Domänen-Controller im Spiel
Abbildung 1: Das hier behandelte Setup besteht aus einem Linux-Client, dem 389 Directory Server und zwei
Active-Directory-Instanzen.
34 Ausgabe 06-2011 Admin www.admin-magazin.de

LDAP und AD
Netzwerk
die Möglichkeit, ein virtuelles Directory
zu erzeugen, das als Proxy zwischen
LDAP-Clients und mehreren LDAP-Servern
agiert. Der Proxy zeigt damit eine
vereinheitlichte Ansicht aller Einträge, so
als würden sie aus einem einzigen LDAP-
Server stammen. Der Directory Server
leitet an ihn gerichtete Anfragen an den
richtigen LDAP/​AD-Server weiter, ohne
dass etwas zu synchronisieren wäre.
Diese Herangehensweise hat einige Vorteile
verglichen mit Windows Sync, beispielsweise
eine geringere Komplexität.
Im Interesse einer größtmöglichen Flexibilität
speichert das hier besprochene
Setup alle User-Einträge (Name, UID,
Shell und so weiter) im Active Directory
und bildet Autorisierungsgruppen im 389
DS. Die Konfiguration wurde mit RHEL 5
und Windows Server 2003 R2 getestet,
sollte prinzipiell aber auch mit anderen
aktuellen Linuxdistributionen funktionieren.
Wem Begriffe wie Suffix, Distinguished
Name oder Attribute wenig sagen,
Abbildung 2: Das Identity-Management für Unix
installieren.
der sollte sich zunächst etwas mit der
Funktionsweise von LDAP beschäftigen.
Der Kasten „LDAP-Primer“ ist vielleicht
ein Ausgangspunkt, für tiefer gehende
Erklärungen empfiehlt sich etwa [1].
AD und Unix-Attribute
Der erste Schritt besteht darin, Microsofts
Active Directory Server zu ertüchtigen,
UNIX UIDs und GIDs, Home Directories
Abbildung 3: Unix-Attribute für einen Benutzer im
Active Directory konfigurieren.
und so weiter zu speichern. Auf einem
Active Directory Server unter Windows
2003 R2 kann man dafür die Identity
Management Unit für Unix installieren,
die es auch für Windows 2008 gibt. Die
Installation des Pakets ist einfach: In der
SCHEDULE OUT NOW!
This years conference topics:
- Mobile computing and communications
- IPv6 (yes, again!)
- Security management and IT governance
- Cloud computing and virtualisation
- Security intelligence
- Topics that have a high impact on IT security
- Design flaws ("defective by design")
WORKSHOPS
CONFERENCE
TH
TH
NOV 15 -16
TH
TH
NOV 17 -18
IN-DEPTH SECURITY

Netzwerk
LDAP und AD
Abbildung 4: Einloggen beim 389 Directory Server
als Directory Manager.
Systemsteuerung klickt man auf »Programme«
»Programme und Funktionen«
»Windows‐Funktionen aktivieren« und
selektiert dort »Identity Management for
Unix« (Abbildung 2). Um das Erzeugen
einer NIS-Domäne braucht sich der Admin
dabei glücklicherweise keine Gedanken
machen.
Nach der Installation ist das LDAP-
Schema, das die AD-Struktur abbildet,
erweitert. Um die Auswirkungen dieses
Schritts zu sehen, editiert man einen
Benutzer, den man auf einer Linux-
Maschine authentifizieren will. Der Dialog
sollte nun einen neuen Tab »Unix‐Attribute«
haben (Abbildung 3).
Den 389 DS installieren
Im Web zirkulieren einige sehr gute Artikel
über die Konfiguration des 389 Directory
Server, aber der beste Startpunkt ist
die Dokumentation des Red Hat Director
Servers [2]. Tatsächlich ist nämlich der
389 DS die Code-Basis für dieses Produkt.
Wer keine Zeit hat, sich durch den umfangreichen
Admin-Guide zu graben, der
ungefähr den Umfang des Telefonbuchs
von Manhatten hat, der findet einige
nützliche How-tos in der Fedora-Dokumentation
[3].
Als Voraussetzung für die Installation muss
entweder das Open JDK 1.6.0 oder Sun
JDK 1.6.0 aufgespielt sein. An das Open
JDK gelangt man einfach via »yum install
Listing 1: »pta.ldif«
01 dn: cn=Pass Through Authentication,cn=plugins,cn=co
jsvs‐2.6.0‐openjdk«.
Benutzt man
mehr als eine
JDK-Version, muss
man zuvor via »alternatives
‐‐config
java« eine passende
einstellen.
Danach installiert
man ebenfalls mit
»yum« das Paket
»389‐ds« nebst allen
Paketen, von
denen es abhängt.
Wenn dieses Paket
kein Bestandteil Directory Manager.
der gerade verwendeten
Linux-Distribution sein sollte,
dasnn hilft zuverlässig das Yum-Repositiory
EPEL weiter (Extra Packages for
Enterprise Linux). Wer das benötigt, installiert
zunächst »epel‐release‐5.3.noarch.
rpm«.
Ist der Directory-Server installiert,
lässt man abschließend das Skript
»setup‐ds‐admin.pl« laufen, das ihn
konfiguriert. Dabei kann eine Warnmeldung
wegen der Anzahl verfügbarer
Filedeskriptoren auftauchen oder eine
Empfehlung, die TCP-Keepalive-Zeit zu
verringern. Diese Warnungen kann man
aber zumindest in einer Testumgebung
ignorieren, ohne dass das irgendwelche
Folgen hätte. Muss man diese Parameter
aber doch anpassen, findet man Näheres
dazu in [5].
Das Skript »setup‐ds‐admin.pl« stellt einige
Fragen, aber in den meisten Fällen
kann man die Default-Antwort bestätigen.
Als Minimum sollte man den
Root-Suffix einstellen, im Beispiel ist es
»dc=example, dc=local«.
Nach der Konfiguration laufen zwei Services:
ein Directory Server (der LDAP-Server)
und ein Administrationsserver, der
sich der Systemeinstellungen annimmt
und eine Reihe Web-Applikationen bereitstellt,
darunter ein Organigramm und
ein Telefonbuch. An diesem Punkt sollte
dafür gesorgt werden, dass diese administrativen
Dienste beim Booten starten:
Abbildung 5: So verbindet man sich mit dem aktuellen Verzeichnis als Benutzer
lässt. Dieser Client ist auch unter Windows
installierbar.
Chaining konfigurieren
Nachdem nun der Directory Server läuft,
muss er dafür konfiguriert werden, LDAP-
Anfragen für »dc=foo, dc=example,
dc=local« beziehungsweise »dc=bar,
dc=example, dc=local« an den jeweils
richtigen AD-Domänen-Controller weiterzuleiten
(Chaining). Dazu öffnet man
einen der frisch installierten 389-Clients
(der auf dem LDAP-Server aber auch auf
einer anderen Maschine laufen kann)
und verbindet sich mit dem Benutzernamen
»cn = Directory Manager« auf Port
9830 wie in Abbildung 4. Danach sollte
sich die Management Konsole öffnen.
Dann selektiert man den Directory Server
im linken Panel wie in Abbildung 5
zu sehen und klickt auf »Open«. Nach
einem Rechtsklick auf den Root-Suffix
»dc=example, dc=local« wählt man
unterhalb des Tab »Configuration« anschließend
»New Root Sub‐Suffix« aus.
In dem Dialog der daraufhin erscheint,
deselektiert man die Checkbox und erzeugt
einen Suffix mit demselben Distinguished
Name wie die AD-Domäne
(Abbildung 6).
nfig
02 nsslapd‐pluginEnabled: on
03 nsslapd‐pluginarg0: ldap://10.1.1.10/
dc=foo,dc=example,dc=local
04 nsslapd‐pluginarg1: ldap://10.2.1.10/
dc=bar,dc=example,dc=local
chkconfig dirsrv on
chkconfig dirsrv‐admin on
Für die Verwaltung des neuen LDAP-Servers
gibt es eine Java-GUI, die sich mit
dem Kommando »389‐console« starten
Abbildung 6: Einen neuen Root-Sub-Suffix erzeugen.
36 Ausgabe 06-2011 Admin www.admin-magazin.de

LDAP und AD
Netzwerk
Abbildung 7: Einen Datenbank-Link ins Active Directory anlegen.
Danach klappt man den neuen Suffix
durch einen weiteren Rechtsklick auf und
wählt »New Database Link«. Der Datenbank-Link
braucht einen Namen und
die IP-Adresse des entfernten Windows-
Controllers. Das Active Directory erlaubt
anonymen Benutzern normalerweise
keinen Lesezugriff, weswegen für jeden
Benutzer, der das Recht zum Suchen haben
soll, Benutzername und Passwort
einzugeben sind. In einer Produktivumgebung
sollte man unbedingt TLS verwenden,
um diese Eingaben zu schützen.
Aus Umfangsgründen verzichten wir auf
eine Darstellung der TLS-Option, sodass
Abbildung 7 die Simple-Bind-Option in
einer Testumgebung zeigt.
Im nächsten Schritt müssen ein paar
Konfigurationsparameter angepasst werden,
damit das Chaining funktioniert.
Dazu öffnet man das Directory-Tab,
klappt die Items »config«, »plugins« und
»chaining‐database« auf und doppelklickt
dann auf den Namen der mit dem AD
verbundenen Datenbank.
Darauf kann man die Option
»nsProxiedAuthorization« in »off«
ändern. Damit weiß der 389 DS, dass er
die Autorisierung via Proxy abschalten
soll und alle Binds für die Verkettung so
ausführen soll, wie auf den vorangegangenen
Screens konfiguriert.
Nun stoppt man den 389 DS mit »service
dirsrv stop«. Jetzt lässt sich die Datei
»/etc/dirsrv/slapd‐*dse.ldif« editieren. In
ihr sucht man nach einer Sektion, die mit
der folgenden Zeile
beginnt:
dn: cn=chaining
database, cn=plugins,U
cn=config
In dieser Sektion
löscht man alle Zeilen,
die »nstransmittedcontrols«
enthalten.
Das schaltet ein
paar potenziell problematische
Controls
ab. Danach sichert
man das File und
startet den Directory
Server neu: »service
dirsrv start«. An diesem
Punkt sollte man
den lokalen 389 DS
nach Usern im AD
fragen können, beispielsweise so:
ldapsearch ‐x ‐b U
dc=example,dc=local U
"(uid=alexd)"
Damit auch die Benutzer in das Resultat
der Anfrage eingeschlossen werden, die
im zweiten Domain Controller gespeichert
sind, wiederholt man einfach den
Prozess und kreiert einen weiteren Sub-
Suffix und einen neuen Datenbank-Link.
Dabei muss man daran denken, dass
auch der zweite Domain Controller über
einen Account verfügen muss, zu dem
Listing 2: »/etc/ldap.conf«
01 scope sub
02 ldap_version 3
03
04 # Do not follow referrals.
05 # Following referrals will send you to all
domains in a AD
06 # forest, which will often take a very long
time for no benefit
07 referrals no
08
09 # Filter for only users/groups with Unix
attributes
10 # (this makes a huge performance difference)
11 nss_base_passwd dc=example,dc=local?sub?&(uidN
umber=*)
12 nss_base_group dc=example,dc=local?sub?&(gidNu
mber=*)
13 nss_initgroups_ignoreusers root,ldap,dbus,xfs,h
aldaemon,nscd,nocpulse
14
15 # If not soft, the machine may hang on boot and
all sorts
man sich verbinden kann, und dass auch
dort das Management für Unix installiert
sein muss.
Ein Problem kann beim Zusammenfügen
der beiden AD-Domänen in ein virtuelles
Directory auftauchen: Unix-Attribute wie
etwa UIDs können in Konflikt geraten.
Das kann man verhindern, indem man
verschiedenen AD-Domänen verschiedene
Bereiche von UIDs zuweist, was
sich erzwingen lässt.
Ein anderes mögliches Problem ist, dass
das Active Directory Resultate in Form
von Seiten zu je 1000 Objekten zurückgibt,
wogegen das Chaining-Plugin des
389 DS das Seitenkonzept nicht kennt.
Das heißt: Sobald es mehr als 1000 User
mit Unix-Attributen im Active Directory
gibt, erhält man auf Suchanfragen nur
noch Teilergebnisse zurück. Dieses Problem
lässt sich beheben, indem man die
»MaxPageSize« im Active Directory heraufsetzt,
wie das in der Microsoft Knowledge
Base beschrieben ist [7].
Konfigurieren der Pass-
Through-Authentifizierung
Bis hierhin wurde erläutert, wie man
User und Gruppen aus mehreren Active
Directory Servern unter Verwendung
Listing 3: »/etc/nsswitch.conf«
01 passwd: files ldap
02 group: files ldap
16 # of other horrid things if it cant talk to a
LDAP server
17 bind_policy soft
18
19 uri ldap://10.0.1.10:389/
20
21 # Base DN to start search
22 base dc=example,dc=local
23
24 # Active Directory mappings
25 nss_schema rfc2307bis
26 nss_map_objectclass posixAccount
organizationalPerson
27 nss_map_attribute homeDirectory
unixHomeDirectory
28 nss_initgroups backlink
29
30 # At the cost of excessive repetition, use
StartTLS or LDAP
31 # over SSL in a production environment
32 ssl no
www.admin-magazin.de
Admin
Ausgabe 06-2011
37

Netzwerk
LDAP und AD
des 389 DS abfragt. Der nächste Schritt
besteht darin, den 389 DS so zu konfigurieren,
dass er Anfragen nach Entries,
die sich nicht in seiner lokalen Datenbank
finden, an den passenden Windows-
Domänen-Controller weiterleitet. Für
diesen Zweck kann das Pass-Through-
Authentication-Plugin (PTA) verwendet
werden, das sehr leicht zu konfigurieren
ist.
Zuerst erzeugt man LDIF-File mit demselben
Inhalt wie »pta.ldif«, so wie es
Listing 1 zeigt (LDIF ist ein Standardformat
für Verzeichniseinträge). Dann führt
man das folgende Kommando aus, um
die Konfigurationsänderungen auf den
389 DS anzuwenden:
LDAP-Primer
Das Lightweight Directory Access Protocol
(LDAP) ist ein offenes Protokoll für die Speicherung,
den Zugriff und die Aktualisierung von
Verzeichnisinformationen. Ein Verzeichnis ist
dabei eine spezielle Art von Datenbank. die für
Leseoperationen optimiert ist. LDAP definiert
das Format der Messages, die Client und Server
austauschen (search, modify, delete, und so
weiter)
Verzeichnisse (Directories) enthalten Einträge
(Entries), die ihrerseits ein oder mehrere
Attribute haben. Abhängig von der Objektklasse
können die Attribute zwingend nötig oder
optional sein. Jedes Attribut hat einen Typ, der
bestimmt, welche Werte das Attribut annehmen
kann. Verzeichnisse sind in einer baumartigen
Struktur organisiert. Die Basis bildet ihr Distinguished
Name (DN), der sich aus relativen DNs
(RDNs) zusammensetzt.
Listing 4: »/etc/pam.d/system‐auth‐ac«
01 # This file is auto‐generated.
02 # But modified by Alex
03 # User changes will be destroyed the next time
authconfig is run.
04 # So please dont :p
05 auth required pam_env.so
06 auth sufficient pam_unix.so nullok
try_first_pass
07 auth requisite pam_succeed_if.so uid
>= 500 quiet
08 auth sufficient pam_ldap.so use_
first_pass
09 auth required pam_deny.so
10
11 account required pam_unix.so broken_
shadow
12 account sufficient pam_succeed_if.so uid
< 500 quiet
13 account [default=bad success=ok user_
ldapmodify ‐x ‐D "cn=Directory Manager" U
‐W ‐f pta.ldif
Danach startet man den Directory Server
neu; »service dirsrv restart«. Damit kann
der 389 DS Anfragen nach den »foo«- und
»bar«-Suffixen an den richtigen Windows
Active Directory Server weiterleiten,
so wie es in der »pta.ldif« definiert ist.
Auch hier lassen wir der Kürze wegen
die TLS-Verschlüsselung weg, legen sie
aber jedem für Produktivumgebungen
ans Herz.
Alles zusammenfügen
Ein Beispiel: »cn=Alex, ou=IT, dc=example,
dc=com« ist der DN eines Eintrags, der einen
Benutzer namens Alex repräsentiert, der zu einer
Organisationseinheit IT gehört und in einem
Directory mit dem Root-Suffix »dc=example,
dc=com« gespeichert ist. Dieser Eintrag könnte
vom Typ Person sein, der noch andere optionale
oder verbindliche Felder enthält wie den Familiennamen
oder auch die Telefonnummer. Er
könnte außerdem zu einer bestimmten Klasse
von Objekten gehören, zum Beispiel der Klasse
»posixAccount«, die ihrerseits noch andere
Attribute definiert, etwa UID und GID oder
»loginShell«.
LDAP-Verzeichnisse lassen sich für die Verwaltung
von Benutzeraccounts in einem zentralen
Repository nutzen und haben in dieser Funktion
andere zentralisierte Repositories wie zum Beispiel
NIS verdrängt.
unknown=ignore] pam_ldap.so
14 account required pam_permit.so
15
16 password requisite pam_cracklib.so try_
first_pass retry=3
17 password sufficient pam_unix.so md5
shadow nullok try_first_pass use_authtok
18 password required pam_deny.so
19
20 # Create home directory
21 session optional pam_mkhomedir.so
skel=/etc/skel/ umask=0077
22 session optional pam_keyinit.so revoke
23 session required pam_limits.so
24 session [success=1 default=ignore] pam_
succeed_if.so service in crond quiet use_uid
25 session required pam_unix.so
26 session optional pam_ldap.so
Ist soweit alles am Platz, kann man die
Linux-Clients konfigurieren. Zuerst vergewissert
man sich, dass die Packages
»nss_ldap« und »pam_ldap« installiert
sind. Danach ändert man die Datei
»/etc/ldap.conf« so wie in Listing 2 gezeigt.
Dieses File enthält die URI des 389
DS, mit der sich der Client verbindet,
den Base Distinguished Name und einige
andere Parameter,
Um den Linux-Clients beizubringen, dass
sie den 389 DS für die Abfrage von Benutzer-
und Gruppeninformationen nutzen,
ändert man »/etc/nsswitch.conf« so wie
in Listing 3. Wenn alles geklappt hat
sollte das Kommando »getent passwd«
eine vollständige Liste der lokalen und
AD-User liefern.
Im folgenden Schritt kann man die Linux
Clients so einstellen, dass sie den 389 DS
außerdem für die Authentifizierung benutzen.
Dafür ist das PAM-LDAP- Modul
zuständig, das auf den meisten von Red
Hat abstammenden Distributionen die
Datei »system‐auth‐ac« als Konfigurationsinterface
zu den Service-Daemons
nutzt. Listing 4 zeigt ein Beispiel dieser
Datei, die außerdem das Modul »pam_
mkhomedir« nutzt, das bei einem Login
automatisch ein Homedirectory erzeugt,
sollte es fehlen. Jetzt sollte ein Login
mit dem Linux-Client möglich sein, wenn
man dafür einen Account verwendet, der
in einem der beiden Active Directories
gespeichert ist.
Als optionalen Schritt könnte man jetzt
noch den NSCD-Daemon konfigurieren,
der die Performance verbessert, indem
er User und Gruppen cachet. NSCD lässt
sich wie folgt einschalten und starten:
chkconfig nscd on
service nscd start
Von Authentifizierung zu
Autorisierung
Bis hierhin haben wir beschrieben, wie
sich der 389 DS nutzen lässt, um Benutzerinformationen
aus verschiedenen
Active Directories zu extrahieren und Anfragen
an den richtigen AD-Server weiterzuleiten.
Diese Konfiguration ist nützlich,
wenn sich alle User an allen Servern anmelden
dürfen, aber das ist selten der
Fall. Typischerweise dürfen sich einige
Benutzer nur an bestimmten Maschinen
einloggen und deshalb braucht es einen
Mechanismus, um festzustellen, welche
38 Ausgabe 06-2011 Admin www.admin-magazin.de

LDAP und AD
Netzwerk
Benutzer für welche Server autorisiert
sind. Um das zu erreichen bietet »pam_
access« einen einfachen Weg, um eine
Zugriffssteuerung einzurichten. Für jeden
Linux-Client gilt es festzulegen, welcher
Benutzer auf ihn zugreifen darf. Im 389
DS sind dann entsprechende Gruppen
einzurichten, auf die das PAM-Modul
zugreift. Sie lassen sich entweder über
die grafische Oberfläche oder die Kommandozeile
anlegen. Listing 5 zeigt das
Beispiel eines LDIF-Files, das ein Gruppenobjekt
beschreibt, dessen Mitglieder
durch das Attribut »uniqueMember«
identifiziert werden. Sobald das File »linuxadmin.ldif«
existiert, erzeugt das folgende
Kommando einen neuen Eintrag
für ein Gruppenobjekt auf dem 389 DS:
ldapmodify ‐x ‐D "cn=Directory Manager" U
‐W ‐f linuxadmins.ldiff
Nun kann man festlegen, welche Benutzer
und Gruppen sich an welcher
Maschine anmelden dürfen. Sie hinterlegt
man dabei im File »/etc/security/
access.conf« (Auszug in Listing 6). Die
ersten beiden Zeilen erlauben es »root«
und »joe«, sich vom lokalen System und
überall her einzuloggen. Die dritte Zeile
gestattet es der Gruppe »LinuxAdmins«
auf den Server »server1.example.local«
aus dem Netz 10.1.1.0/​24 zuzugreifen.
Die vierte Zeile verbietet alle anderen
Zugriffe.
Der letzte Schritt besteht darin, PAM so
zu konfigurieren, dass es »access.conf«
verwendet. Das geht einfach, indem
man die folgende Zeile in »/etc/pam.d/
systen‐auth‐ac« ergänzt:
account required pam‐access.so
Zugabe Failover
Was aber, wenn einer der Windows-Domänen-Controller
ausfällt? Glücklicherweise
ist es sehr einfach, das System
ausfallsicher zu machen. Dazu braucht
es zuerst einen weiteren 389 Directory
Server mit identischer Konfiguration. Auf
ihm schaltet man die Replikation ein und
synchronisiert so alle lokalen Objekte.
Zusätzlich müssen die Chaining- und
Pass-Through-Plugins so konfiguriert
werden, dass sie mehrere AD-Server im
Zuge eines Failovers unterstützen. Das
geht wie Abbildung 7 zeigt, indem die
IP-Adresse eines zweiten AD-Servers unter
»Failover Servers« eingetragen wird.
Auch das Pass-Through-Plugin unterstützt
mehrere Authentication-Server als
mit Leerzeichen separierte Liste.
Schließlich lassen sich die Linux-Clients
so konfigurieren, dass sie ihre Benutzer
und Gruppen von einem anderen 389 DS
empfangen, sollte der erste ausgefallen
sein. Dazu spezifiziert man eine alternative
URI in der »/etc/ldap.conf«.
Fazit
Die Integration einer Identity-Management-Lösung
mit Linux- und Windowskomponenten
ist ein einigermaßen störrisches
Biest. Dieser Artikel stellte aber einen
erfolgversprechenden Ansatz für ein
solches Projekt vor. So hilft er hoffentlich,
die Infrastruktur einer in ein Active Directory
integrierten Linux-Authentifikation
einfach zu halten. (jcb)
n
Infos
[1] Gerald Carter: LDAP System Administration;
O’Reilly, 2003
[2] Red Hat Directory Server Documentation:
[http:// www. redhat. com/ docs/ manuals/​
dir‐server]
[3] Fedora 389 DS Documentation:
[http:// directory. fedoraproject. org/ wiki/​
Documentation]
[4] EPEL: [http:// download. fedora. redhat. com/​
pub/ epel/ 5]
Identity-Management-Lösungen
Typischerweise benutzen Linux-Clients das NSS-
LDAP-Modul, um von LDAP-Servern Informationen
über Benutzer und Gruppen abzufragen.
Dieses Modul bietet allerdings keinerlei Möglichkeiten,
um mehrere LDAP-Server zu kontaktieren
und die zusammengefassten Ergebnisse
zurück an den Client zu übermitteln. Für diese
Aufgabe gibt es stattdessen drei erfolgversprechende
Lösungsansätze: Replikation, virtuelle
Directories und spezielle Clients.
Viele Directory Server, darunter OpenLDAP, 389
DS oder das Oracle Internet Directory haben eingebaute
Features für eine Synchronisation von
Einträgen aus einem Active Directory. Obwohl
die Replikation von User- und Gruppenobjekten
in der Regel gut funktioniert, hat sie doch einige
Beschränkungen. So lässt sich nur eine
kleine Untermenge der Attribute replizieren.
Besonders die Synchronisation von Passwörtern
aus dem AD kann mühsam sein, speziell in
[5] Fedora 389 DS Performance Tuning:
[http:// directory. fedoraproject. org/ wiki/​
Performance_Tuning]
[6] Fedora 389 DS Download page:
[http:// directory. fedoraproject. org/ wiki/​
Download]
[7] How to view and set LDAP policy
in Active Directory:
[http:// support. microsoft. com/ kb/ 315071]
[8] Likewise Open:
[http:// www. likewiseopen. org]
Die Autoren
Alex Davies und Alessandro Orsaria arbeiten
beide bei PartyGaming, einer großen Online-
Spielefirma, als IT Infrastruktur-Architekt
beziehungsweise ‐Manager in London und in
Gibraltar.
Listing 5: »linuxadmins.ldif«
01 dn: cn=LinuxAdmins,ou=Groups,dc=example,dc=local
02 gidNumber: 500
03 objectClass: top
04 objectClass: groupOfUniqueNames
05 objectClass: posixgroup
06 cn: LinuxAdmins
07 uniqueMember: CN=Alessandro Orsaria,CN=Users,DC=bar,D
C=example,DC=local
08 uniqueMember: CN=Alex SQ. Davies,CN=Users,DC=foo,DC=e
xample,DC=local
Listing 6: »/etc/security/access.conf«
01 + : root : LOCAL
02 + : joe : ALL
03 + : LinuxAdmins@server1.example.local : 10.1.1.0/24
04 ‐ : ALL : ALL
großen Umgebungen. Als eine Alternative bietet
sich immer die Umleitung der Authentification
Requests via SASL oder LDAP Binds an, wie in
diesem Beitrag beschrieben.
Wo die Replikation nicht möglich oder angezeigt
ist, kommen virtuelle Directories infrage, die als
Proxies ein zentralisiertes Repository bilden.
Der 389 DS bietet zwar einige Ansätze für virtuelle
Directories, doch fehlen ihm fortgeschrittenere
Features wie das Attribut-Mapping.
Schließlich enthalten spezielle Clients Samba/​
Winbind, um Windows-Controller zusammenzuschließen.
Dazu gehören Softwareprodukte wie Likewise
Enterprise, das es auch in einer freien Open-
Source-Version gibt [8]. Likewise hat den
zusätzlichen Vorteil, dass es die AD Gruppen-
Policen integriert, um Identity-Management-
Aspekte von Linux, Windows und Mac zu
kontrollieren.
www.admin-magazin.de
Admin
Ausgabe 06-2011
39

Datenbanken
DB-Duell
© dimaberkut, 123RF
PostgreSQL oder MySQL: Wer skaliert besser?
Das Datenbankduell
Die Konkurrenz von MySQL und PostgreSQL ist so alt wie die Datenbanken selbst und kennt keinen endgültigen
Sieger. Nichtsdestotrotz ist das Kräftemessen immer wieder reizvoll und aufschlussreich. Das ADMIN-Magazin
arrangierte deshalb jetzt ein Duell, das es so noch nicht gab. Jens-Christoph Brendel
Um beim großen Datenbankduell MySQL
versus PostgreSQL einerseits für maximale
Fairness und andererseits dafür zu
sorgen, dass die Zweikämpfer wirklich
alle Register ziehen und sich in Bestform
messen können, hat sich die ADMIN-
Redaktion mit erfahrenen Sekundanten
verstärkt. Jeder Beistand steuerte für
„seine“ Datenbank die besten Insider-
Tuning-Tipps bei. Im Fall von MySQL
half dankenswerterweise Oli Sennhauser,
früherer Senior Database Consultant für
MySQL bei Sun und heute als selbstständiger
und neutraler MySQL-Berater mit
der eigenen Firma FromDual unterwegs.
Bei PostgreSQL unterstützte die Redaktion
Susanne Ebrecht, PostgreSQL-Entwicklerin
und unter anderem Mitbegründerin
der europäischen PostgreSQL User
Group. Heute ist sie beim PostgreSQL-
Spezialisten 2ndQuadrant unter Vertrag.
Mithilfe dieser beiden Datenbankprofis
sollte sich erweisen, was jeder der Kontrahenten
im untersuchten konkreten
Fall zu leisten vermag. Ein endgültiges
Ergebnis war von vornherein nicht zu
erwarten, denn mit anderen Parametern –
etwa einem anderen Workload oder einer
anderen Datenbankgröße – würden sich
wahrscheinlich andere Resultate ergeben.
Deshalb ging es auch nicht vordergründig
um Sieg oder Niederlage, sondern vor allem
um den Weg zum Ziel: Was muss ich
messen? An welchen Stellschrauben kann
ich drehen? Welchen Effekt hat welche
Maßnahme? Welche Leistungssteigerung
lassen die beiden Datenbanken relativ zu
ihrer Default-Konfiguration zu? Wer profitiert
besser von schneller Hardware?
Schließlich bleibt anzumerken, dass
Geschwindigkeit nicht das einzige Kriterium
sein kann, wenn man zwischen
den beiden Datenbanken zu wählen hat.
Da geht es außerdem häufig um Applikationen,
die die Datenbank unterstützen
können soll, um die Administrierbarkeit
und eventuell bereits vorhandenes Knowhow
der einen oder anderen Sorte, um
Ausfallsicherheit und damit um solche
Dinge wie Clustering und Replikation,
um Supportfragen oder Migrationsmöglichkeiten
und manches mehr, das leicht
wichtiger sein kann als ein paar Prozente
mehr Performance. Nichtsdestotrotz ist
die Performance ein nicht unwichtiger
Faktor in der Gesamtschau.
Zu guter Letzt: Das SQL in den Prozeduren
des Benchmarks ist als gegeben
hinzunehmen – in der Praxis und mit
dem nötigen Know-how läge aber gerade
dort das größte Tuning-Potenzial, denn
was durch ungünstig gestaltete Abfragen
oder ein mangelndes Datenbank-Design
an Geschwindigkeit verloren geht, das
lässt sich kaum durch trickreich konfigurierte
Einstellungen wieder aufholen.
Der Benchmark
Für den Datenbankvergleich verwendete
das ADMIN-Magazin den Benchmark
DBT-2 [1], der ursprünglich einmal von
den Open Source Development Labs entwickelt
wurde (von dem er heute aber
leider nicht mehr gepflegt wird). Der
Vorzug dieses Benchmarks ist, dass er
nicht nur einen relativ komplexen und
vielfältig konfigurierbaren OLTP-Workload
erzeugt, sondern darüber hinaus
auf eine anerkannte Methodik zurückgreift.
Er benutzt nämlich dasselbe Sys-
40 Ausgabe 06-2011 Admin www.admin-magazin.de

DB-Duell
Datenbanken
tem wie der Industriestandard TPC-C,
dem er nachempfunden ist. Zwar sind die
resultierenden TPC-C- und DBT-2-Werte
nicht direkt vergleichbar, doch prinzipiell
absolvieren die Datenbanken in beiden
Fällen dasselbe Prozedere.
Die Installation des Benchmarks hält allerdings
ein paar Fallstricke in Gestalt
kleinerer Fehler bereit: Da ist mal die
Syntax in SQL-Skripten nicht korrekt, mal
steht die Bourne-Shell in der Shebang-
Line, wo es die Bash sein müsste, mal
finden sich fest verdrahtete Pfade in den
Skripten, die ins Nirgendwo weisen und
so weiter. Alles nichts, was ein einigermaßen
geübter Admin nicht fixen könnte,
aber es kostet Zeit. Einzelne Fehler soll
allerdings eine spätere Version bereinigen.
Die Redaktion hatte vor einiger Zeit
sogar versucht, die ehemaligen Entwickler
wieder für ihr verwaistes Projekt zu
interessieren – ohne Erfolg.
Wenn der Benchmark läuft, simuliert er
eine Großhandelsanwendung, bei der
eine Anzahl Mitarbeiter an Terminals
Transaktionen auslösen, die Bestellungen,
Auslieferungen, die Zahlungsabwicklung,
die Überwachung der Bestellabwicklung
und die Überwachung des
Lagerbestands umfassen. Diese Transaktionen
werden in einem festgelegten Mix
in der Datenbank gestartet, am häufigsten
„New Order“ gefolgt von „Payment“,
„Order Status“, „Delivery“ und „Stock
Level“. Die zentrale Messgröße sind die
neuen Bestellungen pro Minute, die das
Datenbanksystem bewältigen kann.
Die Umgebung, in der sich das alles
abspielt, besteht aus Warehouses. Zu
jedem Warehouse gehören 10 Districts.
Jeder District hat 3000 Kunden. Jedes
Warehouse verwaltet 100000 Artikel.
Jede zehnte Bestellung muss an ein anderes
Warehouse abgegeben werden, weil
nicht immer alle Artikel am Lager sind.
Pro Warehouse starten per Default zehn
Terminalprozesse.
Alle Transaktionen des Benchmarks sind
als Stored Procedures in der Datenbank
hinterlegt. Den Benchmark steuern zur
Laufzeit zwei Software -Komponenten:
Zuerst öffnet ein Client eine vorzugebende
Anzahl Datenbankverbindungen,
was während einer Einschwingphase
abgewartet wird. Danach löst ein Driver
über den Client die Transaktionen aus,
wobei er entweder eine Think Time zwi-
Abbildung 1: Tuningeffekte verschiedener Setups bei MySQL (Erläuterungen im Text).
schen zwei Transaktionen einbaut oder
nicht.
Der Benchmark ist in weiten Grenzen
konfigurierbar. Insbesondere kann man
einstellen
n die Anzahl Warehouses (der zentrale
Skalierungsfaktor) (-w)
n die Anzahl paralleler Datenbankverbindungen
(-c)
n die Laufzeit (-d)
n ob eine Think Time verwendet werden
soll oder nicht (-n)
Bei den hier diskutierten Ergebnissen
haben wir immer auf die Think Time
verzichtet, weil andernfalls die Belastungsgrenze
erst bei einer hohen Anzahl
Warehouses erreicht würde, was aber
gleichzeitig eine ebenfalls hohe Anzahl
Terminalprozesse mit sich brächte. Dabei
würde die Konkurrenz dieser Terminal-
Threads mit einem übermäßigen Gewicht
in das Ergebnis eingehen.
Alle hier wiedergegebenen Messwerte
sind Mittelwerte, die Ausreißer nivellieren.
Das ADMIN-Magazin hat jeweils
mindestens drei Durchläufe pro Setup
gemessen, manchmal auch wesentlich
mehr. Die Tester versuchten, jede Datenbank
nacheinander durch eine Reihe von
Tuningmaßnahmen zu beschleunigen. Erfolglose
Versuche übergeht dieser Beitrag,
der im Folgenden nur die Datenbankoptionen
vorstellt, die zu einer signifikanten
Geschwindigkeitssteigerung geführt
haben oder die zumindest unter anderen
Umständen sicher einen positiven Effekt
gehabt hätten. Die Performanceverbesserungen
machen sich normalerweise an
mindestens drei Mess-Serien fest, bei der
die Tester die Last ohne Think Time von
1 bis 20 Warehouses ansteigen ließen und
nach der Einschwingphase zum Aufbau
der Datenbankverbindungen den Lasttest
jeweils fünf Minuten laufen ließen.
Start mit MySQL
Die grobe Marschrichtung für das Tuning
muss bei beiden Datenbanken sicher
lauten: Plattenzugriffe einsparen. Davon
produziert der Benchmark reichlich, und
sie sind jeweils um Größenordnungen
langsamer als die Hauptspeicheroperationen,
mit denen sie sich substituieren
lassen. Beide Datenbanken bieten eine
Vielzahl von Stellschrauben an, unter
MySQL liefert beispielsweise »SHOW
GLOBAL VARIABLES;« einen Überblick.
Die Liste ist lang, doch keine Angst: Für
das Tuning sind nur eine Handvoll Parameter
wirklich interessant.
Um einen Ausgangswert als Vergleichspunkt
zu bestimmen, maß die Redaktion
zuerst die Performance mit der Konfiguration,
die jeweils die Paketinstallation
der Datenbank mitbrachte. Danach
visierte sie im Fall von MySQL verschiedene
Stoßrichtungen an.
Zuerst das Parameter-Tuning als die kostengünstigste
Variante, weil dafür nur Datenbankeinstellungen
zu ändern sind und
nichts neu zu installieren ist. Zweitens
www.admin-magazin.de
Admin
Ausgabe 06-2011
41

Datenbanken
DB-Duell
Abbildung 2: Beide Datenbanken – maximal getunt – mit und ohne SSD als Massenspeicher für die Datenfiles.
Die Werte bei Verwendung einer SSD sind noch einmal wenigstens doppelt so hoch.
sollte aber auch eine aktuellere MySQL-
Version getestet werden, als sie das Repository
des verwendeten Ubuntu LTS 10.04
zu bieten hat. Theoretisch wären drittens
auch MySQL-Ableger wie MariaDB, der
Percona-Server oder Drizzle einen Versuch
wert gewesen, allerdings können
sich hier in der Praxis leicht höhere Hürden
ergeben, etwa in Form zusätzlicher
Kosten oder weil damit der für MySQL
eingekaufte Support verloren ginge. Diesen
Weg hat die Redaktion deswegen
nicht weiter verfolgt.
Zudem zwang der Aufwand zu einer Beschränkung.
Allein für beide Datenbanken
zusammen startete der Benchmark
an die 2000 Mal. Dabei lief er im Mittel
zwischen sieben und acht Minuten,
macht insgesamt um die 250 Stunden
oder mehr als zehn Tage rund um die
Uhr. Viertens – und das haben wir wieder
praktisch getestet – wollten wir wissen,
was es ausmacht, die zunächst eingesetzte
Festplatte gegen eine schnelle SSD
zu tauschen.
Alle Messungen unternahmen wir auf
ein und derselben Hardware, einem Dell
PowerEdge T110 mit zwei Intel Dual-Core
Prozessoren i3 530, die mit 2,93 GHz
getaktet wurden. Der Server war mit 8
GByte RAM ausgestattet. Als Massenspeicher
diente eine interne 300-GByte-
Platte von Western Digital beziehungsweise
eine Intel SSD der 320er-Serie (160
GByte), auf die wir versuchsweise die
Data Directories der Datenbanken verleg-
ten. Das System war zum Messzeitpunkt
ausschließlich mit den Benchmarks beschäftigt.
Tuning, konkret
Die erste Aktion im Falle von MySQL war
der Umstieg von dem schon leicht angestaubten
5.1.41 (Abbildung 1, Kurve A)
aus dem Ubuntu-Repository auf die aktuelle
Version 5.5.15 (Abbildung 1, Kurve
B). Die jüngere Datenbank war aus dem
Stand und mit der Standard-Konfiguration
gut doppelt so schnell, was auch daran
liegt, dass hier einige Parameter von
vornherein großzügiger eingestellt waren
als beim alten MySQL. Mit Tuning lässt
sich zwar auch die alte Version merklich
beschleunigen, die neuere behält aber
die Nase vorn, weswegen alle folgenden
Benchmarks mit der jüngeren Datenbank
absolviert wurden. Gelegentliche
Upgrades lohnen bei MySQL nach diesen
Zahlen sicherlich.
Im zweiten Schritt stand eine Vergrößerung
des Innodb-Bufferpools an. Gehandelt
wird für den zugehörigen Parameter
»innodb_buffer_pool_size« ein Richtwert
von 80 Prozent des vorhandenen RAM
oder – wenn man viel RAM zur Verfügung
hat und die Datenbank kleiner ist
– so viel RAM, wie es dem Wert Datenbankgröße
plus 10 Prozent entspricht.
Die alte Datenbankversion sieht allerdings
per Default nur mickrige 8 MByte
vor, die neuere immerhin 128 MByte.
Wichtig ist auf jeden Fall, ausreichend
Speicher übrig zu behalten, um sowohl
die Bedürfnisse des Betriebssystems (Page
Tables, Socket Buffers, etc.) als auch die
anderer MySQL-Konsumenten (Query
Cache, temporäre Tabellen, Threads,
Key Buffer und so weiter) befriedigen zu
können. Der Testserver verfügte über 8
GByte RAM, die Benchmark-Datenbank
war initial um die 4 GByte groß, also
erwiesen sich 5 GByte für den Innodb-
Bufferpool als gute Wahl. Sie brachte
prompt einen Leistungssprung um 88
Prozent (Abbildung 1, Kurve C) gegenüber
der ungetuneten Konfiguration des
neueren MySQL.
Die dritte Maßnahme betraf das Innodb-
Logfile. Will man dessen Größe ändern,
ist es übrigens wichtig, bei heruntergefahrener
Datenbank die alten Logs zu
löschen – sonst passen sie anschließend
nicht zur neu konfigurierten Größe, und
MySQL verweigert den Start. Hat man sie
dagegen entfernt, legt sie die Datenbank
beim Booten mit den neuen Proportionen
wieder an.
Außerdem ist zu bedenken, dass ein stark
vergrößertes Logfile das Wiederanlaufen
nach einem Crash deutlich ausbremsen
kann, weil die Datenbank zunächst das
gesamte Log nach Transaktionen durchsucht,
die nur im Speicher ausgeführt
wurden, es aber noch nicht auf die Platte
geschafft haben. Die Dauer dieser sogenannten
Redo-Phase ist proportional
zur Größe des Logs, hängt aber ansonsten
von so vielen weiteren Faktoren ab,
dass man Werte für eine konkrete Datenbank
am besten experimentell ermittelt.
Schließlich gibt es eine weitere Obergrenze:
Die Größe aller Logfiles zusammen
muss unter 4 GByte bleiben. Alle
diese Erwägungen einbeziehend fiel die
Wahl auf ein 1 GByte großes Innodb-Log.
Der Erfolg war ein Leistungszuwachs von
weiteren 52 Prozent (Abbildung 1, Kurve
D) gegenüber der Vorversion der Konfiguration.
Die vierte Tuning-Maßnahme führt in einen
Grenzbereich, denn sie tangiert die
Sicherheit der Datenbank. Per Default ist
der Parameter »flush_log_at_trx_commit«
auf »1« eingestellt, was bedeutet, dass
MySQL das Transaction-Log jedesmal auf
die Platte schreibt, wenn eine Transaktion
committet wird. Damit kann keine
Transaktion verloren gehen, ganz egal,
42 Ausgabe 06-2011 Admin www.admin-magazin.de

DB-Duell
Datenbanken
ob MySQL oder das Betriebssystem abstürzt.
Für OLTP-Workloads mit vielen
Schreiboperationen auf den Massenspeicher
kann das aber eine Bremse sein, die
sich lösen lässt, wenn man den Parameter
ändert. Setzt man ihn auf »0« schaltet
man den Log-Flush nach Commit ganz
ab, setzt man ihn auf »2«, wandern die
Log-Daten zwar ebenfalls nicht sofort auf
die Platte, aber immerhin in den Cache
des Betriebssystems. Damit überlebt die
Transaktion einen Datenbank-Crash,
ginge aber bei einem Betriebssystemabsturz
verloren. Wir haben uns für diesen
letzteren Fall als Kompromiss entschieden,
das ergab gegenüber der Vorgänger-
Konfiguration noch einmal mehr als eine
Verdoppelung der Performance (Abbildung
1, Kurve E).
Der fünfte Schritt dreht sich um den Parameter
»innodb_buffer_pool_instances«,
mit dessen Hilfe sich der Buffer Pool in
separate Regionen unterteilen lässt, was
wiederum die Bearbeitung konkurrierender
Lese- und Schreiboperationen
begünstigt. Für den Wert von »innodb_
buffer_pool_instances« liest man verschiedene
Empfehlungen. Unser Experte
empfahl, ihn auf die Anzahl Cores zu
setzen. Eine andere Empfehlung, »(innodb_buffer_pool_size
in GB + number
of CPUs)/2«, wäre im vorliegenden Fall
ungefähr auf dasselbe hinausgelaufen
und auch den Hinweis von MySQL selbst,
jeder Teil des Bufferpools solle minimal
1 GByte betragen, erfüllt die gewählte
Einstellung nach der Anzahl Cores. Das
Ganze brachte wiederum eine deutliche
Steigerung (Abbildung 1, Kurve F).
Diese Kurve fällt – wie prinzipiell alle anderen
– mit steigender Anzahl Warehouses
wieder deutlich ab, weil am oberen
Ende unseres Belastungsspektrums mit
bis zu 200 Threads mehr parallele Aktionen
ausgeführt werden als der maximalen
Performance zuträglich sind.
Sicher nicht zufällig fällt das Maximum
der meisten Leistungskurven in einen Bereich,
in dem 30 bis 60 Terminal-Threads
zeitgleich laufen.
Aus einer anderen Welt scheinen erwartungsgemäß
die Resultate, die sich einstellen,
wenn man das Data Directory
auf eine SSD (Abbildung 2) verlegt. In
der Spitze schnellen sie bis fast an die 20
000 New Orders pro Minute hoch, also
noch einmal mehr als doppelt so viel, wie
mit allen bisherigen Tuningmaßnahmen
zusammen maximal zu erzielen war. Das
liegt einfach daran, dass hier mit der
Festplatte die langsamste Komponente
eliminiert wurde. Unter dem Strich bleibt
bis hierhin zu vermerken: Das aktuelle
MySQL ließ sich in der Spitze auf ungefähr
die zehnfache Leistung der ungetuneten
älteren Version beschleunigen, die
wir als Baseline vermessen hatten. Mit
einer SSD ergeben sich mehr als 20fach
höhere Leistungswerte.
PostgreSQL im Rennen
Weiter ging es mit PostgreSQL. Auch hier
haben wir zunächst die Version vermessen,
die das Ubuntu-Repository mitbringt,
das war das Release 8.4.8 (Abbildung
4 Kurve A). Schon der Fairness halber
wechselten wir dann aber auch hier zum
derzeit aktuellen PostgreSQL 9.1.0 (Abbildung
4, Kurve B). Diese Version war
zwar nicht sehr viel schneller als der Vorgänger,
gewann aber aus dem Stand den
Wettbewerb der Default-Konfigurationen.
Das ältere Postgres ist mit den Standard-
Einstellungen ungefähr so schnell wie
das ungetunete neuere MySQL, aber das
neueste PostgreSQL mit Standardkonfiguration
kann noch einmal leicht zulegen
und diese Konkurrenz für sich entscheiden
(Abbildung 3).
Der Grund dafür dürfte sein, dass PostgreSQL
beim Initialisieren der Datenbank
während der Installation aktiv überprüft,
auf welche Werte einige Parameter gesetzt
werden können, ohne dass sie in
Konflikt mit dem Betriebssystem geraten.
MySQL spart sich diesen Check und verwendet
in seiner Default-Konfiguration
stattdessen so kleine Werte, dass ein Konflikt
unwahrscheinlich ist. Dadurch ist es
ohne Anpassung aber auch langsamer,
weil es den vorhandenen Spielraum nicht
ausnutzt. Zudem kann PostgreSQL unter
Umständen einen weiteren kleinen Vorteil
ausspielen: Seine Stored Procedures
für den Benchmark sind kompilierte C-
Programme, wogegen MySQL für denselben
Zweck SQL-Skripte verwenden muss,
die der Server interpretiert. Allerdings ist
der Unterschied nicht sehr groß, und das
Ergebnis sagt auch noch nichts über die
Steigerungsfähigkeit im Laufe des folgenden
Tunings – es bleibt also spannend.
PostgreSQL beschleunigen
Die nächste Maßnahme beim Postgres-Tuning
sollte gar nicht direkt der Datenbank
gelten, sondern dem Betriebssystem. Weil
PostgreSQL auf den Read-Ahead-Buffer
des Betriebssystems baut, kann es sich
lohnen, den zu vergrößern – per Default
setzt ihn Ubuntu nur auf den niedrigen
Abbildung 3: Wettbewerb der Default-Konfigurationen verschiedener Datenbank-Versionen. Das erst wenige
Wochen alte PostgreSQL 9.1 hat hier die Nase vorn. MySQL liegt in der aktuellsten Version ungefähr auf dem
Niveau des älteren Postgres.
www.admin-magazin.de
Admin
Ausgabe 06-2011
43

Datenbanken
DB-Duell
Abbildung 4: Diverse PostgreSQL-Setups im Vergleich (Erläuterungen im Text).
Wert »256«. Früher bewerkstelligte man
diese Änderung mit »hdparm«, aber der
Kernel 2.6 bringt jetzt ein eigenes Kommando
dafür mit »blockdev ‐‐setra 4096
/dev/sda« (Device und Anzahl Blöcke
sind Beispielwerte). Allerdings überwiegen
bei dem Workload des hier verwendeten
Benchmarks Schreiboperationen,
sodass sich nach der Anpassung kein
merklich positiver Effekt einstellte. Wo
die Verhältnisse andere sind, sollte man
das fragliche Kommando in »rc.local«
oder einem anderen Init-Skript unterbringen,
sonst ist die Einstellung beim
nächsten Booten futsch.
Auch die folgende Maßnahme hängt engt
mit Linux zusammen. Will man nämlich
der Datenbank mehr Shared Memory zukommen
lassen (hauptsächlich in Form
von Shared Buffers), dann darf dessen
Menge nicht das im Betriebssystem definierte
Limit überschreiten – andernfalls
würde die Datenbank nicht starten, weil
sie dann versucht, mehr Speicher zu allozieren,
als sie erhalten kann. Einer Faustregel
zufolge sollte man ein Viertel des
RAMs für die Shared Buffers reservieren,
im vorliegenden Fall also 2 GByte. Dafür
kann man so vorgehen:
n Zunächst editiert man »/etc/sysctl.
conf« und ergänzt dort die Zeilen
»kernel.shmmax = 4190150656« und
»kernel.shmall = 10229896«.
n Danach kann man diese Einstellungen
per »sysctl ‐p« laden (und müsste das
ebenfalls nach jedem Booten tun).
Der Betriebssystem-Parameter »SHM-
MAX« ist auf genau vier GByte eingestellt.
n Jetzt kann man in der »postgresql.
conf« kongruente Puffergrößen für
Caches konfigurieren: »max_connection
= 25« und »shared_buffers =
2GB« (vorher: 32 MByte). Damit PostgreSQL
weiß, wie viel Cache es vom
Betriebssystem erwarten kann, setzt
man schließlich noch den Wert von
»effective_cache_size« auf »RAM minus
Shared Buffers«, im vorliegenden
Fall »effective_cache_size = 6GB«.
Ein wenig zur Verwunderung der Tester
hatte diese Maßnahme allerdings ebenfalls
keinen deutlichen Einfluß auf die
Postgres-Performance (Abbildung 4,
Kurve C). Zwar nutzt die Datenbank den
Cache mit einer ordentlichen Trefferquote
(94 Prozent), doch spielt er wahrscheinlich
wegen der überwiegenden Schreiboperationen
keine entscheidende Rolle.
Dafür fiel auf, dass PostgreSQL offenbar
sensibler auf die im Zuge der
Benchmarks steigende Datenbankgröße
reagiert. Ein Leistungsabfall mit längerer
Testdauer war auch bei MySQL zu beobachten
– PostgreSQL aber produzierte
mit einer jungfräulichen Datenbank regelmäßig
Ausreißer mit deutlich erhöhten
Transaktionszahlen, die sich aber bereits
nach einigen Dutzend Testläufen, in deren
Verlauf sich die Datenbank vergrößerte,
wieder auf den vorigen Mittelwert
einpendelten.
Aus diesen Grund haben wir MySQL
einmal nach rund 700 Durchläufen und
PostgreSQL mehrmals nach je rund 350
Durchläufen komplett resettet und die
Testdatenbank neu aufgesetzt. Nach jeder
Serie wäre eine solche Aktion aber
wegen des damit verbundenen Aufwands
undurchführbar und mit Blick auf die
Verhältnisse in der Praxis auch unrealistisch
gewesen.
Der nächste Tuning-Versuch galt noch
einmal der Speicherverwaltung. Über
die Variable »work_mem« lässt sich die
Menge an Memory konfigurieren, die
für interne Sortieroperationen und Hash-
Tabellen zur Verfügung stehen soll. Der
Default beträgt ein Megabyte, die Tester
erhöhten den Wert auf 24 MByte. Via
»maintanance_work_mem« lässt sich außerdem
vorherbestimmen, wie viel Speicher
maximal für Operationen wie »VA-
CUUM«, »CREATE INDEX« oder »ALTER
TABLE ADD FOREIGN KEY« verfügbar
ist. Der Defaultwert beläuft sich hier auf
16 MByte, für die Benchmarks wurde er
auf 512 MByte gesteigert. Die Effekte der
beiden Maßnahmen verloren sich allerdings
wieder im statistischen Rauschen
(Abbildung 4, Kurve D).
Log-Tuning
Nun versuchte das Benchmark-Team,
den Hebel beim Logging anzusetzen.
An einem sogenannten Checkpoint garantiert
PostgreSQL, dass alle Heap- und
Index-Datendateien auf den neuesten
Stand gebracht und alle geänderten Speicherseiten
auf die Festplatte geschrieben
worden sind. Nach einem Crash würde
die Recovery-Prozedur einen solchen
Checkpoint suchen, von dem sie weiß,
dass alle Operationen, die vorher stattgefunden
haben, auf der Festplatte gelandet
sind. Wie oft der Background Writer-Prozess
diese Checkpoints auslöst, ist einstellbar.
Eine Methode ist, die Anzahl der
jeweils 16 MByte großen Log-Segmente
(»checkpoint_segments«) vorzugeben,
nach denen jeweils ein Checkpoint geschrieben
werden muss. Voreingestellt
sind drei. Dieser Wert ist besonders bei
vielen Schreiboperationen sehr klein.
Deshalb wurde er jetzt auf 32 gesetzt,
was zwar möglicherweise die Zeit für ein
Crash Recovery erhöht, aber etliche der
I/​O-intensiven Checkpoints einspart.
Diese Maßnahme hatte einen deutlichen
Erfolg: Die Performance steigerte sich um
44 Ausgabe 06-2011 Admin www.admin-magazin.de

DB-Duell
Datenbanken
bis zu 100 Prozent (Abbildung 4, Kurve
E). Spätere Versuche ergaben, dass noch
höhere Werte für »checkpoint_segments«
hier keine nennenswerte Verbesserung
bringen.
In dieselbe Richtung ist ein weiterer
Schritt möglich, der allerdings – ganz
ähnlich wie zuvor bei MySQL – auf Kosten
der Sicherheit geht. Stellt man nämlich
die Option »synchronous_commit«
(Default) ab, dann wartet der Datenbankserver
nicht mehr darauf, dass die Write
Ahead-Logs (WAL) tatsächlich auf der
Festplatte gelandet sind, bevor er eine
Erfolgsmeldung an den Client weitergibt.
Das geht schneller, es können im Fall
eines Crashs dabei aber einzelne Transaktionen
verloren gehen. Es gibt durchaus
Fälle, in denen man das für eine höhere
Performance ohne große Bauchschmerzen
in Kauf nehmen kann. Auf eine
Finanztransaktion trifft das sicher nicht
zu, auf ein Forum-Posting eher. Man
muss also wissen, was man tut.
Wir haben – schon allein aus Gründen
der Chancengleichheit – aber auch diese
Tuningvariante gestestet. Das Resultat:
Mit asynchronem Commit ist die Bremse
endgültig gelöst, und die Menge der erreichbaren
Transaktionen klettert mit
über 15 000 pro Minute in den Bereich,
den auch MySQL maximal erreichte
( Abbildung 4, Kurve F).
Fazit
PostgreSQL hatte den besseren Start, tat
sich dann aber etwas schwer, noch zuzulegen.
MySQL begann mit der schlechteren
Default-Konfiguration, konnte sich
dann aber kontinuierlich Schritt um
Schritt steigern. Besonders beim Caching
erschloss es noch Reserven, die es bei
PostgreSQL wahrscheinlich deshalb nicht
mehr gab, weil es von Anfang an näher
am Optimum war. Nachdem möglichst
viele Plattenzugriffe durch Operationen
im RAM ersetzt waren, profitierten beide
Datenbanken stark von einer Verminderung
des unvermeidlichen Overheads
durch das Transaction Logging. In der
besten Einstellung, die wir finden konnten,
und für die jeweils ein Kompromiss
mit Blick auf die Datensicherheit nötig
war, lagen die beiden Kontrahenten aber
am Ende wieder ziemlich gleich auf.
Einen noch größeren Boost verschaffte
beiden Datenbanken der Umstieg auf
SSD. Mit der besten Konfiguration und
einer SSD als Massenspeicher verdoppelte
sich die Anzahl Transaktionen zum
Schluss noch einmal. Wieder begegneten
sich die Kontrahenten auf Augenhöhe,
allerdings schwanken die Werte von PostgreSQL
etwas stärker und fallen auch
etwas schneller ab. (jcb)
n
Infos
[1] DBT2:
[http:// sourceforge. net/ apps/ mediawiki/​
osdldbt/ index. php? title=Main_Page]
Für Leser des ADMIN-Magazins: Gutschein
für 2 Networking-Kompendien gratis.
Einfach unter http://www.SearchNetworking.de/Registrierung anmelden
und den Aktionscode „admin“ verwenden.
Sie gehen keine Verpflichtungen ein und bekommen die zwei Ausgaben automatisch zugeschickt:
• Highspeed-Networking
• Routing & Switching in konvergenten Umgebungen
Der Gutschein ist bis zum 9. Dezember 2011 gültig.
NEU!
Jetzt Gutschein einlösen:
www.SearchNetworking.de/
Kompendium

Datenbanken
NoSQL
hypermania2, 123RF
NoSQL-Datenbanken – Technologie und Projekte
NoSQL
Mit der Datenexplosion des Web-2.0-Zeitalters ist in den letzten Jahren
eine ganze Klasse neuartiger Datensilos aufgetaucht, die sogenannten
NoSQL-Datenbanken. Der Autor des weltweit ersten NoSQL-Buches stellt in
diesem Beitrag die neue Technologie vor und hilft, in der Praxis die richtige
Auswahl zu treffen. Stefan Edlich
Datenbanken gibt es seit Ende der 60erund
der 70er-Jahre. Schon bevor Edgar
F. Codd das relationale Datenmodell einführte,
kannte man anders strukturierte
Datenbankmodelle. 1979 entwickelte
etwa Ken Thompson eine Hash-orientierte
Datenbank, und in den 90er-Jahren
erschienen mit Lotus, BerkeleyDB oder
GT.M viele weitere Datenbanken. Danach
setzte sich in den 80er- und 90er-Jahren
allerdings das relationale Modell aus gutem
Grund durch. Dafür sprachen neben
dem konsistenten mathematischen
Modell einige weitere Gründe: Es gab
überwiegend statische Daten, die meisten
Anwendungen liefen auf einem Server,
und es war von Vorteil, mit Normalisierung
Plattenplatz zu sparen.
Im Web-2.0-Zeitalter gibt es viele Anwendungsbereiche,
in denen die oben
genannten Gründe nicht mehr gelten.
Zum einen sind die Daten inzwischen
kaum mehr statisch. Analysen zufolge
sind über 90 Prozent aller Daten im Web
ständigen Änderungen unterworfen und
eher unstrukturiert. Zum anderen haben
Web‐2.0-Firmen wie Google, Yahoo,
Facebook, LinkedIn, Digg oder MySpace
so viele Daten, dass sie sich nicht mehr
auf einem Server hosten und verarbeiten
lassen. Und schließlich muss man heutzutage
kaum mehr Plattenplatz sparen.
Was heißt NoSQL?
Der Wegfall von Argumenten für das relationale
Modell hat daher der Konkurrenz
wieder mehr Raum gegeben und die Verbreitung
von NoSQL-Datenbanken gefördert.
Doch was genau ist damit gemeint?
Ein Definitionsversuch findet sich auf
[2]. Danach sind NoSQL-Datenbanken:
Nicht-relational: Wie bereits oben erwähnt,
ist die Nicht-Relationalität eher
ein Kriterium für eine NoSQL Datenbank
als die fehlende Verwendung von SQL.
Entscheidend ist hier, dass die Datenbank
ein ganz anders Datenmodell umsetzt,
beispielsweise Dokumentenstrukturen
(wie JSON) oder Graphenstrukturen.
Verteilt und horizontal skalierbar:
NoSQL-Datenbanken sind in der Regel
auf eine einfache horizontale Skalierung
ausgelegt (Scale-Out), siehe Abbildung
1. Mit minimalem Aufwand und ohne
Verlust der Erreichbarkeit lässt sich dabei
weitere handelsübliche Hardware in das
Datenbanksystem einfügen. Im Gegensatz
dazu wurde in den 80er- und 90er-
Jahren meist vertikal skaliert, das heißt,
der Server aufgerüstet.
Open Source: Die meisten NoSQL-Datenbanken
sind Open Source. Dies kann eine
Kostenersparnis bedeuten, muss es aber
natürlich nicht zwingend.
Web-Scale und schemafrei: NoSQL-
Datenbanksysteme sind für den skalierbaren
Einsatz im Web prädestiniert.
Gründe dafür sind die Datenmenge und
ihre flüchtige Struktur: Webdaten ändern
ihre Struktur häufig. Gleichzeitig ist eine
Downtime wegen »ALTER TABLE« aber
nicht immer akzeptabel.
48 Ausgabe 06-2011 Admin www.admin-magazin.de

NoSQL
Datenbanken
Einfache Replikation: Wenn Datenbanken
auf eine Scale-Out-Architektur ausgerichtet
sind, dann ist Replikation ein
wichtiger Faktor. Und meistens ist das
ebenfalls ein Kernelement von NoSQL-
Datenbanken. Replikation in NoSQL-
Systemen wie CouchDB oder Riak lässt
sich deshalb mit nur einer Anweisung
auf der Kommandozeile oder lediglich
mit einer Konfigurationseinstellung bewerkstelligen.
Im Gegensatz dazu merkt
man bei vielen relationalen Datenbanken,
dass das Datenmodell im Vordergrund
steht und Möglichkeiten für die
Skalierung und Replikation erst später
hinzugefügt wurden und komplizierter
zu handhaben sind.
Einfache API: In relationalen Systemen
ist SQL eine Schnittstelle mit vielen Vorund
Nachteilen. NoSQL-Systeme gehen
hier oft ganz andere Wege und bieten unterschiedliche
Schnittstellen und Abfragemodelle
an. Sehr viele NoSQL-Datenbanken
offerieren etwa REST-Schnittstellen,
bei denen die Datenbank komplett via
Web-Anfragen verwaltet wird. Des Weiteren
gibt es oft Datenbankschnittstellen
wie Apache Thrift [3] für alle Programmiersprachen
und auch oft native Abfragen,
die LINQ ähneln [4].
Schwächere Transaktionsanforderungen:
Was für Banken wichtig ist – nämlich
ACID-Transaktionen – ist für viele
Webanwendungen verzichtbar. Facebook-
oder Twitter-Einträge müssen nicht
transaktionsfest sein. Viele dieser Daten
sind auch unzusammenhängend, müssen
also auch nicht mit kostspieligen Join-
Operatoren durchsucht werden. Wenn
aber ACID und Join-Abfragen einen
anderen Stellenwert haben, kann man
ganz andere Datenbanksysteme bauen,
die besser skalieren. In der Regel gelten
für NoSQL-Systeme viele dieser Kriterien.
Abbildung 1: Scale-Up versus Scale-Out – während man früher zumeist größere Server anschaffen musste,
sobald man an die Leistungsgrenze kam, erlauben heutige, horizontal skalierbare Architekturen einfach das
Hinzufügen weiterer Commodity-Hardware.
Es müssen jedoch nicht zwingend alle
Kriterien erfüllt sein. Die Community
übersetzt NoSQL mittlerweile als „Not
Only SQL“ und verweist damit auch auf
das Recht, über andere Lösungen als relationale
Datenbanken nachzudenken.
Klassifikation
Welche Klassen von NoSQL-Datenbanken
gibt es nun? Man unterscheidet – wie in
Abbildung 3 (mittlere Schicht) dargestellt
– meistens vier Gruppen (stores
steht hier für Datenbank):
n Wide Column Stores: NoSQL-DBs mit
tabellenartigen Datenstrukturen für
extreme Datenmengen.
n Document Stores: NoSQL-DBs, die interpretierbare
Dokumente definierter
Struktur (wie JSON) speichern.
n Key/​Value Stores: NoSQL-DBs, die
Hash-Strukturen, also beliebig viele
Abbildung 2: Sowohl in der Zugriffsschicht wie auf der Ebene der Datenmodelle wie auch im Speichermodell
ergeben sich Unterschiede zwischen den vier Hauptgruppen der NoSQL- und relationalen Datenbanken.
Key/​Value-Paare speichern.
n Graph Databases: Datenbanken, die
Graphenstrukturen speichern.
Es gibt noch viele weitere Datenbankarten
wie XML- oder Objekt-, Grid- oder
Multi-Value-Datenbanken, die man unter
Umständen auch dem NoSQL-Bereich zurechnen
kann. Jedoch stehen die NoSQL-
Datenbanken der oben genannten vier
Gruppen im Hauptfokus der NoSQL-
Bewegung.
Zusammenfassend ergeben sich – in
Bezug auf den Vergleich mit relationalen
Datenbanken – Unterschiede in drei
Ebenen, die Abbildung 2 darstellt. Zugriff
auf die NoSQL-Datenbank erhält
man meistens über ein REST-Protokoll,
das erwähnte Thrift, ein einfaches Get/​
Put für Hashes oder über die unzähligen
Sprachanbindungen. Auf der Schicht
des Datenmodells gibt es (Wide) Column
Families, eindeutig definiert parsierbare
Dokumente, Key/​Value-Strukturen
(Hashes) und Graphenstrukturen.
Interessant ist aber auch, dass einige Datenbanken
auch im Speichermodell ungewöhnliche
Wege gehen. Zwar speichern
die meisten Programme immer noch auf
Platte, daneben aber gibt es viele RAMund
RAM-Hybrid Lösungen. Programme
wie Scalaris oder Hazelcast setzen vollständig
auf RAM und sorgen für transparente
Replikation. Nach Argumentation
dieser Programme ist repliziertes RAM
nicht unsicherer als das Schreiben auf die
www.admin-magazin.de
Admin
Ausgabe 06-2011
49

Datenbanken
NoSQL
es von sehr vielen NoSQL-Datenbanken
als Operation angeboten. Vorteil ist weiterhin,
dass die Map- und Reduce-Funktionen
in jeder Programmiersprache formuliert
werden können. Die Forschung
arbeitet derzeit fieberhaft an weiteren
Modellen, die Vorteile beider Welten
– extreme Parallelisierbarkeit und die
Mächtigkeit relationaler Abfragen – zu
integrieren versucht.
Abbildung 3: Arbeitsweise des Map/​Reduce-Verfahrens, das sich eignet, um rechenintensive Prozesse zu
parallelisieren.
Platte. Andere NoSQL-Datenbanken wie
MongoDB oder Redis setzen auf eine Hybridlösung.
Auch hier sollten alle Daten
(oder mit Virtual Memory mindestens als
Schlüssel) in den RAM passen, sie werden
in konfigurierbaren Zeitintervallen
mit der Festplatte synchronisiert. Dies
hat extreme Performancevorteile, ist aber
vielleicht nicht hundertprozentig ausfallsicher.
Als letzte Variante erlauben viele
NoSQL-Datenbanken die Definition einer
beliebigen Speicher-Engine. Sogar auch
relationale Datenbanken lassen sich oft
als Unterbau einsetzen.
Abschließend bleibt anzumerken, dass
viele der NoSQL-Datenbanken von Web-
2.0-Firmen selbst entwickelt wurden, die
sie dann häufig als Open Source freigaben.
So geschehen bei Yahoo, das Hadoop
erschaffen hat, oder beim Akamai Team,
das Riak entwickelte.
NoSQL kann nicht ordentlich ohne etwas
theoretischen Hintergrund verstanden
werden. Dabei gibt es ganz grob fünf
Konzepte, auf denen verteilte NoSQL-
Systeme aufbauen. Sie können hier nur
kurz angesprochen werden, weiterführende
Literatur wie [1] hilft dabei, diese
Themen zu vertiefen.
Map/​Reduce
Um sehr große Datenmengen effizient bearbeiten
zu können, hat Google das Map/​
Reduce-Verfahren entwickelt und 2004
vorgestellt [5]. Mittlerweile ist es paten-
tiert. Die Grundlagen dieses Verfahrens
waren allerdings schon seit vielen Jahrzehnten
in der funktionalen Programmierung
geläufig.
Kernidee dieses Verfahrens ist, Daten zu
segmentieren und dann von sehr vielen
Prozessen bearbeiten zu lassen (Abbildung
3). Das läuft im Wesentlichen auf
das Sammeln und gegebenenfalls Transformieren
und Verdichten der Daten heraus,
so wie man eine Ameisen- oder
Bienenarmee beauftragen würde. Die
Daten werden dazu typischerweise in 16
bis 64 MByte große Blöcke zerlegt. Ein
Master-Prozess weist dann den Worker-
Prozessen zuerst eine Map-Aufgabe zu.
Dabei müssen die Key/​Value-Paare der
Daten analysiert und gesammelt werden.
Die Ergebnisse
werden dann
weiteren Workern
übergeben, die das
Reduce ausführen
und die Daten verdichten.
Dieses Verfahren
ist hochparallelisierbar
und gut für
Aufgaben geeignet
wie verteiltes Suchen,
das Zählen
von URL-Zugriffe
und Web-Verlinkungen,
Indexe
erstellen und so
weiter. Daher wird gleichzeitig realisierbar.
CAP
Als einer der ersten hat Amazon mit dem
Dynamo-System aufgezeigt und darüber
publiziert [6], wie man extrem große
Datenmengen so verwaltet, dass die
zugrunde liegenden Systeme hochverfügbar
sind. Da Amazon viele Dutzend
Millionen Anwender gleichzeitig bedienen
muss, ist Hochverfügbarkeit ein
wichtiges Thema. Dabei darf der Ausfall
von Rechnerknoten keine negativen Auswirkungen
haben (Partition Tolerance).
Andere Knoten müssen einspringen können,
und das System muss immer reagieren.
Firmen wie Google, Yahoo oder
Amazon verlieren sehr viele Millionen
Dollar in jeder Minute Downtime. Wenn
man auf Availability und Partition Toleranz
setzt, zeigt es sich jedoch, dass
man keine hundertprozentige Konsistenz
aufrechterhalten kann, da Knoten Zeit
brauchen, um zu replizieren. Man gibt
daher ACID-Transaktionalität zugunsten
des BASE-Modells (Basically Available,
Soft State, Eventually Consistent) auf.
Eventual Consistency bedeutet, dass es
möglich sein kann, dass Knoten zum Bei-
Abbildung 4: Das CAP-Theorem – nur zwei der drei Bedingungen sind jeweils
50 Ausgabe 06-2011 Admin www.admin-magazin.de

NoSQL
Datenbanken
Abbildung 5: Consistent Hashing Ring: Jedes Datenbankobjekt hat eine
eindeutige Position im Ring und kann auf andere Nodes replizieren.
spiel für wenige Zehntelsekunden einen
unterschiedlichen Stand haben und ein
Client in seltenen Fällen einen älteren
Zustand „sieht“. Dies ist bei sicherheitskritischen
Systemen wie Bankanwendungen
inakzeptabel. Bei Web-2.0-Systemen
wie Social Networks ist es jedoch absolut
kein Problem. Ob ein Tweet oder eine
Gefällt-mir-Bekundung sofort oder eine
Sekunde später sichtbar wird, interessiert
nicht wirklich.
Wie in Abbildung 4 gezeigt, bilden die
drei Punkte Availability, Consistency und
Partition Tolerance das CAP-Theorem-
Dreieck, für das Eric Brewer schon im
Jahre 2000 gezeigt hat, dass nur zwei
dieser drei Ziele gleichzeitig erreichbar
sind.
Consistent Hashing ist eine Methode,
die es erlaubt, eine Gruppe von Rechnerknoten
(Nodes) mit besonders geringem
Aufwand zu verkleinern oder zu
vergrößern. Eine Veränderung hat dann
nämlich meistens nur Auswirkungen auf
Nachbarknoten, wogegen bei konventionellen
Verfahren häufig so gut wie alle
Knoten betroffen sind. Dazu baut man
einen Ring (Abbildung 5) wie folgt auf:
Alle Elemente der Datenbank werden
mit einem geeigneten Hashverfahren wie
MD5 auf einen Adressraum abgebildet,
beispielsweise von 0 bis 2^160. Dieser
Adressraum wird dann auf Rechnerknoten
aufgeteilt. Bei Bedarf können die
Rechnerknoten wieder virtuelle Nodes
enthalten. Jedes Datenbankobjekt be-
kommt nun eine
eindeutige Position
im Ring. Jeder
Node kann
nun auf N weitere
Nodes replizieren
und so für weitere
Sicherheit sorgen.
Dieses System ist
dann einfach rekonfigurierbar.
Multi Version
Concurrency
Control (MVCC):
Dieses Verfahren
sei anhand einer
Analogie zur
Versionskontrolle
veranschaulicht.
Viele Versionskontrollsysteme
in den
90er-Jahren arbeiteten mit Locks (pessimistische
Sperrverfahren). Zwei Softwareentwickler
konnten nicht gleichzeitig
dieselbe Datei editieren. Einer musste
warten, bis der Lock aufgelöst war. Es hat
sich jedoch gezeigt, dass dieses Verfahren
bei vielen Entwicklern (in hochgradig
verteilten und parallelen Systemen) nicht
immer praktikabel ist. Daher setzen Subversion
und besonders moderne Systeme
wie Git und Mercurial darauf, nicht zu
sperren, sondern stattdessen mit Versionen
zu arbeiten (optimistische Sperrverfahren).
Oftmals ist es nämlich viel
leichter, sehr seltene Konflikte zu lösen,
als ständig in Locks hängenzubleiben.
Das Gleiche gilt ganz allgemein für parallel
schreibende Systeme, die den gleichen
Datenbestand bearbeiten möchten.
Verwendet man wie bei MVCC einfach
nummerierte Versionen, dann kann es
zwar sein, dass Prozesse ältere Versionen
erhalten oder dass zwei Transaktionen
zwei verschiedene Versionen des
gleichen Objektes schreiben, aber das
Objekt ist nicht mehr gesperrt. Nach anfänglicher
Zurückhaltung der Industrie
ist dieses Verfahren nicht nur bei NoSQL-
Datenbanken, sondern auch in allen bedeutenden
relationalen Datenbanken
und sogar in Programmiersprachen wie
Clojure implementiert [8].
Vector Clocks sind ein wichtiges Mittel
in verteilten Systemen, um zeitliche Zusammenhänge
zu erkennen. Oftmals können
oder möchten sich Systeme nicht auf
reale Uhren wie Unix Epoch-Zeitstempel
verlassen. In diesem Fall werden einfach
eindeutige Identifier (IDs wie beispielsweise
eine Prozess ID) zusammen mit einem
persönlichen Counter versendet, die
eine Nachricht eindeutig auszeichnen.
Mit dieser Menge an IDs und Zeitstempeln
liefert der Vektor die Möglichkeit,
Ereignisse wie das Schreiben in eine Datenbank
zeitlich zu ordnen. Viel wichtiger
ist es aber zu erkennen, dass das
Schreiben eines Wertes X die Ursache
eines anderen Ereignisses ist. Dies ermöglicht
es Clients, selbst zu entscheiden,
welche Version eines Objektes jetzt
die beste oder aktuellste ist [9]. Wer
dagegen eine Einigung aller Teilnehmer
erreichen möchte, muss unter Umständen
auf komplexere Protokolle wie Paxos
zurückgreifen [10].
Wide Column Stores oder auch Column
Families fühlen sich ein bisschen wie
eine Mischung aus relationalen Tabellen
und Excel-Sheets an. Kennzeichnend ist,
dass die unterste Ebene meistens Schlüssel
und Werte speichert, ähnlich einer
Tabelle. Eine beliebige Anzahl dieser
Schlüssel-Wert-Paare lassen sich dann
meist in einer Column Family zusammenfassen,
die wiederum selbst einen
Schlüssel repräsentiert. Auf oberster
Ebene steht dann meistens noch eine
Domain oder ein Keyspace zur Verfügung.
Der Aufbau ist also meistens der:
Keyspace x ColumnFamily x (Key ‐> Value*)
Die bekanntesten Vertreter, die alle auf
die Verarbeitung extrem großer Datenmengen
ausgelegt sind, heißen:
n Hadoop / HBase (Hypertable, Cloudera)
n Cassandra
n Amazon SimpleDB
Hadoop/​HBase ist das Pendant zu
Googles BigTable und wurde von Yahoo
initiiert. Dabei ist Hadoop das komplette
Apache-Projekt mit vielen Unterprojekten.
HBase definiert nun das spaltenorientierte
Datenbanksystem als mehrdimensionales
assoziatives Array auf der
Hadoop-Infrastruktur wie dem Hadoop
Filesystem (HDFS). Der Zugriff erfolgt
über Java, REST und Thrift.
Hypertable ist im Gegensatz zu Hadoop/
HBase (Java) in C++ geschrieben. Dadurch
ist es deutlich schneller und ressourcenschonender
als Hadoop. Es wird
www.admin-magazin.de
Admin
Ausgabe 06-2011
51

Datenbanken
NoSQL
Cassandra ist einfach skalierbar, Replikation,
Konsistenz und Latenzzeit der
Antworten sind leicht konfigurierbar. Einen
Single Point of Failure gibt es nicht.
Allerdings ist es bisher nicht möglich,
das Schema im laufenden Betrieb zu
ändern.
Dokumenten-Datenbanken
Abbildung 6: Das Datenmodell von Cassandra: Schlüssel verweisen auf weitere Schlüssel-Wert-Paare innerhalb
von Column Families und Keyspaces.
zum Beispiel bei Baidu eingesetzt, dem
Konkurrenten der Google-Suchmaschine
in China. Für Hadoop und Hypertable
gibt es viele solcher Beispiele für wirklich
extrem große Installationen. Cloudera
bietet Services und Werkzeuge rund um
Hadoop an.
Die Datenbanken dieser Gruppe bieten
einfachste Skalierung durch Hinzufügen
eines Region-Servers mit handelsüblicher
Hardware. Sie verfügen über eine starke
Community und lassen sich leicht aufsetzen,
das Optimieren und Warten ist
allerdings komplex. Die Replikation funktioniert
nur auf Filesystem-Ebene.
Amazon SimpleDB: Dieser Datenbank-
Dienst ist Teil der der Amazon Web Services
(AWS), in die er sich nahtlos in
eingliedert. Da es sich um einen proprietären
Cloud-Service handelt (SaaS), ist
SimpleDB nicht lokal installierbar. Als
Cloud Service zahlt man ähnlich wie bei
EC2 jeweils Gebühren für Übertragung,
Anfragen und Speicher. Der Zugriff erfolgt
via REST, SOAP, Java, C#, Perl, PHP,
Javascript oder über das HTTP-Protokoll.
Angenehm ist, dass die Datenbank automatisch
skaliert. Dabei ist es möglich, auf
etwas Konsistenz zugunsten der Performance
zu verzichten. Das Datenmodell
ist ähnlich dem obigen allgemeinen:
Domains x Items x Attributes, Values.
Dabei können dynamisch beliebige viele
neue Attribute angelegt werden.
Cassandra: Die NoSQL Datenbank Cassandra
entstammt Facebook. Google Big-
Table war hier zwar ebenfalls Vorbild,
das Datenmodell ist aber eher hybrid, da
ein festes Schema erweitert werden kann.
Die API ist komplett auf Thrift ausgelegt.
Cassandra ist komplett in Java geschrieben
und dennoch relativ schnell. Ziel war
es auch hier, den Cassandra-Ring sehr
leicht dynamisch erweitern zu können.
Das Datenmodell Abbildung 6 anhand
eines einfachen Beispiels.
Die Daten in Cassandra bestehen aus
beliebig vielen Keyspaces. Darin sind beliebig
viele Column Families enthalten.
Beide müssen leider in einer XML-Datei
bekannt gemacht werden. Danach folgen
beliebig viele Zeilen, die links durch
einen Key („GUI“, „Controller“ und so
weiter) identifiziert werden und als Hash
dann auf beliebig viele Werte verweisen.
Cassandra erlaubt dabei sogar mit Super
Columns eine weitere Schachtelungstiefe,
in der eine Liste statt eines Values angegeben
werden kann. Eine Einfügeoperation
erfolgt dann beispielsweise in Ruby
ganz einfach mit:
# Der Keyspace
siemens = Cassandra.new("Siemens")
gui = {"dev1" => "Jim", "dev2" => "Tom"}
siemens.insert(:Development, "GUI", gui)
Mit Dokumenten-Datenbanken verbinden
sich nicht selten Missverständnisse. Es
geht nicht darum, beliebige Dokumente
wie in einem CRM-System zu verwalten
oder ein Dateisystem nachzubilden.
Was NoSQL-Datenbanken stattdessen
auszeichnet, ist der Umstand, dass die
Schemaverantwortung nicht mehr bei
der Datenbank liegt, sondern beim Dokument
und damit beim Entwickler. Dies
ist die eigentliche Revolution. Jeder ist
von relationalen Datenbanken gewohnt,
in der Datenbank ein sauberes aber starres
Schema zu definieren. Jetzt hingegen
muss nur noch das Dokumentenformat
festgelegt werden und eindeutig
interpretierbar sein. Dabei überwiegt als
Dateiformat in der Praxis JSON [11]. Es
ermöglicht eine einfachere Notation als
XML und bietet verschachtelte Objekte
an, die aus Arrays, Strings, Zahlen oder
booleschen Werten bestehen können.
Tatsächlich gibt es nur zwei relevante
Document Stores in der NoSQL-Szene:
CouchDB und MongoDB.
CouchDB ist eine echte Web-2.0-Datenbank
und wurde von Damien Katz,
einem ehemaligen Chefentwickler bei
Lotus Notes, gestartet. CouchDB ist zudem
ein Toplevel-Apache-Projekt und
in Erlang geschrieben. Mit am interessantesten
ist die REST-API. Zugriff ist
daher auch über Javascript und fast alle
Sprachen möglich. Alle CRUD-Operationen
sind REST-Operationen, was das
weiter unten folgende Beispiel zeigt. Die
Objekte werden nach einem definierten
Intervall via MVCC gespeichert und sind
damit – im Gegensatz zu manch anderer
Datenbank – nach dem entsprechenden
»fsync« dauerhaft. Die vom Anwender
angelegten Dokumente werden in B-Bäumen
gesichert und mit einer ID und einer
Revi sionsnummer versehen. CouchDB erlaubt
es, mit Map/​Reduce via Javascript
Anfragen zu erstellen und diese als Views
zu materialisieren.
Eine der Stärken von CouchDB ist die
Replikation. Über das Web-Interface oder
mit einer HTTP-Anfrage lassen sich zwei
52 Ausgabe 06-2011 Admin www.admin-magazin.de

NoSQL
Datenbanken
Datenbanken synchronisieren oder replizieren.
Damit eignet sich CouchDB ideal
für Offline-Arbeiten und mobile Anwendungen,
wo viele Datenbanken synchronisiert
werden müssen. Skalieren lässt
sich CouchDB mit dem Drittanbietertool
Couch Lounge, welches verteiltes Partitionieren/​Clustering
im Consistent Hashing
Ring ermöglicht. Mittels Oversharding
kann jede Shard-Partition selbst wieder
durch eine Lounge ersetzt werden, um so
eine fraktale Skalierung zu erreichen.
Dank des einfachen Zugriffs via REST
und Javascript, ermöglicht CouchDB Architekturen,
die ohne Middleware auskommen.
Es kommt sogar noch besser:
Da CouchDB selbst einen Webserver
und den Browser Futon mitbringt (Abbildung
7), ist es möglich, die gesamte
Anwendung als Javascript in der Datenbank
selbst abzulegen (sogenannte
CouchApps) und sie dynamisch zu verändern.
Dies geschieht derzeit bei vielen
Projekten im Web, wo viele Anwender
CouchDB selbst dynamisch und evolutionär
verbessern.
Eine CouchDB-Anfrage, die ein Dokument
anlegt, lässt sich ganz einfach in
der Konsole starten:
curl ‐X PUT http://127.0.0.1:5984/persons/ U
2974a6283c85e98237405f3542ca1344 ‐d U
'{"name":"mahatma gandhi","job":"guru"}'
In der Anfrage ist daher mit »persons«
die Dokumentenklasse und das konkrete
Dokument mit einer ID enthalten.
CouchDB bietet die einfachste Master-
Slave- und Master-Master-Replikation
und eignet sich sehr gut für Webanwendungen.
MongoDB
MongoDB wird federführend von der
Firma 10gen entwickelt. Einer der Chefs
von 10gen ist ehemaliger CTO von
DoubleClick. MongoDB wurde entwickelt,
um die konkreten Anforderungen
eines Web-Unternehmens zu befriedigen.
MongoDB nimmt ebenfalls Daten im Format
JSON an, verwendet für Austausch
und Speicherung aber das Binärformat
BSON. Der Zugriff erfolgt über APIs in
fast allen gängigen Sprachen.
Das primäre Ziel bei MongoDB war Performance.
Dies wird nicht nur durch das
Binärformat, sondern auch durch Me-
Abbildung 7: Die CouchDB-Oberfläche mit dem eingebauten Webbrowser Futon.
mory Mapped Files erreicht. Außerdem
ist MongoDB in C++ geschrieben und
erlaubt Zugriff über alle Programmiersprachen.
Die große Stärke von MongoDB
ist die Indexierung und die Anfrage-API.
MongoDB ist besonders performant, erlaubt
reichhaltige und dynamische Abfragen.
Ein kleiner Nachteil ist, dass es
teilweise keine Transaktionssicherheit
bietet.
Key/​Value-Datenbanken
Warum sind Key/​Value-Datenbanken in
letzter Zeit so populär geworden? Das
liegt im Wesentlichen daran, das Key/​
Value-Datenbanken der Schlüssel zu erfolgreicher
Skalierung sind. Das ist bei
anderen Datenmodellen wie Graph-Datenbanken
oder normalisierten relationalen
Daten dagegen einfach problematischer,
da deren Elemente stärker miteinander
verknüpft sind oder traversiert
werden müssen.
Spätestens seit dem Amazon Dynamo
schossen Key/​Value-Datenbanken wie
Pilze aus dem Boden. Allein auf [1] sind
einige Dutzend gelistet. Die erfolgreichsten
sind: Riak, Redis, Membase, Tokyo,
Voldemort und vielleicht kann man auch
den Azure Table Storage von Microsoft
dazu zählen. Hier seien nur kurz Riak
und Redis vorgestellt.
Riak entstammt einem Entwicklerteam
(Team Basho) um die Suchmaschine
Akamai. Das Datenmodell bei Riak entspricht
der Form
Bucket x Key x Document
Im Document Feld können JSON-Daten
oder sonstige beliebige Daten stehen. Da
Riak JSON interpretieren und durchsuchen
kann, ist RIAK eigentlich eine interessante
Dokumentendatenbank. Die
Entwickler sind jedoch bescheiden und
ordnen sich in die Kategorie Key/​Value
ein. Riak selbst ist in Erlang und C geschrieben
und folgt dem BASE-Modell
(eventually consistent). Als Schnittstelle
bietet Riak ebenfalls REST und die Sprachen
Erlang, Javascript, Java, PHP und
Ruby an. Realisiert wird ein klassischer
Consistent Hashing Ring mit bis zu 2^160
Elementen. Vorbild war auch hier wieder
Amazon Dynamo. Für die Persistenz können
beliebige Provider konfiguriert werden,
auch relationale Datenbanken. In
Riak kann durch eine einfache Konfiguration
die Anzahl der Replikate im System,
der erfolgreichen Lesebestätigungen und
der erfolgreichen Schreibbestätigungen
definiert werden. Damit lassen sich die
System-Durability und das Antwortverhalten
genau steuern.
Der Zugriff via REST erfolgt über die
URL »http://bucket/key«. Genauso können
Abfragen hier über eine Art URL
OpenSource Training Ralf Spenneberg
Schulungen direkt vom Autor
Firewall Lösungen mit Linux
5 Tage 14.11. ­ 18.11.2011
OpenLDAP und Kerberos
5 Tage 27.11. ­ 01.12.2011
Snort IDS/IPS Technology
4 Tage 06.12. ­ 09.12.2011
Sichere Mailserver Lösungen mit Postfix
5 Tage 12.12. ­ 16.12.2011
Linux System Administration / LPIC­1
5 Tage 09.01. ­ 13.01.2012
Hacking Webapplications
4 Tage 17.01. ­ 20.01.2012
Monitoring mit Nagios & Co.
5 Tage 23.01. ­ 27.01.2012
Sourcefire 3D
4 Tage 23.01. ­ 26.01.2012
Linux Netzwerk Administration / LPIC­2
5 Tage 30.01. ­ 03.02.2012
Freie Distributionswahl:
Opensuse, Fedora, Debian Squeeze,
CentOS oder Ubuntu LTS
Ergonomische Arbeitsplätze
Umfangreiche Schulungsunterlagen mit
Übungen
Am Bahnhof 3­5
48565 Steinfurt
Tel.: 02552 638755
Fax: 02552 638757
Weitere Informationen unter www.os­t.de
www.admin-magazin.de
Admin
Ausgabe 06-2011
53

Datenbanken
NoSQL
Abbildung 8: Der eingebaute Redis Performance Test zeigt hier auf einer virtuellen Maschine schon
erstaunliche 34000 Operationen pro Sekunde.
Pattern Matching durchgeführt werden.
Hochinteressant an Riak ist die Fähigkeit,
Links in JSON-Dokumente einbauen zu
können:
links: [
[Bucket1, Key2, Linkname3]
[Bucket10, Key42, Linkname77]
...
Dies gibt Riak schon fast die Mächtigkeit
einer Graph-Datenbank, weil ein Link-
Walking möglich wird, das teilweise
sogar kostenintensive Join-Operationen
spart.
Riak offeriert einfachste Skalierbarkeit,
Konfigurierbarkeit und Replikation (mit
Hinted-Handoff-Selbstreparatur) sowie
als ein besonders mächtiges Feature das
Link-Walking über Links in Dokumenten.
Nachteilig ist, dass bis jetzt noch keine
Literatur zu Riak existiert.
Redis startete als One-Man-Entwicklung
eines cleveren Italieners (Salvatore San
Fillipo), die mittlerweile von VMware eingekauft
wurde. Redis ist komplett in ANSI
C geschrieben. Der Sourcecode erstreckt
sich über nur wenige Dutzend Dateien.
Der Datenzugriff ist über alle gängigen
Programmiersprachen möglich.
Redis zeichnet sich besonders durch
seine Performance aus. Zusammen mit
OrientDB ist Redis vielleicht die schnellste
Datenbank. Redis hält alle Daten im RAM
Listing 1: Schreiben unter Redis
01 $ rc RPUSH mylist Dollar // (Dollar)
02 $ rc LPUSH mylist Euro // (Dollar, Euro)
03 $ rc RPUSH mylist Audi // (Dollar, Euro, Yen)
04 $ rc LRANGE mylist 0 ‐1 // Abfrage liefert (Dollar,
Euro, Yen)
des Servers und schreibt konfigurierbar
auf die Platte. Via Virtual Memory kann
es bei Speicherknappheit auch nur die
Schlüssel im RAM halten. Values werden
dann gegebenenfalls nachgeladen.
Schnell bedeutet, dass auf normaler
Hardware leicht über 100 000 Operationen
pro Sekunde zu erreichen sind.
Die Values bei Redis können (wahlweise
sortierte) Listen und Sets sein. Operationen
lassen sich als Transaktionen gruppieren.
Seit Version 2.0 sind sogar Publish/​Subscribe-Operationen
verfügbar.
Redis auf einem frischen UNIX-System
aufzusetzen, zu kompilieren, zu starten
und Werte zu speichern, kostet weniger
als eine Minute, was im Gegensatz zu einer
typischen Oracle-Installation einfach
mehr Spaß bedeutet.
Hochgeschwindigkeit
Redis ist damit der ideale Data-Structure-
Server für Massendaten oder Log-Daten.
Insbesondere in der Spieleindustrie ist
Redis beliebt, wo etwa viele Writes in
Hochgeschwindigkeit und wenige Reads
auf einem Server nötig sind. Redis skaliert
leider noch nicht nativ. Dieses Feature ist
aber in Arbeit. Dennoch implementiert
Redis eine sehr einfache aber leistungsfähige
Replikation, mit der beliebige Shards
aufgebaut oder die Read-Befehle auf beliebig
viele andere Maschinen verteilt
werden können.
In Abbildung 8 ist der eingebaute Redis
Benchmark zu sehen. Ausgeführt auf einem
VMware-Image von Ubuntu 9 unter
Windows sind allein hier schon 34.270
Operationen pro Sekunde möglich. Auf
einem nativen Unix-System (Redis kompiliert
bisher nur unter Unix) ist dagegen
ein Vielfaches dieser Performance – für
alle Redis-Datenstrukturen – möglich.
Das Listing 1 zeigt, wie mit der mitgelieferten
Shell Werte geschrieben werden
können. In diesem Fall eine Liste. Abfragen
über die Programmiersprache sind
ähnlich einfach.
Es gibt kaum Datenbanken, die schneller
sind als Redis, was auch für die Inbetriebnahme
gilt. Alle Daten (zumindest
die Schlüssel) müssen ins RAM passen.
Automatische Skalierung ist noch nicht
eingebaut, aber angekündigt.
Graphendatenbanken
Graphendatenbanken gehören zu den am
schnellsten wachsenden Bereichen der
NoSQL-Welt. Dies ist nicht weiter verwunderlich,
da ein bedeutender Teil des
Web 2.0 eine Graphenstruktur hat. Nicht
nur das Web selbst ist ein Graph, auch
viele Anwendungen im Web benötigen
graphenähnliche Daten und passende
Algorithmen. Das betrifft zum Beispiel
Social-Web-Dienste (wer ist wessen
Freund, alias Facebook oder Xing) das
Semantic Web, GIS (Geoinformationssysteme)
und Location Based Services.
Gerade der letzte Bereich spielt eine
große Rolle für Graphendatenbanken.
Die Anforderungen an Mehrschichten-
Graphenabfragen werden immer größer.
So müssen beispielsweise alle Ebenen
für Landkarten, Freunde und Points of
Interest miteinander verknüpft werden,
wenn mobile Anwender mit Smartphones
entsprechende Anfragen stellen.
Interessant ist dabei, dass die Graphentheorie
(zum Beispiel mit Dijkstra 1959)
schon relativ alt ist. Um so erstaunlicher
ist es, dass es allgemeine und leistungsfähige
Graphendatenbanken noch nicht
allzu lange gibt. So hat sich erst in den
letzten Jahren das Modell des Property-
Graphen ganz vorne positioniert. Bei
einem Property-Graphen [12] können
sowohl Kanten als auch Knoten mit beliebigen
Attributen (ähnlich eines Objektes)
versehen werden. Dieses mächtige
Datenmodell erlaubt auch die einfache
Abbildung von komplexen gerichteten
und gewichteten Graphen.
Während man vor fünf oder zehn Jahren
noch lange nach entsprechenden Daten-
54 Ausgabe 06-2011 Admin www.admin-magazin.de

NoSQL
Datenbanken
banken suchen musste und oft nur wenige
Speziallösungen gefunden hat, gibt
es seit einigen Jahren gut ein Dutzend
dieser Datenbanken, die an dieser Stelle
aufgelistet sein sollen: Neo4j, sones,
InfoGrid, DEX, HyperGraphDB, Infinite-
Graph, OrientDB, FlockDB, Google Pregel,
Apache Hama / Hamburg, VertexDB
und Filament. Viele dieser Projekte wie
das deutsche sones, Infinite Graph oder
OrientDB sind relativ neu, aber vielversprechend.
Schnell gefunden
Vorteil der Graphendatenbanken ist,
dass Links, das heißt die Verbindungen
zwischen den Kanten, schnell gefunden
und traversiert werden können. Links
sind hier sozusagen First Class Citizens.
Leider wird in der Industrie oft ein Graphenmodell
in eine relationale Datenbank
gepresst, was fatale Auswirkungen
hat. Das Traversieren und Suchen wird
extrem ineffizient. Graphendatenbanken
sind hier um ein Vielfaches schneller.
Leider ist die Suche in extrem großen
Graphdatenbeständen generell problematisch
und eine Skalierung von großen
Graphendatenbanken auch nicht einfach.
Ein Grund dafür ist, dass das Sharding,
das heißt die Aufteilung des Datenbestandes
des Graphen auf mehrere Server nicht
ohne große Nachteile möglich ist.
Neo4j: An dieser Stelle soll ein System
ausführlicher erwähnt werden: Bei Neo4j
handelt es sich um eine der ältesten Propeller-Graph-Datenbanken,
die seit 2003
in Produktion und seit 2007 auch als
Open-Source-Version verfügbar ist. Neo4j
implementiert einen ACID-Datenzugriff
und ist im Wesentlichen auf Performance
getrimmt. Es ist in Java implementiert
und läuft nur auf einer JVM. Nebenbei
können auch Indexsysteme wie Lucene
& Solar angebunden werden.
Neo4j ist als Jar-File verfügbar und
kann daher leicht in das Maven- oder
andere Buildsysteme integriert werden.
Neben einer REST-Schnittstelle gibt es
Anbindungen für fast alle bekannten Programmiersprachen.
Dennoch ist Java die
Haussprache von Neo4j. Listing 2 zeigt
das Erstellen oder Updaten der Property
eines Knotens in Java.
Interessant ist auch, dass Neo4j einige
neue Standards für die Suche in Graphen
implementiert. Auch hier wirkt Neo4j intensiv
an der Standardisierung [13] von
Sprachen und Konzepten wie Tinkerpop
Gremlin, Pipes, Traversern oder Rexter
mit. Bewertung: Neo4j ist industrieerprobt
und liegt in Enterprise-Versionen
wie als Open Source vor. Es existieren
Anbindungen für sehr viele Sprachen.
Das Skalieren der Datenbank oder Sharden
des Datenbestandes ist nicht leicht
möglich (das gilt allerdings für alle Graphendatenbanken).
Sones stammt aus einer deutschen Softwareschmiede
und ist auf den .NET-
Markt spezialisiert. Dennoch liegt eine
REST-Schnittstelle vor. Interessant ist dabei,
dass ein eigenes Filesystem genutzt
werden kann, welches die Datenbank
sehr schnell macht. Ausgefeilte Versionierungsfähigkeiten,
Binärdatenmanagement
und Cloud-Fähigkeit (auf Basis von
Amazon S3 oder MS Azure) zeichnen die
Datenbank aus.
OrientDB entstammt zwar aus der Feder
eines einzigen cleveren Entwicklers namens
Luca Garulli, jedoch ist diese Datenbank
aus zwei Gründen nicht minder
interessant: Die Datenbank war zuerst
eine Key/​Value-Datenbank und kann als
solche genutzt werden. Danach wurde
die Fähigkeit, Dokumente zu verwalten
integriert. Und schließlich wurden Eigenschaften
einer Graphendatenbank hinzugefügt.
Dies macht OrientDB zu einer
sehr universell einsetzbaren Datenbank.
OrientDB ist extrem schnell und braucht
den Benchmark mit anderen berühmten
Turbo-NoSQL-Datenbanken wie MongoDB
oder Redis nicht zu fürchten.
Datenbanken bewerten
Leider sind die Alternativen zu den relationalen
Platzhirschen (Oracle, MySQL)
viel zu wenig bekannt. Andere als relationale
Modelle werden auch in Universitäten
kaum gelehrt. Weiterhin gibt
es kaum Richtlinien, wie man die beste
Datenbank findet. In [1] wurde daher
erstmals versucht, einen Leitfaden oder
eine Checkliste zu erstellen, die dabei
hilft, die beste Datenbank für den Einsatzzweck
zu finden. Die wichtigsten
Kernelemente sind daher funktionale und
nicht-funktionale Anforderungen:
Datenanalyse: Jedes Projekt muss zunächst
die Daten untersuchen. Es gibt
eine Vielzahl von Datenarten wie Domain-,
Log-, Event-, Message-, kritische,
Business-, Meta-, temporäre, Session-,
geographische Daten. Viele davon passen
perfekt in relationale Datenbanken.
Andere – wie Session- oder Logdaten –
sind meist viel besser in NoSQL-Datenbanken
aufgehoben. Meistens geht mit
dieser Analyse die Frage nach dem besten
Daten- und Speichermodell einher (relational,
spalten-, dokumenten- graphen-,
objektorientiert und so weiter). Hier sind
Formate, Datentypen und Agilität wichtig.
Aber auch solche Fragen: Wie wird in
den Daten navigiert? Welche Datenmenge
gilt es zu beherrschen? Wie komplex sind
die Daten?
Transaktionsmodell: Durch die klassischen
relationalen Systeme wird der
Bereich der ACID Transaktionen seit
Langem bestens abgedeckt. Wie vorher
erläutert, gibt es aber viele Anwendungsfelder,
bei denen ein BASE-Modell genauso
gut funktioniert. Hier ist eventuell
eine NoSQL Datenbank besser. Nicht die
ACID-Anforderungen zu erfüllen, eröffnet
(siehe CAP-Teil) andere Möglichkeiten.
Aber natürlich kann es zwischen
ACID und BASE auch andere Transaktionsmodelle
geben, und eine eigene CAP-
Abwägung ist immer wichtig.
Performance: Hier ist eine der ersten
Entscheidungen, ob Scale-Up langfristig
möglich oder ein Scale-Out wirklich nötig
ist. Danach gilt es Datendurchsatz,
Antwortverhalten und Latenzzeitanforderungen
festzulegen.
Anfrageanforderungen: Die Anforderungen
des Projektes geben Aufschluss
darüber, wie intensiv und tief überhaupt
in den Daten gesucht werden muss. Sind
lediglich Schlüssel abzufragen, ist sicher
eine Key/​Value-Datenbank besser. Wird
intensiv an Knoten entlang nach Ele-
Listing 2: Neo4j: Knoten erstellen
01 Transaction tx = graphdb.beginTx();
02 try{
03 Node node1 = graphdb.createNode();
04 node1.setProperty("Name","Vitali Klitschko");
05 Node node2 = graphdb.createNode();
06 tx.success();
07 } catch (Exception e) {
08 tx.failure();
09 } finally {
10 tx.finish();
11 }
www.admin-magazin.de
Admin
Ausgabe 06-2011
55

Datenbanken
NoSQL
menten gesucht, ist gegebenenfalls eine
Graphendatenbank besser. Für OLAP und
Business-Analyse sind SQL oder LINQ
unverzichtbar.
Und schließlich legt die Architektur der
Anwendung auch schon einiges fest (mobil,
Peer-to-Peer, lokal, verteilt und so
weiter). Soll etwa auch mobil und offline
gearbeitet werden können, dann ist
beispielsweise CouchDB die erste Wahl.
Oftmals gibt es Datenzugriffsmuster, wie
zum Beispiel ein häufige Writes und nur
wenig Read-Operationen. Auch diese
weisen oftmals in die Richtung einer Datenbankklasse.
Daneben gibt es natürlich auch viele
nicht-fachliche Kriterien:
n Replikation
n Refactoring Bedarf
n Support / Bedienung
n Entwickler-Qualifikation
n Unternehmensvorgaben
n Security
n Vereinheitlichung der Software
n Backup / Recovery / Crash Resistance
n Lizenzkosten / Open Source / Community
Erfahrungen im NoSQL-
Zeitalter
Die Praxiserfahrung zeigt, dass eine qualifizierte
Analyse bei der Suche nach der
besten Datenbank sehr selten stattfindet.
Es herrschen meistens Unternehmensvorgaben
oder noch häufiger Bauchentscheidungen
vor. Leider kann dies Fehler
zur Folge haben, die später viel Geld
kosten.
Die hier konkret vorgestellten NoSQL-
Datenbanken zeigen, dass NoSQL-Systeme
in vielen Nischenbereichen ideal
sind. Agile Daten, hohe Availability, Offline-Arbeit,
Performance und Graphendaten
sind nur einige wenige Beispiele, wo
NoSQL-Datenbanken Vorteile bringen.
Aber natürlich gilt es, immer die Gesamtheit
der Anforderungen zu analysieren
und abzuwägen.
Aus diesem Vorteil in Nischenbereichen
folgt natürlich, dass NoSQL-Datenbanken
relationale Datenbanken niemals ersetzen
werden. Die Situation ist hier ähnlich
wie bei Programmiersprachen. Genauso
wie sich mit dem Web 2.0 der Raum der
Anforderungen erweitert, erweitert sich
auch die Zahl der verfügbaren Datenbanksysteme.
Eine direkte Migration von relationalen
Systemen auf NoSQL-Systeme ist meistens
nicht so leicht, da viel Anwendungslogik
umgeschrieben werden muss. So
müssen zum Beispiel eventuell Abfragen
umgeschrieben werden, und die Transformation
des Datenmodells ist generell
mit Reibungsverlusten verbunden. Selbst
Firmen wie Twitter haben den Umstellungsaufwand
deshalb gescheut und die
Migration nach NoSQL erst einmal nach
hinten geschoben. Auf NoSQL zu setzen,
lohnt daher oftmals eher bei neuen
Projekten.
Nicht ohne Probleme
Probleme mit NoSQL-Datenbanken lauern
oft da, wo mit dieser jungen Datenbankgeneration
noch keine Erfahrungen
vorliegen. So hatte die Firma Foursquare
kürzlich eine Downtime durch die
NoSQL-Datenbank MongoDB Probleme
[14]. Im Einsatz waren zwei große Amazon
EC2-Instanzen mit je 66 GByte RAM.
Jedoch wuchs der Speicherbedarf (MongoDB
nutzt hier Memory Mapped Files
im RAM) bei einer Instanz auf über 66
GByte und bei der anderen auf 50 GByte.
Dies konnte nicht einfach repariert werden,
wäre aber durch Überwachung und
Hinzufügen einer neuen EC2 Instanz
leicht vermeidbar gewesen.
Abschließend soll an dieser Stelle auf
zwei Trends hingewiesen werden, die
auch die NoSQL-Datenbankwelt beeinflussen:
n Oft hat ein Unternehmen hohe Persistenzanforderungen.
In Zukunft
werden diese immer öfter mit mehreren
Datenbanken gelöst. Es gibt
schon viele praktische Beispiele zum
hervorragenden Zusammenspiel der
relationalen Welt mit NoSQL. Auch
gibt es schon einige Hybridlösungen
wie etwa HadoopDB. Hier sollte man
nicht voreilig mit dem Argument der
Maintenance-Kosten den Aufbau einer
Multi-DB-Umgebung verhindern.
n Mit der Geschwindigkeit, mit der
Cloud-Lösungen und Virtualisierung
weiter voranschreiten, wird auch das
Datenbank-Hosting zunehmen. Künftig
wird es auf Cloud-Umgebungen
wie Amazon AWS oder Rackspace
viele Dutzende von gehosteten Datenbanklösungen
geben. Hier ist bereits
von DaaS (Database as a Service) die
Rede. Die Kunst dabei wird zukünftig
immer mehr darin bestehen, für die
Menge der Anforderungen die richtige
Mischung an DaaS-Lösungen zu
finden. (ofr)
n
Infos
[1] Stefan Edlich, Achim Friedland, Jens
Hampe, Benjamin Brauer, „Einstieg in die
Welt nichtrelationaler Web 2.0 Datenbanken“,
2010, Hanser Verlag
[2] NoSQL-Website:
[http:// nosql‐database. org]
[3] Apache Thrift:
[http:// incubator. apache. org/ thrift]
[4] LINQ: [http:// de. wikipedia. org/ wiki/ LINQ]
[5] Map/​Reduce-Technik:
[http:// labs. google. com/ papers/​
mapreduce. html]
[6] Amazon’s Dynamo Technology:
[http:// www. allthingsdistributed. com/​
2007/ 10/ amazons_dynamo. html]
[7] Eventually Consistent:
[http:// queue. acm. org/ detail. cfm?​
id=1466448]
[8] MVCC:
[http:// en. wikipedia. org/ wiki/​
Multiversion_concurrency_control]
[9] Vector Clocks:
[http:// blog. basho. com/ 2010/ 01/ 29/​
why‐vector‐clocksare‐easy]
[10] Paxos Family of Consensus Protocols:
[http:// sites. google. com/ site/ brturn2/​
paxosfamily]
[11] JSON: [http:// json. org]
[12] Graphen: [http:// arxiv. org/ abs/ 1006. 2361]
[13] Tinkerpop: [http:// www. tinkerpop. com]
[14] Probleme beim Sharding:
[http:// highscalability. com/ blog/ 2010/ 10/​
15/ troubles‐with‐sharding‐what‐can‐we‐le
arn‐from‐the‐foursquare. html]
Der Autor
Prof. Dr.-Ing. Stefan Edlich ist Professor für
Softwaretechnik und Datenbanken an der Beuth
Hochschule für Technik in Berlin. Er startete die
International Conference on Object Databases
(ICOODB). Neben vielen Veröffentlichungen ist
er Autor von zehn IT-Fachbüchern, darunter dem
ersten Fachbuch der Welt zum Thema NoSQL-Datenbanken.
Zudem betreibt er das NoSQL-Archiv
[nosql‐database. org] und führt Veranstaltungen
zum Thema NoSQL durch.
56 Ausgabe 06-2011 Admin www.admin-magazin.de

Bla Bla Bla gibt´s bei uns nicht:
Business - Telefonie der outbox AG.
Telefonie ist die Grundlage Ihres Unternehmens.
Ohne sie läuft nichts!
Deshalb konzentriert sich die outbox AG auf das
Wichtigste: Ein funktionierendes Telefonnetz,
praxiserprobte Produkt - Module und einen technisch
versierten Kundensupport.
Überzeugen Sie sich jetzt von unserem
Know - How aus mehr als sieben
Jahren Telefonnetzbetrieb –
Exklusiv für Geschäftskunden.
Auch auf
SIP - Basis und
für Reseller
Infos und Beratung: 0800 / 66 474 640
www.outbox.de/admin

Test
Windows Server 8
neftali77, 123RF
Neuerungen in Windows Server 8
Gekachelt
Auf der hauseigenen Build-Konferenz im kalifornischen Anaheim hat Microsoft die Desktop- und die Server-
Varianten des kommenden Betriebssystems Windows 8 vorgestellt. Schwerpunkt der kommenden Server-Version
sind Cloud-Computing und Virtualisierung. Thomas Joos
Gleichzeitig mit der Desktop-Ausgabe
von Windows 8 arbeitet Microsoft auch
an der neuen Serverversion, die der
Nachfolger von Windows Server 2008 R2
SP1 werden soll. Auch wenn derzeit vor
allem Neuigkeiten des Clients im Vordergrund
stehen, ist mit der Server-Version
ein interessantes Produkt in der Pipeline,
welches zahlreiche Neuerungen bringt.
Viele Neuerungen liegen noch im Dunkeln,
einiges hat Microsoft aber schon
offenbart. MSDN-Abonnenten können
sich die Developer Preview von Windows
Server 8 schon ansehen.
Hyper-V 3.0
In Windows 8 Server integriert Microsoft
die neue Version 3.0 von Hyper-V. Eine
der wichtigsten Neuerungen des Systems
ist die Replikation von virtuellen Maschinen
zwischen verschiedenen Hosts un-
ter dem Namen „Hyper-V-Replica“. Dazu
müssen die Hosts nicht unbedingt Teil
eines Clusters sein, sondern nur in einem
gemeinsamen Netzwerk laufen. Die Replikation
erfolgt asynchron im laufenden
Betrieb. Sie kann zeitgesteuert starten
oder vom Administrator manuell über
einen Assistenten oder die Powershell
angestoßen werden.
Hyper-V 3.0 unterstützt Festplatten – die
jetzt als VHDX-Datei eingebunden sind
– mit bis zu 16 TByte und kann virtuellen
Maschinen mehr als 16 CPU-Kerne
zuweisen. Auch im Bereich der Netzwerkgeschwindigkeit
soll der neue Server
deutlich optimiert sein, und Hyper-V-
Maschinen können direkt auf Funktionen
der Netzwerkkarten zugreifen, ohne den
Umweg über den Host gehen zu müssen.
Hyper-V-Hosts können zukünftig 2
TByte RAM nutzen und 160 CPUs verwalten.
Virtuelle Maschinen beherrschen
in Windows Server 8 bis zu 512 GByte
Arbeitsspeicher. Hyper-V-Cluster unterstützen
in Windows Server 8 mindestens
63 Knoten und bis zu 4000 virtuelle Maschinen.
Virtuelle Maschinen lassen sich
in Hyper-V-Clustern priorisieren und mit
der Live-Migration lassen sich im laufenden
Betrieb mehrere Server auf einmal
zwischen Clusterknoten verschieben.
Fällt ein Knoten aus, verschiebt Hyper-
V 3.0 die virtuellen Maschinen mit der
höchsten Priorität zuerst.
Sieht man sich die Änderungen in Windows
Server 8 an, fällt auf, dass sich die
meisten um die Leistungsverbesserung
in Bereich der Virtualisierung kümmern.
Hyper-V-Hosts lassen sich in Windows
Server 8, inklusive aller virtuellen Maschinen
in einen Energiesparmodus versetzen
und daraus auch wieder aufwecken.
Unternehmen, in denen nachts die
Server nicht unbedingt laufen müssen,
58 Ausgabe 06-2011 Admin www.admin-magazin.de

können auf diesem Weg durch Virtualisierung
deutlich Energie sparen, ohne die
Benutzer zu beeinträchtigen.
Microsoft will VMware mit dem neuen
Server das Leben schwermachen. Der
Vorteil von Windows Server 8 liegt darin,
dass viele Technologien, zum Beispiel
die Replikation virtueller Server, kostenlos
in den Server integriert sind. Beim
Konkurrenten VMware müssen Unternehmen
für solche Funktionen tief in die
Tasche greifen.
Um einen Cluster für Hyper-V aufzubauen,
ist in Windows Server 8 nicht
zwingend ein SAN notwendig. Die virtuellen
Maschinen lassen sich auch auf
einem Dateiserver ablegen. Dazu hat
Microsoft das Server-Message-Block-Protokoll
(SMB) in der Version 2.2 deutlich
verbessert. Dieses erlaubt mehrere parallele
und deutlich schnellere Zugriffe von
Daten über das Netzwerk.
Mehr Power im Netzwerk
und im Speicher
Windows Server 8 kann Netzwerkkarten
ohne speziellen Treiber als sogenanntes
Team zusammenfassen. Die Karten
müssen dafür nicht einmal vom gleichen
Hersteller oder Typ sein, auch wenn das
nach wie vor der bessere Weg ist. Die
kommende Server-Version erlaubt im
Netzwerk eine Zusammenfassung verschiedener
DHCP-Server, ohne einen
Cluster bilden zu müssen.
Mit der neuen Version von Direct Access,
also der Anbindung von Clients über das
Internet ohne VPN-Verbindung, können
Unternehmen Windows-7-Clients, aber
auch Windows-8-Clients mit IPv4 anbinden.
In Windows Server 2008 R2 ist die
Anbindung nur über IPv6 möglich, auch
wenn sich die Verbindungen in IPv4 tunneln
lassen, was die Einrichtung unnötig
kompliziert.
Ebenfalls neu ist die Möglichkeit, virtuelle
Fibrechannel-Adapter zu verwenden
und Speicherplatz im SAN als Speicher-
Pool zur Verfügung zu stellen. Auch andere
Datenträger lassen sich in Windows
Server 8 zu Pools zusammenfassen, was
die Verwaltung deutlich erleichtert. In
solchen Pools lassen sich physische Datenträger
zusammenfassen und auch
hochverfügbar betreiben. Das Betriebssystem
kann solche Pools als einzelne
Festplatte mit einer Größe von bis zu 64
TByte darstellen.
Schnellere Platten-Checks
Festplatten kann der neue Server im laufenden
Betrieb auf Fehler überprüfen.
Dazu hat Microsoft das bekannte Chkdsk
verbessert. Liegt ein Fehler vor, muss der
Datenträger für die Reparatur, also der
Deaktivierung der defekten Sektoren,
offline genommen werden. Das geht in
Windows Server 8 aber deutlich schneller
als in Vorgängerversionen.
Die neue Technik Data Deduplication in
Windows Server 8 verhindert das doppelte
Speichern identischer Daten. Vor allem
Hyper-V-Hosts mit virtuellen Servern
können hier deutlich an Speicherplatz
Sie haben Ihre
IT im Griff.
In Zukunft auch
ohne Überstunden?
NETHINKS unterstützt Sie
als zertifizierter deutscher
OpenNMS-Partner mit:
a Support
a Schulung
a Neukonzeptionen
a Systemoptimierungen
Sprechen Sie uns an!
www.NETHINKS.com
OpenNMS User Conference:
10.05. – 11.05.2012
Abbildung 1: Der neue Server-Manager in Windows Server 8.
www.admin-magazin.de
NETHINKS GmbH | Bahnhofstr. 16 | 36037 Fulda
T +49 661 25000-0 | info@NETHINKS.com

Test
Windows Server 8
einsparen. NTFS in Windows Server 8
wurde dazu deutlich aufgebohrt, ist aber
immer noch das Dateisystem der Wahl.
Verwaltung mit Powershell
oder Befehlszeile
Der Server-Manager in Windows Server
8 kann mehrere Server auf einmal verwalten,
was in Windows Server 2008 R2 nur
eingeschränkt und in Windows Server
2003/​2008 überhaupt nicht funktioniert.
Hier verwendet Microsoft ebenfalls die
neue Metro-GUI, was für Administratoren
eine gewisse Umgewöhnung mit sich
bringt (Abbildung 1).
Über den neuen Server-Manager lassen
sich auch Rollen und Features auf
Remoteservern installieren, was vor allem
bei der Verwaltung des bevorzugten GUIlosen
Core-Modus von Windows Server 8
die Arbeit von Administratoren erleichtert.
Der neue Server-Manager soll mehr
als nur ein temporäres Werkzeug sein,
das Administratoren zur Installation und
Einrichtung verwenden, sondern auch
der Diagnose dienen. Dazu kann das
Tool Server zusammenfassen und auch
Fehler auf Servern, die in den Ereignisanzeigen
vorliegen, gruppiert anzeigen.
Auf diesem Weg sehen Administratoren
dann zum Beispiel Fehler gruppiert nach
Dateiserver, Webserver oder Exchange.
Die Befehlszeile gibt es auch in Windows
Server 8 weiterhin. Zusätzlich
enthält der Server – wie übrigens auch
die Client-Version von Windows 8 – die
neue Version 3.0 der Powershell. Bei
der Installation von Windows 8 Server
bevorzugt Microsoft den Core-Modus
und die Verwaltung in Befehlszeile und
Powershell. Dieser Installationsmodus ist
in der neuen Version der offizielle von
Microsoft empfohlene Weg zur Installation.
In Windows Server 2008 R2 ist der
Core-Modus zwar auch verfügbar, aber
derzeit nur wenig im Einsatz. Das soll
sich in der neuen Version ändern. Es gibt
aber weiterhin die grafische Oberfläche
und auch die bekannten Verwaltungswerkzeuge.
In der neuen Version ist es
möglich, die Core-Version direkt auf eine
Installation mit grafischer Benutzeroberfläche
zu erweitern. In Windows Server
2008 R2 ist das nicht möglich.
Um die PowerShell-Befehle schneller zu
lernen, zeigen die grafischen Oberflächen
in Windows Server 8, zum Beispiel der
Server-Manager, die ausgeführten Aktionen
auch als Powershell-Befehl an. Diese
lassen sich einfach kopieren und auch in
die Powershell integrieren. Diese unterstützt
zur Verwaltung alle verfügbaren
Serverrollen, auch Hyper-V. Generell lassen
sich Core-Server deutlich einfacher
und effektiver über das Netzwerk verwalten
als in Windows Server 2008 R2.
Mehr Sicherheit und
Verschlüsselung
Die Verwaltung der Berechtigungen im
neuen Server ändern sich ebenfalls. Mit
der dynamischen Zugriffskontrolle können
Administratoren die Berechtigungen
für den Zugriff auf Dateien, Ordner und
sogar SharePoint-Bibliotheken einfacher
steuern. Dazu lassen sich Dateien mit
Metadaten versorgen, die nur bestimmten
Anwendern, zum Beispiel allen Anwendern
einer Abteilung oder der Geschäftsführung,
den Zugriff erlauben,
unabhängig in welchem Verzeichnis oder
welcher Freigabe die Daten gespeichert
sind. Das Ganze funktioniert lückenlos
auch beim Verschieben von Dateien in
Sharepoint-Bibliotheken.
Zusätzlich lässt sich über diesen Weg
auch festlegen, von welchen Geräten aus
Anwender auf die Daten zugreifen dürfen.
Unsichere PCs, Heim-Arbeitsplätze,
Computer in Internetcafés oder Smartphones
lassen sich so aussperren. Bitlocker-Laufwerksverschlüsselung
kann in
Windows Server 8 auch Clustervolumes
sichern. Das ist dann sinnvoll, wenn bestimmte
Daten nicht im lokalen Netzwerk
gespeichert sind, sondern bei einem
Cloudanbieter liegen.
Remotedesktop
Mit RemoteFX lassen sich Anwendungen
auf Remotedesktop-Servern (ehemals
Terminalservern), genauso betreiben wie
lokal installierte Anwendungen. In Windows
Server 8 verbessert Microsoft das
Protokoll noch einmal. Auf diesem Weg
lassen sich auf Tablets zum Beispiel Anwendungen
bedienen wie lokal installierte
Programme, obwohl sie auf einem
Remotedesktop-Server laufen. Auch leistungsschwache
Geräte können so Multimedia-Anwendungen
laufen lassen, der
Server bereitet die Daten auf und schickt
sie dann zum Client. Die Aufbereitung
der Daten verbessert Microsoft in der
neuen Version von RemoteFX dazu deutlich.
Auch RDP-Verbindungen zwischen
Windows-8-Clients nutzen RemoteFX, in
Windows Server 2008 R2 SP1 ist diese
Funktion nur Servern vorbehalten. Verbessert
hat Microsoft dazu auch den
neuen Remotedesktop-Client. Er verwaltet
jetzt alle konfigurierten Verbindungen
auf einem PC übersichtlich, ganz ohne
Zusatzwerkzeuge.
Keine ARM-Unterstützung
Auch wenn es einige Gerüchte dazu im
Internet gibt, wird Windows Server 8 laut
Bill Laing, dem Vice President für Server,
keine ARM-Prozessoren unterstützen.
Diese stehen aktuell nur als 32-Bit-Version
zur Verfügung. Windows Server 8
wird allerdings ausschließlich als 64-Bit-
Version auf den Markt kommen, wie der
Vorgänger Windows Server 2008 R2. Der
Windows-8-Client wird dagegen auch auf
ARM-Prozessoren laufen.
Fazit
Viele der neuen Fähigkeiten von Windows
Server 8 sind schon bekannt, alle
Funktionen sind derzeit allerdings noch
nicht offengelegt. Was schon klar ist:
Microsoft will mit dem neuen Server vor
allem in Cloud-Umgebungen und bei der
Virtualisierung punkten. Hier bietet die
neue Version zahlreiche neue Features,
die sogar kostenlos zur Verfügung stehen.
Ob sich eine Aktualisierung auf die neue
Version lohnt, lässt sich erst mit einer
endgültigen Version oder zumindest dem
Release-Kandidaten beurteilen. (ofr) n
Infos
[1] Windows Server 8: [http:// www. microsoft.​
com/ en‐us/ server‐cloud/ windows‐server/​
v8. aspx]
Der Autor
Thomas Joos ist freiberuflicher IT-Consultant
und seit über 20 Jahren in der IT tätig. Neben
seinen Projekten schreibt er praxisnahe Fachbücher
und Fachartikel rund um Windows und
andere Microsoft-Themen. Online trifft man ihn
unter [http:// thomasjoos. spaces. live. com].
60 Ausgabe 06-2011 Admin www.admin-magazin.de

Open Source goes
Präsentieren auch Sie sich auf der größten Sonderausstellung
der CeBIT 2012 zum Thema Linux und freie Software –
hervorragend platziert in Halle 2!
Kleine und mittlere Unternehmen treffen hier auf hochrangige Entscheider.
Nirgendwo sonst finden Sie eine bessere Business-Umgebung für Ihre
Open-Source-Lösungen.
Ein rundum perfekter Messeauftritt ‒
maximaler Erfolg mit minimalem Aufwand:
• individuelle Standgrößen ab 4 m²
• Alles-inklusive-Service (Standbau, Catering, Konferenzräume, u.v.m.)
• direkte Ansprache zahlreicher Neukunden
• ausgewählte Fachvorträge und Keynotes im Open Source Forum
• Kontakt zur internationalen Open Source Community
Jetzt anmelden!
www.open-source-park.de
oder 0 26 1 - 20 16 902
In Kooperation mit:
Veranstalter:
pluspol.de
Marketing Kommunikation Internet

Test
Archipel
Management virtueller Server mit Archipel
Rettungsinsel
Archipel hilft dem Administrator, Virtualisierungs-Umgebungen auf Basis von KVM, Open VZ, VMware, Xen,
Virtualbox oder LXC in einem einzigen GUI zu verwalten. ADMIN testet die Beta-Version 3, die einen ersten
eindruck vom zentralen Virtualisierungs-Management der Zukunft verschafft. Thomas Drilling
Der Umfang an Virtualisierungs-Technologien
hat anno 2011 ein beträchtliches
Ausmaß angenommen. Lässt man die
kommerziellen Akteure im Cloud-Business
von VMware, Citrix und Red Hat
mit ihren integrierten oder proprietären
Verwaltungslösungen außen vor, besteht
immer noch reichlich Bedarf, die nicht
minder interessanten Betriebssystem-,
Para- und Hardware-Virtualisierer LXC,
Open VZ, VMware, Xen, Virtualbox und
KVM unter eine gemeinsame Verwaltungsoberfläche
zu bringen, woran Libvirt
[1] einen maßgeblichen Anteil hat.
Das mit Spannung erwartete Archipel [2]
von Antoine Mercadal basiert auf Libvirt
und dem XMPP-Protokoll. Archipel unterstützt
alle Virtualisierungstechnologien,
für die Libvirt entsprechende Treiber bereithält.
Aktuell sind das KVM/​Qemu,
Xen, Linux Containers (LXC), Open VZ,
User Mode Linux (UML), VMware GSX/​
ESX, VMware Workstation/​Player, Microsoft
Hyper-V und seit einiger Zeit auch
Virtualbox. Damit steht Archipel auch in
Konkurrenz zu Red Hats Virtual Machine
Manager (VMM) [3] und verschiedenen
anderen GUIs für KVM/​Qemu [4].
Red Hats eigene Enterprise-Virtualisierung
(RHEV) basiert zwar ebenfalls auf
KVM, enttäuschte Admins aber bis einschließlich
der Version 2.2 dadurch, dass
eine Administration unter Linux kaum
sinnvoll möglich war, weil Red Hat auf
Microsofts Management-Konsole setzt.
Sogar der Einsatz des hauseigenen Virt-
Managers scheitert am Einsatz zwar
leistungsfähiger aber leider vollkommen
neuer Technologien wie Spice. Immerhin
verspricht die neue Version 3 mit integriertem
Virtualization Manager als Java-
Anwendung Besserung.
Vielfältig
Wer jedoch seine Virtualisierungs-
Infrastruktur mit KVM, Xen oder VMware
ESX/​GSX betreibt oder ausschließlich Betriebssystem-Virtualisierung
(Ressource
Container) betreibt, dem steht mit Archipel
in Kürze ein leistungsfähiges Werkzeug
zur Verfügung. Ähnlich integrative
Ansätze verfolgen die von ADMIN bereits
vorgestellten Virtualisierungslösungen
von Univention [5] und Proxmox [6].
Archipel befindet sich noch in einem frühen
Entwicklungsstadium. Die aktuelle
Beta-Version 3.2 von Archipel [7] vom
Juli 2011 dient als Grundlage des Tests im
Rahmen einer kleinen Installation.
Archipel bietet eine Weboberfläche zum
Verwalten virtueller Maschinen und verwendet
zur Kommunikation das XMPP-
Protokoll und zum Verwalten virtuelle
Maschinen die Libvirt. Damit ist Archipel
in der Lage, heterogene Landschaften von
virtuellen Maschinen zentral zu verwalten
und zu überwachen, im Wortlaut der
Archipel-Entwickler zu „orchestrieren“.
Archipel bereitet unter anderem die aktuellen
Betriebsparameter der einzelnen
VMs in Echtzeit grafisch auf. Libvirt ist
eine freie C-Bibliothek, die über ein eigenes
API eine einheitliche Schnittstelle
zum Verwalten verschiedener Virtualisierungslösungen
zur Verfügung stellt und
zu deren Unterstützung eigene Treiber
für KVM, Virtualbox, VMware, Xen, LXC,
Open VZ und so weiter mitbringt.
Die Bibliothek fungiert mit ihrer API
als Abstraktionsschicht zwischen Virtualisierungssoftware
und Management-
Werkzeugen. XMPP dürfte vielen Admins
unter der Bezeichnung Jabber bekannt
© arquiplay77, Fotolia
62 Ausgabe 06-2011 Admin www.admin-magazin.de

Archipel
Test
Abbildung 1: Die physische Archipel-Infrastruktur
besteht aus dem oder den Archipel-Agenten, die auf
dem jeweiligen Hypervisor laufen, einem zentralen
XMPP-Server (Jabber), sowie einem Webserver, der
die GUI für die anfragenden Browser-Clients zur
Verfügung stellt.
sein und versteht sich als „erweiterbares
Nachrichten- und Anwesenheitsprotokoll“.
XMPP hält sich an den XML-
Standard und kommt primär für Instant
Messaging zum Einsatz, es gibt aber verschiedene
XMPP-Erweiterungen. Jabber
wird seit 1999 von Peter Saint-Andre entwickelt.
Mit der Verabschiedung als IETF-
Standard im Jahr 2004 wurde Jabber offiziell
in XMPP (Extensible Messaging and
Presence Protocol) umbenannt.
Die grafische Benutzeroberfläche von
Archipel basiert auf dem Capuccino-
Javascript-Framework [8], mit dem die
Entwickler versuchen, das Look-and-Feel
von Mac OS im Browser nachzubilden.
Zur grafischen Fernsteuerung der virtuellen
Maschinen dient auch bei Archipel
das VNC-Framework, allerdings verzichtet
Archipel vollständig auf Flash und
Java und setzt am Webclient durchgängig
auf Javascript. Außerdem ist Archipel
modular aufgebaut und soll sich künftig
auch durch ein SDK erweitern lassen.
Die aktuelle Beta-Version 3.2 steht unter
[7] zum Download zur Verfügung.
Wer es noch aktueller mag, kann sich
die Nightly-Builds unter [9] zu Gemüte
führen. Beide Quellen bieten Agents und
Clients in Form kompletter Tar-Pakete
zum schnellen Download an. Über die
auf Github gehosteten Quellen kann der
Admin optional auch direkt auf möglicherweise
aktuellere Bestandteile des
Abbildung 2: Aus Sicht der Kommunikations-Infrastruktur
steht der XMPP-Server im Zentrum der Architektur und
kommuniziert via XMPP mit dem Hypervisor, den virtuellen
Maschinen und den Benutzern.
Archipel-Projektes zugreifen. Archipel ist
unter der AGPL v3 lizensiert und damit
frei verfügbar.
Architektur
Ein Archipel-Szenario („Archipel Datacenter“)
besteht aus einem oder mehreren
Hypervisor-Systemen (Xen, KVM,
VMware), auf denen der sogenannte Archipel-Agent
läuft, einem Jabber-Server
(XMPP) als Kommunikationszentrale,
dem Webserver zum Bereitstellen der
GUI sowie den jeweiligen Clients. Alle
Komponenten können auf einem physischen
Host oder auch auf getrennten
Maschinen laufen. Das Installieren aller
Komponenten auf einer einzigen Maschine
ist, außer eben zu Testzwecken,
in der Regel wenig sinnvoll. In der Praxis
sollte typischerweise ein KVM-, Xen, oder
ESX-Hypervisor zum Einsatz kommen. In
unserem Beispiel dient dieser gleichermaßen
als Jabber- und Web-Server (Abbildung
1, Abbildung 2).
Archipel ist größtenteils in Objective-J
(60 Prozent) und Python (35 Prozent)
geschrieben; lediglich der Client ist pures
Javascript. Der Archipel-Agent läuft
auf dem Hypervisor und besteht aus den
Modulen Libvirt-Python (Abbildung 3),
Archipel-Core und Xmpppy.
Der Archipel-Client ist eine typische Webanwendung
(Javascript), die im Browser
auf dem Client-Rechner läuft. Die Installation
von Archipel ist übrigens im
englischsprachigen Wiki auf der Github-
Seite gut dokumentiert. Der folgende
Workshop fußt zum Teil auf der englischsprachigen
Dokumentation. Wer Archipel
aus den fertig geschnürten Paketen
oder den Nightly-Builds installiert,
sollte mit den folgenden Handreichungen
gut zurechtkommen. Für
das Beispiel haben wir Archipel
auf einem aktuellen Kubuntu-System
(11.04) mit KVM installiert,
und zwar der Einfachheit wegen
Agent, Client, Web- und Jabber-
Server auf der gleichen Maschine,
was in freier Wildbahn wohl eher
die Ausnahme sein dürfte.
Die meisten der folgenden Schritte
lassen sich problemlos auf andere
aktuelle Debian-Systeme übertragen.
Das Installieren von Archipel
aus den Quellen ist aufwendiger,
unter [13] aber ebenfalls gut dokumentiert.
Ein Java Developement Kit (Sun
JDK oder Open JDK) wird übrigens nur
beim Installieren aus den Quellen benötigt
und dort auch nur für die Cappuccino
Build Tools. Der Admin kann das
SDK später problemlos wieder entfernen.
Archipel selbst braucht kein Java.
Das Installieren von Webserver und
Client verursacht den geringsten Aufwand,
denn der Client besteht nur aus
Javascript-Code. Außerdem braucht er im
Gegensatz zu den heute üblichen Webanwendungen
weder ein Backend noch
PHP, Java/​Servlets oder irgendetwas anderes.
Es genügt, das von [7] oder [9]
heruntergeladene Archiv im gewünschten
Vhost- oder Documentroot-Verzeichnis
auf dem Webserver zu entpacken. Wir
haben uns im Beispiel für den aktuellen
Nightly-Build entschieden.
wget http://nightlies.archipelproject.orgU
/latest‐archipel‐client.tar.gz
tar ‐vxf latest‐archipel‐client.tar.gz
sudo mv Archipel Pfad zum Webserver‐Root
Abbildung 3: Der Python-Interpreter besitzt,
sofern das Paket Python-Libvirt installiert ist,
eine Schnittstelle zur Libvirt, die wiederum über
den jeweiligen Treiber mit dem Hypervisor-Kernel
kommuniziert.
www.admin-magazin.de
Admin
Ausgabe 06-2011
63

Test
Archipel
der Domain anzugeben. Der Host muss
also im DNS-System unter diesem Namen
bekannt sein. Die im Folgeschritt erfragte
Admin-ID ist eine Jabber-ID (JID) mit
administrativen Rechten. Der Admin
kann diese später unter anderem dazu
verwenden, sich über einen beliebigen
XMPP-Client unter der URL »http://
Hostname:5280/admin« am XMPP-Server
anzumelden, also nicht nur am Archipel-
Frontend. Ejabberd kennt eine Reihe von
Kommandozeilen-Optionen, darunter
die oben erwähnten zum Anlegen oder
Löschen von Benutzern:
sudo ejabberdctl register BenutzernameU
Servername Passwort
Das Löschen erfolgt analog mit
sudo ejabberdctl unregister BenutzernameU
Servername
Abbildung 4: Das Web-GUI von Archipel wirkt modern und aufgeräumt. Dank purem Javascript setzt es auf
Serverseite keine speziellen Frameworks voraus.
Ist der Webserver bereits konfiguriert und
aktiv, steht das Archipel-Web-GUI sofort
unter »http://Server/Archipel‐Verzeichnis«
zur Verfügung (Abbildung 4).
Für das Konfigurieren des Webservers,
insbesondere dessen Sicherheitsmerkmale,
ist der Admin allerdings selbst
zuständig. Da der Archipel-Client kein
Backend benötigt, ist es ratsam, den
Empfehlungen der Archipel-Entwickler
zu folgen und auf eine schwergewichtige
Apache-Installation zugunsten von
Lighttpd zu verzichten, der sich bei
Ubuntu problemlos über das Paketmanagement
installieren lässt.
sudo apt‐get install lighttpd
Dessen Documentroot lässt sich in der
Basis-Konfiguration unter »/etc/lighttpd/
lighttpd.conf« nach Bedarf anpassen.
Jabber-Server installieren
Jetzt fehlt noch ein Server, der das XMPP-
Protokoll unterstützt, das vom Instant-
Messaging-Dienst Jabber bekannt ist.
Die meisten Linux-Distributionen bringen
verschiedene Jabber-Server mit. Wir
haben uns im Test mit Ejabberd für die
von den Archipel-Entwicklern empfohlenen
Jabber-Version entschieden, die sich
über das Paket-Management installieren
lässt:
sudo apt‐get install ejabberd
Archipel braucht außerdem das
Ejabberd-Modul »mod_admin_extra«,
das bei den meisten Distributionen Teil
des Ejabberd-Paketes ist. Je nach verwendeter
Archipel-Version (< Beta 3) ist
außerdem das Modul »ejabberd_xmlrpc«
erforderlich. Erfreulicherweise stellen die
Archipel-Entwickler auf der Github-Seite
eine passende Konfigurationsdatei »/etc/
ejabberd/ejabberd.cfg« als Vorlage zur
Verfügung. Der Admin muss hierin lediglich
den Platzhalter »FQDN« durch den
Hostnamen seines Jabber-Servers ersetzen.
Hat er die geänderte Konfigurationsdatei
»ejabberd.cfg« an die angegebene
Position kopiert, kann er den Daemon
neu starten:
sudo service ejabberd restart
Vor dem ersten Test braucht der Jabber-
Server einen Admin-Benutzer, der sich
wie folgt anlegen lässt:
ejabberdctl register admin Hostname Passwort
Ubuntu- oder Debian-Nutzer können
Ejabberd wahlweise auch mit »sudo
dpkg‐reconfigure ejabberd« konfigurieren.
Das Dpkg-Skript fragt dann den
Hostnamen des Servers und anschließend
den gewünschten Admin-Account
ab. Ersterer ist als Hostnamen inklusive
Nun fehlt noch der Archipel-Agent auf
dem Hypervisor. Im Beispiel haben wir
den Client der Einfachheit halber auf dem
Hypervisor (Node) installiert. Die weitere
Vorgehensweise setzt voraus, dass dieser
bereits läuft und installiert ist. Ist das
noch nicht der Fall, muss der Admin die
notwendigen Voraussetzungen schaffen,
was bei einem aktuellen Ubuntu-System
11.04 durch Installieren von KVM und
Python meist schnell erledigt ist, denn
das Paketmanagement kümmert sich zuverlässig
um aufzulösende Paket-Abhängigkeiten.
Der Vollständigkeit halber seit trotzdem
erwähnt, was ein Archipel-Agent im Einzelnen
braucht: Neben einem Kernel mit
KVM-Unterstützung sowie einer CPU mit
VT-Erweiterung sind das vor allem möglichst
aktuelle Versionen von KVM (0.13),
Qemu (0.12.5), Libvirt (0.8.7 oder höher)
und Python (2.5 oder höher). Darüber
hinaus empfiehlt sich die Installation der
Pakete »python‐magic«, »python‐imaging«
und der »python‐setuptools«. Außerdem
setzt das Archipel-Setup die »libvirtpython‐bindings«
in Form des Paketes
»python‐libvirt« voraus.
Zum Installieren des Archipel-Agents
kann der Admin zwischen der manuellen
Variante auf Basis der Sourcen
oder Nightly-Builds und der wesentlich
einfacheren und schneller umsetzbaren
Variante via Pypi wählen. Für den Produktivbetrieb
ist der erste Weg sicher
sinnvoll, im Beispiel-Setup haben wir uns
64 Ausgabe 06-2011 Admin www.admin-magazin.de

Archipel
Test
einzutragen: »http://Webserver:5280/
http‐bind«. Das Interface ergänzt den
String aber beim korrekten Eintragen der
JID in der Form »admin@Jabber‐Server«
automatisch (Abbildung 6).
Sollte die GUI trotzdem nicht starten,
kann der Administrator mit
sudo ejabberdctl connected_users
prüfen, ob sich der Archipel-Agent erfolgreich
beim Ejabberd anmelden konnte.
Übrigens ist es, wie von den Entwicklern
empfohlen, eine gute Idee, in »/etc/archipel/archipel.conf«,
für »machine_ip« statt
»auto« die tatsächliche IP zu verwenden.
Beim Betrieb auf demselben Rechner ist
zwingend 127.0.0.1 zu verwenden. Jetzt
sollten sich existente KVM- oder Xen VMs
an der Archipel-GUI verwalten lassen.
Abbildung 5: Eine passende Beispiel-Konfiguration für den Archipel-Agent findet sich im Wiki auf der Archipel-
Github-Seite. Im Prinzip ist dabei nur der Name des XMPP-Hosts an die eigene Installation anzupassen.
für Pypi entschieden. Dazu muss der Admin
lediglich das Paket »python‐pip« installieren.
Pip ist ein alternativer Installer
für Python-Pakete von Ian Bicking.
sudo apt‐get install python‐pip
Ist das geschehen, lässt sich der Archipel-Client
direkt von [pypi. python. org]
installieren.
sudo easy_install archipel_agent
Mit einem Aufruf »sudo archipelinitinstall«
sollte die Installation des
Archipel-Agents abgeschlossen sein. Allerdings
muss der Administrator noch
eine Reihe von Parametern in der Konfigurationsdatei
»/etc/archipel/archipel.
conf« anpassen, darunter etwa sämtliche
XMPP-Einstellungen, damit der Archipel-
Agent den Jabber-Server erreichen kann.
Eine Beispiel-Konfiguration findet sich
unter [15] (Abbildung 5).
Die wichtigsten Einstellungen sind im
nebenstehenden Kasten „Agenten-
Konfiguration“ zu finden. Wer die Beta
3 des Achipel-Agents installiert, kann
übrigens im Abschnitt »XMPPSERVER«
den XMLRPC-Mode aktivieren, was das
Verwenden der Shared-Roster-Group-
Funktion erlaubt und damit ein mühseliges
Installieren des XMPP-Moduls
»ejabberd‐xmlrpc« für Ejabberd (siehe
oben) obsolet macht. Mit dieser Einstellung
behandelt Archipel sämtliche
Hypervisor-Systeme als Ejabberd-Administratoren:
[XMPPSERVER]
...
use_xmlrpc_api = True
Der Archipel-Agent lässt sich mithilfe des
Initskriptes starten:
/etc/init.d/archipel start
oder auch manuell durch Eingabe von
»runarchipel«. Wurde der Jabber-Server
wie beschrieben aufgesetzt, sollte jetzt
die Anmeldung am Archipel-Webclient
möglich sein: Mit Jabber-ID und Passwort
ist der beim Einrichten des Jabber-Servers
angelegte Admin-Account gemeint. Bei
»BOSH service« ist der Hostname oder
die Adresse des Webservers wie folgt
Agenten-Konfiguration
Zwar stellen die Archipel-Entwickler eine Basis-
Konfigurationsdatei für den Archipel-Agent zur
Verfügung, diese ist allerdings mindestens in
den folgenden Punkten vom Admin an die eigenen
Wünsche anzupassen:
n »xmpp_server«: Hostname des Ejabberd-
Servers (nicht die IP-Adresse).
n »archipel_root_admins«: Gibt es mehr als einen
Admin-XMPP-Acount für Archipel, lassen
sich die verschiedenen JIDs hier kommasepariert
angeben.
n »machine_ip«: Der Parameter ist per Default
mit »auto« belegt, was allerdings in
der Praxis zu Problemen führte. Besser ist
Archipel verwenden
Hat sich der Admin erfolgreich an der
Archipel-GUI angemeldet, kann er im
Menü »Archipel | Preferences« zunächst
die GUI auf Deutsch einstellen und eine
Reihe weiterer Parameter anpassen (Abbildung
7).
Dank Javascript lässt sich die GUI fast
wie eine native Anwendung bedienen,
es gibt lediglich keine Kontextmenüs.
Die deutsche Lokalisierung ist außerdem
noch nicht vollständig, was man einer
Beta-Version aber nachsehen sollte. Zum
Hinzufügen eines Hypervisors muss der
Admin wie folgt vorgehen.
Damit der Archipel-Client mit einem
Archipel-Agent kommunizieren kann,
muss der Admin einen solchen seiner
Kontakt-Liste (Roster) auf der linken
Seite hinzufügen. Dazu dient das Menü
»Kontakte | Kontakt hinzufügen« oder
es, hier die IP-Adresse des Hypervisors manuell
einzutragen.
n »hypervisor_xmpp_jid«: Hier ist die JID des
Hypervisors einzutragen.
n »qemu_img_bin_path«: Der Pfad zum Qemu-
Img-Binary ist meist korrekt. Es genügt normalerweise,
die Einstellung zu überprüfen.
n »use_xmlrpc_api«: Sollte auf »True« gesetzt
sein, um das Ejabberd-XMLRPC-API verwenden
zu können. Das setzt allerdings voraus,
dass das Ejabberd-XMLRPC-Modul installiert
ist. Dann muss man auch die entsprechenden
Werte für »xmlrpc_host«, »xmlrpc_password«
und »xmlrpc_user« setzen.
www.admin-magazin.de
Admin
Ausgabe 06-2011
65

Test
Archipel
archipel/archipel.conf«. Die »‐‐uuid« ist
die Libvirt-UUID der existenten virtuellen
Maschine, »‐‐xmppserver« steht für den
aktuellen Archipel-XMPP-Server. Hinter
»‐‐name« folgt der Name für die VM und
ein optionales Zugriffs-Passwort.
Fazit
Abbildung 6: Für das Anmelden an dem Web-GUI wird die Jabber ID (JID) des XMPP-Admins benötigt.
alternativ ein Klick auf das Plus-Symbol
links unter der Kontaktliste gefolgt von
»Einen Kontakt hinzufügen«. Achtung:
Ein Kontakt ist hier kein User, sondern
die JID abzufragenden Hypervisors in der
Form »myfqdn@myfqdn«, den der Admin
durch einen frei wählbaren Nicknamen
für die Kontaktliste ergänzen kann. Lässt
er den Namen frei, erscheint in der Kontaktliste
der Name des Hypervisors. Die
Angabe »account@jabberserver« entspricht
dem Wert für »hypervisor_xmpp_
jid« in »/etc/archipel/archipel.conf«.
In Archipel ist jede virtuelle Maschine
eine XMPP-Entity, genau wie ein Hypervisor
selbst mit seiner eigenen JID. Um
eine virtuelle Maschine zu erzeugen,
stellt der Admin durch einen Klick auf
»Neue VM« eine entsprechende Anfrage
an den gewünschten Hypervisor, der bei
Erfolg mit dem Installations-Dialog für
eine neue virtuelle Maschine antwortet.
Mit den sogenannten Vmcasts bietet
Archipel übrigens ein leistungsfähiges
XML-Template-System zum Erzeugen
virtueller Maschinen (Abbildung 8).
fügung. Zuvor ist allerdings ein laufender
Archipel-Agent zu stoppen. Die Syntax
des Tools ist Folgende:
archipel‐importvirtualmachine ‐‐file=U
sqlite3DB ‐‐uuid=aUUID ‐‐xmppserver=aServerU
‐‐name=aName [‐‐password=aPassword]
Dabei ist ist »‐‐file« die Sqlite3-DB-Datei
des Hypervisors. Der Wert findet sich
bei »hypervisor_database_path« in »/etc/
Antoine Mercadals Archipel ist ein äußerst
vielversprechendes grafisches Werkzeug
zum Verwalten virtueller Libvirt-Maschinen.
Das Konzept geht weit über das
hinaus, was andere Libvirt-GUIs (siehe
Kasten „Weitere Libvirt-GUIs“) bisher
bieten und verspricht, eine universelle
Management-Konsole für beinahe beliebige
virtuelle Maschinen in der Cloud zu
werden. Archipel kann beispielsweise den
Status laufender virtueller Maschinen in
Echtzeit visualisieren und bietet innerhalb
der Oberfläche die Möglichkeit, in Echtzeit
Befehle an die beteiligten VMs abzusetzen
oder untereinander via XMPP zu kommunizieren.
Darüber hinaus lassen sich VMs
und Hypervisor(s) in Gruppen organisieren.
Auf diese Weise bietet Archipel eine
homogene Verwaltung sinstanz für Virtualisierungslösungen
wie KVM, Xen, Open
VZ, Virtualbox.
Das vollständig in Javascript realisierte
Web-Interface beeindruckt schon jetzt
durch sein modernes Look-and-Feel und
Libvirt-VMs importieren
Wer bereits einen KVM-Hypervisor im
Einsatz hat, kann auch bestehende
Libvirt-VMs importieren. Archipel stellt
dazu das Kommandozeilenwerkzeug
»archipel‐importvirtualmachine« zur Ver-
Abbildung 7: Das Web-GUI ist teilweise bereits deutsch lokalisiert. Weitere Konfigurations-Parameter dafür
finden sich im Preferences-Dialog.
66 Ausgabe 06-2011 Admin www.admin-magazin.de

Archipel
Test
Abbildung 8: Mit sogenannten Vmcasts haben die Archipel-Entwickler ein Template-System für virtuelle
Maschinen implementiert.
lädt zum Experimentieren ein. Während
Features wie die bereits implementierte
Geo-Lokalisierung virtueller Maschinen
im Unternehmens-Netz oder das Kommunikations-
und Nachrichtensystem
bereits gut funktionieren, gestaltet sich
die Inbetriebnahme derzeit noch etwas
holprig. Der von uns gewählte Weg via
Pypi unter Verwendung von Standard-
Konfigurationen für Jabber-Server, Webserver
und Archipel-Agent genügt zwar
für einen ersten Eindruck, wird aber den
Anforderungen an eine Produktivumgebung
noch nicht ganz gerecht. (ofr) n
Infos
[1] Libvirt: [http:// libvirt. org]
[2] Archipel: [http:// archipelproject. org]
[3] Red Hat Virt-Manager:
[http:// virt‐manager. org]
[4] GUIs für KVM: [http:// www. linux‐kvm. org/​
page/ Management_Tools]
[5] Thomas Drilling, Univention Corporate
Server als Virtualisierungsplattoform,
ADMIN 03/​11: [http:// www. admin‐magazin.​
de/ Das‐Heft/ 2011/ 03/ Univention‐Corporat
e‐Server‐fuer‐virtuelle‐Infrastrukturen]
[6] Thomas Drilling, Proxmox VE, ADMIN
05/​10: [http:// www. admin‐magazin. de/​
Das‐Heft/ 2010/ 05/ Container‐und‐Hardwar
e‐Virtualisierung‐unter‐einem‐Dach]
[7] Download von Archipel Beta 3.2:
[http:// archipelproject. org/ download]
[8] Cappuccino: [http:// cappuccino. org]
[9] Nightly-Builds:
[http:// nightlies. archipelproject. org]
[10] Archipel-Sourcen: [https:// github. com/​
primalmotion/ archipel]
[11] Archipel installieren: [https:// github. com/​
primalmotion/ archipel/ wiki]
[12] Jabber-Beispielkonfiguration: [https://​
github. com/ primalmotion/ Archipel/ wiki/​
Ejabberd%3A‐Configuration]
[13] Archipel-Client aus den Quellen
installieren: [https:// github. com/​
primalmotion/ Archipel/ wiki/​
Installation%3A‐Client]
[14] Archipel-Agent aus den Quellen
installieren: [https:// github. com/​
primalmotion/ Archipel/ wiki/​
Installation%3A‐Agent]
[15] Beispiel-Konfiguration Archipel-Agent:
[https:// github. com/ primalmotion/​
Archipel/ wiki/ Installation%3A‐archipel‐ag
ent%27s‐configuration‐file]
Weitere Libvirt-GUIs
Archipel beschränkt sich als ausgewachsene Management-Konsole nicht
nur auf einen Hypervisor-Host und unterstützt eine ganze Palette von
Virtualisierungs-Lösungen, sofern Libvirt sie unterstützt. Wer nicht auf
das finale Release warten möchte, findet im Open-Source-Umfeld weitere
Benutzeroberflächen für KVM/​Qemu, Xen oder Open VZ.
n Aqemu, [http:// sourceforge. net/ projects/ aqemu/]: Eine sehr ausgereifte,
fortgeschrittene Qt-Oberfläche zum Einrichten und Verwalten
von KVM/​Qemu-VMs im Stil von VMware Workstation. Aqemu lässt sich
unter Debian und Ubuntu via Paketmanagement durch Auswahl des
Pakets »aqemu« installieren.
n Qemulator, [http:// qemulator. createweb. de/ de/]: Noch eine grafische
Benutzeroberfläche für KVM- oder Wemu-VMs. Qemulator kann unter
Debian und Ubuntu via Paketmanagement über das Paket »qemulator«
installiert werden.
n QtEmu, [http:// qtemu. org]: Eine weitere Qt4-Oberfläche für Qemu.
Auch diese GUI lässt sich unter Ubuntu leicht durch Auswahl des Paketes
»qtemu« installieren.
n JQEMU, [http:// www. exprofesso. com/ jqemu/]: Eine Java-Oberfläche
für Qemu, die sich noch in der Entwicklung befindet. Derzeit läuft
JQEMU unter Linux mit JRE/​JDK 1.4 oder höher, beherrscht allerdings
nur die Optionen der Qemu-Version 0.8.0.
n Qemu Launcher, [http:// download. gna. org/ qemulaunch]: Auch der
Qemu Launcher bietet eine GUI zum Einstellen der Qemu-Optionen.
Ubuntu 11.04 bringt das Paket »qemu‐lauchner« derzeit nur in der
Version 1.7.4 mit. Es empfiehlt sich allerdings, die aktuelle Version
1.8.0 zu verwenden.
n Open QEMU Manager, [http:// sourceforge. net/ projects/​
openqemumanager/]: Open QEMU Manager bietet eine Weboberfläche
zum Verwalten von virtuellen Qemu/​KVM-Maschinen.
n QwebMon, [http:// research. xlab. si/ index. php? option=com_content&​
task=view& id=107& Itemid=142]: Eine Webapplikation zum Verwalten
von virtuellen Maschinen, die sich aber noch in einem sehr frühen
Entwicklungsstadium befindet.
n Enomalism, [http:// www. enomalism. com]: Realisiert eine Weboberfläche
zur VM-Verwaltung auf einem oder mehreren Hosts.
n Xenner, [http:// kraxel. fedorapeople. org/ xenner]: Das Tool Xenner ermöglicht
die Ausführung von Xen-Gastmaschinen unter KVM.
n ConVirt, [http:// www. convirt. net]: Das früher unter dem Namen
Xenman entwickelte Paket ist ein in Python geschriebenes grafisches
Management-Werkzeug für KVM und Xen.
n Proxmox Virtual Environment, [http:// pve. proxmox. com]: Das Proxmox
Virtual Environment ist eine auf Debian basierende 64-Bit-Linux-
Distribution, die als Virtualisierungsplattform ausgelegt ist, sich als
Appliance um das Aufsetzen eines KVM-Hypervisors kümmert und
gleichzeitig eine Web-GUI zum Verwalten von KVM und Open VZ zur
Verfügung stellt. Proxmox eignet sich auch zum Aufbau eines VM-
Clusters, in dem der Admin die Open-Source-Lösung auf mehreren
Hosts installiert.
www.admin-magazin.de
Admin
Ausgabe 06-2011
67

Security
LXC
Workshop: Container-Virtualisierung mit LXC
Eingedost
LXC legt mit wenig Overhead Systemcontainer an, um darin beispielsweise
sicherheitskritische Dienste zu isolieren. Als Anwender müssen Sie jedoch
einige Maßnahmen ergreifen, um ein System im System aufzubauen – und
überhaupt hineinzukommen. Eva-Katharina Kunst, Jürgen Quade
© Stefan Balk, Fotolia
Kommen Ihnen die großen Virtualisierungen
wie KVM, Xen, VMware oder Virtualbox
etwas klobig vor, wenn es nur
darum geht, einen einzelnen Dienst wie
einen Druckerspooler oder ein Intrusion
Detection System zu virtualisieren? Dieser
Workshop zeigt, wie Sie stattdessen
die leichtgewichtige Containervirtualisierung
LXC unter Ubuntu 10.04 zu diesem
Zweck einsetzen. Da LXC fester Bestandteil
des Kernels ist, benötigen Sie nur
die Userspace-Tools aus dem Paket »lxc«,
um damit erste Erfahrungen zu machen.
Die Zeile
none /cgroup cgroup defaults 0 0
in »/etc/fstab« hilft das zusätzlich not-
wendige, virtuelle Cgroup-Filesystem unter
»/cgroup« zu mounten.
Das reicht Root bereits, um ein einzelnes
Kommando – etwa eine Shell – in
einem Anwendungs-Container ablaufen
zu lassen:
lxc‐execute ‐n foo ‐f /usr/share/U
doc/lxc/examples/lxc‐macvlan.confU
/bin/bash
Das erzeugt gemäß der Konfigurationsdatei
»lxc‐macvlan.conf« den Container und
startet die Shell. Dass die in einer virtualisierten
Umgebung läuft, zeigt bereits der
Prompt an: Er trägt den geänderten Hostnamen.
Die Liste der Prozesse – durch
»ps auxw« aufgerufen – ist außerordentlich
übersichtlich, Kernelthreads fehlen
dort sogar vollständig. Und wenn Sie in
das Proc-Verzeichnis wechseln, sehen Sie
auch hier im Vergleich zum Hostsystem
die reduzierte Anzahl von Einträgen für
Prozesse.
Ein- und Mehrwegbehälter
Das Anlegen eines Systemcontainers ist
komplexer, weil Sie dafür ein komplettes
System installieren und vorbereiten
müssen. Außerdem will insbesondere auf
dem Host das Netzwerk konfiguriert sein.
Installieren Sie darum auf dem Hostsystem
zusätzlich die Pakete: »debootstrap«,
»bridge‐utils« und »libcap2‐bin«. Als Teil
der Netzkonfiguration benötigen Sie eine
Brücke, um den Container unter einer
eigenen IP-Adresse zu erreichen. Steht
der Inhalt aus Listing 1 in »/etc/network/
interfaces«, aktiviert »/etc/init.d/networking
restart« die Einstellungen.
Legen Sie nun ein Verzeichnis an, beispielsweise
»/lxc«, in dem Sie die Systemdateien
des Gastsystems ablegen. Ein
Unterverzeichnis davon repräsentiert das
Root-Filesystem des neuen Containers:
mkdir -p /lxc/rootfs.guest
Außerdem benötigen Sie eine Datei mit
Namen »/lxc/fstab.guest«, die Pfade zu
Mountpoints ähnlich wie in »/etc/fstab«
festlegt (siehe Listing 2).
Bereiten Sie jetzt das Gastsystem vor.
Dazu wechseln Sie in dessen eben angelegtes
Verzeichnis und erzeugen dort
mit dem Debian-Installer ein minimales
Linux-System (hier für die 64-Bit-Variante,
für die 32-Bit-Version tauschen Sie
»amd64« gegen »i386« aus):
debootstrap ‐‐arch amd64 lucidU
/lxc/rootfs.guest/U
http://archive.ubuntu.com/ubuntu
Jetzt müssen Sie das neue System noch
anpassen: Kommentieren Sie in der Datei
»/lxc/rootfs.guest/lib/init/fstab« die Zeilen
aus, die »/proc«, »/dev« und »/dev/
pts« mounten. Sie vergeben einen Hostnamen,
indem Sie die Datei »/lxc/rootfs.
guest/hostname« editieren. Im Beispiel
heißt das System »guest«. Schreiben Sie
dazu in die neue Datei »/lxc/rootfs.guest/
etc/hosts«:
127.0.0.1 localhost guest
Die nächsten Änderungen führen Sie direkt
im System aus, indem Sie mit Hilfe
von »chroot« vorläufig in die neue Umgebung
wechseln:
chroot /lxc/rootfs.guest /bin/bash
Um sich später in den Container einzuloggen,
bietet sich Open SSH an, das Sie
mit dem Paket »openssh‐server« installieren.
Nun fehlen noch ein Benutzer-
68 Ausgabe 06-2011 Admin www.admin-magazin.de

LXC
Security
account und ein geregelter Weg, um per
»sudo« an Root-Rechte zu gelangen. Dazu
legen Sie einen Benutzer an und machen
ihn zum Mitglied der Gruppe »admin«:
u=linuxmagazin; g=admin
adduser $u; addgroup $g; adduser $u $g
Editieren Sie mit Hilfe des Kommandos
»visudo« die Datei »/etc/sudoers«. Ersetzen
Sie dabei in der Zeile
%sudo ALL=(ALL) ALL
den Eintrag »sudo« durch »admin«. Danach
verlassen Sie die Chroot-Umgebung
durch »exit« wieder. Vor dem Test des
vorbereiteten Containers konfigurieren
Sie LXC noch in »/lxc/conf.guest« mit
dem Inhalt aus Listing 3 und passen in
Zeile 8 die IP-Adresse an. Mit
lxc‐create ‐n guest ‐f /lxc/conf.guest
bereitet LXC nun die Konfiguration auf.
Das ist Voraussetzung, um anschließend
das System mit »lxc‐start ‐n guest ‐d«
zu aktivieren. Die Option »‐d« führt das
Kommando im Hintergrund als Daemon
aus. Sie haben jetzt zwei Möglichkeiten,
sich auf dem virtualisierten System
einzuloggen: direkt per »lxc‐console -n
guest« oder – falls das Netzwerk auf Anhieb
funktioniert – per »ssh«:
ssh linuxmagazin@192.168.1.69
Beim Zugang per »lxc‐console« müssen
Sie allerdings etwas Geduld aufbringen.
Bis der Systemcontainer sie aktiviert,
kann es durchaus mehrere Minuten dauern!
Dann meldet sich der Container, wie
in Abbildung 1 zu sehen.
Recycling-Container
Um das System anzuhalten, verwenden
Sie vom Host aus das Kommando
»lxc‐stop ‐n guest«. Nach jeder Änderung
der Konfigurationsdatei »/lxc/conf.
guest« löschen Sie die alte Konfiguration
mit »lxc-destroy -n Gastname« und legen
mit dem Befehl »lxc-create« wieder eine
neue an.
Im LXC-Howto finden Sie die wichtigsten
Schritte zusammengefasst [1], optional
auch Ubuntu-Eigenheiten [2]. Mehr von
den LXC-Tools weiß ein IBM-Kernelentwickler
zu sagen [3]. Sind alle Konfigurationen
am rechten Ort, bietet LXC eine
flotte Alternative für die Trennung kleiner
Dienste, die sich untereinander nicht ins
Gehege kommen sollen. (mg/ofr) n
Infos
[1] Dwight Schauer, „LXC Howto“:
[http:// lxc. teegra. net]
[2] Beau Steward, „Virtualizing with LXC in
Ubuntu“: [http:// www. nimdae. com/ ? p=576]
[3] Matt Heisley, „LXC: Linux container tools“:
[http:// www. ibm. com/ developerworks/​
linux/ library/ l‐lxc‐containers/]
Die Autoren
Eva-Katharina Kunst, Journalistin, und Jürgen
Quade, Professor an der Hochschule Niederrhein,
sind seit den Anfängen von Linux Fans von Open
Source. Demnächst erscheint die dritte Auflage
ihres Buches „Linux Treiber entwickeln“.
01 auto lo
Listing 1: »/etc/network/interfaces«
02 iface lo inet loopback
03 # LXC‐Config
04 # The primary network interface
05 #auto eth0
06 #iface eth0 inet dhcp
07 auto br0
08 iface br0 inet dhcp
09 bridge_ports eth0
10 bridge_stp off
11 bridge_maxwait 5
12 post‐up /usr/sbin/brctl setfd br0 0
Listing 2: »/etc/fstab«
Abbildung 1: Die aktivierte Config startet den Container, was bisweilen einige Minuten dauert.
01 none /lxc/rootfs.guest/dev/pts devpts defaults 0 0
02 none /lxc/rootfs.guest/var/run tmpfs defaults 0 0
03 none /lxc/rootfs.guest/dev/shm tmpfs defaults 0 0
01 lxc.utsname = guest
02 lxc.tty = 4
03 lxc.network.type = veth
04 lxc.network.flags = up
05 lxc.network.link = br0
06 lxc.network.hwaddr = 08:00:12:34:56:78
07 #lxc.network.ipv4 = 0.0.0.0
08 lxc.network.ipv4 = 192.168.1.69
09 lxc.network.name = eth0
10 lxc.mount = /lxc/fstab.guest
Listing 3: Die Container-Konfiguration »conf.guest«
11 lxc.rootfs = /lxc/rootfs.guest
20 lxc.cgroup.devices.allow = c 5:0 rwm
12 lxc.pts = 1024
21 lxc.cgroup.devices.allow = c 4:0 rwm
22 lxc.cgroup.devices.allow = c 4:1 rwm
13 #
23 # /dev/{,u}random
14 lxc.cgroup.devices.deny = a
24 lxc.cgroup.devices.allow = c 1:9 rwm
15 # /dev/null and zero
25 lxc.cgroup.devices.allow = c 1:8 rwm
16 lxc.cgroup.devices.allow = c 1:3 rwm
26 lxc.cgroup.devices.allow = c 136:* rwm
17 lxc.cgroup.devices.allow = c 1:5 rwm
27 lxc.cgroup.devices.allow = c 5:2 rwm
18 # consoles
28 # rtc
19 lxc.cgroup.devices.allow = c 5:1 rwm
29 lxc.cgroup.devices.allow = c 254:0 rwm
www.admin-magazin.de
Admin
Ausgabe 06-2011
69

Security
Cloud-Sicherheit
Überlegungen zur Sicherheit in Clouds
Überwiegend heiter?
An Cloud-Computing führt kein Weg vorbei, wenn man Marketing und
Analysten glauben will. Doch wie sieht es mit der Sicherheit in der
Cloud aus? Einige Gedanken dazu… Kurt Seifried
Ob man das nun gut findet oder nicht:
Cloud-Computing setzt sich auf breiter
Front durch und wird uns auch eine
lange Zeit erhalten bleiben (darauf zu
wetten, ist ziemlich risikolos, angesichts
der Tatsache, dass Cobol und Fortran
auch noch nach 50 Jahren existieren).
Die gute Nachricht ist, dass Linux für die
Cloud-Provider wie auch die ‐Anwender
eine hervorragende Plattform ist.
Eine große Herausforderung beim Cloud-
Computing besteht darin, dass man keine
Kontrolle über die zugrunde liegende
Hardware wie das Netzwerk, Storage und
so weiter hat. Wer seine Anwendungen
in der Cloud laufen lässt, teilt vermutlich
die Hardware mit anderen, etwa auf
Amazons EC2. Für die Provider ist dieses
Modell toll, denn sie können jeden Cent
aus ihrer Hardware quetschen, indem
sie ungenutzte Ressourcen an Anwender
verkaufen, aber für die Enduser kann das
gelegentlich zum Problem werden.
Die Bandbreite der Anwendungen für
Cloud Computing erweitert sich gleichermaßen
ständig. Jeder kann sich plötzlich
selbst rechenintensive Aufgaben leisten,
etwa das Knacken von WLAN-Passwörtern
mit Tesla-Karten von Nvidia. Service-Provider
wie Google Apps erlauben
es, Webanwendungen bereitzustellen,
die mit Traffic-Spitzen umgehen können,
ohne dass man sich selbst darum kümmern
müsste. Letztlich stehen einem mit
den Cloud-Angeboten dieselben Möglichkeiten
zur Verfügung wie den großen
Webdienstleistern.
Aus Sicherheitsgründen müssen die Provider
sicherstellen, dass die Daten der
einzelnen Kunden sauber getrennt sind.
Im Fall von Infrastructure as a Service
(IaaS) haben sich die meisten zugrunde
liegenden Virtualisierungstechnologien
wie VMware, Xen oder KVM in dieser
Hinsicht als zuverlässig erwiesen und
trennen von Haus aus die einzelnen Instanzen.
Bei Platform as a Service (PaaS)
wie Google Apps liegen die Dinge etwas
komplizierter. Sehr wenige Programmiersprachen
lassen sich auf eine „sichere“
Weise für Anwender bereitstellen, die
zumindest potenziell Böses im Schilde
führen. Ein Beispiel dafür ist Java, das
zwar von Anfang an eine Art Sandbox
implementierte, in der aber dennoch immer
wieder schwerwiegende sicherheitskritische
Fehler gefunden werden.
Schließlich gibt es auch noch die Anbieter
von Software as a Service (SaaS), die
fertige Anwendungen bereitstellen und
damit so viele Anwender wie möglich
erreichen möchten. Da bleibt nur zu
hoffen, dass sie darauf acht geben, dass
diese Anwendungen weitgehend frei von
den üblichen Sicherheitslücken wie etwa
SQL-Injections und so weiter sind.
Verschlüsselt
Daten, die in der Cloud lagern, unterscheiden
sich auf vielerlei Art von lokalen
Daten, aber der wesentliche Punkt
ist, dass sie sich auf Systemen befinden,
die man nicht selbst kontrolliert. Noch
schlimmer: Sie liegen auf Systemen, die
man mit anderen teilt. Wenn nun etwa
ein Kunde etwas Illegales auf dem Server
anstellt, kann es sein, dass die Ermittlungsbehörden
die komplette Maschine
mitnehmen. Oder der Provider ist nicht
anders in der Lage, den entsprechenden
Aufforderungen nachzukommen [1].
Ein Provider könnte auch eine komplette
Festplatten mit sensiblen Daten zur Reparatur
außer Haus schicken oder alte
Hardware verkaufen, ohne sie vorher zu
löschen – falls das überhaupt vollständig
möglich ist [2]. Schließlich könnte auch
die Server-Infrastruktur so beschaffen
sein, dass sie zwar lokal und sicher erscheint,
in Wirklichkeit aber die eigenen
Daten übers Netzwerk fließen.
Selbst wenn es beim Provider entsprechende
Sicherheits-Policies gibt, die solche
Dinge abdecken, bringt das wenig,
wenn er irgendwann in Konkurs geht.
Beispielsweise sicherte Toysmart.com
seinen Kunden zu, niemals die persönlichen
Daten zu Geschäftszwecken zu
verwenden. Nach der Pleite fingen sie
aber plötzlich an, genau das zu tun. Die
Federal Trade Commission kam ins Spiel
und einigte sich mit der Firma darauf,
dass „der Verkauf dieser Kundeninformationen
verboten sei – außer im Fall sehr
spezieller Umstände“ [3].
Der erste Schritt zur Absicherung liegt
deshalb darin, die eigenen Daten zu verschlüsseln.
Wo auch immer Daten gespeichert
werden, sollten sie verschlüsselt
werden, und das umfasst mehr als nur
Storage und Datenbanken. Wer zum Beispiel
bei einer Webanwendung Message
Queues verwendet, muss damit rechnen,
dass sie auf die Festplatte geschrieben
werden, etwa das Binärlog von Beanstalkd.
NoSQL-Datenbanken schreiben
manchmal selbst Daten auf die Platte,
aber auch beim Swappen können sensible
Daten auf den Festspeicher gelangen.
70 Ausgabe 06-2011 Admin www.admin-magazin.de

Cloud-Sicherheit
Security
Glücklicherweise bietet Linux ausgereifte
Verschlüsselungsmechanismen dafür, inklusive
der Verschlüsselung kompletter
Festplatten, die per Default zur Verfügung
steht. Dummerweise bieten nicht alle
Provider einen vollwertigen Konsolenzugang,
der Vorausetzung dafür ist, die
komplette Platte zu verschlüsseln, denn
man muss beim Booten ein Passwort eingeben.
Bevor man die Verschlüsselung
der ganzen Festplatte in Betracht zieht,
muss man also erst einmal sicherstellen,
dass das überhaupt möglich ist.
Auch die zwischen einzelnen Rechnern
in der Cloud übertragenen Netzwerkdaten
müssen verschlüsselt werden. Beim
Einsatz von VLANs und Tunnels entsteht
leicht der Eindruck, es handle sich um
direkt nebeneinander stehende Systeme,
die sich aber tatsächlich in unterschiedlichen
Gebäudeteilen, vielleicht sogar in
unterschiedlichen Daten-Centern befinden.
Ich bin schon gespannt, wann die
erste Geschichte eines Einbruchs publik
wird, bei dem Einbrecher die virtuelle
Netzwerkinfrastruktur eines Providers
gehackt und dann Zugriff auf den Netzwerktraffic
aller Kunden erlangt haben.
Je nach Anwendung und Infrastruktur
gibt es verschiedene Möglichkeiten, den
Netzwerktraffic abzusichern. So lässt
sich mit IPsec der komplette Verkehr
zwischen Systemen verschlüsseln, während
sich SSL und SSH dafür eignen, die
Übertragung einzelner Dienste zu verschlüsseln.
Speicher
Letztlich befinden sich sensible Daten
immer noch ungeschützt im Speicher.
Das war in der Vergangenheit vielleicht
kein so großes Problem, als man noch
der alleine Benutzer eines Servers war.
Auf virtualisierten Systemen kann der
Hypervisor die Speicherbereiche aller
virtuellen Maschinen lesen. Wenn ein
Angreifer sich Zugriff zum Hypervisor
verschaffen kann, erlangt er damit auch
Zugang zum Speicher aller virtuellen Maschinen.
Wer also sensible Daten wie
Krypto-Schlüssel, SSL-Zertifikate oder
Kreditkartendaten verarbeiten will, sollte
in letzter Konsequenz auf den Einsatz in
der Cloud verzichten.
Viele Cloud-Computing-Systeme sind so
aufgebaut, dass sie so zustandslos wie
möglich arbeiten. So beeinträchtigt der
Ausfall eines Knotens das Gesamtsystem
nicht oder nur wenig. Im Extremfall sind
den Anwendern Ausfälle sogar willkommen
[4]. Einzelne Komponenten wie Datenbanken
(eventuell repliziert), Message
Queues oder Storage müssen dennoch
zuverlässig funktionieren. Eine Technologie
wie Ksplice [5], die das Patchen
des Kernels ohne Reboot erlaubt, macht
für Linux im Prinzip den ausfallsicheren
Betrieb möglich.
Für Provider ist der zuverlässige Betrieb
des Hypervisors von größter Bedeutung.
Unter allen Umständen will man es vermeiden,
virtuelle Maschinen im großen
Stil umzuziehen und ganze Farmen von
virtuellen Hosts neu booten zu müssen.
Derzeit ist Ksplice für Linux verfügbar,
aber mit etwas Glück wird es in Zukunft
noch für verbreitete Anwendungen erweitert.
Security Policy Framework
Das Militär ist typischerweise extrem paranoid,
wenn es um Datenschutz und
Sicherheit geht. Vermutlich weil sie wissen,
wie effektiv es ist, an die Daten
des Gegners zu kommen. Aus diesem
Grund hat die NSA die Entwicklung von
SELinux [6] gesponsort, einem System,
das Mandatory Access Control (MAC)
für Linux implementiert. Die meisten
Administratoren begrüßen die Idee von
SELinux: Man kann die Berechtigungen
einzelner Anwendungen und Dienste so
beschränken, dass ein Angreifer selbst
dann keinen großen Schaden anrichten
kann, wenn er sich Zugriff zu diesen
Anwendungen verschafft.
In der Praxis finden die meisten Administratoren
SELinux dann weniger toll, denn
es erschwert die Arbeit und behindert
die Funktion vieler Dienste. Ich musste
SELinux abschalten, weil damit Samba
(mit nicht standardisierten Shares) und
einige Webanwendungen nicht mehr
funktionierten. Für Service-Provider, insbesondere
Anbieter von PaaS, ist SELinux
dennoch eine sehr nützliche Sicherheitsmaßnahme.
Die meisten dieser Sicherheitsmaßnahmen
helfen Kunden wenig, wenn sie
sich mit einem böswilligen Provider
konfrontiert sehen. Die meisten Verschlüsselungsverfahren
basieren auf der
Geheimhaltung eines Schlüssels. Interessiert
sich der Provider für die Daten des
Kunden, ist es ein Leichtes, im Speicher
den Schlüssel zu finden. Oder er spiegelt
die entsprechenden Ports der Netzwerk-
Switches und schneidet den kompletten
Traffic mit. Wenn er an den Schlüssel
gelangt ist, kann er leicht alle Informationen
entschlüsseln, etwa gespeicherte
Kreditkarteninformationen.
Ein Einbrecher kann natürlich dieselben
Methoden anwenden, wenn er einmal
entsprechende Rechte erlangt hat. Provider
müssen deshalb Maßnahmen gegen
solche Angriffe treffen.
Die gute Nachricht
Trotz der erwähnten Herausforderungen
bei der Absicherung von Cloud-Systemen,
stellt Linux eine gute Basis für sichere
Clouds dar. SELinux beispielsweise gibt
es nun schon seit mehr als zehn Jahren
und ist entsprechend ausgereift. Auch in
den Hypervisor-Systemen wurden bisher
keine kritischen Bugs gefunden. Jetzt
ist es nur noch eine Frage der richtigen
Anwendung der passenden Tools,
um genügend Sicherheit in der Cloud zu
gewährleisten. (ofr)
n
Infos
[1] Cloud computing, law enforcement,
and business continuity: [http://​
berkeleyclouds. blogspot. com/ 2009/ 04/ clo
ud‐computing‐law‐enforcement‐and. html]
[2] Sanitizing SSDs:
[http:// nvsl. ucsd. edu/ sanitize/]
[3] FTC-Vereinbarung mit Toysmart.com:
[http:// www. ftc. gov/ opa/ 2000/ 07/​
toysmart2. shtm]
[4] 5 Lessons We’ve Learned Using AWS:
[http:// techblog. netflix. com/ 2010/ 12/ 5‐les
sons‐weve‐learned‐using‐aws. html]
[5] Ksplice: [http://www.ksplice.com]
[6] Thorsten Scherf, SELinux-Workshop,
ADMIN 02/​2008, S. 22
Der Autor
Kurt Seifried hat sich als
Security-Consultat auf
Linux und Netzwerke spezialisiert.
Er fragt sich oft,
wieso Technologie im großen
Maßstab funktioniert,
aber so häufig im Detail doch versagt.
www.admin-magazin.de
Admin
Ausgabe 06-2011
71

Know-how
Performance-Simulation
©nasa
Was wäre wenn? Mathematische Lastsimulation mit Perl
Berechenbare
Performance
Simulationen sind eine Möglichkeit, in die Zukunft zu schauen. Sie können zeigen, wie sich beispielsweise eine
Aufstockung der Hardware oder auch Laständerungen auswirken würden. Mit dem richtigen Know-how kann
jeder dieses Werkzeug nutzen. Neil J. Gunther
Drei aufeinanderfolgende Prozesse machen
das Performance-Management aus:
Monitoring, Analyse und Modellierung
(Abbildung 1). Das Monitoring sammelt
die Daten, die Analyse erkennt in ihnen
wiederkehrende Muster, und Modelle
sagen auf dieser Grundlage künftige Ereignisse
wie etwa Ressourcen-Engpässe
voraus. PDQ (Pretty Damn Quick) ist ein
Queueing-Analysetool in Gestalt eines
Perl-Moduls, das dazu dient, solche Vorhersagen
zu ermöglichen.
Einführung
Eine passende Monitoring-Lösung ist
ausgewählt, installiert und konfiguriert
– jetzt läuft sie im Produktivbetrieb. Das
aber ist nicht etwa das Ende, sondern ein
neuer Anfang und Ausgangspunkt. Eine
wesentliche Voraussetzung besteht zunächst
darin, die Leistung zu messen und
Performancedaten zu sammeln. Ohne Daten
lassen sich die Leistungseigenschaften
der zu überwachenden Systeme und
Applikationen nicht quantifizieren. Dies
ist die Aufgabe der Monitoring-Phase.
Das Monitoring auf sich alleine gestellt ist
aber so sinnlos wie das bloße Starren auf
die tänzelnden Zeiger im Cockpit eines
Autos. Um die Lage richtig einschätzen zu
können, muss man außerdem durch die
Windschutzscheibe schauen, um andere
Fahrzeuge in der Nähe zu erkennen. Mit
anderen Worten: Wer sich ausschließlich
auf das Monitoring verlässt, der erhält
lediglich einen kurzfristigen Eindruck
vom Systemverhalten (Abbildung 2).
Der Blick aus dem Fenster eröffnet dagegen
die Fernsicht. Doch je weiter weg ein
Beobachtungsobjekt ist, desto schwieriger
lässt sich mit Bestimmtheit sagen,
wie wichtig es einmal werden könnte.
Um aus Beobachtungswerten später Prognosen
ableiten zu können, muss man
die Leistungsdaten aus der Überwachungsphase
mit Zeitstempeln versehen
und sie in einer Datenbank speichern.
Darauf baut die nächste Phase, die Performance-Analyse
auf, die den Admin in
die Lage versetzt, die gewonnenen Daten
aus einer historischen Perspektive zu betrachten,
um in ihnen Muster und Trends
zu erkennen.
Auf das Performance-Modeling baut anschließend
die Leistungsvorhersage auf,
die Phase des Performance-Managements,
72 Ausgabe 06-2011 Admin www.admin-magazin.de

Performance-Simulation
Know-How
Queueing-Paradigmas vom realen System
abstrahieren. Allerdings verursacht diese
Vorgehensweise einen größeren Aufwand
als die Trendanalyse in den Rohdaten,
und sie setzt voraus, dass die Queueing-
Abstraktion das echte System genau
nachbildet. Je stärker das Modell von
der Wirklichkeit abweicht, desto höher
ist die Ungenauigkeit der Vorhersagen.
Wie dieser Artikel demonstriert, ist es
aber bei Weitem nicht so schwer, Wartedie
einen in die Lage versetzt, aus dem
Fenster und in die Zukunft zu blicken.
Dafür benötigt man zusätzliche Tools,
welche die Daten so aufbereiten, dass sie
in Leistungsmodelle eingehen können.
Dazu ist etwas Mathematik nötig.
Statistik versus
Warteschlange
Es gibt zwei klassische Ansätze für das
Performance-Modeling: die statistische
Datenanalyse und das Warteschlangenmodell.
Beide Methoden schließen sich
gegenseitig nicht aus. Die Unterschiede
lassen sich so beschreiben: Die statistische
Datenanalyse, eine Aufgabe, die
jede Buchhaltung kennt, basiert auf der
Berechnung von Trends in den Rohdaten.
Statistiker entwickelten viele schlaue
Techniken und Tools im Laufe der Jahre,
und ein Großteil dieser Intelligenz ist in
Form von Open-Source-Paketen für das
statistische Modeling erhältlich. Ein Beispiel
für ein mächtiges freies Tool dieser
Art ist R [2].
Dieser Ansatz ist jedoch dadurch begrenzt,
dass er sich ausschließlich auf
bestehende Daten stützt. Wenn die Zukunft
jedoch (angenehme oder unangenehme)
Überraschungen bereithält, die
sich aus den aktuellen Daten nicht erkennen
lassen, leidet die Zuverlässigkeit
der Vorhersage. Und wer sich etwa mit
der Börse beschäftigt, der weiß, dass dies
ständig geschieht.
Warteschlangenmodelle sind von diesen
Beschränkungen nicht betroffen. Das liegt
daran, dass sie per Definition mithilfe des
Performance analysis
Performance monitoring
Performance modeling
Past Present Future
Abbildung 1: Die drei Phasen des Performance-Managements – Monitoring, Analyse und Modeling – sind eng
miteinander verknüpft.
Abbildung 2: Ein 24-Stunden-Protokoll der durchschnittlichen Auslastung, das die Orca-Tools für Linux [1] auf
eine Zeitachse projizieren.
schlangenmodelle zu entwickeln als man
vermuten würde. In Wirklichkeit ist es oft
erstaunlich einfach.
Marschroute
Zu Anfang soll das bekannte Beispiel der
Warteschlange vor der Kasse im Supermarkt
grundlegende Queueing-Konzepte
erklären (Abbildung 3). Danach wird
dieses fundamentale Konzept so erweitert,
dass sich damit die Skalierbarkeit
einer dreischichtigen E-Commerce-Anwendung
vorhersagen lässt (Listing 3).
Gegen Ende des Artikels rücken schließlich
realitätsnahe Erweiterungen der vorgestellten
Leistungsmodelle und praktische
Ratschläge für ihren Aufbau ins
Blickfeld. Alle Beispiele verwenden Perl
und das Open-Source-Queueing-Analysetool
Pretty Damn Quick (PDQ), das
der Autor zusammen mit Peter Harding
pflegt. Es findet sich hier [6].
© Julien Rousset, Fotolia
Abbildung 3: Kunden stehen in einem Lebensmittelmarkt Schlange.
Warum Warteschlangen?
Buffer und Stacks sind in Computersystemen
allgegenwärtig. Beim Buffer handelt
es sich um eine Warteschlange, bei
www.admin-magazin.de
Admin
Ausgabe 06-2011
73

Know-how
Performance-Simulation
Mit anderen Worten: Ersetzt man auf der
rechten Seite der Gleichung die Verweilzeit
R durch die Servicezeit S, dann entder
die Reihenfolge des Eintreffens von
Anforderungen die Reihenfolge ihrer Abarbeitung
diktiert. Man spricht hier auch
von FIFO (first-in, first-out) oder FCFS
(first come, first served). Im Gegenzug
dazu bedient ein Stack Anforderungen
in LIFO-Reihenfolge (last-in, first-out);
es handelt sich um eine LCFS-Warteschlange
(last-come, first served). Unter
Linux ist etwa der History-Buffer der
Shell eine bekannte Warteschlange. Wie
jede physikalische Implementierung ist
er durch die endliche Menge an Speicherplatz
(die Kapazität) beschränkt. In der
Theorie kann eine Warteschlange jedoch
eine unbegrenzte Kapazität besitzen, so
wie das auch bei PDQ der Fall ist.
Eine Warteschlange ist eine gute Abstraktion
für gemeinsam genutzte Ressourcen.
Ein sehr bekanntes Beispiel ist die
Kasse im Supermarkt. Diese Ressource
besteht aus Aufträgen (den Menschen,
die Schlange stehen) sowie einer Bedienstation
(der Kassiererin). Wenn man mit
dem Einkaufen fertig ist, will man so
schnell wie möglich den Laden verlassen,
das ist das Performanceziel. Man kann
dieses Ziel auch so formulieren, dass es
darauf ankommt, möglichst wenig Zeit in
der Schlange zu verbringen – man spricht
hier von der Verweilzeit (R).
Nachdem sich ein Kunde für eine bestimmte
Kasse entschieden hat und sich
anstellt, besteht seine Verweilzeit aus
zwei Komponenten: zum einen aus der
Zeit, die er in der Warteschlange verbringt
bevor er zur Kasse gelangt, und
zum anderen aus der Zeit für die Bedienung
durch die Kassiererin, in der sie
die Einkäufe über den Scanner zieht,
das Geld annimmt und herausgibt. Geht
man nun davon aus, dass jede Person in
Tabelle 1: Leistungsmetriken
Symbol Metrik PDQ
l Ankunftrate Input
S Bedienzeit Input
N User-Last Input
Z Denkzeit Input
R Verweilzeit Output
R Antwortzeit Output
X Durchsatz Output
p Auslastung Output
Q Warteschlangenlänge
Output
N* Optimale Last Output
Warteschlange
der Warteschlange mehr oder weniger
die gleiche Menge Artikel im Einkaufswagen
hat, dann kann man erwarten,
dass sich die Bedienzeiten pro Kunde im
Schnitt angleichen. Darüber hinaus steht
die Länge der Warteschlange offensichtlich
im direkten Bezug zur Anzahl der
Kunden im Laden. Wenn der Supermarkt
fast leer ist, wird die durchschnittliche
Wartezeit um einiges kürzer sein als zu
Stoßzeiten.
Die Abstraktion der Warteschlange (Abbildung
4) bietet ein leistungsfähiges
Paradigma, mit dessen Hilfe sich (unter
anderem) die Leistung von Computersystemen
und Netzwerken ermitteln lässt.
Ihr besonderer Vorzug ist, dass sie die
ansonsten unterschiedlichen Leistungsdaten,
die die Monitoring-Tools liefern,
in einem Modell zusammenfasst.
Dieser Artikel nimmt immer wieder Bezug
auf die Metriken in Tabelle 1 und
zwar insbesondere auf die Beziehung
zwischen der Verweilzeit (R), der Servicezeit
(S) und der Ankunftrate (t):
S
R = 1−
λ S
Wartende
Kunden
Abbildung 4: Komponenten einer symbolischen Warteschlange.
1
Man kann Gleichung (1) als sehr einfaches
Performancemodell betrachten.
Die Eingaben für das Modell stehen auf
der rechten Seite, die Ausgaben auf der
linken. Nach genau demselben Schema
funktionieren auch die Berechnungen
mit PDQ. Durch dieses einfache Modell
sieht man sofort, dass bei geringem Publikumsverkehr,
die zum Passieren der
Kasse benötigte Zeit (die Verweilzeit)
ausschließlich aus der eigenen Servicezeit
besteht. Wenn keine weiteren Personen
eintreffen ( =0), dann fällt nur
die Zeit an, die man selbst benötigt, um
die Waren eingeben zu lassen und zu
bezahlen.
Wenn das Geschäft jedoch stark frequentiert
ist, sodass für das Produkt λS 1
gilt, dann steigt auch die Verweilzeit sehr
stark an. Das rührt daher, dass sich die
Länge der Warteschlange aus der Gleichung
Q
Kassierer
= λR
berechnet. Mit anderen Worten: Die
Verweilzeit steht im direkten Bezug zur
Warteschlangenlänge mal Eintreffrate
und umgekehrt.
Gleichung (2) stellt außerdem den Bezug
zu den Überwachungsdaten her. Die Daten
für die durchschnittliche Auslastung
in Abbildung 2 sind Echtzeitwerte, gemessen
über relativ kurze Zeitabschnitte,
beispielsweise eine Minute. Für die Berechnung
der Warteschlangenlänge (Q)
wird dagegen der Durchschnittswert über
die gesamte Messdauer von 24 Stunden
verwendet. Will man sich das bildlich
vergegenwärtigen, so kann man sich Q
als Höhe eines imaginären Rechtecks vorstellen,
das die gleiche Fläche hat wie
die Kurve der Überwachungsdaten über
demselben 24-Stunden-Zeitabschnitt.
Eine dazu analoge Beziehung gilt, wenn
man die Wartezeit aus der Verweilzeit (R)
in (2) ausklammert:
ρ = λS
Neuankömmlinge
Abgefertigte
Kunden
Kunden
werden bedient
2
3
74 Ausgabe 06-2011 Admin www.admin-magazin.de

Performance-Simulation
Know-How
interessiert, dem sei Kapitel 10 von [4]
empfohlen.
Eine der grundlegenden Annahmen in
PDQ ist, dass sowohl die durchschnittliche
Zwischenankunftszeit wie die durchschnittliche
Bediendauer beide statistisch
zufällig sind. Mathematisch gesehen bedeutet
das, dass jede Ankunft und jedes
Bedienereignis zu einem Poisson-Prozess
gehört. Dann entspricht die Dauer dem
Mittelwert einer exponentialen Wahrscheinlichkeitsstreuung.
Erlang hat festgestellt,
dass sich der Verkehr im Telefonnetz
tatsächlich dieser Anforderung
entsprechend verhält. Es gibt Methoden
[5], mit deren Hilfe sich feststellen lässt,
wie gut gegebene Monitoring-Daten diese
Anforderung erfüllen.
Wenn diese Monitoring-Daten wesentlich
von den Bedingungen des Exponentials
abweichen, ist es vielleicht sinnvoller,
auf einen ereignisbasierten Simulator wie
beispielsweise SimPy [3] auszuweichen,
mit dessen Hilfe sich eine größere Bandbreite
an Wahrscheinlichkeitsstreuungen
berücksichtigen lässt. Das Problem dabei
ist, dass die Programmierung und das Debuggen
mehr Zeit in Anspruch nehmen
(bei jeder Simulation geht es zugleich um
die Programmierung); außerdem braucht
man länger, um sicherzustellen, dass die
Ergebnisse statistisch gültig sind.
Ein weiterer Aspekt, der bei jeder wie
auch immer gearteten Vorhersage stört,
sind die Fehler, die grundlegende Annahmen
des Modells verursachen. Annahmen
in Modellen verursachen tatsächlich
systematische Fehler im Vorhersageprospricht
auf der linken Seite die Ausgabemenge
der Auslastung in Tabelle 1.
Geschichte der
Warteschlangentheorie
Die mathematische Theorie der Warteschlangen
ist noch sehr jung; tatsächlich
gibt es sie seit weniger als 100 Jahren.
Agner Erlang hat im Jahre 1917 das erste
formale Warteschlangenmodell entwickelt,
um die Leistung des Telefonsystems
(des Internets der damaligen Zeit)
zu analysieren. Seine Aufgabe bestand
darin, für Amtsgespräche aus Kopenhagen
die Puffergröße für Vermittlungen
festzulegen. Die heutige Terminologie
bezeichnet dieses Modell als Einzel-
Warteschlangenmodell.
Einer der nächsten wesentlichen Schritte
in der Entwicklung der Warteschlangentheorie
folgte 1957, als James Jackson
die ersten formalen Lösungen für die
Berechnung eines Netzwerks oder einer
Kette aus Warteschlangen entwickelte.
Dieses Ergebnis blieb 20 Jahre lang rein
akademisch, bis man schließlich den Bezug
zur Implementierung des Internets
erkannte. Das Warteschlangenmodell
erwies sich dafür als zutreffend mit einer
Abweichung von weniger als fünf
Prozent. 1967, etwa fünfzig Jahre nach
dem ersten Modell von Erlang, setzte ein
Doktorand namens Allan Scherr ein Warteschlangenmodell
ein, um die Leistung
der CTSS- und Multics-Time-Sharing-
Computersysteme zu berechnen, die in
vielen Beziehungen die Vorläufer der
Unix- und letztendlich damit auch der
Linux-Rechner waren.
zess, und daher sollte man sich alle PDQ-
Ergebnisse in Wirklichkeit als Streuung
plausibler Werte vorstellen. Was außerdem
oft unberücksichtigt bleibt, ist
die Tatsache, dass jede Quantifizierung
fehlerbehaftet ist. Davon sind auch die
Monitoring-Daten betroffen – aber wer
kennt schon den exakten Fehlerbereich
seines Monitoring?
Weil es sich bei allen PDQ-Performance-
Ein- und Ausgaben um Durchschnittswerte
handelt, ist unbedingt sicherzustellen,
dass es sich dabei um zuverlässige
Mittelwerte handelt. Die lassen
sich beispielsweise in der stabilen Phase
(steady state) eines Lasttests messen
(Abbildung 5). Der durchschnittliche
Durchsatz im stabilen Zustand (X) für
eine bekannte Benutzerlast (N) ergibt
sich, indem man Messungen über einen
längeren Zeitraum T vornimmt und alle
Anfahr- oder Herunterfahrzeiten aus den
Daten eliminiert. Eine nominelle Zeit T
kann beispielsweise fünf bis zehn Minuten
betragen, je nach Anwendung. Auch
bei Industriestandard-Benchmarks wie
SPEC und TPC gilt die Anforderung, dass
alle gemeldeten Durchsatzergebnisse aus
einem stabilen Zustand stammen.
Eine einfache
Warteschlange in PDQ
Die Beziehung zwischen dem Szenario
im Lebensmittelmarkt und den PDQ-
Funktionen fasst Tabelle 2 zusammen.
Nach diesem Schema kann man leicht
ein einfaches Modell der Kasse in einem
Fraktale Modelle
In den späten 70er- und frühen 80er-
Jahren haben einige neue theoretische
Entwicklungen zu vereinfachten Algorithmen
für die Berechnung der Leistungsmetriken
von Warteschlangensystemen
geführt. Diese Algorithmen sind
auch in Tools wie PDQ implementiert.
Bei den neuesten Entwicklungen in der
Warteschlangentheorie geht es um Modelle
für den sogenannten selbstähnlichen
oder fraktalisierten Paketverkehr im
Internet. Diese Begriffe sprengen zwar
den Rahmen dieses Artikels; Wer sich
aber für weiterführende Informationen
Instantaneous throughput
Ramp up Steady-state
Abbildung 5: Durchsatzmessungen im stabilen Zustand.
Ramp down
Elapsed time
www.admin-magazin.de
Admin
Ausgabe 06-2011
75

Know-how
Performance-Simulation
Lebensmittelmarkt nachbilden, wie das
folgende Listing für die Perl-Variante von
PDQ zeigt (Listing 1). Im PDQ-Code (unten)
befinden sich die Input-Werte für die
Ankunftsrate (λ) und die Bedienzeit (S):
λ = 3/
4
4
S = 10 .
5
Abbildung 6: Ein offenes System mit drei Queueing-Phasen.
Wendet man nun die metrische Beziehung
(2) an, ergibt sich die Auslastung
der Kasse wie folgt:
3*
1
ρ = = 075 .
4
Analog dazu ergibt sich für die Verweildauer
durch Anwenden der metrischen
Beziehungen (1) und (2):
10 .
R = = 40 . seconds
3
1−
*
4 10 .
So erfährt man, dass die Verweildauer an
der Kasse gleich vier durchschnittliche
Bedienzeiten ist, wenn der Kassierer zu
75% ausgelastet ist. Die sich daraus ergebende
durchschnittliche Warteschlangenlänge
ist:
3
Q = =
4* 40 .
Listing 1: Kassenmodell in PDQ
01 #! /usr/bin/perl
02 # groxq.pl
03 use pdq;
3.0 customers
6
7
8
04 #‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ INPUTS
‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
05 $ArrivalRate = 3/4; # Kunden je Sekunde
06 $ServiceRate = 1.0; # Kunden je Sekunde
07 $SeviceTime = 1/$ServiceRate;
08 $ServerName = "Cashier";
09 $Workload = "Customers";
10 #‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ PDQ Model
‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
11 # Interne PDQ‐Variable initialisieren
12 pdq::Init("Grocery Store Checkout");
13 # Die von PDQ::Report() genutzten
Einheiten anpassen
14 pdq::SetWUnit("Cust");
15 pdq::SetTUnit("Sec");
16 # PDQ Bedienknoten erstellen
Aus Platzgründen kann hier lediglich
die Ausgabeseite des generischen PDQ-
Reports für dieses Modell gezeigt werden
(Listing 1a).
Die berechneten PDQ-Werte stimmen genau
mit den theoretischen Vorhersagen
für den Durchsatz (X=λ), die Auslastung
(r), die Warteschlangenlänge (Q) und die
Verweildauer (R) überein.
Nachdem die fundamentalen Begriffe
bekannt sind und PDQ als Tool für die
Berechnungen eingeführt ist, lassen sich
diese Werkzeuge auch auf Computerprobleme
anwenden, etwa auf die Vorhersage
der Leistung individueller Hardware-
Ressourcen wie der Ausführungswarteschlange
der CPU (siehe Kapitel 4 in [5])
oder eines Festplattengerätetreibers.
Die meisten Lehrwerke zur Warteschlangentheorie
bieten Beispiele auf diesem
Niveau. Wichtiger für die Vorhersage der
Leistung von echten Computersystemen
ist allerdings die Fähigkeit, den Workflow
zwischen mehreren Warteschlangen-
Ressourcen abbilden zu können, also die
(KassiererIn)
17 $pdq::nodes =
pdq::CreateNode($ServerName, $pdq::CEN,
$pdq::FCFS);
18 # Die PDQ‐Aufgabe mit Ankunftsrate
erstellen
19 $pdq::streams =
pdq::CreateOpen($Workload,
$ArrivalRate);
20 # Bedienrate je Kunden an der Kasse
definieren
21 pdq::SetDemand($ServerName, $Workload,
$SeviceTime);
22 #‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ OUTPUTS
‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
23 # Das PDQ‐Modell lösen
24 pdq::Solve($pdq::CANON);
25 pdq::Report(); # einen vollständigen
PDQ‐Report generieren
Interaktion zwischen Anforderungen, die
gleichzeitig an Prozessoren, Festplatten
und das Netzwerk gestellt werden. Die
nächsten Abschnitte zeigen, wie man
diese Aufgabe mithilfe von PDQ erfüllt.
Warteschlangensysteme
Anforderungen, die aus einer Warteschlange
in eine andere fließen, entsprechen
einer Warteschlangenkette oder
einem Warteschlangennetz. Erfasst man
anstelle der Anzahl der Anforderungen
lediglich die Ankunftsrate (λ), spricht
man von einem offenen System oder
Kreis (Abbildung 6). Ein Beispiel für
eine Situation dieser Art, die nicht aus
der Welt der Computer stammt und sich
durch das offene Modell in Abbildung
6 abbilden ließe, wäre das Boarding am
Flughafen. Die drei Phasen sind: Warten
am Gate, Schlangestehen auf der Fluggastbrücke,
um ins Flugzeug zu gelangen,
und zum Schluss Schlangestehen
im Gang des Flugzeugs beim Boarding,
während Passagiere weiter vorn Platz
nehmen. Die durchschnittliche Antwortzeit
(R) ergibt sich aus den in jeder Warteschlangenphase
verbrachten Zeiten,
also der Summe der drei Verweildauern.
Im Computerkontext ließe sich das auf
eine dreistufige Webapplikation anwenden,
von der lediglich die Rate der HTTP-
Requests bekannt ist.
Eine weitere Art von Warteschlangensystemen
wird durch eine finite Menge (N)
von Kunden oder Anforderungen charak-
Tabelle 2: PDQ-Funktionen
Physikalisch
PDQ-Funktion
Warteschlange
Kunde Arbeitslast CreateOpen()
Kassierer Bedienknoten
CreateNode()
Buchhaltung Bedienzeit SetDemand()
76 Ausgabe 06-2011 Admin www.admin-magazin.de

Performance-Simulation
Know-How
terisiert. Genau diese Situation ergibt sich
bei einem Lasttest. Eine finite Menge von
Client-Lastgeneratoren sendet Anforderungen
an das Testsystem, wobei keine
weiteren Anforderungen von außerhalb
in das isolierte System eintreten können.
(Open-Source Last- und Stresstesttools
finden Sie unter [7].)
Darüber hinaus wirkt eine Art Rückkopplungsmechanismus,
weil zu jeder Zeit
nicht mehr als eine Anforderung unbearbeitet
bleiben darf. Mit anderen Worten:
Jeder Lastgenerator sendet erst dann eine
weitere Anforderung, wenn die vorherige
abgearbeitet worden ist. In der Sprache
der Warteschlangentheorie geht es hier
um einen geschlossenen Warteschlangenkreis.
Requests
N clients
Z = 0 ms
Responses
D ws
D as D db
Web Server App Server DBMS Server
Abbildung 7: Ein geschlossener Warteschlangenkreis mit drei Warteschlangenphasen in Verbindung mit einer
speziellen Wartephase (oben), die N Client-seitigen Lastgeneratoren mit einer durchschnittlichen Bedenkzeit
von Z entspricht.
E-Commerce-Applikation
in PDQ
Dieser Abschnitt zeigt, wie sich das
PDQ-Modell des geschlossenen Systems
aus Abbildung 7 einsetzen lässt, um
die Durchsatzleistung der dreistufigen
E-Commerce-Architektur aus Abbildung
8 vorherzusagen. Wegen der hohen Kosten
solcher Installationen sind Lasttests
mit einem kleineren Modell der späteren
Produktivumgebung die Regel. In unserem
Beispiel soll jeweils ein Server jede
Stufe abbilden. Ein Testsystem dieser Art
eignet sich sehr gut für Leistungsmessungen,
wie sie für die Parametrisierung
Tabelle 3: Bedienzeiten
N Sws Sas Sdb
1 0.0088 0.0021 0.0019
2 0.0085 0.0033 0.0012
4 0.0087 0.0045 0.0007
7 0.0095 0.0034 0.0005
10 0.0097 0.0022 0.0006
20 0.0103 0.0010 0.0006
Avg 0.0093 0.0028 0.0009
Tabelle 4: Leistungsdaten
N X R Sws Sas Sdb
(Clients) (GPS) (s) (%) (%) (%)
1 24 0.039 21 8 4
2 48 0.039 41 13 5
4 85 0.044 74 20 5
7 100 0.067 95 23 5
10 99 0.099 96 22 6
20 94 0.210 97 22 6
Der erste Versuch, die Leistungscharakteristik
von
Abbildung 7 nachzubilden,
stellt jeden Anwendungsserver
einfach als eigenständigen
PDQ-Knoten unter Eineines
PDQ-Modells vonnöten sind. Den
Durchsatz misst man in HTTP-Gets pro
Sekunde (GPS) und die entsprechende
Antwortzeit in Sekunden (s).
Aus Platzgründen konzentriert sich dieser
Artikel ausschließlich auf die Nachbildung
der Durchsatzleistung. Wer sich für
Antwortzeitmodelle interessiert, findet
dazu Einzelheiten in [5]. Die kritischen
Lasttestergebnisse für dieses Beispiel fasst
Listing 1a: PDQ-Report
01 *************************************
02 ***** Pretty Damn Quick REPORT ******
03 *************************************
04 *** of : Sun Feb 4 17:25:39 2007 ***
05 *** for: Grocery Store Checkout ***
06 *** Ver: PDQ Analyzer v3.0 111904 ***
07 *************************************
08 ****** RESOURCE Performance *******
09
10 Metric Resource Work Value Unit
11 ‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐ ‐‐‐‐ ‐‐‐‐‐ ‐‐‐‐
12 Throughput Cashier Customers 0.7500 Cust/Sec
13 Utilization Cashier Customers 75.0000 Percent
14 Queue Length Cashier Customers 3.0000 Cust
15 Residence Time Cashier Customers 4.0000 Sec
16 N Sws Sas Sdb
17 1 0.0088 0.0021 0.0019
18 2 0.0085 0.0033 0.0012
19 4 0.0087 0.0045 0.0007
20 7 0.0095 0.0034 0.0005
21 10 0.0097 0.0022 0.0006
22 20 0.0103 0.0010 0.0006
23 Avg 0.0093 0.0028 0.0009
Tabelle 4 zusammen. Leider wurden die
Daten nicht mit einer gleichbleibenden
Inkrementierung der User-Last erzeugt,
was für eine korrekte Leistungsanalyse
nicht gerade optimal ist, aber dennoch
kein unüberwindliches Problem darstellt.
X und R sind Systemmetriken auf der
Clientseite. Die Auslastung wurde eigenständig
durch Performance-Monitore
auf jedem der lokalen Server gemessen.
Die gemessene Auslastung
(r) und der Durchsatz (X)
in Tabelle 4 lassen sich in
eine umgestellte Version der
Gleichung (3) einsetzen,
um die entsprechenden Bedienzeiten
für jede Stufe zu
ermitteln:
S
= ρ
X
9
Der nächste Abschnitt
zeigt, wie der Durchschnittswert
der ermittelten
Bedienzeiten (die letzte
Zeile in Tabelle 3) einzusetzen
ist, um das PDQ-
Modell zu parametrisieren.
Naives PDQ-Modell
www.admin-magazin.de
Admin
Ausgabe 06-2011
77

Know-how
Performance-Simulation
satz der durchschnittlichen Bedienzeiten
aus Tabelle 3 dar. In Perl::PDQ wird die
Parametrisierung der Warteschlangenknoten
so, wie in Listing 2 zu sehen,
codiert.
Ein Diagramm des Durchsatzes, den dieses
erste, sehr einfache Modell vorhersagt,
zeigt die Abbildung 9. Man sieht
auf den ersten Blick, dass das naive PDQ-
Modell einen Durchsatz prophezeit, der
im Vergleich mit den real gemessenen
Daten der Testumgebung zu schnell absättigt.
Allerdings teilt uns PDQ ebenfalls mit,
dass der bestmögliche Durchsatz für
dieses System – auf Basis der gemessenen
Listing 2: Parametrisierung
01 pdq::Init($model);
02 $pdq::streams = pdq::CreateClosed($work, $pdq::TERM,
$users,
03 $think);
04 ...
05 # eine Warteschlange für jede der drei Stufen
erstellen
06 $pdq::nodes = pdq::CreateNode($node1, $pdq::CEN,
$pdq::FCFS);
07 $pdq::nodes = pdq::CreateNode($node2, $pdq::CEN,
$pdq::FCFS);
08 $pdq::nodes = pdq::CreateNode($node3, $pdq::CEN,
$pdq::FCFS);
09 ...
10 # Zeitbasis sind Sekunden, die in Millisekunden
ausgedrückt werden
11 pdq::SetDemand($node1, $work, 9.3 * 1e‐3);
12 pdq::SetDemand($node2, $work, 2.8 * 1e‐3);
13 pdq::SetDemand($node3, $work, 0.9 * 1e‐3);
Bedienzeiten aus Tabelle 3 – etwa 100
GPS beträgt. Diese Leistung wird durch
einen Ressourcen-Engpass begrenzt (die
Warteschlange mit der längsten durchschnittlichen
Bedienzeit), das ist im
Beispiel der Webserver. Ihn muss man
belasten, sodass der maximale Durchsatz
nicht über einen Wert steigen kann, der
sich aus der Beziehung (10) ergibt.
X
max
1
=
max( S , S , S )
ws as db
1
=
0,
0093
= 107.
53 GPS
Load
Drivers
Load
Balancer
Web
Servers
Abbildung 8: Multitier-E-Commerce-Anwendung.
Der höchstmögliche Durchsatz wird, wie
sich hier zeigt, in unmittelbarer Nähe des
errechneten optimalen Belastungspunkts
N* erreicht (siehe Tabelle 1):
N
*
Sws + Sas + Sdb
+ Z
=
max( S , S , S )
ws as db
00093 . + 0. 0028 + 0. 0009 + 00 .
=
0.
0093
= 140 . clients
Der liegt bei 1.40 Clients. Ändern sich die
Bedienzeiten in Zukunft, beispielsweise
durch eine neue Release der Anwendung,
kann sich der Ressourcen-Engpass verschieben;
das PDQ-Modell kann dann die
Auswirkung Durchsatz und Antwortzeiten
vorhersagen.
Application
Cluster
Disk Array
Database
Server
Listing 3: E-Commerce-Modell
01 #! /usr/bin/perl
02 # ebiz_final.pl
03 use pdq;
04 use constant MAXDUMMIES => 12;
05
06 # Hash AV pairs: (in vusers laden, durchsatz in gets/sec)
07 %tpdata = ( (1,24), (2,48), (4,85), (7,100), (10,99), (20,94) );
08
09 @vusers = keys(%tpdata);
10 $model = "e‐Commerce Final Model";
11 $work = "ebiz‐tx";
12 $node1 = "WebServer";
13 $node2 = "AppServer";
14 $node3 = "DBMServer";
15 $think = 0.0 * 1e‐3; # wie beim testsystem
16 $dtime = 2.2 * 1e‐3; # dummy‐bedienzeit
17
18 # Header für benutzerspezifischen Report
19 printf("%2s\t%4s\t%4s\tD=%2d\n", "N", "Xdat", "Xpdq", MAXDUMMIES);
20
21 foreach $users (sort {$a $b} @vusers) {
22 pdq::Init($model);
23 $pdq::streams = pdq::CreateClosed($work, $pdq::TERM, $users, $think);
24 $pdq::nodes = pdq::CreateNode($node1, $pdq::CEN, $pdq::FCFS);
25 $pdq::nodes = pdq::CreateNode($node2, $pdq::CEN, $pdq::FCFS);
26 $pdq::nodes = pdq::CreateNode($node3, $pdq::CEN, $pdq::FCFS);
27
28 # Zeitbasis in Sekunden " in Millisekunden ausgedrückt
29 pdq::SetDemand($node1, $work, 8.0 * 1e‐3 * ($users ** 0.085));
30 pdq::SetDemand($node2, $work, 2.8 * 1e‐3);
31 pdq::SetDemand($node3, $work, 0.9 * 1e‐3);
32
33 # Dummy‐Knoten mit entsprechenden Bedienzeiten erstellen ...
34 for ($i = 0; $i < MAXDUMMIES; $i++) {
35 $dnode = "Dummy" . ($i < 10 ? "0$i" : "$i");
36 $pdq::nodes = pdq::CreateNode($dnode, $pdq::CEN, $pdq::FCFS);
37 pdq::SetDemand($dnode, $work, $dtime);
38 }
39
40 pdq::Solve($pdq::EXACT);
41 printf("%2d\t%2d\t%4.2f\n", $users, $tpdata{$users},
42 pdq::GetThruput($pdq::TERM, $work));
43 }
78 Ausgabe 06-2011 Admin www.admin-magazin.de

Performance-Simulation
Know-How
Offensichtlich ist es wünschenswert, den
gesamten Datenbestand besser nachzubilden
als das mit dem naiven PDQ-Modell
gelang. Eine einfache Methode, um
der schnellen Sättigung des Durchsatzes
zu begegnen, wäre, die Bedenkzeit
auf einen Wert ungleich null zu setzen
( Abbildung 10):
Z > 0:
$think = 28.0 * 1e‐3; # freier Parameter
...
pdq::Init($model);
$pdq::streams = pdq::CreateClosed(U
$work, $pdq::TERM, $users,
$think);
Auf diese Art werden neue Anforderungen
verlangsamt ins System injiziert.
Man spielt hier mit der Bedenkzeit, als
wäre sie ein freier Parameter. Der positive
Wert von Z = 0.028 Sekunden stimmt
nicht mit den Einstellungen überein, die
beim Lasttest tatsächlich verwendet wurden,
aber er kann einen Hinweis darauf
geben, in welcher Richtung nach einem
verbesserten PDQ-Modell zu suchen ist.
Wie Abbildung 10 zeigt, verbessert die
positive Bedenkzeit das Durchsatzprofil
entscheidend.
0. 0093 + 0. 0028 + 0. 0009 + 0.
0028
N * =
0.
0093
= 441 . clients
Der Trick mit der Bedenkzeit verrät uns,
dass weitere Latenzen existieren, die in
den Stresstestmessungen keine Berücksichtigung
fanden. Die positive Bedenkzeit
erzeugt eine Latenz, sodass sich die
Round-Trip-Time der Anforderung verlängert.
Als Nebenwirkung verringert
sich der Durchsatz bei niedriger Last.
Throughput (X)
130
120
110
100
90
80
70
60
50
40
30
20
10
0
0 2 4 6 8 10 12 14 16 18 20
Abbildung 9: Naives PDQ-Durchsatzmodell.
Aber in der Praxis betrug die Bedenkzeit
während der realen Lastmessungen null!
Wie löst man dieses Paradoxon?
Versteckte Latenzen
berücksichtigen
Als nächsten Trick fügt man dem PDQ-
Modell aus Abbildung 11 Dummy-Knoten
hinzu. Allerdings gibt es Bedingungen,
die von den Bedienanforderungen der
virtuellen Knoten zu erfüllen sind. Die
Bedienanforderung eines jeden Dummy-
Knotens ist so zu wählen, dass sie die
Bedienanforderung des Engpassknotens
nicht übersteigt. Darüber hinaus ist die
Anzahl der Dummy-Knoten so zu wählen,
dass die Summe der Serviceanforderungen
einen Wert von Rmin = R(1)
nicht übersteigt, sofern keine Konkurrenz
auftritt, das heißt für eine Einzelanforderung.
Wie sich herausstellt, lassen sich
Clients (N)
Xpdq
Xdat
diese Bedingungen erfüllen, wenn man
zwölf einheitliche Dummy-Knoten einführt,
von denen jeder eine Serviceanforderung
von 2,2 ms aufweist. Die Änderungen
des entsprechenden PDQ-Codes
sehen folgendermaßen aus:
use constant MAXDUMMIES => 12;
$think = 0.0 * 1e‐3; #same as in test rig
$dtime = 2.2 * 1e‐3; #dummy service time
# Dummy‐Knoten mit Bedienzeiten erstellen
for ($i = 0; $i < MAXDUMMIES; $i++) {
$dnode = "Dummy" . ($i < 10 ? "0$i" :U
"$i");
$pdq::nodes = pdq::CreateNode($dnode,U
$pdq::CEN, $pdq::FCFS);
pdq::SetDemand($dnode, $work, $dtime);
}
Man beachte, dass die Bedenkzeit wieder
auf null zurückgesetzt ist. Die Ergebnisse
dieser Änderungen am PDQ-Modell finden
sich in Abbildung 12. Das Durchsatzprofil
ist immer noch für geringe Lasten
(N < N*) passend, wobei gilt
Throughput (X)
130
120
110
100
90
80
70
60
50
40
30
20
Xdat
10
Xpdq
0
0 2 4 6 8 10 12 14 16 18 20
Clients (N)
Abbildung 10: Durchsatzmodell mit positiver Bedenkzeit.
. . . ( . )
N * = 0 0093 + 0 0028 + 0 0009 + 12 0 0022
0.
0093
= 424 . clients
Lastabhängige Server
Bestimmte Aspekte des physikalischen
Systems wurden nicht gemessen, sodass
die Validierung des PDQ-Modells schwerfällt.
Bisher haben wir versucht, die Intensität
der Arbeitslast durch Einführung
einer positiven Bedenkzeit anzupassen.
Die Einstellung von Z = 0.028 Sekunden
beseitigte das Problem der schnellen
Sättigung; gleichzeitig stimmt der Wert
nicht mit dem Wert von Z = 0 Sekunden
www.admin-magazin.de
Admin
Ausgabe 06-2011
79

Know-how
Performance-Simulation
überein, der für die eigentlichen Messungen
eingestellt wurde. Durch die Einführung
von Dummy-Warteschlangenknoten
ins PDQ-Modell wurde das Modell für
Szenarien mit geringer Last verbessert,
aber dadurch wird dem in den Daten
beobachteten Abfall des Durchsatzes
nicht Rechnung getragen. Um diesen
Effekt nachzubilden, können wir den
Webserverknoten durch einen lastabhängigen
Knoten ersetzen. Die Theorie
der lastabhängigen Server wird in [5]
besprochen.
In unserem Beispiel wenden wir einen
etwas einfacheren Ansatz an. Aus der
Bedienzeit (Sws) in Tabelle 4 erkennt
man, dass sie nicht für alle Clientlasten
konstant bleibt. Es wird also eine
Methode benötigt, um diese Variabilität
auszudrücken. Wenn man ein Diagramm
der Messdaten für Sws erstellt, lässt sich
eine statistische Regressionsanpassung
durchführen, wie sie Abbildung 13 zeigt.
Die sich daraus ergebende Potenzgesetzgleichung
lautet:
D ( ws
N ) . .
= 8 0000N
0 0850
Damit wird Node1 des PDQ-Modells wie
folgt parametrisiert:
pdq::SetDemand($node1, $work, $$
8.0 * 1e‐3 * ($users ** 0.085));
Die angepasste Ausgabe des fertigen
PDQ-Modells zeigt Tabelle 5. Sie zeugt
von einer guten Übereinstimmung mit
den gemessenen Daten für D = 12
Dummy-PDQ-Knoten.
Die Auswirkung auf das Durchsatzmodell
lässt sich in Abbildung 14 erkennen. Die
Throughput (X)
140
120
100
80
60
40
20
0
Requests
mit Xpdq2 gekennzeichnete Kurve zeigt
den vorhergesagten übersteuerten Durchsatz
auf Basis des lastabhängigen Servers
für das Webfrontend, und die Vorhersagen
liegen locker innerhalb des Fehlerbereichs
der gemessenen Daten. In diesem Fall
bringt es wenig, PDQ für die Vorhersage
einer Last einzusetzen, die oberhalb der
gemessenen Last von N = 20 Clients liegt,
weil der Durchsatz nicht nur gesättigt ist,
sondern auch rückgängig. Nachdem nun
ein PDQ-Modell existiert, das mit den Testdaten
validiert wurde, kann man jetzt alle
erdenklichen Was-wäre-wenn-Szenarien
durchspielen.
Das vorherige Beispiel ist bereits ziemlich
anspruchsvoll, und ähnliche PDQ-Modelle
sind für die meisten Anwendungsfälle
vollkommen ausreichend. Allerdings
N clients
Z = 0 ms
Responses
D ws
D as D db
Web Server App Server DBMS Server
Abbildung 11: Dummy-Knoten bilden versteckte Latenzen ab.
0 2 4 6 8 10 12 14 16 18 20
Abbildung 12: Durchsatz bei Z = 0 mit Dummy-Knoten.
Clients (N)
Xdat
Xpdq
UXB
SXB
Dummy Servers
gibt es auch Situationen, in denen detailliertere
Modelle erforderlich sein können.
Zwei Beispiele für diese Szenarien sind
multiple Server und multiple Aufgaben.
Multiple Server
Ein Szenario außerhalb der Computerwelt,
das man mithilfe der Warteschlange
mit multiplen Servern aus Abbildung 15
nachbilden könnte, ist das Schlangestehen
in einer Bank oder einem Postamt.
Im Kontext der Computer-Performance
könnte Abbildung 15 als einfaches Modell
eines symmetrischen Mehrprozessorsystems
dienen.
Weitere Informationen zu diesem Thema
finden Sie in Kapitel 7 von [5]. Die
Antwortzeit in (1) wird durch Folgendes
ersetzt:
S
R
m
1− ρ
wobei r = lS, und m ist die integrale
Anzahl von Servern. Technisch betrachtet
Tabelle 5: Modellresultate
N Xdat Xpdq D=12
1 24 26.25
2 48 47.41
4 85 77.42
7 100 98.09
10 99 101.71
20 94 96.90
80 Ausgabe 06-2011 Admin www.admin-magazin.de

Performance-Simulation
Know-How
handelt es sich um eine Annäherung,
aber keine schlechte! Die genaue Lösung
ist komplexer und lässt sich mit dem
folgenden Perl-Algorithmus entdecken
(Listing 4).
Es handelt sich um genau das Warteschlangenmodell,
das Erlang vor 100 Jahren
entwickelt hat. Damals stellte jeder
Server eine Hauptleitung im Telefonnetz
dar.
Multiple Aufgaben
Service Demand
10.5
10
9.5
9
8.5
y = 8.3437x 0.0645
R 2 = 0.8745
Data_Dws
8.0 N^{0.085}
Power (Data_Dws)
Was in Wirklichkeit sehr häufig vorkommt,
ist, dass eine einzelne Ressource,
etwa ein Datenbankserver, mit
verschiedenen Transaktionstypen umgehen
muss. Zum Beispiel kann der Kauf
eines Flugtickets oder die Buchung eines
Hotelzimmers im Internet ein halbes
Dutzend unterschiedliche Transaktionen
erfordern, bevor das Ticket ausgestellt
oder das Zimmer endlich reserviert ist.
Situationen dieser Art lassen sich wie
folgt mit PDQ abbilden.
Man betrachte den einfacheren Fall von
drei unterschiedlichen Transaktionstypen,
die durch die Farben Rot, Grün und
Blau gekennzeichnet werden. Jede dieser
eingefärbten Aufgaben kann auf eine gemeinsam
genutzte Ressource zugreifen,
zum Beispiel einen Datenbankserver.
Im Warteschlangenparadigma (Abbildung
16) wird jede der bunten Aufgaben
durch die unterschiedlichen Bedienzeiten
charakterisiert. Mit anderen Worten: Die
rote Last erhält eine rote Bedienzeit, die
grüne eine grüne Bedienzeit und so weiter.
Für jede Farbe gilt auch eine eigene
Ankunftrate.
Throughput (X)
130
120
110
100
90
80
70
60
50
40
30
20
10
0
8
0 5 10 15 20
Clients (N)
Abbildung 13: Regressionsanpassung der Webserver-Zeiten.
0 2 4 6 8 10 12 14 16 18 20
Abbildung 14: Modell des lastabhängigen Durchsatzes.
Clients (N)
Xdat
Xpdq1
UXB
SXB
Xpdq2
Geht man davon aus, dass sich die Bedienzeiten
unterscheiden, resultiert die
tatsächliche Auswirkung auf die Warteschlange
beim Eintreffen beispielsweise
einer roten Anforderung nicht mehr allein
aus der Anzahl von bereits wartenden
Anforderungen (das trifft nur für eine
„monochrome“ Aufgabe zu), sondern
aus der Farbkombination der wartenden
Anforderungen. In PDQ lässt sich Abbildung
16 vielleicht so darstellen wie im
Kasten „Gemischte Workloads“.
Natürlich ist der durch multiple Aufgaben
generierte PDQ-Report komplexer
aufgrund der vielen möglichen Interaktionen.
Auf jeden Fall wirft er etwas Licht
auf die vielfältigen Erweiterungsmöglichkeiten
von PDQ, um realistische Computerarchitekturen
abbilden zu können.
Diese Thematik noch weiter auszuführen,
würde den Rahmen sprengen, aber
man findet weitere Details in [5].
Richtlinien für den Einsatz
von PDQ
Modelle jeder Art zu erstellen, ist teils
Wissenschaft und teils Kunst, und daher
ist es unmöglich, ein komplettes Regelwerk
oder eine komplette Sammlung
von Algorithmen bereitzustellen, die
immer das richtige Modell liefern. Wie
dieser Artikel illustriert, handelt es sich in
Wirklichkeit um einen Prozess der ständigen
Verbesserung. Erfahrung ist durch
nichts zu ersetzen, und sie gewinnt man
bekanntlich durch die ständige Wiederholung.
In diesem Sinne folgen nun einige Richtlinien,
die unter Umständen helfen, wenn
man PDQ-Modelle kreiert: .
n Keep it simple: Ein PDQ-Modell sollte
so einfach wie irgend möglich sein,
aber auch nicht einfacher. Es ist kaum
zu vermeiden, dass man um so mehr
Abbildung 15: PDQ-Modell einer Multiserver-
Warteschlange.
www.admin-magazin.de
Admin
Ausgabe 06-2011
81

Know-how
Performance-Simulation
01 #! /usr/bin/perl
02 # erlang.pl
03
04 ## Input‐Parameter
05 $servers = 8;
06 $erlangs = 4;
07
Details in das PDQ-Modell stopfen
möchte, je mehr man über die Systemarchitektur
weiß. Das führt jedoch unausweichlich
zu einer Überlastung des
Modells.
n Eher die Streckenkarte als die U-Bahn
im Hinterkopf behalten: Ein PDQ-Modell
verhält sich zum Computersystem
wie eine Karte der U-Bahn zum
physikalischen U-Bahn-Netz. Eine
U-Bahn-Karte ist eine Abstraktion, die
kaum etwas mit der physischen Beschaffenheit
des Netzes zu tun hat.
Sie bietet gerade ausreichende Details,
sodass man von Punkt A nach Punkt
B kommt. Sie enthält jedoch keine
überflüssigen Details wie die Höhe der
Bahnhöfe über Normalnull, ja noch
nicht einmal die Entfernung zwischen
ihnen. Ein PDQ-Modell ist eine ähnliche
Abstraktion.
n Das große Bild: Im Gegensatz zu vielen
Aspekten der Computertechnologie,
bei denen man große Mengen
winziger Details aufnehmen muss,
geht es beim PDQ-Modell darum, zu
entscheiden, wie viele Details man
ignorieren kann!
n Suchen nach dem Operationsprinzip:
Wer das Operationsprinzip nicht in
08 if($erlangs > $servers) {
Listing 4: »erlang.pl«
09 print "Error: Erlangs exceeds servers\n";
10 exit;
11 }
12
13 $rho = $erlangs / $servers;
14 $erlangB = $erlangs / (1 + $erlangs);
15
16 for ($m = 2; $m

gemischten Aufgabenmodell (Multiclass-Streams
in PDQ) vermeidet man
die Nutzung von mehr als drei gleichzeitigen
Aufgabenstreams, wo immer
das möglich ist. Davon abgesehen,
dass der resultierende PDQ-Report
ansonsten ganz bestimmt unhandlich
ist, interessiert man sich in der Regel
lediglich für die Interaktion zweier
Aufgaben, das heißt für einen Vergleich
von Aufgabenpaaren. Alles andere
gehört zur dritten Aufgabe (dem
„Hintergrund“). Wenn man nicht
erkennen kann, wie dieses Problem
praktisch zu lösen wäre, dann ist
man wahrscheinlich noch nicht so
weit, das PDQ-Modell erstellen zu
können.
Fazit
Performance-Modeling ist eine anspruchsvolle
Disziplin, die man am
besten durch ständige Wiederholung
trainiert. Ein Großteil der Bemühungen
kreisen dabei immer wieder um
die Erstellung und die Validierung eines
Modells, der zu untersuchenden Umgebung
und ihrer Anwendungen. Sobald
das PDQ-Modell erst einmal validiert ist,
muss es nicht immer wieder aufs Neue
zusammengebaut werden. Im Allgemeinen
reicht dann etwas Tuning – und
schon lassen sich auch Performance-
Änderungen durch Hardware-Upgrades
oder durch neue Software berücksichtigen.
Die dreistufige E-Commerce- Applikation,
für die dieser Beitrag ein beispielhaftes
Modell geliefert hat, bildet einen recht
guten Ausgangspunkt, auf dem sich aufbauen
lässt. Auf diese Weise lässt sich
das Modell relativ einfach um multiple
Server und zusätzliche Aufgaben erweitern.
Eines der erstaunlichsten Ergebnisse
des PDQ-Modells ist die Tat sache,
dass es den analysierenden Admin
bestimmte Effekte – zum Beispiel versteckte
Latenzen – erkennen lässt, die
in den überwachten Daten für ihn sonst
nicht ohne weiteres ersichtlich gewesen
wären. Aber das vielleicht allerwichtigste
Resultat des PDQ-Einsatzes
sind gar nicht die Leistungsmodelle
an sich, sondern es ist die Tatsache,
dass der PDQ- Modellierungsprozess
einen organisatorischen Rahmen für
die Beurteilung aller Leistungsdaten
liefert, in dem Erkenntnisse aus dem
Monitoring bis hin zur Trendvorhersage
zusammenfließen können. (jcb) n
Infos
[1] Kenneth Hess: „Monitoring Linux Performance
with Orca“ [http:// www.​
linux‐magazine. com/ issue/ 65/ Linux_Performance_Monitoring_With_Orca.
pdf]
[2] R, Open Source Statistical Analysis Package:
[http:// www. r‐project. org]
[3] SimPy, Open Source Simulator wirtten in
Python: [http:// sorceforge. net/ projects/​
simpy]
[4] N. J. Gunther, „Guerrilla Capacity Planning“,
Springer-Verlag, 2007
[5] N. J. Gunther: „Analyzing Computer
System Performance with Perl::PDQ“,
Springer-Verlag, 2005
[6] Perl-PDQ: [http:// www. perfdynamics. com/​
Tools/ pdq. tar. gz] .pdf
[7] Linux-Stresstesttools: [http:// www.​
opensourcetesting. org/ performance. php]
Der Autor
Neil Gunther, M.Sc., Ph.D. ist ein international
anerkannter Consultant und Gründer der Firma
Performance Dynamics Company ([http:// www.​
perfdynamics. com]).
Nach einer Ausbildung in theoretischer Physik
nahm er verschiedene Forschungs- und
Management-Aufgaben wahr, unter anderem an
der San Jose State University und bei der NASA
(Voyager- und Galileo-Missionen).
Dr. Gunther ist Mitglied von AMS, APS, ACM,
CMG, IEEE und INFORMS.
&
Listing 5: Gemischte Workloads
01 $pdq::nodes = pdq::CreateNode("DBserver", $pdq::CEN, $pdq::FCFS);
02 $pdq::streams = pdq::CreateOpen("Red", $ArrivalsRed);
03 $pdq::streams = pdq::CreateOpen("Grn", $ArrivalsGrn);
04 $pdq::streams = pdq::CreateOpen("Blu", $ArrivalsBlu);
05 pdq::SetDemand("DBserver", "Red", $ServiceRed);
06 pdq::SetDemand("DBserver", "Grn", $ServiceGrn);
07 pdq::SetDemand("DBserver", "Blu", $ServiceBlu);
www.admin-magazin.de

Know-how
HA-Serie
fbmadeira, 123RF
HA-Workshop, Teil 5: Zentrales Cloud-Storage dank Pacemaker und iSCSI
Die Speicherwolke
Diese Fortsetzung des HA-Workshops setzt das Konzept des letzten Teils auf neue Füße und sorgt für die Skalierbarkeit.
Dreh- und Angelpunkt: ein SAN-Drop-In mit DRBD, iSCSI und Pacemaker. Martin Loschwitz
Die Wolke ist derzeit bekanntermaßen in
aller Munde. Die Idee dahinter ist nicht
neu, hieß früher nur anders: Infrastructure
as a Service ist nichts anderes als
das, was Cloud-Provider heute feilbieten.
Im Grunde braucht es gar nicht viel,
um sich eine eigene Wolke zu basteln.
Schon der letzte Teil der vorliegenden
Serie kam mit Hardware von der Stange,
DRBD, KVM und Pacemaker schließlich
zu einem voll funktionstüchtigen Virtualisierungscluster.
An dieser Stelle von einer „Mini-Cloud“
zu sprechen, mag dem einen oder anderen
etwas zu dick aufgetragen vorkommen.
Denn der vorgestellte Cluster erfüllt
zwar die grundsätzlichen Anforderungen
– im Rahmen der Ressourcen, die er zur
Verfügung stellt, lässt sich Rechenleistung
unkompliziert in die Hände Dritter
übergeben. Aber bei genau diesem
Detail liegt das Problem: Die gängigen
Cloud-Setups sind immer auch skalierbar.
Brauchen die Benutzer mehr Leistung,
lässt sich diese schnell bereitstellen.
Der Virtualisierungscluster aus dem
Beispiel im letzten Heft stößt aber an
Grenzen, wenn er seine Möglichkeiten
ausgeschöpft hat. Und spätestens mit der
maximalen Ausbaustufe der Hardware
des Clusters ist auch das Ende der Fahnenstange
erreicht.
iSCSI zu Hilfe
Cloud-Setups verwenden für gute Skalierung
üblicherweise zentralen, geshareten
Speicher und viele Virtualisierungsfrontends.
Die holen sich den Speicher aus
dem Shared Storage, binden ihn lokal ein
und starten dann virtuelle Maschinen damit.
Shared Storage bietet genau die Skalierbarkeit,
die in solchen Setups nützlich
ist: Neuer Speicher lässt sich bei Bedarf
per Kommandozeile zuweisen oder entfernen,
zusätzlicher Speicher ist durch
neue Platten oder JBods leicht bereitzustellen.
Im Vergleich zum Zwei-Knoten-
Cluster mit Virtualisierungsfunktion ist
die Fahnenstange bei solchen Setups sehr
viel länger.
Typischerweise arbeitet Shared Storage
mit Fibre Channel. Das belastet den
Admin mit den Nachteilen, die solche
SANs üblicherweise haben: Hohe Anschaffungskosten,
Vendor Lock-in und
die Verwendung eines nicht-ubiquitären
Protokolls sind nur drei davon. Kleinere
Betriebe, die auf der Suche nach einer
günstigen Lösung für eine private Cloud
sind, haben selten das Budget für ein
typisches SAN samt der meist benötigten
Fibre-Channel-Hardware.
84 Ausgabe 06-2011 Admin www.admin-magazin.de

HA-Serie
Know-how
Zentraler Speicher für eine skalierbare
private Wolke lässt sich aber auch
ohne SAN, dafür mit Standard-Hardware
und Standard-Netzwerkhardware (1 GBit
oder 10 GBit) realisieren. Die Komponenten,
die dafür notwendig sind, hat die
HA- Serie in den letzten zwei Ausgaben
bereits vorgestellt: DRBD kümmert sich
im Zwei-Knoten-Storagecluster um die
Redundanz der eigentlichen Daten. Pacemaker
managed mithilfe von Heartbeat 3
oder Corosync den Cluster. Bleibt noch
der Weg zwischen Storage und Virtualisierungsfrontend:
Hier ist Ethernet als
Transport gesetzt, und die Kommunikation
auf dem Kabel übernimmt iSCSI.
Voila: Fertig ist das Jedermann-SAN.
Die passende Hardware
Abbildung 1: 50 GBit wie zwischen diesen optischen Intel-Adaptern müssen es nicht sein, aber 10 wären sehr gut.
Das vorgestellte Setup hat zwei Dimensionen
in Sachen Hardware. Einerseits
gilt es, die Hardware für den iSCSI-
Cluster ordentlich zu dimensionieren, es
müssen aber auch die Virtualisierungsfrontends
genug Dampf unter der Haube
haben. Was den iSCSI-Cluster angeht,
gilt: CPU ist von geringerem Interesse
als RAM und Speicher; Letztere sollten
ausreichend vorhanden sein. Sinnvoll ist
es, von Anfang an Rechner einzusetzen,
die über zusätzliche Controller zu einem
späteren Zeitpunkt mit JBODs erweiterbar
sind. Zum Flaschenhals wird gern
auch die Backplane der Server selbst;
im Idealfall sind die Platten über mehrere
Backplanes angebunden. In Sachen
Netzwerkanbindung empfiehlt sich 10
GBit; Controller hierfür sind schon unter
200 Euro zu bekommen (Abbildung
1). Der Crosslink zwischen den zwei
Knoten des Clusters sollte genauso über
eine 10-Gbit-Verbindung realisiert sein
wie die Anbindung des iSCSI-Clusters
an den Rest des Netzwerks. Das setzt
freilich passende Switches voraus; die
meisten Mittelklasse-Switches erlauben
es, 10-Gbit-Funktionen über entsprechende
Zusatzmodule nachzurüsten.
Insgesamt liegt ein Zwei-Knoten-Cluster
mit diesen Eigenschaften selbst bei größeren
Mengen an Plattenplatz trotzdem
weit unter dem Preis, den ein SAN mit
Fibre Channel hätte. Im Hinblick auf die
Virtualisierungsfrontends gilt, dass sie
eine starke CPU und viel RAM benötigen.
10 Gbit auf den Frontends ist toll,
aber nicht zwingend notwendig. Dass
die virtuellen Maschinen, die auf einer
Kiste laufen, zusammen permanent 75-
Abbildung 2: Ist ein Host an einem iSCSI-Target angemeldet, erscheint die Platte auf Linux-Systemen im
»dmesg« als Virtual Disk.
85 Megabyte konsumieren, die mit einer
1-GBit-Verbindung erreichbar sind, ist
unwahrscheinlich. Außerdem lässt sich
die Kapazität der Netzwerkanbindung
mit Bonding noch entsprechend erhöhen.
Plattenplatz ist bei den Frontends
hingegen ein zu vernachlässigender Faktor,
denn ihre wichtigen Daten beziehen
diese ohnehin vom iSCSI-Cluster.
Die Systemarchitektur des
iSCSI-Clusters
Um die iSCSI-Funktion zu realisieren,
braucht es auf dem iSCSI-Cluster ein
passendes Storage-Setup. Der Storage-
Controller stellt im Normalfall ein großes
Device bereit, das den gesamten
Platz der lokalen System-Platten enthält.
Freilich ist es unsinnig, diesen gesamten
Platz in ein DRBD-Laufwerk zu packen
und das dann per iSCSI zu exportieren,
denn so entfällt die Möglichkeit, den
Platz in kleine Scheiben zu schneiden
und bedarfsweise unterschiedlichen
Aufgaben zu widmen. Sinnvoller ist es,
LVM als zusätzliche Komponente mit
aufzunehmen. Im Gegensatz zu den
Setups, die im Rahmen der HA-Serie
bisher dargestellt waren, liegt beim
iSCSI-Cluster allerdings nicht das DRBD
auf den LVM-Devices, sondern die Reihenfolge
ist umgekehrt. Zwischen den
beiden Knoten des iSCSI-Clusters gibt
es ein paar DRBD-Ressourcen, die zusammen
den gesamten Platz der Platten
abdecken. Die DRBD-Konfiguration
www.admin-magazin.de
Admin
Ausgabe 06-2011
85

Know-how
HA-Serie
bleibt schlank, weil nicht für jede VM
auf einem Virtualisierungsfrontend eine
neue Ressource anzulegen ist.
Zudem entfällt mit dem vorgestellten
Setup auch die Konfigurationsarbeit für
neue DRBD-Ressourcen, wenn zu einem
späteren Zeitpunkt eine neue VM auf den
Frontends hinzukommt – das Anlegen
einer neuen LV auf der vorhandenen
LVM-Struktur geht auf der Komman-
dozeile viel schneller (Abbildung 2).
Streng genommen wäre es sogar möglich,
bloß ein einziges, riesiges DRBD zu
erzeugen und per LVM zu verwalten.
Mit dieser Herangehensweise zwingt
man aber den Cluster in ein typisches
Aktiv-Passiv-Setup, weil die DRBD-Ressource
jeweils nur auf einem Cluster-
Knoten aktiv sein kann. Fragmentiert
man den HDD-Platz zumindest ein kleines
Stück weit, ermöglicht man eine
einfache Form des Load-Balancings für
den Fall mit zwei verfügbaren beiden
Cluster-Knoten.
Natürlich müsste man dann auch mit
unterschiedlichen Service-IP-Adressen
am Server und bei den Clients arbeiten.
Außerdem gilt es, Over-Commitment zu
verhindern: Ein einzelner Knoten muss
stets die gesamte Last tragen können,
Die Linux-iSCSI-Targets
Ein Motto der FOSS-Bewegung ist, dass es mehr als einen Weg gibt, um
etwas zu tun. Von dieser Regel machen die Entwickler auch bei iSCSI keine
Ausnahme. So existiert nicht ein einzelnes iSCSI-Target, sondern es gibt
gleich vier verschiedene, die um die Gunst der Admins buhlen.
Generische Storage-Targets
Dreh- und Angelpunkt von diversen Diskussionen, die sich um iSCSI und
die dazugehörigen Targets abgespielt haben, ist die Frage, wie generisch
ein iSCSI-Target sein soll. Oder anders: Soll ein Target außer iSCSI grundsätzlich
auch andere Protokolle beherrschen? Und darf das im Prinzip so
weit gehen, dass das eigentliche Target bloß noch dazu da ist, Plugins für
verschiedene Protokolle zu laden – eines davon dann iSCSI?
Bei den Debatten auf verschiedenen Entwickler-Mailinglisten zeichnete
sich ab, dass die Idee von generischen Targets die meisten Fans hat.
Nicht zuletzt hat auch Linux-Erfinder Linus Torvalds in anderen Fällen
schon einige Male festgehalten, dass er generische Frameworks im Kernel
bevorzugt, um dann möglichst viele hochspezifische Treiber die gleichen
Funktionen nutzen zu lassen. Ob ein Storage-Target zum Bestandteil des
offiziellen Kernels wird, hängt also zum großen Teil auch davon ab, wie gut
es sich an diese Vorgabe hält.
Der Veteran: IET
Den Anfang dieses Überblicks macht IET, das älteste Target. Die Abkürzung
IET steht für iSCSI Enterprise Target. Der Name verrät bereits, dass es
sich nicht um ein generisches Target handelt: IET kann nur iSCSI, und die
Entwickler planen auch nicht, das zu ändern, weil sie dazu riesige Teile der
Treiberstruktur umbauen müssten. IET basiert auf der Arbeit von Ardis, das
vor einigen Jahren ebenfalls ein eigenes iSCSI-Target am Markt etablieren
wollte, dann aber das Interesse daran verlor. Die Köpfe hinter IET sind
derzeit vor allem Arne Redlich und Ross S. W. Walker. Lange beteiligt war
auch Fujita Tomonori, der sich als eifriger Poster auf der LKML mittlerweile
auch auf anderen Themengebieten einen Namen gemacht hat.
IET ist nicht Bestandteil des offiziellen Linux-Kernels. Die Lösung besteht
aus einem Kernel-Modul und dazugehörigen Userland-Utilities. IET steht
im Ruf, besonders stabil zu sein, und seine Entwickler sind sehr schnell,
wenn es auftretende Probleme zu reparieren gilt. Außerdem ist die IET-
Konfiguration verhältnismäßig leicht und lässt sich mittels eines Resource
Agents für Pacemaker praktisch vollständig in der CRM des Cluster-Managers
erledigen. Wer noch nicht mit iSCSI in Kontakt gekommen ist, findet
mit IET einen guten Einstieg.
Der Klassiker: STGT
STGT ist ein zwar nicht von Red Hat entwickeltes, wohl aber von Red
Hat sehr unterstütztes Storage-Target. Als Einziges der vier „großen“
Targets ist STGT Bestandteil des Linux-Kernels, wobei die Aussage streng
genommen so nicht stimmt: Der Teil von STGT, der im Kernel ist, hat für
die eigentliche Funktion von STGT praktisch keinen Nutzen, sondern ist ein
Stub. Sämtliche Funktionen wickelt STGT über die Userland-Programme
ab, weshalb es in den meisten Benchmarks schlechter wegkommt als die
anderen Targets, die sich in den Kernel einklinken. Im Gegensatz zu IET
ist STGT ein generisches Target, das prinzipiell auch andere Protokolle als
iSCSI zur Verfügung stellen kann. Im Gegensatz zu IET unterstützt STGT
iSER – also iSCSI mitsamt RDMA.
Der aufsteigende Stern: LIO
Der Name LIO steht als Abkürzung für Linux-ISCSI.org. Gemeint ist ein
generisches Storage-Target, das von den Linux-Entwicklern als Ersatz für
STGT auserkoren worden ist. Anders als STGT spielt sich bei LIO der große
Teil der Funktionen direkt im Kernel ab, ein passendes LIO-Modul im Kernel
ist also Pflicht. Glücklich darf sich schätzen, wer von seinem Distributor
einen Linux-Kernel 2.6.38 oder höher mitgeliefert bekommt; ab dieser
Kernel-Revision ist LIO nämlich fester Bestandteil des Vanilla-Kernels.
Treibende Kraft hinter LIO ist die Firma Rising Tide, deren Anteil an der
kürzlichen Mainline-Integration riesig ist. Wie üblich haben die Kernel-
Entwickler die Patches der LIO-Leute nämlich nicht einfach ohne Murren
akzeptiert, sondern viele, teils tiefgehende Änderungen erbeten.
LIO kommt mit einem iSCSI-Target, das SRP beherrscht und mithin auch
Infiniband als Transportweg einsetzen kann – RDMA-Funktion inbegriffen.
Auch Fibre Channel-HBAs von QLogic und LSI lassen sich mit LIO nutzen.
Manche Funktionen sind bei LIO allerdings noch nicht so ausgereizt, wie
man es sich als Admin wünschen würde. Die schon erwähnte SRP-Funktion
ist hierfür ein gutes Beispiel: Bei Redaktionsschluss konnte LIO zwar SRP
sprechen, im Rahmen eines Pacemaker-Clusters ließ sich die Funktion
allerdings noch nicht nutzen – denn dafür fehlten ein paar Funktionen.
Der böse Bube: SCST
Schließlich ist noch SCST zu erwähnen: Auch bei SCST handelt es sich um
ein Target mit Split-Design. Ein Teil der Funktionen liegt im Kernel, der Rest
wird von entsprechenden Userland-Werkzeugen erledigt. SCST hat hohe
Ansprüche an sich selbst: Auf der Website des Targets findet sich eine Vergleichstabelle,
in der es für sich in Anspruch nimmt, das beste, schnellste
und tollste Target zu sein. Sein Hauptentwickler, Vladislav Bolkhovitin, ist
auf der LKML allerdings eher durch andere Ereignisse bekannt geworden,
denn er fetzt sich dort regelmäßig mit den anderen Entwicklern. Die haben
seinen Bestrebungen, SCST in den Mainline-Kernel zu hieven, dann bisher
auch erwartungsgemäß eine Absage erteilt. Für schwache Nerven ist
SCST aber ohnehin nichts: Um die versprochenen Performance-Gewinne
zu erreichen, braucht es einen Kernel-Patch – und schon das dürfte SCST
in vielen Firmen aus der engeren Wahl befördern.
Pacemaker-Integration
Die Pacemaker-Integration von iSCSI ist grundsätzlich gut. Florian Haas
von hastexo hat schon 2009, damals noch bei LINBIT, zwei RAs auf OCF-
Basis vorgestellt, die sowohl IET als auch STGT und LIO verwenden können.
Lediglich die Unterstützung für SCST fehlt. Wer Pacemaker mit den anderen
Targets betreiben möchte, ist aber fein raus.
86 Ausgabe 06-2011 Admin www.admin-magazin.de

HA-Serie
Know-how
damit der gesamte Cluster als HA-
Cluster durchgeht.
Konkret sieht das Storage-Setup des iSCSI-
Clusters also so aus: Ein großes Device
wird vom Storage-Controller der beiden
Knoten zur Verfügung gestellt, auf diesem
liegen ein paar DRBD- Ressourcen,
um die Redundanz der Daten zu erreichen.
Die DRBD-Ressourcen sind die
Physical Volumes von Volume Groups in
LVM. Pacemaker aktiviert die VGs automatisch,
nachdem auf einem Knoten ein
DRBD-Laufwerk primär geworden ist.
Die LVs der aktivierten VG exportiert
ein iSCSI-Resource-Agent für Pacemaker
schließlich in das lokale Netz.
Die Pacemaker-
Konfiguration
Der Artikel geht im weiteren Verlauf davon
aus, dass die beiden Knoten des
iSCSI-Clusters bereits über ein Betriebssystem
verfügen und dass sowohl DRBD
wie auch der gesamte Cluster-Management-Stack
– also Corosync oder Heartbeat
plus Pacemaker – bereits installiert
und grundlegend konfiguriert sind. Für
iSCSI setzt der Artikel auf IET, das iSCSI
Enterprise Target (Abbildung 3). Die
zwei Resource Agents (RAs), die in Pacemaker
das iSCSI-Setup übernehmen, beherrschen
aber jeweils auch LIO und
STGT. Detaillierte Informationen hierzu
finden sich im Hilfstext des RA.
Schritt 1: Die DRBD-
Ressource
Der lokale Plattenplatz der beiden Clusterknoten
erscheint meist als ein großes
Laufwerk im System. Mit Partitionen
lässt er sich in kleinere Teile splitten,
anschließend dienen die einzelnen Partitionen
DRBD-Ressourcen auf beiden
Knoten als Backing Device. Die Konfiguration
der Ressource enthält die üblichen
Einträge, ein funktionierendes Beispiel
findet sich im Listing 1. Wenn die DRBD-
Konfiguration auf beiden Servern passt,
folgt das Anlegen des DRBD-Laufwerks.
Das geschieht mit »drbdadm create‐md
iscsivg01« auf beiden Clusterknoten. Es
folgt der Start der Ressource, ebenfalls auf
beiden Knoten: »drbdadm up iscsivg01«.
Auf einem der beiden wird die Ressource
danach zum ersten Mal primär: »drbdadm
Abbildung 3: IET greift für seine Aufgaben auf den Kernel zurück, deshalb ist für den IET-Betrieb ein eigenes
Kernel-Modul notwendig.
‐‐ ‐‐force primary iscsivg01«. Sie ist damit
einsatzbereit.
Schritt 2: Die LVM-
Infrastruktur
Auf dem Knoten, auf dem die DRBD-Ressource
primär ist, lässt sich nun die LVM-
Infrastruktur anlegen: Mittels »pvcreate
/dev/drbd/by‐res/iscsivg01/0« wird
aus der DRBD-Ressource ein Physical
Volume. »vgcreate iscsivg01 /dev/drbd/
by‐res/iscsivg01/0« schafft eine Volume
Group namens »iscsivg01 « und macht die
DRBD-Ressource zum Teil davon. Nun
fehlen noch die Logical Volumes, die
später mittels iSCSI exportiert werden.
»lvcreate ‐L512M ‐n lun1 iscsivg01« legt
ein 512 Megabyte großes Logical Volume
namens »lun1 « an. Analog kommt noch
eine zweite LV gleicher Größe hinzu, die
»lun2« heißt.
In Sachen Storage ist das Haus bestellt,
die nächste Hürde ist es, iSCSI mittels IET
zum Laufen zu bringen.
IET installieren und
konfigurieren
Das IET-iSCSI-Target gehört auf Debianbasierten
Distributionen zum Lieferumfang.
Red Hat unterstützt offiziell nur
STGT, für CentOS finden sich aber passende
Zusatzpakete. Für SLES stehen
ebenfalls Drittanbieter-Pakete zur Verfügung.
Die folgende Beschreibung bezieht
sich auf Debian GNU/​Linux.
Um IET auf Debian zu nutzen, sind sowohl
die Userland-Utilities im Paket »iscsitarget«
zu installieren wie auch das entsprechende
Kernel-Modul, das zuvor händisch
gebaut gehört. Die Installation von »iscsitarget‐source«
holt den Modul-Quelltext,
mittels »apt‐get install module‐assistant
&& m‐a prepare && m‐a ‐t a‐i iscsitarget«
wird das Modulpaket gebaut und installiert.
Das fertige ».deb«-File findet sich
dann in »/usr/src« für die Installation auf
dem zweiten Clusterknoten.
Vorsicht: Der Module-Assistant bringt einige
Development-Pakete mit. Wer auf
seinem Server keine Development-Pakete
dauerhaft installiert haben will, baut das
Modul entweder gleich woanders, oder
räumt anschließend händisch auf.
Wenn IET installiert ist, schaltet
»ISCSITARGET_ENABLE=true« in » /
etc/default/iscsitarget« auf beiden Hosts
IET scharf.
Das große Ganze: die
Pacemaker-Konfiguration
Nun, da alle Software-Komponenten für
den iSCSI-Cluster-Betrieb installiert sind,
ist der letzte Schritt die Konfiguration
der Dienste in Pacemaker. Weil einige
Dienste zu konfigurieren sind, empfiehlt
sich die CRM-Shell: Über den Befehl
»crm« einmal gestartet, führt »configure«
in den Abschnitt für die Konfiguration,
und »edit« öffnet die aktuelle Konfiguration
in einem Editor. Erst wenn alle
Konfigurationseinträge fertig sind, sorgt
Listing 1: »/etc/drbd.d/iscsivg01.res« für DRBD 8.4
01 resource iscsivg01 {
02 volume 0 {
03 device /dev/drbd7;
04 disk /dev/sdc1;
05 meta‐disk internal;
06 }
07
08 on alice {
09 address 192.168.133.111:7588;
10 }
11
12 on bob {
13 address 192.168.133.112:7588;
14
15 }
16 }
www.admin-magazin.de
Admin
Ausgabe 06-2011
87

Know-how
HA-Serie
»commit« dafür, dass die Änderungen
im Clustermanager aktiv werden – eine
zusätzliche Sicherheitsstufe ist in der
CRM-Shell quasi eingebaut. Der Vorteil
dieser Methode ist, dass die benötigten
Ressourcen in Ruhe und nacheinander
in den Cluster-Manager gelangen, unvollständige
Einträge oder Tippfehler sorgen
nicht automatisch für Chaos.
Am Anfang der Pacemaker-Konfiguration
steht die DRBD-Ressource. Die
dafür benötigten Pacemaker- Einträge
bestehen aus zwei Teilen, wie im zweiten
Teil der HA-Serie erläutert wurde:
zum einen der »primitive«-Ressource,
zu anderen dem dazugehörigen »Master/Slave«-Setup.
Im Beispiel heißt die DRBD-Ressource
»iscsivg01«, die Pacemaker-Konfiguration
dafür kann so aussehen:
primitive res_drbd_iscsivg01 ocf:linbit:U
drbd \
params drbd_resource="iscsivg01" \
op monitor interval="10s" role="Master" \
op monitor interval="20s" role="Slave" \
op start interval="0" timeout="240" \
op stop interval="0" timeout="240"
ms ms_drbd_iscsivg01 res_drbd_iscsivg01 \
meta clone‐max="2" master‐max="1" master‐U
node‐max="1" clone‐node‐max="1"
notify="true" target‐role="Master"
Die Konfiguration sorgt dafür, dass die
DRBD-Ressouce auf einem der zwei Clus-
ter-Knoten stets »Primary« ist.
Weiter geht es mit der LVM-VG,
die Pacemaker aktivieren muss,
um an ihre LVs he ranzukommen.
Pacemaker verfügt über einen eigenen
Resource Agent für LVM
namens »ocf:heartbeat:LVM«. Dieser
Konfigurationseintrag greift für
die Volume Group »iscsivg01«:
primitive res_lvm_iscsivg01 ocf:U
heartbeat:LVM params volgrpname=U
"iscsivg01" op monitor interval="30s"
Nun folgt die Konfiguration der Abbildung 4: Wenn Pacemaker wie im Beispiel beschrieben
iSCSI-Dienste. Sie ist in zwei konfiguriert ist, sollte die Ausgabe von »crm_mon ‐1 ‐rf« so
einzelne Teile getrennt: Einerseits
startet der Resource Agent
aussehen.
»ocf:heartbeat:iSCSITarget« den
IET-Daemon »ietd«, andererseits sorgt example:storage.example.iscsivg01" lun="1"
»ocf:heartbeat:iSCSILogicalUnit« dafür, path="/dev/iscsivg01/lun1" U
dass »ietd« weiß, welche Devices er exportieren
soll.
op monitor interval="10s"
primitive res_lu_iscsivg01_lun2 U
In diesem Beispiel sind zwei Logical Volumess
zu exportieren, »lun1« und »lun2«. params target_iqn="iqn.2001‐04.com.U
ocf:heartbeat:iSCSILogicalUnit U
Mitsamt dem »ietd«-Start erledigen das example:storage.example.iscsivg01" lun="2"
die folgenden Einträge:
primitive res_target_iscsivg01 U
ocf:heartbeat:iSCSITarget U
params iqn="iqn.2001‐04.com.exampleU
:storage.example.iscsivg01" U
op monitor interval="10s"
primitive res_lu_iscsivg01_lun1 U
ocf:heartbeat:iSCSILogicalUnit U
params target_iqn="iqn.2001‐04.com.U
path="/dev/iscsivg01/lun2" U
op monitor interval="10s"
Der String »iqn.2001‐04.com.example:​
storage.example.iscsivg01« wirkt zuerst
etwas kryptisch. Es handelt sich um
den iSCSI Qualified Name. Der Eintrag
sollte der Syntax »iqn.yyyy‐mm.reversed
domainname[:identifier]« folgen.
Listing 2: Die CRM-Shell-Konfiguration
01 node $id="42e94fd0‐872d‐4021‐b606‐0f901f208138" bob \
02 attributes standby="off"
03 node $id="7b88dc12‐ee0d‐41cc‐9967‐aeb795d96292" alice \
04 attributes standby="off"
05 primitive res_drbd_iscsivg01 ocf:linbit:drbd \
06 params drbd_resource="iscsivg01" \
07 op monitor interval="10s" role="Master" \
08 op monitor interval="20s" role="Slave" \
09 op start interval="0" timeout="240" \
10 op stop interval="0" timeout="240"
11 primitive res_ip_iscsivg01 ocf:heartbeat:IPaddr2 \
12 params ip="192.168.122.115" cidr_netmask="24" \
13 op monitor interval="20s"
14 primitive res_lu_iscsivg01_lun1 ocf:heartbeat:iSCSILogicalUnit \
15 params target_iqn="iqn.2001‐04.com.example:storage.example.
iscsivg01" lun="1" path="/dev/iscsivg01/lun1" \
16 op monitor interval="10s"
17 primitive res_lu_iscsivg01_lun2 ocf:heartbeat:iSCSILogicalUnit \
18 params target_iqn="iqn.2001‐04.com.example:storage.example.
iscsivg01" lun="2" path="/dev/iscsivg01/lun2" \
19 op monitor interval="10s"
20 primitive res_lvm_iscsivg01 ocf:heartbeat:LVM \
21 params volgrpname="iscsivg01" \
22 op monitor interval="30s"
23 primitive res_target_iscsivg01 ocf:heartbeat:iSCSITarget \
24 params iqn="iqn.2001‐04.com.example:storage.example.iscsivg01" \
25 op monitor interval="10s"
26 group g_iscsivg01 res_lvm_iscsivg01 res_target_iscsivg01 res_lu_
iscsivg01_lun1 res_lu_iscsivg01_lun2 res_ip_iscsivg01
27 ms ms_drbd_iscsivg01 res_drbd_iscsivg01 \
28 meta clone‐max="2" master‐max="1" master‐node‐max="1"
clone‐node‐max="1" notify="true" target‐role="Master"
29 colocation co_g_iscsivg01_always_with_ms_drbd_iscsivg01 inf: g_iscsivg01
ms_drbd_iscsivg01:Master
30 order o_g_iscsivg01_always_after_ms_drbd_iscsivg01 inf: ms_drbd_
iscsivg01:promote g_iscsivg01:start
31 property $id="cib‐bootstrap‐options" \
32 dc‐version="1.0.11‐6e010d6b0d49a6b929d17c0114e9d2d934dc8e04" \
33 cluster‐infrastructure="Heartbeat" \
34 no‐quorum‐policy="ignore" \
35 stonith‐enabled="false" \
36 maintenance‐mode="false" \
37 last‐lrm‐refresh="1311435605"
38 rsc_defaults $id="rsc‐options" \
39 resource‐stickiness="200"
40
88 Ausgabe 06-2011 Admin www.admin-magazin.de

HA-Serie
Know-how
Schließlich fehlt eine IP-Adresse, über
die diese iSCSI-Targets zu erreichen sind.
Diese sieht in Pacemaker so aus:
primitive res_ip_iscsivg01 ocf: heartbeat: U
IPaddr2 params ip="192.168.122.115" U
cidr_netmask ="24" op monitor interval="20s"
Damit sind alle Ressourcen komplett –
nun muss Pacemaker noch wissen, wie
die einzelnen Ressourcen zusammenhängen.
Schließlich ist der iSCSI-Server dort
zu starten, wo auch das dazugehörige
DRBD-Device primär ist. Und zwar erst
dann, wenn die LVM-VG erfolgreich aktiviert
und deren LVs verfügbar sind. Die
einfachste Lösung ist ein »group«-Eintrag
für die angelegten Ressourcen:
group g_iscsivg01 res_lvm_iscsivg01 U
res_target_iscsivg01 res_lu_iscsivg01_U
lun1 res_lu_iscsivg01_lun2 res_ip_iscsivg01
Die DRBD-Ressource kann aufgrund ihrer
Master/​Slave-Eigenschaft nicht Teil einer
Gruppe werden, sondern ist mit der angelegten
Gruppe mittels Colocation- und
Order-Constraint zu verbinden. DRBD
muss auf einem Host im »Primary«-
Modus laufen, bevor die Gruppe startbar
ist. Diese Constraints stellen das sicher:
colocation co_g_iscsivg01_always_with_U
ms_drbd_iscsivg01 inf: g_iscsivg01 ms_U
drbd_iscsivg01:Master
order o_g_iscsivg01_always_after_ms_U
drbd_iscsivg01 inf: ms_drbd_iscsivg01:U
promote g_iscsivg01:start
Wenn diese Einträge in der CRM-Shell
gelandet sind, lädt Pacemaker wie oben
beschrieben nach einem »commit« die
neue Konfiguration. Ein »crm_mon ‐1 ‐rf«
sollte danach wie in Abbildung 4 aussehen,
und »cat /proc/net/iet/volume«
sollte eine ähnliche Liste wie in Abbildung
5 hervorbringen. Wenn dem so ist,
ist die Konfiguration des iSCSI-Targets
abgeschlossen.
Das iSCSI-Target nutzen
Das hochverfügbare iSCSI-Target ist fertig,
nun bleibt noch zu klären, wie es
sich auf Clients und insbesondere bei den
Virtualisierungs-Frontends nutzen lässt.
Grundvoraussetzung dafür ist, dass das
Paket »open‐iscsi« installiert ist. So, wie
„echtes“ SCSI, braucht auch iSCSI einen
Initiator auf der Client-Seite. Der OpeniSCSI-Connector
liegt praktisch jeder ak-
Abbildung 5: Mittels »cat /proc/net/iet/volume« lässt sich herausfinden, welche iSCSI-Targets derzeit von
einem Host exportiert werden.
tuellen Distribution bei. Nach der Paketinstallation
auf Debian ist sein Daemon
noch mittels »/etc/init.d/open‐iscsi start«
zu starten. Danach lässt sich das iSCSI-
Device verbinden – im Beispiel mit dem
Befehl
scsiadm ‐m node ‐T iqn.2001‐04.com.U
example:storage.example.iscsivg01 ‐p U
192.168.122.115:3260 ‐‐login
auf dem Knoten, auf dem das iSCSI-
Target nicht gestartet ist (im Zweifelsfall
gibt »crm_mon ‐1 ‐rf« Auskunft). Der Befehl
sollte »Successful!« zurückliefern, in
»dmesg« sind dann die neuen Devices
als »Virtual Disk« zu sehen. Damit ist der
lokale Zugriff auf sie möglich.
Es gibt für Pacemaker auch einen Ressource-Agent,
der über »open-iscsi« die
Verbindung mit einem iSCSI-Target herstellt.
Er heißt »ocf:heartbeat:iscsi « und
setzt ein installiertes »open‐iscsi« voraus.
Der entsprechende Eintrag in der CRM-
Shell braucht zwei Parameter, nämlich
»portal=« mit der IP-Adresse des Targets
(im Beispiel 192.168.122.115) und andererseits
» target=« mit dem Target-Namen
(gemeint ist der IQN, im Beispiel wäre
das »iqn.2001-04.com.example:storage.
example.iscsivg01«). Ein vollständiger
Eintrag für dieses Beispiel wäre dieses:
primitive res_connect_iSCSI_iscsivg01 ocf:U
heartbeat:iscsi \
params portal="192.168.122.115:3260"
target="iqn.2001‐04.com.example:storage.U
example.iscsivg01" \
op monitor interval="10s"
Der Eintrag gehört allerdings nicht in die
Pacemaker-Konfiguration auf dem iSCSI-
Cluster, sondern in die der Virtualisierungs-Frontends.
Die letzte noch zu klärende Frage betrifft
die Virtualisierungs-Frontends selbst.
Denn der iSCSI-Cluster kann nur Storage-
Devices zur Verfügung stellen; er kann
sich nicht unmittelbar darum kümmern,
dass auf den Frontends wirklich auch
virtuelle Maschinen laufen.
Auch die Virtualisierungs-Frontends
müssen deshalb im Hinblick auf HA noch
ein paar Besonderheiten beachten. Verschiedene
Konzepte bieten sich an. Die
einfachste Variante besteht darin, auf den
Frontends eine Linux-Distribution einzusetzen,
die KVM oder Xen beherrscht.
Aus den Frontends wird dank Pacemaker
ebenfalls ein Cluster.
Auf dem Laufenden
Mittels eines Konfigurationsverwaltungstools
wie Puppet oder Chef ist dafür gesorgt,
dass die notwendigen Konfigurationsdateien
überall und immer auf dem
aktuellen Stand sind. Der iSCSI-Cluster
exportiert pro VM ein iSCSI-Target (im
Beispiel weitere Devices analog zu »iscsivg01«).
Und der Pacemaker auf den Virtualisierungs-Frontends
sorgt mit Colocation-
und Order-Constraints dafür, dass
die Pärchen aus iSCSI-Target und VM
jeweils auf dem gleichen Host laufen. Ein
Beispiel für die Anbindung eines iSCSI-
Targets auf dem lokalen System findet
sich weiter oben, wie VMs in Pacemaker
zu integrieren sind, erklärte der vierte
Artikel der Serie [1].
Wer es lieber bunter mag oder auf eine
fertige Lösung für die Frontends zurückgreifen
möchte, kann das ebenso tun.
Sowohl VMware ESX als auch der weit
verbreitete Citrix Xenserver können auf
iSCSI-Devices als Datenquelle zurückgreifen.
Mit der iSCSI-Lösung steht storage-seitig
eine sehr vielfältige Lösung
zur Verfügung. (jcb)
n
Infos
[1] Martin Gerhard Loschwitz, „Eigene Clouds“
ADMIN 05/​2011, S. 98
Der Autor
Martin Gerhard Loschwitz arbeitet als Principal
Consultant bei hastexo. Er beschäftigt sich dort
intensiv mit Hochverfügbarkeitslösungen.
www.admin-magazin.de
Admin
Ausgabe 06-2011
89

Know-how
Cgroups
Miss X, photocase.com
Cgroups zur Ressourcenkontrolle in Linux
Wie viel darf's
denn sein?
Mit dem neuen Cgroups-Feature lässt sich bei modernen Linux-Distributionen der Ressourcen-Verbrauch etwa
von Prozessen administrativ beschränken. Besonders interessant ist die Anwendung der Technologie bei
virtualisierten Systemen. Ralf Spenneberg
Vor einigen Jahren führte der Autor
eine Linux-Schulung bei einem großen
IT-Dienstleister durch. Dessen Administratoren
verfügten über umfangreiche
Erfahrungen mit kommerziellen Unix-
Varianten, wie etwa HP-UX, und stellten
die Frage, wie sie unter Linux eine Ressourcensteuerung
und ‐kontrolle umsetzen
könnten: Wie kann ein Administrator
den genutzten Arbeitsspeicher eines einzelnen
Prozesses oder einer Gruppe von
Prozessen beschränken?
Zum damaligen Zeitpunkt musste der Autor
einräumen, dass Linux diese Funktion
nicht bietet. 2006 hat jedoch Rohit Seth
begonnen, diese Funktionalität zu entwickeln.
Seit dem Kernel 2.6.24 kann ein
Administrator diese nun auch nutzen.
Ursprünglich als „process container“
bezeichnet, können die Control-Groups
(kurz: cgroups) Ressourcen (Arbeitsspeicher,
CPU, I/O) limitieren, priorisieren,
zählen (für Abrechnungszwecke) und
isolieren.
Auch wenn viele Administratoren diese
Funktionalität auf einem normalen Server
wahrscheinlich nicht einsetzen werden,
ist sie beim Einsatz etwa von KVM-Virtualisierung
sehr interessant. Mit Cgroups
lassen sich die Ressourcen eines virtuellen
Gastes beschränken oder gegenüber
anderen Gästen priorisieren [1].
Gruppenzwang
Mit einer Cgroup kann ein Administrator
mehrere Prozesse zu einer Gruppe zusammenfassen.
Diese Prozesse und sämtliche
Kindprozesse kann der Administrator
dann mit Parametern für bestimmte
Subsysteme versehen. Ein Subsystem ist
dann zum Beispiel ein Ressource-Controller,
der den verfügbaren Arbeitsspeicher
verwaltet. Am einfachsten illustriert
dies ein Beispiel.
Um die Cgroups zu verwenden, muss
der Administrator zunächst Hierarchien
anlegen, in der die Gruppen verwaltet
werden. Hierzu editiert er die Datei
»/ etc / cgconfig.conf«, die in Listing 1 zu
sehen ist. Existiert die Datei noch nicht,
so muss er das entsprechende Paket
noch installieren. Diese Datei legt für
jedes Subsystem eine eigene Hierarchie
an, unterhalb derer die Cgroups angelegt
werden können. Die Hierarchie
»/cgroup/cpu« erlaubt die Verwaltung der
CPU-Shares, während »/ cgroup/net_cls«
die Verwaltung der Netz-I/O-Leistung
unterstützt.
Ein Start des Cgconfig-Daemons erzeugt
dann die Verzeichnisse und mountet
das Cgroups-Dateisystem. Mit dem Befehl
»lssubsys« kontrolliert der Admin
die korrekte Erzeugung der Hierarchien
(Lis ting 2).
Die Control Groups legt der Administrator
mit dem Befehl »cgcreate« an:
cgcreate ‐g blkio:/dd
Welche Parameter für das Subsystem
Block-I/​O zur Verfügung stehen, lässt
sich mit dem Befehl in Listing 3 in Erfahrung
bringen.
Ab Kernel 2.6.37 unterstützt der Kernel
hier auch die Optionen »blkio.throttle.*«.
Damit kann der Administrator die maximale
I/​O-Bandbreite beim Lesen und
90 Ausgabe 06-2011 Admin www.admin-magazin.de

Cgroups
Know-How
Schreiben einer Prozessgruppe einschränken.
Um dies zu testen, benötigt
der Admin zunächst die Major- und
Minor-Nummern des Gerätes, auf dem
die Bandbreite eingeschränkt werden
soll. Handelt es sich um »/dev/sda1«,
kann er diese mit einem einfachen »ls«
ermitteln:
# ls ‐l /dev/sda1
brw‐rw‐‐‐‐. 1 root disk 8, 1 10. Okt U
08:32 /dev/sda1
Hier handelt es sich um die Major/​Minor-Nummern
8 respektive 1. Um die
Bandbreite für die Control-Group nun auf
1 Mbyte/​s zu beschränken, verwendet
er den Befehl »cgset« oder einfach ein
»echo«:
echo "8:1 1048576" > /cgroup/blkio/dd/U
blkio.throttle.write_bps_device
Für den Test startet er nun dd.
dd if=/dev/zero of=/tmp/test & pid=$!
Zunächst arbeitet der Prozess »dd« in der
Root-Cgroup, die nicht eingeschränkt ist.
Dies testet der Administrator, indem er
dem Prozess ein SIGUSR1 sendet:
# kill ‐USR1 $pid
578804+0 Datensätze ein
578804+0 Datensätze aus
296347648 Bytes (296 MB) kopiert, 7,00803 s,U
42,3 MB/s
Um den Prozess in die Cgroup »dd« zu
verschieben, verwendet er den Befehl
»echo«:
# echo $pid > /cgroups/blkio/dd/tasks
Sendet der Administrator nun erneut
ein USR1-Signal an den »dd«-Prozess,
erkennt er, dass die durchschnittliche
Bandbreite stark sinkt, da der Prozess
nun nur noch mit einer Bandbreite von 1
MByte/​s schreiben darf.
Statt die maximale Bandbreite zu beschränken,
kann der Admin auch die
Bandbreiten zwischen den Gruppen
priorisieren. Hierzu dient der Parameter
»blkio.weight=«. Der Default-Wert beträgt
500. Erhält eine Gruppe den Wert
1000, so kann sie doppelt so häufig auf
die Block-Geräte zugreifen wie die anderen
Gruppen.
Statt des Echo-Kommandos lassen
sich Prozesse auch mit dem Kommando
»cgclassify« einzelnen Gruppen
zuweisen.
Möchte der Admin einen Prozess direkt
in einer bestimmten Gruppe starten, so
verwendet er den Befehl »cgexec«:
cgexec ‐g blkio:dd "dd if=/dev/zero of=U
/tmp/test"
Automatik
Die manuelle Zuweisung von Prozessen
zu verschiedenen Gruppen ist aufwendig
und fehlerträchtig. Besser ist es deshalb,
wenn der Daemon »cgrulesengd«
diese Zuweisung auch automatisch übernimmt.
Hierzu benötigt dieser Dienst die
Regeldatei »/etc/cgrules.conf«, die ihm
mitteilt, welcher Prozess von welchem
Benutzer in welcher Control-Group landen
soll. Die Datei besitzt eine recht einfache
Syntax:
[:

Know-how
Cgroups
elle Anwendungen, die im Alltag davon
profitieren können. Jedoch ist es in vielen
Fällen sinnvoller, dass der Linux-Kernel
die Ressourcen selbstständig zuweist und
hierbei keine Schranken setzt. Setzt man
jedoch eine Virtualisierungslösung wie
KVM ein und virtualisiert mehrere Gäste
auf einem Host, gibt es durchaus Bedarf,
die Ressourcennutzung der einzelnen
Gäste untereinander zu beschränken, priorisieren
und zu messen. Hierfür lassen
sich die Cgroups ideal einsetzen.
Virtualisiert
Allerdings muss man beim Einsatz von
Cgroups die Virtualisierung über die
Libvirt-Bibliotheken steuern und LXC-
Container oder Qemu/​KVM verwenden.
Der Libvirtd-Daemon erzeugt dann beim
Der Autor
Ralf Spenneberg arbeitet
als freier Unix/​Linux-
Trainer, Berater und Autor.
Mit seinem Unternehmen
OpenSource Training Ralf
Spenneberg führt er Schulungen
und Beratungen durch. Er veröffentlichte
bereits mehrere Bücher zu den Themen
Intrusion Detection, SELinux, Firewalling und
Virtuelle Private Netzwerke. Vor wenigen Wochen
erschien sein neues Buch „Linux-Firewalls:
Sicherheit für Linux-Server und ‐Netzwerke mit
IPv4 und IPv6“.
Bandbreitenkontrolle
Wird ein Prozess vom Net_cls-Controller überwacht,
kann der Admin für sämtliche Prozesse
der Cgroup eine Class-ID vergeben. Diese kann
dann mit dem »tc« Kommando genutzt werden.
Hierzu setzt der Admin zunächst für die Cgroup
die Class-ID:
echo 0x00100001 > /cgroup/net_cls/libvirt/U
qemu/Gast/net_cls.classid
Diese hexadezimale Zahl besteht aus zwei Teilen:
0xAAAABBBB. Hierbei definieren die Ziffern
AAAA die Major-Nummer der Class-ID, während
die Ziffern BBBB die Minor-Nummer angeben.
Führende Nullen müssen nicht angegeben
werden. Der obige Ausdruck hätte also auch
0x100001 lauten können.
Um nun die Class-ID zu nutzen, muss der Admin
eine Classbased-Queueing-Discipline (QDisc) auf
der ausgehenden Netzwerkkarte (etwas »eth0«)
installieren. Die QDisc entscheidet, wann ein
Start für jeden Gast eine eigene Cgroup
mit dem Namen des Gastes. Diese befindet
sich in der Hierarchie »libvirtd/
qemu|lxc/Gast« unter jedem Controller.
Hier kann der Admin nun für jeden Gast
einzeln die Ressourcen verwalten und
priorisieren. Damit ein Gast doppelt so
viel CPU-Zeit wie ein zweiter Gast erhalten
kann, muss man im CPU-Controller
die »cpu.shares« ändern. Das angestrebte
Ziel lässt sich erreichen, indem man den
Default-Wert von 1024 auf 2048 ändert.
Genauso kann der Administrator auch
den Verbrauch des Arbeitsspeichers
oder die Bandbreitennutzung im Netzwerk
konfigurieren. Hierzu nutzt er den
Memory-Controller oder den Net_Cls-
Controller in Kombination mit dem
»tc«-Befehl. Allerdings unterstützen
erst die aktuellsten Libvirt-Varianten
den Net_Cls-Controller. Er unterscheidet
sich von den anderen Controllern,
da er lediglich eine Class-ID setzt und
man dann mit dem Kommando »tc« die
Bandbreite kontrolliert (siehe Kasten
„Bandbreiten kontrolle“). Der Blkio-
Controller lässt sich noch nicht mit Libvirt
nutzen, da er noch nicht die Hierarchien
unterstützt, die der Libvirtd erzeugen
möchte. Daran arbeiten die Kernel-Entwickler
aber schon [2]. Will der Admin
für die verbrauchte Zeit der einzelnen
vir tuellen Gäste Abrechnungen erstellen,
so kann er das mit dem CPUAcct-Controller
erreichen. Dieser zählt für jeden
Gast in »/cgroup/ cpuacct/libvirt/qemu/
Paket zu versenden ist. Eine klassenbasierte
QDisc erlaubt die Einsortierung der Pakete in
unterschiedliche Klassen sowie die Priorisierung
und Beschränkung dieser Klassen. Eine klassische
QDisc für die Beschränkung des Netzwerkverkehrs
ist der Hierarchical Token Bucket Filter
(HTB). Der Admin muss zunächst diesen auf der
Netzwerkkarte installieren. Hierzu löscht er eine
möglicherweise vorhandene QDisc und lädt dann
den HTB:
tc qdisc del dev eth0 root 2>/dev/null
tc qdisc add dev etho root handle 10: htbU
default 2
Nun muss der Admin die Klassen erzeugen.
tc class add dev eth0 parent 10: classid 10:1U
htb rate 10mbit
tc class add dev eth0 parent 10: classid 10:2U
htb rate 20mbit ceil 100mbit
Gast/cpuacct.usage« die tatsächlich verbrauchte
CPU-Zeit in Nano-Sekunden.
Jeder Thread eines Prozesses kann in
einer eigenen Cgroup kontrolliert werden.
Daran muss der Administrator denken,
wenn er, wie zu Beginn gezeigt,
die Prozesse nach ihrem Start mit dem
echo-Kommando einer Cgroup zuweisen
möchte. Auch sämtliche gestarteten
Threads (»/proc/pid/task/«) muss er
entsprechenden Cgroups zuweisen. Einfacher
ist da das Kommando »cgexec«.
Dieser Befehl startet den Prozess bereits
in der Cgroup. Alle Kindprozesse und
‐threads erben dann diese Gruppe.
Fazit
Leider unterstützen nur die aktuellen
Linux-Distributionen Cgroups. Einzelne
Funktionen stehen sogar nur in den aktuellsten
Linux-Kerneln zur Verfügung. Der
Administrator muss daher im Einzelfall
testen, welche Eigenschaften er nutzen
kann. Dann bieten die Cgroups aber, insbesondere
auch beim Einsatz von Virtualisierung,
umfangreiche Funktionen für
die Ressourcen-Steuerung der Prozesse
und Gäste. (ofr)
n
Infos
[1] Cgroups: [http:// www. kernel. org/ doc/​
Documentation/ cgroups/]
[2] Blkio-Hierarchien:
[http:// lwn. net/ Articles/ 413015/]
Diese zwei Zeilen erzeugen zwei verschiedene
Klassen. Die erste Klasse verfügt über eine
maximale Bandbreite von 10 Megabit/​s. Die
zwei Klasse verfügt über 20 Megabit/​s, darf
jedoch bis zu einer maximalen Bandbreite von
100 Mbit/​s beanspruchen, wenn keine andere
Klasse Ansprüche erhebt. Die Option »default 2«
bei der Erzeugung des HTB weist unklassifizierten
Verkehr der zweiten Klasse zu.
Um die Class-ID der Cgroup Net_Cls nun auszuwerten,
muss der Admin noch einen Filter
definieren:
tc filter add dev eth0 parent 10: \
protocol ip prio 10 \
handle 1: cgroup
Nun wird die Net_Cls-Class-ID automatisch von
dem Kernel für die Einsortierung der Pakete in
den HTB-Klassen genutzt. Der Libvirt-Gast erhält
nun eine maximale Sendeleistung von 10 Mbit/​s.
92 Ausgabe 06-2011 Admin www.admin-magazin.de

Admin-mAGAZin
im JAhres-Abo
Jede Ausgabe des Admin-Magazins bietet praktisch anwendbares Wissen
von ausgewiesenen Experten und ausführliche Hintergrundberichte für alle
Systemverwalter von Linux, Unix und Windows. Die Schwerpunkte reichen von
Storage und Backup bis hin zu Netzwerk-Themen und Security.
Ein Sonderteil hilft Admins heterogener Welten.
15 % sparen
Jetzt bestellen unter:
www.admin-magazin.de/abo
sichern sie sich ihr
GrAtis Admin t-shirt!
• Telefon 07131 / 2707 274 • Fax 07131 / 2707 78 601 • E-Mail: abo@admin-magazin.de
Mit dem Jahres-Abo erhalten Sie 6 Ausgaben des Admin-Magazins zum Vorzugspreis von E 49,90 * statt E 58,80 *
(Lieferung frei Haus).
* Preise gelten für Deutschland. Schweiz: SFr 99,90; Österreich: E 54,90; anderes Europa: E 59,90

Know-how
Zarafa auf UCS
© tykhyi, 123RF
Zarafa-Groupware-Lösung auf Univention Corporate Server installieren
Fundament für
Teamarbeit
Die Bremer Univention GmbH hat sich mit ihrem Corporate Server als Infrastruktur-Lieferant etabliert. Wer
diesen Server als Fundament für die Groupware Zarafa nutzen möchte, kann zusätzlich auf die gute Vorarbeit
des Univention-Partners LINET Services GmbH zurückgreifen. Thomas Drilling
Die Groupware-Lösung mit dem Giraffen-Logo
konzentriert sich bekanntlich
auf die möglichst kompromisslose Umsetzung
des MAPI-Protokolls, empfiehlt
sich damit vorrangig als kostengünstige
Alternative zu MS Exchange und wird
von Zarafa auch in diesem Sinne vermarktet.
Die jüngst erschienene Version
7 [1] bringt mit Unicode-Unterstützung,
neuem Admin-Interface, verbesserter
Performance vor allem im Datenbankbereich
und optimiertem IMAP-Gateway
interessante Features mit und basiert
mit MAPI bei der Umsetzung sämtlicher
Collaboration-Features vollständig auf einem
echten Groupware-Protokoll.
Inwieweit eine Exchange-Alternative auf
Zarafa-Basis tatsächlich kostengünstiger
ist – Hersteller Zarafa spricht von bis zu
50 Prozent – hängt von vielen Faktoren
ab. Neben etwaigen Kosten für Migration,
Pflege, Service und Schulung von Administratoren
im Linux-Bereich – für Nutzer
ändert sich dank nahezu vollständiger
Outlook-Unterstützung und Outlookähnlichem
Ajax-Web-GUI (Abbildung
1) kaum etwas – fallen mitunter auch
Kosten für das Server-Betriebssystem an,
denn Zarafa vermarktet seine Groupware-
Lösung nicht als Appliance, wenngleich
es solche Produkte von Zarafa-Partnern
wie etwa der Bitbone AG durchaus gibt.
Zarafa soll sich nämlich nach den Vorstellungen
der Entwickler maximal flexibel
in die vorhandenen Infrastrukturen
einfügen. Es obliegt also der Entscheidung
des Administrators, welche
Linux-Distribution er als Basis für eine
Zarafa-Installation wählt. Im günstigsten
Fall ergeben sich sogar für die gesamte
Infrastruktur überhaupt keine Anschaffungskosten,
nämlich dann, wenn sich
der Admin für die Community-Version
von Zarafa zusammen mit einer freien
Distribution entscheidet. Die Community-Version
unterstützt bereits eine unbegrenzte
Nutzerzahl beim Webclient
und dem IMAP-Gateway, allerdings nur
94 Ausgabe 06-2011 Admin www.admin-magazin.de

Zarafa auf UCS
know-how
Rollen-Konzeptes für die in der Domäne
verfügbaren Hosts, namentlich Domänencontroller
Master, Domänencontroller
Backup, Domänencontroller Slave, Memberserver,
Managed Client, Mobile Client
und Thin Client.
Das Domänen-Konzept des UCS basiert
auf den Diensten DNS, LDAP, Samba
und Kerberos. Der von UCS beim Installieren
eines DC Master implementierte
DNS-Dienst löst sämtliche Namen und
IP-Adressen aller im Managementsystem
registrierten Systeme auf. Alle UCS-Einstellungen
landen im LDAP. Alle UCS-
Systeme registrieren sich in den im LDAP
konfigurierten DNS-Domänen. Die Administration
der DNS-Domäne erfolgt dann
anhand der Rechnerobjekte im Managementsystem
über eine Web-Schnittstelle
zum LDAP-Verzeichnisdienst.
UCS hält Änderungen bei Bedarf auch mit
der DHCP-Konfiguration synchron. Außerdem
lässt sich die DNS-Domäne auch
für das Mail-Routing verwenden, wenn
der Admin sie als MX-Record einträgt.
Auch Windows-Clients können Mitglied
einer UCS-Domäne sein, sofern die Unterstützung
von Windows-Diensten (Samba)
im UCS aktiviert ist. Dabei erscheint die
UCS-Domäne aus Sicht der Windowsdrei
Benutzer beim Outlook-Zugriff. Ihr
fehlen zudem die Active-Directory-Unterstützung,
der Mehrbenutzer-Kalender
und das Backup-Tool. Diese Features
bietet erst die Small Business Version.
Ihr gegenüber bringt die Professional-
Version den Blackberry Enterprise Server,
Hochverfügbarkeitsfunktionen und eine
automatische Software-Verteilung mit.
Die Enterprise-Variante schließlich lässt
sich dank Multiserver-Unterstützung auf
mehrere Server verteilen und ist mandantenfähig.
UCS-Konzepte
Ein typisches Zarafa-Szenario ist in der
Regel im KMU- oder Enterprise-Umfeld
angesiedelt ist, deshalb ist für das Server-Betriebssystem
eine Enterprise-Distribution
die beste Wahl. Univentions
Corporate Server (UCS) drängt sich hier
insofern auf, als er für den Einsatz mit
Zarafa zertifiziert und als Appliance konzipiert
ist. Neben den generellen Vorteilen
jeder Enterprise-Distributionen wie
vom Hersteller gepflegte Repositories mit
stabilen, aufeinander abgestimmten und
besonders getesteten Paketen zählt im
Praxiseinsatz für viele Admins vor allem
ein möglichst langer Support-Zeitraum.
Der Univention Server lockt darüber
hi naus mit zahlreichen Funktionen,
die nicht unmittelbar mit seiner Zertifizierung
als Groupware-Server zu tun
haben [2]. Für ihn spricht etwa sein
Verzeichnisdienst-basiertes Identity- und
Infrastruktur-Managementsystem, dessen
durchgängige Umsetzung einmalig in der
Linuxwelt ist, allerdings auch die Integration
einer komplexen Software wie Zarafa
erschwert. Es gibt aber sowohl von UCS
als auch von Zarafa Versionen für eine
unbegrenzte Nutzung zu persönlichen
Zwecken, die sich für ein kostenloses
Testszenario empfehlen. Herausragendes
Merkmal des UCS ist sein Single-Pointof-Administration-Konzept.
Der UCS
verwaltet sämtliche Benutzer, Gruppen
und Hosts webbasiert, wozu alle Komponenten
den gemeinsamen OpenLDAP-
Verzeichnisdienst nutzen. Dazu implementieren
die Univention-Entwickler
ein eigenes Domänen-Konzept zur einfachen
Integration von Servern und Arbeitsplätzen
in das zentrale Identity- und
Infrastrukturmanagement mitsamt eines
Abbildung 1: Die Zarafa-Web-GUI steht nach Installation von »zarafa4ucs« nach wenigen Schritten auf dem
Univention Server zur Verfügung.
Clients wie eine Windows NT-Domäne.
Der Windows-Client (ab Windows XP
Professional) tritt der Domäne bei. Das
ist allerdings nicht Voraussetzung, um
MS Outlook als Zarafa-Client verwenden
zu können, denn der Zarafa-Dienst läuft
in Prinzip auch unabhängig von den geschilderten
UCS-Funktionen.
Unabhängig vom UCS
Gleiches gilt auch für die Benutzerverwaltung
und Authentifizierung des Zarafa-
Servers. Auch diese ist im Prinzip unabhängig
vom UCS. Allerdings kann Zarafa
diese Prozesse wahlweise via MySQL,
Unix/​Passwd oder LDAP abwickeln und
verlangt dann einen entsprechend konfigurierten
UCS. Der verwendet nämlich
unter anderem die Kerberos-Implementierung
Heimdal (Kerberos 5-Standard)
zur Realisierung eines echten und sicheren
„Single Sign On“, wobei die Kerberos-
Realm (Kerberos-Domäne) in der Regel
mit der DNS-Domain übereinstimmt.
Da UCS bei der Installation des DC Master
die Kerberos-Realm anhand der DNS-Domain
einstellt, erhalten die im Managementsystem
angelegten Benutzerkonten
automatisch ein Kerberos-Konto unter
www.admin-magazin.de
Admin
Ausgabe 06-2011
95

Know-how
Zarafa auf UCS
dieser Realm, und der DC Master registriert
alle UCS Systeme als Kerberos Hosts.
Im Übrigen erfolgt dann das Anbinden
existierender Kerberos-Installation durch
den Aufbau einer Vertrauensstellung. Elegant
ist ferner, dass die Datenhaltung der
Domänen-Kontexte von DNS und Kerberos
durch den Einsatz des UCS-Managementsystems
konsistent bleiben. Benennt
der Admin etwa einen Host dort um, gilt
der neue Name sowohl im DNS als auch
in der Windows-Domäne. Ändert ein Benutzer
sein Passwort gegenüber Kerberos
oder der Windows-Domäne, ändert es
sich auch im jeweils anderen Kontext.
Zarafa und Univention
Für die weitere Vorgehensweise wird
vorausgesetzt, dass ein UCS DC Master
bereits installiert ist und läuft, wie etwa
unter [2] beschrieben. Das Konfigurieren
eines Zarafa-Setups ist dann in Prinzip
kein großes Problem und in [1] und [3]
sowie auf der Zarafa-Seite [4] hinreichend
erläutert. Als Fundament kann
jede der von Zarafa unterstützen Linux-
Distributionen dienen. Die Installation
gelingt dank des mitgelieferten Installer-
Skripts nahezu überall problemlos, sofern
die wichtigsten Voraussetzungen wie
das Vorhandensein von Webserver und
Datenbank erfüllt sind.
Wer neu installiert, entpackt das Installationsarchiv
etwa der aktuellen Version
»zcp‐7.0.2‐2xxxxxx‐free.tar.gz« in einem
beliebigen Verzeichnis mit Schreibrechten,
wechselt dann ins entsprechende
Unterverzeichnis »zcp‐7.0xxxx« und führt
dort das Installationsskript aus »sudo ./
install.sh« . In dessen Verlauf bestückt das
Skript unter anderem die Server-Konfigurationsdatei
»/etc/zarafa/server.cfg« mit
Default-Werten oder zeigt Werte an, die
Zarafa 7 mit UCS
Leider berücksichtigt die aktuelle Version des
Zarafa4ucs-Integrationspakets noch nicht die
neue Zarafa-Version 7, die bei Redaktionsschluss
bereits in der finalen Version 7.02 vorlag.
Allerdings gibt es inoffiziell seit Sommer
eine neue Version des Integrationspakets, das
gegenwärtig noch Alpha-Status besitzt. Doch
das Paket befindet sich bereits bei einigen Kunden
zuverlässig im Einsatz. Bis auf Weiteres
lässt sich das Paket daher zum Ausprobieren
von [10] kostenlos herunterladen. Sollte sich
Abbildung 2: Nach erfolgreichem Installieren von »zarafa4ucs« lassen sich Zarafa-Nutzer über den Univention
Directory Manager (UDM) anlegen und werden unmittelbar im LDAP gespeichert.
der Admin durch »[Enter]« übernehmen
kann. Leider ist diese Vorgehensweise
in Zusammenarbeit mit dem Univention
Corporate Server nicht zu empfehlen, einerseits
weil die Default-Konfiguration
lediglich das DB-User-Plugin konfiguriert
– das LDAP-Plugin erfordert ohnehin eine
weitergehende Konfiguration – und andererseits,
weil externe Paketquellen oder
gar generische Installer die Integrität des
Univentions Servers gefährden könnten.
Außerdem verzichtet der Admin bei einer
Zarafa-Standardinstallation auf sämtliche
geschilderten Vorteile des zentralen Identity-
und Infrastrukturmanagements des
UCS, auch wenn sich die reine Groupware-Funtkionalität
auf dieser Weise
der Link bis zum Erscheinen dieses Beitrages
ändern, genügt eine Mail an »zarafa4ucs@
linet‐services.de«. Der Funktionsumfang ist
fast identisch zur beschriebenen Version für
Zarafa 6.40, ergänzt um die Möglichkeit, POP3/​
IMAP auf Benutzer-Ebene an- und abschalten zu
können. Der einzige Grund dafür, weshalb das
Paket noch im Repository zu finden ist, ist der,
dass LINET Services, Univention und Zarafa derzeit
noch klären, wie sich der Entwicklungs- und
Release-Prozess künftig verbessern lässt.
wohl gewährleisten ließe. Im Übrigen
ist es beim UCS kaum empfehlenswert,
wichtige Konfigurationsdateien etwa zur
Postfix-Konfiguration selbst anzufassen
oder durch ein externes Skript anfassen
zu lassen, denn zur Umsetzung seines
einheitliches Konfigurationsmanagement
enthält der UCS seine Univention Configuration
Registry (UCR), ein zentrales
Tool zum Verwalten der lokalen Systemkonfiguration
und damit eine Art Registrierungsmechanismus
für Systemeinstellungen.
Der Admin setzt hier einzelne
Einstellungen ausschließlich durch UCR-
Variablen. Das Verwalten der UCR-Variablen
erfolgt dabei mithilfe des Kommandos
»univention‐config‐registry«, oder dessen
Alias »ucr« auf der Konsole oder alternativ
mit dem UMC-Modul Univention
Configuration Registry im Webbrowser.
Das System aktualisiert dabei zahlreiche
Standard-Konfigurationsdateien nach jeder
Veränderung bestimmter auf sie registrierter
UCR-Variablen.
»zarafa4ucs«
Dreh und Angelpunkt der Zarafa-Integration
in UCS ist die Tatsache, dass Zarafa
ebenfalls ein Single-Sign-On auf Basis
96 Ausgabe 06-2011 Admin www.admin-magazin.de

Zarafa auf UCS
know-how
von LDAP und Kerberos oder gegen einen
existenten Active Directory Domain
Controller unterstützt. Der Admin muss
dafür entsprechende Suchanfragen in der
»ldap.cfg« des Zarafa-Servers konfigurieren.
Im Zentrum des folgenden Workarounds
steht daher die Integration der
LDAP-Schema-Erweiterung von Zarafa
zum Speichern von Zarafa-Attributen im
LDAP des UCS durch das Zarafa4ucs-Kit.
Es wurde von der LINET Services GmbH
in Braunschweig, einem Univention-
Partner der ersten Stunde, zunächst zur
eigenen Verwendung entwickelt, dann
aber der Zarafa Community-Seite samt
ausführlicher Dokumentation [6] [7] zur
Verfügung gestellt.
Das Integrationskit »zarafa4ucs« installiert
und konfiguriert Zarafa auf dem
Univention Corporate Server (UCS) und
kümmert sich dabei um das Einbinden
der Groupware in das Managementsystem
des UCS. Die LDAP-Anbindung besteht
im Wesentlichen aus dem Erstellen
eines Extended-Attributes im UCS. Das
Integrationskit ist elegant als UCS-Paket
realisiert und installiert Zarafa nicht nur
inklusive aller benötigten Komponenten
automatisch auf dem UCS, sondern sorgt
außerdem dafür, dass der Admin Zarafa
vollständig unter UCS verwalten kann.
Das Integrationspaket selbst besteht aus
zwei Komponenten, nämlich den für Zarafa
angepassten Schema-Erweiterungen
für LDAP und einigen angepassten Konfigurationsdateien
für den Betrieb auf
UCS-Systemen. Die Zarafa-Pakete der
Community-Version werden vom Integrationskit
im Zuge der Installation aus
einem eigens zur Verfügung gestellten
Apt-Repository geholt. Für das Verwenden
des Integrationspakets »zarafa4ucs«
Zarafa sollte jetzt installiert sein und
einwandfrei funktionieren. Das sonst
erforderliche manuelle Anlegen von
Zarafa-Nutzern erübrigt sich jetzt, denn
der Univention Directory Manager besitzt
nun nach erfolgreicher Installation
einen zusätzlichen Reiter »Zarafa« in der
Benutzer-Verwaltung (Abbildung 2).
Mit einem Häckchen bei »Zarafa‐User«
wird aus einem UCS Nutzer-Account auf
einfache Weise ein Zarafa-User. Login
und Passwort sind dann mit dem UCS-
Login identisch. Genauso einfach lässt
sich der User auch zum Zarafa-Admin
heraufstufen. Ebenfalls komfortabel ist,
dass sich das händische Konfigurieren
des MTA (etwa Postfix) ebenfalls erübfallen
keine zusätzlichen Lizenz-oder
Maintenance-Gebühren bei Univention
oder LINET Services an.
Installationskit einrichten
Die vorliegenden Erläuterungen beziehen
sich auf den Einsatz des Zarafa-Integrationkits
auf Basis von UCS 2.3 und 2.4.
mit Zarafa 6.40. Die zum Redaktionsschluss
bevorstehende Veröffentlichung
von UCS 3.0 (unter anderem mit Samba4-
Unterstützung) wird aller Voraussicht
nach eine geänderte Vorgehensweise
nach sich ziehen. Allerdings arbeitet die
LINET Service GmbH bereits an einer
Umsetzung.
Will man das Integrationskit in Betrieb
nehmen, geht man wie folgt vor (alle folgenden
Befehle benötigen Root-Rechte):
Der Admin richtet das entsprechende
Apt-Repository von LINET auf seinem
UCS-System zunächst als Online-Repository
ein. Es gibt für jede UCS-Version
(aktuell 2.3 und 2.4) jeweils passende
Pakete. Das Einbinden des Online-Repositorys
geschieht für UCS 2.3 so:
ucr set repository/online/component/U
zarafa4ucs/server=zarafa4ucs.LINET‐U
services.de \
repository/online/component/zarafa4ucsU
=enabled \
repository/online/component/zarafa4ucsU
/version=2.3 \
repository/online/component/zarafa4ucsU
prefix=repository
Für UCS 2.4 klappt es entsprechend mit
geänderter Versionsnummer.
Beim Verwenden einer UCS-Version 2.3
oder 2.4 mit lokalen Repository funktioniert
das Einbinden eines Online-
Repositorys mitunter nicht. In diesem
Abbildung 3: Auch die Gruppen-Verwaltung integriert sich elegant in den Directory Manager.
Fall spricht aber nichts dagegen, die
Zarafa4ucs-Paketquellen manuell einzubinden.
Bei Debian-basierten Systemen
wie UCS ist dazu eine neue »sources.
list«-Datei unterhalb von »/etc/apt/sources.list.d/«
anzulegen, deren Name mit
einer Ziffer, größer als die letzte Vorhandene
(in der Regel 20 …) beginnt,
etwa »25_zarafa4ucs.list«. Diese nimmt
je nach verwendeter UCS-Version und
Architektur-Variante beide Paketquellen
wie im folgenden Beispiel für UCS 2.3
– i386 auf:
deb http://zarafa4ucs.LINET‐services.deU
/repository/2.3/maintained/component U
zarafa4ucs/all/
deb http://zarafa4ucs.LINET‐services.deU
/repository/2.3/maintained/component U
zarafa4ucs/i386/
Danach ist ein Update der Paketquellen
mittels »apt‐get update« erforderlich. Jetzt
steht dem Installieren der Zarafa4ucs-
Pakete aus den Apt-Repositories nichts
mehr im Wege, zunächst die Zarafa-
Schema-Erweiterungen für UCS:
apt‐get install zarafa‐ucs‐schema
gefolgt von Zarafa selbst
apt‐get install zarafa‐ucs
Alles Weitere erledigt das Zarafa-Integrationspaket
automatisch und speichert
übrigens alle während der Installation
gewählten Optionen als Univention
Baseconfig-Variable, die sich nachträglich
wie gewohnt mit dem Werkzeug (»ucr«)
ändern lässt.
Zarafa administrieren
www.admin-magazin.de
Admin
Ausgabe 06-2011
97

Know-how
Zarafa auf UCS
Was macht das Integrationspaket?
Bei einer klassischen Zarafa-Installation mit
dem mitgelieferten Install-Skript kümmert sich
der Zarafa-Installer unter anderem um das Anpassen
der Konfiguration für den Zarafa-Server
sowie die wichtigsten Komponenten wie Webaccess,
Spooler, Gateway und so weiter und um
die Postfix-Konfiguration. Diese Default-Konfiguration
fällt bei der Integration mit »zarafa4ucs«
weg, weil sie für die Zusammenarbeit mit dem
UCS unzweckmäßig ist oder gar dessen Konzepte
unterläuft.
Aus diesem Grunde enthält das Zarafa4ucs-
Apt-Repository nur die reinen Debian-Pakete
für Server, Webaccess, Webaccess Mobile,
Lizenz-Dienst und einige andere. Das Zarafa4ucs-Integrationskit
installiert zunächst alle
diese Pakete und kümmert sich dann um die
Zarafa-Konfiguration und die Integration in den
Univention Directory Manager, damit sämtliche
Zarafa-Funktionen via UDM verwaltbar sind. Zarafa4ucs
integriert im Wesentlichen die LDAP-
Schema-Erweiterung von Zarafa und erstellt
ein zugehöriges Extended-Attribut im UCS. Es
benutzt dazu die im UDM vorgesehene Erweiterungsschnittstelle
sowie die UCS Registry
(UCR), um viele der Anpassungen im LDAP/​UDM
unterzubringen. Details kann der interessierte
Admin unter [6] nachlesen. Eine grobe Zusammenfassung
sieht etwa so aus:
1. Nach dem Installieren der Zarafa-Debian-Pakete
und einem Neustart des Webservers richtet
»zarafa4ucs« zunächst Zarafas Standard-LDAP-
Schema ein. Das findet sich unter »/usr/share/
doc« in Form der Archiv-Datei »zarafa.schema.
gz«. Die wird entpackt und nach »/usr/share/zarafa/«
kopiert. Danach erweitert »zarafa4ucs«
das Standard-LDAP-Schema derart, dass das
Abbildung 6: Dank »zarafa4ucs« lassen sich Zarafa-Optionen
über UCS-Base-Config-Variablen setzen.
Zarafa-Feature »zarafa contacts« mit dem Univention
Directory Manager administrierbar ist.
Zarafa4ucs ergänzt dazu den UCS um ein zusätzliches
LDAP-Attribut »z4uContact«.
Um dabei möglichst wenig Änderungen am
Original-Schema vornehmen zu müssen, haben
die Entwickler eine zusätzliche Schema-Datei
»/usr/share/zarafa/zarafa_extensions.schema«
kreiert [6]. Zum Aktiveren der LDAP-Schema-
Erweiterung muss sie ins laufende LDAP übernommen
werden. Das Zara4ucs-Kit enthält dazu
ein UCR-Template »/etc/univention/templates/
files/etc/ldap/slapd.conf.d/14zarafa‐schema«.
Zum Registrieren des UCR-Template-Files in
Univentions Configuration Registry ergänzt
»zarafa4ucs« die Datei »/etc/univention/templates/info/zarafa4ucs.info«
mit der Subfile-
Directive um den Eintrag »/etc/ldap/slapd.
conf.d/14zarafa‐schema«, ruft dann die UCR-
Kommandos
ucr register zarafa4ucs
ucr commit /etc/ldap/slapd.conf >/dev/null 2>&1
auf und startet anschließend den OpenLDAP-
Verzeichnisdienst neu.
2. Anschließend erweitert das Zarafa4ucs-Kit
den Univention Directory Manager. Der UDM
ist nämlich so konzipiert, dass er sich mit so
genannten erweiterten Attributen gezielt
aufbohren lässt, was detailliert in Univention
Server-Dokumentation [9] beschrieben ist. Die
Erweiterung erstreckt sich neben dem Erstellen
von Containern zur Aufnahme erweiterter Attribute
und weiterer Zarafa-Features wie etwa
der Adress-List-Funktion auf die beschriebenen
UDM-Bereiche für Benutzer und Gruppen.
Teil der erwähnten Erweiterung ist beispielsweise
auch ein Workaround, welcher
es erlaubt, im LDAP einen
Zarafa Contact zum normalen User
zu machen. Dieser Workaround ist
etwa erforderlich, weil es aufgrund
eines bekannten Bugs nicht möglich
ist, im LDAP die einem LDAP-User
einmal zugewiesene ObjectClass-
Klasse wieder zu entziehen. Ein
weiterer in [6] beschriebener
recht umfangreicher Work around
bezieht sich auf die Tatsache, dass
bei Zarafa normalerweise das Tool
»zarafa‐admin« zum Einsatz kommt,
um Meeting Request Options zu
ändern, die meist im Zusammenhang
mit Ressourcen zum Einsatz
kommen. Auch zum Integrieren der
Zarafa-Features Address List haben
die LINET-Experten entsprechende
Python-Skripte erstellt.
3. Den größten Teil der von »zara4ucs« vorgenommenen
Änderungen betrifft allerdings das
Anpassen der zahlreichen an der Integration von
Zarafa in UCS beteiligten Konfigurationsdateien.
Das sind sowohl alle Zarafa-Konfigurationsdateien,
deren Bedeutung unter anderem in [1]
erklärt ist, als auch die am Mail-Routing beteiligten
Postfix-Konfigurationsdateien »master.
cf« und »main.cf«.
So kümmert sich »zarafa4ucs« beispielsweise
um das Bereitstellen von Zertifikaten für die
verschlüsselte Kommunikation und konfiguriert
den Zarafa Server, Zarafa Webaccess und
Postfix. Dabei erstellt das Kit unter anderem
eine Reihe von UCR-Einträgen (Univention
Configuration Registry) zum Konfigurieren
der meisten Aspekte einer typischen Zarafa-
Installation wie
ucr set zarafa/server/mysql/host="localhost" U
zarafa/server/mysql/port="3306" U
zarafa/server/mysql/user="MySQL-User" U
zarafa/server/mysql/password="MySQL-U
Passwort" zarafa/server/mysql/U
database="Datenbank-Name"
Eine vollständige Liste findet sich in [6]. Danach
erstellt Zarafa4ucs Zarafa-Configfile-Templates
unter »/etc/univention/templates/files/etc/zarafa«
und ergänzt zum Registrieren der Templates
die Datei »/etc/univention/templates/info/
zarafa4ucs.info« um die Pfade der beteiligten
Zarafa-Konfigurationsdateien.
Zarafa4ucs kümmert sich unter anderem auch
um das Konfigurieren von Zarafa-Webaccess.
Der erfordert zum Beispiel das Aktivieren von
»magic_quotes_gpc« in der PHP-Konfiguration
»/etc/php5/apache2/php.ini«. Zum Erweitern
der UCS-Portalseite um die URL für den Zarafa-
Webaccess zieht Zara fa4ucs wieder die UCR-
Schnittstelle heran und erstellt dazu die beiden
Kommandos
ucr commit /var/www/ucs‐overview/de.html.dU
/42zarafa‐webaccess.html
ucr commit /var/www/ucs‐overview/en.html.dU
/42zarafa‐webaccess.html
Auch die Postfix-Konfiguration geschieht mithilfe
von UCR-Variablen:
ucr set postfix/mailbox_transport="mailbox_U
transport = zarafa"
ucr set postfix/zarafa=true
gefolgt von einem Restart von Postfix. Zarafa4ucs
überschreibt übrigens auch das Template
der Postfix-Konfiguration, weil sich nicht alle
erforderlichen Optionen mit dem Standard-Template
des UCS umsetzen lassen.
98 Ausgabe 06-2011 Admin www.admin-magazin.de

Zarafa auf UCS
know-how
rigt, weil der UCS dank »zarafa4ucs« die
für den jeweiligen Benutzer im UDM
hinterlegten E-Mail-Adressen automatisch
in das zugehörige Zarafa-Postfach
einliefert. Außerdem kann der Admin
an dieser Stelle auf einfache Weise
Hard- und Soft-Quotas einrichten oder
einen einfachen Shared-Store anlegen.
Ebenso elegant in den Univention
Directory Manager integriert ist die
Gruppen-Verwaltung (Abbildung 3).
Auch sie verfügt nach dem Installieren
von »zarafa4ucs« in den Gruppeneinstellungen
über einen Reiter »Zarafa«.
Setzt der Admin hier das Häckchen bei
»Zarafa‐Gruppe«, taucht diese Gruppe in
Zarafas globalem Adressbuch auf.
Übrigens lässt sich die bei der
ausgewählten Zarafa-Gruppe eingetragene
E-Mail-Adresse zum direkten
Adressieren aller Gruppenmitglieder
benutzen. Beim Versand einer E-Mail
an diese Gruppen-Adresse erhalten
dann somit alle Mitglieder der Gruppe
eine Kopie der E-Mail in ihrem Zarafa-
Postfach.
Fazit
Zarafa und der UCS sind ein interessantes
Gespann. Letzterer erschwert
mit seinem individuellen Konzept zwar
auf den ersten Blick die Integration
von Zarafa, es lohnt sich aber, sich
auf die Integration von Zarafa mit den
UCS-Konzepten einzulassen, denn
im Ergebnis lockt die durchgängige
Administrierbarkeit von Zarafa über
die Web-Schnittstelle des Univention
Servers inklusive Benutzerverwaltung
im LDAP. Dank des Engagements des
LINET Services, halten sich die Mühen
des Unterfangens in Grenzen, da das
Zarafa4ucs-Inte grationspaket sämtliche
benötigten Schritte zuverlässig automatisch
erledigt. (jcb)
n
Abbildung 5: Vor der Installation von Zarafa4ucs empfiehlt sich ein Online-Update auf die aktuellste UCS-Version.
Abbildung 4: Der Zarafa-Webaccess steht nach Installation von »zarafa4ucs« auch in der UCS-Startseite zur
Verfügung.
Infos
[1] Thomas Drilling, Zarafa 7, ADMIN 04/2011:
[http://www.admin-magazin.de/
Das-Heft/2011/04/Zarafa-7-mit-MAPI-
Unterstuetzung-und-voller-Outlook-
2010-Kompatibilitaet/%28language%29/
ger-DE]
[2] Thomas Drilling, UCS 2.4, ADMIN 03/​11:
[http:// www. admin‐magazin. de/ Das‐Heft/​
2011/ 03/ Univention‐Corporate‐Server‐fu
er‐virtuelle‐Infrastrukturen/ (language)/​
ger‐DE]
[3] Thomas Drilling, Zarafa 6.40, ADMIN
06/2010: [http://www.admin-magazin.
de/Das-Heft/2010/06/Open-Source-
Mapi-und-Active-Sync-mit-Zarafa-
6.40/%28language%29/ger-DE]
[4] Dokumentation Zarafa-Server:
[http:// www. zarafa. com/ content/​
documentation]
[5] LINET Services:
[http:// www. LINET‐services. de/]
[6] Zarafa4UCS Dokumentation:
[http:// community. zarafa. com/ pg/ plugins/​
project/ 190/ developer/ tisp/ zarafa4ucs]
[7] Zarafa4UCS:
[http:// zarafa4ucs. LINET‐services. de/]
[8] Zarafa-Community-Download
[http:// download. zarafa. com/ community/​
final/ 6. 40/]
[9] UCS-Server-Dokumentation:
[http:// www. univention. de/ download/​
dokumentation/ standarddokumentation/]
www.admin-magazin.de
Admin
Ausgabe 06-2011
99

Know-how
HA-Troubleshooting
© Gleb Semenov, 123RF
HA-Workshop, Teil 5: Troubleshooting, Tipps & Tricks
Aus der Werkstatt
HA-Cluster und umfassende HA-Setups bergen viele Fallstricke und bieten
sehr viele Fettnäpfchen. Wer mit dem Fuß in einem solchen steht, findet in
diesem Artikel die Lösung für das Problem. Martin Loschwitz
Der Alltag eines IT-Admins bietet gelegentlich
genügend Gründe für pure
Verzweifelung. Wer mit dem Linux-Clusterstack
zu tun hat, kann davon meist
eine mehrstündige Arie singen: Nach etlichen
Stunden des Tüftelns ist die CIB-
Konfiguration für Pacemaker endlich
fertig, doch beim ersten Test führt das
Abschalten eines Knotens nicht zum gewünschten
Failover. Stattdessen schwadroniert
der Kernel im »dmesg« von einem
»Split‐Brain«, und im Anschluss helfen
nicht einmal mehr die bekannten Befehle,
damit DRBD wieder tut, was es tun soll.
Und dann ist da noch die ungute Erinnerung
an das letzte Kernel-Update: Nach
dem Reboot war einiges an Konfigurationsarbeit
notwendig, um Pacemaker
zur neuerlichen Kooperation zu überreden.
Außerdem gab es Probleme mit der
Datenbank, weil Pacemaker sie immer
wieder neu gestartet hat. Eine Nacht ohne
Schlaf war der Lohn für das Bestreben,
die Software aktuell zu halten. Schrauben
und Räder hat ein Cluster einige, und entsprechend
viel kann in einem HA-Setup
daneben gehen. Dieser Artikel versucht,
die Ursachen für die häufigsten Fehler zu
erklären, und beschäftigt sich ausführlich
mit der kurz- und langfristigen Lösung
der Cluster-Probleme.
Rund um DRBD
Die Replikationslösung DRBD hat üblicherweise
direkt mit Hardware zu tun,
denn der DRBD-Treiber kommuniziert
mit den Storage-Laufwerken und sorgt
dafür, dass auf den Platten landet, was
auf die Platten gehört. Entsprechend ist
es auch der DRBD-Treiber, der als Erster
von Hardware-Problemen erfährt und
idealerweise die richtigen Gegenmaßnahmen
einleitet. Soforthilfe bringt die
»Diskless‐Primary«-Funktion, die viele
Admins gar nicht kennen.
Schon der erste Artikel dieser Serie [1]
erwähnte, dass der Befehl »drbdadm up
Ressource« eigentlich ein Alias ist. Ruft
ein Admin »drbdadm up« auf, dann tut
»drbdadm« drei verschiedene Dinge: Zunächst
sorgt es dafür, dass eine DRBD-
Ressource sich für ihr konfiguriertes
Backing-Device die exklusiven Zugriffsrechte
sichert (der Einzelbefehl hierfür
lautet »drbdadm attach«). Dann startet
es im Kernel einen Receiver-Thread und
einen Sender-Thread für die TCP/​IP-Verbindung
zum jeweils anderen Clusterknoten
(»drbdadm connect«). Schließlich
konfiguriert es auch die »rate«, also den
maximal zulässigen Datendurchsatz dieser
Ressource, wenn dieser in DRBDs
Konfigurationsdatei festgelegt ist (» drbdsetup
/dev/Minor‐Nummer ‐r Rate«).
Alternativ zu »drbdadm up« wäre es folglich
auch möglich, diese drei Befehle händisch
abzusetzen. Mit »drbdadm down«
verhält es sich übrigens ganz ähnlich: Es
ist ein Alias für »drbdadm disconnect«
und »drbdadm detach« – das Entfernen
der Syncer-Rate entfällt, weil die beim
nächsten Start der Ressource ohnehin
wieder den Wert annimmt, den sie in der
Config hat, oder den Default-Wert. Die
beiden getrennten »drbdadm up«-Kom-
102 Ausgabe 06-2011 Admin www.admin-magazin.de

HA-Troubleshooting
Know-how
mandos machen deutlich,
dass der Netzwerkzustand
einer DRBD-Ressource und
ihr Plattenzustand miteinander
nur indirekt zu tun
haben. Faktisch kann eine
DRBD-Ressource attached
sein, aber keine Netzwerkverbindung
haben.
Und umgekehrt geht’s
genauso: Eine Ressource
kann eine Netzwerkverbindung haben,
aber kein funktionierendes Backing
Device. Dieses Feature trägt den schon
erwähnten Namen »Diskless Primary
Mode« und ist ein echter Retter in der
Not, denn es sorgt im Zweifelsfalle dafür,
dass ein Dienst trotz kaputter Festplatte
unterbrechungsfrei weiterlaufen kann.
Diskless-Primary aktivieren
Ob der Diskless-Primary-Modus (Abbildung
1) zur Anwendung kommt, entscheidet
sich in der DRBD-Konfiguration.
Der Parameter heißt »on‐io‐error«, gehört
zur Sektion »disk« und kennt als wichtigste
Parameter »pass_on« und »detach«.
Bis einschließlich DRBD 8.3 war es in der
Default-Config so, dass DRBD I/​O-Fehler
von Backing Devices an das Dateisystem
weitergab und diesem die Entscheidung
überließ, was zu tun sei (»pass_on«).
Ab DRBD 8.4 ist die »detach«-Option der
Defaultwert.
Sobald DRBD mit dieser Konfiguration
Fehlermeldungen vom lokalen Storage
erhält, gibt es automatisch sein Backing
Device frei und lässt es fortan in Ruhe.
Das geschieht unabhängig davon, ob die
DRBD-Ressource gerade im » Primary«-
oder »Secondary«-Modus ist. Admins
können das feststellen, indem sie einerseits
die entsprechenden Meldungen in
»dmesg« verfolgen, andererseits ist im
Feld »ds« in »cat /proc/drbd« der Wert
für den Rechner mit der defekten Platte
ab diesem Zeitpunkt »Diskless«.
Sollte die Ressource »Primary« sein, wickelt
DRBD für sie sämtliche Lese- sowie
Schreibvorgänge ab sofort über den verbliebenen
sekundären Knoten ab.
Wann immer also ein Zugriff auf die Ressource
ohne Backing Device stattfindet,
holt DRBD sich vom sekundären Knoten
die Daten oder schaufelt sie dorthin weiter
– je nachdem, ob es sich um einen
Abbildung 1: Dank des »Diskless‐Primary«-Modus kann eine DRBD-Ressource ohne ein Backing Device im »Primary«-Modus sein.
Lese- oder Schreibzugriff handelt. Der
Vorteil für Admins liegt auf der Hand:
Es geht mit dem Server zwar für die
nächsten Stunden langsamer weiter –
denn jeder Zugriff muss ja zwischen dem
primären und dem sekundären Knoten
hin- und herwandern – dafür lässt sich
aber die Reparatur sinnvoll planen.
Der Switch over lässt sich beispielsweise
in eine Zeit legen, in der weniger auf den
Systemen los ist als zu einer Stoßzeit.
Diskless-Primary gibt dem Admin also
vor allem Zeit zum Planen.
Defekte Platten richtig
austauschen
Hat eine Platte das Zeitliche gesegnet
(oder ist durch den Defekt von mehreren
Platte ein RAID-Verbund kaputtgegangen),
braucht es nach dem Hardware-
Tausch noch ein paar DRBD-Handgriffe,
um wieder klare Verhältnisse zu schaffen.
Der Artikel geht an dieser Stelle davon
aus, dass die kaputte Hardware ausgetauscht
ist und dass im System die Storages
so aussehen wie vor dem Ausfall.
War zwischen DRBD und der Hardware
noch eine Zwischenschicht eingezogen,
beispielsweise LVM, so ist auch diese
entsprechend wiederherzustellen.
Nach dem Hardwaretausch ist die lokale
DRBD-Ressource im Grunde nicht
mehr vorhanden, vor allem dann nicht,
wenn sie interne Metadaten genutzt hat.
Aber auch, wenn externe Metadaten in
Verwendung waren – die Daten, die zu
diesen Metadaten gehören, sind nichtsdestotrotz
auf dieser Seite des Clusters
schlichtweg weg.
Der Tausch der Platte funktioniert so wie
das Anlegen einer neuen Ressource. Auf
dem Rechner mit der ausgetauschten
Platte führen die folgenden Befehle zum
Ziel: »drbdadm create‐md Ressource« legt
die Metadaten an (externe Metadaten der
vorherigen Ressource sind zu überschreiben
»drbdadm up Ressource« sorgt für
den Start der Ressource. Weil der andere
Clusterknoten als Diskstate »UpToDate«
hat, erkennt DRBD automatisch, dass der
reparierte Knoten aktuelle Daten braucht,
und startet eine komplette Synchronisation.
Bereits während diese läuft, ist
es übrigens möglich, Primary-Rolle und
Secondary-Rolle wieder zu vertauschen,
falls das notwendig sein sollte.
DRBD nachträglich
installieren
Das Thema Hochverfügbarkeit wird
immer wichtiger, und viele Setups, die
zuvor als SPOFs ihr Dasein fristeten, sollen
redundant werden. DRBD kommt da
gerade recht: Es ist einerseits eine sehr
günstige Lösung für redundante Daten,
andererseits lässt es sich ohne größere
Mühen auch auf existierende Setups
anwenden, wenn die richtigen Tipps
Beachtung finden.
Fakt ist: Nutzt eine DRBD-Ressource
interne Metadaten, dann liegen diese
am Ende der Ressource. Um auf ein vorhandenes
Storage DRBD anzuwenden,
muss es also entweder möglich sein,
das Backing Device zu vergrößern (bei
LVs in einer LVM-Volume-Group, in der
noch Platz ist, ist das die eleganteste
und sicherste Lösung) oder das darauf
residierende Dateisystem zu verkleinern.
Wer XFS verwendet, kann die
Verkleinerungsvariante vergessen, denn
XFS lässt sich ob seiner Eigenschaft als
extent-basiertes Dateisystem grundsätzlich
nicht schrumpfen.
Ist kein Plattenplatz für die Vergrößerung
des Devices mehr vorhanden und
kann das Dateisystem nicht verkleinert
werden, bleibt als letzter Ausweg nur die
Variante mit externen Meta-Daten.Wenn
interne Meta-Daten möglich sind, ist der
www.admin-magazin.de
Admin
Ausgabe 06-2011
103

Know-how
HA-Troubleshooting
Abbildung 2: Das DRBD-Kernel-Modul beschwert sich im »dmesg« ausführlich über Split Brain-Situationen …
Rest des Vorgangs quasi das berühmte
Schema F: Am Ende des zukünftigen
Backing Devices ist so viel Platz freizuschaufeln,
dass die Meta-Daten Platz
haben.
Wie groß die Metadaten im schlimmsten
Falle werden, lässt sich mit der Faustformel
„32 kByte pro repliziertem Gigabyte“
ungefähr herausfinden. Wenn
sicher ist, dass genug freier Platz am
Ende des Backing Devices vorhanden ist
und für die Ressource eine brauchbare
Konfigurationsdatei existiert, geht es mit
»drbdadm create‐md Ressource« wie gewohnt
weiter. »drbdadm up Ressource «
setzt die Ressource in Gang, »drbdadm
‐‐ ‐‐force primary Ressource « versetzt sie
in den »Primary«-Modus. Ab sofort sind
über die Ressource die gleichen Daten
verfügbar, die vorher direkt vom Backing
Device kamen. Im Anschluss kann der
neue Clusterpartner folgen – fertig ist
das Setup.
Anpassen der DRBD-
Konfiguration
»drbdadm« ist das Werkzeug, mit dem
Admins ihre DRBD-Ressourcen auf der
Kommandozeile verwalten sollen. Im
Hintergrund ruft es »drbdsetup« auf, das
die Kommunikation mit DRBDs Kernel-
Modul abwickelt. »drbdsetup« hat aber
auch noch einen anderen Nutzen: Mit
ihm lassen sich im laufenden Betrieb
zumindest einige Konfigurationsparameter
einer Ressource anpassen. Das
beste Beispiel dafür ist die Syncer-
Rate, die festlegt, wie viel Bandbreite
die DRBD-Resynchronisation höchstens
in Anspruch nehmen darf. Wenn nach
längeren Ausfällen große Mengen an
Daten zu resynchronisieren sind, wirkt
sich das unter Umständen negativ auf
die Performance des Storage-Systems
aus. Mittels »drbdset-up« lässt sich das
unterbinden. Um die Synchronisationsrate
so anzupassen, lautet der korrekte
Befehl »drbdsetup /dev/drbdMinor ‐r
Rate«. »Minor« ist dabei durch die Minor-Nummer
der Ressource zu ersetzen
und »Rate« durch die gewünschte Rate
samt Größeneinheit, also beispielsweise
»60M« für 60 Megabyte pro Sekunde.
Änderungen an der DRBD-Konfiguration,
die so vorgenommen werden, sind nach
dem nächsten Neustart der Ressource
verschwunden. Sollen sie permanent
sein, empfiehlt sich eine andere Funktion,
diesmal wieder von »drbdadm«:
der »adjust«-Befehl. Er liest die derzeit
auf der Platte liegende Config ein und
passt die Parameter der gerade laufenden
Ressourcen entsprechend an. Eine
Änderung in der Konfigurationsdatei
einer Ressource mit anschließendem
»drbdadm adjust Ressource« führt also
ebenfalls dazu, dass die neue Konfiguration
on-the-fly aktiv wird – und nach
dem nächsten Neustart noch vorhanden
ist. Vorsicht ist bei »drbdadm adjust«
trotzdem geboten: Manche Parameter
müssen auf beiden Hosts zwingend
identisch sein, sonst trennt DRBD die
Verbindung zwischen den Clusterknoten.
Genauere Informationen enthält der
DRBD User’s Guide unter [2].
Split-Brain-Situationen
mit DRBD
DRBD ist darauf ausgelegt, dass der eine
Knoten eines Clusters weiß, was der andere
Knoten gerade tut – oder sicher annehmen
kann, dass der zweite Knoten
außer Betrieb ist. Aus diesem Grunde sei
dringend dazu geraten, dass zwischen
zwei Clusterknoten mindestens zwei
Kommunikationspfade existieren, um
auch den Ausfall beispielsweise eines
Switches noch zu kompensieren.
Verlieren beide Clusterknoten zu irgendeinem
Zeitpunkt all ihre Pfade zur Kommunikation,
während sie ansonsten noch
funktionstüchtig sind, so ist das für den
Cluster eine Katastrophe. Denn solch ein
Szenario führt zwangsläufig zu Datenkorruption.
Die Clustermanager auf beiden
Seiten des Clusters glauben, der andere
Clusterknoten sei weg und sie müssten
sofort sämtliche Cluster-Dienste alleine
anbieten. Solange eine DRBD-Ressource
104 Ausgabe 06-2011 Admin www.admin-magazin.de

HA-Troubleshooting
Know-how
Abbildung 3: … und nimmt die Arbeit erst wieder auf, nachdem der Admin das Problem händisch gelöst hat.
auf einem Host den Diskstate »UpTo-
Date« hat, hindert der DRBD-Treiber den
Cluster Resource Manager nicht daran,
die Ressource in den primären Modus
umzuschalten. So nimmt das Unglück
seinen Lauf: Pacemaker macht genau das
auf beiden Clusterknoten. Und wenn wenigstens
ein Kommunikationspfad wieder
funktioniert und die Ressourcen die
Verbindung wiederherstellen könnten,
stellen sie fest, dass auf beiden Seiten
unterschiedliche Veränderungen passiert
sind. Dieses Szenario heißt „Split‐Brain“:
Alleine weiß der Cluster nun nicht mehr,
welcher der beiden Datensätze der Richtige
ist.
Fakt ist: Sollen nicht die Inhalte der beiden
Ressourcen händisch wieder zusammengeführt
werden, geht definitiv einer der
Datensätze verloren. Im DRBD-Sprachgebrauch
ist vom „Split‐Brain Victim“
und vom „Split‐Brain Survivor“ die Rede.
Die Daten von Ersterem gehen den Bach
runter, Letztere bleiben erhalten.
Ein Split Brain erkennen
DRBD ist darauf ausgerichtet, sich bei
einem Split Brain lautstark über diesen
Zustand zu beschweren. Meistens fallen
Probleme zuerst in Pacemaker auf: Weil
sich eine DRBD-Ressource mit Split Brain
partout nicht mehr von beiden Seiten aus
Abbildung 4: Wenn die Ressourcen im Cluster wie von Geisterhand außer Rand und Band geraten, ist oft eine kopierte DRBD-Konfigurationsdatei schuld.
www.admin-magazin.de
Admin
Ausgabe 06-2011
105

Know-how
HA-Troubleshooting
Abbildung 5: Mittels des »is‐managed«-Meta-Attributes lässt sich Pacemakers Klammergriff auf einzelne Ressourcen deaktivieren.
verbinden lässt, ist die Ressource in Pacemaker
als » failed« markiert. Ein Blick ins
»dmesg« verschafft Klarheit: Findet sich
darin eine Zeile wie »Split‐Brain detected
but unresolved, dropping connection!«,
ist manuelle Intervention angesagt (Abbildung
2).
Der wichtigste Schritt für den Admin ist,
das Victim und den Survivor festzulegen.
Es steht die Frage im Mittelpunkt, mit
welchem Datensatz der Cluster weiterar-
beitet. Wegen der konkreten Eigenheiten
von Setups sieht der Artikel an dieser
Stelle von einer generellen Empfehlung
ab. Stehen Victim und Survivor fest, ist
der weitere Verlauf aber klar: Auf beiden
Knoten ist zunächst »drbdadm disconnect
Ressource« sinnvoll – das stellt sicher,
dass von beiden Seiten keine Connect-
Versuche mehr ausgehen.
Jetzt erfährt das Victim, dass es das
Victim ist: »drbdadm secondary Ressource«
sichert ab, dass sich die Ressource
im »Secondary«-Modus befindet. Dann
kommt der entscheidende Befehl auf dem
Victim: »drbdadm ‐‐ ‐‐discard‐my‐data
connect Ressource« weist die Ressource
an, wieder einen Verbindungsversuch zu
unternehmen und seine eigenen Daten
zu verwerfen. »drbdadm connect Ressource«
auf dem Survivor sorgt dafür,
dass er wieder Connections akzeptiert.
Im »dmesg« findet sich für die Ressource
Abbildung 6: Der Maintenance-Modus setzt das gesamte Cluster-Management außer Kraft, ohne sich auf den Zustand der Ressourcen auszuwirken.
106 Ausgabe 06-2011 Admin www.admin-magazin.de

Linux-Magazin
ACADEMY
anschließend eine Meldung wie diese:
»Split‐Brain detected, manually solved.
Sync from this node« (Abbildung 3). Der
Split Brain ist repariert und der Normalzustand
wiederhergestellt.
Geisterhand bei der
Clusterkonfiguration
Die alltäglichen DRBD-Probleme sind damit
abgedeckt. Hinzu gesellen sich ein
paar Schwierigkeiten im Zusammenspiel
von Pacemaker und DRBD oder von Pacemaker
mit anderen Cluster-Ressourcen.
Ein häufig beobachteter Effekt ist beispielsweise,
dass beim Anlegen neuer
DRBD-Ressourcen die bereits in Pacemaker
vorhandenen Ressourcen plötzlich
Fehler anzeigen und der gesamte Cluster
aus dem Tritt gerät.
Das Problem ist allerdings handgemacht.
Es ist eine Mischung aus der Faulheit
vieler Admins und einer etwas unglücklichen
Verhaltensweise von »drbdadm«.
Häufig nehmen Admins für neue Ressourcen
die Konfigurationsdateien von
schon existierenden DRBD-Ressourcen
und ändern diese entsprechend ab.
Im Grunde spricht nichts gegen diese
Technik, denn oft verwenden sämtliche
Ressourcen auf einem System exakt die
gleichen Parameter.
Unglücklich wird die Situation, wenn
beim Anlegen der neuen Datei im Ordner
»/etc/drbd.d« einfach eine existierende
Datei kopiert wird und ihr Name
auf ».res« endet – das Standard-Suffix für
Ressourcen.
Zumindest kurzzeitig liegen dann
nämlich in diesem Ordner zwei Dateien
mit der Endung, die eine identische
Res sourcenkonfiguration haben. An dieser
Stelle steigt »drbdadm« aus und gibt
außer einer Fehlermeldung gar nichts
mehr aus, bis das Problem behoben
ist – und zwar ganz gleich, zu welcher
Ressource es Informationen ausgeben
soll (Abbildung 4).
Das letzte Puzzleteil fügt Pacemaker
selbst hinzu: Der Ressource-Agent von
Linbit, mit dem sich DRBD-Ressourcen
steuern und überwachen lassen, ruft
»drbdadm« auf, wenn der »monitor«-
Parameter angegeben wird. Solange die
DRBD-Fehlkonfiguration vorliegt, wird
aber auch Pacemaker mit einer Fehlermeldung
abgespeist – und denkt, sämt-
liche Ressourcen seien plötzlich kaputt.
Der Versuch, Ressourcen hektisch hin
und her zu verschieben, ist selten von
Erfolg gekrönt, und so bleibt der Cluster
am Ende einer solchen Aktion häufig
kaputt zurück.
Kurzfristig hilft der Cleanup-Befehl, sinnvoller
ist aber Prävention: Wer neue Ressourcen
auf Basis alter Konfigurationsdateien
anlegt, gibt diesen idealerweise
die Endung ».res.new« und benennt sie
erst um, wenn die Konfiguration tatsächlich
ordentlich eingerichtet ist. Auf diese
Weise bleiben unangenehme Effekte
jedenfalls aus.
Der Cleanup-Befehl
Beim Thema Troubleshooting soll auch
Pacemaker nicht zu kurz kommen. Der
wichtigste Befehl ist definitiv das »crm
resource cleanup«-Kommando.
Nicht immer geht beim Anlegen einer
neuen Cluster-Ressource alles glatt, gelegentlich
unterlaufen dem Administrator
Tippfehler oder es fehlt noch eine
Konfigurationsdatei: Schon schlägt der
erste Start der Ressource fehl. Wenn der
gleiche Fehler auf beiden Clusterknoten
vorhanden ist und auf beiden Knoten der
erste Start fehlschlägt, setzt Pacemaker
automatisch den Wert für »fail‐count«
bei dieser Ressource auf 1.000.000 und
lässt sie danach in Ruhe. Laufen tut sie
deshalb freilich trotzdem nicht.
Die fehlgeschlagenen Starts sind an der
eindeutigen Ausgabe in »crm_mon« eindeutig
zu erkennen. Mittels des »crm
resource cleanup«-Befehls bringt der
Clusteradmin Pacemaker dazu, den Fail-
Count auf 0 zu stellen und mit dieser
Resssource quasi von vorn anzufangen.
Heißt die Ressource zum Beispiel »res_ip_
nfs«, wäre der korrekte Cleanup- Befehl
»crm resource cleanup res_ip_nfs«. In
älteren Anleitungen findet sich möglicherweise
noch der Befehl »crm_resource
‐C ‐r Ressource« – dies ist die in Heartbeat
2 typische Vorgehensweise, weil es
die CRM-Shell damals noch nicht gab.
bei Pacemaker-Setups gibt es allerdings
keinen Grund, auf die CRM-Shell zu verzichten.
Eine Besonderheit gilt übrigens beim
»cleanup«-Kommando, wenn es um
Master-Slave-Ressourcen geht, typischerweise
also um DRBD. Hier ist der
Online-Training
IT-Sicherheit
Grundlagen
mit Tobias Eggendorfer
Themen:
❚ physikalische Sicherheit
❚ logische Sicherheit
• Betriebssystem
• Netzwerk
❚ Sicherheitskonzepte
❚ Sicherheitsprüfung
@Kirsty Pargeter, 123RF
20%
Treue-Rabatt für
Abonnenten
Deckt in Teilbereichen auch das
Prüfungswissen für LPIC-303-
Inhalte ab.
Inklusive Benutzer- und Rechteverwaltung,
Authentifizierung,
ACLs sowie wichtige Netzwerkprotokolle
und mehr!
Das Grundlagentraining für IT-
Sicherheit richtet sich an Systemadministratoren
und solche, die
es werden wollen ebenso wie an
ambitionierte Heimanwender.
Nur 299 Euro inkl. 19 % MwSt.
www.admin-magazin.de
Informationen und Anmeldung unter:
academy.linux-magazin.de/sicherheit

Know-how
HA-Troubleshooting
Abbildung 7: »grep ERROR« auf das Syslog führt zu manch erhellender Idee im Hinblick auf auftretende Probleme.
»cleanup«-Befehl nicht auf die einzelnen
Ressourcen auszuführen, sondern auf die
Master-Slave-Regel selbst. »crm resource
cleanup ms_drbd_nfs« bringt sämtliche
DRBD-Ressourcen auf allen Clusterknoten
auf Vordermann, die zum Master-
Slave-Setup »ms_drbd_nfs« gehören.
Der Maintenance-Modus
Wenn Pacemaker eine Ressource einmal
unter seine Fittiche genommen hat,
kümmert er sich nahezu rührend um sie.
Mit entsprechend eingerichteter Monitor-
Operation merkt er, wenn sie abgestürzt
ist und startet sie neu. Im Alltag der Systemadministration
kann es gelegentlich
aber vorkommen, dass eine Ressource
zeitweise gar nicht laufen soll. Wird sie
vom Admin händisch gestoppt, würde
Pacemaker die Ressource trotzdem neu
starten. Für solche Fälle ist in Pacemaker
das Meta-Flag »is‐managed« vorgesehen
(Abbildung 5).
Um eine einzelne Ressource aus den
Klauen von Pacemaker zu entreißen,
führt »crm configure« zunächst auf die
CRM-Shell, wo »edit« einen Editor mit
der aktuellen CRM-Konfiguration öffnet.
Dann gilt es, die Ressource ausfindig zu
machen, die Pacemaker kurzzeitig egal
sein soll. An die letzte Zeile von deren
Ressourcen-Konfiguration kommt ein
„\“, um den Zeilenumbruch zu maskieren.
Die nächste Zeile sieht so aus: » meta
is‐managed="false"«. Nach dem Abspeichern
und »commit« zeigt »crm_mon ‐1
‐rf« an, dass die Ressource von Pacemaker
ignoriert wird. Um den Vorgang zu
revidieren, genügt es, die hinzugefügte
Zeile wieder aus der CRM-Konfiguration
zu entfernen.
Bei größeren Wartungsarbeiten, beispielsweise
einem kompletten Update
des Clusterstacks, ist es übrigens auch
möglich, Pacemaker zeitweilig ohne Auswirkung
auf die Ressourcen komplett zu
deaktivieren (Abbildung 6). Die Funktion
heißt »maintenance‐mode«. »crm configure
property maintenance‐mode=true«
aktiviert den Wartungsmodus. Anstelle
von »true« deaktiviert »false« ihn wieder.
Es sei allerdings vor dem lässigen
Umgang mit diesem Modus ausdrücklich
gewarnt: Mancher Einfaltspinsel hat auf
genau diese Art seinen Clustermanager
unbemerkt über mehrere Wochen außer
Betrieb gesetzt – weil er vergessen hatte,
den Modus am Ende der Wartungsarbeiten
zu deaktivieren.
Fazit
Die in diesem Artikel vorgegebenen Hilfestellungen
decken erfahrungsgemäß
95 Prozent der alltäglichen Probleme ab,
die bei der Cluster-Arbeit auftreten. Wer
ein nicht beschriebenes Problem hat, findet
sowohl im DRBD User’s Guide wie
auch in Andrew Beekhofs Cluster-Handbuch
Cluster From Scratch [3] diverse
Hilfestellungen und Erläuterungen. Und
sollte eine Ressource einmal gar nicht
starten wollen, gibt es noch einen alten,
aber sehr hilfreichen Trick: Alle Fehlermeldungen,
die Pacemaker von seinen
Resource Agents serviert bekommt, gibt
er mit dem Präfix »ERROR« in die festgelegte
Logdatei aus (meist entweder das
Syslog oder »/var/log/ha‐log«. Der Befehl
»grep ERROR Logdatei« fördert meistens
sehr nützliche Informationen zutage
und gibt eine Vorstellung davon, wo das
Problem liegt (Abbildung 7). (jcb) n
Infos
[1] Martin Gerhard Loschwitz, Admin-Magazin
04/​2011, Seite 68: „Der Cluster-Leitstand“
[2] DRBD User’s Guide:
[http:// www. drbd. org/ users‐guide/]
[3] Cluster from Scratch:
[http:// www. clusterlabs. org/ doc/ en‐US/​
Pacemaker/ 1. 1/ html/ Clusters_from_
Scratch/]
Der Autor
Martin Gerhard Loschwitz arbeitet als Principal
Consultant bei hastexo. Er beschäftigt sich dort
intensiv mit Hochverfügbarkeitslösungen und
pflegt in seiner Freizeit den Linux-Cluster-Stack
für Debian GNU/​Linux.
108 Ausgabe 06-2011 Admin www.admin-magazin.de

GPT
Basics
© Gennadiy Kravchenko, 123RF.com
GUID-Partitionstabelle statt MBR in der Praxis
Table Dance
GPT – die GUID-Partitionstabelle – löst bei großen Festplatten den gewohnten
Master Boot Record zwangsweise ab. Die normalen Linux-Fdisk-
Programme kommen aber noch nicht klar mit dem neuen Partitionierungsschema.
Mit den richtigen Tools ist der korrekte Dreh aber schnell
gefunden. Hans-Peter Merkely
Seit Menschen Festplatten in PC-Gehäuse
schrauben, stoßen sie an Limits.
Mal waren es die im Bios, dann die von
Controllern [1] oder solche in den Betriebssystemen.
Maximale Sektoren,
Köpfe, Partitionsgrenzen und ‐mengen,
Bootbereiche und, und, und. In den
80ern beispielsweise zwang MS-DOS
3.2 Festplattenbesitzer dazu, ihre teuren
Schätzchen in 32-MByte-Partition aufzuteilen.
Eine solche Veteranin mit 2,5
Kilo Kampfgewicht zeigt Abbildung 1 auf
der Seite liegend. Um ihre nach heutigen
Maßstäben lächerlichen 85 MByte Kapazität
zu nutzen, waren mindestens drei
Partitionen nötig.
Das zweite, optisch kleinere Gerät auf
dem Foto dagegen ist sehr viel neuerem
Datums, eine von zwei Seagate-Festplatten
ST 33000651 AS, die der Hersteller
dem Autor für die Tests zu diesem Artikel
geliehen hat. Mit ihrer Kapazität von
rund 3 TByte überschreitet sie gegenwär-
tig das PC-geschichtlich kritische Limit
von 2 TByte, verursacht diesmal durch
die MBR-Partitionstabelle (Abbildung 2,
[2]).
Altlasten
Das klassische MBR-Partitionierungsschema
CHS ist sowieso schon lange ausgeschöpft
(maximal 1024 Cylinders * 255
Heads * 63 Sectors) mit seinen 8 GByte.
Seither nehmen Bios und Betriebssystem
immer 254 Köpfe, 63 Sektoren und 1023
Zylinder an und nutzen die jeweils 4 Byte
in der Partitionstabelle, um Position und
Größe der Sektoren festzulegen (Logical
Block Addressing, LBA).
Mit diesem Kniff lebte die PC-Welt bislang
ganz gut – doch die Zeit ist vorbei,
denn (2 32 -1 Sektoren)*512 Byte Sektorgröße
ergibt rund 2,2 TByte als maximale
Größe für eine Partition und reichlich 4
TByte als Größe der Festplatte ([3], [4]).
Wer also eine aktuelle 3-TByte-Platte am
Stück verwenden will, beispielsweise in
einem File- oder Mailserver, muss grundlegend
etwas ändern – willkommen in
der Welt der GUID-Partitionstabellen!
Die GPT ist Nachfolgerin der MBR-Partitionstabellen
und Teil des EFI-Standards
(Extensible Firmware Interface, [5]). Die
Spezifikation EFI, in der Hersteller-unabhängigen
Ausprägung heißt sie Unified
EFI (UEFI), ersetzt und vereinheitlicht die
Teile des Bios, die fürs Booten und zum
Abarbeiten von Pre-Boot-Programmen
zuständig sind. Die GPT verwendet wie
die moderneren MBR-Tabellen LBA, aber
mit 64 Bit, was Festplatten bei 512 Byte
Sektorgröße bis 8 Zettabyte adressierbar
macht, was rund 8 Milliarden TByte entspricht.
Außerdem verwaltet eine GPT bis
zu 128 Partitionen (Abbildung 3, [6]).
Trotz „Hirnschadens“:
GPT in der Praxis
Der Linux-Kernel unterstützt die aktuellen
großen Platten und GPTs seit Version
2.6.25, auch wenn Linus Torvalds EFI als
„Intels Hirnschaden“ abtut [7]. Das Testsystem
spricht die Seagate als »/dev/sdh«
an, Listing 1 zeigt, was der »dmesg«-Befehl
liefert. Beim Partitionieren mit einer
GPT verweigern die bekanntesten Programme
»fdisk« oder »cfdisk« allerdings
die Mitarbeit. Das grafische Programm
Gparted dagegen unterstützt GPTs (Abbildung
4). Die erste Festplatte soll eine
einzige große Datenpartition erhalten.
www.admin-magazin.de
Admin
Ausgabe 06-2011
109

Basics
GPT
Bootloader
Disk-Signatur
Partitionstabelle
MBR-
Signatur
Programmcode
0x0000
4 Einträge à 16 Byte
0x55AA
0x000 0x1B8 0x1BC 0x1BE 0x1FE
440 Byte
4 Byte 2 Byte
64 Byte
2 Byte
Abbildung 2: Aufbau des Master Boot Record. Die Partitionstabelle mit vier Einträgen hat nur 4 Byte pro
Sektornummer zur Verfügung.
Abbildung 1: Alt und neu: Seite an Seite eine mit
85 MByte nur äußerlich große Micropolis-Platte
aus den 80ern neben einer aktuellen 3-TByte-SATA-
Festplatte von Seagate, die für diesen Artikel als
Testobjekt diente.
In Gparted legt der Admin zuerst über
den Menüpunkt »Laufwerk« eine Partitionstabelle
an, die eine Meldung in
Übergröße nach sich zieht, dass alle
bisher darauf enthaltenen Daten verlustig
gehen. Im selben Fenster navigiert
der Administrator dann zu »Erweitert |
Partitionstabellentyp« an und wählt den
Eintrag»gpt«.
Geduld gefragt
Der Menüpunkt »Partition | Neu« macht
den Weg für eine neue primäre Partition
mit Ext 4 als Dateissystem frei. Die Ankündigung
»Abhängig von Anzahl und
Größe der Operationen kann dies einige
Zeit in Anspruch nehmen« konkretisierte
das Testsystem mit einer 10-minütigen
Auszeit. Anschließend stehen die 3 TByte
zur Verfügung – abzüglich eines stolzen
Verwaltungs-Overhead von 44,05 Gibibyte
(Listing 2).
Listing 1: Kernel erkennt 3-TByte-Platte
Listing 3 riskiert einen Blick in den 512
Byte großen Master Boot Record, den
die GPT aus Kompatibilitätsgründen auch
besitzt. Die Signatur 0x55AA signalisiert
in Zeile 5 das Ende des MBR. Im zweiten
Sektor der GPT befindet sich die Header-
Information zur GUID-Partitionierung
(Zeilen 7 bis 12). Ab Position 0x400 liegen
die Partitionseinträge, die aus folgenden
Daten bestehen:
n Partitionstyp (16 Byte)
n GUID der Partition (16 Byte)
n Beginn der Partition (8 Byte)
n Ende der Partition (8 Byte)
n Attribute (8 Byte)
n Partitionsname (72 Byte)
Die GUID (Globally Unique Identifier) ist
Namensgeberin der GPT, einer eindeutigen,
16 Byte langen Chiffre des Partitionstyps.
Tabelle 1 zeigt einige GUIDs (Quelle:
Wikipedia). Das Testsystem besitzt seit
der Gparted-Aktion eine Datenpartition.
Die zugehörige GUID lautet EBD0A0A2-
B9E5-4433-87C0-68B6B72699C7, die Umsetzung
in Zeile 14 dreht (wohl wegen
Big und Little Endian) einige Positionen
der ID um.
Backup-Block
Ans Ende des Datenträgers legt EFI übrigens
eine Kopie der GPT zu Sicherungszwecken
ab. Eine beschädigte primäre
GPT lässt sich mit Hilfe dieser Kopie wiederherstellen.
Wer ein Speichermedium
von GPT- wieder auf eine MBR-Partitionierung
zurückführen möchte, muss die
zweite GPT auch löschen, sonst erkennt
das System die Festplatte weiterhin als
GPT-initialisiert.
Kleine Auswahl
Serveradmins, die auf der Kommandozeile
arbeiten, können mit Gparted wenig
anfangen. Derzeit ist die Zahl der
GPT-geeigneten Fdisk-Ersatzprogramme
recht überschaubar. Am interessantesten
erscheint das Projekt GPT fdisk [8], es
besteht aus den Programmen »gdisk«,
»sgdisk« und »fixparts«. Ein aktuelles
Ubuntu kann nur »gdisk« über sein Repository
beziehen. Deshalb ist es sinnvoller,
alle Pakete direkt über den Open Suse
Build Service [9] zu holen.
Ist das Toolset installiert, lässt sich eine
Festplatte prüfen und bearbeiten. Gdisk
zeigt bei einer frischen Festplatte:
Partition table scan:
MBR: not present
BSD: not present
APM: not present
GPT: not present
Mit dem Kommando »p« für „Print the
partition table“ listet das Tool die Partitionstabelle
(Listing 4). Der Kurzbefehl
»o« (Create a new empty GUID partition
table) legt nach einer Sicherheitsabfrage
eine neue GPT-Tabelle an. Mit der Auswahl
»n« (Add a new partition) lässt sich
wie vorhin mit Gparted eine durchgängige
Datenpartition erzeugen. Gdisk liefert
dabei GUID-Optionen, die Gparted
nicht kennt:
01 [782663.410960] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
02 [782663.445923] ata6.00: ATA‐8: ST33000651AS, CC44, max UDMA/133
03 [782663.445931] ata6.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth
31/32)
04 [782663.446811] ata6.00: configured for UDMA/133
05 [782663.446830] ata6: EH complete
06 [782663.447076] scsi 7:0:0:0: Direct‐Access ATA ST33000651AS
CC44 PQ: 0 ANSI: 5
07 [782663.447507] sd 7:0:0:0: Attached scsi generic sg9 type 0
08 [782663.447585] sd 7:0:0:0: [sdh] 5860533168 512‐byte
logical blocks: (3.00 TB/2.72 TiB)
09 [782663.447780] sd 7:0:0:0: [sdh] Write Protect is off
10 [782663.447788] sd 7:0:0:0: [sdh] Mode Sense: 00 3a 00 00
11 [782663.447928] sd 7:0:0:0: [sdh] Write cache: enabled,
read cache: enabled, doesn't support DPO or FUA
12 [782663.448846] sdh: unknown partition table
13 [782663.474623] sd 7:0:0:0: [sdh] Attached SCSI disk
110 Ausgabe 06-2011 Admin www.admin-magazin.de

GPT
Basics
MBR Header 1 2 . . . . . . 128
512 Byte 128 Byte 128 Byte 128 Byte
Signatur
EFI PART
Revision
0x0001
0000
Headergröße
und
Prüfsumme
Reserviert
Position der
Partitionstabellen
Position des
ersten und letzten Blocks
GUID
Position der
Partitionsstelle
Anzahl der
Partitionen
Tabellen-
Prüfsumme
CRC32
Größe des
Partitionseintrags
8 Byte
4 Byte 8 Byte 4 Byte 16 Byte 16 Byte 16 Byte 8 Byte 4 Byte 4 Byte 4 Byte
Abbildung 3: Aufbau einer GPT. Nach dem wegen der Kompatibilität zu alten Betriebssystemen mitgeführten Standard-MBR folgt ein knapp 100 Byte langer Header. Die
eigentliche Partitionstabelle nimmt in 32 Blöcken die Daten von maximal 128 Partitionen à 128 Byte auf.
Use 'l' on the experts' menu to adjustU
alignment
Last sector (2048‐5860533134, default =U
5860533134) or {+‐}size{KMGTP}:
Current type is 'Linux/Windows data'
Hex code or GUID (L to show codes, Enter =U
0700):
Den vorgeschlagenen Wert »0700« für
»Linux/Windows data« übernahmen die
Tester und schrieben per »w« (Write table
to disk and exit) alles auf den Datenträger.
Zum Formatieren diente im Test
»mkfs.ext4«. Auf der Kommandozeile
dauerte der gesamte Vorgang etwa 3 Mi-
Tabelle 1: Beispiele für GUIDs
Partitionstyp
nuten weniger als mit Gparted. Die so
geschriebene GPT war identisch mit der
von Gparted erzeugten, das jedenfalls
ergab im Test ein direkter Vergleich mit
»dd« und »xxd«.
Von MBR nach GPT ...
Praktischerweise vermag Gdisk MBRpartitionierte
Festplatten in GPT-partitionierte
umzuwandeln. Das spart das Retten
und Wiederherstellen vorhandener
Partitionsinhalte. Zuständig ist das Gdisk-
Kommando »r« (Recovery and transfor-
GUID
Kein Betriebssystem
Unbenutzt 00000000-0000-0000-0000-000000000000
MBR
024DEE41-33E7-11D3-9D69-0008C781F39F
EFI-Systempartition
C12A7328-F81F-11D2-BA4B-00A0C93EC93B
Bios-Bootpartition
21686148-6449-6E6F-744E-656564454649
Linux
Datenpartition
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
Raidpartition
A19D880F-05FC-4D3B-A006-743F0F84911E
Swappartition
0657FD6D-A4AB-43C4-84E5-0933C84B4F4F
Partition für Linux-LVM
E6D6D379-F507-44C2-A23C-238F2A3DF928
Reserviert
8DA63339-0007-60C0-C436-083AC8230908
Windows
Von Microsoft reservierte Partition
E3C9E316-0B5C-4DB8-817D-F92DF00215AE
Basic-Datenpartition
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
Logical-Disk-Manager-Partition für Metadaten 5808C8AA-7E8F-42E0-85D2-E1E90434CFB3
Logical-Disk-Manager-Partition für Daten AF9B60A0-1431-4F62-BC68-3311714A69AD
Mac OS X
Partition für HFS+
48465300-0000-11AA-AA11-00306543ECAC
Partition für UFS
55465300-0000-11AA-AA11-00306543ECAC
Partition für Software-Raid
52414944-0000-11AA-AA11-00306543ECAC
Partition für Apple-TV-Recovery
5265636F-7665-11AA-AA11-00306543ECAC
mation options). Die Tester zogen dafür
einen älteren, 200 GByte großen Datenträger
mit MBR-Partitionierung aus ihrem
Fundus. Nach der Konvertierung liefert
»gdisk /dev/sde« folgendes Ergebnis:
Partition table scan:
[...]
Found valid GPT with protective MBR; usingU
GPT.
Listing 5 zeigt die Ausgabe des Forensiktools
»mmls« aus dem Sleuthkit-Paket
[10]. Zeile 2 bestätigt die erfolgreiche
Umwandlung. Interessant gestaltet sich
der Partitionseintrag selbst in Listing 6,
denn der Datentyp liegt zusätzlich zur
GUID als Texteintrag in Zeile 4 bis 6 vor.
... und umgekehrt
Gdisk konvertiert ebenfalls GPT in MBR
zurück. Diese Option funktioniert nicht
in allen Fällen und ist darum mit Vorsicht
anzuwenden. Nach Rückkonvertierung
der zuvor schon umgewandelten Festplatte
meldet sich Gdisk mit den Hinweisen
aus Listing 7. An dieser Stelle kann
Listing 2: »fdisk ‐lu« nach dem Partitionieren
01 Disk /dev/sdh: 3000 GB, 3000590369280 bytes
02 255 heads, 63 sectors/track, 364801 cylinders, total
5860528065 sectors
03 Units = sectors of 1 * 512 = 512 bytes
04
05 Device Boot Start End Blocks Id
System
06 /dev/sdh1 2048 5860532223 2930272033 83
Linux
07 Warning: Partition 1 does not end on cylinder
boundary.
www.admin-magazin.de
Admin
Ausgabe 06-2011
111

Basics
GPT
Abbildung 4: Gparted erkennt unpartitionierte 3-GByte-Platten auf Anhieb, anders als Fdisk und Cfisk. Um sie
zu nutzen, muss der Admin nun eine GPT anlegen.
»sgdisk«, das zweite Program aus dem
GPT-fdisk-Paket, hilfreich sein, das Low-
Level-Reparaturen ausführt.
Normale Festplatten speichern die Daten
in ihren Sektoren zu je 512 Bytes.
Betriebssysteme und deren Filesysteme
fassen mehrere dieser Sektoren zu einem
Cluster zusammen, häufig acht Stück,
was Cluster mit 4096 Byte Länge ergibt.
Um mehr Performance zu erreichen,
arbeiten neuerdings große Festplatten
intern ebenfalls mit 4096 Byte großen
Clustersektoren, die Hersteller sprechen
dann von „4k“-Festplatten. Die im Test
benutzten Seagate-Festplatten zählen zu
dieser Klasse.
Um nach außen für das Bios kompatibel
zu sein, übersetzt eine Festplatteninterne
Logik die Cluster wieder in 512
Byte große Sektoren. Damit die Angleichung
der Verwaltungseinheiten-Größen
von Betriebssystem und Festplatte auch
zu dem gewünschten Geschwindigkeitsgewinn
führt, sollten – egal ob MBR-
Partitionen oder mit einer GPT – die
4-KByte-Cluster der Festplatte und die
4-KByte-Cluster des Dateisystems genau
aufeinander liegen.
Andernfalls verkehrt sich der Effekt sogar
ins Gegenteil: Wenn bei einem Versatz
von 2048 Byte das Betriebssystem
zum Beispiel einen Cluster auf die Platte
schreibt, muss diese dann zwei halbe
Cluster auf seine Scheiben übertragen,
was auf zwei ganze Cluster hinausläuft.
Besonders negativ betroffen von diesem
so genannten Alignment sind SSD-Disks,
da es auf dem Flashspeicher bei überlappenden
Schreibzyklen zu einem Read-
Modify-Write-Zyklus kommt.
Startsektor 63 oder 2048
Dass Betriebssystem und Permanentspeicher
ihre Verwaltungseinheiten nicht
synchron betreiben, ist eher die Regel als
die Ausnahme. Schuld ist Microsoft, denn
die Partitionierungstools von MS-DOS bis
Windows XP lassen die erste Partition
nach dem MBR bei Sektor 63 starten. So
partitionierte Platten sind darum immer
falsch ausgerichtet. Würde die erste Partition
bei Sektor 64 beginnen, wäre dagegen
eine ganzzahlige Zusammenfassung
von 4096 Blöcken möglich. Fdisk von
Linux ahmt aus Kompatibilitätsgründen
dieses Verhalten nach ([11], [12])
Seit Windows Vista hat Microsoft das
Problem erkannt und legt bei neu zu partitionierenden
Datenträgern den Start der
ersten Partition auf Sektor 2048 statt auf
Sektor 63. Bei Fdisk von Linux muss man
je nach Version mindestens den DOS-
Kompatibilitätsmodus per Kommandozeilenoption
abschaltenden. Die Details
weiß [11] zu berichten. Alle Tools, die
eine GPT einrichten können, legen per
Default den Startsektor zum Glück auf
Position 2048.
Genau dies ließ sich bei den Tests zu diesem
Artikel beobachten: Zeile 6 von Listing
2 zeigt als Startsektor 2048 – daher
läuft die Zuordnung der ersten verwen-
Booten von GPT-Platten
Handelsübliche Serversysteme, Großrechner
und neuere Apple-Rechner entsprechen der
EFI-Spezifikation und booten darum auch von
einer GPT-initialisierten Festplatte. Desktop-
Mainboards für Intel- und AMD-CPUs dagegen
booten derzeit fast ausschließlich über ihre
MBR-Bios-Routinen.
Linuxer haben aber das große Glück, Grub 2
als Lösung des Problems an der Hand zu haben.
Der Urlader des Tools stellt nämlich dem
Rechner eine EFI-Umgebung zur Verfügung,
aus der Linux problemlos von GPT-Datenträgern
hochfährt. Achtung: Frühere Grub-Versionen
haben dieses Feature noch nicht!
Abbildung 5: Durch die ungünstige Wahl des Partitions-Startsektors 63 liegen die 4096 Byte großen Cluster von Dateisystem und Festplatte niemals aufeinander.
(Quelle: Thomas Krenn Server)
Listing 1: Kernel erkennt 3-TByte-Platte
01 [...]
02 00001c0: 0100 eefe ffff 0100 0000 ffff ffff 0000 ................
03 00001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
04 00001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
05 00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U.
06 [...]
07 0000200: 4546 4920 5041 5254 0000 0100 5c00 0000 EFI PART....\...
08 0000210: 0e0f 49ee 0000 0000 0100 0000 0000 0000 ..I.............
09 0000220: afa3 505d 0100 0000 2200 0000 0000 0000 ..P]....".......
10 0000230: 8ea3 505d 0100 0000 cbb9 6e3f 0765 a746 ..P]......n?.e.F
11 0000240: a7c2 70a1 3db8 25c4 0200 0000 0000 0000 ..p.=.%.........
12 0000250: 8000 0000 8000 0000 6afb 3a17 0000 0000 ........j.:.....
13 [...]
14 0000400: a2a0 d0eb e5b9 3344 87c0 68b6 b726 99c7 ......3D..h..&..
15 0000410: 6903 b666 b91c 7646 a8dd e9d1 d7c6 bc5a i..f..vF.......Z
16 0000420: 0008 0000 0000 0000 ff9f 505d 0100 0000 ..........P]....
112 Ausgabe 06-2011 Admin www.admin-magazin.de

GPT
Basics
deten 3-TByte-Platte optimal. Vorsicht ist
jedoch bei Datenträgern mit einer Vorgeschichte
geboten. Zeile 10 von Listing
5 zeigt nämlich, dass eine GPT auch ab
Sektor 63 statt ab 2048 starten darf. Zur
Erinnerung: Die zweite Festplatte wurde
von einem MBR-Schema in ein GPT-
Schema konvertiert. Dabei blieb dann
die Partitionsgrenze bei 63 bestehen.
Ob sich die Gesamtproblematik in der
Praxis so scharf stellt wie in der Theorie,
ist strittig, da moderne Festplatten
ein ausgeklügeltes, nur dem Hersteller
bekanntes Mapping betreiben und zudem
in den Betriebs- und Dateisystemen
diverse Puffer und Optimierungen eingebaut
sind. Es bleibt aber festzuhalten,
dass das Verlegen der Partitionen auf
4-KByte-Grenzen eine begrüßenswerte
Entwicklung darstellt, die Admins tätig
mittragen sollten.
GUID-Table, bitte zum Tanz!
Die Zeit für GPT ist definitiv angebrochen.
Moderne Festplatten benötigen
die neuen Tabellen, um Partitionen jenseits
der 2,2 TByte anzulegen. Von Fdisk
muss der Admin dabei vorerst die Finger
lassen, Tools wie Gparted springen in
die Bresche. Mit dem Bootloader Grub
2 booten auch Desktop-Mainboards problemlos
Linux von einer GPT-Platte. In
Sachen Performance heißt es, die Augen
offen halten: Dass viele moderne Speicher
intern mit 4 KByte großen Clustern
statt mit 512-Byte-Sektoren arbeiten, ist
zwar beim LBA-Adressieren nicht zu bemerken,
kann aber bei ungünstigen Partitionen
die Performance ruinieren. (jk) n
Infos
[1] ST506-Schnittstelle von 1982:
[http:// de. wikipedia. org/ wiki/ ST506]
[2] MBR: [http:// de. wikipedia. org/ wiki/​
Master_Boot_Record]
[3] MBR-Partitionstabelle: [http:// de.​
wikipedia. org/ wiki/ Partitionstabelle]
[4] FAQ: Drive Partition Limits:
[http:// www. uefi. org/ learning_center/​
UEFI_MBR_Limits_v2. pdf]
[5] EFI und UEFI:
[http:// developer. intel. com/ technology/​
efi/], [http:// www. uefi. org/ home/]
[6] GPT: [http:// de. wikipedia. org/ wiki/​
GUID_Partition_Table]
[7] „Linus On The Extensible Firmware Interface“:
[http:// kerneltrap. org/ node/ 6884]
[8] GPT fdisk:
[http:// www. rodsbooks. com/ gdisk/]
[9] GPT fdisk über den Open Suse Build
Service: [https:// build. opensuse. org/​
package/ show? package=gptfdisk&​
project=home%3Asrs5694]
[10] Sleuthkit: [http:// sleuthkit. org]
[11] Partition Alignment:
[http:// www. thomas‐krenn. com/ de/ wiki/​
Partition_Alignment]
[12] Hintergründe zum Paragon Alignment
Tool: [http:// blog. paragon‐software. de/​
uploads/ WhitePaper_ParagonAlignment-
Tool_GER. pdf]
Der Autor
Hans-Peter Merkel ist mit
dem Schwerpunkt Datenforensik
seit vielen Jahren in
der Open-Source-Community
aktiv. Er bildet Mitarbeiter
von Strafverfolgungsbehörden
in Europa, Asien und Afrika aus und engagiert
sich als Gründer und Vorsitzender bei Freioss und
Linux4afrika.
Listing 4: Partitions-Informationen von Gdisk
01 Disk /dev/sdh: 5860533168 sectors, 2.7 TiB
02 Logical sector size: 512 bytes
03 Disk identifier (GUID): 0AE667A2‐818F‐4670‐A328‐500021C76A73
04 Partition table holds up to 128 entries
05 First usable sector is 34, last usable sector is 5860533134
06 Partitions will be aligned on 2048‐sector boundaries
Listing 5: »mmls /e3v/sde«
01 GUID Partition Table (EFI)
02 Offset Sector: 0
03 Units are in 512‐byte sectors
04
05 Slot Start End Length Description
06 00: Meta 0000000000 0000000000 0000000001 Safety Table
07 01: ‐‐‐‐‐ 0000000000 0000000062 0000000063 Unallocated
08 02: Meta 0000000001 0000000001 0000000001 GPT Header
09 03: Meta 0000000002 0000000033 0000000032 Partition Table
10 04: 00 0000000063 0390716864 0390716802 Linux/Windows data
11 05: ‐‐‐‐‐ 0390716865 0390721967 0000005103 Unallocated
Listing 6: »dd if=/dev/sde | xxd« (Auszug)
01 0000400: a2a0 d0eb e5b9 3344 87c0 68b6 b726 99c7 ......3D..h..&..
02 0000410: 42c4 6d88 c9f9 c84c a33d a0a6 ceb3 2bf3 B.m....L.=....+.
03 0000420: 3f00 0000 0000 0000 c0dd 4917 0000 0000 ?.........I.....
04 0000430: 0000 0000 0000 0000 4c00 6900 6e00 7500 ........L.i.n.u.
05 0000440: 7800 2f00 5700 6900 6e00 6400 6f00 7700 x./.W.i.n.d.o.w.
06 0000450: 7300 2000 6400 6100 7400 6100 0000 0000 s. .d.a.t.a.....
Listing 7: »gdisk /dev/sde«
01 GPT fdisk (gdisk) version 0.7.1
02
03 Partition table scan:
04 MBR: MBR only
05 BSD: not present
06 APM: not present
07 GPT: not present
08
09 ***************************************************************
10 Found invalid GPT and valid MBR; converting MBR to GPT format.
11 THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if
12 you don't want to convert your MBR partitions to GPT format!
13 ***************************************************************
14
15 Exact type match not found for type code A400; assigning type code for
16 'Linux/Windows data'
www.admin-magazin.de
Admin
Ausgabe 06-2011
113

Basics
RAM erklärt
Nicholas Kinney, 123RF
RAM-Speicher erklärt
Hirnforschung
Virtualisierte Systeme treiben den RAM-Bedarf in die Höhe, Storage-Zugriffe gehen flotter, weil überschüssiger
RAM als Pagecache hilft, und schließlich vermeidet ausreichend RAM den gefürchteten Performance-Killer Swapping.
Höchste Zeit also, sich die aktuellen Random Access Memorys näher anzusehen. Werner Fischer
Arbeitsspeicher dient Prozessoren in
Computersystemen seit jeher als Speicher
für die gerade auszuführenden Programme
und ihre Daten. Seit den 80er-
Jahren wird überschüssiger Arbeitsspeicher
auch als Pagecache zum Cachen
von Disk-Zugriffen verwendet [1][2].
Als Technologie kommt seit Anfang 2000
Double Data Rate Synchronous Dynamic
Random Access Memory (DDR-SDRAM)
zum Einsatz. Im Gegensatz zum Vorläufer
SDRAM überträgt DDR-SDRAM
sowohl bei der steigenden als auch fallenden
Flanke des Taktsignals Daten und
verdoppelt damit die Datenrate.
DDR-SDRAM gibt es mittlerweile in
drei Generationen, die vierte ist bereits
in Arbeit (Tabelle 1). Aktuelle Systeme
nutzen DDR3. Da Server und Desktops
aber meist über einen Zeitraum von drei
bis fünf Jahren im Einsatz sind, findet
sich in vielen Rechenzentren und Büros
auch noch viel DDR2-Arbeitsspeicher.
Für DDR4 gibt es erste Prototypen. Da
aber die Energieeffizienz von DDR3
laufend verbessert wird und LR-DIMMs
künftig noch höhere DDR3-Speicherkonfigurationen
erlauben werden, erwarten
Analysten eine signifikante Verbreitung
von DDR4 erst ab 2014.
Fehlerkorrektur
Egal, welche DDR-Generation zum Einsatz
kommt, zur Auswahl stehen immer
herkömmliche Speichermodule und
solche, die eine Fehlerkorrektur bieten.
Letztere sind mit Mechanismen zur
Fehlerkorrektur (Error-Correcting Code,
ECC) ausgestattet und kommen vor allem
im Serverbereich zum Einsatz. Der
Vorteil liegt dabei auf der Hand: Durch
den integrierten Hamming-Code können
ECC-Speichermodule 1-Bit-Fehler erkennen
und korrigieren, 2-Bit-Fehler werden
zumindest noch erkannt. Mainboard und
Prozessor müssen ECC für die Fehlerkorrektur
unterstützen, andernfalls laufen
ECC-Module ohne ECC. Erkennbar sind
die fehlerkorrigierenden Module übrigens
auch optisch an der Anzahl der aufgelöteten
Speicherchips: Während herkömmliche
Dual-Inline-Memory-Module
(DIMMs) meist acht Speicherchips auf
einer Seite haben, findet sich bei ECC
DIMMs noch ein neunter Speicherchip.
ECC-Module sind im Vergleich zu den
herkömmlichen Modulen zwar etwas
teurer, die höhere Zuverlässigkeit rechnet
sich im Server-Betrieb aber allemal.
Pufferchips
In Desktop-Rechnern und Servern mit
einem CPU-Sockel werden sogenannte
Unbuffered DIMMs verwendet. Der Speichercontroller
greift in diesem Fall direkt
auf die Speicherchips zu. Das ermöglicht
ein gutes Preis-/​Leistungsverhältnis, da
114 Ausgabe 06-2011 Admin www.admin-magazin.de

RAM erklärt
Basics
genden Nehalem/​Westmere-Microarchitektur
(Xeon 5500 und 5600) wurden
die FB-DIMMs durch Registered DIMMs
auf Basis von DDR3 ersetzt. Durch den
Registerchip laufen nur die CMD/​ADDR/​
CLK-Signalleitungen, nicht aber die Verbindungen
für die eigentlichen Daten.
Der Energiebedarf ist damit im Vergleich
zu FB-DIMMs deutlich geringer. Einen
weiteren Schritt gehen die bereits angekündigten
Load-Reduced DIMMs (LR-
DIMMs, Abbildung 1). Die haben zwar
ähnlich wie FB-DIMMs einen Puffer (Isolation
Memory Buffer, iMB), durch den
alle Signalleitungen verlaufen. Der iMB
arbeitet allerdings nicht wie der AMB
von FB-DIMMs mit einem speziellen
Signalprotokoll, sondern wie normale Redie
Signale aber vom Speichercontroller
bis in jeden Speicherchip laufen, sind
dem maximalen Speicherausbau Grenzen
gesetzt. Dual-CPU-Systeme verwenden
aus diesem Grund andere Speichermodule,
die Pufferchips oder Register
enthalten und dadurch die Obergrenzen
erhöhen. Bei den Dual-CPU-Systemen der
Intel-Core-Microarchitektur (Xeon 5100,
5200, 5300 und 5400) kamen dazu Fully
Buffered DIMMs (FB-DIMMs) auf Basis
von DDR2 zum Einsatz.
Der auf den FB-DIMMs enthaltene
Advanced Memory Buffer (AMB) erhöht
allerdings den Energiebedarf und
die W ärmeentwicklung, die Hersteller
haben die Speichermodule daher mit
Kühl blechen ausgestattet. Bei der fol-
gistered DIMMs. Der Stromverbrauch soll
durch den iMB daher nur gering steigen.
Da bei LR-DIMMs alle Signalleitungen
durch den iMB laufen, ist die elektrische
Last für den Speichercontroller im
Vergleich zu Registered DIMMs geringer.
Gegenüber dem Speichercontroller
verhalten sich LR-DIMMs wie ein Single
Rank Modul. Die für 2012 erwarteten
Dual-CPU-Systeme der Sandy-Bridge-
Mikroarchitektur sollen als erste Systeme
LR-DIMMs unterstützen.
Rangordnung
Auf DIMMs sind immer mehrere Speicherchips
aufgelötet. Die einzelnen Chips
können entweder über vier (x4), acht (x8)
Tabelle 1: DDR-Generationen
Eigenschaft DDR1 DDR2 DDR3 DDR4 (in Entwicklung),
ab 2014 erwartet
Anzahl Kontakte 184 240 240 noch unbekannt
Betriebsspannung 2,5 V 1,8 V 1,5 V (DDR3L: 1,35V
DDR3U: 1,25V)
1,2V
Chip (I/​O Taktfrequenz)
Prefetching
DDR-200 (100 MHz),
DDR-266 (133 MHz),
DDR-333 (166 MHz),
DDR-400 (200 MHz)
Zweifach-Prefetch
(2-Bit)
DDR2-400 (200 MHz), DDR2-
533 (266 MHz), DDR2-667
(333 MHz), DDR2-800 (400
MHz), DDR2-1066 (533 MHz)
DDR3-800 (400 MHz),
DDR3-1066 (533 MHz),
DDR3-1333 (666 MHz),
DDR3-1600 (800 MHz),
DDR3-1866 (933 MHz),
DDR3-2133 (1066 MHz)
DDR3-1600 (800 MHz) bis DDR3-3200
(1600 MHz)
Vierfach-Prefetch (4-Bit) Achtfach-Prefetch (8-Bit) Achtfach-Prefetch mit zwei oder vier
Bank Groups
Typische Strukturbreiten 150nm, 100nm 100nm, 90nm, 80nm, 60nm 80nm, 60nm, 50nm,
40nm, 30nm, 25nm
30nm
MAGAZIN
ONLINE
Linux-Magazin newsLetter
Newsletter
informativ
kompakt
Nachrichten rund um die
Themen Linux und Open
Source lesen Sie täglich
im Newsletter des Linux-
Magazins.
tagesaktuell
www.linux-magazin.de/newsletter

Basics
RAM erklärt
Abbildung 1: Bei Load-Reduced DIMMs verlaufen alle Signalleitungen (einschließlich Daten) durch den
Zwischenchip. Die elektrische Last ist für den Speichercontroller damit geringer.
oder 16 (x16) Signalleitungen verfügen.
Da bei Unbuffered DIMMs die Signalleitungen
des Speichercontrollers direkt
mit den Speichercips verbunden sind,
scheiden x4-Chips hier aus – diese können
nur in Verbindung mit Pufferchips
genutzt werden.
Ein vom Speichercontroller eindeutig
adressierbarer Bereich verfügt über 64
(non-ECC) oder 72 (ECC) Signalleitungen
und wird als Rang (englisch Rank)
bezeichnet. Für ein Nicht-ECC-Speichermodul
kann ein Rang damit entweder
aus acht x8-Chips oder vier x1-Chips bestehen.
Speichermodule, die mit einem
Rang bestückt sind, werden als Single-
Rank-Module bezeichnet, solche mit
zwei Rängen als Dual-Rank-Module. Ein
einzelnes Dual-Rank-DIMM belastet den
Speicherbus übrigens gleich stark wie
zwei Single-Rank-DIMMs. Im Desktop-
Umfeld unterstützen die Speichercontrol-
ler bis zu vier Ranks pro Speicherkanal,
das entspricht zwei Dual-Rank-DIMMs.
Entsprechende Mainboards mit zwei
Speichercontrollern (Dual-Channel) sind
daher meistens mit vier RAM-Slots ausgestattet.
Es gibt zwar auch Boards mit
sechs Slots, die erlauben dann allerdings
nur jeweils ein Dual-Rank-DIMM gepaart
mit zwei Single-Rank-DIMMs pro Kanal.
Auf Boards mit drei Speichercontrollern
(Triple-Channel) finden sich im Desktop-
Umfeld ebenfalls vier RAM-Slots: zwei
Slots für den Kanal A und jeweils ein Slot
für die Kanäle B und C.
Green RAM
Neben der Entwicklung von FB-DIMMs
hin zu Registered DIMMs und LR-DIMMs
gibt es weitere technologische Fortschritte,
die den Energiebedarf von Arbeitsspeicher
laufend senken. So wurde
etwa die Betriebsspannung kontinuierlich
verringert: von 2,5V bei DDR-1 über
1,8V bei DDR2 hin zu 1,5V bei DDR3.
Mit DDR3L (1,35V) und DDR3U (1,25V)
stehen zwei weitere Reduktionen bevor,
ehe DDR4 auf 1,2V zurückgeht.
Weitere Beiträge zum Stromsparen leistet
die kontinuierliche Verkleinerung
der Strukturengrößen bei der Fertigung:
DDR1 startete mit 150nm, die Strukturbreiten
wurden bei DDR2 und DDR3 weiter
gesenkt und die ersten DDR4 Protypen
stammen gar aus einer 30nm-Fertigung.
In Summe haben es die Chip-Hersteller
geschafft, mit diesen Maßnahmen den
Energiebedarf pro GByte RAM von knapp
7 Watt bei ECC DDR2 FB-DIMMs auf aktuell
0,54 Watt bei ECC DDR3 Registered
DIMMs zu senken (Tabelle 2). (ofr) n
Infos
[1] Page Cache allgemein:
[http:// en. wikipedia. org/ wiki/ Page_cache]
[2] Page Cache in Linux:
[http:// www. thomas‐krenn. com/ de/ wiki/​
Linux_Page_Cache_Grundlagen]
[3] DDR-SDRAM:
[http:// www. thomas‐krenn. com/ de/ wiki/​
DDR‐SDRAM] (Listing 1)
Der Autor
Werner Fischer ist seit
2005 Technology Specialist
bei der Thomas-Krenn AG
und Chefredakteur des
Thomas Krenn Wikis. Seine
Arbeitsschwerpunkte
liegen in den Bereichen Hardware-Monitoring,
Virtualisierung, I/​O-Performance und Hochverfügbarkeit.
Tabelle 2: Energieverbrauch einiger Speichermodule (Quelle: ATP)
Speichermodul Kapazität Speichertyp Leistungsaufnahme
Leistungsaufnahme
je GByte
AL48M72F4GKF8S 16 GByte DDR3, Registered, ECC, 4 Rank 8,710 Watt 0,54 Watt/​GByte
AL24M72E4BKH9S 8 GByte DDR3, Registered, ECC, 2 Rank 6,132 Watt 0,77 Watt/​GByte
AL12M72B8BKH9S 4 GByte DDR3, Registered, ECC, 2 Rank, Speicherchips mit 256Mx8 Organisation
(2 Gbit Chips)
AL56M72B8BJH9S 2 GByte DDR3, Registered, ECC, 2 Rank, Speicherchips mit 128Mx8 Organisation
(1 Gbit Chips)
2,934 Watt 0,73 Watt/​GByte
5,132 Watt 2,57 Watt/​GByte
AL28M72A8BJH9S 1 GByte DDR3, Registered, ECC, 1 Rank 2,241 Watt 2,24 Watt/​GByte
AQ12M72E8BKH9S 4 GByte DDR3, Unbuffered, ECC, 2 Rank, Speicherchips mit 256Mx8 Organisation
(2 Gbit Chips)
2,214 Watt 0,55 Watt/​GByte
AQ28M72D8BJH9S 1 GByte DDR3, Unbuffered, ECC, 1 Rank 1,387 Watt 1,39 Watt/​GByte
AJ28K72F8BJE6S 1 GByte DDR2, Unbuffered, ECC 1,872 Watt 1,87 Watt/​GByte
AP56K72G4BHE6S 2 GByte DDR2, FB-DIMM, ECC 13,683 Watt 6,84 Watt/​GByte
116 Ausgabe 06-2011 Admin www.admin-magazin.de

Linux-Magazin
ACADEMY
LPIC-1
All-in-One Solution
✓
✓
✓
Stellen Sie Ihr Linux-Wissen mit
einer Zertifizierung unter Beweis!
Nutzen Sie die volle Flexibilität bei
der Zeiteinteilung Ihrer Schulung!
Holen Sie sich alles, was Sie
benötigen, in einem Paket!
LPIC-1 Komplettpaket* nur € 1.249
*Zertifizierung als „Junior Level Linux Professional“
(zzgl. MwSt.)
100% flexibel!
Weitere Infos: academy.linux-magazin.de/solution

Basics
Windows-Tuning
© Matthias Creydt, Fotolia
Leistungsüberwachung in Windows Server 2008 R2
Stellschraube
Vor allem, wenn auf einem Server noch Zusatzdienste laufen, etwa
sharepoint, Exchange oder SQL, tauchen manchmal Leistungsprobleme
auf, die sich durch die Leistungsüberwachung aufdecken und beheben
lassen. Dazu genügen mitgelieferte und kostenlose Tools. Thomas Joos
Windows Server 2008 R2 stellt mit der
Leistungsüberwachung ein mächtiges
Tool zur Verfügung, um Performance-
Probleme auf einem Server aufzudecken.
Die Bedienung hat sich im Vergleich
zu den Vorgängerversionen nur
wenig geändert. Sie finden das Tool im
Server-Manager unter »Diagnose\Leistung\Überwachungstools\Leistungsüberwachung«.
Schneller starten Sie es durch
Eingabe von »perfmon.msc« im Suchfeld
des Startmenüs. Ein Aufruf von »perfmon
/res« startet den Ressourcenmonitor,
der aktuell verbrauchten Ressourcen in
Echtzeit anzeigt, ähnlich wie der Task-
Manager.
Exchange und Active
Directory
Treten Leistungsprobleme in Exchange
oder anderen Serverdiensten auf, die von
Active Directory abhängen, zum Beispiel
beim Postfachzugriff oder dem Versenden
von Nachrichten, liegt häufig auch ein
Problem in Active Directory oder DNS
vor. Das heißt, parallel zur Leistungsüberwachung
sollten Sie noch eine Diagnose
der Namensauflösung sowie der Domänencontroller
durchführen, zum Beispiel
über »dcdiag.exe«. Exchange, aber auch
andere Dienste, die den Windows-Verzeichnisdienst
benötigen, greifen über
die Systemdatei »wldap32.dll« auf das
Active Directory zu. Dabei laufen (vereinfacht)
folgende Vorgänge ab:
n Die Datei »wldap32.dll« auf dem
Exchange-Server erhält durch einen
Exchange-Prozess eine Anfrage, um
auf den globalen Katalog zuzugreifen.
n Per DNS versucht der Server, den globalen
Katalog-Server aufzulösen, um
auf diesen zugreifen zu können. Dauert
das zu lange, verzögert sich bereits
an dieser Stelle der Active-Directory-
Zugriff.
n Nach der Namensauflösung baut
»wldap32.dll« eine Verbindung zum
globalen Katalog auf und überträgt die
Anfrage.
n Anschließend wird eine TCP-Verbindung
aufgebaut und eine LDAP-Abfrage
gestartet. Damit die Verbindung
funktioniert, benötigt die TCP-Verbindung
drei Bestätigungen durch den
Domänencontroller. Bei einer Latenz
von 10ms im Netzwerk dauert der
Zugriff also bereits 30ms, bevor der
Exchange-Server die LDAP-Abfrage
übertragen kann.
n Die LDAP-Abfrage wird auf dem
Domänencontroller von der Datei
»lsass.exe« entgegengenommen, die
auf dem LDAP-Port des Servers auf
Verbindungen wartet.
n Der Domänencontroller nimmt die
Abfrage an den globalen Katalog entgegen
und führt die Suche in seinem
globalen Katalog durch.
n Der globale Katalog sendet die Daten
über die Netzwerkkarte zur Datei
»wldap32.dll« auf dem Exchange-Server.
Handelt es sich um eine große
Anzahl an Daten, zum Beispiel beim
Auflösen der Mitglieder einer Verteilergruppe,
müssen erst alle Daten übertragen
werden, bevor Exchange mit
der Verarbeitung weitermachen kann.
Ein großer Teil der Leistung hängt also
bei Servern von der Netzwerkgeschwindigkeit
zwischen Exchange-Server und
dem globalen Katalog oder Domänencontroller
ab. Aus diesem Grund sollten Sie
bei Leistungsproblemen der Exchange-
Infrastruktur auch immer die Geschwindigkeit
des Netzwerks messen.
Grundlage:
Netzwerkperformance
Auch eine schnelle Verbindung zum
DNS-Server und eine prompte, stabile
und korrekte Namensauflösung sind sehr
wichtig. Die Verzögerung zum DNS-Server
darf 50ms nicht überschreiten, wenn
Sie die Leistung des Exchange-Servers
optimieren wollen. Dauert die Anfrage
länger, haben Sie schon den ersten Flaschenhals
bei der Exchange-Performance
gefunden. Dazu reicht das Pingen des
Servers aus, Sie benötigen noch nicht mal
die Leistungsüberwachung.
Auf der Seite [1] finden Sie das
Freeware-Tool Performance Analysis
of Logs (PAL), das bei der Auswertung
von Leistungsberichten eine
gute Hilfe sein kann. Auf der Seite
erhalten Sie das Tool und weiterführende
Hilfe und Dokumentationen
zum Thema Leistungsüberwachung
von Servern. Bei
komplexen Strukturen sollten
118 Ausgabe 06-2011 Admin www.admin-magazin.de

Windows-Tuning
Basics
Sie sich die Anleitungen auf der Seite
durchlesen. Sie benötigen für das Tool
noch die ebenfalls frei erhältlichen Zusatzprogramme
Log Parser 2.2 [2] und
Office 2003 Add-in: Office Web Components
[3].
Diese Tools müssen Sie vor der Installation
von Performance Analysis of Logs
(PAL) auf dem Server installieren. Mit
Insight für Active Directory, auch als
ADInsight bezeichnet, überwachen Sie
die LDAP-Verbindungen eines Domänencontrollers
in Echtzeit mit einer grafischen
Oberfläche (Abbildung 1). Das
Tool gehört zu den Sysinternal-Tools von
Microsoft und steht kostenlos zur Verfügung.
Sie erhalten es von der Seite [4].
Die Bedienung entspricht in etwa den
beiden Sysinternal-Tools Regmon und
Filemon. ADInsight untersucht alle Aufrufe
der Datei »wldap32.dll« und zeigt
alle Anfragen an, auch die blockierten.
Auf diesem Weg können Administratoren
Authentifizierungsprobleme von Active-
Directory-abhängigen Programmen analysieren
und feststellen, welche Clients
und Server eine Verbindung mit den
Domänencontrollern aufbauen.
Leistungsprobleme müssen nicht immer
von der Latenz oder Serverressourcen
kommen, oft liegt deren Ursache auch
in Authentifizierungsproblemen. Alle Anfragen
an den Domänencontroller protokolliert
ADInsight und speichert diese
zur Fehlersuche auch als HTML-Bericht
oder als Textdatei. Das Protokoll enthält
die Anfrage des Clients und die Antwort,
die der Client über LDAP erhalten hat.
Auch die Zugriffe der Systemdienste zeigt
ADInsight an. Bestandteil des Tools ist
eine englischsprachige Hilfedatei, die den
Anwender bei den ausführlichen Analysemöglichkeiten
unterstützt. Sobald
Programme wie Exchange auf den Domänencontroller
zugreifen, füllt sich das
Fenster mit Informationen. Über einen
Rechtsklick können Sie weitere Informationen
über die einzelnen Einträge anzeigen.
Die Anzeige lässt sich über das
Menü auch filtern.
Die Anzeige umfasst auch den Benutzernamen
des zugreifenden Benutzers.
Mit ADInsight lassen sich nur lokale Zugriffe
überwachen, eine Diagnose über
das Netzwerk per Remotezugriff ist nicht
möglich. Immerhin besteht die Möglichkeit,
über die Suchfunktion von ADIn-
Abbildung 1: Mit ADInsight lassen sich LDAP-Zugriffe auf Domänencontroller diagnostizieren.
sight nach bestimmten Prozessen, Fehlern
oder Abfrageergebnissen zu filtern. Das
Tool markiert das Ergebnis, sodass sich
auch spezifische Überwachungsvorgänge
durchführen lassen. ADInsight kann auch
automatisiert eingesetzt werden und stellt
dazu verschiedene Optionen zur Verfügung.
Hilfreich bei der Automatisierung
ist die Fähigkeit, das Protokoll in eine
Datei schreiben zu lassen, ohne die Vorgänge
in der grafischen Oberfläche anzuzeigen.
Das Tool läuft auf Windows 2000
Server und höher.
LDAP-Lesezugriffe messen
Um die Leistung von Active-Directoryabhängigen
Serverdiensten wie Exchange
im Zusammenspiel mit dem Verzeichnisdienst
zu überprüfen, benötigen Sie
zunächst die Leistungsdaten beim Abrufen
von Active-Directory-Informationen
über LDAP. Ist die Verbindung zum
Active Directory langsam, dann reagiert
auch Exchange langsam. Haben Sie Probleme
der Namensauflösung, des Active
Directory und der Authentifizierung mit
den vorangegangenen Schritten bereits
ausgeschlossen, können Sie mit der Leistungsüberwachung
die Ursache des Problems
weiter eingrenzen. Der erste Schritt
bei der Leistungsüberwachung führt
daher zunächst über die Leistungsüberwachung
auf dem Exchange-Server, die
Sie mit »perfmon.msc« starten. Klicken
Sie anschließend auf Leistungsüberwachung.
Klicken Sie auf das grüne Plus-Zeichen,
um einen neuen Indikator hinzuzufügen.
Mit Indikatoren überwachen Sie verschiedene
Ressourcen des Servers. Wählen Sie
zunächst den entsprechenden Indikator
aus und klicken Sie auf »Hinzufügen«.
Sie können eine Beschreibung der Indikatorengruppe
anzeigen, die aktuell in
der Liste ausgewählt ist. Aktivieren Sie
dazu das Kontrollkästchen »Beschreibung
anzeigen« in der unteren linken Ecke des
Bildschirms. Sie können die verfügbaren
Indikatoren einer Gruppe anzeigen,
indem Sie auf den Abwärtspfeil rechts
neben dem Gruppennamen klicken. Zum
Hinzufügen einer Indikatorengruppe
markieren Sie den Gruppennamen und
klicken auf die Schaltfläche »Hinzufügen«.
Markieren Sie einen Indikator in
der Liste, bevor Sie auf »Hinzufügen«
klicken, fügen Sie nur diesen Indikator
hinzu. Möchten Sie mehrere Indikatoren
einer Gruppe auswählen, klicken Sie bei
gedrückter [Strg]-Taste auf die Namen in
der Liste.
Sobald alle gewünschten Indikatoren
ausgewählt sind, klicken Sie auf »Hinzufügen«.
Möchten Sie nur eine bestimmte
Instanz eines Indikators hinzufügen, markieren
Sie einen Gruppennamen in der
Liste, wählen den gewünschten Prozess
in der Liste im Bereich »Instanzen des
gewählten Objekts« aus und klicken auf
»Hinzufügen«. Bei Auswahl einer Instanz
protokolliert die Leistungsüberwachung
nur die Indikatoren, die der gewählte
Prozess erzeugt. Wenn Sie keine Instanz
auswählen, protokolliert die Leistungsüberwachung
alle Instanzen, zum Beispiel
alle Prozessoren.
Als Instanzen können Sie zum Beispiel
einzelne Webanwendungen auf dem Server
auswählen oder auch alle Prozessoren
oder Prozessorkerne. Wichtig für die
Verbindung von Exchange zum Active
www.admin-magazin.de
Admin
Ausgabe 06-2011
119

Basics
Windows-Tuning
Abbildung 2: Hinzufügen von neuen Leistungsindikatoren zur Windows-
Leistungsüberwachung auf Exchange-Servern.
Directory ist die Indikatorgruppe »MSExchange
ADAccess‐Prozesse«. Diese fügt
der Exchange-Installationsassistent auf
einem Server hinzu (Abbildung 2).
Interessant sind in dieser Gruppe die beiden
Indikatoren »LDAP‐Lesedauer« und
»LDAP‐Suchdauer«. Klicken Sie dazu
auf das Pluszeichen neben der Indikatorgruppe
im oberen Bereich und dann
auf die beiden Indikatoren. Wählen Sie
im unteren Bereich Instanzen die Instanz
»Alle Instanzen« und klicken Sie
auf »Hinzufügen«. »LDAP‐Lesedauer«
misst die Zeit, die eine LDAP-Abfrage
bis zur Datenübermittlung benötigt.
»LDAP‐Suchdauer« zeigt die Zeit an, die
der Server für eine Suche per LDAP im
Active Directory benötigt.
Der Durchschnittswert für diese
Indikatoren sollte unter 50ms liegen, die
Maximaldauer sollte nicht über 100ms
steigen. Über die Symbolleiste der
Leistungsüberwachung können Sie die
Anzeige zwischen Linie, Histogrammleiste
und Bericht hin- und herwechseln.
Auf diesem Weg können Sie zum Beispiel
schneller eine Übersicht erhalten, wenn
ein bestimmter Server Probleme beim
Verbinden mit dem Active Directory hat.
Damit Active-Directory-abhängige
Dienste schnell und effizient Daten aus
dem Active Directory abrufen können,
muss der globale Katalog schnell antworten
und darf nicht überlastet sein. Um
diese Auslastung zu überprüfen, können
Sie ebenfalls die Leistungsüberwachung
verwenden. Klicken Sie anschließend
auf »Sammlung-
sätze\System\Active
Directory Diagnostics«.
Klicken
Sie anschließend
auf das grüne
Dreieck in der
Symbolleiste, um
den Sammlungssatz
zu starten.
Während der
Server die Daten
misst, versuchen
Sie, die Abfrage
auf das Active
Directory durchzuführen,
um
festzustellen, ob
das Problem auf
Seite des globalen
Katalogs liegt. Ist die Abfrage
fertiggestellt, können Sie den Sammlungssatz
über das Stopzeichen anhalten.
Zeigt ein Server Leistungsprobleme,
starten Sie den Sammlungssatz einfach
und lassen eine Zeit lang die Abfragen
messen. Nach einiger Zeit beenden Sie
die Messung über das Kontextmenü
des Sammlungssatzes oder die Symbolleiste.
Anschließend können Sie über
»Berichte\System\Active Directory Diagnostics«
die Daten der letzten Messung
anzeigen lassen. In verschiedenen Bereichen
sehen Sie alle durchgeführten Aufgaben
und deren Daten und Zugriffsgeschwindigkeiten.
Wichtig in diesem Bericht ist vor allem
der Bereich »Active Directory«. Klicken
Sie im Bericht auf den kleinen Pfeil an
der rechten Seite und wählen Sie die Option
»Suche« aus. Es öffnet sich eine neue
Seite, in der Sie die Daten und Verbindungen
sowie die Vorgänge genau anzeigen
können. Im rechten Bereich sehen Sie
die Antwortzeiten und die übertragenen
Daten. Hier sollten keine größeren Ausschläge
nach oben zu sehen sein. Je kürzer
die Antwortzeiten, desto schneller reagiert
der Server. Klicken Sie den Bericht
mit der rechten Maustaste an, können
Sie über »Ansicht\Ordner« den Inhalt des
Berichtes anzeigen lassen. In der Ordneransicht
stehen zum Beispiel auch eine
HTML-Datei sowie eine XML-Datei zur
Verfügung, die die Daten des Berichtes
enthalten. Diese Daten lassen sich mit
anderen Programmen weiterverarbeiten,
zum Beispiel mit dem bereits erwähnten
Freeware Performance Analysis of Logs
(PAL).
Speicherengpässe beheben
Performanceprobleme können eine Reihe
unterschiedlicher Ursachen haben. Ein
weiteres Problem bei der Performanceanalyse
ist, dass die Beseitigung eines
Engpasses oft zum nächsten Engpass
führt. Dafür gibt es viele Beispiele. Wer
mehr Speicher bereitstellt, erfährt oft als
Nächstes, dass auch der Prozessor bereits
an der Kapazitätsgrenze angelangt ist.
Es gibt einige grundsätzliche Regeln für
den Einsatz von Hauptspeicher. Die erste
Regel lautet: Viel hilft viel, sowohl bei
Hauptspeicher als auch beim Cache. Das
hat bei Windows Server 2008 R2 noch
mehr Gültigkeit als unter Windows Server
2003/​2008. Die zweite Regel besagt,
dass die Auslagerungsdatei am besten
auf einer anderen physischen Festplatte
als der Systempartition aufgehoben ist.
Der Preis dafür ist, dass bei einem Systemfehler
keine Speicherdumps mehr zur
Verfügung stehen.
Profis können Speicherdumps dazu nutzen,
Fehler im Betriebssystem nachzuvollziehen.
Allerdings werden diese Möglichkeiten
heutzutage eher selten genutzt, da
es zur Fehlerbehebung einfachere Tools
gibt. Die Auslagerungsdatei ist auch einer
der Bereiche, die für die Speicherverwaltung
die größte Bedeutung haben. Windows
Server 2008 R2 lagert Informationen
aus dem physischen Hauptspeicher
in die Auslagerungsdatei aus, wenn nicht
genügend Hauptspeicher zur Verfügung
steht, beziehungsweise Prozesse ihre Daten
nicht dauerhaft benötigen. Der Server
kann zwar, ausreichend freie Festplattenkapazität
vorausgesetzt, fast beliebig viel
Speicher auslagern. Es ist aber relativ
schnell der Punkt erreicht, an dem diese
Auslagerung zu langsam ist. Die Überwachung
der Auslagerung spielt daher bei
der Analyse eine wichtige Rolle.
Sie sollten die Auslagerungsdatei auf eine
andere physische Festplatte des Servers
verschieben, damit Schreibzugriffe auf
die Auslagerungsdatei nicht von Schreibzugriffen
auf der Festplatte ausgebremst
werden. Wenn keine zweite physische
Festplatte zur Verfügung steht, ist ein
Verschieben sinnlos, da die Auslagerung
120 Ausgabe 06-2011 Admin www.admin-magazin.de

Windows-Tuning
Basics
auf eine Partition, die auf derselben Platte
liegt, keine positiven Auswirkungen hat.
Zusätzlich können Sie die Größe der Auslagerungsdatei
auf etwa das 2,5-Fache
des tatsächlichen Arbeitsspeichers legen.
Damit verhindern Sie die Fragmentierung
der Datei, da Windows diese nicht ständig
vergrößern oder verkleinern muss.
Die Einstellungen für die Auslagerungsdatei
finden Sie unter »Start\Systemsteuerung\System
und Sicherheit\System\
Erweiterte Systemeinstellungen« auf
der Registerkarte »Erweitert« mit »Leistung\Einstellungen\Erweitert\Virtueller
Arbeits speicher\Ändern«.
Deaktivieren Sie das Kontrollkästchen
»Auslagerungsdateigröße für alle Laufwerke
automatisch verwalten«. Aktivieren
Sie die Option »Benutzerdefinierte
Größe«, wenn Sie selbst eine Größe
der Datei festlegen wollen. Setzen Sie
bei »Anfangsgröße« und bei »Maximale
Größe« in etwa das 2,5-Fache des Arbeitsspeichers
ein. Dadurch ist sichergestellt,
dass die Datei nicht fragmentiert wird, da
sie immer die gleiche Größe hat. Setzen
Sie die Größe der Auslagerungsdatei für
Laufwerk C: auf 0. Klicken Sie auf »Festlegen«,
um die Änderungen zu speichern,
schließen Sie alle Fenster und starten Sie
den Server neu.
Auf einem Core-Server verschieben Sie
die Auslagerungsdatei am besten mit
dem Befehl
Wmic pagefileset where name="Pfad"U
set InitialSize=Anfangsgröße,U
MaximumSize=Maximale Größe
Zuvor beenden Sie die automatische Konfiguration
mit dem Befehl
wmic computersystem where name="Hostname"U
set AutomaticManagedPagefile=False.
Interessante Hinweise zu diesem Vorgang
finden Sie auch unter [5]. Die naheliegende
Konsequenz bei Speicherengpässen
ist, mehr Arbeitsspeicher den Server
einzubauen. Nur ist das keineswegs auch
immer der sinnvollste Weg. In jedem
Fall sollten Sie zunächst untersuchen,
welche Prozesse für die hohe Speicherauslastung
verantwortlich sind. Dazu
verwenden Sie das Objekt »Prozess« in
der Leistungsüberwachung. Auch die
Prozessorleistung kann natürlich einen
solchen Flaschenhals darstellen. Zu wenig
Hauptspeicher kann die Konsequenz
haben, dass auch der Prozessor sehr
stark belastet ist. Denn die Auslagerung
von Seiten und viele andere Vorgänge gehen
natürlich nicht spurlos am Prozessor
vorbei. Schließlich ist er maßgeblich an
der Verwaltung des Arbeitsspeichers beteiligt.
Da Engpässe beim Hauptspeicher
typischerweise deutlich kostengünstiger
zu beheben sind als solche beim Prozessor,
sollte diese Situation zunächst
untersucht werden. Es ist in Ordnung,
wenn die die Auslastung kurzzeitig oder
nur gelegentlich über 90 Prozent liegt.
Zum Problem wird es erst, wenn sie andauernd
in diesem Bereich liegt.
Bei Mehrprozessorsystemen gilt das Augenmerk
natürlich vor allem den Leistungsindikatoren
aus dem Objekt »System«.
Dort fasst Windows die Informationen
von mehreren Systemkomponenten
zusammen. So ermitteln Sie die Gesamtbelastung
aller Prozessoren. Ergänzend
sind aber auch hier die Leistungsindikatoren
»Prozessorzeit« des Objekts
»Prozessor« von Bedeutung. Wenn viele
verschiedene Prozesse laufen, ist eine einigermaßen
gleichmäßige Lastverteilung
fast sicher. Bei einem einzelnen Prozess
ist dagegen die Aufteilung in einigermaßen
gleichgewichtige Threads wichtig.
Ein Thread ist eine Ausführungseinheit
eines Prozesses. Wenn ein Prozess mehrere
Threads verwendet, können diese
auf unterschiedlichen Prozessoren laufen.
Die Verteilung erfolgt entsprechend
der Auslastung der einzelnen Prozessoren
durch das System. Eine hohe Zahl von
Warteschlangen bedeutet, dass mehrere
Threads rechenbereit sind, ihnen aber
vom System noch keine Rechenzeit zugewiesen
wurde. Die Faustregel für diesen
Wert ist, dass er nicht allzu häufig über
2 liegen sollte. Wenn die Auslastung des
Prozessors im Durchschnitt relativ gering
ist, spielt dieser Wert nur eine untergeordnete
Rolle.
Um die Leistung eines Servers zu messen,
spielen also vor allem die Überwachung
des Prozessors, des Arbeitsspeichers, der
Netzwerkgeschwindigkeit und die Antwortzeiten
des Active Directorys eine wesentliche
Rolle. Bei virtuellen Servern, die
Sie mit Hyper-V in Windows Server 2008
R2 einsetzen, sollten Sie auf jeden Fall
das Service Pack 1 für Windows Server
2008 R2 einsetzen und Dynamic Memory
aktivieren. Dynamic Memory ermöglicht
die dynamische Zuteilung von Arbeitsspeicher
zwischen den virtuellen Servern.
Sie können für virtuelle Computer
einen Minimalwert und einen maximalen
Wert für den Arbeitsspeicher zuteilen.
Zusätzlich können Sie den Server noch
gewichten, sodass Hyper-V entscheiden
kann, welcher Server welche Menge an
Arbeitsspeicher erhält. Der Vorteil ist,
dass der Arbeitsspeicher dynamisch
zur Verfügung steht, sodass Server, die
zeitweise mehr RAM benötigen, diese
automatisch von Hyper-V zugeteilt bekommen.
Andere Server, die zeitweise
nicht ihren kompletten Speicher benötigen,
geben ihn dafür ab.
Fortgeschritten
Reichen Ihnen die Möglichkeiten der
Leistungsüberwachung nicht aus, bietet
Microsoft weitere Lösungen an. So
lässt sich mit dem kostenlosen Windows
Performance Toolkit von Microsoft die
Leistung eines Systems ebenfalls sehr
effizient messen. Mehr dazu verrät ein
Artikel im ADMIN 05/2011 [6]. (ofr) n
Infos
[1] PAL: [http:// pal. codeplex. com]
[2] Log Parser 2.2: [http:// www. microsoft.​
com/ downloads/ details. aspx? FamilyID=8
90cd06b‐abf8‐4c25‐91b2‐f8d975cf8c07&​
DisplayLang=en]
[3] Office 2003 Add-in: Office Web Components:
[http:// www. microsoft. com/​
downloads/ details. aspx? FamilyID=7287
252c‐402e‐4f72‐97a5‐e0fd290d4b76&​
DisplayLang=en]
[4] Active Directory Insight: [http:// technet.​
microsoft. com/ de‐de/ sysinternals/​
bb897539]
[5] Command for changing the page file:
[http:// forums. microsoft. com/ TechNet/​
ShowPost. aspx? PostID=2599415&​
SiteID=17]
[6] Thomas Joos, Windows Performance Toolkit,
ADMIN 05/​2011, S. 58
Der Autor
Thomas Joos ist freiberuflicher IT-Consultant
und seit über 20 Jahren in der IT tätig. Neben
seinen Projekten schreibt er praxisnahe Fachbücher
und Fachartikel rund um Windows und
andere Microsoft-Themen. Online trifft man ihn
unter [http:// thomasjoos. spaces. live. com].
www.admin-magazin.de
Admin
Ausgabe 06-2011
121

Programmieren
Python
Skriptprogrammierung mit Python
Werkzeugkasten
Es ist nicht alles Shell, was glänzt. Auch mit Python lassen sich Systemaufgaben unkompliziert skripten. Dieser
Artikel gibt eine Einführung in die moderne Skriptsprache. Oliver Frommel
Wenn ich auf einem Linux-Rechner ein
komplizierteres Problem auf der Kommandozeile
lösen möchte, mache ich
das nur in einfachen Fällen mit einem
Shellskript. Bei Fallunterscheidungen,
Schleifen und Variablen ist mir die
Syntax zu kompliziert. Das liegt sicher
auch an fehlender Übung, aber warum
sollte ich mich mit dem Erlernen einer
weiteren Programmiersprache, in diesem
Fall der Shell abmühen, wenn ich
etwa mit Python einfache wie komplexe
Programme schreiben kann?
Zudem hat sich Python in den letzten 15
Jahren als Standard auf allen Betriebssystemen
und Linux-Distributionen etabliert.
Die Versionen 2.5 bis 2.7 sind weitgehend
kompatibel und auf den meisten Plattformen
verfügbar – einschließlich Windows
und Mac OS X. Python zeigt sich inklusive
seiner umfangreichen Zusatzbibliotheken
als ausgereiftere Plattform. Bei
aller Sympathie für Ruby muss man feststellen,
dass es in der Ruby-Welt häufige
und teilweise inkompatible Änderungen
gibt, die die Portabilität von Skripten erschweren
(eine Lösung dafür bietet der
Ruby Version Manager, den ein Artikel in
diesem Heft näher vorstellt).
Über die Installation von Python gibt es
nicht viele Worte zu verlieren, da es auf
allen Linux-Distributionen wie auch auf
Mac OS X standardmäßig zur Verfügung
steht. Für Windows gibt es einfache
Installer, die nur wenige Klicks benötigen.
Eine interessante Alternative für
Windows ist der Ironpython-Interpreter,
der die Programmiersprache auf der
Dotnet-Runtime implementiert.
Weißraum
Das charakteristische Feature von Python,
an dem sich die Geister scheiden, ist die
Kennzeichnung von Blocks per Whitespace,
das heißt durch die Tiefe der Einrückung,
sei es mittels Leer- oder Tab-
Zeichen. Ruft man den Python-Interpreter
»python« auf der Kommandozeile auf,
gelangt man in einen Modus, der sich für
die interaktive Erforschung der Sprache
eignet. Alternativ dazu bietet sich der
IPython-Interpreter [1] an, der ebenfalls
eine interaktive Umgebung aber noch
einigen Komfort mehr – wie etwa die
automatische Vervollständigung von
Methoden – bietet (Abbildung 1).
Eine einfache If-Unterscheidung
sieht in Python beispielsweise so
aus:
user = "root"
if user == "root":
print "Superuser"
privileged = True
else:
print "Normalo"
privileged = False
Vladimir Yudin, 123RF
Hier ist zu sehen, wie die einzelnen
Blöcke durch die Einrückungstiefe gekennzeichnet
werden. Vor der Print-Anweisung
im If-Block und der Zuweisung
an die Variable »privileged« muss die
gleiche Zahl an Leer- beziehungsweise
Tab-Zeichen stehen. Ich bevorzuge hierbei
Leerzeichen, da es erfahrungsgemäß
weniger Probleme damit gibt, ein Skript
in unterschiedlichen Editoren und auf
mehreren Plattformen zu bearbeiten.
Hinweise zur entsprechenden Einstel-
122 Ausgabe 06-2011 Admin www.admin-magazin.de

Python
Programmieren
lung des Vi(m)-Editors gibt der Kasten
„Vim-Konfiguration“. Praktisch ist hierbei,
dass man zur Eingabe trotzdem die
Tab-Taste verwenden kann, die der Editor
dann durch die konfigurierte Zahl von
Leerzeichen ersetzt.
Was das obige Code-Beispiel außerdem
illustriert, ist die Tatsache, dass Anweisungen
nicht durch Semikolons abgeschlossen
werden müssen (wie etwa in
Perl oder PHP). Hinter den Fall-Unterscheidungen
von If und Else folgt jeweils
ein Doppelpunkt. Das ist beispielsweise
auch bei For- oder While-Schleifen der
Fall, mit denen man über häufig verwendete
Datenstrukturen wie numerische
und assoziative Arrays (sogenannte
Dictionaries) iteriert, etwa:
packages = ['apache', 'xftpd', 'postfix']
for package in packages:
print package
Diese Syntax ist auch für Nicht-Programmierer
beinahe intuitiv verständlich, während
die Verarbeitung von Arrays in einem
Bash-Skript mit vielen eckigen Klammern
mir eher qualvoll erscheint. Bei jedem
Schleifendurchgang findet hier eine Zuweisung
statt, die jeweils das aktuelle Element
der Liste »packages« an die Variable
»package« zuweist. Etwas komplizierter
gestaltet sich das Gleiche mit Dictionaries.
Mit der eingebauten Methode »keys()«
lassen sich die Schlüssel auslesen, mit
»values()« die dazugehörigen Werte. Iteriert
man über die Keys, kann man den
jeweiligen Schlüssel dazu verwenden, um
an den Wert zu gelangen:
versions = {'apache': 2.4, 'xftpd': 1.0}
for package in versions.keys():
print package, versions[package]
Das lässt sich mit der Methode »items()«
auch in einem Schritt erreichen:
for package, version in versions.items():
print package, version
Wie man hier sieht, besitzt Python als
objektorientierte Programmiersprache für
die eingebauten Datentypen eine Reihe
praktischer Methoden, um zum Beispiel
Listen (Arrays) zu verändern: »append()«
hängt ein Element an, »del()« löscht ein
Element per Index, »remove()« löscht es
nach dem Wert, »len()« gibt die Länge
des Arrays aus und so weiter. Alle Methoden,
die zu einem Datentyp (oder an-
Abbildung 1: Die IPython-Umgebung bietet gegenüber dem normalen Python-Interpreter noch mehr Komfort:
etwa Tab-Completion, automatische Ergänzung von Klammern, Objekt-Introspektion und vieles mehr.
die Import-Anweisung geladen werden
müssen. Als „Bad Practice“ gilt es dabei
eigentlich, ein komplettes Modul per »import
Modul« zu laden. Stattdessen sollte
man nur die Methoden beziehungsweise
Klassen importieren, die man auch wirklich
verwendet, etwa mit »from string
import lower«.
Mit dem OS-Modul lassen sich typische
Teilschritte von Shellskripten lösen, wie
etwa in ein Verzeichnis zu wechseln
(»chdir()«), das aktuelle Arbeitsverzeichderen
Klassen) gehören, lassen sich der
Python-API-Dokumentation entnehmen.
Beispielsweise empfiehlt sich ein Blick
in die String-Klasse [2], da man ohne
die Verarbeitung von Strings wohl in den
seltensten Fällen auskommen wird.
Module
Python besteht aus dem Interpreter, der
den Sprachkern implementiert und aus
einer Sammlung von Standard-Modulen,
ohne die sich kaum Skripts schreiben
lassen, die wirklich Arbeit verrichten.
So implementiert das Modul »os« eine
Schnittstelle zum Betriebssystem [3].
Viele Methoden sind auf allen Betriebssystemen
gleichermaßen verfügbar, manche
unterscheiden sich zwischen Unix
(Linux, Mac OS X …) und Windows, andere
lassen sich sogar dazu verwenden,
Portabilitätsprobleme zu lösen. Einen
Überblick über die aktuelle Umgebung
liefert beispielsweise das Dictionary »os.
environ«, dessen Ausgabe auf Mac OS X
in Listing 1 abgedruckt ist.
In Listing 1 ist auch zu sehen, dass nicht
im Sprachkern vorhandene Module über
Vim-Konfiguration
Da Python die Grenzen von Blocks per Einrückungstiefe
kennzeichnet, muss der verwendete
Editor sorgfältig damit umgehen und
am besten die Arbeit damit erleichtern. Es
bietet sich an, ihn so einzustellen, dass ein
Druck auf die Tab-Taste zwar den folgenden
Text ein Stück weit einrückt, aber statt eines
Tab-Zeichens die entsprechende Anzahl an
Leerzeichen eingefügt wird. Im Vi(m)-Editor
lässt sich das mit der folgenden Konfiguration
in der Datei ».vimrc« erreichen:
set expandtab
set tabstop=3
set shiftwidth=3
set smartindent
www.admin-magazin.de
Admin
Ausgabe 06-2011
123

Programmieren
Python
Listing 1: »os.environ« auf OS X
01 >>> import os
02 >>> for key, value in os.environ.items():
03 ... print key, value
04 ...
05 VERSIONER_PYTHON_PREFER_32_BIT no
06 TERM_PROGRAM_VERSION 273.1
07 LOGNAME oliver
08 USER oliver
09 PATH /opt/local/bin:/opt/local/sbin:/Users/oliver/
bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/
usr/local/bin:/usr/texbin:/usr/X11/bin
10 DISPLAY /tmp/launch‐X9bzHU/org.x:0
11 TERM_PROGRAM Apple_Terminal
12 LANG de_DE.UTF‐8
13 TERM xterm‐color
14 VERSIONER_PYTHON_VERSION 2.6
15 SHLVL 1
16 _ /usr/bin/python
17 HOME /Users/oliver
18 SSH_AUTH_SOCK /tmp/launch‐9nXMJp/Listeners
19 SHELL /bin/bash
20 TMPDIR /var/folders/Sd/
SdnFaCHZE5CuSIG3‐c1lpU+++TI/‐Tmp‐/
21 __CF_USER_TEXT_ENCODING 0x1F5:0:3
22 PWD /Users/oliver
23 COMMAND_MODE unix2003
Listing 2: »os.walk()«
01 import os
02 from os.path import join, getsize
03 for root, dirs, files in os.walk('python/Lib/email'):
04 print root, "consumes",
05 print sum(getsize(join(root, name)) for name in
files),
06 print "bytes in", len(files), "non‐directory
files"
07 if 'CVS' in dirs:
08 dirs.remove('CVS') # don't visit CVS
directories
Listing 3: Zugriff auf SQLite
01 from pysqlite2 import dbapi2 as sqlite
02 import sys
03
04 db = "urls.db"
05 conn = sqlite.connect(db)
06 if not conn:
07 debug("can't get db connection")
08 sys.exit()
09 conn.execute('create table if not exists urls ( url
text, time integer )')
10
11 c = conn.cursor()
12 c.execute('insert into urls values ( ?,
strftime("%s","now"))', (url,))
13 conn.commit()
14 url = "http://www.admin‐magazin.de"
15 results = c.execute('''select * from urls where url =
?''', (url,))
16 for result in results:
17 print result
nis auslesen (»getcwd()«). Die Eigentumsverhältnisse
ändert »os.chown()«,
die Rechte »os.chmod()«. Dateien und
Verzeichnisse lassen sich mit dem Modul
anlegen, löschen, umbenennen. Darüber
hinaus enthält es Low-Level-Methoden,
um Dateien zu öffen, zu lesen, zu
schreiben und so weiter. Mit der Methode
»walk()« kann ein Skript einen
Verzeichnisbaum durchschreiten, wie es
Listing 2, ein Beispiel aus der Python-
Dokumentation, vormacht. Ab Python
2.6 versteht die Walk-Methode einen Parameter
»followlinks«, der festlegt, ob sie
symbolischen Links folgt oder nicht.
Bis zu Python 2.5 waren auch die Popen-
Methoden, die die Kommunikation mit
Subprozessen ermöglichen, Bestandteil
des OS-Moduls. Mit Version 2.6 wurden
sie durch ein neues Subprocess-Modul ersetzt
[4]. Damit lassen sich zum Beispiel
Unix-Tools aufrufen und deren Ausgabe
im Python-Skript weiterverarbeiten. Im
einfachsten Fall geht das mit »subprocess.
Popen()«, dem man als erstes Argument
die auszuführende Kommandozeile als
Array übergibt. Die dafür nötigen Tokens
gewinnt man aus einer einfachen Zeichenkette
beispielsweise mit »split()« aus
dem »shlex«-Modul:
cmd = '''import ‐window root screen.png'''
args = shlex.split(cmd)
subprocess.Popen(args)
Die Popen-Methode kennt noch eine
Reihe weiterer Parameter, etwa um ein
Dictionary von Umgebungsvariablen zu
übergeben. Insbesondere sollte man in
den meisten Fällen darauf verzichten,
per »Shell=true« eine Subshell zu starten,
weil das mögliche Sicherheitslücken
öffnet.
Um an die Ergebnisse zu gelangen, bietet
es sich an, die Standardausgabe umzuleiten
und dann mit der Communicate-
Methode auszulesen:
result = subprocess.Popen("ls", stdout=U
subprocess.PIPE).communicate()
print result
('artikel.txt\n', None)
print result[0]
'artikel.txt\nbild.png\n'
Das ist zugegebenermaßen keine besonders
schöne Methode und ziemlich viel
zu tippen. Einfacher geht es mit dem OS-
Modul, auch wenn dessen Verwendung
nicht mehr empfohlen wird:
result = os.popen('ls').read()
'artikel.txt\nbild.png\n'
Das Ergebnis kann mithilfe der »split()«-
Methode der String-Klasse wieder leicht
in eine Liste zerlegt werden. Man sollte
auch nur im Ausnahmefall auf das Aufrufen
von Unix-Kommandos ausweichen
und stattdessen eines der über 3000
Python-Module verwenden, die die meisten
Anwendungsgebiete abdecken.
Regulär
Auch Regular Expressions für die Verarbeitung
von Strings gehören zur Standardausstattung
einer Python-Installation.
Nach dem Importieren des dazugehörigen
Moduls stehen Methoden
wie »search()« und »match()« zur Verfügung.
Der Unterschied besteht darin,
dass Match nur am Anfang eines Strings
nachsieht, sein Pendant Search aber den
ganzen String durchsucht. Die Anwendung
sieht etwa so aus:
import re
s = "Regulär ausgedrückt"
m = re.search('(Reg.*) ', s)
m.group(0)
'Regul\xc3\xa4r '
print m.group(0)
Regulär
Wie man sieht, funktioniert das auch
mit Umlauten, allerdings muss man dabei
auf die richtige Zeichen-Codierung
achten. Aktuelle Python-Versionen können
mit UTF-8 umgehen, manchmal ist
es aber erforderlich, Strings erst in die
richtige Codierung zu wandeln, etwa mit
der »unicode()«-Methode. Mehr dazu
verrät das Python-Unicode-Howto. Das
Encoding einer Python-Quelldatei lässt
sich festlegen, indem man in der ersten
Zeile (nach dem Aufruf des Interpreters)
einen Kommentar in folgendem Format
schreibt: »# encoding: utf‐8«.
Datenbanken
Für den Zugriff auf relationale Datenbanken
bietet Python ein mehr oder weniger
standardisiertes Interface über die DB-API
2.0 an, etwa für die Standards MySQL,
PostgreSQL oder SQLite. Ein Beispiel für
SQLite ist in Listing 3 zu sehen.
Die meisten Statements dürften sich für
alle diejenigen selbst erklären, die schon
124 Ausgabe 06-2011 Admin www.admin-magazin.de

Python
Programmieren
einmal mit einer SQL-Datenbank gearbeitet
haben. Interessant ist die Verwendung
sogenannter Prepared Statements, vor allem
beim Insert in Zeile 12. Insbesondere
bei Webanwendungen ist dies ein Gegenmittel
gegen SQL-Injections. Die Argumente
sind in eine Tupel-Datenstruktur
zu verpacken, was bei einem Tupel mit
nur einem Element zu der etwas eigentümlichen
Schreibweise mit einem abschließenden
Komma führt.
Webverarbeitung
Um mit Webseiten umzugehen, bringt
Python einige nützliche Module mit. So
sind dank der »urllib« nur wenige Zeilen
nötig, um eine Webseite oder eine im Web
gespeicherte Datei herunterzuladen.
import urllib
url = "http://www.spiegel.de"
u = urllib.urlopen(url)
data = u.read()
Die Methode »urlretrieve()« speichert
Webseiten als Datei. Um beispielsweise
den User-Agent-String selbst zu setzen,
leitet man die eigene Klasse vom »Fancy-
URLopener« ab und setzt in ihr die Klassenvariable
»version« auf den gewünschten
Wert. Wer ein großes Webmining-
Projekt plant, sollte daran denken, den
Inhalt der Datei »robots.txt« zu respektieren
und ein gewisses Maß an Vernunft
walten zu lassen. Einen relativ robusten
Parser für das oft nicht korrekte HTML
findet man in Beautiful Soup [5].
Ausblick
Eine Vorstellung der praktischen
Python-Module lässt sich noch endlos
fortsetzen, eine Liste findet sich unter
[6]. Gerade zur Systemverwaltung gibt
es schon eine Reihe Pakete, die bereits
auf Linux-Distributionen installiert sind,
etwa »python‐fstab«, »python‐cups« oder
»python‐xdg«. Wer daran interessiert ist,
sollte einfach mal die Liste der installierten
Pakete durchsehen. Das ADMIN-
Magazin wird nützliche Module im Rahmen
dieser Python-Reihe regelmäßig
vorstellen, etwa für LDAP, Logdateien,
Virtualisierung und vieles mehr. (ofr) n
Infos
[1] IPython: [http://i python. org]
[2] String-Library:
[http:// docs. python. org/ release/ 2. 6/​
library/ string. html]
[3] OS-Modul:
[http:// docs. python. org/ library/ os. html]
[4] Subprocess:
[http:// docs. python. org/ library/​
subprocess. html]
[5] Beautiful Soup:
[http:// www. crummy. com/ software/​
BeautifulSoup/]
[6] Useful Modules:
[http:// wiki. python. org/ moin/​
UsefulModules]
Alles zum ThemA Android
Die Monatszeitschrift für Android-Fans, Smartphone- und Tablet-Nutzer
Neu!
Kennenlernangebot:
3 AusgAben
für nur 3 euro
Jetzt bestellen unter:
www.android–user.de/miniabo
Telefon 07131 / 2707 274 • Fax 07131 / 2707 78 601 • E-Mail: abo@android-user.de

Programmieren
Ruby Environment Manager
Der Ruby Environment Manager (RVM) im Einsatz
Der Verwandlungskünstler
Die Verwaltung mehrerer Ruby-Interpreter und ‐Versionen sowie Gem-Sets zeitgleich auf demselben Rechner
wird mit »rvm« fast zum Kinderspiel Caspar Clemens Mierau
Seit einigen Jahren hat sich Ruby durch
den Erfolg von Rails neben anderen
Skriptsprachen wie PHP, Perl und Python
einen festen Platz in Webhosting-Stacks
gesichert. Wo allerdings mehrere Ruby-
Versionen gleichzeitig genutzt werden,
ergeben sich schnell Probleme.
Zudem wird die Auswahl an möglichen
Ruby-Interpretern und ‐Versionen zunehmend
unübersichtlich. Der klassische
Ruby Interpreter – oft nach seinem Haupt-
Entwickler „Matz’s Ruby Interpreter“
oder kurz MRI [2] genannt – wird durch
Änderungen, die die Rückwärtskompatibilität
brechen, derzeit im 1.8er und 1.9er
Branch gepflegt. Projekte, die auf Ruby
1.8 setzen, nutzen für den Live-Betrieb
nicht selten die um einen verbesserten
Garbage Collector erweiterte Ruby Enterprise
Edition (REE)[3]. Java-nahe und
Performance-kritische Projekte setzen mit
JRuby [4] eine Ruby-Implementation in
Java ein, um etwa in einem Rails-Projekt
von Java-Bindings zu profitieren.
Zugleich gibt es mit Rubygems [5] einen
De-facto-Standard für Erweiterungen,
vergleichbar zu Perl CPAN, PHP Pear
und Python Eggs. Gems werden über ein
eigenes Paketmanagement verwaltet, was
die Arbeit zwar zunächst vereinfacht, bei
mehreren Projekten mit verschiedenen
Gem-Abhängigkeiten aber schnell unübersichtlich
werden kann. Einen Ausweg
aus der komplexen Verschränkung
von Ruby-Interpretern und ‐Versionen
sowie Gems bietet »rvm« [1] mit der Möglichkeit,
projektbasierte Umgebungen zu
pflegen.
Elnur Amikishiyev, 123RF
Die Standard-Installation von »rvm« gestaltet
sich einfach, wenn auch für Administratoren
eher ungewohnt. Wie in der
Ruby-/​Rails-Welt nicht selten, wird das
Installationsskript direkt aus dem Netz
ausgeführt. Zuvor müssen lediglich Git
und Curl installiert sein. Unter Debian/​
Ubuntu wird das System mit »apt‐get
install curl git‐core« für die Installation
von »rvm« vorbereitet.
Installation
Folgt man der offiziellen Quick Installation
Methode [6], ruft man in einem
Shellfenster direkt ein Skript aus dem
Netz auf: »bash <

Ruby Environment Manager
Programmieren
Daten, kommt vollständig ohne Root-
Rechte aus und ist gegebenenfalls per
»rm ‐rf ~/.rvm« wieder zu entfernen.
Systemweite Installation
Sollen mehrere Benutzer auf RVM zugreifen
können, empfiehlt sich die systemweite
Installation, die wie die benutzerspezifische
Installation gestartet wird,
jedoch per »sudo« oder direkt als Root.
Das Installationsskript erkennt dann,
dass es über die Rechte zur systemweiten
Installation verfügt, und führt sie aus.
EVM wird in »/usr/local/rvm« installiert,
der Befehl »rvm« in »/usr/local/bin/rvm«
per Symlink eingebunden, der Bootstrapper
für Bash und Zsh in »/etc/profile.d/
rvm.sh« abgelegt und die Gruppe »rvm«
gespeichert. Benutzer, die mit »rvm«
arbeiten sollen, müssen Mitglied dieser
Gruppe sein. Die Installationslogik von
RVM hat sich im Laufe des Projekts mehrfach
geändert – je nach Version kann es
zu Abweichungen bei den verwendeten
Pfaden kommen.
Nach einem erneuten Login des Users
zum Auslesen der geänderten Gruppenrechte
und des Bootstrappers steht der
Befehl »rvm« in der Konsole zur Verfügung.
Der Bootstrapper in »/etc/profile«
wird in der Regel von Login-Shells automatisch
ausgeführt, eine manuelle Erweiterung
wie bei der benutzerspezifischen
Installation ist also nicht notwendig.
Erste Schritte
»rvm help« und »man rvm« geben einen
Überblick über die generelle Benutzung.
Je nach gewünschter Ruby-Installation
müssen eventuell noch Abhängigkeiten
erfüllt werden. »rvm requirements«
zeigt je nach Distribution eine Liste mit
Abbildung 2: Die Ausgabe des Kommandos »rvm info« nach dem Wechsel in eine
installierte Version 1.9.2 des MRI.
Besonders hilfreich ist RVM im Umgang
mit Rubygems. Während es mit noch
vertretbarem Aufwand möglich ist, mehrere
Ruby-Versionen nebeneinander zu
betreiben, sprengt spätestens der Umden
erforderlichen
Abhängigkeiten
je Ruby-Version
und deren Auflösung
mit dem jeweils
spezifischen
Paketmanager.
Die »aptget«-Aufrufe
zur Vorbereitung
von klassischen
Ruby- und
etwas exotischeren
JRuby-Installatio
nen zeigt entsprechend
Abbildung
1.
Die Installation
von Ruby-Interpretern
gestaltet
sich nach Erfüllen
der Abhängigkeiten
einfach: »rvm
install ruby‐1.9.2«
installiert den
klassischen Ruby-
Interpreter im aktuellsten
stabilen Patchlevel der Version
1.9.2. Dabei werden die Quellen heruntergeladen
und auf dem Zielsystem kompiliert.
RVM warnt, wenn dazu nötige
Pakete fehlen und gibt die zur Installation
nötigen Kommandos aus, spezifisch nach
Betriebssystem oder Linux-Distribution.
Konfigurationsparameter des eigentlichen
Configure-Skripts können direkt übergeben
werden, etwa »rvm install 1.9.2
‐‐without‐readline«. Auch JRuby und andere
Ruby-Interpreter werden auf diese
Weise installiert, etwa »jruby‐1.6.3« oder
»ree‐1.8.7«. Eine Liste aller über »rvm«
installierbaren Ruby-Derivate und ‐Versionen
erhält man über »rvm list known«.
Hier wird ersichtlich, dass neben der genauen
Angabe eines Patchlevels (wie in
»ruby‐1.8.7‐p352«)
auch die jeweils
aktuellste Version
(»‐head«) oder ein
bestimmter Release-Status
(zum
Beispiel »‐rc1«)
gewählt werden
kann. Beim klassischen
Ruby-Interpreter
kann der
Name weggelassen
werden, sodass
Abbildung 1: Auflistung der Abhängigkeiten per »rvm requirements« zur
Installation verschiedener Ruby-Interpreter auf einem Ubuntu.
auch »rvm install 1.9.2« funktioniert.
Nach erfolgreicher Installation wechselt
man per »rvm use« die Ruby-Umgebung.
»rvm use 1.9.2« führt in die soeben installierte
Version. Die vom System bereitgestellte
Version kann jederzeit per »rvm
use system« wieder aktiviert werden. Der
Wechsel in eine spezifische RVM-Version
ist immer sitzungsspezifisch. Es ist also
problemlos möglich, in zwei verschiedenen
Terminalfenstern zugleich zwei
völlig verschiedene Ruby-Versionen zu
nutzen. Eine genaue Auskunft über die
aktuell verwendete Version erhält man
mit »rvm info«. Abbildung 2 zeigt die
Ausgabe nach dem Wechsel in die installierte
Version 1.9.2. Hier wird auch deutlich,
wie RVM arbeitet: Die Veränderung
der PATH- und weiterer Umgebungsvariablen
ermöglichen den bequemen Wechsel
in andere Umgebungen, ohne auf dem
Dateisystem Änderungen durchführen zu
müssen.
Gem-Sets
www.admin-magazin.de
Admin
Ausgabe 06-2011
127

Programmieren
Ruby Environment Manager
Fortgeschrittene Ruby-Anwender und
‐Entwickler finden auf der RVM-Webseite
eine Zusammenstellung von Best
Practices und problemspezifischen Lögang
mit verschiedenen Gem-Sets den
Rahmen. Unter einem Gem-Set versteht
man eine spezifische Zusammenstellung
von Gems. Rubygems selbst unterstützt
den parallelen Betrieb mehrerer Versionen
desselben Gems. Rails, das selbst
ein Gem ist, kann theoretisch also nebst
seiner Abhängigkeiten in verschiedenen
Versionen installiert sein. Innerhalb von
Ruby lassen sich dann spezifische Gems
laden. Leider sind Programme jedoch oft
fehlerhaft und laden zum Beispiel immer
die neueste statt einer spezifischen
Version eines Gems, was nicht selten zu
Kompatibilitätsproblemen führt.
Hilfreich ist hier der Ansatz, Gems nicht
mehr beliebig zu installieren, sondern
pro Projekt zu pflegen, um nur die benötigten
Gems vorzuhalten. RVM bietet
hierfür Gem-Sets als Container für spezifische
Zusammenstellungen von Gems
an. »rvm gemset create projekt1« erstellt
ein Gemset »projekt1« in der aktuellen
Umgebung. Nun kann man mit »rvm use
1.9.2@projekt1« in das Gem-Set wechseln.
Alle per »gem install« installierten Gems
werden nur innerhalb dieses Gem-Sets
dieser Ruby-Version ausgerollt. Schneller
kann man per »rvm use 1.9.2@projekt2
‐‐create« gleichzeitig ein Gem-Set erstellen
und hineinwechseln. Benötigt man direkten
Zugriff auf das Gem-Verzeichnis, lässt
man sich den Pfad über »rvm info« oder
»echo $GEM_HOME« anzeigen.
Listing 2: Die wichtigsten RVM-Befehle
01 # zeige benötigte Abhängigkeiten
02 rvm requirements
03 # zeige installierte Interpreter
04 rvm list
05 # Installiere Interpreter
06 rvm install Interpreter_version
07 # zeige aktuelle RVM‐Umgebung
08 rvm info
09 # wechsle Umgebung
10 rvm use Interpreter_version/default/system
11 # aktualisiere RVM
12 rvm get latest/head/VERSION
13 # Entferne Interpreter
14 rvm remove Interpreter_version
15 # zeige Release‐Notes
16 rvm notes
Listing 1: »~/​.rvm/​gemsets/​global.gems«
01 LISTING Default Gem‐Set
02 bundler ‐v~>1.0.0
03 awesome_print
04 shoutbox_client
Über Gem-Sets lassen sich nicht nur Projekte
klar voneinander trennen, sondern
auch neue Gemversionen problemlos testen.
Mit »rvm gemset copy 1.9.2@projekt1
1.9.2@projekt2« werden komplette
Gem-Sets kopiert. Dies ist auch zwischen
verschiedenen Ruby-Versionen möglich.
Ebenso können mit »rvm gemset export/
import« Gem-Sets in einer ».gems«-Datei
gesichert oder aus dieser importiert
werden. Wer auch bei neu angelegten
Gem-Sets immer wieder dieselben Gems
benötigt, kann in »~/.rvm/gemsets/
global.gems« eine Liste von Standard-
Gems pflegen. Sie werden bei Erstellen
neuer Gem-Sets automatisch ausgerollt.
Listing 1 zeigt ein Beispiel.
Konfiguration
RVM wird über »~/.rvmrc« bzw »/etc/
rvmrc« konfiguriert. Die Konfiguration
ist optional, ermöglicht aber das Setzen
spezifischer Compiler-Flags und Pfadangaben.
Eine Liste möglicher Optionen liefert
die Datei »~/.rvm/examples/rvmrc«.
Interessanter ist der Einsatz projektspezifischer
».rvmrc«-Konfigurationen. Der
eingangs erwähnte RVM-Bootstrapper für
Bash und Zsh lädt nicht nur »rvm«, sondern
prüft bei jedem Verzeichniswechsel,
ob im aktuellen Verzeichnis eine
».rvmrc«-Datei vorhanden ist und bietet
nach einmaliger Prüfung an, diese automatisch
zu laden.
Die entsprechende Datei ».rvmrc« kann
bereits bei Erstellung eines Gem-Sets
automatisch im aktuellen Ordner geschrieben
werden: »rvm ‐‐rvmrc ‐‐create
1.9.2@projekt3«. Beim ersten Wechsel
in das Verzeichnis muss einmalig die
Vertrauenswürdigkeit der Datei bestätigt
werden. Danach löst jeder Wechsel in das
Verzeichnis einen automatischen Wechsel
in die entsprechende Ruby-Version
und das Gem-Set aus. Für Entwickler
ergibt sich so eine einfache Möglichkeit,
durch eine gemeinsam bearbeitete
».rvmrc« Ruby-Version den Namen des
Gem-Sets für alle am Projekt Beteiligten
bekanntzumachen. Neue Entwickler erhalten
automatisch die richtige Version.
Einziger Nachteil ist, dass nur Gem-Sets
automatisch erstellt werden – eventuell
nicht vorhandene Ruby-Versionen müssen
einmalig per »rvm install« nachinstalliert
werden.
Letztlich handelt es sich bei der ».rvmrc«
nur um ein Bash-Skript. Ein Blick in die
automatisch erstellte Datei zeigt, dass
hier mit Umgebungsvariablen und Shell-
Logik gearbeitet wird. Es bietet sich also
an, innerhalb der ».rvmrc« weitere Umgebungsvariablen
zu setzen oder das
RVM-Bootstrapping weiter ans Projekt
anzupassen, um zum Beispiel die Verwendung
von 32- oder 64-Bit-Versionen
eines Ruby-Interpreters sicherzustellen.
Integration und Skripting
Benutzt man auf Ruby und Rubygems
aufbauende Dienste wie Passenger, ist
der Einsatz von RVM teils nicht ganz
trivial [7]. Je nach verwendeter Software
muss geprüft werden, wie RVM eingebunden
werden kann. Hilfreich ist oft
die Verwendung absoluter Pfadangaben
zu Ruby-Interpretern. Für jede Ruby-
Version legt RVM symbolische Links an,
die direkt aufrufbar sind. »rvm info« zeigt
die entsprechenden Pfadangaben. Auch,
wenn Pfadangaben wie »/home/ccm/.
rvm/rubies/ruby‐1.9.2‐p290/bin/ruby«
ungewohnt aussehen, verweisen sie auf
eine vollständige Ruby-Installation.
Das Laden von Gem-Sets wird je nach
Dienst über Umgebungsvariablen, Start-
Skripte oder weitere Bootstrapper geregelt.
Für Passenger und Rails3 kann zum
Beispiel eine Datei »config/setup_load_
paths.rb« im Rails-Projekt die entsprechenden
Pfade setzen.
Für den täglichen Einsatz von RVM gibt
es weitere hilfreiche Skripte. Soll ein Befehl
per »sudo« unter Beibehalten der
aktuellen RVM-Umgebung ausgeführt
werden, kann »rvmsudo« als Wrapper
genutzt werden. Für den Einsatz in Shellskripten
bietet »rvm‐shell« als RVM-Bash-
Wrapper die Möglichkeit, auch für nichtinteraktive
Sitzungen den Einsatz von
».rvmrc«-Dateien zu ermöglichen. Für
Cronjobs bietet sich zum Beispiel an, die
Variable »SHELL« auf die entsprechende
RVM-Shell zu setzen, sodass Skripte korrekt
ausgeführt werden.
Ausblick
128 Ausgabe 06-2011 Admin www.admin-magazin.de

Ruby Environment Manager
Programmieren
sungsansätzen [8]. Die Interaktion mit
dem Gem-Bundler wird ebenso diskutiert
wie die Einbindung in Entwicklungsumgebungen,
der Einsatz in Continuous
Integration Systemen wie Hudson und
Auto-Completion in Zsh/​Bash.
Ubuntu Oneiric Ocelot (11.10) liefert
als eine der ersten Linux-Distributionen
RVM selbst als Paket aus [9]. Inwieweit
sich der untypische Ansatz von RVM
und das Paketmanagement vertragen,
wird sich erst zeigen müssen. Obwohl
die Auslieferung von RVM als Paket dem
Nutzer die erste Hürde der ungewohnten
Installation nimmt, muss er dafür aber
auf die Verbesserungen der sehr kurzen
RVM-Entwicklungszyklen verzichten.
In automatisierten Server-Landschaften
lässt sich RVM bequem per Puppet ausrollen
und verwalten. Entsprechende
Puppet-Module finden sich auf Github
[10]. Experimentierfreudige können
RVM zum Anlass nehmen, sich mit dem
Scripting Management Framework (SM)
auseinanderzusetzen [11]. Das auch
BDSM genannte System ist ein Skripting-
Framework zur Automatisierung von Servern,
welches weitestgehend die RVM-
Entwickler pflegen.
RVM ist ein komplexer Meta-Paketmanager
für Ruby-Interpreter und Gem-Sets.
Die Implementation in Bash-Skripten und
die geringen Abhängigkeiten von »curl«
und »git‐core« bieten eine vergleichsweise
schlanke, wenn auch komplexe Lösung.
»rvm« ist trotz einiger Schwierigkeiten in
der Handhabung der derzeit am weitesten
verbreitete Ansatz dieser Art in der Ruby-
Welt. Ob man nun am Distributions-Paketmanager
vorbeiinstallieren möchte oder
nicht: Einfacher lässt sich die Verwaltung
kaum übernehmen. (jcb)
n
Infos
[1] RVM: [https:// rvm. beginrescueend. com]
[2] MRI:
[http:// en. wikipedia. org/ wiki/ Ruby_MRI]
[3] Ruby Enterprise Edition:
[http:// www. rubyenterpriseedition. com]
[4] JRuby: [http:// jruby. org]
[5] Ruby Gems: [http:// rubygems. org]
[6] Installations-Möglichkeiten: [https:// rvm.​
beginrescueend. com/ rvm/ install]
[7] Passenger: [http:// beginrescueend. com/​
integration/ passenger]
[8] RVM-Integration:
[http:// beginrescueend. com/ integration]
[9] RVM-Packages für Ubuntu:
[http:// packages. ubuntu. com/ oneiric/​
ruby‐rvm]
[10] RVM und Puppet:
[https:// github. com/ blt04/ puppet‐rvm]
[11] BSDM-Projekt:
[https:// sm. beginrescueend. com]
Der Autor:
Caspar Clemens Mierau ist Medien-Kulturwissenschaftler,
arbeitet an seiner Dissertation
über Entwicklungsumgebungen und berät mit
seinem Projekt Screenage Firmen wie moviepilot.de,
artfacts.net und aperto.de.
Die Linux New Media AG ist das weltweit größte Medienunternehmen rund um Linux und Open Source. Der Verlag produziert eine umfangreiche Reihe an Monatsund
Sonderpublikationen zum Thema Linux, Open Source, Android, und anderen IT-Themen. Zielgruppenorientierte Onlineangebote kennzeichnen einen wichtigen Teil
der Zukunftsstrategie des Unternehmens. Die Linux New Media AG agiert international, ihre Print- und Online-Publikationen erscheinen in fünf Sprachen weltweit.
Wir suchen für die Weiterentwicklung unseres Online-Geschäfts zum nächstmöglichen Zeitpunkt eine/n
Webentwickler (m/w) in Vollzeit
Ihre Aufgaben:
• Weiterentwicklung der bestehenden und Umsetzung neuer Websites unter Einbringung eigener Ideen und Vorschläge.
• Support des Teams bei der Arbeit mit eZ Publish und Magento.
• Unterstützung des Anzeigenteams bei der Verwaltung und Planung von Eigen- und Kundenkampagnen in OpenX
Ihr Profil:
• Gute Kenntnisse in PHP, objektorientierter Programmierung sowie Webservices
• Sie verfügen über Kenntnisse in einem oder mehreren der folgenden Bereiche:
- Programmierung von Templates und Erweiterungen für das CMS eZ Publish,
oder die Bereitschaft sich kurzfristig und weitgehend selbständig darin einzuarbeiten. Erfahrungen
mit der Smarty Template Engine erleichtern den Einstieg.
- Entwicklung von Designs und Plug-Ins für Magento
- Kenntnisse in XML und XSLT
• Erfahrungen mit anderen PHP-basierten Content Management Systemen sind von Vorteil
• Versierter Umgang mit MySQL
• HTML-, CSS-, JavaScript-Entwicklung unter Berücksichtigung der Kompatibilität mit den wichtigen
Webbrowsern
• Versierter Umgang mit Subversion und anderen Versionskontrollsystemen sowie mit Bugtracking-
Systemen
• Von Vorteil sind Kenntnisse weiterer Webtechnologien wie Rails, Zope, Perl oder Java.
• Englischkenntnisse in Wort und Schrift werden vorausgesetzt
Ihr Arbeitsplatz ist am Verlagsstandort in München
Können Sie sich dafür begeistern, kreative
Lösungen zu suchen und im Kontakt mit einem
jungen, dynamischen Team etwas Neues
aufzubauen?
Wenn ja, bewerben Sie sich mit Beispielen
Ihrer bisherigen Tätigkeit im Bereich
Webentwicklung und Ihren Gehaltsvorstellungen
bei:
Linux New Media AG
Frau Liane Ganguin
Putzbrunner Str. 71
81739 München
Tel.: 089 / 99 34 11 -00
E-Mail: bewerbung-web@linuxnewmedia.de
Mehr Infos unter:
www.linux-magazin.de/Webentwickler

Service
Impressum und Vorschau
Impressum ISSN 2190-1066
ADMIN-Magazin
eine Publikation der Linux New Media AG
Redaktionsanschrift Putzbrunner Straße 71
81739 München
Tel.: 0 89/99 34 11-0
Fax: 0 89/99 34 11-99 oder -96
Internet
www.admin-magazin.de
E-Mail
redaktion@admin-magazin.de
Geschäftsleitung
Chefredakteure
Redaktion
News/Report
Software/Test
Security/Networking
Ständige Mitarbeiter
Produktionsleitung
Grafik
Abo-Infoseite
Abonnenten-Service
Brian Osborn (Vorstand), bosborn@linuxnewmedia.de
Hermann Plank (Vorstand), hplank@linuxnewmedia.de
Oliver Frommel (V.i.S.d.P.),
ofrommel@admin-magazin.de (ofr)
Jens-Christoph Brendel
jbrendel@admin-magazin.de (jcb)
Ulrich Bantle (Ltg.), ubantle@linuxnewmedia.de (uba)
Mathias Huber, mhuber@linuxnewmedia.de (mhu)
Marcel Hilzinger, mhilzinger@linuxnewmedia.de, (mhi)
Kristian Kißling, kkissling@linuxnewmedia.de, (kki)
Markus Feilner, mfeilner@linuxnewmedia.de (mfe)
Thomas Leichtenstern, tleichtenstern@linuxnewmedia.de (tle)
Elke Knitter (Schlussredaktion),
Carsten Schnober, Tim Schürmann, Claudia Thalgott
Christian Ullrich, cullrich@linuxnewmedia.de
Kristina Fleischer, Judith Erb
Titel: Judith Erb, Bildmaterial: mipan, 123RF
www.admin-magazin.de/abo
Lea-Maria Schmitt
abo@admin-magazin.de
Tel.: 07131/27 07 274, Fax: 07131/27 07 78 601
Preise Print Deutschland Österreich Schweiz Ausland EU
Einzelheft € 9,80 € 10,80 Sfr 19,60 (siehe Titel)
Mini-Abo (2 Ausgaben) € 9,80 € 10,80 Sfr 19,60 (siehe Titel)
Jahres-DVD (Einzelpreis) € 14,95 € 14,95 Sfr 18,90 € 14,95
Jahres-DVD (zum Abo 1 ) € 6,70 € 6,70 Sfr 8,50 € 6,70
Jahresabo € 49,90 € 54,90 Sfr 99,90 € 59,90
Preise Digital Deutschland Österreich Schweiz Ausland EU
Heft-PDF Einzelausgabe € 9,80 € 9,80 Sfr 10,71 € 9,80
DigiSub (6 Ausgaben) € 44,90 € 44,90 Sfr 49,05 € 44,90
DigiSub (zum Printabo) € 6,— € 6,— sfr 6,— € 6,—
HTML-Archiv (zum Abo 1 ) € 48,— € 48,— sfr 48,— € 48,—
Preise Kombiabos
Profi-Abo 2 € 136,60 € 151,70 Sfr 259,90 € 165,70
1
nur erhältlich in Verbindung mit einem Jahresabo Print oder Digital
2
mit Linux-Magazin-Abo und beiden Jahres-DVDs
Schüler- und Studentenermäßigung: 20 Prozent gegen Vorlage eines Schülerausweises oder einer aktuellen
Immatrikulationsbescheinigung. Der aktuelle Nachweis ist bei Verlängerung neu zu erbringen. Andere Abo-
Formen, Ermäßigungen im Ausland etc. auf Anfrage.
Adressänderungen bitte umgehend mitteilen, da Nachsendeaufträge bei der Post nicht für Zeitschriften gelten.
Pressemitteilungen info@admin-magazin.de
Anzeigen/Repräsentanz
Es gilt die Anzeigenpreisliste vom 01.01.2010
National
Petra Jaser
Tel.: 089/99 34 11 24, Fax: 089/99 34 11 99
E-Mail: anzeigen@admin-magazin.de
Pressevertrieb MZV, Moderner Zeitschriften Vertrieb GmbH
Breslauer Straße 5, 85386 Eching
Tel.: 089/31906-0, Fax: 089/31906-113
Druck
Vogel Druck und Medienservice GmbH
97204 Höchberg
Der Begriff Unix wird in dieser Schreibweise als generelle Bezeichnung für die Unix-ähnlichen Betriebssysteme
verschiedener Hersteller, zum Beispiel Eurix (Comfood), Ultrix (Digital Equipment), HP/UX (Hewlett-Packard) oder Sinix
(Siemens) benutzt, nicht als die Bezeichnung für das Trademark von X/Open. Linux ist eingetragenes Marken zeichen von
Linus Torvalds und wird in unserem Markennamen mit seiner Erlaubnis verwendet. Alle anderen Marken sind Eigentum
der jeweiligen Inhaber. Eine Haftung für die Richtigkeit von Veröffentlichungen kann trotz sorgfältiger Prüfung durch
die Redaktion vom Verlag nicht übernommen werden. Mit der Einsendung von Manu s kripten gibt der Verfasser seine
Zustimmung zum Abdruck im Admin-Magazin. Für unverlangt ein gesandte Manuskripte kann keine Haftung übernommen
werden. Die Redaktion behält sich vor, Artikel zu kürzen. Das Exklusiv- und Verfügungsrecht für angenommene
Manuskripte liegt beim Verlag. Es darf kein Teil des Inhalts ohne ausdrückliche schriftliche Genehmigung des Verlags in
irgendeiner Form vervielfältigt oder verbreitet werden. Copyright © 1994–2011 Linux New Media AG
Inserentenverzeichnis
1&1 Internet AG http://​www.einsundeins.de 14
ADMIN http://​www.admin-magazin.de 93
Android User GY http://www.android-user.de 125
Fernschule Weber GmbH http://​www.fernschule-weber.de 91
Galileo Press http://​www.galileo-press.de 31
German Unix User Group (GUUG) e.V. http://​www.guug.de​ 83
Hetzner Online AG http://​www.hetzner.de 2
Hostserver GmbH http://​www.hostserver.de 132
In-Depth Security Conference ​https://​deepsec.net 35
Kamp Netzwerkdienste GmbH http://​www.kamp.net 23
Linux New Media AG http://​www.linuxnewmedia.de 129
Linux-Hotel http://​www.linuxhotel.de 13
Linux-Magazin http://​www.linux-magazin.de 131
Linux-Magazin Academy http://​academy.linux-magazin.de 107, 117
Linux-Magazin Online http://​www.linux-magazin.de 115
Netclusive GmbH http://​www.netclusive.de 9
NETHINKS GmbH http://​www.nethinks.com 59
outbox AG http://​www.outbox.de 57
OVH GmbH http://​www.ovh.de 7
pascom GmbH & Co.KG http://​www.pascom.net 11
Pluspol GmbH http://​www.pluspol.de 61
PlusServer AG http://​www.plusserver.de 20, 32, 46, 100
Spenneberg Training & Consulting http://​www.spenneberg.com 53
Stern & Schatz GmbH http://​www.getdigital.de 25
Thomas Krenn AG http://​www.thomas-krenn.com 17
Vogel IT-Medien GmbH http://​www.vogel.de​ 45
Vollmar.net http://​www.vollmar.net 27
Einem Teil dieser Ausgabe liegt eine Beilage der Firma OVH GmbH (http://​www.ovh.de​)
bei. Wir bitten unsere Leser um freundliche Beachtung.
Autoren dieser Ausgabe
Alex Davies Auf der Liste 34
Thomas Drilling Fundament für Teamarbeit 94
Thomas Drilling Rettungsinsel 62
Prof. Dr. Stefan Edlich NoSQL 48
Werner Fischer Hirnforschung 114
Dr. Neil Gunther Berechenbare Performance 72
Thomas Joos Flusskontrolle 28
Thomas Joos Gekachelt 58
Thomas Joos Stellschraube 118
Eva-Katharina Kunst Eingedost 68
Martin Loschwitz Aus der Werkstatt 102
Martin Loschwitz Die Speicherwolke 84
Hans-Peter Merkel Table Dance 109
Caspar Clemens Mierau Der Verwandlungskünstler 126
Alessandro Osaria Auf der Liste 34
Jürgen Quade Eingedost 68
Thorsten Scherf Aufzucht 18
Kurt Seifried Weitgehend heiter? 70
Ralf Spenneberg Wie viel darf’s denn sein? 90
VORSCHAU
norebbo, 123RF
ADMIN 01/2012 erscheint am 12. JANUAR 2012
Monitoring
Die eigene Systemlandschaft zu
überwachen hilft dabei, Probleme
frühzeitig zu erkennen. Die kommende
ADMIN-Ausgabe gibt einen Überblick
über Monitoring-Software und verrät,
worin sich die zahlreichen Nagios-Forks
unterscheiden.
BSD-Firewall
Ein Blick über den Tellerrand
schadet nicht. Und so nehmen
wir im kommenden Heft die
auf FreeBSD basierende Firewall
pfSense unter die Lupe,
die mit Features wie Hochverfügbarkeit
beeindruckt.
Yuri Arcurs, Fotolia
130 Ausgabe 06-2011 Admin www.admin-magazin.de

JETZT
MiT dVd!
MAGAZIN
SondErAkTion
Testen Sie jetzt
3 Ausgaben
für 3 Euro!
Jetzt schnell bestellen:
• Telefon 07131 / 2707 274
• Fax 07131 / 2707 78 601
• E-Mail: abo@linux-magazin.de
• Web: www.linux-magazin.de/probeabo
Mit großem Gewinnspiel unter:
www.linux-magazin.de/probeabo
GEwinnEn SiE... EinE Von fünf rEwind Mini hd
kAMErAS iM GESAMTwErT Von fAST 400 Euro!
Einsendeschluss ist der 15.12.2011
zur Verfügung gestellt von
.de

Managed
Hosting
sicher, flexibel und
verfügbar
Profitieren Sie von:
aktueller Clustertechnologie
ISO 27001 zertifiziertem
Hochsicherheits-Datacenter
Hosting direkt am DE-CIX
IPv4 und IPv6 Anbindung
24/7 Service und Support
Entdecken Sie den Unterschied
Professionelles Hosting mit persönlichem
und kompetentem Support.
Individuelle Hostinglösungen vom Server
bis zum Clustersystem. Beratung, Planung
und Service 24/7.
Wir bieten über 10 Jahre Erfahrung in
Hosting und Systemadministration.
Für mehr Performance, Sicherheit und
Verfügbarkeit, jeden Tag, rund um die Uhr.
hostserver.de/hosting
0 30 / 420 200 24 hostserver.de
Berlin Marburg Frankfurt am Main