Drucken

Bitte loggen sie sich ein oder registrieren sie sich.
1 Stunde 1 Tag 1 Woche 1 Monat Immer
Einloggen mit Benutzername, Passwort und Sitzungslänge

[watchdog]

Hallo,

mir fällt bei der Neueinrichtung eines Kundenserver auf, dass die Zeitspanne zwischen Anforderung eines Re-Installs im Kundencenter bis zur tatsächlichen Fertigstellung unheimlich lang ist - was mir die Vermutung nahe brint, dass es möglicherweise sein könnte, dass diese Re-Installs gar nicht vollautomatisch ablaufen, sondern da erst jemand bei Ihnen tätig werden muss???

Ich frage dehalb, weil ich schon mal gerne einen Re-Install mache, obwohl das vielleicht gar nicht nötig wäre - also zu viel Aufwand = Re-Install - oder auch einfach "nur mal gucken", wie die Images so sind. Wenn ich aber weiss, dass da erst jemand bei Ihnen aktiv werden muss, um das duchzuführen, lass ich das natürlich lieber bleiben und beschränke mich auf Situationen, in denen es wirklich notwendig ist.

In Vorbereitung für Not-Situationen würde ich aber schon gerne wissen, was genau geschieht ("emergency management") und wie lange es dauert -  gestern hat eine Neu-Installation eines Images über 20 Stunden gedauert, heute sind es schon 10, aber es ist noch nix passiert - könnten Sie eine einplanbare Zeitdauer für die Re-Installationen angeben?

Es geht darum, dass es planbar, also voraussagbar wird, nicht um Kritik an der Geschwindigkeit - allerdings kann ich mir den Seitenhieb nicht verkneifen, dass das Einspielen eines Images hier bei mir selten länger als eine Stunde dauert, mit Kaffeepause  - aber ok, sicherlich ist das bei Ihnen ein viel komplizierterer Vorgang... ist also nicht vergleichbar...

Falls es doch vollautomatisiert ist: woran hakt es? Vielleicht könnte man das Verfahren öffentlich machen, also Open Source, dann könnte man die Bugs leichter finden und ausbügeln? Wäre es nicht von Vorteil für alle, das Potential Ihrer Kunden hier einzubinden? 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.

watchdog

[DirkatEUserv]

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

[watchdog]

Danke für die ausführliche Erläuterung.

Der Server, bei dem ich diese enormen Wartezeiten habe, scheint ja dann zu den Problem-Servern zu gehören (Location 1/9/1/1) - Re-Install von gestern abend ist ca. 20 Stunden später immer noch nicht durch.

Nun gut, Fehler in Hard- und Software und andere Probleme sind ja leider der Alltag in der IT - es kommt auf den Umgang damit an.

Daher wundert mich nun: wenn doch diese Probleme bekannt sind, warum bieten Sie dann solche fehlerhaften Systeme als neue "MiSurfi"-Server an?

Warum erhalte ich nicht einen Server aus den bereits umgerüsteten Locations Loc 1/4/xx/xx und 1/6/xx/xx

Und nochwas: warum erfährt man sowas nicht vorher? Ein solch übler Bug, der nach einem Web-Reset dazu führt, dass das System gar nicht mehr hoch kommt, ist doch wohl etwas, was man als Server-Admin wissen sollte, oder?

Natürlich plane ich bei grösseren Aktionen wie Server-Umzug oder auch nur einem Reboot immer das Worst-Case-Szenario ein - insofern trifft mich das jetzt nicht wirklich hart, die Sache verbrennt nur unheimlich viel Zeit, die ich anders hätte nutzen wollen diese Woche.

Aber wenn ich mir vorstelle, dass aus irgendeinem Grund ein Reset auf einem Live-System nötig wird und das dauert dann 20 Stunden - und ich erfahre erst hinterher davon, dass das an defekter Hardware liegt, das bekannt war und mir hat keiner vorher Bescheid gesagt - ich glaube, ich wäre da schon ein wenig enttäuscht, um es mal sanft zu formulieren.

[Ronny]

Hallo,

kurze Info von meiner Seite:

Das Installsystem ist optimiert, ein ReInstall benötigt ab Beauftragung im Kundencenter (sofern Sie den Reset hier mit aktivieren) bis zur Fertigstellung durchschnittlich:

Linux Images: je nach Hardware zwischen 10 und  30 Minuten
Windows:      je nach Hardware zwischen 30 und 120 Minuten
OpenBSD:      je nach Hardware zwischen 10 und  15 Minuten

Hierbei nutzen wir in Teilen openSource und geben Optimierungen auch an die Projekte zurück. Hier gab es einige Optimierungen in der Vergangenheit im Hintergrund, die einige neue Möglichkeiten eröffnen.

Kurz zu Ihrem Server / dem genannten Vorgang ansich:
Laut der History zu Ihrem Server, war dieser beim letzten Ticket, NICHT von dem genannten FSC Bug betroffen, sondern hing beim Grub. Die Kollegen haben daraufhin den Reset nochmals über das Resetsystem gestartet, der ReInstall wurde innerhalb 15 Minuten erfolgreich durchgeführt.
Die Kollegen schauen sich den Server nun genauer an, der Kollege Timo Engler hat bereits das bestehende Ticket wieder geöffnet und es an die Kollegen weitergegeben.

Bezüglich Webreset und dem "FSC" Bug:
Wir haben hier informiert: http://forum.euserv.de/index.php?topic=1587.0

Die Arbeiten zur Umrüstung auf das neue System sind im vollen Gange, allerdings benötigt eine derartige Umrüstung entsprechende Planung und Wartungsintervalle. Wir werden die Kunden informieren, sowie die Umschaltung auf das neue System bevorsteht (dazu werden auch Sie gehören).

Gruß Ronny

[watchdog]

OK, danke für die Angabe der Re-Install-Zeiten.

Laut der History zu Ihrem Server, war dieser beim letzten Ticket, NICHT von dem genannten FSC Bug betroffen, sondern hing beim Grub.

Für eine Re-Installation des Systems wird Grub auf dem Server benötigt?

Ihr Hinweis auf die Veröffentlichung des FSC-Problems zeigt ein Datum vom 24.Februar 2008 - das war vor zwei Jahren.

Sie haben heute noch Geräte im Einsatz, von denen seit zwei Jahren bekannt ist, dass diese möglicherweise fehlerhaft sind?

Das kann ich nicht glauben.

[timo]

Hallo,

der Server hing im Grub vom installiertem System, für eine ReInstallation ist natürlich kein Grub nötig.

Timo,

[watchdog]

Es ist doch auch für einen RESET völlig unerheblich, was mit grub ist, oder?
Selbst wenn der Bootsektor mit rosa Elefanten befüllt wäre, der RESET müsste ja dennoch stattfinden.

Hab mittlerweile einen neuen Server in der Location 1/10/3/1 - ein erster Re-Install scheiterte scheinbar zunächst wieder am RESET - nach ca. einer Stunde gabs im Kundencenter dazu auch eine Mitteilung (siehe Anhang) - allerdings gabs dann ca. eine weitere Stunde später doch ein neues System auf dem Server - allerdings bis jetzt noch keine Benachrichtigungs-Email, wie angefordert. Fühlt sich für mich so an, als ob da manuell nachgeholfen wurde, was ja auch sinnvoll ist - aber das Web-Reset-System scheint immer noch nicht besonders zuverlässig zu sein.

[timo]

Hallo,

es wurde kein Reset mit der ReInstallation beauftragt, daher wurde auch kein Reset durchgeführt. Daher wird der ReInstall mit dem nächsten Reset / Reboot gestartet.

Wenn Sie einen Reset eintragen und dann, bevor dieser ausgeführt wurde, erneut einen Reset eintragen, erhalten Sie genau diese Fehlermeldung. Dies ist etwas undurchsichtig, aber wir arbeiten auch hieran.

Fakt ist, Sie nutzen das neue Reset-System, hier können keine Probleme auftreten, das wird technisch abgesichert und realisiert.

Timo,

[watchdog]

es wurde kein Reset mit der ReInstallation beauftragt, daher wurde auch kein Reset durchgeführt.

Nein, das stimmt nicht - ich hab den Reset-Haken angekreuzt. Ich mach nächstes mal auch davon Screenshots.

Scheint jetzt jedenfalls mit dem neuen Server besser zu funktionieren - werde weiter testen.

Allerdings wird immer noch keine Benachrichtigungs-Email verschickt.

Es bleibt ein unangenehmer Nachgeschmack.

[timo]

Hallo,

Eine Benachrichtungs-eMail für was genau ? Bei einem WebReset können Sie den eMail haken aktivieren und Sie erhalten nach Ausführung des Resets eine entsprechende eMail.

Es gibt keine eMail, das der Install abgeschlossen ist.

Timo,

[watchdog]

Es gibt keine eMail, das der Install abgeschlossen ist.

Gut, ok, dann gibts keine Email bei Re-Install, Hauptsache es funktioniert einwandfrei.

Jetzt läuft es sauber und schnell - wäre das schon am Montag so gewesen, hätte ich jetzt noch drei weitere Server bei Ihnen.

Nunja, vielleicht hab ich diesmal einfach nur Pech - aber vielleicht hatte ich bisher einfach nur Glück und bin daher verschont geblieben von sowas.

Eine Frage noch: sind denn die Misurfis NEUE HARDWARE - oder sind die auch schon zwei Jahre gelaufen?

Danke für die Aufmerksamkeit.

[alexwille]

Eine Frage noch: sind denn die Misurfis NEUE HARDWARE - oder sind die auch schon zwei Jahre gelaufen?

...die Frage kannst Du Dir selbst beantworten mit einem Blick in die aktuelle CPU-Liste der Hersteller. Oder du schaust dir die Laufzeit der Festplatte der Kiste an. Für die paar Kröten sind die Misurfis jedenfalls super.

[BlueStar88]

[...]

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.

[...]

mit freundlichen Grüßen,
Dirk

Ich glaube ich bin gerade jetzt im Moment von diesem Bug (welchem jetzt auch immer) betroffen. Trotz Hard-Reset keine Erreichbarkeit des Rescue-Systems mehr.

Location 1/9/2/4, Misurfi M 2010

Habe dazu bereits eine eMail geschrieben. Apropos, warum gibts eigentlich kein Ticket-System, wo man den Status der Bearbeitung sehen kann? Ich gebe zu, ich habe erst wie blöd in der Kundenoberfläche nach sowas gesucht. ^^

Da ich das System selbst aufsetze (Partitionierung, Verschlüsselung, Kernel), wäre ich für ein zuverlässiges Rescue System dankbar. Ich benötige gerade in der Ersteinrichtung evtl. ein paar "Anläufe", bis es läuft. Eben wegen der bekannten Stichworte Bootloader, Kernel usw.



BlueStar88

[timo]

Hallo,

wir haben das bereits per eMail geklärt (jedenfalls, sagt mir die Lokation hier etwas ).

Der Bug tritt nur bei FSC Mainboards in Verbindung mit dem früheren Resetsystem auf. Er  äussert sich dadurch, das bei einem Reset der Server ausgeht, dies jedoch nicht in jedem Fall.
Daher wurde das neue Resetsystem entwickelt. Aktuell werden alle Server auf das neue Resetsystem umgezogen.
Da hier umfangreiche Vorbereitungen, wie auch Änderungen nötig sind, passiert dies Stückweise nach Lokation der Server.

Sollte dieser Fall eintreten, bitte direkt beim Support per eMail melden, bitte wenn möglich, immer gleich Lokation, Kundennummer und Vertragsnummer angeben, damit eine schnelle Bearbeitung sichergestellt werden kann.

Es gibt ein Ticketsystem, allerdings ist derzeit noch keine Integration in das Kundencenter verfügbar, wir arbeiten aber bereits daran.

Timo,

[BlueStar88]

Hallo,

wir haben das bereits per eMail geklärt (jedenfalls, sagt mir die Lokation hier etwas ).

[...]

Timo,

Yuup, sieht gut aus, bin nun auf den Beinen, es kann losgehen! ^^

Hab in der Offzeit a bisserl gestöbert und muß schon sagen, eine super Kommunikation hier! Was vergleichbares sucht man bei anderen Anbietern vergeblich, weiter so!


Blue