Weil mich mittlerweile einige Leute drauf angesprochen haben, hier ein kleines Statement:

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

m0rphex wird heute um 10.30 für einige Stunden offline gehen, weil wir einige wichtige Änderungen am System durchführen müssen damit m0rphex weiter wachsen kann. Die Änderungen sind leider nicht während des Betriebs möglich, daher müsst ihr einige Stunden ohne m0rphex auskommen :-)

In den letzten 48 Stunden haben wir zwei kurze und eine lange Downtime zu verzeichnen.

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!

Aufgrund einiger Systemupdates ( 2*250GB HDDs fuer Homer ) und einer DNS Änderung ist m0rphex momentan nur unter http://www3.m0rphex.com zu erreichen, dies wird sich im Laufe des Tages wieder ändern.

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

Nachdem nun fast alle Server auf dem neuesten Stand sind bzw erst vor kurzem aufgesetzt wurden muss nun noch Homer ( unser loadbalancer p4 2,0 ) mal ausgemistet und sauber neu aufgesetzt werden.

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

Vor dem heute Mittag eingerichteten lighttpd läuft jetzt noch ein Squid auf beiden Grafikservern als reverse proxy.

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)

Die beiden Grafikserver liefern die statischen Grafiken nun mit “lighttpd” aus, die dynamischen m0rphexshout Signaturen werden weiterhin von einem Apache generiert.

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”.