pflock - Di 30.08.05 10:19
Titel: Clusterfähige Applikation

---

hallo

auf einem sql2000server werden mit einer delphi-applikation jede nacht daten von ascii-files eingelesen und in die datenbank gepumpt. der sqlserver ist auf einem failover-cluster (sql1 und sql2). die applikation ist momentan nur auf dem sql1 installiert. nun hatten wir einige male die situation, dass der sql1 auf tauchstation ging und sql2 die arbeit übernahm. das datenbank-moving klappte problemlos, nur unsere applikation natürlich nicht - sie ist ja auch nicht im cluster eingebunden. nun die fragen:

- müssen beim coden von delphi-applikationen gewisse dinge berücksichtigt werden, damit die applikation clusterfähig wird?
- wie mache ich überhaupt ein delphi-programm clusterfähig?

bin dankbar für alle tips.

gruss
alex

Udontknow - Di 30.08.05 10:31

---

Hallo!

Ähm, ich habe keine Ahnung in Sachen MSSQL, aber grundsätzlich sind die zusätzlichen Sicherheiten eines DBMS (hier dieser Failovercluster) ja nur als Ausfallschutz des DB-Services zu verstehen. Eine Clientanwendung, die von irgendwo auf diesen Service zugreift, ist ja deswegen noch lange nicht vor Applikationsfehlern oder allgemein Fehlern auf der Maschine, von der sie gestartet wird, gefeit. Wenn also Rechner SQL1 sich regelmäßig verabschiedet, und mit ihm die Applikation, wäre die logische Konsequenz, die Applikation auf einen anderen Rechner auszulagern.

Werden denn bestehende Datenbankverbindungen bei einem Problem auf SQL1 automatisch nach SQL2 übergeben, oder wie ist das?

Cu,
Udontknow

pflock - Di 30.08.05 10:42

---

Zitat:

Eine Clientanwendung, die von irgendwo auf diesen Service zugreift, ist ja deswegen noch lange nicht vor Applikationsfehlern oder allgemein Fehlern auf der Maschine, von der sie gestartet wird, gefeit.

die applikation läuft direkt auf dem server sql1, ist aber (nocht) nicht in die cluster-gruppe eingebunden.

Zitat:

Werden denn bestehende Datenbankverbindungen bei einem Problem auf SQL1 automatisch nach SQL2 übergeben, oder wie ist das?

ich weiss: wenn ein moving stattfindet (während dem tag, wenn die user arbeiten) verliert delphi die verbindung zur datenbank, obwohl sie grundsätzlich nach einem kurzen ausfall von wenigen sekunden wieder verfügbar ist. andere client-programme haben damit keine probleme.

mein problem:
der server ist genau aus gründen des ausfallschutzes und hoher verfügbarkeit eingerichtet worden. die von mir beschriebene nächtliche datenpumperei ist für unser unternehmen sehr wichtig und fällt deshalb ebenfalls in die sparte "hoch verfügbar". deshalb ist mein auftrag, unsere datenpumpe (delphi7-app) ebenfalls so hinzukriegen, dass sie im fall eines failovers vollumfänglich clusterfähig ist.

Udontknow - Di 30.08.05 10:56

---

Ja, also die Verbindung wiederherzustellen, ist ja das geringste Problem, eben alles ordentlich mit Try/except kapseln, bei einer Exception 10 Sekunden warten, Verbindung wiederherstellen und da aufsetzen, wo man unterbrochen wurde. Nur, wie gesagt, ein Client wie deine Applikation weiß nichts von irgendeiner Clustergruppe, es gibt nur eine DB-Verbindung.

Entweder muss das Programm, wie schon gesagt, auf einem anderen Rechner laufen, oder aber du musst, wenn es zu einem Absturz kommt, auf der Maschine SQL2 dann genau wissen, wann der Absturz (bei welcher Zeile in welcher Textdatei) erfolgte, um wieder sauber aufsetzen zu können. Ich persönlich fände die erste Variante schöner, weil auf den ersten Blick auch schneller zu realisieren.

Cu,
Udontknow

pflock - Di 30.08.05 11:05

---

tja, die appl auf einem anderen sever laufen zu lassen war auch meine idee ... doch mein chef sieht das anders. ich hab den konkreten auftrag, das teil in den cluster zu integrieren und dafür zu sorgen, dass das progi im falle eines failovers mit dem rest der clustergruppe den server wechselt. und genau jetzt betrete ich neuland.

Udontknow - Di 30.08.05 11:18

---

Dein Chef vermischt da Teile miteinander, der Cluster hat, wie ich sagte, erstmal so nichts mit der Clientanwendung zu tun. Wenn man die Applikation auf dem Rechner des Clusters, der immer abstüzt, parkt, bringt es doch nichts. Der Cluster ist nur nach aussen eine Sicherheitserhöhung, die einzelnen Teile des Clusters können, wie ihr ja schon gemerkt habt, nach wie vor ausfallen. Dementsprechend sollte sogar die Anwendung dort weggeholt werden.

Wie sieht es denn aus, läuft SQL2 rund um die Uhr, oder wird der erst gestartet, wenn SQL1 ausfällt? Wenn ersters, lager das Programm dorthin aus. Aber gut ist das nicht, denn wenn SQL1 ausfallen kann, wird es womöglich auch SQL2 irgendwann erwischen können.

Cu,
Udontknow

pflock - Di 30.08.05 11:31

---

das argument von uncle big boss ist: "wir haben jetzt einen teuren cluster eingerichtet, also hat jetzt diese applikation clusterfähig zu sein!" im weiteren ist er der meinung, dass der ort, an dem die applikation dann laufen würde (nicht auf dem server) ebenfalls gegen ausfall gesichert sein müsste, was ihn wiederum in der meinung bestärkt, dass der cluster genau das tut und deshalb muss das progi das auch begreiffen.

der sql2 läuft permanent, da läuft unser exchange drauf. die datendateien (sqldaten) liegen übrigens auf einem san-storage-system.

alzaimar - Di 30.08.05 11:52

---

Erstmal dachte ich, das nach aussen hin ein SQL-Server-Cluster nur eine IP-Adresse hat... Aber egal..

Ich habe es anders gelöst:
Ein kleines Programm ("Repository") checkt regelmäßig per Ping und/oder ADO-Connect, wie es dem dem SQL-Server geht. Ist der nicht erreichbar, dann werden die Failover-Server durchprobiert. Nebenbei hält dieses kleine Piddyprogramm auch zentrale Einstellungen.
Sobald der aktuelle SQL-Server nicht mehr vorhanden ist und ein neuer gefunden wurde, wird per 'broadcast' (z.B. UDP oder mailslot) eine Nachricht an die clients verschickt, das sie sich bitte mal neu verbinden sollen.

Alle Clients beziehen vor einem Connect den aktuellen SQL-Server (sowie weitere Geschichten) von der Repository und verbinden sich erst dann.

So klappt es in einer 24/7 Umgebung, bis auf die üblichen Katastrophen (Putze zieht Netzwerkkabel mit Besen raus etc.) sehr sehr gut.

pflock - Di 30.08.05 14:41

---

workarounds haben wir bereits im einsatz, damit ist man aber nicht zufrieden. man will diese applikation auf dem sql-server haben und man will sie clusterfähig haben, das ist mein auftrag.

oder ist das wirklich so unsinnig und abwägig?

noidic - Di 30.08.05 14:47

---

Dann wird die Anwednung auf jedem Server laufen müssen, allerdings nur eine Instanz 'aktiv', die andere(n) bekommen lediglich mit, welche Datensätze aus der Textdatei bereits verarbeitet sind.
Fällt nun die aktive Instanz aus, merkt das die failover-Instanz ( z.B. per Timeout der Datensatz-Infos ) und wird zur aktiven Instanz.

So in etwa läuft das afaik auch bei SQL-Server und Co., einer ist aktiv, die anderen sind in Wartestellung, bis der aktive ausfällt.

Was anderes ist das bei Lastverteilung, da müssen alle zugleich aktiv sein und sich die Arbeit teilen, ist aber hier ja nicht der Fall.

alzaimar - Mi 31.08.05 09:10

---

pflock hat folgendes geschrieben:

...man will diese applikation auf dem sql-server haben und man will sie clusterfähig haben, das ist mein auftrag. oder ist das wirklich so unsinnig und abwägig?

Antwort: Total unsinnig und abwegig (mit ä, stammt doch von 'vom Wege abkommen' ab, nicht?), denn: Auf einem DB-Server lässt man doch nicht eine Applikation (oder Mittelschicht) laufen, Uargl. Das wäre ja so, als ob man auf seiner Kaffeemaschine gleich die Eier brät oder zumindest kocht... Sowas macht man nicht.

Dann lieber die paar Kröten in einen kleinen App-Server stecken. Der braucht doch nicht viel.

Wie gesagt, bin kein Serverspezialist, aber unsere Hardwarebude hat mir mal gesagt, das eine Clusterlösung nach aussen hin vollständig transparent ist, sprich: Ein Computername, eine IP-Adresse. Die verclusterten Server machen das unter sich aus... Wenn's stimmt. Da wäre dann nur die Applikation vom DB-Server zu schmeissen.

EDIT: Hab mir Deine Problemstellung jetzt mal richtig angeschaut: Jeder SQL-Server schickt alive-pakets in die Runde, das kannst Du einstellen, wie oft das geht. Das erkennst Du u.A. am Enterprise-Manager, der immer nach einer gewissen Verzögerung den Server als 'verfügbar' markiert. Weiterhin siehst Du im Icon des Servers alle paar Sekunden einen kleinen roten Punkt blinken. Dann sendet er die Alive-Messages.

Ich würd' mal sagen, Du gehst so vor, das Du einfach auf das NICHT-Auftreten dieser Message reagierst: Denn sowohl SQL1 als auch SQL2 sollten diese Messages periodisch senden... Wenn Du merkst, das vom aktuellen SQL-Server nix mehr kommt, dann wechsest du auf den, vom DEM was kommt... Und falls Du das mit den Messages nicht hinbekommst, dan ping doch einach, oder mach ein "select * from bla where 1=0" oder sonst was.

pflock - Do 01.09.05 10:40

---

ich sehe, man ist sich hier einig, uneinig mit meinen chef zu sein :D :D

beten dank mal für die antworten und ich werde mir das alles mal zu gemüte führen und versuchen, den server server sein zu lassen und die applikation woanders laufen zu lassen.