Pilot100

Aus PILARKTO.ORG Open Laboratory e.V.
Wechseln zu: Navigation, Suche
{{{Bildbeschribung}}}
Projektstart 2013/04/13
Projektleiter Philipp.Strobl
Betreuer Matthias.hauber
Status RC
Projektname pilot100
Bildbeschribung

Inhaltsverzeichnis

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.
Hochverfügbar werden aber nur wenige zentrale Services ausgestattet. Andere Systemen werden für Ausfall und Wartung auf failover ausgelegt.

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 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 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 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 "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. 

- 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)

  • Pilot100@Skylab 1

  • Pilot100@Skylab 2

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 HP 10Gigabit Switch, HP 5400zl (6HE) ( Dank einer Spende von Prof. Menno Harms)

  • Globalways Schrank Vorderseite

  • Globalways Schrank Rückseite

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

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

Pilo100 Storage Design (RC2)

Schematische Dasrstellung

Pilo100 Schema v1.png

Konzeption

Netzwerk

Load Balancer

Möglich Lösungen:

  1. 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.
  2. HAProxy: http://haproxy.1wt.eu/

HyperVisor

Im Zusammenhang mit der HyperVisor-Auswahl wird für weitere Infos aus die Projekt-Seite SRI verwiesen. Als Management-System stehen diese Lösungen in engerer Auswahl: ganeti, OpenStack oder Archipel

  1. Hardware-Tests mit libvirtd und virt-manager: http://libvirt.org/
  2. Archipel: http://archipelproject.org/
  3. 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. Storage/Failover/HA

Realisierung

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.

Eine Überblick gibt die SRI Seite: http://wiki.open-laboratory.de/SRI#Storage

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.
Der auslösene Trigger für Updates ist neben zstl. notwendigen Features, vor allem Sicherheitsupdates.
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

Von „http://wiki.open-laboratory.de/index.php?title=Pilot100&oldid=7215“