Wartungsarbeiten

Kibelka.de

Aktuelles 

Mitmachen 

Liebe Mitglieder,

wie bereits vorangekündigt, werden wir an diesem Wochenende, ggf. bis
zum Montag, den 14.5., auf einen neuen Server umziehen. Der Umzug wird
ungefähr nach folgendem Plan ablaufen:

        http://mi.hostsharing.de/todos.html

Es gibt eine geplante Downtime am Sonntag-Vormittag von ca. 8:00h - ca.
11:00h. Diese betrifft alle Dienste ausser HTTP mit statischen Seiten.
In dieser Zeit werden die Daten auf den neuen Server übertragen, die
geplante Downtime aller Dienste, die Daten schreiben können, verhindert
dabei, dass es zu Inkonsistenzen kommt. Logfiles werden separat 
behandelt. Für den Fall, dass es am Wochenende zu unerarteten 
Verzögerungen kommt, verschiebt sich diese Auszeit sich auf Montag ca. 
6:00h - 9:00h.

Wenn in euren DocumentRoot-Verzeichnis eine Datei outage.php oder im 
cgi-Verzeichnis eine outage.pl liegt, dann wird diese während des 
tatsächlichen Ausfalls für jede URL unter der Domain angezeigt. Diese 
Umleitung werde ich zentral für MUA und SUA Pakete für die Zeit des 
tatsächlichen Ausfalls dynamischer Seiten aktivieren, in QVS Paketen 
werde ich nur nach einer solchen deaktiven (auskommentierten) 
Redirection suchen und diese aktivieren.

Das outage.php sollte den HTTP-Status 500 (Service Unavailable) liefern
und das Caching verhindern, damit wird verhindert, dass diese Seite in
Suchmaschienen aufgenommen wird und erreicht, dass Caches noch
stundenlang den Ausfall "simulieren". Hier der Code für php (unbedingt
VOR jeder andern Ausgabe, da man hinterher keine Header mehr setzen
kann):

        header("Expires: Mon, 1 Jan 1999 00:00:00 GMT");
        header("Last-Modified: " . gmdate("D, d M Y H:i:s") ." GMT");
        header("Cache-Control: no-cache");
        header("Pragma: no-cache");
        header("Cache-Control: post-check=0, pre-check=0");        
        header("Status: 500 Service Unavailable");

Desweiteren ist voraussichtlich ein Umkonfigurieren der User (passwd),
Domain-Admin-Zuordnung, E-Mail-Adress-Zuordnung (virtusertable) und
E-Mail-Aliases (aliases) und Zonefiles (pri.*) sowie Domain-Aufgräge 
für weitere ca. 12-24 Stunden nicht möglich (Änderungen werden dann 
einfach für diese Zeit nicht übernommen. Ein Umkonfigurieren der 
Zonefiles sollte ausserdem bereits jetzt unterlassen werden, um den 
Umzug der betreffenden Domain nicht zu gefährden. 

Nun ein paar Daten zu unserem neuen Server:

        CPU:                    Dual Pentium III (Coppermine) mit je 1 GHz 

        RAM:                    1 GB

        Festplatten:            4 U2SCSI mit je 10.000/min und 18 GB
                                als RAID-10 geschaltet => 36 GB Kapazität

        IP-Nummern:             maximal 50 (derzeit 10: 66.70.34.150ff)

        Inklusiv-Traffic:       200 GB / Monat

        Bandbreite:             100 Mbit/s ungedrosselt

        Betriebssystem:         Debian Linux 2.2 Woody

        Kernel:                 Linux 2.4.4     

Die Installation durch Datapipe lief nicht ganz problemlos, da sich das
RAID-System zunächst nicht unter Debian aktivieren ließ. Aber im
Endeffekt haben wir den Rechner nur mit etwa. 3 Stunden Verspätung
gehabt, wobei es danach noch einige Nachbesserungen durch Datapipe gab.

Die IP-Nummern werden wie folgt verteilt:

        66.70.34.150    hsh00, inkl. Nameserver
        66.70.34.151    MUAs ohne eigene IP#
        66.70.34.152    SUAs ohne eigene IP#
        66.70.34.153    frei    
        66.70.34.154    frei
        66.70.34.155    frei
        66.70.34.156    frei
        66.70.34.157    QVS mas00
        66.70.34.158    QVS mih00
        66.70.34.159    QVS rad00

Wir vergeben IP#n ab jetzt nach der neuen Regel: eigene IP# nur, wenn
diese aus technischen Gründen benötigt wird. Denn wir werden deutlich
mehr als 50 Pakete auf diesem Rechner hosten können und es kann auch mal
gute Gründe geben, einzelnen Pakete mehrere IP#n zu geben. Bei der
Anforderung weiterer IP#n müssen wir jetzt, ähnlich wie in Deutschland,
darlegen, wofür wir die bisherigen benötigt haben, wobei die Maßstäbe
bei weitem nicht so streng wie beim RIPE sind.

Nochmals weise ich darauf hin, dass keiner von uns Hostmastern Erfahrung
mit einem solchen Umzug hat. Falls es also zu unangekündigten Problemen
kommen sollte, bitten wir schon im Vorfeld um Entschuldigung. Aber es
kann auch durchaus sein, dass der eigentliche Umzug schneller als die
genannten 3 (Kern) bis 27 (bis alle Dienste wieder laufen) Stunden 
abläuft.

Auf Gutes Gelingen!

        Michael