Zwei Neuzugänge: clusterserver01 und clusterserver02

Für ein größeres Hostingprojekt eines Kunden mussten wir einen HyperV-Cluster aus zwei Servern aufbauen.

Ein weiteres Requirement des Kunden war, dass die Server getrennt voneinander aufgestellt werden, wobei keine volle Georedundanz nötig ist, sondern verschiedene Serverschränke im selben Rechenzentrum ausreichend sind.

Eine kurze Klärung mit Hetzner ergab, dass gegen eine Gebühr von 100 € beliebige Kabel zwischen eigenen Serverschränken im selben Rechenzentrum gezogen werden können – als nächstes stand also die Entscheidung Fibre vs. 10GbE an. Da die Kabellänge sich im Bereich unter 20 m bewegt, und ein nach CAT 7 (abgesehen vom Stecker ;-)) abgeschirmtes Kupferkabel verwendet werden kann, fiel die Entscheidung recht schnell auf 10 GBit/s Ethernet – die Netzwerkkarten (Hersteller: Intel) sind einfach günstiger, als die Fibre-Hardware.

In Ermangelung eines 10 GBit/s Ethernet fähigen Switches (und angesichts der Mondpreise für selbige) haben wir uns für ein anderes Setup entschieden: Es wurden zwei Kabel zwischen den beiden Serverschränken gezogen, eines davon verbindet direkt die beiden 10 GbE Netzwerkkarten der neuen Server, das andere verbindet ganz klassisch die beiden 1-Gigabit/s-Switches, die wir bei sinkenden Preisen der 10 GbE-Hardware immer noch austauschen können.

Beide Serverschränke genießen das selbe Niveau an technischer und Sicherheitsausstattung: nach Zugang ins Rechenzentrum per Dongle muss der einzelne Serverschrank jeweils vorne und hinten per 6-stelligem Code geöffnet werden. Die Stromversorgung ist redundant (riesen Vorteil: Zusammen mit redundanten Netzteilen, die immer auf Stromkreise A und B aufgeteilt werden, laufen die Server sogar bei Ausfall eines Stromkreises weiter), der Uplink ist ein einzelner 1 GBit/s Ethernet Uplink.

… Doch nun zu den Servern:

Da durchaus CPU-Lastige Anwendungen (Stichwort: HiRes-PDF-Rendering für den Druck) auf den Servern laufen, hieß es beim Prozessor diesmal klotzen nicht kleckern, und es wurden folgende Spezifikationen gewählt:

SuperMicro 2 HE LFF Barebone mit 2 Prozessor-Bays und redundantem Netzteil
1 * Intel Xeon E5-2690 V2
128 GB Arbeitsspeicher (8 * 16 GB DDR-1600 ECC Reg, Dual Rank, LowProfile)
1 * LSI 9271-8i + CacheVault
2 * 400 GB Intel DC S3700 im RAID1 als Systemplatte für den Virtualisierungs-Host
4 * 400 GB Intel DC S3700 im RAID5 als schneller Storage für die VM-Systemplatten sowie MSSQL-Daten, PDF-Renderserver, etc.
6 * 4 TB SAS 7.200 rpm Festplatte im RAID5 als Massenspeicher für die Druckdaten & Backups

Dieser Server wurde in exakt der selben Spezifikation zwei mal angeschafft, um eine vollwertige Failover-Cloud mit HyperV aufzubauen.

Ein externer SAN wurde aus Kostengründen nicht verwendet – statt dessen läuft eine ebenfals gefailoverte Windows-VM auf den Servern, die jeweils den SSD- und HDD-Array gemountet hat, und diesen als SMB-Freigabe für alle anderen VMs zur Verfügung stellt.

Hinzu kommt ein aufwändiges Monitoring der Hosts, aller VMs, sowie einzelner Web Applications innerhalb der VMs per icinga.

In diesem Fall hat der Kunde den Wunsch geäußert, selber auch direkt auf den icinga-Verteilern zu stehen, um bei Störungen direkt informiert zu werden. Eigentlich eine unpopuläre Anfrage, sind wir so doch nicht in der Lage, Probleme zu beheben bevor sie der Kunde bemerkt – aber wegen des engen Vertrauensverhältnisses zum Kunden haben wir diese Anfrage in diesem Fall gerne bejaht.