[Makru]

Hallo,

ich habe als recht Unwissender zu diesem Thema den Job gefasst, für einen Windows 2012 R2 Server Hardwareprotection zu evaluieren. Es geht im Prinzip nur darum, dass wenn eine Maschine den Geist aufgibt, die Applikationen weiterlaufen.

Dabei bin ich auf das Windows Server Failover Cluster-aktiv/passiv gestossen.
Wenn ich es richtig verstanden habe, müssen die Applikationen die dort laufen sollen speziell clusterfähig sein, oder?
Oder ist es doch so, wie ich urprünglich dachte, dass im Prinzip nur ein virtueller Server sichtbar ist, auf dem nur eine Intanz der Applikationen läuft?

Merci im Voraus für eure Antwort.

Freundliche Grüsse
Makru

[RalphS]

Ein Cluster *ist* eine "virtuelle" Maschine (aber keine VM!). Man hat letztlich zwei (oder mehr) Rechner, die logisch zu einem zusammengefaßt werden. Mit diesem "logischen" Rechner kann man dann (mehr oder weniger) genauso wie mit einem "richtigen" Rechner arbeiten - ein paar Dinge gehen damit besser, ein paar andere Dinge schlechter.

Failover-Clustering *erfordert* clusterfähige Software. Der *Cluster* muß den Softwarezustand halten, nicht (irgendeiner) der Clusterknoten, sodaß wenn der aktive Knoten ausfällt, auch der Status übertragen werden kann (und es bestünde keine Möglichkeit, "weiter"zumachen).


Daher die alles entscheidende Frage: WAS soll der Cluster bereitstellen?

NB. Windows-basierte Cluster (NLB und FO) dürfen NICHT über Windows Update aktualisiert werden. Das muß man über den Clustermanager machen. Sonst fällt der Cluster auseinander, wenn plötzlich 3 von 4 Rechnern von Updates wegen neustarten.

-- Referenz:
Failover-Clustering on Windows Server 2012R2 (TechNet)

Dieser Beitrag wurde von RalphS bearbeitet: 29. August 2014 - 19:13

[Future010]

Ich musste ähnliches letztens selbst erstellen, kannst mich gerne per PN anschreiben. Habe
das ganze gut dokumentiert als PDF

Wenns gut läuft veröffentliche ich noch ein HowTo diesbezüglich.

Dieser Beitrag wurde von Future010 bearbeitet: 31. August 2014 - 20:33

[scar1]

Der Trend geht wohl in die Richtung, dass eine ganze Maschine geschwenkt wird. Dazu würdest du einen Hyper-V Failover Cluster aufsetzen.
Seit 2012 ist dies z.B. Microsofts Empfehlung für Printdienste.

Das schützt dich gegen einen Ausfall der Clusterknoten. Allerdings ist dein Dienst dann trotzdem nicht verfügbar während du den virtuellen Server z.B. nach einem Patch rebooten musst.

[RalphS]

Eh, ist mir bisher immer noch nicht klar geworden, warum MS da so dermaßen ihren Hyper-V anschieben wollen. Clusterknoten *dürfen* ausfallen. Dafür sind sie Clusterknoten geworden. Wenn man sich vor "Clusterknoten-Ausfall" schützt und dafür aber den Dienst offline kriegt, dann macht man da was ganz falsch.

Klar kann man das auch mit Hyper-V-Failover bauen, braucht dann aber auch mehrere (Host)Maschinen dazu, sonst bringt es nix. Und wenn man die Hostmaschinen hat, kann man da eigentlich auch gleich einen "normalen" Cluster bauen (finde ich).

Wenn man natürlich ein riesiges RZ hat und System Center einsetzt, sieht das schon wieder ganz anders aus. Dann bietet die Plattform eine ganze Menge mehr Möglichkeiten als "echte", "physische" Cluster.

Dieser Beitrag wurde von RalphS bearbeitet: 03. September 2014 - 15:47

[shiversc]

Guten Abend... Hobby Admins

Ich bin der Meinung hier wird viel zu viel vermengt!

Das Server 2012 R2 Cluster soll welche Software höher verfügbar machen?

Die Clients sind welche Windows-Generation?

Gibt es ein gemeinsames Storage für die Server?

[Makru]

Merci für eure Antworten.

Eigentlich geht es um Applikationen, die normalerweise auf einem Single Windowsserver als Master an einem Standort laufen und an einem 2ten als Slave. Fällt nun der Master aus, wird der Slave automatisch zum Master, fällt der Slve aus, gibt es einen Alarm.
Die Datenbanken, MS-SQL, werden zwischen Master und Slave repliziert. Damit sind Daten, Hard-und Software bei Ausfall geschützt.

Ein Kunde fragt aber nun nach Hardwareprotection pro Standort an und findet das Wort Cluster ganz toll.

Mit Hilfe von Google und euren Antworten denke ich verstanden zu haben, das unsere eigenen, nicht clusterfähigen Applikationen mit dem Windows Server Failover Cluster nicht funktionieren werden. Meine erste Idee war halt, ein Windows-Failover-Cluster z.B. in eine "Cluster in a box" Hardware laufen zu lassen.

Gruss
Mathias

[RalphS]

MSSQL läßt sich clustern, aber nicht über Windows. MSSQL kann (und muß) das selber machen.

[Sturmovik]

Nicht ganz richtig, Ralph.
Wenn MSSQL geclustert wird, müssen sowohl Betrübssystem, als auch die SQL-Instanz geclustert werden. Einen Windowscluster brauchste da schon als Basis.

Bei dem Failovercluster fallen mir spontan zwei gewaltige Nachteile ein.
Einerseits nicht clustertaugliche Software, andererseits füttert man nur unnötig viel Hardware durch, die nur darauf wartet, gebraucht zu werden.

ICh würde hier eher auf eine virtualisierte Umgebung setzen: ein paar gut ausgestattete Bleche, die als ESX/XEN/Hyper-V-Hosts laufen, und soviele Maschinen virtualisieren, wie die Physik stemmen kann, natürlich unter Berücksichtigung, dass mal ein Host wegbrechen darf, ohne dass die Umgebung kollabiert.

Dieser Beitrag wurde von Sturmovik bearbeitet: 08. September 2014 - 15:13

[RalphS]

Ähm... nein? Okay, vielleicht hab ich ja wirklich was vergessen, und vielleicht reden wir auch von verschiedenen Dingen.... möglich. Aber MSSQL AlwaysOn™ erfordert keinen Windows Cluster - zumindest soweit ich weiß.

Zumindest finde ich bei MSDN nichts Entsprechendes, und ich meine auch mich zu erinnern als ich AlwaysOn mal testweise eingerichtet hatte, daß da explizit KEIN Windows Cluster dran sein durfte. Stattdessen konfiguriert man einfach den MSSQL-Server als Clusterknoten.

[Sturmovik]

Ok, ich geb zu, so tief bin ich in den MSSQL-Server noch nicht eingestiegen und vor allem sind diese Kenntnisse leicht veraltet. Jedenfalls waren das damals für mein Szenario MSSQL-Cluster die beiden Grundvoraussetzungen. Ich halte es auch für sinnvoller, wenn sich die beiden Windowsen ähnlich nahestehen, wie die darauf laufenden Datenbankinstanzen.

(Always-On ist übrigens eine neue Vokabel für mich, daher bin ich mir zi9emlich sicher, dass wir von verschiedenen Dingen reden )

---

Um beim Originalthema zu bleiben:

Bei Datenbanken ist ein Failovercluster auf Blech eine vertretbare Lösung (statt virtualisiert), da hier bei hoher Last jedes bischen an Ressourcen benötigt wird. Da stört die Virtualisierungsschicht nur. Ansonsten ist ein Blech, das den ganzen Tag nur auf den Failover wartet, die reinste ressourcenverschwendung.

Dieser Beitrag wurde von Sturmovik bearbeitet: 08. September 2014 - 17:01

[RalphS]

Datenbanken virtualisieren

Ist ne neumodische (blöde) Angewohnheit. DBs virtualisiert man nicht. Punkt. Und wenn wer was anderes behauptet, dann ist ihm entweder die Performance egal oder die Datenintegrität oder beides.

AlwaysOn... ... gibt es glaub ich tatsächlich erst ab MSSQL 2012. Bis dahin war da, wenn ich das richtig kapiert hab, DB Clustering nicht... so das Wahre.

AlwaysOn sind einfach mehrere Knoten, die sich auf DB-Ebene replizieren (gibt's verschiedene Optionen; Log Shipping ist nur eine davon). Es ist nicht so, daß da "zwei" SQL Server auf "eine" hochverfügbare "Datendatei" zugreifen; stattdessen halten die Datenbank-Serverknoten alle eine Kopie und die Transaktionen werden halt auf- und absynchronisiert. (Genau dafür gibt es die verschiedenen Transaction-Log-Modelle.)


ALLERDINGS würde ich für solche Datenbankangelegenheiten UNBEDINGT einen ausgebildeten DATENBANKadmin einsetzen (KEINEN Windowsadmin und schon gar nicht nebenher). DBMS sind eine Konzeption für sich, auch im Sinne des Clustering. Das ist mit Windows-Clustering auch nur sehr bedingt zu vergleichen.

Dieser Beitrag wurde von RalphS bearbeitet: 08. September 2014 - 17:55

[Ludacris]

Wenn man auf Azure hostet bleibt einem nicht viel über - entweder man nimmt AzureSQL was aber im Funktionsumfang eingeschränkt ist oder man hostet selbst auf einem (oder mehrern) virtuellen Servern und stellt die in ein Availability Set und den Loadbalancer (Clouddienst) davor (passiert sowieso automatisch) allerdings hab ich da noch nicht so ganz durchgeblickt und es ist ein wenig offtopic.

Edit. Um wieder halbwegs on topic zu kommen: AlwaysOn klingt wie das standardverhalten von AzureSQL. Hier wird alles in von Haus aus auf einen weiteren Server im gleichen rechenzentrum und in das jeweils nächste rz (zb. Bei Europa nord in Europa west) gespiegelt und das zieht die insert Geschwindigkeit extrem runter.

[RalphS]

Mit "Cloud-SQL" kannst mich jagen Ich mein okay, das ist natürlich der Unschärfe der Cloud geschuldet, weil man ja nicht weiß, was wie wo ist (oder auch nicht) und Zustände faktisch nicht abgebildet werden können.

AlwaysOn tut das halt nicht, das ist eher sowas wie "DC-Replikation für Datenbankserver". Die sind nicht autonom und betreiben sowas wie Multimaster-Replikation untereinander. Ist eigentlich ein interessantes Konzept, was da zugrunde liegt (nachzulesen wie immer bei der TechNet).

... wenn das eher eine Art von Master/Slave Konfiguration sein soll und über mehrere Standorte geht, mh. Hab mich da mit der HA-Konfiguration von SQL Server nicht so tiefgehend befaßt; simples Log Shipping könnte da die bessere Option sein. Immerhin hat man mit AlwaysOn im Normalbetrieb jederzeit haufenweise Daten auf der Leitung... und wenn das nicht grad eine dedizierte Standort-zu-Standort Leitung ist, die momentan eher frei ist und nicht nur 10Mbits/s im Up/Downstream hergibt, rieche ich ansonsten eher Leitungsverstopfung als Performance.

[shiversc]

Zitat (Makru: 08. September 2014 - 14:28)

Merci für eure Antworten.

Eigentlich geht es um Applikationen, die normalerweise auf einem Single Windowsserver als Master an einem Standort laufen und an einem 2ten als Slave. Fällt nun der Master aus, wird der Slave automatisch zum Master, fällt der Slve aus, gibt es einen Alarm.
Die Datenbanken, MS-SQL, werden zwischen Master und Slave repliziert. Damit sind Daten, Hard-und Software bei Ausfall geschützt.

Ein Kunde fragt aber nun nach Hardwareprotection pro Standort an und findet das Wort Cluster ganz toll.

Mit Hilfe von Google und euren Antworten denke ich verstanden zu haben, das unsere eigenen, nicht clusterfähigen Applikationen mit dem Windows Server Failover Cluster nicht funktionieren werden. Meine erste Idee war halt, ein Windows-Failover-Cluster z.B. in eine "Cluster in a box" Hardware laufen zu lassen.

Gruss
Mathias

Definiere Standort!
Wer sagt, dass eure Apps nicht Clusterfähig sind?
Ich denke du hast gegoogelt und weißt wie ein MS Failovercluster funktioniert? Ich hoffe du hast auch verstanden was mit SMB 3.x hinzugekommen ist?

Zitat (RalphS: 08. September 2014 - 14:39)

MSSQL läßt sich clustern, aber nicht über Windows. MSSQL kann (und muß) das selber machen.

Wieder alles in einen Topf und schön gerührt....

Zitat (RalphS: 08. September 2014 - 16:24)

Ähm... nein? Okay, vielleicht hab ich ja wirklich was vergessen, und vielleicht reden wir auch von verschiedenen Dingen.... möglich. Aber MSSQL AlwaysOn™ erfordert keinen Windows Cluster - zumindest soweit ich weiß.

Zumindest finde ich bei MSDN nichts Entsprechendes, und ich meine auch mich zu erinnern als ich AlwaysOn mal testweise eingerichtet hatte, daß da explizit KEIN Windows Cluster dran sein durfte. Stattdessen konfiguriert man einfach den MSSQL-Server als Clusterknoten.

Wie alles in einen Topf. AlwaysOn ist eine lizenzpflichtige Funktion. Die Funktion hat Anforderungen damit sie optimal läuft. Aber warum ist sie im Topf mit dem MS Failovercluster?

Zitat (RalphS: 08. September 2014 - 17:51)

Datenbanken virtualisieren

Ist ne neumodische (blöde) Angewohnheit. DBs virtualisiert man nicht. Punkt. Und wenn wer was anderes behauptet, dann ist ihm entweder die Performance egal oder die Datenintegrität oder beides.

AlwaysOn... ... gibt es glaub ich tatsächlich erst ab MSSQL 2012. Bis dahin war da, wenn ich das richtig kapiert hab, DB Clustering nicht... so das Wahre.

AlwaysOn sind einfach mehrere Knoten, die sich auf DB-Ebene replizieren (gibt's verschiedene Optionen; Log Shipping ist nur eine davon). Es ist nicht so, daß da "zwei" SQL Server auf "eine" hochverfügbare "Datendatei" zugreifen; stattdessen halten die Datenbank-Serverknoten alle eine Kopie und die Transaktionen werden halt auf- und absynchronisiert. (Genau dafür gibt es die verschiedenen Transaction-Log-Modelle.)


ALLERDINGS würde ich für solche Datenbankangelegenheiten UNBEDINGT einen ausgebildeten DATENBANKadmin einsetzen (KEINEN Windowsadmin und schon gar nicht nebenher). DBMS sind eine Konzeption für sich, auch im Sinne des Clustering. Das ist mit Windows-Clustering auch nur sehr bedingt zu vergleichen.

Tolle Ratschläge und Meinungen. Aber komme bitte erst mal in der Gegenwart an!

Zitat (RalphS: 12. September 2014 - 07:21)

Mit "Cloud-SQL" kannst mich jagen Ich mein okay, das ist natürlich der Unschärfe der Cloud geschuldet, weil man ja nicht weiß, was wie wo ist (oder auch nicht) und Zustände faktisch nicht abgebildet werden können.

AlwaysOn tut das halt nicht, das ist eher sowas wie "DC-Replikation für Datenbankserver". Die sind nicht autonom und betreiben sowas wie Multimaster-Replikation untereinander. Ist eigentlich ein interessantes Konzept, was da zugrunde liegt (nachzulesen wie immer bei der TechNet).

... wenn das eher eine Art von Master/Slave Konfiguration sein soll und über mehrere Standorte geht, mh. Hab mich da mit der HA-Konfiguration von SQL Server nicht so tiefgehend befaßt; simples Log Shipping könnte da die bessere Option sein. Immerhin hat man mit AlwaysOn im Normalbetrieb jederzeit haufenweise Daten auf der Leitung... und wenn das nicht grad eine dedizierte Standort-zu-Standort Leitung ist, die momentan eher frei ist und nicht nur 10Mbits/s im Up/Downstream hergibt, rieche ich ansonsten eher Leitungsverstopfung als Performance.

"...Zustände nicht abgebildet..."
Meinst du nicht dass das eher Phrasen für die Politik sind?


@Topicstarter:
Wenn ich das richtig gelesen habe, dann seid ihr eine Firma oder wollt es sein und ein Kunde fragt eine etwas aufwendigere Lösung an.
Ich habe den Eindruck dass euer Kunde bessere beraten ist, wenn er Profis einkauft, die wenigstens die Basics drauf haben. Das ist auch in euren Interesse, ihr stellt auch für euch ein Risiko dar.