plattform-migration:konzept_v2
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_v2 [2015/11/05 18:08] – [Systemadministration] thomasb | plattform-migration:konzept_v2 [2015/11/09 17:45] – [Systemadministration] truniger | ||
---|---|---|---|
Zeile 57: | Zeile 57: | ||
^Typ der Auswertung ^Datenquelle ^Tool ^ | ^Typ der Auswertung ^Datenquelle ^Tool ^ | ||
- | | FIXME Bitte hier eine Liste der benötigten Statistiken bzw. Auswertungen einfügen. | + | | tägliche Auswertung |
+ | | Echtzeitauswertung der Webserver-Zugriffshäufigkeit | ||
+ | | Echtzeitauswertung von Greylisting | / | ||
+ | | mehrfach-tägliche Auswertung der Mailserver-Nutzung | / | ||
+ | | mehrfach-tägliche Auswertung der Mailbox-Zugriffe | / | ||
+ | | Systemkennwerte | | statgrab, rrdtool, eigene Skripte | ||
===== Klassifizierung von virtuellen Maschinen, Daten und Zonen ===== | ===== Klassifizierung von virtuellen Maschinen, Daten und Zonen ===== | ||
Zeile 309: | Zeile 314: | ||
Der bisherige DNS-Setup soll vereinfacht werden: Es gibt dazu noch zwei VMs mit einer bind-Instanz auf dem roten Interface. Eine VM ist Master, die andere beschafft sich Kopien der Zonen per AXFR. | Der bisherige DNS-Setup soll vereinfacht werden: Es gibt dazu noch zwei VMs mit einer bind-Instanz auf dem roten Interface. Eine VM ist Master, die andere beschafft sich Kopien der Zonen per AXFR. | ||
- | Neu wird standardmässig jede Zone per DNSSEC signiert. Mit Inline Signing (http:// | + | FIXME Neu wird standardmässig jede Zone per DNSSEC signiert. Mit Inline Signing (http:// |
+ | |||
+ | FIXME Alternativ kann weiterhin ZKT verwendet werden. | ||
===== DNS rekursiv ===== | ===== DNS rekursiv ===== | ||
Zeile 332: | Zeile 339: | ||
✘ Es wird weiterhin möglich sein, dass der Code von einem Benutzer (z.B. PHP oder CGI) die world-readable Files von anderen Benutzern lesen kann. Dazu gibt es keine Lösung. | ✘ Es wird weiterhin möglich sein, dass der Code von einem Benutzer (z.B. PHP oder CGI) die world-readable Files von anderen Benutzern lesen kann. Dazu gibt es keine Lösung. | ||
+ | |||
+ | ☝Die virtuellen Webseiten sind bisher als dedizierter VirtualHost-Block in Apache konfiguriert. Die Umstellung auf Links hat erstens den Vorteil, dass keine Synchronisation der Apache-Konfiguration zwischen den VM notwendig ist und zweitens, dass IPv4 und IPv6 nicht getrennt konfiguriert werden muss (es muss je ein v4 und v6 VirtualHost aufgesetzt werden, der dann anhand der Host-Header und Symlinks die richtige Seite abruft). | ||
+ | |||
+ | ☝Aufgrund der Symlinks werden die Pfade der Logfiles der virtuellen Webseiten nicht mehr in Apache konfiguriert. Apache piped seine Logs in ein Skript, welches die Logs anhand des dort spezifizierten Host-Headers in die richtigen Pfade ablegt. Deshalb muss das Schema der Pfade der Logs für jeden Benutzer identisch sein. Das Log-Format muss ebenfalls angepasst werden für den Split: Es wird zu Beginn ein neues Feld eingefügt, welches den Host-Header des Requests beinhaltet und für den Split genutzt wird. | ||
===== Webapplikationen von trash.net ===== | ===== Webapplikationen von trash.net ===== | ||
Zeile 375: | Zeile 386: | ||
Die beiden VM sind für alle anderen VM auch als Relay nutzbar. Sie akzeptieren über das grüne Interface Mails von den anderen VM. Die VM für Typ Other müssen entweder den Mailversand selber implementieren oder sich via SMTP-Auth auf dem roten Interface der Mailserver anmelden. | Die beiden VM sind für alle anderen VM auch als Relay nutzbar. Sie akzeptieren über das grüne Interface Mails von den anderen VM. Die VM für Typ Other müssen entweder den Mailversand selber implementieren oder sich via SMTP-Auth auf dem roten Interface der Mailserver anmelden. | ||
+ | |||
+ | Auf den roten und grünen VM wird Postfix konfiguriert als Satellite (abgesehen natürlich von den Mail-VM). Ihre // | ||
Zeile 389: | Zeile 402: | ||
|Web | Extended | rot | LDAP, mounted /usr/home und /home per NFS (zusätzlich /srv/web, wenn die eigenen Services von trash.net darauf betrieben werden) | Die Webseiten werden per DNS auf beide VM verteilt. Sofern eine VM ausfällt, kann durch Anpassung im DNS der Fail-Over herbeigeführt werden. | | |Web | Extended | rot | LDAP, mounted /usr/home und /home per NFS (zusätzlich /srv/web, wenn die eigenen Services von trash.net darauf betrieben werden) | Die Webseiten werden per DNS auf beide VM verteilt. Sofern eine VM ausfällt, kann durch Anpassung im DNS der Fail-Over herbeigeführt werden. | | ||
|Messaging | Extended | rot | LDAP, mounted /usr/home per NFS | VM ist alleinstehend. | | |Messaging | Extended | rot | LDAP, mounted /usr/home per NFS | VM ist alleinstehend. | | ||
- | |Proxy | Extended | + | |Proxy | Base | rot | - | Werden auf Shell-Servern betrieben. Es wird kein spezieller Failover eingerichtet. Benutzer können bei sich auswählen, welcher der beiden Shell-Server der Tunnel-Endpunkt sein soll. | |
Das gesetzte Ziel, möglichst wenige VM der Klasse Core zu haben, wird somit erreicht. Wirklich kritisch sind nur NFS und LDAP. Hier ist bei einem Ausfall eine schnelle Reaktion notwendig. Bei allen anderen VM ist keine sofortige Intervention notwendig, da diese Services unabhängig voneinander laufen. | Das gesetzte Ziel, möglichst wenige VM der Klasse Core zu haben, wird somit erreicht. Wirklich kritisch sind nur NFS und LDAP. Hier ist bei einem Ausfall eine schnelle Reaktion notwendig. Bei allen anderen VM ist keine sofortige Intervention notwendig, da diese Services unabhängig voneinander laufen. | ||
Zeile 408: | Zeile 421: | ||
|Datenupload mit SFTP | Über die Shell-Server. Daten sind auf den Webservern via /home NFS-Mount verfügbar. | | |Datenupload mit SFTP | Über die Shell-Server. Daten sind auf den Webservern via /home NFS-Mount verfügbar. | | ||
|2ndary MX | Auf den Mail-VM. | | |2ndary MX | Auf den Mail-VM. | | ||
- | |Proxy | eigene Proxy-VM der Klasse Extended, kein Failover. | + | |Proxy |
- | |Stunnel | eigene Proxy-VM der Klasse Extended, kein Failover. | + | |Stunnel | Auf Shell-Server |
- | |DNSTunnel | eigene Proxy-VM der Klasse Extended, kein Failover. | + | |DNSTunnel | Auf Shell-Server |
|Mailinglisten | eigene Messaging-VM der Klasse Extended, kein Failover. | | |Mailinglisten | eigene Messaging-VM der Klasse Extended, kein Failover. | | ||
|Jabber | eigene Messaging-VM der Klasse Extended, kein Failover. | | |Jabber | eigene Messaging-VM der Klasse Extended, kein Failover. | | ||
Zeile 450: | Zeile 463: | ||
|Shell | Nicht notwendig, da Benutzer jederzeit auf die übrig bleibende VM wechseln können. | /etc/motd anpassen und Benutzer darauf hinweisen, auf die andere VM zu verbinden. | | |Shell | Nicht notwendig, da Benutzer jederzeit auf die übrig bleibende VM wechseln können. | /etc/motd anpassen und Benutzer darauf hinweisen, auf die andere VM zu verbinden. | | ||
|Web | Manuell durch Anpassung der web-prod0/ | |Web | Manuell durch Anpassung der web-prod0/ | ||
- | |Proxy, Messaging und weitere VM | Manuell durch Start der VM auf dem übrig bleibenden Hypervisor. | Keine speziellen Vorkehrungen für die Wartung erforderlich, | + | |Stunnel & DNSTunnel | Nicht notwendig, da Benutzer jederzeit seinen Tunnelendpunkt wechseln kann. | Kein spezielles Vorgehen. | |
+ | |Proxy | ||
+ | Bei einer Wartung einen Failover auszuführen ist jedes Mal mit Aufwand verbunden. Es sei angenommen, dass die Einleitung von einem Failover 10 Minuten Aufwand beträgt sowie nochmals 10 Minuten um ihn rückgängig zu machen. Wenn eine Wartung weniger als eine Stunde dauert, würde der Failover mindestens einen Drittel der Zeit betragen. Es ist deshalb angemessen, bei Ausfällen von weniger als einer Stunde auf einen eingeleiteten Failover zu verzichten. | ||
===== Netzwerk ===== | ===== Netzwerk ===== | ||
Zeile 459: | Zeile 474: | ||
{{ : | {{ : | ||
+ | |||
+ | ==== Q&A ==== | ||
+ | |||
+ | === Netzwerk === | ||
+ | |||
+ | == IP-Ranges == | ||
+ | |||
+ | VM von trash.net werden nicht mehr in 213.144.137.32/ | ||
+ | |||
+ | == Trennung rote und blaue Zone == | ||
+ | |||
+ | Die Unterscheidung zwischen der roten und blauen Zone ist rein administrativ. Die VM in den beiden Zonen sind in der selben Broadcast-Domain. | ||
+ | |||
+ | == Zugriff auf Management-Boards == | ||
+ | |||
+ | Zwischen den Hypervisoren werden Ethernet-Crosslinks eingerichtet - je von einem Port der Netzwerkkarte zum Port des Management-Boards des benachbarten Systems. Ein Zugriff auf die Management-Boards ist nur möglich, wenn man lokal auf der Shell vom benachbarten Hypervisor arbeitet. | ||
+ | |||
+ | == Upstream-Links == | ||
+ | |||
+ | Die beiden Hypervisoren können je einen eigenen Uplink ins Netz von Init7 nutzen. Es wird kein Switch benötigt. | ||
+ | |||
+ | == Link zur Replikation und grüne Zone == | ||
+ | |||
+ | Die beiden Hypervisoren haben einen Crosslink, auf dem per VLAN-Tagging zwei VLAN transportiert werden. Eines ist für die DRBD-Replikation und nicht zugänglich von den VM, das andere für die grüne Zone. | ||
+ | |||
+ | == Netzwerkports == | ||
+ | |||
+ | Es müssen auf jedem Hypervisor drei Netzwerkports verfügbar sein: 1x Uplink, 1x Crosslink für DRBD/grüne Zone, 1x Crosslink zum Management-Board des anderen Hypervisor. | ||
+ | |||
+ | == Zugriff von der grünen Zone ins Internet == | ||
+ | |||
+ | Die Systeme in der grünen Zone sollen keinen direkten Internetzugriff erhalten. Für sie wird lediglich NTP, DNS sowie ein Webproxy (HTTP/ | ||
+ | |||
+ | Der lokale, rekursive DNS-Server wird auf den DNS-VM betrieben. Sie sind multihomed und können auf einem Interface einen rekursiven DNS bereitstellen. | ||
+ | |||
+ | FIXME Es ist zu definieren, wo NTP läuft. | ||
+ | |||
+ | FIXME Es ist zu definieren, wo ein Proxy-Server betrieben wird. | ||
+ |
plattform-migration/konzept_v2.txt · Zuletzt geändert: 2015/11/24 16:56 von thomasb