Du bist nicht berechtigt, die Seite zu bearbeiten. Grund:
Diese Aktion ist auf Benutzer beschränkt, die der Gruppe „Benutzer“ angehören.
Freitext:
[[Category:Projekte]] == 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). [[File:Projektaushang-SRI.pdf]] == Grundlagen == Cloud: [http://books.google.de/books?id=SbSbdkqibwIC&printsec=frontcover&dq=cloud+computing&hl=de&ei=bp_DTYTvBtCI4QbDyNiqBQ&sa=X&oi=book_result&ct=result&resnum=1&ved=0CGQQ6AEwADgK#v=onepage&q&f=false Cloud Computing: Principles, Systems and Applications Von Lee Gillam] Cloud Typen: [http://www.tecchannel.de/server/cloud_computing/2030180/cloud_computing_das_muessen_sie_wissen_saas_paas_iaas/ SaaS, PaaS, IaaS], [http://wiki.openstack.org/naas NaaS] CPU und Virtualisierungs-Erweiterung: [http://de.wikipedia.org/wiki/Virtualisierung_(Informatik) Virtualisierung Allgemein] [http://en.wikipedia.org/wiki/X86_virtualization#Intel_Virtualization_Technology_for_x86_.28Intel_VT-x.29 x86 Virtualisierung] [http://virt.kernelnewbies.org/TechComparison Vergleich verschiedener Virtualisierungen] [http://www.intel.com/products/desktop/processors/index.htm Intel-CPUs] [http://products.amd.com/en-us/desktopcpuresult.aspx?f1=&f2=&f3=&f4=&f5=&f6=&f7=&f8=&f9=&f10=&f11=&f12=True 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: [http://virt.kernelnewbies.org/TechComparison virt.kernelnewbies.org/TechComparison] Dazu ist aber noch dieser Artikel von zusätzlichem Nutzen: [[Squab]]<br> {| style="width: 778px; height: 156px;" border="1" cellspacing="1" cellpadding="1" |- | Virtualisierung<br> | Kernel/Module<br> | Für aktuellen stable Kernel vorhanden <br> | Version Debian (testing Kernel 3.0)<br> | libvirt-Unterstützung | live-Migration |- | KVM<br> | Module<br> | alle<br> | OK | OK | OK |- | OpenVZ<br> | Kernel<br> | 2.6.32<br> | -- (entfernt)<br> | OK | OK |- | Linux Vserver<br> | Kernel<br> | alle<br> | -- (entfernt)<br> | OK ([http://www.redhat.com/archives/libvir-list/2008-January/msg00097.html mit patch]) | [http://www.montanalinux.org/linux-vserver-interview.html unbekannt] |- | LXC | Module | alle | OK | OK | [http://lxc.sourceforge.net/man/lxc-checkpoint.html nocht nicht] |} <br> 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.[[Image:PORG - SRI - Schichten.png|center|700px|PORG - SRI - Schichten.png]]<br> == Virtual Infrastructure Management == {| class="wikitable sortable FCK__ShowTableBorders" |- ! 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 | <br> |- | 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 | <br> |- | 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 | <br> |- | 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 | <br> |- | Ganeti | google | RC, v.2 | Xen, KVM, LXC | private | IaaS | h-tools | Python<br> | Metadaten und Images<br> | LVM, DRBD, Files | muß außerhalb von Ganeti umgesetzt werden <br> | <br> |- | 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 | ?? | <br> |- | 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 |} <br> Zusätzliche Informationen über KVM Management Tools sind [http://www.linux-kvm.org/page/Management_Tools hier] erhältlich. == Storage == === Überblick === Es gibt verschieden Möglichkeiten die virtuellen Festplatten zu verwenden. <br> Einen Überblick kann dabei die [http://libvirt.org/storage.html Anbindungsmöglichkeiten von libvirtd] bieten. <br> ==== DRBD ==== Eine typischen Linux-Lösung bei HA ist [http://www.drbd.org/ 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). <br> 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 [http://www.howtoforge.com/linux_lvm_p6 CentOS/Howtoforge] bzw. [http://www.howtogeek.com/howto/40702/how-to-manage-and-use-lvm-logical-volume-management-in-ubuntu/ Debain/Howtogeek] <br> 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 [http://wiki.apache.org/hadoop/QuickStart QuickStart] oder [http://wiki.apache.org/hadoop/ 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. [http://www.howtoforge.com/virtualization-with-kvm-on-a-centos-6.2-server Howtoforge:KVM+LVM] [http://www.howtogeek.com/howto/40702/how-to-manage-and-use-lvm-logical-volume-management-in-ubuntu/ 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. <br> <br> Eine Vergleich von Lokales Image zu CephFS Image auf einer Test-Installation mit Ceph im Rahmen von [http://wiki.open-laboratory.de/Pilot100 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 == [http://wiki.open-laboratory.de/Pilot100 Pilot100] [http://wiki.open-laboratory.de/MiniZ MiniZ] [[Category:Projekte]]
Zusammenfassung:
Nur Kleinigkeiten wurden verändert Diese Seite beobachten
Abbrechen
