Qualitäts-Software
30. November 2007 | 
Autor: Gegeben Redhat Enterprise Linux AS 4 Update 6 mit neuesten Updates:
[root@zapbrannigan ~]# system-config-cluster
Traceback (most recent call last):
File "/usr/sbin/system-config-cluster", line 52, in ?
from ConfigTab import ConfigTab
File "/usr/share/system-config-cluster/ConfigTab.py", line 27, in ?
from ConfigTabController import ConfigTabController
File "/usr/share/system-config-cluster/ConfigTabController.py", line 35, in ?
from FaildomController import FaildomController
File "/usr/share/system-config-cluster/FaildomController.py", line 213
if val == "Yes" or val == "yes" or val="1":
^
SyntaxError: invalid syntax
Dafür gibt es natürlich auch einen Bug-Report. Am besten finde ich die letzte Zeile:
Looking for qa ack…please.
Die spannende Frage ist doch: wo war die Qualitäts-Sicherung vor Auslieferung des kaputten Programmes?
Schlagworte:
I am the server with no name – zapbrannigan at your service.
Ich für meinen Teil bin froh, mit diesem Blogeintrag die Bestätigung dafür bekommen, daß meine Versuche mit der Clusterconfig unter CentOS nicht ausschließlich an meiner eigenen Unzulänglichkeit gescheitert sind.
Dann doch lieber Heartbeat und DRBD. Die sind von der Papierform zwar bei weitem nicht in der Lage, das zu leisten, was der GFS-Cluster von Redhat angeblich leistet, aber funktionieren. Einfach so. Keep it simple, stupid.
@martin: Du hast Recht, system-config-cluster ist eine Zicke, die nichtmal in der Lage ist eine syntaktisch richtige Konfiguration zu erstellen. Da geben sich weder CentOS noch RHEL irgendetwas. Beide machen intressanterweise die gleichen Fehler.
Die Frage ist halt, ob man eine fertige Lösung haben will oder sich selbst etwas zusammenbaut.
Das letzte mal als ich gekuckt habe, _war_ Heartbeat eine fertige Lösung.
Die Frage läuft also darauf hinaus, ob man die nicht funktionierende mitgelieferte Software von RedHat einer funktionierenden, dokumentierten und ernsthaft betriebenen (das sind die Voraussetzungen) Third-Party-Lösung vorziehen will. Wenn man glaubt, daß die Arbeit getan ist, wenn man dem Anbieter die Schuld in die Schuhe geschoben hat, kann man durchaus bei der erstgenannten Variante bleiben.
@martin: Hm, ich kenne nur sorgsam handgepatchte Heartbeats. Die tun, keine Frage, aber fertig sah das bist jetzt nicht für mich aus. Heartbeat hat aber einen Vorteil gegenüber der Redhat-Lösung: es kommt auch mit seriellen Heartbeats klar.
DRBD und Heartbeat funktionieren – solange man sich an gewisse Spielregeln hält. Sonst hat man schnell mal einen inkonsistenten Zustand nach einem Failover.