SRI

Datei:SRI-mini.jpg noch kein Bild
Projektstart	2011/05/06
Projektleiter	philipp.strobl
Betreuer	philippe.kaeufer
Status	Alpha
Projektname	SRI
Bildbeschribung	noch kein Bild

Idee

Das Thema "Cloud" ist momentan in aller Munde. Eine anonyme Wolke, ist aber nicht das Ziel dieses Projekts, sondern eine skalierbare Ressourcen-Infrastruktur (SRI) für die Vereinsaktivitäten, die zusätzlich die Möglichkeit beinhalten soll, Virtuelle Maschinen aus der eigenen Cloud in andere (externe) Clouds zu migrieren (hybride Clouds).

Datei:Projektaushang-SRI.pdf

Grundlagen

Cloud: Cloud Computing: Principles, Systems and Applications Von Lee Gillam

Cloud Typen: SaaS, PaaS, IaaS, NaaS

CPU und Virtualisierungs-Erweiterung:

Virtualisierung Allgemein

x86 Virtualisierung

Vergleich verschiedener Virtualisierungen

Intel-CPUs

AMD-CPUs

Skalierbarkeit

Die Skalierbarkeit ist vor allem dann wichtig, wenn zu Beginn (beim Einrichten des Servers) nicht klar ist, welche Reaktionszeiten, Ausfallsicherheit und Datenmengen benötigt werden. Durch die Trennung von Hardware und Anwendung mittels Virtualisierung kann dies erreicht werden.

Unabhängig vom Begriff "Cloud" und Outsourcing von IT-Funktionen, ist darauf hinzuweisen, dass Linux-Systeme (bzw. der Kernel) in Hinsicht auf Migration von unterschiedlicher Hardware recht flexibel sind, wenn Standard-Hardware (Treiber bzw. Module im Kernel enthalten) zum Einsatz kommt und bei Paravirtualisierung Kernel bzw. Bibliotheken mit einander kompatibel sind.

Durch die fortgeschrittenen Virtualisierungs-Lösungen kommt in diesem Zusammenhang auch die Frage nach der Isolierung von Anwendungen zum Tragen. Grundsätzlich kann größte Flexibilität und Skalierbarkeit durch eine maximale Granularität der Dienste erreicht werden. Dem stehen allerdings der steigende Administrationsaufwand und die schwächere Sicherheit, sowie der Overhead durch die Virtualisierung gegenüber.

Virtualisierungen

Grundsätzlich ist diese Seite ein guter Start: virt.kernelnewbies.org/TechComparison

Dazu ist aber noch dieser Artikel von zusätzlichem Nutzen: Squab

Virtualisierung	Kernel/Module	Für aktuellen stable Kernel vorhanden	Version Debian (testing Kernel 3.0)	libvirt-Unterstützung	live-Migration
KVM	Module	alle	OK	OK	OK
OpenVZ	Kernel	2.6.32	-- (entfernt)	OK	OK
Linux Vserver	Kernel	alle	-- (entfernt)	OK (mit patch)	unbekannt
LXC	Module	alle	OK	OK	nocht nicht

KVM und LXC als Module haben den Vorteil, dass dazu keine Anpassung des Kernels notwendig ist.

Jedoch geht damit auch der größte Nachteil einher, denn durch die Modularisierung geht auch die Performance gegenüber einem speziell angepassten Kernel zurück.

Obwohl nur OpenVZ nicht mit dem aktuellen Kernel Schritt hält, ist es im Moment eines der am besten ausgebauten Kernel-basierten Virtualisierungen.

Ressourcen Skalierung

Die Kernel-Funktion nennt sich "Cgroups". Diese wird unterstützt von

- KVM (http://libvirt.org/drvqemu.html)
- Linux VServer (http://linux-vserver.org/util-vserver:Cgroups)
- XEN (RAM: http://wiki.xen.org/wiki/XCP_FAQ_Dynamic_Memory_Control)
- LXC (http://lxc.sourceforge.net/man/lxc.html)

Schichtenmodell

Die Trennng der Infrastruktur in Schichten vereinfacht das Austauschen einzelner Teile und damit sowohl die Wartbarkeit als auch die Skalierbarkeit. Dafür sind wohldefinierte Schnitstellen zwischen den Schichten sinnvoll.

Ein vorläufiges Modell könnte so aussehen: Aktuell ist PILARKTO.ORG - Open Laboratory auf zwei Standorte verteilt. Daraus ergeben sich drei Bereiche, die sich in der Art der Zuverlässigkeit unterscheiden. Das Prinzip ist aber ohne Weiteres vervielfachbar. Production und Core ist nur durch vom Verein bestimmtes Fachpersonal zugänglich. Die dort ansässigen Dienste bilden die Basis der IT-Infrastruktur. Lab kann in Anlehung an Debian's "Unstable" als Versuchslabor verstanden werden.

Virtual Infrastructure Management

Name	Initiative/Sponsor	Status	VM Hypervisor	Cloud type	Service	Load balancing	Programmier Umgebung	Fault tolerance	Storage	Sicherheit	Bemerkungen
OpenECP	OpenECP Project	Fork der letzten Open Source Version von ECP	Xen, KVM	private, public	IaaS, Xen images	user-space: round-robin, random, hash, least resource	Ruby on rails, PHP, Python	Overflow, disaster und failover	S3, Nirvanix, CloudFS (MySQL)	Gruppen basiert
Eucalyptus	Eucalyptus Systems, Inc.	RC , v.2	Xen, KVM, VMware	private, public	IaaS	load balancing cloud controller	Hibernate, Axis2, Java	seperate Gruppen	Walrus - Frontend für Subsystem	WS-security Authentifikation, cloud controller public/private key
Nimbus	University of Chicago	RC, v.2	Xen	private, public	IaaS	virtuelle Cluster (z.B. context broker)	Python, Java	Prüft worker nodes periodisch und recover	Repository of Vm images pro Benutzer(GridFTP)	PKI, VMOS, PDP
Open Nebula	C12G Labs	RC, v.2	Xen, KVM, VMware	private, hybrid, public (EC2, Elastic Host)	IaaS	über Nginx	Java, Ruby	Recovert alle bei Daemon-Neustart, Persistent Datenbank (Host, VM)	Datenbank (persistent), SQLite3 (internal)	Firewall, virtual private network tunnel
Ganeti	google	RC, v.2	Xen, KVM, LXC	private	IaaS	h-tools	Python	Metadaten und Images	LVM, DRBD, Files	muß außerhalb von Ganeti umgesetzt werden
OpenQRM	OpenQRM Enterprise	RC, v.4	Xen, KVM, VMware, Amazon EC2	private, public	??	über openMosix oder andere SSI technology	Nagios überwacht, ?	N to 1" fail-over	Aoe/Coraid, LVM, NFS, iSCSI, NetApp, local	??
Openstack	Diverse	Diabolo	VMware, Hyper-V, KVM, Xen, Citrix, Qemu, UML	public, private	IaaS, NaaS (Nova), Image Service (Glance)	??	Python	??	Object Storage (Swift)	OpenStack Identity (Keystone) mit SQL, LDAP	Schnell entwickelndes Projekt, es bildet sich ein umfassendes Ökosystem mit diversen Unterprojekten
Archipel	??	Vesta Beta 4	libvirt	private	IaaS	??	Python, JavaScript	??	??	Jabber Server	Webfrontend für libvirt, Kommunikation mit libvirt läuft eventbasiert übers Jabber Protokol
lcmc	Rasto Levrinc	1.3.6 stable	alle die von pacemaker mit libvirt unterstützt werden: kvm, lxc, ??	private	IaaS	mit pacemaker Regeln	java	hot stand by mit automatischem fail over (HA)	LVM, DRBD, Files, ??	jeder kann alles	GUI für cluster mit pacemaker, libvirt und drbd
proxmox	Proxmox Server Solutions GmbH	2.0 stable	openvz, kvm	private	IaaS	??	javascript, ??	??	LVM, DRBD, Files	??	besitzt integriete Backuplösung

Zusätzliche Informationen über KVM Management Tools sind hier erhältlich.

Storage

Überblick

Es gibt verschieden Möglichkeiten die virtuellen Festplatten zu verwenden.
Einen Überblick kann dabei die Anbindungsmöglichkeiten von libvirtd bieten.

DRBD

Eine typischen Linux-Lösung bei HA ist DRBD. Leider kann DRBD nur im Falle von Failover eingesetzt werden, da es keine "Active-Active" Konfiguration erlaubt (http://www.drbd.org/users-guide/ch-fundamentals.html).
Damit könnten zwar Maschinen live von einem Storage-Server zum anderen Transferiert werden, aber zwei VMs können nicht auf den selben Datenbereich schreiben. Load Balancing ist damit nicht möglich.

LVM

Einrichtung von LVM CentOS/Howtoforge bzw. Debain/Howtogeek

Um das zu erreichen, gibt es einen ganze reihe Lösungen: Ein Vergleich MooseFS, Ceph, GlusterFS und noch ein paar mehr http://itp.tugraz.at/~ahi/admin/verteiltesDateisystem.html

Hadoop

Als Ausblick sei hier noch auf Hadoop verwiesen QuickStart oder Hadoop Wiki.

Ceph

Allgemeine Informationen gibt es hier: http://ceph.com/ceph-storage/

Konvertierung

Ein erstaunliche leichstes Vorhaben ist es, mit dem qemu-img z.B. ein Festplatten-Image zu einer LVM-Volume zu konvertieren. Howtoforge:KVM+LVM Howtogeek.

Performance

Ein Test mit einer Proxy-Installation (Squid und HAVP) brachte keinen Signifikanten Unterschied zwischen Festplatten-Image (qcow), Festplatten-Image (img/raw) und LVM-Volume zu tage, obwohl die Dateisystem-Ebene des Host-Systems durch die LVM-Ebene ersetzt wurde. Ein Download einer 5MB Datei dauert zwischen 7 und 9 Sekunden. Snapshots sind sowhl mit qcow-Images als auch mit LVM möglich. Ebenfalls sind Änderung der Größe im Nachhinein bei beiden möglich.

Eine Vergleich von Lokales Image zu CephFS Image auf einer Test-Installation mit Ceph im Rahmen von Pilot100 erbrachte.

Direktes Schreiben im Image auf das gemountete CephFS
dd if=/dev/zero of=/mnt/speedtest_pvsa bs=4k count=25000
 25000+0 Datensätze ein
 25000+0 Datensätze aus
 102400000 Bytes (102 MB) kopiert, 0,828817 s, 124 MB/s

Direktes Schreiben im Image auf einem RBD-Device. rbd-Gerät angegeben als /dev/rbd0 für Libvirtd
dd if=/dev/zero of=./speedtest_pvsa bs=4k count=25000
25000+0 Datensätze ein 
25000+0 Datensätze aus
102400000 Bytes (102 MB) kopiert, 3,28813 s, 31,1 MB/s

Zum Vergleich direkt auf einen SSD geschriebene Testfile
 dd if=/dev/zero of=./speedtest_pvsa bs=4k count=25000
 25000+0 Datensätze ein
 25000+0 Datensätze aus
 102400000 Bytes (102 MB) kopiert, 0,1678 s, 610 MB/s

Jeweils eine "dd" innerhalb der VM.

Lokales Image (.img) auf einer SSD
 dd if=/dev/zero of=./speedtest_pvsa bs=4k count=25000
 25000+0 Datensätze ein
 25000+0 Datensätze aus
 102400000 Bytes (102 MB) kopiert, 3,52757 s, 29,0 MB/s

Image auf einem gemounteten CephFS-Storage-Server
 dd if=/dev/zero of=./speedtest_pvsa bs=4k count=25000
 25000+0 Datensätze ein
 25000+0 Datensätze aus
 102400000 Bytes (102 MB) kopiert, 3,44572 s, 29,7 MB/s

Weiterführende Projekte

Pilot100 MiniZ