Jump to content

Lian

Moderators
  • Gesamte Inhalte

    22.422
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Lian

  1. So ist es, daher gilt es Split Brain und Partition in Time Fälle auszuschließen, so wie die SPOFs. Hier hat sich schon einiges von Windows 2000 auf Windows 2003 verbessert und wiederum von 2K3 auf 2K8.

     

    Zur Frage: Nur wenn sich Deine Applikation darum kümmert:

    Falls das eine eigens entwickelte Applikation ist, macht es ggf. Sinn die Anwendung Cluster-Aware zu programmieren. So wie es für Exchange oder den SQL Server und viele andere Anwendungen der Fall ist.
  2. Das ist ein potentieller SPOF, allerdings ist eine SAN von Haus aus mehrfach redundant ausgelegt was deren Teile betrifft (FC Switche, FC Verbindungen, Storage Prozessoren, Lüfter, Netzteile, USV, Platten etc.)

    In einem Multi-Site Cluster mit gespiegelter SAN darf dann sogar ein ganzes RZ wegfallen.

    Für Deine Anforderungen (N-1 soll ausfallen dürfen) blieb nur das Model übrig.

     

    Ich schau mir die Infos in der PN mal im Detail an.

     

    Falls das eine eigens entwickelte Applikation ist, macht es ggf. Sinn die Anwendung Cluster-Aware zu programmieren. So wie es für Exchange oder den SQL Server und viele andere Anwendungen der Fall ist.

    Sei es für Failover oder NLB Cluster.

  3. Wie gesagt: Ohne zu Wissen, was im Detail passiert und wofür die Applikation eigentlich da ist, kann man Dir schwer zu etwas raten.

     

    Das von Dir sog. "alte" Quorum Model ist eigentlich eher die Königsklasse beim Clustering, dahinter eine ordentliche SAN mit SnapShots und ggf. Mirroring auf SAN Ebene (SRDF zB.): Da kommt wenig darüber;)

    Die anderen Modelle (MNS) sind aus Kostengründen entstanden (2k3), die neuen Hybridmodelle unter Windows Server 2008 sind wieder interessant geworden.

     

    Zum Thema stateless Applikationen:

    http://www.mcseboard.de/windows-forum-ms-backoffice-31/iis-cluster-vorteil-clusftp-vbs-141667.html#post869631

     

    Mag sein, daß NLB in der Tat die bessere Option für den TO ist. Das ist primär abhängig von Deiner Applikation, siehe zB: http://technet.microsoft.com/en-us/library/cc757350.aspx

  4. Es gibt immer noch zwei grundsätzlich verschiedene Modelle, was die Datenhaltung mit den Konfigurationsdaten und Statusinformationen eines Clusters angeht.

    Diese übergehst Du.

    Cluster mit Shared Device (hat nichts mit "alt" zu tun) auf dem per se eine konsistente Datenhaltung erfolgt oder ein Majority Node Cluster, bei dem die Daten auf jeden Node repliziert werden und erst konsistent sowie aktuell gehalten werden müssen.

     

    Appendix B: Additional Information About Quorum Modes

    We recommend using a disk witness instead of a file share witness as it is less likely for a “split” scenario to occur, because there is a replica on the disk witness but not on the file share witness. The disk witness can ensure that there is no partition in time since it has a copy of the replica on it and ensures that the cluster has the most up to date configuration.

     

    Du läufst ggf. in das Problem, daß die Daten nicht aktuell sind - sprich: Das Replika auf den Nodes nicht aktuell:

    The file share witness keeps track of which node has the most updated replica, but does not have a replica itself. This can lead to scenarios when only a node and the file share witness survive, but the cluster will not come online if the surviving node does not have the updated replica because this would cause a “partition in time.” This solution does not solve the partition in time problem, but prevents a “split” scenario from occurring.

     

    Die Applikation brauch es ja nicht wissen. Beide arbeiten parallel und unabhängig von einander. Das soll auch so sein. Aber die Teilnehmer des "Ziel-WAN" müssen es "wissen". Bzw. auch nicht, denn sie sollen über eine Cluster-IP automatisch auf einen von den beiden Rechnern zugreifen. Die Cluster-Software soll festlegen (durch Vergabe/Zuordnung der CLuster-IP) auf welchen Rechner zugegriffen werden soll.
    Ohne zu Wissen, was im Detail passiert und wofür die Applikation eigentlich da ist, kann man Dir schwer zu etwas raten.

     

    Die Stimmenanzahl kann man nicht konfigurieren.

  5. Zur Frage:

    In a cluster with the Node and File Share Majority configuration, the nodes and the witness file share are counted when calculating a majority. This is similar to the Node and Disk Majority quorum configuration (...) except that the witness is a file share that all nodes in the cluster can access instead of a disk in cluster storage.

    Diese PPT gibt imo mehr her:

    http://download.microsoft.com/download/6/d/c/6dcfa437-da3d-417d-a530-68e087b71923/WSR439.ppt (PPT Download)

     

    Du musst das so sehen: Eine zentrale Storage mag für die Applikation nicht wichtig sein, aber für den Clusterbetrieb, diese stellt das Quorum selbst dar und enthält Konfigurations- und Statusinformationen oder stellt eine Stimme (Vote) dar, die im Fehlerfall mitzählt. Je nach Model.

     

    Die Applikation muss (und das habe ich bisher noch nicht gesagt) auf 2 Nodes parallel laufen, um im Fehlerfall schnell umschalten zu können.

    Naja, in dem Fall nimmst Du dem Cluster sozusagen die Arbeit ab... ;)

    Woher weiß die Applikation welche gerade aktiv ist?

  6. Zur Frage: Nein, von Haus aus nicht.

     

    Ohne gespiegelte SAN im Multi-Site Cluster:

     

    Wenn es eine Ressource sein muss, die über alle Nodes verfügbar sein soll, dann landen wir für einen Geo-(Neu: Multi-Site)Cluster bei "Node and File Share Majority" Model.

     

    Mit gespiegelter SAN im Multi-Site Cluster:

     

    Für einen "Node and Disk Majority" Cluster brauchst Du im Falle eines Multi-Site Clusters Drittanbieterlösungen für die Storage wie EMC SRDF.

  7. Wichtig ist also IP und Generic Application (.exe)?

     

    Naja, kommt immer darauf an, welchen Level von Hochverfügbarkeit Du erreichen willst und welche SLA Du wiederum auf Ersatzteile hast.

     

    Woher weiß man nun aus Sicht des "Ziel-WANs" welcher der beiden Server den Dienst bereit stellt? Wie macht man ein IP-Failover zwischen den beiden Cluster?

    Gar nicht. Wären denn alle Knoten in Deinem Konstrukt im gleichen Netz (Ziel-WAN)?

    Ist denn das Quell-WAN redundant ausgelegt?

  8. Was hast Du für einen Webserver? Mit Perl hat man das früher realisiert, als es nur CGI gab.

     

    Mittlerweile wird meistens ASP oder PHP genutzt...

     

    Zu Deiner Frage:

    Wo muss ich denn dem Script sagen, welches der Mailserver im lokalen netz ist?

    Es wird versucht auf ein lokales sendmail (Linux, *nix) zuzugreifen:

    $Sendmail_Prog = "/usr/lib/sendmail";

  9. Die Server sammeln Daten eines Netztes und stellen sie dem anderen Netz konverteiert zur Verfügung.
    Das sind Windows Dateien, die auf einem NTFS Volume gespeichert werden, richtig?

     

    Es stehen also 2 Nodes an einem Standort in einem Netz und weitere 2 an dem anderen Standort, ok.

    Nachdem keine gemeinsame Datenhaltung nötig ist, kannst Du Deine Anforderung durch das Aufbauen von 2 Clustern mit jeweils 2 Nodes erreichen (Node and Disk Majority).

    Der verbleibende Node kommt immer nur an seine Daten an dem einen Standort heran. Je nachdem wie die Datenreplikation funktioniert -Du schreibst etwas von "weiterreichen"- sind das sowieso die kummulierten Daten. So zumindest das Ziel.

    Mehr dazu (Multi-Site Cluster und Data Replication) hier: Data Replication in Geographically Dispersed Clusters: Server Clusters (MSCS)

    Microsoft verweist hier auf die Hardware & Software Vendoren, da Datenreplikation nicht der Job eines Windows Failover Clusters ist.

     

    So und so: Solange die SPOFs weitestgehend ausgeräumt sind, muss schon eine Menge passieren bis mal drei Knoten ausfallen. ;)

     

    Aber ich möchte Dir an dieser Stelle nochmal danken, dass Du Dir Zeit für mich nimmst!
    Gerne, dazu sind wir da :wink2:
  10. Ah ok, jetzt verstehe ich worauf Du hinaus willst.

     

    Da kommen wir speziell in den Fall von Node Majority und Multi-Site Clustering.

     

    Generell ist eine reine Node Majority ohne Shared Storage für Even-Node cluster nicht empfohlen, das steht auch in dem von Dir zitierten Link.

     

    Geht es Euch um einen File Server Cluster oder was habt Ihr vor?

  11. geht nicht bei allen Druckern, wenns geht nehme ich die Inbox Treiber her.

    Nur zum Testen, ob es am Treiber liegt. Wenn es am Treiber liegt, kann Dir nur HP helfen.

    habe ich gestest, keine Probleme Papiertyp bleibt auf "Nicht bestimmt" so wie es sein soll, d.h. das Problem besteht nur wenn der Drucker über den Cluster installiert wird.
    Bingo.
    nein, da die sagen man solle den Postscript Treiber hernehmen oder den HP Universal Printdriver. Mit dem Postscript Treiber würde es sogar funktionieren. Kann ich aber nicht so ohne weiteres installieren, da bestimmte Vorgaben eingehalten werden müßen. Der HP UPD macht allerdings die gleichen Probleme.

    Wie gesagt: Notfalls bei HP insistieren oder einen Call bei MS eröffnen: Die können sich wiederum an HP wenden, um den Fehler im entsprechenden Treiber/Modul im Detail zu lokalisieren.

  12. Hallo,

     

    bei Windows Server 2003 gab es "nur" zwei Quorum Modelle: Single/Standard Quorum Model mit einer Shared Storage oder Majority Node Set. Bei Windows Server 2008 ist die Auswahl etwas größer:

    There are four quorum modes:

     

    * Node Majority: Each node that is available and in communication can vote. The cluster functions only with a majority of the votes, that is, more than half.

    * Node and Disk Majority: Each node plus a designated disk in the cluster storage (the “disk witness”) can vote, whenever they are available and in communication. The cluster functions only with a majority of the votes, that is, more than half.

    * Node and File Share Majority: Each node plus a designated file share created by the administrator (the “file share witness”) can vote, whenever they are available and in communication. The cluster functions only with a majority of the votes, that is, more than half.

    * No Majority: Disk Only: The cluster has quorum if one node is available and in communication with a specific disk in the cluster storage. Only the nodes that are also in communication with that disk can join the cluster.

     

    Siehe: Failover Cluster Step-by-Step Guide: Configuring the Quorum in a Failover Cluster

     

    Wichtig ist eine gemeinsame Datenhaltung für die Ablage der Konfigurationsdaten und der Statusinformationen eines Clusters.

     

    Wie ich das bisher sehe ist das mit Windows-Mitteln nicht realisierbar, oder etwa doch?

    Wieso sollte das nicht mit einem Windows Server Failover Cluster umsetzbar sein?

    Ein Multi-Site Cluster ist keine Neuerung und gab es schon unter Windows Server 2003, hier die Einstiegsseite zu 2008: Windows Server 2008: Failover Clustering Program Overview

     

    Ideal für Deine Zwecke wäre das Node and File Share Majority Model, siehe Anhang (Quelle)

    post-8-13567389604427_thumb.gif

  13. Naja, nicht ganz egal. Erstmal sollten wir klären wie die Umgebung aussieht und jetzt wird schon einiges klarer ;)

     

    Magst Du Dir den KB Artikel von Norbert (307962) zu Gemüte führen? Dort steht alles, was Du zu dem Thema wissen solltest.

    Habt Ihr denn Probleme mit den Clustern, oder was bewegt Dich?

     

    Nachdem das System bereits läuft (richtig?), ist die Frage, die Du Dir stellen solltest: Wie ist der Heartbeat konfiguriert hinsichtlich der Netzwerkadressen und -topologie.

    Ich nehme an, das Heartbeat-Netz ist ein eigenes Netz an einem Switch oder an mehreren Switchen? Ist dieses an einem dedizierten Switch angebunden oder in VLANs auf mehreren Switchen angebunden oder...?

     

    Noch eine grundsätzliche Frage: Wir reden hier aber nicht über Geo-Cluster? Die Clusternodes sind alle im gleichen RZ?

×
×
  • Neu erstellen...