Treehuggin’ pussy

FreeBSD Snapshots in der Praxis

Thursday, February 24th, 2005 | Technik | No Comments

Vortrag von Dirk Meyer

FreeBSD bietet seit System 5 die Möglichkeit, ein Dateissystem mit Filesystem Snapshots zu sichern, die ein Weiterarbeiten des Benutzers während der Datensicherung ermöglicht

Voraussetzungen

• FreeBSD > 5
• Filesystem ufs ufs2

Einschränkungen

• 20 Snapshots pro Dateisystem
• Snapshots nicht veränderbar, nur als Ganzes zu löschen

Platzbedarf

• Original Datenbestand plus zusätzlich den veränderten Daten, als Reserve wird die Grösse des Dateisystems vorgeschlagen

Anwendungen

• Analyse: ein snapshot kann mit fsck auf Fehler untersucht werden, das Ganze kann auch im Hintergrund passieren, mit Background fsck
• Verzögertes Backup: Snapshots können zu beliebigen Zeiten erstellt werden, so dass Backups mit Tapewechseln auch zu zivilen Arbeitszeiten durchgeführt werden ohne den Einsatz eines Automatens zu erfordern.
• Als eigenes Dateisystems einhängen: Snapshots können über das Mounten desselben ausgelesen, die Rechteverwaltung bleibt dabei erhalten

Skripte

• Erzeugen und Aktivieren mittels snap.sh, dabei wird das gesicherte Verzeichnis gleich wieder eingehängt
• Entsorgen mittels unsnap.sh
• Wiederherstellen der Backups mit rc-snap.sh
• Sinnvoll automatisch ausgeführt, durchsucht das Filesystem nach Snapshots und hängt diese dann ein. So können User dann automatisch auf ältere Backups zugreifen.

Performance

• Das Erzeugen eines Snapshots geht recht schnell, z. B. 8 GByte brauchen ca. 30 Sekunden, davon sind Schreibzugriffe ca. 5 Sekunden gesperrt
• Das Entfernen dauert ca. 120 Sekungen, schreibende Prozesse werden nicht beeinflusst, beim Löschen grösserer Dateibäume werden Verzögerungen bemerkbar
• anderes Beispiel: 1,8 TB SATA, deaktivierter Schreibcache, Filesystem zu 77% gefüllt: Anlegen dauert 24 m, davon 2 Minuten gesperrt, Löschen 9 min

Fragen

• Mehrere Snapshots im Filesystem? Nein, da immer nur das gesamte Dateisystem gesichert wird, nicht einzelne Verzeichnisse

Dokumente

people.freebsd.org/~dinoex/batch/snapshots

Quality as defined by the Indian Standards Board

Thursday, February 24th, 2005 | Internet gucken, Treehuggin Posse, Universität | No Comments

Lars schreibt über seine Erfahrungen mit indischem Qualitätsmanagement.

Quality as defined by the Indian Standards Board

Ich bin nicht überrascht, wenn ich mir die Vorträge der Inder und Pakistani hier angucke. Irgendwo muss das ja her kommen.

Solaris 10

Thursday, February 24th, 2005 | Technik | No Comments

Vortrag von Daniel Jäschke

ziemlicher Werbevortrag, auch wenn der Vortragende versucht, nicht als Marketingmensch zu erscheinen.

Solaris 10 Release Cycle – Was ist neu

ca. alle 4 Jahre wird eine neues Release herausgebracht, Solaris 8 wird demnächst auslaufen. Insgesamt wird ein Release ca. 9 Jahre benutzbar sein.

Sun wird Solaris offenlegen, der Prozess begann (mit DTrace), allerdings müssen legale Probleme umschifft werden, Stichwort hier sind Softwarepatente, Unix-Patente
Solaris wird nicht mehr plattformspezifisch verkauft, sondern ein Solaris mit gleichen Features wird auf Sparc und x86 laufen, auch 64Bit Opteron wird unterstützt.
Neue Dinge in Solaris 10

Selfmanagement erkennt zukünftige Fehler und versucht die entsprechenden Geräte herauszunehmen
TCP/IP Stack hat einen enormen Performancesprung gemacht
Die Standardkonfiguration (Out of the box) ist viel performanter geworden

Dynamic Tracing

Dann ein paar Werbefolien, Solaris ist schneller als Linux, sagen die Folien. Das ist eine Überraschung.

Service Management Facility

• Keine Verbindung zwischen Services, Abhängigkeiten werden nicht beachtet
• Bootprozesse laufen schneller, da viele Prozesse parallel gestartet werden können
• Services werden aus der init.d und rc.d konvertiert, können aber auch herkömmlich gestartet werden.
• Hilfe gibt es auch über man smf

Solaris Container (Zones)

• Herkömmlcihe Auslastung ca. 20-30%, da eine Applikation pro Server
• Suns Lösung: Virtualisierung durch Domains (Partitions), denen jeweils einige Prozessoren zugeordnet werden. Diese können dynamisch gewechselt werden. Innerhalb einer Domain können Container definiert werden, die als unabhängige BS-Instanzen erscheinen, d. h. gebootet werden, als Root arbeiten usw. Daher können z.B. bestimmte Kunden nur 4 Prozessoren bekommen, für mehr müssten sie mehr zahlen
• Fair Share: Applikationen bekommen Prozessorleistungen zugesichert, überschüssige Prozessorlast wird nach Bedarf verteilt
• Virtuelle Maschinen vs. Container: Virtuelle Maschine: Virtualisierung im Betriebssystem oder darüber, jedes BS hat seinen eigenen Kernel mit entsprechendem Overhead. Solaris: Ein Kernel wird von allen Containern genutzt.
• Zone: Virtuelles BS
• Container: Zone plus Resource- Management
• Zonenbeispiel: Virtuelle Server werden sehr schnell gebootet, Zonen sind von innerhalb komplett unsichtbar, man kann nicht von einer Zone in die andere Wechseln.
• Rechtevergabe viel differenzierter
• Software Partitionierung
• Trusted Solaris

DTrace (Dynamic Tracing)

• “Jeden Morgen ist das System langsam” “Leistung verdopplet, Output steigt aber nur um 10%”
• Bisherige Methoden: mdb, truss, Veränderung der Binaries, alles recht unsicher und schlecht im Produktivsystem zu nutzen
• DTrace ist mit wenig Overhead im Produktiv zu nutzen
• DTrace besteht aus eine Scriptsprache D, die ähnlich perl ist und 40.000 Sensorpunkten
• Skripte können auf beliebige Punkte im BS zugreifen, z.B. /dev/null abfangen, Abfragen der System-ID abzufangen und zu ändern

ZFS

• Problem bei lokalen Dateisystemen: Kein umfassendes Konzept gegen Dateikorruption, viele Limits: Dateigrösse,
• ZFS hält immer ein konsistentes Dateisystem vor
• 128 Bit, daher absehbar kein Limit in der Dateigrösse
• Kleines Beispiel: 2 Platten, 3 Nutzer, Aufgabe: Plattenplatz hinzufügen, mit 4 Befehlen erzeugt, mit 1 Befehl werden zwei neue platten hinzugefügt

Fragen

• Quotas auf Verzeichnisebenen? Ja.
• Was fehlt: Es kommt noch eine graphische Oberfläche um Zonen zu erstellen
• Kernelpatches bei Zonen: Vorteil schnell eingespielt, Nachteil: man kann schlecht Testumgebungen erstellen, aber diese Möglichkeit kann über Domänen aufgebaut werden.
• Verzeichnisse können global oder lokal in der Zone erstellt werden, aber man kann von einer Zone keine andere Zone beeinflussen. Globale Dateien können kopiert oder Read-Only gemountet werden.

LiMux – Migration der Verwaltung Münchens zu Linux

Thursday, February 24th, 2005 | Technik | No Comments

Einige Notizen

Die Grundlagen

• 14.000 Rechner
• ca. 300 Anwendungen
• verschiedene Szenerien
• Linux und OpenOffice
• WinXP und OpenOffice
• zentrale Beschaffung und Strategie
• dezentraler Betrieb, z. B. Helpdesks

Beschluss

• Neue Entwicklungen möglichst nur noch als Webanwendungen

Kosten ca. 35 Millionen

• 38% Schulungen
• 18% Einführungen
• 15% Umstellung Makros
• 10% Anwendungsmigration

Vorstellung des Projekts den Mitarbeitern

• “Da kann man ja eine Maus benutzen”
• “Ich hab da eine Diskette mit einer Exceltabelle

Ziele Migration

• Durchführung ohne Gefährdung des Dienstbetriebs
• Lösungen sollten bevorzugt herstellerunabhängig und auch unabhängig vom BS und Office sein
• Migration der Fachverfahren auf webbasierte Lösungen oder native Linux-Anwendungen
• Konsolidierung und Migration der PC-Standard-Anwendungen
• Konsolidierung und Migration von MS-Office Makros, Formularen und Vorlagen
• Einführung von Systemmanagement-Lösungen

Rahmenbedingungen der Migration

• Umstellung möglichst durch eigenes Personal
• weiche Migration mit dezentraler Zuständigkeit
• unproblematische Bereiche zuerst

Erste Erkenntnisse der Migration

• Enormes Interesse an der Stellenausschreibung
• die beabsichtigte EU-Richtlinie erhöht das Risiko für den Einsatz von Open Source vermutlich nicht:
• Keine Trivialpatente
• technische Beitrag nötig
• Risiko beim Einsatz von Open Source und kommerzieller Software nahezu gleich

Begonnene Schritte

• Abschliessen der Ausschreibung des Basisclients
• Aufbau des Linux Client Teams
• Ausschreibungen für Schulungsmodule und Fachverfahren
• Entwicklung einer Office-Migration
• Beginn von Pilotprojekten
• Ende 2005 Beginn der Umstellung in den ersten Referaten, zunächst OpenOffice und Mozilla unter Windows,
• Architekturfestlegung für einheitliche Authentifizierung und Ressourcen (LDAP)
• Auswahl Softwareverteilung
• Projekte zur Anbindung von OpenOffice an bestehende Fachverfahren, BS2000 und SAP R/3 an OpenOffice
• Umstellung und Erneuerung von zentralen Applikationen
• Aufbau von weboptimierter Hardware (Bladeserver unter Linux)
• Anbindung von bestehenden File-und Printservices an den Linux-Desktop durch Samba, Novell Netware

Zukunft

• Austausch per PDF und Word97-Dateiformat, später XML
• SAP unterstützt auf ganzer Ebene die Migration
• Support wird bei 30-40 Leuten erwartet, diese Einsparungen machen die Lizensierungskosten zweitrangig
• München sieht sich als Eisbrecher, Beratungen in Wien und Paris, viele kleinere Gemeinden fragen an, der Basisclient wird nach Fertigstellung frei verfügbar