Cluster oder nicht.... Frage dazu...

[Peter G. 10]

Hallo!

 

Vorgeschichte: ich soll den "Service" für einen Cluster übernehmen, da die Servicekosten mit 120.000 € p.a unserer Firma einfach zuviel geworden sind (ist das ein realer Betrag eigentlich? - im Falle einer Störung kommt eben der Techniker und sieht halt zu daß der Cluster läuft...).

 

Auf dem Cluster läuft eine SQL Datenbank, sonst nichts. Mittlerweile gehen wir davon aus, daß es bei einem Ausfall nicht weiter tragisch wäre wenn die Datenbank für sagen wir mal ein paar Stunden stehen bleibt. Die Daten für die Datenbank kommen von anderen Servern im Netz, die im Falle einer Störung des Clusters einfach die Daten erstmal lokal halten können.

 

Meine Frage jetzt: ist es sinvoll überhaupt ein Cluster einzusetzen? Bevor ich mich damit auseinandersetze, frage ich eben mal... :-)

 

Meine Idee wäre: zwei absolut identische PCs hinzustellen (schon vorhanden....) und im Falles eines Defektes an den einem PC einfach die Platten (welche sowieso schon im Raid arbeiten) in den anderen PC stecken, einschalten und gut ist... :-) so die Theorie... :cool:

 

Hört sich nicht sooo profesionell an, aber bedeutet für mich den Weg des geringsten Widerstandes, da ich ja noch andere Sachen zu tun habe.. :wink2: Netzwerktechnik ist mir vertraut, bin aber mehr der Coder für Prozessleitsysteme.... und Supporter für die DAUs.. :D

 

Tschau & Danke für Anregungen...

 

Peter

[frieda 10]

Hi Peter,

 

Frage vorab: steht da schon ein Cluster? Und was für ein System? Oder versteh ich das grad falsch. Musst du ein laufendes betreuen oder ein Neues bauen?

 

Nächste Frage. Servicekosten von 120,000 €, was ist denn da alles drin? Das klingt nämlich nach richtig viel. Wir haben auch einen Cluster, aber ich wüsste nicht, dass wir so hohe Kosten haben.....

 

Das mit den 2 PCs ist wirklich nicht sehr professionel, aber es hängt doch davon ab wie wichtig dieses Sql System ist.

 

bis gleich

[Peter G. 10]

Hallo Frieda! :-)

 

Also: bezahlt wird mit 120.000 € die Installation und Wartung des schon laufenden Clusters. Dazu kommen monatlich 2000€ für die Bereitschaft des Technikers (1 Stunde Reaktionszeit...).

 

Das System ist ein WIN2K AServer, irgendetwas mit 19 Zoll und ein externes Netraid für beide Rechner.

 

Der Cluster läuft schon, der Vertrag läuft demnächst aus und für das Geld könnten wir wohl locker einen neuen Mann einstellen, der sich darum kümmern würde (und auch sicherlich viele andere Arbeit in der Fa. übernehmen könnte...). Bis dahin aber, habe ich es an der Backe....

 

Die Verfügbarkeit? Naja, wie ich schon erwähnt habe, mittlerweile nicht so wichtig, wenn die SQL mal ein paar Stunden nicht läuft, wäre es nicht weiter tragisch, höchstens unangenehm...

 

Tschau & Danke Peter

[Norek 10]

Die Frage die sich mir hierbei stellt, was ist für Euch sinnvoller im Falle einer Störung und unter welchem SLA Aspekt betrachtet ihr den SQL Server?

 

Folgendes Szenario.

 

1)

Du hast 2 identische Systeme. SQL fällt aus, sagen wir mal an einem Feiertag "es sind meist die Feiertage, sonst würde es ja kein Spass machen ^^ ). Ein Administrator fährt raus und baut von Server A die festplatten in den Server B.

 

2)

Du hast einen Cluster. Node 1 fällt aufgrund einer Störung aus (Festplattendefekt genau auf dem Volume wo die Datenbank gehostet wird). Da ihr aber für dieses Szenario vorgesorgt habt, sind die Volumes auf Hot Spare Platten im SAN oder kleineren Plattensystemen eingebaut. Die Platte fällt aus, aber der Server kann weiter laufen und steht weiterhin zur Verfügung. Dann eines schönen Feiertags mal wieder, wie sollte es auch anders sein, fällt der Dienst auf Node 1 aus. Der Clusterservice erkennt dies, führt einen Failover durch und Node 2 übernimmt binnen weniger Minuten den SQL Dienst. Dies alles ohne Administrativen Aufwand. Der fehlerhafte Dienst kann am folgenden Arbeitstag auf Node 1 erörtert werden, ohne das die Benutzer etwas davon merken.

 

 

Nun entscheide selbst was wichtiger ist. Verfügbarkeit und automatisierte ausgrenzender Ausfälle über einen längeren Zeitraum, oder ein Techniker der sich ständig auf Abruf bei Störfällen einstellt. ;)

 

is it your Choice.

[Peter G. 10]

Original geschrieben von Norek

Die Frage die sich mir hierbei stellt, was ist für Euch sinnvoller im Falle einer Störung und unter welchem SLA Aspekt betrachtet ihr den SQL Server?

 

Folgendes Szenario.

 

1)

Du hast 2 identische Systeme. SQL fällt aus, sagen wir mal an einem Feiertag "es sind meist die Feiertage, sonst würde es ja kein Spass machen ^^ ). Ein Administrator fährt raus und baut von Server A die festplatten in den Server B.

 

2)

Du hast einen Cluster. Node 1 fällt aufgrund einer Störung aus (Festplattendefekt genau auf dem Volume wo die Datenbank gehostet wird). Da ihr aber für dieses Szenario vorgesorgt habt, sind die Volumes auf Hot Spare Platten im SAN oder kleineren Plattensystemen eingebaut. Die Platte fällt aus, aber der Server kann weiter laufen und steht weiterhin zur Verfügung. Dann eines schönen Feiertags mal wieder, wie sollte es auch anders sein, fällt der Dienst auf Node 1 aus. Der Clusterservice erkennt dies, führt einen Failover durch und Node 2 übernimmt binnen weniger Minuten den SQL Dienst. Dies alles ohne Administrativen Aufwand. Der fehlerhafte Dienst kann am folgenden Arbeitstag auf Node 1 erörtert werden, ohne das die Benutzer etwas davon merken.

 

 

Nun entscheide selbst was wichtiger ist. Verfügbarkeit und automatisierte ausgrenzender Ausfälle über einen längeren Zeitraum, oder ein Techniker der sich ständig auf Abruf bei Störfällen einstellt. ;)

 

is it your Choice.

 

Hai!

 

Ich habe sowieso Bereitschaft, daher macht es für mich keinen grossen Unterschied (wir wechseln uns mit ein paar anderen Kolegen hier ab, jeder muss mal ca. alle 7 Wochen daran glauben - für eine Woche...)

Es geht auch primär um die Kostenreduzierung und wenn wir den Cluster übernehmen, dann soll es bei einer Störung so einfach sein wie nur möglich - gerade im Falle eines GAUs - PC tot.

 

So sollen alle Kollegen in der Lage sein einfach den anderen PC hochzufahren und gut ist. Wir sind mehr auf Leitsysteme eingestellt, daher eben so einfach wie möglich...

 

Tschau Peter

[frieda 10]

Hi Peter,

 

Norek hat es ja gut beschrieben. Ich stimme ihm zu. ;-)

 

Ich möchte noch hinzufügen, dass ich persönlich das Cluster behalten würde, weil es ja bereits läuft und mit den 2000 €, die jetzt "über" wären kann man ja jemand einstellen oder dich fortbilden lassen oder so.

 

Wenn das Cluster aber schlecht lief und ihr unzufrieden seid, dann könnte man über was Neues nachdenken.

 

grüsse.

[frieda 10]

Nachtrag, du warst etwas schneller ;-)

 

Ein laufender Cluster ist nicht so schwer zu betreuen, wenn er richtig konfiguriert ist. Und Knoten umschalten ist nun wirklich einfach.

 

Und bevor ich eine komplett neues System aufbaue, und mich mit Migration usw. beschäftigen muss würd ich doch das was jetzt da ist vorziehen.

[Norek 10]

Original geschrieben von Peter G.

Hai!

 

Ich habe sowieso Bereitschaft, daher macht es für mich keinen grossen Unterschied (wir wechseln uns mit ein paar anderen Kolegen hier ab, jeder muss mal ca. alle 7 Wochen daran glauben - für eine Woche...)

Es geht auch primär um die Kostenreduzierung und wenn wir den Cluster übernehmen, dann soll es bei einer Störung so einfach sein wie nur möglich - gerade im Falle eines GAUs - PC tot.

 

So sollen alle Kollegen in der Lage sein einfach den anderen PC hochzufahren und gut ist. Wir sind mehr auf Leitsysteme eingestellt, daher eben so einfach wie möglich...

 

Tschau Peter

 

Hi Peter,

 

Du solltest Dir eines Bewusst machen. Sollte einmal ein Betriebssystemfehler vorliegen, dann ist mit Platten umtauschen und auf dem anderen Server mal eben hochfahren eben nicht gleich alles wieder in Butter. Dann fällt der Server aus und das für mehrere Stunden wenn nicht Tage, falls kein entsprechendes Know how vorhanden ist. Dann seid Ihr mit Fehleranalyse und Behebung beschäftigt und die Datenbank steht.

 

Bei einem Cluster, wird der Failover iniziiert und am fehlerhaft laufendem Knoten kann gearbeitet werden, während der SQL weiterhin zur Verfügung steht.

[frieda 10]

@ norek

 

*zustimm* , du kannst es besser ausdrücken... ;-)

[Norek 10]

Original geschrieben von frieda

@ norek

 

*zustimm* , du kannst es besser ausdrücken... ;-)

 

Reine Erfahrungswerte Frieda ;)

[Peter G. 10]

@Frieda & Norek: Dankeschön für eure Mühe, ihr habt mich schonmal weitergebracht.. :)

 

Der Cluster läuft zur Zeit einwandfrei. Die Grundidee, die ich hatte war die Datenplatten (Raid) im Falle eines Fehlers in den anderen Rechner zu stöpseln und einschalten.... Backups laufen sowieso und mit einer Reaktionszeit von ein paar Stunden wäre das ok. -> Zu naive Vorstellung?

 

Das Problem sind eben diese 144.000€ jährlich, die wir für die Clusterbetreuung ausgeben, irgendwie zu reduzieren und im Moment eben nicht die Manpower haben jemanden aus den eigenen Reihen dafür ausbilden zu lassen und aus Firmenpolitischen Gründen auch zur Zeit nicht die Möglichkeit jemanden zusätzlich einzustellen (Besitzerwechsel..., mal wieder, alles ist eingefroren...).

 

Ich werde vorschlagen den Cluster zu verwenden, den Servicevertrag zu kündigen und uns eben ausbilden zu lassen.

Für den Anfang würde mir ein wenig Doku reichen, am besten in Deutsch - habt ihr vielleicht irgendwelche Empfehlungen?

 

Trotzdem nochmal die Frage: sind 144.000€ im Jahr realistisch (Installation - einmal geschehen, Wartung - wird remote erledigt, 24/7 Bereitschaft)? Ursprünglich wurde sogar nachgedacht EDS (....) dafür zu nehmen, die würden angeblich sogar das doppelte dafür verlangen, ich kann es mir einfach nicht vorstellen. Es ist doch nur ein Cluster...

 

Durch die hohe Summe waren wir natürlich ein wenig "eingeschüchtert" und dachten "wow, ein Cluster, da muss wohl sehr viel Know How drinnsein, bzw. es ist wohl seeeehr aufwändig soetwas zu betreuen, Hexerei".

Jetzt muss ich wohl die Hexerei selber in die Hand nehmen. Bin gespannt. :rolleyes:

 

Einen schönen Tag noch :cool:

 

Tschau & Danke Peter

[Norek 10]

Hehe, das mit EDS ist mir bekannt. Ist ja mein Arbeitgeber. ;)

 

 

Grundsätzlich zu den Kosten kann ich nicht viel sagen, da ich nicht die Einzelheiten zur Berechnung des SLA's kenne.

 

Eines kann ich Dir auf jeden Fall mitgeben. Dokus zum Thema Clustering unter W2k gibt es zu Hauf bei MS in der Technet Knowledge Base. Einfach mal Cluster als Stichwort eingeben. ;)

 

Den Vertrag einfach so zu kündigen müsste man abwegen, ob man imstande ist den Cluster grundlegend zu administrieren und nur im schwerwiegendem Störungsfall einen Clusterspezialisten einzukaufen.

[fritzo 10]

Hi,

 

ich hab mal versucht, die beiden Lösungen gegenüber zu stellen:

 

2 PCs Cold Standby

--------------------------------

-einfache Administration

-unanfällige Technik

-geringe Betriebskosten

 

-niedrige Verfügbarkeit

-manueller Aufwand im Störungsfall

 

Clusterlösung 2 Nodes

-------------------------------------

-hohe Verfügbarkeit

-niedriger Aufwand im Störungsfall, wenn nur ein Node betroffen

 

-komplexe Administration

-anfälligere Technik

-hohe Betriebs/Wartungskosten

 

Wenn Ihr keine hohen SLA habt und eine einfache, kostensparende Lösung wollt, würde ich Cold Standby nehmen. Da Du die Kostenersparnis als Ziel erwähntest, würde ich wiederum zu Cold Standby raten - allerdings ist dabei ja noch zu berücksichtigen, daß die Hardware ja schon da steht.

 

Ansonsten ist ein Cluster im Fehlerfall sehr angenehm, wenn nur ein Node von Fehlern betroffen ist. Ist aber der Cluster selbst oder die DB betroffen, die auf der Clusterressource liegt, sieht es anders aus - dann ist der Aufwand im Fehlerfall wiederum hoch.

 

Hoffe, das hilft ein bißchen.

 

Grüße,

Fritz