Hallo,
es gibt 2 Arten von Installationen bei Rootservern, die hier im Forum bereits schon vor einiger Zeit an anderer Stelle erläutert wurden. Gern aber noch einmal als Zusammenfassung:
1.) Erstinitialisierung:
Die Erstinitialisierung ist das
ERSTE Aufspielen des Betriebssystems mit Systemcheck. Hierbei werden RAM und Platten in der Regel besonders getestet um Fehler für den laufenden Betrieb auszuschliessen. Die Erstinstallation dauert verhältnismäßig lang, d.h. man kann 24-48h rechnen.
2.) Re-Installation:
Eine Reinstallation ist lediglich das Reinstallieren des Servers im laufenden Betrieb. Es werden keine besonderen Checks mehr durchgeführt, es werden lediglich alle Platten gelöscht, neu partitioniert und das OS aufgespielt. Je nach OS dauert das zwischen 15 und 120 Minuten. (z.B. SuSE dauert länger als Debian, Windows generell länger als Linux, Raid0 länger als Raid1, Raid generell läger als minimal usw.)
In unserem Rechenzentrum gibt es derzeit noch 2 Arten von geschalteten Servern:
1.) Server die "regulär" an das Stromnetz angeschlossen sind (Kaltgerätekabel -> Steckdose)
Diese Server werden mit dem früher eingesetzten Webresetsystem resettet, in dem virtuell der Resetknopf gedrückt wird.
Bei einem Reinstall passiert der Reset wie bei allen anderen Servern auch, bei Erstinitialisierung muss der Server am Netzschalter angeschaltet werden und läuft dann. Das führt bei der Erstinstallation zu einer (manuellen) Verzögerung, da wir nur einmal am Tag anschalten.
2.) Server mit EPC Stromsystem:
Seit 2008 werden alle Server an das neue EPC-System angeschlossen. Hierbei wird der Stromkreis durch ein System geschaltet, was den Server an bzw. ausschaltet. Bei einem Erstinstall wird der Server lediglich angeschaltet, bei einem Reset erfolgt ein hartes Aus- und Anschalten mit zeitlicher Verzögerung von einigen Sekunden, um die Hardware zu schonen. Erstinstalls werden hier entsprechend der Technik sofort nach Initialisierung über das KC2 ausgeführt.
Alle Server ab der "Location"-Angabe 1/13/xx/xx sind mit einer EPC ausgestattet. (Relevant sind die 1. und 2. Stelle, hochzählend) Das neue RZ Jena1-B wird generell nur EPC-Systeme nutzen.
Soweit zum Idealzustand.
Nun die Bugs:
"FSC-Bug", tritt nur bei Webresettern auf
Im Laufe unseres RZ-Betriebes haben wir einen fatalen Bug mit dem Webresetsystem und den FSC-Boards entdeckt. Es gibt dazu bereits einen Post hier im Forum. Die FSC-Boards schalten sich bei einem Reset in 50% der Fälle ab, wir müssen den Server manuell wieder anschalten. Die meisten Server stehen in Racks < 1/13 , sind aber meistens schon mit EPC's versorgt. Einzelne Server bilden die Ausnahme, wir sind aber bereits am umrüsten. (z.B. sind die Loc 1/4/xx/xx und 1/6/xx/xx schon komplett EPC versorgt.)
"CMOS-Bug"
Beim CMOS-Bug ist schlichtweg die BIOS-Batterie leer, die "PXE" als Default Bootmethode "vergessen" läßt und damit bei einem Reset/Reinstall wieder das alte System gestartet wird. Das können wir nicht detektieren, hier muss sich der Kunde bei uns melden und wir tauschen die Batterie aus, rekonfigurieren das BIOS und los gehts.
"RAM-Bug"
Wir haben seit 2007 vermehrt festgestellt, dass einige (nicht alle) RAM-Riegel nicht so arbeiten wie sie sollen. Bei einigen Servern führte das zu Problemen z.B. beim entpacken von grossen Files oder zum "Einschlafen" von Maschinen. Wir haben daher Ende 2008 den RAM Hersteller von MDT auf Kingston (teilweise auch Samsung) gewechselt und verbauen seit den Serien "Prime64" ausschliesslich diesen RAM. Tritt es bei Servern vorheriger Generationen auf, tauschen wir den RAM kostenfrei aus.
In den Images, die ich bisher kenne, sehe ich auch einige Probleme, Kleinigkeiten zwar, die aber korrigiert werden könnten - wenn man für sowas offene Repositories einrichtet mit TRAC (oder beliebigem Bugtracker), könnten Sie evtl. nicht nur Kraft und Energie sparen, sondern auch durch eine quasi-öffentliche QS die Qualität der Images erheblich erhöhen - wäre doch für Kunden und Euserv eine WIN-WIN Situation - plus die positive Publicity durch Bereitstellung eines interessanten OS-Projektes, plus evtl. Contributions von Interessierten.
Wir hatten uns bereits Gedanken über einen öffentlichen Bugtracker gemacht (intern haben wir einen). Das Problem sind hier nicht die gewollten und durchaus hilfreichen Bugreports, sondern die Supportanfragen die darüber reinkommen von Usern, die nicht wissen, was ein Bugtracker ist. Weiterhin ist es eine Gratwanderung zwischen "offen" und "zu offen". (Wir haben festgestellt, das der Wettbewerb gern von uns kopiert.)
Sofern Sie konkrete Vorschläge unter Berücksichtigung dieser Problematik haben, sind wir aber dafür immer offen!
mit freundlichen Grüßen,
Dirk