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]] == Allgemeines == Die Zahl 100 steht für 100% Verfügbarkeit. Man muss hierbei zwischen "failover" und "hochverfügbar" unterscheiden. Oft beinhaltet "hochverfügbar" auch Load Balancing. <br> Hochverfügbar werden aber nur wenige zentrale Services ausgestattet. Andere Systemen werden für Ausfall und Wartung auf failover ausgelegt. <br> Sinn ist es mit dem Pilot100 zu zeigen, was heute schon machbar ist und später eine weitere Instanz mit entsprechender Skalierbarkeit für "produktive Dienste" aufzusetzen. Wir beschränken uns auf die Relevanz der IT-Strategie des Open Laboratory e.V. Dies bezieht sich z.B. auf die Dienste des [http://wiki.open-laboratory.de/Squab Projekt Squab]. === Operating System === Im Zusammenhang mit Virtualisierung gibt es meist eine Referenz-Distribution die als Empfehlung für leichtes Setup mit Voll-Support aller Features steht. So wird für ein OpenStack bspw. Ubuntu preferiert, da die Entwicklung auf dieser Distribution stattfindet. Möchte man alledings alle Möglichkeiten ausreizen, empfiehlt es sich, Technologien und Software genauer zu betrachten und nach Möglichkeit einiges in Eigenverantwortlichkeit zu pflegen. Daher setzen wir als Erste-Wahl OS auf [http://gentoo.org gentoo] mit einem Overlay für eigene Anpassungen. Bei einer Source-Based Distribution ist es uns möglich: * Features in Software zu enablen oder zu disablen. * Patches einfach zu implementieren * Festhalten, was geändert wurde * anderen offenzulegen, wie man es machen kann, ohne jemandem intransparente Binaries vorzulegen. * Änderungen schnell einfließen zu lassen. Als Overlay kommt optional [https://github.com/cr-ver/falkland falkland] in Frage, da wir hier bereits einen gewissen Erfahrungsschatz aufgebaut haben. Desweiteren besteht bei einem gentoolinux die Möglichkeit, zusätzlich zu den "Build-Regeln" die Pakete bereits als Binary Packages vorzuhalten, ohne einen größeren Aufwand in Paketierung zu stecken. ==== Installiere OS ==== siehe HowTo: [[Intern:IT:HowTo:Gentoo_Install]] === Erfahrungswerte === Um ein paar Erfahrungswerte zu sammeln, wie sich z.B. CephFS verhält werden wir eine erste Demo-Plattform auf Basis von 2 Hypervisorn und einem Management Server aufsetzen. Folgende Hardware steht zur Verfügung: Hypervisor: dedizierter Server Intel i7-3770 32 GB Ram 2x2 TB Festplatten Management Server: virtuelle Maschine 2 vCPUs 1 GB Ram 1x50 GB Festplatte == Komponenten == Hier sprechen wir von folgenden Komponenten: - LDAP Server - GIT Server - OpenVPN Server - Webserver für Open-Laboratory Seiten - Intranet (z.B. nur im OpenVPN erreichbar), Seiten für Benutzerverwaltung, Musik etc. - MariaDB Cluster - E-Mail Server Das ganze wird auf den vorhandenen Ressourcen aufgesetzt mit einzelnen Erweiterungen. Wie wir die einzelnen Systeme designen werden wir im nächsten Meeting besprochen. Evtl. gibt es darüber hinaus Firmen im Stuttgart, die bereit sind unser Projekt zu unterstützen. == Monitoring == Das Monitoring sollte (muss) außerhalb des Pilot100 gehostet werden um sicher zu stellen, dass dieser funktioniert, obwohl die Dienste für den Nutzer nicht erreichbar sind. Auf der anderen Seite verfälscht z.B. ein Netzwerk-Ausfall des RZs, auch die Herabstufung der eigenen Messwerte. Ein Monitoring im eigenen RZ oder auch [http://nagios.sourceforge.net/docs/3_0/dependencychecks.html "Predictive Checks"] bei nagios kann zumindest eine Logik bzw. Abhängigkeiten der Dienste abbilden und somit präziser messen. Hier macht eventuell ein embedded System im Open Laboratory Sinn, das durch den VPN auf alle Systeme zugreifen kann. Desweiteren ein zweites embedded System für ein Configuration Management wie Saltstack (optional). == Hardware == === Alpha Phase === In der Alpha-Phase beschränkt sich die Hardware-Notwendigkeit auf ein Minimum. <br> - Anbindung im Skylab (16 Mbit/s) - zwei Load Balancer (Zusammen 2HE) -- Futjsu Primergy RX100 S5 (? GHz, 4GB RAM) -- Selbstbau P4 (3GHz, 1,5 GB RAM) - zwei Hypervisor (Zusammen 4HE) -- 2x HP DL380 G5 (3GHz, 16GB RAM) - ein bis zwei Storage-Server (Zusammen 2-4HE) -- Supermicro (2,8GHz, 4GB RAM, 6 Festplatten - 2x SYS, 4x STORAGE) - einen Gigabit Switch (1HE) <gallery> Datei:Pilo100-Alpha1.jpg|Pilot100@Skylab 1 Datei:Pilo100-Alpha2.jpg|Pilot100@Skylab 2 </gallery> === Beta-Phase === - Anbindung im RZ (Globalways, 100MBit/s) - zwei Hypervisor (Zusammen 4HE) -- Eigenbau AMD FX-8350, 16GB RAM -- Eigenbau AMD FX-8350, 32GB RAM - zwei Storage-Server (Zusammen 8HE) -- 2x Eigenbau AMD FM2 A6-5400K APU, 8GB RAM, MB Asus F2A85-M; Storage: SSD 250GB, SATA 2TB - einen [http://h17007.www1.hp.com/us/en/networking/products/switches/HP_5400_zl_Switch_Series/index.aspx#.UodKanBLNgg HP 10Gigabit Switch], HP 5400zl (6HE) ( Dank einer Spende von Prof. Menno Harms) <gallery> Datei:Pilo100-Beta1.jpg|Globalways Schrank Vorderseite Datei:Pilo100-Beta2.jpg|Globalways Schrank Rückseite </gallery> === RC1 === Ziel Design - Anbindung im RZ (Globalways, 100MBit/s) - zwei Hypervisor (Zusammen 4HE) -- Eigenbau AMD FX-8350, 16GB RAM -- Eigenbau AMD FX-8350, 32GB RAM - zwei Storage-Server (Zusammen 4HE) -- 2x Eigenbau AMD FX-6300/A6-5400k, 4GB RAM/8GB RAM, MB Asus/Gigabyte; Storage: SSD 1x 250GB, 2x SATA 500GB - einen HP 10Gigabit Switch], HP 5400zl (6HE) Storage Redesign [[Image:Pilot100_-_Storage-Design_(RC1).png|center|700px|Pilo100 Storage Design (RC1)]] === RC2 === Ziel Design - Anbindung im RZ (Globalways, 100MBit/s) - zwei Hypervisor (Zusammen 4HE) -- Eigenbau AMD FX-8350, 16GB RAM; Storage: HDD 1x1TB -- Eigenbau AMD FX-8350, 32GB RAM - zwei Storage-Server (Zusammen 4HE) -- 2x Eigenbau AMD FX-6300/FX-4300, 4GB RAM, MB Asus/Gigabyte; Storage: SSD 1x 250GB - einen HP 10Gigabit Switch], HP 5400zl (6HE) Storage Redesign [[Image:Pilot100_-_Storage-Design_(RC2).png|center|700px|Pilo100 Storage Design (RC2)]] == Schematische Dasrstellung == [[Image:pilo100-schemav1.png|center|700px|Pilo100 Schema v1.png]] == Konzeption == === Netzwerk === === Load Balancer === Möglich Lösungen: # ZEN Load Balancer: http://www.zenloadbalancer.com/ - Diese Lösung bietet aber nur die Möglichkeit den Backend-Server als Fallback zu verwenden. Ein zweiter LB ist nicht vorgesehen. # HAProxy: http://haproxy.1wt.eu/ <br> * mit heartbeat: http://www.howtoforge.com/setting-up-a-high-availability-load-balancer-with-haproxy-heartbeat-on-debian-lenny * mit keepalived: http://kaivanov.blogspot.de/2012/02/building-ha-load-balancer-with-haproxy.html * pfsense https://doc.pfsense.org/index.php/Inbound_Load_Balancing === HyperVisor === Im Zusammenhang mit der HyperVisor-Auswahl wird für weitere Infos aus die [http://wiki.open-laboratory.de/SRI Projekt-Seite SRI] verwiesen. Als Management-System stehen diese Lösungen in engerer Auswahl: [http://code.google.com/p/ganeti/ ganeti], [http://www.openstack.org/ OpenStack] oder [http://archipelproject.org/ Archipel] # Hardware-Tests mit libvirtd und virt-manager: http://libvirt.org/ # Archipel: http://archipelproject.org/ # Ganeti: https://code.google.com/p/ganeti/ weitere Infos zu Ganeti und dem Ganeti_WebManager unter http://wiki.open-laboratory.de/Intern:IT:HowTo:Ganeti === Storage-Server === s. [http://wiki.open-laboratory.de/Pilot100#Storage-Server Storage/Failover/HA] == Realisierung == === Hardware === [http://wiki.open-laboratory.de/Pilot100#Hardware s.o.] === Software === ==== RC1 ==== * Ganeti * Ceph (RBD und CephFS) * KVM * pfsense Appliance ==== RC2 ==== * Ganeti * DRBD * Ceph (RBD) * KVM * pfsense Appliance == Storage/Failover/HA == Die Problematiken bleiben deshalb zusammen, weil die Strategie des HA mit dem Storage-Konzept eng verbunden ist. <br> Eine Überblick gibt die SRI Seite: http://wiki.open-laboratory.de/SRI#Storage <br> Für die ersten Tests mit einem "Shared Storage", auf das auch mehrere VMs gleichzeitig schreiben könenn sollen, wird Ceph verwendet (http://wiki.open-laboratory.de/Intern:IT:HowTo:Ceph). == Performance Tuning == Bonding: http://www.howtoforge.com/nic_bonding - Achtung: 2x 1Gbit/s != 2 GBit/s 10GBASE-T: http://www.thomas-krenn.com/de/wiki/10_Gigabit_Ethernet SSD: z.B. http://ceph.com/docs/master/install/hardware-recommendations/ == Verfügbarkeit und Software-Updates == === OS === Durch Gentoo wird die Notwendigkeit, Updates einzuspielen auf das effektive Minimum begrenzt. <br> Der auslösene Trigger für Updates ist neben zstl. notwendigen Features, vor allem Sicherheitsupdates. <br> Für den Cluster (aber auch die VMs) gibt es ein Script, dass gentoo, Debian und Redhat (inkl. darauf basierenden Dtsributionen) unterstützt: http://git.pilarkto.net/pnet-suite.git/tree/INSTALL_START/update-check === Storage (Ceph) === s. http://wiki.open-laboratory.de/Intern:IT:HowTo:Ceph#Updates === Virtualisierung (Ganeti) === s. http://wiki.open-laboratory.de/Intern:IT:HowTo:Ganeti#Updates == Weiterführendes == http://de.slideshare.net/openstack/use-this-version-utpal-thakrar-stacking-up-with-openstack41713
Zusammenfassung:
Nur Kleinigkeiten wurden verändert Diese Seite beobachten
Abbrechen
