Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
OES11-Cluster: Ressourcen nicht erreichbar nach "yast lan"
12 views
Skip to first unread message
Bernd
Jul 23, 2014, 1:49:38 AM7/23/14
to
Hi,
es gibt einen OES11 2-Knoten Cluster der auf ESX läuft.
Nach der Installation sollte die Konfiguration des DNS-Resolvers
geändert werden. Also yast lan aufgerufen, die IP-Adressen der
DNS-Server geändert und OK. Yast lief durch, passte die Konfiguration an
und beendete sich.
Anschließend waren die Cluster-Ressourcen nicht erreichbar. Hö? Kurz
geprüft ... die IP-Adressen der Ressourcen (die Secondary IPs) waren
nicht da. Einmal die Ressourcen hin- und hergeschwenkt, alles OK,
fertig.
Das Verhalten ist reproduzierbar.
Wo muss ich lesen um zu sehen das dieses Verhalten so geplant ist ...
Bye
Bernd
es gibt einen OES11 2-Knoten Cluster der auf ESX läuft.
Nach der Installation sollte die Konfiguration des DNS-Resolvers
geändert werden. Also yast lan aufgerufen, die IP-Adressen der
DNS-Server geändert und OK. Yast lief durch, passte die Konfiguration an
und beendete sich.
Anschließend waren die Cluster-Ressourcen nicht erreichbar. Hö? Kurz
geprüft ... die IP-Adressen der Ressourcen (die Secondary IPs) waren
nicht da. Einmal die Ressourcen hin- und hergeschwenkt, alles OK,
fertig.
Das Verhalten ist reproduzierbar.
Wo muss ich lesen um zu sehen das dieses Verhalten so geplant ist ...
Bye
Bernd
Bernd
Jul 23, 2014, 2:24:30 AM7/23/14
to
Am Wed, 23 Jul 2014 07:49:38 +0200
schrieb Bernd <bna...@web.de>:
> Hi,
>
> es gibt einen OES11 2-Knoten Cluster der auf ESX läuft.
>
> Nach der Installation sollte die Konfiguration des DNS-Resolvers
> geändert werden. Also yast lan aufgerufen, die IP-Adressen der
> DNS-Server geändert und OK. Yast lief durch, passte die Konfiguration
> an und beendete sich.
>
> Anschließend waren die Cluster-Ressourcen nicht erreichbar. Hö? Kurz
> geprüft ... die IP-Adressen der Ressourcen (die Secondary IPs) waren
> nicht da. Einmal die Ressourcen hin- und hergeschwenkt, alles OK,
> fertig.
(...)
Ingrid sagt ...
Es ist doch klar ... NCS addiert die Secondary-IP via
Cluster Load-Script. Da kriegt der SLES nichts von mit. Daher schreibt
SuSE-Config die IPs nicht wieder rein.
Bernd
schrieb Bernd <bna...@web.de>:
> Hi,
>
> es gibt einen OES11 2-Knoten Cluster der auf ESX läuft.
>
> Nach der Installation sollte die Konfiguration des DNS-Resolvers
> geändert werden. Also yast lan aufgerufen, die IP-Adressen der
> DNS-Server geändert und OK. Yast lief durch, passte die Konfiguration
> an und beendete sich.
>
> Anschließend waren die Cluster-Ressourcen nicht erreichbar. Hö? Kurz
> geprüft ... die IP-Adressen der Ressourcen (die Secondary IPs) waren
> nicht da. Einmal die Ressourcen hin- und hergeschwenkt, alles OK,
> fertig.
Ingrid sagt ...
Es ist doch klar ... NCS addiert die Secondary-IP via
Cluster Load-Script. Da kriegt der SLES nichts von mit. Daher schreibt
SuSE-Config die IPs nicht wieder rein.
Bernd
Massimo Rosen
Jul 28, 2014, 4:14:53 PM7/28/14
to
irgendwas an den anderen Netzeinstellungen machen? Wenn es das tut, und
z.B. ein rcnetwork restart loslässt, dann ist *das* der Grund, denn das
kickt die Node absichtlich aus dem Cluster.
CU,
Massimo
Bernd
Jul 31, 2014, 1:30:45 PM7/31/14
to
Am Mon, 28 Jul 2014 22:14:53 +0200
schrieb Massimo Rosen <mros...@SPAMcfc-it.de>:
Na ja, (oder auch nee)
der Knoten war schon noch im Cluster und die Ressourcen liefen auch
noch darauf. Der Neustart des Netzwerkstacks hatte nicht dazu geführt,
das der Knoten aus dem Cluster fiel. (Das wäre ja fast schon gut
gewesen ;-)
Nur die secondary IP-Adressen war eben nicht mehr da.
Bernd
schrieb Massimo Rosen <mros...@SPAMcfc-it.de>:
der Knoten war schon noch im Cluster und die Ressourcen liefen auch
noch darauf. Der Neustart des Netzwerkstacks hatte nicht dazu geführt,
das der Knoten aus dem Cluster fiel. (Das wäre ja fast schon gut
gewesen ;-)
Nur die secondary IP-Adressen war eben nicht mehr da.
Bernd
Massimo Rosen
Aug 1, 2014, 3:11:45 AM8/1/14
to
Wie auch immer, es gibt dafür übrigens eine ganz einfache Lösung damit
sowas nicht passiert, die viel zu selten benutzt wird: Die Cluster
Monitor Funktion/skripte. Der hätte nämlich gemerkt dass die IPs weg
sind, und sie einfach widerhergestllt.
CU,
Massimo
Bernd
Aug 1, 2014, 3:31:36 AM8/1/14
to
Am Fri, 01 Aug 2014 09:11:45 +0200
Naja, seltsam finde ich das nicht -wie schon geschrieben- aber es
stimmt natürlich, die Monitoring Skripte hätten das evtl. repariert.
Die sind aber bei dem (neuen) System noch nicht konfiguriert. Ein Grund
mehr das zu tun ... ;-)
Bernd
stimmt natürlich, die Monitoring Skripte hätten das evtl. repariert.
Die sind aber bei dem (neuen) System noch nicht konfiguriert. Ein Grund
mehr das zu tun ... ;-)
Bernd
Massimo Rosen
Aug 1, 2014, 8:40:02 AM8/1/14
to
On 01.08.2014 09:31, Bernd wrote:
>
> Naja, seltsam finde ich das nicht -wie schon geschrieben-
Doch, wohl. ;)
>
> Naja, seltsam finde ich das nicht -wie schon geschrieben-
Nochmal, das ändern des DNS Servers hätte schonmal nicht zu irgendeiner
Veränderung an einer anderen Stelle des Netzes führen dürfen, und
genausowenig zu einem Neustart des Netzwerks.
Offensichtlich hat aber Yast *doch* einen Neustart des Netzwerks
losgelassen (andernfalls wären die cluster IPs ja nicht weg), und
widerum dieser Neustart des Netzwerks hätte eben normalerweise einen
sofortigen Failover der Clusterressource(n) auslösen *müssen*. Genauso
wie z.B rausziehen des Netzwerkkabels das sofort auslöst.
> aber es
> stimmt natürlich, die Monitoring Skripte hätten das evtl. repariert.
> Die sind aber bei dem (neuen) System noch nicht konfiguriert. Ein Grund
> mehr das zu tun ... ;-)
CU,
Massimo
Bernd
Aug 1, 2014, 9:08:05 AM8/1/14
to
Am Fri, 01 Aug 2014 14:40:02 +0200
schrieb Massimo Rosen <mros...@SPAMcfc-it.de>:
> (...)
(DNS-)Konfiguration erfahren hätte. Aber YaST lässt halt zum Schluss
immer suseconfig laufen, da ist ein "rcnetwork restart" mit bei. Das mag
man nicht gut finden, dass ist aber so.
>
> Offensichtlich hat aber Yast *doch* einen Neustart des Netzwerks
> losgelassen (andernfalls wären die cluster IPs ja nicht weg), und
> widerum dieser Neustart des Netzwerks hätte eben normalerweise einen
> sofortigen Failover der Clusterressource(n) auslösen *müssen*.
> Genauso wie z.B rausziehen des Netzwerkkabels das sofort auslöst.
Hm, war es nicht mal so, das der Knoten erst nach 4 Heartbeats gekillt
wurde? Und gibt es im Standard nicht alle 2 s einen Heartbeat?
Es handelt sich um virtualisierte Knoten. Es Test zeigt, das suseconfig
weniger als 8 s braucht.
Bernd
schrieb Massimo Rosen <mros...@SPAMcfc-it.de>:
> (...)
> das ändern des DNS Servers hätte schonmal nicht zu
> irgendeiner Veränderung an einer anderen Stelle des Netzes führen
> dürfen, und genausowenig zu einem Neustart des Netzwerks.
OK, es hätte ausgereicht, wenn der (DNS-)resolver von der neuen
> irgendeiner Veränderung an einer anderen Stelle des Netzes führen
> dürfen, und genausowenig zu einem Neustart des Netzwerks.
(DNS-)Konfiguration erfahren hätte. Aber YaST lässt halt zum Schluss
immer suseconfig laufen, da ist ein "rcnetwork restart" mit bei. Das mag
man nicht gut finden, dass ist aber so.
>
> Offensichtlich hat aber Yast *doch* einen Neustart des Netzwerks
> losgelassen (andernfalls wären die cluster IPs ja nicht weg), und
> widerum dieser Neustart des Netzwerks hätte eben normalerweise einen
> sofortigen Failover der Clusterressource(n) auslösen *müssen*.
> Genauso wie z.B rausziehen des Netzwerkkabels das sofort auslöst.
wurde? Und gibt es im Standard nicht alle 2 s einen Heartbeat?
Es handelt sich um virtualisierte Knoten. Es Test zeigt, das suseconfig
weniger als 8 s braucht.
Bernd
Massimo Rosen
Aug 5, 2014, 2:44:39 AM8/5/14
to
Hallo.
On 01.08.2014 15:08, Bernd wrote:
> OK, es hätte ausgereicht, wenn der (DNS-)resolver von der neuen
> (DNS-)Konfiguration erfahren hätte. Aber YaST lässt halt zum Schluss
> immer suseconfig laufen, da ist ein "rcnetwork restart" mit bei. Das mag
> man nicht gut finden, dass ist aber so.
Offensichtlich. Reichlich dämlich...
>>
>> Offensichtlich hat aber Yast *doch* einen Neustart des Netzwerks
>> losgelassen (andernfalls wären die cluster IPs ja nicht weg), und
>> widerum dieser Neustart des Netzwerks hätte eben normalerweise einen
>> sofortigen Failover der Clusterressource(n) auslösen *müssen*.
>> Genauso wie z.B rausziehen des Netzwerkkabels das sofort auslöst.
>
> Hm, war es nicht mal so, das der Knoten erst nach 4 Heartbeats gekillt
> wurde? Und gibt es im Standard nicht alle 2 s einen Heartbeat?
Wenn der Cluster nicht *weiß* dass es ei nProblem gibt, ja. Wenn also
irgendwo im Netz etwas nicht klappt was der Cluster bzw. das OS nicht
auf anderem mitbekommen kann. Wenn aber eine Clusternode z.B. den Link
auf Ihrer Netzwerkkarte verliert, dann *weiß* sie das sofort (weil der
Netzwerkkartentreiber dem OS das sagt!), und reagiert auch sofort. In
den Anfängen des Clusters hatten einige Netzwerkkartentreiber für
Netware das Problem, dass die Link Signalisierung nicht richtig
funktioniert hat. Dassselbe gilt analog auch für einen Neustart des
Netzwerks. Das ist ja nichts, was das OS erst per Timeout und
Übertragungsfehler rausfinden müsste...
CU,
Massimo
On 01.08.2014 15:08, Bernd wrote:
> OK, es hätte ausgereicht, wenn der (DNS-)resolver von der neuen
> (DNS-)Konfiguration erfahren hätte. Aber YaST lässt halt zum Schluss
> immer suseconfig laufen, da ist ein "rcnetwork restart" mit bei. Das mag
> man nicht gut finden, dass ist aber so.
>>
>> Offensichtlich hat aber Yast *doch* einen Neustart des Netzwerks
>> losgelassen (andernfalls wären die cluster IPs ja nicht weg), und
>> widerum dieser Neustart des Netzwerks hätte eben normalerweise einen
>> sofortigen Failover der Clusterressource(n) auslösen *müssen*.
>> Genauso wie z.B rausziehen des Netzwerkkabels das sofort auslöst.
>
> Hm, war es nicht mal so, das der Knoten erst nach 4 Heartbeats gekillt
> wurde? Und gibt es im Standard nicht alle 2 s einen Heartbeat?
irgendwo im Netz etwas nicht klappt was der Cluster bzw. das OS nicht
auf anderem mitbekommen kann. Wenn aber eine Clusternode z.B. den Link
auf Ihrer Netzwerkkarte verliert, dann *weiß* sie das sofort (weil der
Netzwerkkartentreiber dem OS das sagt!), und reagiert auch sofort. In
den Anfängen des Clusters hatten einige Netzwerkkartentreiber für
Netware das Problem, dass die Link Signalisierung nicht richtig
funktioniert hat. Dassselbe gilt analog auch für einen Neustart des
Netzwerks. Das ist ja nichts, was das OS erst per Timeout und
Übertragungsfehler rausfinden müsste...
CU,
Massimo
Bernd
Aug 5, 2014, 3:24:54 AM8/5/14
to
Am Tue, 05 Aug 2014 08:44:39 +0200
schrieb Massimo Rosen <mros...@SPAMcfc-it.de>:
> > Hm, war es nicht mal so, das der Knoten erst nach 4 Heartbeats
> > gekillt wurde? Und gibt es im Standard nicht alle 2 s einen
> > Heartbeat?
>
> Wenn der Cluster nicht *weiß* dass es ei nProblem gibt, ja. Wenn also
> irgendwo im Netz etwas nicht klappt was der Cluster bzw. das OS nicht
> auf anderem mitbekommen kann. Wenn aber eine Clusternode z.B. den
> Link auf Ihrer Netzwerkkarte verliert, dann *weiß* sie das sofort
> (weil der Netzwerkkartentreiber dem OS das sagt!), und reagiert auch
> sofort. In den Anfängen des Clusters hatten einige
> Netzwerkkartentreiber für Netware das Problem, dass die Link
> Signalisierung nicht richtig funktioniert hat. Dassselbe gilt analog
> auch für einen Neustart des Netzwerks. Das ist ja nichts, was das OS
> erst per Timeout und Übertragungsfehler rausfinden müsste...
Ah ja,
danke für die Erklärung! Wieder was gelernt :-)
Bernd
schrieb Massimo Rosen <mros...@SPAMcfc-it.de>:
> > Hm, war es nicht mal so, das der Knoten erst nach 4 Heartbeats
> > gekillt wurde? Und gibt es im Standard nicht alle 2 s einen
> > Heartbeat?
>
> Wenn der Cluster nicht *weiß* dass es ei nProblem gibt, ja. Wenn also
> irgendwo im Netz etwas nicht klappt was der Cluster bzw. das OS nicht
> auf anderem mitbekommen kann. Wenn aber eine Clusternode z.B. den
> Link auf Ihrer Netzwerkkarte verliert, dann *weiß* sie das sofort
> (weil der Netzwerkkartentreiber dem OS das sagt!), und reagiert auch
> sofort. In den Anfängen des Clusters hatten einige
> Netzwerkkartentreiber für Netware das Problem, dass die Link
> Signalisierung nicht richtig funktioniert hat. Dassselbe gilt analog
> auch für einen Neustart des Netzwerks. Das ist ja nichts, was das OS
> erst per Timeout und Übertragungsfehler rausfinden müsste...
danke für die Erklärung! Wieder was gelernt :-)
Bernd
0 new messages