Cluster aus 3 Servern

[Ostrich 10]

moin moin,

 

heute früh der Sprung ins kalte Wasser ... neues projekt, frage nach Realisierbarkeit:

 

Kunde möchte 40 Server virtualisieren, überwiegend Anwendungsserver irgendeiner betriebswirtschaftlichen Software, aber auch 1 SQl-Server und 1 Oracle 10.

 

Oberster gesichtspunkt, wie so häufig, Kosteneinsparung, daher fiel aus litzenzrechtlichen gründen auch die Wahl auf Hyper-V (klar, 3 datacenter Lizenzen sind günstiger als 40 standard-server)

 

zweiter Aspekt, verfügbarkeit: Es soll ein failover-Cluster realisiert werden

 

dritter Aspekt: Wiederherstellbarkeit: Nach einem Ausfall oder einem missluingenem Update soll einfah das letzte Snapshot zurückgespielt werden.

 

Infrastruktur:

- Es werden 3 Server DL385 R05P bereitgestellt, jeder hat 2 Quad-CPU's, 64GB RAM, 4 LAN-Interfaces + 1 ILO, dazu 2x150GB lokale Festplatte zum booten. Weiterhin: 1 HBA zur verbindung mit dem SAN

- Das SAN selbst ist neu angescha´fft worden, eine EVA 4400 mit 24x400GB, wovon 3TB schonmal für file/mailserver draufgegangen sind (alles raid5). Der Rest stünde für die VM'S zur verfügung.

 

Ich hab nmir nun Folgendes gedacht:

- 2 Datacenter Server als Core installieren mit hyper-V+Clusterrolle

- 1 Datacenter Server "Standard" mit hyper-V+Clusterrolle als Hot-Standby + zur verwalötung dazu gestellt

- 2 LUN's im SAn mit dem Cluster verheratet: 1 für die vm's selbst (Raid5) und eine für datenintensive vhd's (Raid1). Grösse: 1TB RAid5 und 0,5TB RAID1.

- Übername der 15 vorhandenen VM'S (Vitual Server 2005 R2) auf den Cluster

- VM's werden auf die Clusternodes (also am Ende die physikalischen hypervisor) nach Funktionen verteilt, also typischerweise einer für alle kafmännischen, einer für alle technischen, und der dritte als "failover" zum abfangen des ausfalls einer der beiden hypervisor

 

Seht ihr vom konzept her Verbesserungsbedarf? habt ihr ähnliches schon umsetzne dürfen, und wenn, wie waren die Erfahrungen, was waren die Stolpersteine, die man vermeiden kann?

 

Vieleicht klingt 40 Server auch einfach zu dramatisch, es sind überwiegend unbelastete server, die teilweise nur lizenen vorhalten+ausspucken, managementsoftware für irgendwas (cisco, watchguard, HP SIM usw) beinhalten und ansonsten 24 Stunden am tag idlen. Die einzigen Kracher sind der/die SQL- und Oracle-Server.

 

Hoffe auf gute Antworten+üwerde das projekt auch mal hier vorstellen, so es gelingt!

 

gruß

harald

[TruckerTom 10]

eines musst Du auf jeden Fall beachten, ich weiss nicht wie Hyper-V mit USB-Dongles umgehen kann, Du hast geschrieben, dass einige Server Lizenzen vorhalten.

Gruß

Thomas

[NilsK 2.789]

Moin,

 

ich hoffe mal, dass die Angaben, die du hier machst, nur einen Ausschnitt des Konzepts darstellen. Die Anforderungen sind nämlich alles andere als klar definiert, und auch die technischen Schlussfolgerungen sind nicht immer sinnvoll.

 

Kunde möchte 40 Server virtualisieren, überwiegend Anwendungsserver irgendeiner betriebswirtschaftlichen Software, aber auch 1 SQl-Server und 1 Oracle 10.

 

40 Server ist schon mal eine Hausnummer. Die geplanten Ressourcen geben das nicht ohne Weiteres her.

 

Oberster gesichtspunkt, wie so häufig, Kosteneinsparung, daher fiel aus litzenzrechtlichen gründen auch die Wahl auf Hyper-V (klar, 3 datacenter Lizenzen sind günstiger als 40 standard-server)

 

Naja. Ich hoffe, dass du so nicht beim Kunden argumentierst. Bei so einem Projekt gäbe es noch ein paar weitere Kriterien.

 

zweiter Aspekt, verfügbarkeit: Es soll ein failover-Cluster realisiert werden

 

Für welche Workloads? Alle?

 

dritter Aspekt: Wiederherstellbarkeit: Nach einem Ausfall oder einem missluingenem Update soll einfah das letzte Snapshot zurückgespielt werden.

 

Möööp. Schon verloren. Snapshots sind in einer produktiven Umgebung nicht supportet. Abgesehen davon, können Snapshots ganz erhebliche Probleme verursachen.

 

faq-o-matic.net Warum Images nicht als Datensicherung taugen

 

- Es werden 3 Server DL385 R05P bereitgestellt, jeder hat 2 Quad-CPU's, 64GB RAM, 4 LAN-Interfaces + 1 ILO, dazu 2x150GB lokale Festplatte zum booten. Weiterhin: 1 HBA zur verbindung mit dem SAN

 

Das sieht nicht gut aus.

 

Nur 1 HBA heißt: Single Point of Failure beim Zugriff aufs SAN. Dringend nachbessern.

 

Da du ja anscheinend die 40 VMs auf nur zwei Server verteilen willst, macht das statistisch 20 VMs pro Server. Das wird knapp: Zur Verfügung stehen "nur" 8 CPU-Cores. Man rechnet max. 3 "vCPUs" pro Core, macht also max. 24 vCPUs. Da du zwei Datenbankserver dabeihast und die Parent-Partition auch CPU braucht, wird das sehr eng. Dasselbe gilt fürs RAM: Bedenke, dass du bei Hyper-V den Arbeitsspeicher fest zuweisen musst. Reserven bleiben da keine!

 

Zudem: Im Fall des Failover hast du bis zu 40 VMs auf einem Server. Spätestens da wird ein Desaster auf den Kunden zukommen.

 

Das SAN selbst ist neu angescha´fft worden, eine EVA 4400 mit 24x400GB, wovon 3TB schonmal für file/mailserver draufgegangen sind (alles raid5). Der Rest stünde für die VM'S zur verfügung.

 

Der Knackpunkt ist der Zugriff. Nur ein HBA bedeutet a) einen möglichen Engpass und b) einen Ausfallpunkt.

 

Seht ihr vom konzept her Verbesserungsbedarf?

 

Ja, und zwar gewaltig. Ihr müsst dringend eine ausführliche Analyse- und Designphase vorausschicken. 40 VMs mal eben auf zwei Clusterknoten verteilt ist ein Problem. Du gibst ja selber an, dass mehrere VMs gar nicht produktionskritisch sind. Also würde ich die nicht mit den kritischen auf einen Cluster tun. Zudem sind, wie oben angemerkt, die Ressourcen vermutlich zu knapp, insbesondere wenn die DB-Server wirklich unter Last stehen.

 

Gruß, Nils

[jaksa 10]

Was mich noch stören würde, wäre das RAID-5.

Dir ist klar das Du im Falle eines Festplattenausfalls ohne Redundanz dar stehst. Kann Dein SAN kein RAID 6 (Vorausgesetzt Du kommst mit den Platten IOs zurecht)?

 

Gruß,

Jaksa

[phoenixcp 10]

Was mich noch stören würde, wäre das RAID-5.

Dir ist klar das Du im Falle eines Festplattenausfalls ohne Redundanz dar stehst.

 

Auch wenn ich eigentlich weniger aus der Hardwareecke komme, aber dem kann ich mich grade nicht so anschließen. Zumal es mittlerweile solche Techniken wie preemptive RAID 5 gibt. Aber selbst bei einem normalen RAID 5 kann dir immer noch ein Platte abpfeiffen. Neue rein, rebuild anhand der Parity bzw. der XOR der Datenbestandteile und am Ende ist wieder schick. Oder seh ich das falsch?

[Dr.Melzer 191]

Was mich noch stören würde, wäre das RAID-5.

Dir ist klar das Du im Falle eines Festplattenausfalls ohne Redundanz dar stehst.

 

Kannst du das bite erklären warum ein RAID5 keien Redundanz gegen den Ausfall eienr Festplatte hat...

[jaksa 10]

Ich muss zur meiner Schande gestehen dass mir preemptive RAID 5 nichts sagt, werde aber gleich googeln. Bei einem plattenausfall in einem RAID-5 System stehst Du bis zum Beenden des Rebuilds ohne Redundaz da. Das wäre mir persönlich in diesem Fall zu lange (und ich weiss nicht mal wie lange es hier dauert). In diesem Fall würde ich lieber noch eine Platte opfern und würde mit zwei Parity Platten arbeiten. Ich hatte tatsächlich den Fall bei dem in einem RAID-5 Verbund in kürzester Zeit zwei Platten ausgefallen sind, ergo Volume pfutsch, Backup vom Band einspielen, längere Ausfallzeit.

[phoenixcp 10]

Ich hatte tatsächlich den Fall bei dem in einem RAID-5 Verbund in kürzester Zeit zwei Platten ausgefallen sind, ergo Volume pfutsch, Backup vom Band einspielen, längere Ausfallzeit.

 

Genau dafür gibt es ja sowas wie preemptive RAID 5. ;)

 

Bei einem plattenausfall in einem RAID-5 System stehst Du bis zum Beenden des Rebuilds ohne Redundaz da.

Ok, dann war deine Formulierung vorhin ein wenig undeutlich. Deine Aussage vorhin kann man durchaus so verstehen, das RAID 5 überhaupt keine Fehlertoleranz für den Ausfall einer Platte bieten würde.

[NorbertFe 1.809]

Moin,

 

ich hoffe mal, dass die Angaben, die du hier machst, nur einen Ausschnitt des Konzepts darstellen. Die Anforderungen sind nämlich alles andere als klar definiert, und auch die technischen Schlussfolgerungen sind nicht immer sinnvoll.

 

Wirkliche Anforderungen sind eigentlich auch nicht zu erkennen.

"Kunde möchte 40 Server virtualisieren, überwiegend Anwendungsserver irgendeiner betriebswirtschaftlichen Software, aber auch 1 SQl-Server und 1 Oracle 10."

 

Wenn man 40 Server virtualisieren will, kommt dein Hardwareplanung ins Spiel, aber auch die Frage, sollen 40 Server virtualisiert werden, die jetzt in Hardwareform existieren? Denn wenn ich das mal betrachte, erscheint mir persönlich der Einsatz von 3 (dicken) Servern etwas knapp. Oder bleiben bestehende Server weiterhin in Betrieb? Fragen über Fragen. Die meiner Meinung nach weit über das sinnvoll Mögliche in einem Forum hinausgehen.

 

Oberster gesichtspunkt, wie so häufig, Kosteneinsparung, daher fiel aus litzenzrechtlichen gründen auch die Wahl auf Hyper-V

 

Die Frage wäre ja, ob eine Komplettvirtualisierun überhaupt kostengünstiger ist. Das müßte man im Zweifel ja erstmal mit Zahlen belegen. Dazu gehört meiner Meinung nach auch die Verfügbarkeit, Managementfähigkeit usw. usf.

 

 

Möööp. Schon verloren. Snapshots sind in einer produktiven Umgebung nicht supportet. Abgesehen davon, können Snapshots ganz erhebliche Probleme verursachen.

 

Kommt ja drauf an, welcher Art die Snapshots sind. ;)

 

 

Zudem: Im Fall des Failover hast du bis zu 40 VMs auf einem Server. Spätestens da wird ein Desaster auf den Kunden zukommen.

 

Dazu ist ja der 3. Knoten vorhanden. Wobei eine komplett virtualisierte Umgebung ohne physikalischen DC, zumindest bei mir ein wenig flaues GEfühl verursacht. ;)

 

Bye

Norbert

[TruckerTom 10]

Wobei eine komplett virtualisierte Umgebung ohne physikalischen DC, zumindest bei mir ein wenig flaues GEfühl verursacht. ;)

 

Bye

Norbert

 

wieso das Norbert?

 

Gruß

Thomas

[NorbertFe 1.809]

wieso das Norbert?

 

Gruß

Thomas

 

Weils bis 2008 ein Domainaccount war, der als Clusterservice verwendet wurde.

Description of the failover cluster security model in Windows Server 2008

 

Wie gesagt, ist eher ein Gefühl. :)

 

Bye

Norbert

[Ostrich 10]

Guten Morgen zusammen,

 

und erstmal bin ich überwältigt von den vielen. sehr qualifizierten und ausführlichen Antworten, ganz speiell an NilsK!

 

Natürlich wird nicht komplett virtualisiert, 2 DC'S, 2 Exchange, 1-2 Filer und noch eine handvoll weiterer Server werden nicht Bestandteil des Clusters. es geht also, abgesehen von 1-2 SQL-Servern und 1 Oracle um Server, die hochverfügbar sein müssen, aber keine nenenswerte I/O oder CPU-Last haben. Server, die vor kurzem noch auf einem BNC-Netz und einem Pentium Pro mit 128MB gelaufen sind ... dort ist schon im Vorfeld mächtig ausgesiebt worden!

 

Zudem: Kunde hat 12-15 Server (oder besser: Installatationen!) auf einem Virtual Server 2005 R2 (1 Dualcore Opteron, 16GB RAM, davon 5 GB frei, CPU-last: 5-35%, Peak 50%), der mit gehostet werden soll.

 

Das Thema Last würde ich hier zunächst mal abschliessen, kommen wir zum Konzept:

 

RAID5 doer RAID1: in dem EVA-SAN kommen (neben einem 4Stunden Wartungsvertrag bei Ausfall von Platten) 2 Hot-Standby Platten zum Einsatz, die beim Ausfall einzelner Platten dann einspringen. Alerting ist konfiguriert. Raid-Level ist daher aus meiner Sicht daher nur für I/O wichtig, RAID1 erzielt eben 30% bessere IO's, wenn man HP da glauben darf.

 

Clusternode: 2 Server produktiv, 1 Server hsb bedeutet ja nicht, dass der hsb beide ausgefallene nodes ersetzen kann, sondern nur einen. auch hier: Wartungsvertrag, reaktion bis next business day, das sollte nach meinem ermessen reichen!

 

UND: bei komplettausfall des SANs sollen die produktionswichtigen VM's auf einem externen Array liegen (iSCSI, räumlich getrennt), und manuell anstartbar sein. Es geht hier um wirkliche PRODUKTION und nicht darum, Lieferscheine zu drucken oder eine mailsystem PRODUKTIv zu halten, da rollen ganz einfach Steine vom Band, ohne den Server steht das BAnd eben :-)

Damit zusamenhängend: Thema Snapshot: Klar, ein Snapshot allein reicht nicht! Daher sollen die VHD's und die Konfig+Snapshot-verzeichniss zyklisch nach extern (iscsi?) wegkopiert werden. Spricht da etwas dagegen?

 

Thema 2. HBA: Fällt der HBA aus, fällt der Clusternode aus, das ist klar! Am nächsten tag kommt der HP-techniker und tauscht den HBA, dann geht der Clusternode wieder produktiv. Wo liegt dennder benefit, oder, welches Risiko umgehe ich mit 2 HBA's?

 

mein HBA hängt an einem FC-Switch, an dem 2 Controller für das SAN mit dran hängen. macht man es konsequent, braucht man 2 Switche, und hängt dann an jeden einen Controller, und bindet an jeden Switch ein seperates HBA an. Aber, wer soll das bezahlen? Der Mittelstand sicher nicht ... für die ist ein FC-SAN schon eine Hammerinvestition gewesen! Daher, auch hier, ein Kompromiss.

[phoenixcp 10]

Moin

 

Ich muss mich grade nochmal zu deiner Reaktion äussern:

1.

in dem EVA-SAN kommen (neben einem 4Stunden Wartungsvertrag bei Ausfall von Platten) 2 Hot-Standby Platten zum Einsatz,

Diese zwei Platten werden pro RAID-Array vorgehalten oder allgemein über die gesamte EVA?

 

2.

2 Server produktiv, 1 Server hsb bedeutet ja nicht, dass der hsb beide ausgefallene nodes ersetzen kann, sondern nur einen. auch hier: Wartungsvertrag, reaktion bis next business day, das sollte nach meinem ermessen reichen!

Hm, wenn ihr wirklich Produktion fahrt wie du schreibst, stellt sich mir die Frage ob Next-Business-Day wirklich ausreichend ist. Denn was machst du im absoluten Worst-Case wenn deine zwei Nodes ausfallen und du nur einen HSB hast? Und dann lass den mal noch was weg haben. Klar, ist sehr konstruiert, aber du weißt ja, Pferde und Apotheken. ;)

 

3.

bei komplettausfall des SANs sollen die produktionswichtigen VM's auf einem externen Array liegen (iSCSI, räumlich getrennt), und manuell anstartbar sein

Wie muss man sich das vorstellen? Im Normalfall laufen die VMs aus dem SAN, wenn das weg ist, dann willst du umschalten auf ein externes Array. Oder hab ich das falsch verstanden? Falls ich das richtig verstanden habe, stellt sich die Frage nach der Synchronisation der VMs zwischen SAN und externem Array.

 

welches Risiko umgehe ich mit 2 HBA's?

Ganz klar, der Node fällt nicht aus, du kannst die ganze Thematik ein wenig entzerren, siehe auch mein Kommentar unter 2.

 

mein HBA hängt an einem FC-Switch, an dem 2 Controller für das SAN mit dran hängen. macht man es konsequent, braucht man 2 Switche, und hängt dann an jeden einen Controller, und bindet an jeden Switch ein seperates HBA an. Aber, wer soll das bezahlen? Der Mittelstand sicher nicht ... für die ist ein FC-SAN schon eine Hammerinvestition gewesen! Daher, auch hier, ein Kompromiss.

Hm, meine Meinung: Klar, richtige Lösungen sind auch mit Kosten verbunden, aber wer das eine will, muss das andere lieben.

 

Gruß

Carsten

[thorsatten 10]

Moin

 

Ich muss mich grade nochmal zu deiner Reaktion äussern:

1.

 

Diese zwei Platten werden pro RAID-Array vorgehalten oder allgemein über die gesamte EVA?

 

 

Die Hot-Standby Platten oder Hot-Spare Platten der EVA sind normalerweise entweder gesamt eingesetzt oder werden einem Diskpool zugewiesen.

Die RAID 5 und RAID 1 Verbünde, die hier genannt wurden sind virtuelle Arrays.

 

Dazu dann gleich eine Frage von mir: Für die vRAIDs, welche Ausfallsicherheit habt ihr da geplant? Einfach oder doppelt?

 

Dann wurde auch gesagt, das ihr da 400GB Disks einsetzen wollt. Warum? Soweit ich weiss, sind die 400GB Fibre Channel Disks bei HP nur 10k Disks, was bei der EVA ja leider ein deutlicher Performanceverlust ist.

 

Dann der Punkt mit dem einen HBA pro Server, das ist im SAN Umfeld ein dickes No-Go wenn man von Hochverfügbarkeit redet. Sobald es irgendein Problem am HBA, Kabel oder Port der EVA gibt ist deine SAN-Anbindung ausgefallen und es erfolgt ein Clusterschwenk, der unnötig ist. Durch den 2. HBA im Server erhöhst du die Verfügbarkeit deutlich, da bei einem Problem auf der ersten Verbindung erstmal nur ein interner Schwenk auf den 2. HBA erfolgt.

 

An einem 2. HBA pro Server und einem 2. Switch führt meiner Meinung nach kein Weg vorbei wenn man eine Lösung haben will, die ausreichend verfügbar sein soll! Diese Singel-HBA Singel-Switch Lösung ist ein riesen Singel Point of Failure Scenario, das dir jeder Mitbewerber in der Luft zerreisst und dich bei deinem Kunden zienlich **** dastehen lässt.

 

Eine Alternative bzgl der EVA wäre eine MSA 2000fc, wenn der Kunde unbedingt HP haben will oder wenn was anderes sein darf die DS3400 von IBM. Diese beiden Systeme sind deutlich günstiger als die EVA. Bei der DS3400 weiss ich auch, das die ähnlich gute Performancewerte liefert wie die kleinen Midrangesysteme von HP (EVA4400) oder IBM (DS4700) bei gleichem Plattenausbau.

Und ich denke mal, das die MSA ähnlich gut performen sollte, wie die EVA mit den 10k Platten drin.

 

Gruß,

Thorsten

[Ostrich 10]

Mensch leute, ihr gebts mir aber richtig :-( ich komm mir ja so was von disqualifiziert in dieser Expertenrunde hier vor, das glaubt ihr gar nicht! Aber der Reihe nach:

 

@thorsatten:

- vraid:

24x400GB FC HDD, davon 2 HSB

 

Die HSB werden nach meinem Verständniss automatisch verwendet, wenn eine der anderen 22 Platten ausfällt. Alle LUN's erstrecken sich über alle Platten (vraid).

 

Wodurch unterscheidet sich denn einfache von doppelter Ausfallsicherheit?

 

- das mit den 2 HBA's je Node werde ich vorschlagen, Argumentation passt soweit, es muss halt alles irgendwie auch ins Budget passen ...

 

- 400GB 10k Disks in "grossen" Storagegroups performen ausreichend schnell, wobei gross wohl Definitionssache ist. 24 Platten sind eher klein. I/O-last war dennoch bisher kein thema, wird aber sicher noch mal Thema werden!

 

Danke Dir, Thorsten, aber schonmal sehr!

 

@phoenixcp:

1) über die gesamte Storagegroup (24x400GB)

2) Wir hatten in den Werken (6 Werke, 4 in Europa+2 in Asien),sonst FT-Server von stratus, welche in Hardware ausfallsicher sind. Stimmt! Weist du was ausgefallen ist?

- der Plattenplatz ist ausgegangen (Softwarefehler)

- der Strom ist länger ausgefallen, als die APC und der nachgeschaltete Diesel Notbetrie aufrecht erhalten konnten

- 2x ist ein Cisco Switch defekt gegangen

Ich will versuchen, das Restrisiko über ein "startfähiges Image" (um snapshot nicht wieder zu bemühen ..) des SQL-Servers im WOrst-case Szenario abzufangen.

3) Siehe Kommentar an Thorsten, wird verargumentiert + Entscheidung dahingehend abgeändert.

 

Danke auch Dir!

 

@all: keiner mehr nen Kommentar zum Hyper-V Cluster, nur zum SAN?