Windows Server Failover Cluster (Newbie) Clusterfähige Applikation notwendig?
#1
geschrieben 29. August 2014 - 14:41
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
Anzeige
#2
geschrieben 29. August 2014 - 19:11
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
#3
geschrieben 31. August 2014 - 20:33
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
#4
geschrieben 03. September 2014 - 14:43
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.
#5
geschrieben 03. September 2014 - 15:45
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
#6
geschrieben 05. September 2014 - 18:59
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?
#7
geschrieben 08. September 2014 - 14:28
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
#8
geschrieben 08. September 2014 - 14:39
#9
geschrieben 08. September 2014 - 15:11
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
Unix won't hold your hand. You wanna shoot your foot, Unix reliably delivers the shot.
True Cloudstorage
#10
geschrieben 08. September 2014 - 16:24
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.
#11
geschrieben 08. September 2014 - 16:48
(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
Unix won't hold your hand. You wanna shoot your foot, Unix reliably delivers the shot.
True Cloudstorage
#12
geschrieben 08. September 2014 - 17:51
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
#13
geschrieben 12. September 2014 - 06:48
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.
#14
geschrieben 12. September 2014 - 07:21
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.
#15
geschrieben 13. September 2014 - 08:36
Zitat (Makru: 08. September 2014 - 14:28)
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)
Wieder alles in einen Topf und schön gerührt....
Zitat (RalphS: 08. September 2014 - 16:24)
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)
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)
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.
- ← Sitzungstimeout / Remotedesktopverbindung
- Windows Server 2012 R2 & Server 2012
- Windows Server 2012 und 2 Internetverbindungen →