plattform-migration:konzept
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende ÜberarbeitungNächste ÜberarbeitungBeide Seiten der Revision | ||
plattform-migration:konzept [2015/09/20 08:54] – thomasb | plattform-migration:konzept [2015/09/20 13:37] – [Übersicht] thomasb | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== Konzept neue Plattform ====== | + | ====== Konzept neue Plattform: Basics |
- | |Dokumentenname | PFM_Konzept | + | |Dokumentenname | PFM_Konzept_Basics |
|Autor | Thomas Bader | | |Autor | Thomas Bader | | ||
|Status | Erster Entwurf, bereit zur Diskussion | | |Status | Erster Entwurf, bereit zur Diskussion | | ||
Zeile 10: | Zeile 10: | ||
Die Dienste werden mit virtualisierten Maschinen bereitgestellt. Dazu werden zwei physische Server als Cluster konfiguriert. | Die Dienste werden mit virtualisierten Maschinen bereitgestellt. Dazu werden zwei physische Server als Cluster konfiguriert. | ||
+ | Die Konfiguration der einzelnen Services bzw. virtuellen Maschinen wird gesondert dokumentiert. Das vorliegende Dokument dient der Konzeptionierung und einer Übersicht über die Infrastruktur der Virtualisierung. | ||
+ | |||
+ | ===== Betriebssysteme ===== | ||
+ | |||
+ | Es werden unterschiedliche Betriebssysteme verwendet: | ||
+ | |||
+ | * RHEL für die beiden Cluster-Nodes bzw. Hypervisoren. Der Cluster-Stack von Redhat ist sehr weit fortgeschritten. Da es sich um Open Source Komponenten handelt, kann er auch auf anderen Betriebssystemen verwendet werden. Bei RHEL ist der Extended Support lange (RHEL7 wurde in 2014 released und ist bis 2024 supported) und es soll vermieden werden, auf den Hypervisoren oft grosse Konfigurationsänderungen bzw. Upgrades vornehmen zu müssen. | ||
===== Komponenten des Clustering ===== | ===== Komponenten des Clustering ===== | ||
Zeile 28: | Zeile 35: | ||
- Die Heartbeats werden zusätzlich auch per RS232-Link übertragen, | - Die Heartbeats werden zusätzlich auch per RS232-Link übertragen, | ||
- Mit Fencing können die Nodes sich gegenseitig abschalten, sofern nicht automatisch behebbare Probleme auftreten | - Mit Fencing können die Nodes sich gegenseitig abschalten, sofern nicht automatisch behebbare Probleme auftreten | ||
+ | |||
+ | corosync führt Controlled Process Groups (CPG) ein. Innerhalb einer CPG werden Nachrichten immer in geordneter Reihenfolge ausgetauscht. Dazu wird ein Totem in einem Ring ausgetauscht, | ||
+ | |||
+ | ==== Rgmanager / Pacemaker ==== | ||
+ | |||
+ | Die beiden Komponenten Rgmanager (Redhat-Cluster Stack) und Pacemaker (Linux-HA) stellen das Ressourcen-Management des Clusters bereit. In ihnen sind die Services des Clusters hinterlegt (z.B. welche virtuelle Maschinen auf welcher Node läuft). Durch corosync festgestellte Änderungen am Cluster-Membership wird an den Resource-Manager signalisiert. Dieser prüft ob Services gestartet oder beendet werden müssen. | ||
+ | |||
+ | Welcher Resource-Manager eingesetzt wird ist zu definieren. | ||
==== DRBD ==== | ==== DRBD ==== | ||
Zeile 42: | Zeile 57: | ||
Der Distributed Lock Manager stellt das Locking im Cluster bereit. Bei Shared-Ressourcen (Clustered-LVM und GFS2) muss sichergestellt werden, dass keine parallelen Zugriffe auf dieselben Daten stattfinden. DRBD synchronisiert lediglich die Datenblöcke der Disks und stellt nicht sicher, ob nicht Prozesse auf beiden Nodes parallen dieselben Datenblöcke schreiben wollen (was zu inkonsistenten Daten führt). | Der Distributed Lock Manager stellt das Locking im Cluster bereit. Bei Shared-Ressourcen (Clustered-LVM und GFS2) muss sichergestellt werden, dass keine parallelen Zugriffe auf dieselben Daten stattfinden. DRBD synchronisiert lediglich die Datenblöcke der Disks und stellt nicht sicher, ob nicht Prozesse auf beiden Nodes parallen dieselben Datenblöcke schreiben wollen (was zu inkonsistenten Daten führt). | ||
+ | |||
+ | Durch die von corosync eingeführten CPG können für eine Ressource niemals zwei Locks parallel vergeben sein. | ||
Mit DLM werden im Cluster zwei Dinge sichergestellt: | Mit DLM werden im Cluster zwei Dinge sichergestellt: | ||
Zeile 56: | Zeile 73: | ||
Im Cluster werden zwei Volume-Groups realisiert. Jede Node verfügt über eine eigene VG und das darunterliegende Physical-Volume wird per DRBD repliziert. | Im Cluster werden zwei Volume-Groups realisiert. Jede Node verfügt über eine eigene VG und das darunterliegende Physical-Volume wird per DRBD repliziert. | ||
+ | ===== Betrieb des Clusters ===== | ||
+ | |||
+ | ==== Start des Clusters ==== | ||
+ | |||
+ | Bei einem Start des Clusters laufen folgende Schritte ab: | ||
+ | |||
+ | - Über cman wird das Quorum des Clusters festgestellt. Es sind nur zwei Nodes im Cluster, deshalb beschränkt sich dies darauf die Erreichbarkeit der jeweils anderen Node zu prüfen. Eine Node hat eine höhere Priorität im Clusters - sofern diese die andere Node nicht sieht, schaltet sie diese via Fencing ab. Dies verhinder Split-Brain Situationen. | ||
+ | - cman signalisiert corosync, dass der Cluster in Betrieb gehen kann und die Nodes beginnen den Austausch von Heartbeats | ||
+ | - corosync signalisiert dem Resource-Manager eine Änderung im Cluster-Membership | ||
+ | - Resource-Manager nimmt anhand seiner lokalen Konfiguration alle Services in Betrieb - DRBD-Blockdevice aktivieren, CLVM-VG aktivieren, virtuelle Maschinen starten | ||
+ | - CLVM holt sich beim DLM Locks und sperrt die jeweils eigene Volume-Group | ||
+ | - GFS2 holt sich bei Bedarf (d.H. bei jedem Schreibzugriff) Locks vom DLM und gibt diese bei Ende der Operation wieder frei | ||
+ | |||
+ | Der Resource-Manager weiss, welcher Service auf welcher Node läuft. Sofern beide Nodes aktiv sind, startet jede Node jeweils ihre eigenen Services. Falls die beiden Nodes einander nicht erreichen können, startet die übrig gebliebende Node alle Services bei sich lokal. | ||
+ | |||
+ | Das Fencing ist deshalb wichtig, da bei einem Verbindungsproblem zwischen den Nodes verhindert werden muss, dass jede Node bei sich selber alle Services lokal startet. | ||
+ | |||
+ | ==== Ausfall einer Node ==== | ||
+ | |||
+ | Beim Ausfall einer Node finden folgende Schritte statt: | ||
+ | |||
+ | - Falls die innerhalb von x Heartbeats wieder online ist, wird der Cluster ohne Veränderung weiterbetrieben | ||
+ | - Falls die Node innerhalb von x Heartbeats immer noch offline ist, prüft cman ob ein Quorum vorhanden ist (nicht notwendig bei Clustern mit zwei Nodes) | ||
+ | - parallel dazu wird DLM signalisiert, | ||
+ | - sobald das Fencing durchgeführt wurde, wird DLM signalisiert, | ||
+ | - ebenso wird dem Resource-Manager signalisiert, | ||
+ | - Resource-Manager startet auf Node lokal alle Services, welche im Cluster nicht aktiv sind | ||
+ | |||
+ | Wenn die ausgefallene Node wird verfügbar ist, prüft cman erneut das Quorum, nimmt die Node wieder in die Verteilung des Totem auf und signalisiert dem Resource-Manager die Prüfung der Resources. Dieser wird so konfiguriert, | ||
===== Virtualisierung ===== | ===== Virtualisierung ===== | ||
Zeile 61: | Zeile 107: | ||
Alternativ können auf einem Cluster in einer lokalen Storage (/local) auch virtuelle Maschinen abgelegt werden, welche vom Fail-Over ausgeschlossen sind. | Alternativ können auf einem Cluster in einer lokalen Storage (/local) auch virtuelle Maschinen abgelegt werden, welche vom Fail-Over ausgeschlossen sind. | ||
+ | |||
+ | ===== Speicherplatz der Mitglieder ===== | ||
+ | |||
+ | Die Daten der Mitglieder werden auf einem Fileserver abgelegt, welcher die Homeverzeichnisse der Benutzer per NFS verteilt. Dadurch können die Mitglieder auf allen Maschinen ihr Homeverzeichnis nutzen. Dies bedeutet: | ||
+ | |||
+ | * Auf einem Shell-Server editierte Daten sind auch auf dem Webserver verfügbar | ||
+ | * Mails können auf beiden Shell-Servern gelesen werden (setzt Maildir voraus) | ||
+ | |||
+ | ===== Benutzerverwaltung ===== | ||
+ | |||
+ | Sämtliche virtuelle Maschinen werden so konfiguriert, | ||
+ | |||
+ | Der Zugriff auf einzelne virtuelle Maschinen wird über die Gruppenmitgliedschaft kontrolliert. Für die Systemadministration wird so bspw. festgelegt, welcher Administrator auf welche der virtuellen Maschinen einloggen darf. | ||
+ | |||
+ | Die Verwaltung des LDAP-Verzeichnis wird mit dem LDAP Account Manager (LAM, https:// | ||
+ | |||
+ | Auf LDAP werden auch die Maildomains bzw. Aliases verwalten. Der Mailserver bezieht die Angaben zur Zustellung von Mails aus dem Verzeichnis. | ||
+ | |||
+ | ===== Systemadministration ===== | ||
+ | |||
+ | Die / | ||
+ | |||
+ | Ein Monitoring-Server mit OMD bzw. check_mk (http:// | ||
+ | |||
+ | Die Shellserver dienen den Administratoren als Jumphosts. Der direkte Login per SSH auf die restlichen VMs mit Diensten ist nur von den Shellservern aus möglich. Um im Falle eines Ausfalls der Shellserver zumindest Zugriff auf die Hypervisor-Hosts zu bekommen, wird auf ihrer host-based Firewall Port-Knocking implementiert (http:// | ||
+ | ===== Security ===== | ||
+ | |||
+ | Jeder Host ist mit einer host-based Firewall ausgestattet (Shorewall, http:// | ||
+ | |||
+ | Die Logs der Systeme werden zentral auf einem Logserver gesammelt (Syslog per TCP). Auf jeder virtuellen Maschine wird die Aufbewahrungsdauer für Logs verkürzt. Stattdessen dient der Logserver der längeren Aufbewahrung der Logs. | ||
+ | |||
+ | Die Aktionen der Systemadministratoren werden, sobald ein Wechsel zu einem privilegierten Account stattgefunden hat, aufgezeichnet. Bevorzugt soll sudo verwendet werden, welches sämtliche Kommandos loggt. Sofern eine Shell als privilegierter Benutzer benötigt wird, dann werden die abgesetzten Kommandos aufgezeichnet. | ||
+ | |||
+ | |||
+ | ===== Netzwerkzonierung ===== | ||
+ | |||
+ | Die Infrastruktur verfügt über eine rote Zone, das Internet. Alle Server, welche von aussen erreichbar sein müssen, sind mit einem Interface in die Zone verbunden. | ||
+ | |||
+ | Die grüne Zone ist das private Netz von trash.net. Mit ihr werden virtuelle Maschinen verbunden, welche kritische Dienstleistungen (z.B. LDAP, Fileserver) bereitstellen und keinen Zugriff ins Internet benötigen. | ||
+ | |||
+ | Die virtuellen Maschinen von trash.net benötigen Zugriff auf LDAP, Fileserver und andere. Deshalb sind einige Maschinen (diejenigen, | ||
+ | |||
+ | Für Mitglieder und Projekte ist die blaue Zone vorgesehen. Mit ihr können private Netze zwischen virtuellen Maschinen realisiert werden. Maschinen von Mitgliedern können, analog zu trash.net, nur mit der blauen Zone verbunden sein oder Dual-Homed rot/blau sein. Pro Projekt/ | ||
+ | |||
+ | Die Nutzung der blauen Zone ist optional. Die virtuelle Maschine eines Projekts kann auch alleine mit der roten Zone verbunden sein. Ein eigenes VLAN in der blauen Zone wird nur zugewiesen, wenn das jeweilige Projekt die Voraussetzungen dafür erfüllt: | ||
+ | |||
+ | * Wenn ein Projekt besonders viele VM benötigen sollte, dann ist die Vorgabe, dass eine virtuelle Maschine im Internet als Reverse Proxy o.ä. betrieben wird, damit die VM mit privaten IP-Adressen adressiert werden können | ||
+ | * Wenn ein Projekt eine Datensynchronisation o.ä. zwischen virtuellen Maschinen benötigt, dann soll diese über die blaue Zone realisiert werden. Hohes Trafficaufkommen zwischen virtuellen Maschinen soll nicht über die rote Zone transferiert werden. | ||
+ | |||
+ | Neben der roten, grünen und blauen Zone existieren noch weitere Zonen, welche exklusiv für die Verbindung zwischen den Hypervisor-Hosts vorgesehen sind: | ||
+ | |||
+ | * grau als Storage-Netz | ||
+ | * gelb als Back-Channel / Cluster-Management | ||
+ | * orange für IPMI | ||
+ | |||
+ | |||
===== Details der Konfiguration ===== | ===== Details der Konfiguration ===== | ||
+ | ==== Zonierung ==== | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | ==== Storage und Cluster-Komponenten ==== | ||
+ | |||
+ | {{ : | ||
==== Netzwerk ==== | ==== Netzwerk ==== | ||
Zeile 78: | Zeile 187: | ||
|RS232 | ttyS0 | serieller Cross-Link, für Cluster-Management | | |RS232 | ttyS0 | serieller Cross-Link, für Cluster-Management | | ||
+ | {{ : | ||
==== Storage ==== | ==== Storage ==== | ||
Zeile 106: | Zeile 216: | ||
| knox | ? | secondary DNS | Node 2 | n | | | knox | ? | secondary DNS | Node 2 | n | | ||
| tbd | ? | primary DNS | Node 1 | n | | | tbd | ? | primary DNS | Node 1 | n | | ||
+ | | Webserver | ? | Webserver | Node 1 | y | | ||
+ | | Mail | ? | Mailserver (SMTP, POP, IMAP) | Node 1 | y | | ||
| Fileserver | ? | NFS-Server | Node 1 | y | | | Fileserver | ? | NFS-Server | Node 1 | y | | ||
+ | | Monitoring | ? | Node für Monitoring | Node 2 | y | | ||
+ | | LDAP/ | ||
+ | | LDAP/ | ||
+ | | Syslog | ? | zentraler Syslog-Server | Node 1 | y | | ||
Anmerkung: nicht alle virtuellen Maschinen sind mit einem Failover ausgestattet. Sofern ein Dienst bereits auf Applikationsebene redundant ist (DNS), dann muss kein Failover auf Ebene der Virtualisierung realisiert werden. | Anmerkung: nicht alle virtuellen Maschinen sind mit einem Failover ausgestattet. Sofern ein Dienst bereits auf Applikationsebene redundant ist (DNS), dann muss kein Failover auf Ebene der Virtualisierung realisiert werden. |
plattform-migration/konzept.txt · Zuletzt geändert: 2015/09/20 13:56 von thomasb