Es ist geschafft, der Server ist komplett auf die neue Maschine umgezogen und nun auch per IPv6 erreichbar.

Seit einigen Tagen hab ich einen eigenen Root-Server angemietet bei Webtropia in Düsseldorf. Wenn man dann schon einen Server aufsetzt, dann gleich richtig. Also Raid, Virtuelle Maschinen (via KVM), LVM und natürlich IPv6.

Grundsetup auf der Maschine ist ein Debian Lenny mit zwei Festplatten (erste Partition Swap, zweite raid1)

IPv6 Tunnel mit Ubuntu

Für letzteres muss ich erstmal meinem Ubuntu IPv6 beitreiben. Da mein Provider noch keine IPv6 Adressen verteilt, musste eine Tunnel-Lösung her. Entschieden hab ich mich letztendlich für Hurricane Electric, keine Ahnung warum, IPv6 Tunnel Anbieter gibt es ja genug.

Zur Einrichtung einfach auf deren Seite, anmelden und die Daten in die /etc/network/interfaces eintragen:

auto he-ipv6
iface he-ipv6 inet6 v4tunnel
     endpoint IPv4_ENDOINT
     address  IPv6_ADRESSE
     netmask  64
     up ip -6 route add default dev he-ipv6
     down ip -6 route del default dev he-ipv6

Dann per "sudo ifup he-ipv6" das Interface starten. Testen kann man die IPv6 Verbindung so:

$ ping6 -n -c 4 heise.de
PING heise.de(2a02:2e0:3fe:100::8) 56 data bytes
64 bytes from 2a02:2e0:3fe:100::8: icmp_seq=1 ttl=59 time=27.8 ms
64 bytes from 2a02:2e0:3fe:100::8: icmp_seq=2 ttl=59 time=25.7 ms
64 bytes from 2a02:2e0:3fe:100::8: icmp_seq=3 ttl=59 time=27.2 ms
64 bytes from 2a02:2e0:3fe:100::8: icmp_seq=4 ttl=59 time=25.8 ms

--- heise.de ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 25.770/26.674/27.866/0.912 ms

Die Verbindung steht

EXT3 und Linux Software Raid verkleinern

Als nächstes musste ich Platz schaffen auf dem Server für das LVM. Das Grundsetup sind zwei Festplatten, die jeweils erste Partition ist 1GB groß und Swap, die zweite Partition belegt den Rest der Platte und ist als Softwareraid 1 zusammengeschaltet.

Layout sda und sdb

Nun muss die zweite Partition verkleinert werden, dabei muss man von innen nach außen vorgehen. Erst das Dateisystem verkleinern, dann das Raid und dann die Partitionen auf den beiden Platten. Ich hab mir das verkleinern des Raids gespart und folgendes gemacht:

• Server im Rescue Modus hochfahren
• Verkleinern des Dateisystem
• Raid 1 anhalten
• Raid 1 zerstören
• Partition 2 verkleinern mit cfdisk
• Partitionstabelle von sda auf sdb kopieren
• Raid neu anlegen
• Dateisystem auf Partitionsgröße vergrößern
• Abschließender Check

e2fsck -f /dev/md0
resize2fs -p /dev/md0 9G
mdadm --stop /dev/md0
mdadm --zero-superblock /dev/sda2
mdadm --zero-superblock /dev/sdb2
cfdisk /dev/sda
sfdisk -d /dev/sda | sfdisk /dev/sdb --force
mdadm --create --assume-clean --level=1 -n2 /dev/md0 /dev/sda2 /dev/sdb2
resize2fs -p /dev/md0
e2fsck -f /dev/md0

Wichtig ist beim neu anlegen des Raids das "--assume-clean", da die Daten auf den beiden Partitionen ja korrekt sind, anderenfalls würden alle Daten verloren gehen auf den beiden Partitionen. Ich hab das Dateisystem auf 9GB geschrumpft, per cfdisk die Partition /dev/sda2 auf 10GB verkleinert. Mit dem abschließenden resize2fs Aufruf wird das Dateisystem dann wieder auf die volle Partitionsgröße ausgedehnt.

Das neue Layout

Das LVM ist stand jetzt noch nicht angelegt, das kommt in einem späteren Schritt. Aber soweit mal der Plan. Jetzt erstmal den Server neu starten und hoffen, dass er sauber hoch fährt :-)

LVM Anlegen

Wenn der Server sauber hochgefahren ist, dann kann man auf der freien Partition auf sda und sdb ein Raid 1 anlegen und darin dann das LVM anlegen.

• Raid 1 anlegen
• LVM Physical Volume anlegen
• LVM Volume Group anlegen
• LVM Logical Volume anlegen

mdadm --create --level=1 /dev/md1 -n2 /dev/sda3 /dev/sdb3
pvcreate /dev/md1
vgcreate -s 16M vg0 /dev/md1
lvcreate -L 10G -n vm01 vg0

Jetzt ist das LVM erzeugt, und ich hab eine 10 GB große Partition angelegt, die als Root-Laufwerk für meine erste virtuelle Maschine dienen darf.

KVM einrichten

aptitude install kvm libvirt-bin

Als erstes habe ich dazu den Rechner auf bridged Networking umgestellt. Dazu einfach folgendes in die /etc/network/interfaces reinschreiben:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
	address DEINE_IPv4
	netmask IPv4_NETMASK
	broadcast IPv4_BROADCAST
	gateway IPv4_GATE
	bridge_ports eth0
	bridge_fd 9
	bridge_hello 2
	bridge_maxage 12
	bridge_stp off
iface br0 inet6 static
	address DEINE_IPv6
	netmask 64
	up ip -6 route add IPv6_GATEWAY dev br0 
	down ip -6 route del IPv6_GATEWAY dev br0
	up ip -6 route add default via IPv6_GATEWAY dev br0
	down ip -6 route del default via IPv6_GATEWAY dev br0
	pre-up modprobe ipv6
	bridge_ports eth0
	bridge_fd 9
	bridge_hello 2
	bridge_maxage 12
	bridge_stp off

Dann per "/etc/init.d/networking restart" das alles neu laden, danach sollte man auch vom Server IPv6 Adressen anpingen können:

$ ping6 heise.de -n -c4
PING heise.de(2a02:2e0:3fe:100::8) 56 data bytes
64 bytes from 2a02:2e0:3fe:100::8: icmp_seq=1 ttl=58 time=5.87 ms
64 bytes from 2a02:2e0:3fe:100::8: icmp_seq=2 ttl=58 time=5.70 ms
64 bytes from 2a02:2e0:3fe:100::8: icmp_seq=3 ttl=58 time=6.15 ms
64 bytes from 2a02:2e0:3fe:100::8: icmp_seq=4 ttl=58 time=5.44 ms

--- heise.de ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 5.445/5.794/6.159/0.265 ms

Wenn das geht und die IPv4 Verbindungen auch noch funktionieren, dann kann man jetzt die virtuelle Maschine starten. Ich hab mir hierzu ein aktuelles CD-Image von debian.com gezogen, mit dem ich die Installation starten kann:

virt-install --connect qemu:///system -n vm01 -r 512 -f /dev/vg0/vm01 -c debian-6.0.0-amd64-netinst.iso
--vnc --os-type linux --os-variant debianLenny --accelerate --network=bridge:br0 --hvm

• -r 512: 512 MB Ram zuweisen
• -f /dev/vg0/vm01: Das Laufwerk, das der Maschine als Festplatte gegeben wird
• -c debian-6.0.0-amd64-netinst.iso: Image für CD-ROM Laufwerk
• --vnc: Damit ich per VNC drauf komm :)
• --network=bridge:br0: Netzwerkverbindung für diese VM über unser bridged Interface

Der Rest kann in der Manpage nachgelesen werden.

Damit läuft die Maschine und man kann per VNC drauf. Ich hab mir dazu auf meinem Ubuntu Desktop virt-manager installiert, damit kann man sich dann sehr bequem auf den virtuellen Maschinen einloggen und auch neue anlegen.

Zur Installation eines IPv6 only Guest noch folgende Hinweise:

• IPv6 Nameserver in die /etc/resolv.conf eintragen
• IPv6 Adresse eintragen und die Routen zum IPv6 Gateway eintragen
• bei einem Debian Guest noch beachten, dass die Mirrors in der /etc/apt/sources.list per IPv6 erreichbar sind

Nachdem ich ja neulich einen V-Server-Test hier hatte und einige Werte veröffentlichte, hat sich vor ein paar Tagen ein Vanager-Mitarbeiter bei mir gemeldet. Er sei überzeugt von der Performance seiner Server und hat mir angeboten, dass System erneut zu testen. Ich hab jetzt einen neuen Zugang bekommen und kann einen Vanager-V-Server drei Monate lang kostenlos testen. Natürlich, um das vergleichen zu können, hab ich den gleichen Tarif gewählt.

Sobald ich Zeit hatte und Test-Ergebnisse vorliegen, werde ich die hier veröffentlichen.

Update (24.09. 08:10)

So, Server getestet und für gut befunden, seht selbst...

Neulich kam eine E-Mail von Domainfactory. Dort hoste ich dieses Blog hier, nur Hosting, die kümmern sich um alles (kein vServer, kein Root-Server, ...). In dieser Mail stand drin, dass die MySQL-Server umgestellt werden. Und zwar sind die im Moment auf einem extra Server drauf und werden jetzt auf den Rechner gezogen, auf dem auch dein Web-Space liegt. Das soll mir Vorteile bringen. Tut es aber nicht, denn die Leistung, die vorher zwei Rechner erbracht haben, soll ab dann nur noch durch einen Rechner erbracht werden, was für mich bedeutet, dass ich zwar weiterhin den vollen Betrag monatlich abdrücken muss, aber weniger Leistung erhalte.

Aus so ziemlich diesem Grund bin ich damals von Host-Europe weg, weil da eben Datenbank und Web-Server auf der gleichen Maschine waren und da kam es dann regelmäßig am Wochenende dazu, dass die Datenbank nicht mehr erreichbar war.

Also hab ich mich entschieden, mal mit einem vServer zu spielen und zu sehen, was ich da so rausholen kann. Dazu bieten Server4You und Vanager kostenlose Testsysteme an, die exakten so eingestellt sind, wie der Server, den man später will. Server4You bietet vier Tage und Vanager sieben Tage Test an, ohne das es was kosten würde und ohne dass anschließend ein Vertrag anläuft. Nach dem Testzeitraum wird der vServer platt gemacht und ich komm einfach nicht mehr drauf, fertig.

Der Benchmark wird ausgeführt auf die Startseite meines Blogs, davon hab ich eine Kopie angefertig, die ich dann auf dem Server einspiele. Zum Test wird siege benutzt:

siege -t10s -c 100 -b http://URL/

Domainfactory

Läuft ja alles schon (MySQL5, Apache und PHP5, kein XCache), also hier die Ergebnisse:

• Transactions: 386 hits
• Availability: 100.00 %
• Elapsed time: 9.74 secs
• Data transferred: 7.83 MB
• Response time: 1.28 secs
• Transaction rate: 39.63 trans/sec
• Throughput: 0.80 MB/sec
• Concurrency: 50.64
• Successful transactions: 386
• Failed transactions: 0
• Longest transaction: 6.55
• Shortest transaction: 0.13

Server4You

Ich hab den Testzugang bei Server4You am 17.07.2008 gegen Mittag geordert, es kam dann auch sofort eine Mail, dass man sich nun darum kümmert und ich dann die Zugansdaten bekomme.

Am 21.07. kamen dann die Zugangsdaten zu dem Server. Drauf war ein Debian Sarge (3.1), welches ich erstmal auf ein Edge (4.0) aktualisiert hab. Nach dem ich beim ersten mal was falsch gemacht hab und die Maschine nicht mehr gebootet hat, hab ich im Backend einfach das 3.1er Debian wieder hergestellt und nochmal ein update gemacht. Nach dem Reboot ging das System dann. Danach erst mal mit Lighttpd, MySQL 5, PHP5 und XCache ausstatten und testen.

• Transactions: 526 hits
• Availability: 100.00 %
• Elapsed time: 9.64 secs
• Data transferred: 12.21 MB
• Response time: 1.61 secs
• Transaction rate: 54.56 trans/sec
• Throughput: 1.27 MB/sec
• Concurrency: 87.84
• Successful transactions: 526
• Failed transactions: 0
• Longest transaction: 4.82
• Shortest transaction: 0.21

Hardware: 15 GB Webspace, 1,5 TB Traffic, 384 MB-Ram (plus 768 MB FlexRam (wenn benötigt und verfügbar)), CPU 3x (was auch immer das heißt), Tarrif: vSERVER MEDIUM x2

Kosten: 7,85 € pro Monat die erste drei/sechs Monate, danach 16,85 €, keine Setupkosten

Vanager

Diesen Testzugang hab ich am 18.07.2008 gegen Mittag geordert, die Web-Seite zeigte mir dann an, dass ich demnächst (innerhalb von einer bis 72 Stunden) meine Zugangsdaten bekommen würde. Leider ist bis jetzt (22.07.) noch nichts gekommen, das Versprechen "Freischaltung innerhalb 1 - 72 Stunden" wurde leider nicht eingehalten, das hinterlässt schon mal keine guten Eindruck, aber gut, Server4You hat auch vier Tage gebraucht.

Eine Mail an den Support und schon hat es geklappt. Am 25.07. kamen meine Zugangsdaten. Ganz schick ist, dass da schon Debian 4.0 drauf ist, und ich nicht erst, wie bei Server4You das System updaten muss. Und dann folgte das gleiche wie bei Server4You: Ert mal den Server mit Lighttpd, MySQL 5, PHP5 und XCache ausstatten und testen, das Flog drauf laden und mit Siegen testen:

• Transactions: 183 hits
• Availability: 100.00 %
• Elapsed time: 9.76 secs
• Data transferred: 4.19 MB
• Response time: 2.98 secs
• Transaction rate: 18.75 trans/sec
• Throughput: 0.43 MB/sec
• Concurrency: 55.86
• Successful transactions: 183
• Failed transactions: 0
• Longest transaction: 6.62
• Shortest transaction: 0.24

Hardware: 16 GB Webspace, 600 GB Traffic, 384 MB Ram, 200% CPU (Was auch immer das heißt), Tarif: Profi.VPS (Linux)

Kosten: 14,99 € im Monat, 9,99 € Setupkosten

Fazit

Domainfactory liegt ziemlich in der Mitte, sowohl beim Preis, als auch bei der Leistung. Von Vanager hab ich mehr echt mehr versprochen, vor allem mehr Leistung. Wenn ich mich schon um den Server komplett selber kümmern muss, dann sollte der doch mehr Leistung bringen, als ein Homepage-Hosting, wo 300 Kunden sich einen Server teilen. Von Server4You war ich positiv überrascht, es ging eigentlich alles recht zügig, die Performance des Servers ist auch gut.

Update (27.07. 11:30)

Heute Nacht hat Domainfactory umgestellt und wie es nicht anders zu erwarten war, hier die aktuellen Benchmarks:

• Transactions: 140 hits
• Availability: 100.00 %
• Elapsed time: 9.99 secs
• Data transferred: 3.21 MB
• Response time: 3.59 secs
• Transaction rate: 14.01 trans/sec
• Throughput: 0.32 MB/sec
• Concurrency: 50.35
• Successful transactions: 140
• Failed transactions: 0
• Longest transaction: 9.26
• Shortest transaction: 0.15

Zusätzlich dazu ist es recht häufig jetzt schon vorgekommen, dass während des Benchmarks man nicht mehr auf die Seite drauf kommt, von wegen zu viele Verbindungen auf die Datenbank. Ganz schlecht. Deswegen werd ich da fristlos kündigen, mal sehen, ob die da mitmachen.

Update (24.09. 08:10)

Heute morgen hatte ich ein wenig Zeit, einen neuen Vanager Server zu testen. Gleiche Daten wie oben, der Benchmark lief aber deutlich besser:

• Transactions: 931 hits
• Availability: 100.00 %
• Elapsed time: 10.02 secs
• Data transferred: 24.16 MB
• Response time: 0.20 secs
• Transaction rate: 92.91 trans/sec
• Throughput: 2.41 MB/sec
• Concurrency: 18.50
• Successful transactions: 931
• Failed transactions: 0
• Longest transaction: 6.12
• Shortest transaction: 0.08

Mit 92 Hits/s ist Vanager damit absolute Nummer Eins. Die Frage, die ich jetzt noch habe ist: Warum war der Test-Server im ersten Test so miserabel schlecht?

Update (24.09. 14:05)

Da mit 2,4 MB/s meine Leitung am Limit war, hab ich nochmal gesieged, diesmal von einem Rechner aus, der mit 100Mbit/s angebunden ist:

• Transactions: 1350 hits
• Availability: 100.00 %
• Elapsed time: 10.08 secs
• Data transferred: 35.03 MB
• Response time: 0.15 secs
• Transaction rate: 133.93 trans/sec
• Throughput: 3.48 MB/sec
• Concurrency: 19.61
• Successful transactions: 1350
• Failed transactions: 0
• Longest transaction: 3.13
• Shortest transaction: 0.07

Perfekt