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

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

Wenn beide Server perfekt laufen und sich die Arbeit aufteilen sollte beim Laden der Grafiken bei m0rphex nochmal eine kleine Geschwindigkeitssteigerung merkbar sein…

Die Leistungsdaten laut Beschreibung:

AMD Athlon X2 4200+
2 GB RAM
2*300GB SATA HDD

Drin ist jedoch ein AMD Athlon(tm) 64 X2 Dual Core Processor 4600+, sowas nen ich mal Kundenservice vom Feinsten :D

Erstmal muss der Server ins Rescue System, damit man in Ruhe die Partitionstabellen von den Festplatten schreiben. Wenn dieser gestartet ist kann man z.B mit fdisk die Partitionstabellen von /dev/sda und /dev/sdb je nach Wunsch bearbeiten. Bei uns wird auf diesem Server aus mehreren Gründen ein recht einfaches System genutzt. 2gb Swap ( SDA(B)1 & Rest auf / ( SDA(B)2.

Wenn die Partitionstabelle für beide Laufwerke gleich ist geht’s an installieren des Raids.

mdadm -Cv /dev/md0 - l1 -n2 /dev/sda2 /dev/sdb2

Dieser Befehl erstellt den Raid Array für /, die Swap Partition zu spiegeln wäre unnötig. Jetzt muss man ne Weile warten bis die Festplatten synchron sind, alle Daten von /dev/sda2 werden auf /dev/sdb2 gespiegelt. Den aktuellen Stand des Vorgangs kann man mit

cat /dev/mdstat

abfragen. Das sieht dann z.B so aus:

Personalities : [raid1]
md0 : active raid1 sdb2[1] sda2[0]
290937024 blocks [2/2] [UU]
[==>..................] resync = 13.9% (40574848/290937024) finish=73.7min speed=56547K/sec

Zu diesem Zeitpunkt ist der Raid Array zu 13,9% fertig synchronisiert. Momentan arbeitet der Vorgang sich mit einer Geschwindigkeit von 56547 Kilobyte pro Sekunde voran und wird vorausichtlich noch 73 Minuten dauern.

Wenn der Vorgang abgeschlossen ist sieht das Ganze so aus:

Personalities : [raid1]
md0 : active raid1 sdb2[1] sda2[0]
290937024 blocks [2/2] [UU]unused devices:Jetzt kann es mit dem erstellen eines Dateisystems weitergehen. Ein ext3 System kann man z.B. so erstellen:

Jetzt kann es mit dem erstellen eines Dateisystems weitergehen. Ein ext3 System kann man z.B. so erstellen:mkfs.ext3 /dev/md0 

Das Raid ist jetzt mit Dateisystem fertig, nun muss man je nach Wunsch ein bestimmtes Betriebssystem installieren, ich verwende hier den System Installer von Hetzner, der im Rescue System verfügbar ist.