Nicht suchen, finden – Ausweg aus dem Server Memory

Die alltägliche Arbeit eines Server Administrators kann schnell zum Memory-Spiel werden, wenn die Anzahl zu verwaltender Server die ersten 100 übersteigt. Server, Dienste und Ressourcen müssen oft eindeutig zugeordnet und Abhängigkeiten  einfach und übersichtlich dargestellt werden.

Beispielweise betrifft dies das Monitoring Webinterface, Definitionstabellen von Server-Automatisierungssystemen, die Ressourcenverteilung für Virtualisierung, das Aufrufen von SSH Logins oder der Konfiguration eines Loadbalancers.

Ein komplettes Support Netzwerk kann aus Kundenservern (virtuelle Server ), den Host-Systemen (für Virtualisierung) sowie einzelnen Support-Infrastruktur-Servern bestehen (virtuelle Server im Wartungsnetzwerk für Datensicherung, Monitoring etc.). Für virtuellen Server sind meistens Ressourcen (z.B. Speicherplatz auf Hostsystemen und für die Datensicherung) vorzuhalten, die ebenfalls übersichtlich und eindeutig zuzuordnen sein sollten.

Oft hilft es, wenn dahinter ein leicht verständliches System steckt.

Die Lösung – eine eigene DNS Server Hierarchie

Vorraussetzung ist, das alle Netzwerke direkt erreichbar sind (z.B. über ein unidirektionales VPN, ich nenne das mal “Wartungsnetzwerk”). Die Orientierung im Wartungsnetzwerk kann eine logische Ordnung der Server und Ressourcen nach dem DNS Prinzip sowie dessen Umkehrung helfen: Unter einer Support – Hauptdomain (Beispiel: “srservers.com”) werden die verschiedenen Netzwerke verschiedener Kunden, darunter dann einzelne Server geführt:

  • Schema: <server[+ Zähler]> . <Kunde [ + Zähler ]> .srservers.com
  • Kurzname <server[+ Zähler]> . <Kunde [ + Zähler ]>

Die Kunden bekommmen eine kurze ID <Kunde> und einen Zähler, der die verschiedenen Arbeitsgruppen, Standorte oder einfach Cluster nummeriert. Ein Beispiel:

  • Der Kunde “Lars SimselDimp GmbH” betreibt den Webserver
    web.simsel1.srservers.com,
    Kurzname: web1.simsel1

Für Ressourcen- und Server-Übersichten ist die Umkehrung des Schemas praktisch, hier kann die Hauptdomain “srservers.com” weggelassen werden.

  • Schema: <Kunde [ + Zähler ]> – <server[+ Zähler]> – < Ressource >
  • Beispiel FestplattenPartitionen, iSCSI, LVM oder DRBD devices
    simsel1-web1-root
    simsel1-web1-var
    simsel1-web1-srv
    simsel1-web1-tmp
  • Beispiel Debian-Netzwerkkarten
    simsel1-web1-eth0
    simsel1-web1-eth1
  • Beispiel Monitoring-Services
    simsel1-web1 http-status
    simsel1-web1 http-status

Alles zusammen – ein Cluster Server Beispiel

Der Kunde “Lars SimselDimp GmbH” betreibt einen Web-Server-Cluster für das Webportal dein-anwalt.simseldimp.de sowie einen Doppelserver für dein-garten.simseldimp.de.

Im Cluster werden 1 Loadbalancer, 2 Webserver, 1 SQL Server und 1 Datenserver betrieben, welche als virtuelle Server auf zwei Host-Systemen arbeiten. Der Doppelserver besteht aus einem virtuellen Server, auf dem alle nötigen Dienste abgebildet werden. Dieser virtuelle Server ist auf zwei Host-Systemen installiert, wird aber nur auf einem betrieben und kann im Notfall auf das andere Host-System umgeschaltet werden.

Extern sind der Loadbalancer für dein-anwalt.simseldimp.de sowie der Webserver dein-garten.simseldimp.de unter eben diesen öffentlichen DNS Namen erreichbar. Im dahinter liegenden Wartungsnetzwerk werden folgende Serveraddressen geführt:

Arbeitsgruppe simsel1:

  • Im Wartungsnetz haben die virtuellen Server folgende DNS Namen:
 ldb.simsel1 # Loadbalancer für "dein-anwalt.simseldimp.de"
lamp1.simsel1 # Webserver 1 
lamp2.simsel1 # Webserver 2 
  sql.simsel1 # Mysql Server (Replication Master)
 data.simsel1 # NFS Fileserver, sFTP - Zugänge
  • Folgende Dienste müssen auf den jeweiligen Servern überwacht werden:
    system, ldb, http, sql, sql-replication, data
  • Anwendungsbeispiel: ClusterSSH
    ClusterSSH ermöglich das parallele Login auf meheren Servern. Für eine Arbeitsgruppe lassen sich mehrere sinnvolle Gruppierungen finden, z.B. das Login auf alle Webserver:cssh web.simsel1   => ssh lamp1.simsel1, ssh lamp2.simsel2, ssh ldb.simsel2
    cssh sql.simsel1     => ssh lamp1.simsel1, ssh lamp2.simsel2, ssh sql.simsel2
    cshh simsel1           => alle Server der Arbeitsgruppe simsel1Die cssh config Dateien lassen sich leicht anhand der installierten Dienste und Rollen automatisch erstellen und auf die Arbeitsplätze des Support Teams verteilen.

Arbeitsgruppe simsel2:

  • Im Wartungsnetz hat der jeweils betriebene virtuelle Server folgenden DNS Namen:
    web1.simsel2 # Webserver für “dein-garten.simseldimp.de”
  • Folgende Dienste müssen auf dem Server web1.simsel2 überwacht werden:
    system, http, sql, data (sFTP)

Fazit

Dieser Beitrag kann nur einen Überblick geben, im Detail ist der Serverbetrieb ja etwas komplexer (Virtualisierung, Failover, Replikation, Datensicherung). Mit etwas Systematik in der Benennung und Einordnung von Servern, Ressourcen und Diensten läßt sich der Überblik über größere Serverpools jedoch deutlich erhöhen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.