Benutzer-Werkzeuge

Webseiten-Werkzeuge


plattform-migration:konzept

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
plattform-migration:konzept [2015/09/20 09:25] – [Virtuelle Maschinen] thomasbplattform-migration:konzept [2015/09/20 13:56] (aktuell) – [Speicherplatz der Mitglieder] 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 =====
 +
 +RHEL wird für die beiden Cluster-Nodes bzw. Hypervisoren verwendet (**TODO**: Sponsoring bei Redhat anfragen). Der Cluster-Stack von Redhat ist sehr weit fortgeschritten. Da es sich um Open Source Komponenten handelt, kann er zwar auch auf anderen Betriebssystemen verwendet werden - RHEL hat jedoch langen Support (RHEL7 wurde in 2014 released und ist bis 2024 supported). Der Life-Cycle der Distribution der Hypervisoren sollte denjenigen der Hardware übersteigen. Upgrades der Hypervisoren sind sehr zeitaufwendig, da das Clustering besonders viele Tests benötigt. Er soll deshalb nur stattfinden, wenn die Hardware ersetzt wird.
 +
 +Debian wird für die restlichen virtuellen Maschinen eingesetzt.
 ===== Komponenten des Clustering ===== ===== Komponenten des Clustering =====
  
Zeile 100: 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)
 +  * Webseiten können auf mehreren Webservern genutzt werden (bei Migrationen können z.B. die Webseiten stückweise auf den Webserver mit den neueren Komponenten migriert werden)
 +
 +===== Benutzerverwaltung =====
 +
 +Sämtliche virtuelle Maschinen werden so konfiguriert, dass sie über PAM die Benutzerdaten ab dem LDAP-Verzeichnis beziehen. Die Authentifizierung erfolgt über Kerberos.
 +
 +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://www.ldap-account-manager.org/) vorgenommen.
 +
 +Auf LDAP werden auch die Maildomains bzw. Aliases verwalten. Der Mailserver bezieht die Angaben zur Zustellung von Mails aus dem Verzeichnis.
 +
 +===== Systemadministration =====
 +
 +Die /etc-Verzeichnisse der Installationen werden mit etckeeper (http://joeyh.name/code/etckeeper/) in ein git-Repository eingecheckt. Jeder Administrator muss seine Änderungen zusammen mit einem Kommentar einchecken.
 +
 +Ein Monitoring-Server mit OMD bzw. check_mk (http://omdistro.org/, http://mathias-kettner.de/checkmk.html) wird dazu verwendet, die Verfügbarkeit sämtlicher Dienste zu prüfen und zu alarmieren.
 +
 +Die Shellserver dienen den Administratoren als Jumphosts. Der direkte Login per SSH auf die restlichen VMs mit Diensten ist nur von ihnen 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://www.shorewall.net/PortKnocking.html).
 +===== Security =====
 +
 +Jeder Host ist mit einer host-based Firewall ausgestattet (Shorewall, http://www.shorewall.net/).
 +
 +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. Der Zugriff auf den Logserver wird eingeschränkt.
 +
 +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, welche gleichzeitig Zugriff auf rot und grün benötigen) Dual-Homed an beide Zonen verbunden.
 +
 +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/Mitglied wird in der blauen Zone jeweils ein eigenes VLAN erstellt.
 +
 +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 ====
 +
 +{{ :plattform-migration:trashnet_logical.png?direct |}}
  
 ==== Storage und Cluster-Komponenten ==== ==== Storage und Cluster-Komponenten ====
Zeile 150: Zeile 218:
 | tbd | ? | primary DNS | Node 1 | n | | tbd | ? | primary DNS | Node 1 | n |
 | Webserver | ? | Webserver | Node 1 | y | | 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 | | Monitoring | ? | Node für Monitoring | Node 2 | y |
-| LDAP/Kerberos | ? | Authentifizierung und Authorisierung für alle Nodes | Node 1 | |+| LDAP/Kerberos Primary | ? | Authentifizierung und Authorisierung für alle Nodes | Node 1 | n | 
 +| LDAP/Kerberos Secondary | ? | Authentifizierung und Authorisierung für alle Nodes | Node 2 | n |
 | Syslog | ? | zentraler Syslog-Server | Node 1 | y | | 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