Wir unterbrechen unser normales Programm für einen Beitrag aus dem Maschinenraum:
Unternehmen reden oft nicht gern über Spezifika ihrer IT-Infrastruktur. Man will entweder keine Geheimnisse preisgeben oder sich nicht blamieren. Das bedeutet leider, dass es für uns Systemadministratoren vergleichsweise wenig Referenzarchitekturen und Möglichkeiten gibt, über den Tellerrand zu schauen. Um hier Abhilfe zu schaffen, wollen wir mal ganz konkret erzählen, wie wir unser neuestes Rack ausgestattet haben. Alle Bilder in diesem Artikel sind dort entstanden.
Rechenzentrum
Hier haben wir uns aufgrund früherer Erfahrungen für Interxion (sprich: Interaction) in Frankfurt entschieden. Dort ist auch der DECIX beheimatet, und es finden sich Racks diverser Größen aus der Tech-Branche. Man ist also in ganz guter Gesellschaft. Wichtig ist für uns (unter anderem) auch die ISO27001-Zertifizierung. Und eine Customer Lounge mit Gratisgetränken für müde Admins gibt es ebenfalls.
Hardware
Erstmals haben wir dieses Rack von Anfang an bis zur letzten HE durchgeplant. Dadurch können wir auch schon vorab das komplette Rack verkabeln und müssen dann zum Ausbau nur noch neue Server in die vorbereiteten HEs schieben. Das spart viel nachträglichen Aufwand und wirkt dem Kabelchaos entgegen. Die Planung sieht vor, dass alle Komponenten redundant ausgelegt sind. Wir können den Ausfall eines beliebigen Geräts ohne signifikante Downtime abfangen, sei es ein Server, ein Switch oder eine ganze PDU. Dazu brauchen wir:
- 2 Router
- 4 Switches
- 16 Server
- 3 Storage-Systeme
- 2 PDUs
Die Router und Switches sind mit dem Ubiquity EdgeRouter Pro und dem Cisco Small Business SG-300 im Vergleich zu den anderen Komponenten sehr günstig. Wir betreiben hier ein relativ einfaches Setup mit ein bisschen Routing, VPN, VLANs und STP. Die genannten Geräte können bereits mehr als wir eigentlich bräuchten. Wir setzen daher im Netzwerk eher auf preiswerte Geräte, für die wir unabhängig vom Hersteller-Support selbst Ersatz bereithalten. Und durch die redundante Architektur sind wir ohnehin gegen den Ausfall einzelner Geräte gewappnet.
Bei den Servern setzen wir schon seit vielen Jahren auf Dell, aktuell sind R630 im Einsatz. Jeder Server verfügt über zwei Netzteile, vier Gigabit-Netzwerkschnittstellen, 256 GB RAM und zwei Intel Xeon E5-2680 v3 CPUs mit je zwölf Kernen. Insbesondere bei der Auswahl der CPU-Kerne relativ zum Arbeitsspeicher haben wir diesmal genau hingesehen und sind zu dem Ergebnis gelangt, dass die Anzahl der in unserer Virtualisierungslösung Citrix XenServer verwendeten vCPUs pro VM eine relativ kleine Rolle spielt. Soll heißen: Es schadet nicht, einer VM eine absurde Anzahl an virtuellen Kernen zu geben, und auch mit nur einem einzelnen Kern arbeitet die VM noch effizient. Auf der Virtualisierungsebene gibt es hier also erfreulich wenig Overhead. Bleibt noch die Frage, wie viele Kerne wir einer VM optimalerweise geben sollten und wie viele dieser vCPUs auf einen physikalischen Kern kommen sollten.
Der wegweisende Faktor ist hier der load-Wert der VM. Eine VM mit einer load von 4 kann vier Kerne voll beschäftigen. Man sollte daher die load der einzelnen VMs prüfen und sicherstellen, dass Peaks in der load durch die entsprechende Anzahl an vCPUs abgearbeitet werden können. Für die physikalischen Kerne sind eher Durchschnittswerte relevant. Beispiel: Angenommen die Durchschnitts-VM hat eine load von 0,25 und 2,5 GB RAM. Nun können wir die ~250 GB RAM des physikalischen Servers aufteilen und kommen auf maximal 100 VMs pro Server. Bei einer durchschnittlichen load von 0,25 bräuchten wir also 25 Kerne. Die bekommen wir am ehesten durch zwei CPUs mit je zwölf Kernen. Wir rechnen dabei nur mit "echten" Kernen, Hyperthreading lassen wir außen vor, da zwei Hyperthreading-Kerne ohne spezielle Optimierung maximal nur ca. 120% der Performance eines einzelnen physikalischen Kerns bringen.
Beim Storage sind wir seit Jahren sehr zufrieden mit NetApp, aktuell mit der FAS2552. Selten haben wir erlebt, dass ein Stück IT-Hardware so wenig Probleme gemacht hat. Bestückt sind die redundanten Nodes mit 24 SAS-Festplatten á 600 GB. Der Filer läuft im Cluster Mode (CDOT) mit zwei SVMs, die den XenServern per NFS Speicherplatz zur Verfügung stellen. Durch das NetApp-eigene RAID-DP können bis zu zwei Festplatten ausfallen, ohne dass es zu einem Datenverlust kommt. Erkennt das System eine Platte als defekt, wird dies vollautomatisch an NetApp kommuniziert; innerhalb von vier Stunden ist ein entsprechendes Ersatzteil geliefert. Die restliche Hardware innerhalb der FAS2552 ist ebenfalls redundant ausgelegt. Im Falle eines Defekts übernimmt automatisch die jeweils andere Node die Aufgaben ihres Partners - ohne dass Clients davon signifikant beeinträchtigt werden. Durch dieses Failover-System können außerdem auch Updates ohne Downtime eingespielt werden.
Verkabelung
Mit fünf Netzwerkkabeln und zwei Stromkabeln für jeden 1 HE-Server haben wir eine überdurchschnittlich hohe Kabeldichte. Ein Netzwerkkabel wird für iDRAC gebraucht, die anderen vier sind für die Storage-Anbindung und den normalen Datenverkehr, jeweils redundant ausgelegt. Wir verwenden hier eine Active/Passive-Konfiguration, die es uns ermöglicht, einen Server mit zwei unterschiedlichen Switches zu verbinden - ohne dass diese in einem Stack oder mit einem MLAG laufen müssen. Alles in allem sind 120 Netzwerkkabel verbaut.
Organisatorisch sind immer jeweils vier Server zu einem Block zusammengefasst. Von dort laufen die Kabel in Kabelmanagement-Leisten und verteilen sich weiter auf die Switches. Schematisch sieht das etwa so aus:
Bei den 40 Stromkabeln haben wir darauf geachtet, nur die rechte Seite des Racks zu verwenden - getrennt von den Netzwerkkabeln an der linken Seite, um Interferenzen zu verhindern. Die Zuordnung zu den PDUs ist außerdem so gewählt, dass bei Ausfall einer PDU zwei Switches ausfallen, die jeweils noch einen Redundanzpartner an der anderen PDU haben. Somit kann eine der beiden Stromzuleitungen ausfallen, ohne dass unser Betrieb beeinträchtigt wird.
Netzwerk
IP-Transit bekommen wir über ein kleines von unserem Carrier bereitgestelltes Transfernetz. Die öffentlichen IPs für unsere VMs kommen aus einem Pool, den wir als LIR direkt bei der RIPE selbst verwalten. Alle unsere VMs sind mit einem internen Netzwerk-Interface ausgestattet, das für die Administration und interne Dienste genutzt wird. Die meisten VMs haben darüber hinaus ein zweites Interface, über das sie öffentlich erreichbar sind. Dort werden dann nur die Dienste verfügbar gemacht, die dort auch gebraucht werden - dadurch verkleinert sich die "Angriffsfläche" der VM im Internet. Die diversen internen Netze sind über VLANs voneinander getrennt. Damit können wir Hardware-Verwaltung, größere Kunden und unsere eigenen Systeme voneinander abschotten.
Untereinander sind die Router und Switches wie folgt miteinander verbunden:
Die meisten Verbindungen sind als LAG ausgeführt; das schafft Redundanz und Flexibilität, falls mal etwas umverkabelt werden muss. Durch STP sind im regulären Betrieb die seitlich eingezeichneten Verbindungen zwischen sw-1 und sw-3 sowie zwischen sw-2 und sw-4 deaktiviert, um Schleifen zu verhindern. Fällt z.B. sw-2 aus, wird die Verbindung zwischen sw-1 und sw-3 automatisch aktiviert, sodass die drei verbleibenden Switches weiterhin untereinander und mit den Routern kommunizieren können.
Dokumentation
Als Atlassian-Partner pflegen wir unsere Dokumentation natürlich in Confluence. Für die Switchports verwenden wir einfache Tabellen, die die Port-Nummer, die ID-Nummer auf dem Kabel, sowie das Zielgerät und den Zielport beinhalten:
Findest du diese Themen interessant? Hast du Ideen, wie wir das alles noch viel besser machen können? Dann bewirb dich unter seibert.biz/jobs. 🙂
Weiterführende Infos
Das Bewerberportal von //SEIBERT/MEDIA
Unser Kulturchronik: Mitarbeiter plaudern aus dem Nähkästchen
FAQ für Bewerber
Mehr über die Creative-Commons-Lizenz erfahren
