Zitat von der Webseite unseres Providers:

Störungsmeldungen

• 07.05.2007-21:31 Tiscali Uplink aufgrund eines Routerproblems derzeit nicht verfuegbar.

Aufgrund einer Störung unseres Uplink Routers zu Tiscali wird der Traffic derzeit über alternative Routen geleitet. Dabei kommt es insbesondere im Lambdanet Netzwerk zu erhöhten Latenzen. Wir arbeiten an der Störungsbeseitigung.

morphex ist momentan recht langsam, weil wir Wartungsarbeiten an einigen Servern durchführen und die vor circa 3 Wochen bestellten Server in das Cluster einfuegen. Weiterhin wechseln wir mit unserem Hauptdaten Server von einem 2*300GB Software Sata Raid auf einen Server mit Hardware Raid Controller.

Damit wir die Zeit wo m0rphex komplett offline ist möglichst klein halten, führen wir grade schon viele der Änderungen nebenbei aus, was in der momentanen Trägheit von morphex resultiert. Das ganze wird sich heute Nacht, spätestens aber morgen früh wieder ändern. Dann sind wir wie gewohnt oder noch schneller erreichbar ;)

Zu den Kommentaren und Wünschen zur Version 4.0 werden wir uns in Kürze hier im Blog äußern.

http://www.morphex.eu

Wenn wir genauere Infos über das Problem erhalten, werde ich es hier erläutern.

Als erstes waren wir am Donnerstag von circa 17.30h bis 22.30h nur schwer zu erreichen. Wir haben in der Zeit einen unserer Server mit zwei neuen 250GB Festplatten ausgestattet, um noch mehr Bilder speichern zu können. Eigentlich hatten wir vor alle Anfragen auf einen anderen Server umzuleiten, damit man nichts von der Umstellung bemerkt. Die TTL unseres DNS Eintrags für www.m0rphex.com hat uns aber einen Strich durch die Rechnung gemacht, die lokalen DNS Caches der Provider ( T-online, Ewetel, etc ) hatten die IP für www.m0rphex.com noch bis 22.30 zwischengespeichert, somit war das Aufrufen von m0rphex.com nicht ohne weiteres möglich. Jetzt werden sicherlich einige von euch denken, wir hätten einfach den DNS Eintrag ändern sollen und dann mit dem Abschalten des Servers warten sollen, dies war uns jedoch Aufgrund der drigenden Notwendigkeit der Festplatten Erweiterung leider nicht möglich :)

Im Laufe des Freitages kam es zu zwei weiteren kurzen Ausfällen, gegen 18.20 habe ich wichtige Sichterheitsupdates auf unserem Hauptsystem eingespielt, die nicht warten konnten. Der zweite Ausfall spielte sich gegen 23.30 ab. Hier kam es zu Problemen bei der Anbindung DTAG <-> Lambdanet, diese Probleme waren nach einigen Minuten aber beseitigt.

Weitere technische Fragen zu den Ausfällen gerne als Kommentar!

Mehr Infos zu den Upgrades und Änderungen gibts dann am Freitag.

Dazu gibts folgenden ganz geheimen Projekt Plan:

1. dns server für m0rphex.com werden geändert, ich leg vorher einträge auf ns servern an
2. wir ändern den A einträg für * und www auf andere ip
3. homer runterfahren wenn das dns überall geändert is (24h+)
4. formatieren homer + neu aufsetzen ( raid etc )
5. setzen ihn online
6. ändern den A eintrag zurück

.

Wird wohl in der nächsten Zeit passieren, hoffentlich ohne Ausfälle!

Wobei, ist schade um die schöne Uptime:

uptime
22:01:39 up 141 days, 2:33, 1 user, load average: 0.19, 0.22, 0.19

Die Anfragen an komplett statische Dateien ( css, banner, werbung, javascripte etc ) werden jetzt von diesem abgearbeitet, so sparen wir uns in 95% der Fälle den Zugriff auf die Festplatte, weil der Squid die häufig benötigten Dateien im Ram behält.

Unsere Squid-Config sieht momentan so aus:

smithers:/# cat /etc/squid/squid.conf
http_port 88.198.105.92:80 defaultsite=image1.m0rphex.fremaks.de
cache_peer 88.198.105.90 parent 80 0 no-query originserver
acl all src 0/0
http_access allow all
cache_dir diskd /squidcache 7000 16 256
cache_mem 128 MB
maximum_object_size_in_memory 500 KB

Wenn ihr über einen Squid von uns eine Datei bekommt, sieht das im HTTP-Header etwa so aus:

( In diesem Fall hatte der Squid die Datei schon zwischengelagert und die Abfrage wurde ohne den Lighttpd im Hintergrund abgearbeitet )

Server lighttpd/1.4.13
X-Cache HIT from static.88-198-224-164.clients.your-server.de
X-Cache-Lookup HIT from static.88-198-224-164.clients.your-server.de:80
Via 1.0 static.88-198-224-164.clients.your-server.de:80 (squid/2.6.STABLE5)

Der Lighttpd spart im Vergleich zum Apache in unserem Fall einiges an CPU Auslastung und braucht weniger Arbeitsspeicher. Weriterhin hab ich ihn nur mit dem beiden Modulen “mod_access” & “mod_alias” gestartet, das normalerweise aktivierte Modul “mod_accesslog” habe ich deaktiviert, um unnötige Schreibzugriffe auf die Festplatte einzusparen. Die vom Apache in unserem Fall benötigten PHP5 Module werden vom Lighttpd nicht geladen, er ist unserem Fall also wirklich ein “light-httpd”.