Neuere Distributionen, z.B. das Ubuntu das ich hier gerade verwende, formatiert die Festplatten richtig. Man kann das ganz einfach mit sfdisk überprüfen.

$ sfdisk -d /dev/sda
[...]
/dev/sda1 : start= 2048, size= 195313, Id=83, bootable

Die 1. Partition meiner SSD beginnt bei 1 MB, also bei LBA-Adresse 2048. Die Nummer der Start-Sektoren können ohne Rest durch 2048 dividiert werden.

CentOS formatiert die Festplatten auf die Startadresse 63 – wie bei 512-byte:

$ sfdisk -d /dev/sda
[...]
/dev/sda1 : start= 63, size= 208782, Id=fd

In einem Wiki-Eintrag von Thomas Krenn wird das alles noch mal im Detail beschrieben.

Beim Administrator’s Blog erschien heute ein Artikel der über die schlechte Performance der WD20EARS-Festplatten berichtet. Western Digital nennt die 4KB-Sektoren “Advanced Format”. In meinem letzten Blog-Eintrag ging es u.a. um die WD20EADS-Festplatten, die bei Manitu eingesetzt werden. Eigentlich – und das bestätigen meine Tests bei Manitu – sollten diese Festplatten 0,5kb Sektoren verwenden. Im Datenblatt steht dazu nichts, genauso wenig wie zu der MTBF, aber das ist ein anderes Thema. Google ist sich dazu auch nicht sicher.

Ich formatiere inzwischen alle System auf Startadresse 2048. Der Artikel beim Administrator’s Blog zeigt aber auch, dass man i.d.R. keine Desktop-Festplatten für einen Server verwenden sollte, zumindest wenn einem etwas an Reliabilität oder Performance liegt…

Bei den geschäftskritischen Diensten sind höhere Anforderungen notwendig, als es die Standardlösungen der Firma manitu bieten. Die wichtigsten Kriterien sind hochwertige Serverhardware, redundante Netzteile mit getrennten Stromkreisen, redundante interne Kommunikation (Cross-Over-Kabel und Vlan). Ich spreche hier ausdrücklich von Standardlösungen, Lösungen von der Stange, bzw. Angebote die auf der Homepage zu finden sind. Wir suchten eine kostengünstige Lösung.

Da wir relativ viele Dienste mit geringer Last als virtuelle Maschinen betreiben, benötigten wir eine Virtualisierungslösung. Die Anzahl der virtuellen Maschinen ergibt sich aus der Anzahl der Dienste (ein Dienst pro Server / virtueller Maschine). Ich wählte Xen als Hypervisor.

Im Februar bestellten wir zwei Root-Server XXLx4. Wenig Zeit später waren die Maschinen verfügbar. Danach begann die Qual…

Neben Xen als Hypervisor wählte ich CentOS als Distribution. Nach der Installation über das Rettungssystem von Manitu booteten die Server mit dem Xen-Kernel nicht. Die Server bei Manitu haben keine Remotmanagementkarte, für 25,00 EUR Tagesmiete kann ein KVM-Switch gemietet werden. Mit dem KVM-Switch war das Problem schnell zu finden, der Kernel darf nicht mit acpi=off gestartet werden, was bei Manitu mit dem selbstkompilierten Kernel standardmäßig der Fall ist.

Die nachfolgende Konfiguration lief problemlos.

Durch die Virtualisierung ist die Auswirkung eines Ausfalles eines physischen Servers relativ groß, die Kosten für einen Server jedoch relativ gering. Dadurch betreiben wir alle wichtigen Dienste (also jede VM) in einem Hochverfügbarkeitscluster (HA-Cluster). Sofern der Dienste (die Anwendung) keine Ausfallsicherheit per Design bietet. DNS ist ein klassisches Beispiel bei dem ein HA-Cluster nicht unbedingt notwendig ist.

Auch die Installation und Konfiguration der virtuellen Maschinen, der Cluster und der Anwendungen lief problemlos.

Für ein kleines privates Projekte installierte ich einen Hadoop-Cluster bestehend aus 3 Nodes und führte ein paar Berechnungen aus. Bei den Berechnungen bemerkte ich, dass ein physischer Server nicht mehr reagierte. Der Hard-Reset des manitu Supports bootete den Server wieder. Das Projekt war zu Ende und ich betrachtete die Angelegenheit nicht mehr aktiv.

Der Fehler trat immer wieder auf. Ich teilte die Dienste und die Last auf beide Maschinen auf, so dass eine Lastspitze in einer verteilten Anwendung regelmäßig dazu führte, dass beide Server nicht mehr reagierten. Manchmal konnte ich die Server noch über das Rettungssystem von Manitu zu einem Neustart bewegen – oft musste der Support helfen.

Das Problem bei Manitu musste erst mal warten, da auch die geschäftskritischen Dienste ein neues Rechenzentrum brauchten. Mit der gemachten Erfahrung wählte ich testweise KVM und machte nach der Installation ausgiebige Stresstests. Bis heute keinen Absturz oder ähnliche Probleme die mit Xen auftraten. Wobei ich hier auch schreiben muss, dass es sich um Redhat Enterprise  zertifizierte Dell PowerEdge Server handelt. Weder von der Hardware noch vom Preis vergleichbar mit den Servern bei Manitu.

Wir bestellten einen weiteren Server bei Manitu und wählten diesmal KVM als Hypervisor. Die Umstellung auf KVM war zeitintensiv, da viele Daten kopiert werden mussten und die virtuellen Maschinen so verschoben werden mussten, dass es nicht zu einer längeren Nichtverfügbarkeit kam. Seit einer Woche ist diese Umstellung abgeschloßen und es gab bisher noch keinen Ausfall. KVM läuft äußert stabil, auch Stresstests über einige Tagen liefen problemlos durch.

Der Support von Manitu reagierte während der ganzen Zeit schnell und hilfsbereit.

Unverständnis ruft die Wahl der Festplatten hervor. Bei uns sind in zwei Servern jeweils 4x 2TB Green-Modelle von Western Digital und in dem neueren Server 4x 2TB Samsung  EcoGreen verbaut. Die wenigsten werden doch 4TB (Raid10) oder 8TB (Raid0) in einem Rootserver benötigen und wenn dann noch der Hersteller über die eigenen Festplatten das Folgende schreibt:

Business Critical RAID Environments – WD Caviar Green Hard Drives are not recommended for and are not warranted for use in RAID environments utilizing Enterprise HBAs and/or expanders and in multi-bay chassis, as they are not designed for, nor tested in, these specific types of RAID applications. For all Business Critical RAID applications, please consider WD’s Enterprise Hard Drives that are specifically designed with RAID-specific, time-limited error recovery (TLER), are tested extensively in 24×7 RAID applications, and include features like enhanced RAFF technology and thermal extended burn-in testing.

Dazu kommt noch die schlechte Performance und das “Problem” mit den 4k-Sektoren.

Fazit: Zufrieden, aber nicht uneingeschränkt zu empfehlen – schade eigentlich.

Native Virtualisierung

Gemeinschaft ist eine Asterisk Distribution der Firma Amooma GmbH. Die Virtualisierung eines Asterisk-Servers bietet sich durch die typischerweise geringe Hardwareanforderung und das Bedürfnis nach hoher Verfügbarkeit geradezu an. Zumindest wenn man davon ausgeht, dass man ein Mediagateway für die Umsetzung IP <> ISDN verwendet. Die Virtualisierung einer PCI-Karte ist keine wünschenswerte Aufgabe, das macht keinen Spaß!

Citrix XenServer ist in einer kostenlosen Version auch für den kommerziellen Einsatz nutzbar. Mit der Software erhält man eine ausgereifte Virtualisierungslösung out of the box.

Paravirtualisierung

In diesem Artikel wird erklärt, wie man eine vollständig virtualisierte Linux Distribution in ein paravirtualisiertes System überführt. Gemeinschaft nutzt ein Debian Lenny; die Vorgehensweise unterscheidet sich nicht grundlegend zu anderen Distributionen.

1. Für die Installation der VM muss “Other install media” als Template und der Gemeinschaft Installer als ISO-Image ausgewählt werden.
2. Nach der Installation werden die XenServer Tools und der XenServer Kernel installiert. Dazu die CD mounten oder den Inhalt über scp auf die VM kopieren:
dpkg -i Linux/xe-guest-utilities_5.5.0-458_i386.deb
dpkg -i Linux/debian-generic/linux-image-2.6*

3. Mit der Paravirtualisierung wird sich das Blockdevice der Festplatte von hda in xvda ändern. In /etc/fstab und /boot/grub/menu.lst die entsprechenden Vorkommnisse ändern. Die Datei /etc/fstab ist selbsterklärend, in menu.lst an der folgende Stelle:
   title Debian GNU/Linux, kernel 2.6.29-xs5.5.0.14
root (hd0,0)
kernel /boot/vmlinuz-2.6.29-xs5.5.0.14 root=/dev/xvda1 ro quiet
initrd /boot/initrd.img-2.6.29-xs5.5.0.14

4. Wahrscheinlich wird im XenCenter der login prompt nicht mehr erscheinen, in der Datei /etc/inittab tty1 durch hvc0 ersetzen:
   # Format:
# :::
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
#
1:2345:respawn:/sbin/getty 38400 hvc0

5. Die VM mit poweroff herunterfahren.

Unter der Konsole des XenServers wird die eigentliche Virtualisierungsmethode umgestellt. Das muss übrigens nicht zwingend auf dem Pool Master durchgeführt werden.

1. Jeder VM ist einer UUID zugeordnet, diese kann mit dem Kommando xe vm-list herausgefunden werden.
2. Jetzt folgt die eigentliche Umstellung der Virtualisierungsmethode:
   xe vm-param-set uuid=<uuid> HVM-boot-policy=""
xe vm-param-set uuid=<uuid> PV-bootloader=pygrub
xe vm-param-set uuid=<uuid> PV-args="-- quiet console=hvc0"

3. Die virtuelle Festplatte ist noch nicht zum Booten bereiten. Für die Aktivierung wird die VBD-UUID benötigt, das Kommando xe vm-disk-list uuid=<uuid> liefert eine Liste der Blockdevices:
   Disk 0 VBD:
uuid ( RO) : <vb-uuid>
vm-name-label ( RO): Other install media (1)
userdevice ( RW): 0Aktivierung des Blockdevices:
   xe vbd-param-set uuid=<vb-uuid> bootable=true

Fertig! Viel Glück mit der Umsetzung.

…ich bin im Ausland und habe einen Rechner mit, der keine Windows Lizenz hat. Es ist ein Linuix installiert…

Es ging daraum, dass er mit diesem Rechner nicht auf XYZ Backoffice Software zugreifen kann. Recht hat er, aber mit einem Windows Terminalserver und rdesktop ist das nicht wirklich ein Problem.

which was pretty at the end of its capacities, dealing with as “little” as 50′000 new mails (sent & received) DAILY for our 1500 mail users.

Gut die haben 0.8 Millionen E-Mail, aber bei 1500 macht das ungefähr 550 E-Mails pro Maildir. Der rsync dauert dann beim Backup vielleicht etwas länger.

Unser alter Mailserver hat Mitte 2007 im Peak etwa 380.000 E-Mails (im Monat) geleistet, alle gingen durch zwei Qmails, Sophos lief zwischen den beiden. Etwa 50-100t Mails wurden durch Spamassassin geschickt. Das ganze lief aber auf einem 2x P3 1.2GHz mit Raid 1 und eine weitere Festplatte für die qmail Queue. Jedoch hatten wir kaum IMAP-Last, das ist bei tilliate wohl anders. Der Server war sehr stabil, lief aber unter sehr hoher Last.

tilllate hat jetzt einen Quad-Core 2.66GHz, 8GB, 4x 146 SAS 15k. Mit 50t. Mails am Tag würde auf der Maschine jede Mailserverkonfiguration sehr schnell laufen.

Ein paar Dinge, die mir direkt aufgefallen sind:

In the beginning of this year, we’ve decided to replace our old mail server

Wir haben jetzt August, das dauert doch nicht länger als ein paar Tage, maximal eine Woche.

Raid 5 for secure and reliable storage

Ein Raid 5 für einen Mailserver?? Postfix hat zwar weniger Ansprüche an die Festplatten als qmail, aber sowas macht man doch nicht. Dann lieber ein Raid 10 mit billigeren und größeren SATA-Platten.

Seit Mitte 2007 läuft unser neuer Server (2x Dual-Core Xeon 2GHz, 2GB Ram, 6x 160GB SATA). Auf dem MX-qmail (mit den MX-Records) gingen im Peak 9.4 Millionen E-Mails durch Spamassassin und Sophos. Dazu kommen noch 280.000 Mails, die von den eigenen Domains verschickt wurden. Die Last war mit den 2GB-Ram schon sehr hoch, nach einer Erweitung auf 4GB aber wieder sehr gering. Es gab einfach zu viele spamd-Prozesse und die Maschine hat angefangen zu swappen.

Die Aufteilung in zwei qmails habe ich übrigens gemacht, damit ich für das “Kunden-qmail” andere RBLs benutzen konnte. Später habe ich das “Kunden-qmail” noch so angepasst, dass im Envelope nur noch eine Absenderadresse einer lokalen Domain stehen darf.

Das kann ja jeder erzählen.

Ich will gar nicht wissen, wie es ohne RBL aussehen würde. Inzwischen blocken die RBLs (auch die von Manitu) fast alles:

Die Statistik basiert auf dlog, einen Artikel dazu habe ich schon einmal geschrieben.

Der Server hat zur Zeit 1.2Millionen E-Mails in 2500 Postfächern, wird viel über POP3 abgefragt. Ein tinydns und dnscache (mit 512MB) läuft auf der Maschine auch noch. Backup wird alle drei Stunden auf vier verschiedene Server gemacht.

Meine Tipps für einen flotten Mailserver, die mir spontan einfallen:

• Software:
• RBLs
• Spamassassin nicht über Maildrop aufrufen, Maildrop kann ausfiltern, aber nicht bewerten. Die Bewertung sollte ein richtige Daemon machen (Tipp No 1: simscan)
• MX und Kunden SMTP-Server aufteilen
• Ramdisk benutzen (natürlich nicht für die Mailserver Queue, für simscan/spamassassin…)

• Hardware:
• mehr Festplatten
• mehr Festplatten
• mehr Festplatten
• Raid 10
• genug RAM für den IO-Cache
• mehrere CPUs, müssen nicht so schnell sein

Meine Behauptung ohne die alte Hardware zu kennen: 100.000 E-Mails am Tage wären locker drin gewesen.

/dev/sdb:
Timing cached reads:     2 MB in  4.03 seconds = 508.50 kB/sec
Timing buffered disk reads:    2 MB in  3.42 seconds = 598.48 kB/sec

/dev/sdb:
HDIO_GET_32BIT failed: Invalid argument
HDIO_GET_UNMASKINTR failed: Invalid argument
HDIO_GET_DMA failed: Invalid argument
HDIO_GET_KEEPSETTINGS failed: Invalid argument
readonly      =  0 (off)
readahead     = 256 (on)
geometry      = 2432/255/63, sectors = 39070080, start = 0

Die Formatierung mit FAT32 funktionierte, testweise konnte ich auch einen Podcast auf die Festplatte kopieren. SMART zum Testen der Festplatte funktioniert allerdings nicht.

Ich bin mal gespannt, wie lange die Platte bei den Vibrationen und Temperaturen in dem Handschuhfach noch laufen wird.

Auf meinem neuen Laptop hatte ich ursprünglich Fedora 7 oder 8 installiert und habe direkt nach der Veröffentlichung von 9 ein Upgrade (yum) durchgeführt.

Zuerst sah es gar nicht schlecht aus, aber es gibt doch viele Probleme. In letzter Zeit überlege ich ernsthaft, ob ich wieder auf 8 bzw. direkt auf Ubuntu wechseln soll.

Hier mal eine Liste der Dinge, die mit Fedora 8 funktioniert haben:

• Suspend2Ram funktioniert manchmal, meistens aber nicht. Wenn er mal funktioniert hat, ist der Mauszeiger vom Touchpad derart langsam, dass man damit nicht arbeiten kann. Ich muss dann immer den X-Server neu starten.
• Ich habe ein Software-Raid 1 über zwei USB-Festplatten, mdadm schmiert sofort ab, sobald ich das Raid starten will. Unter systemrescue lässt sich das Raid ohne Probleme starten. Allerdings habe ich das mit den letzten Kernel-Updates noch nicht ausprobiert.
• Synchronisation mit meinem Nokia N73 über multisync. Anscheinend gibt es das Paket in Fedora 9 nicht mehr, jedoch habe ich auch das noch nicht weiter untersucht.

Seit einige Zeit geht jetzt mein WLAN nicht mehr, der NetworkManager hat nach einem Update den Dienst eingestellt. Auch bei einer LAN-Connection passiert es jetzt oft, dass keine Verbindung aufgebaut werden kann, killall dhclient && dhclient eth0 hilft sofort.

Es ist schon sehr enttäuschen, dass es im Gegensatz zu Fedora 8 mit dem neuen Release so schlecht läuft.

Meine nächsten Schritte werden sein, dass ich das automatische Update deaktiviere und in längeren Abständen ein Update über yum mache. So habe ich das mit den vorherigen Versionen auch gemacht. Danach werde ich Fedora 9 ganz frisch von der DVD installieren, obwohl ich mich nach dem Upgrade um die .rpmnew- Dateien gekümmert habe.

Dabei muss man aber auch sagen, dass die IO-Aktivität stetig steigt, dennoch ist eine Temperatur ~ > 60 Grad für die Festplatte alles andere als förderlich. Und der Peak ist mit 70 schon ziemlich heftig, aber bisher macht die Platte das ohne Probleme mit.

Ich werde mal bei Hetzner anfragen, ob man nicht ein oder zwei Gehäuselüfter einbauen kann, denn so kann das nicht weitergehen.

Auf der Firewall werde ich doch etwas schwermütig:

18:57:15 up 519 days, 22:36, 2 users, load average: 0.08, 0.11, 0.04

Aus Interesse habe ich mal ein hdparm ausgeführt:

/dev/hda:
Timing cached reads: 484 MB in 2.00 seconds = 241.55 MB/sec
Timing buffered disk reads: 120 MB in 3.06 seconds = 39.26 MB/sec

Die Festplatte geht ja noch, aber die cached reads…mein Notebook schafft locker 2-3GB/s. Bei der FW handelt es sich übrigens um einen P3 mit 1000Mhz auf einem Intel 815 Chipsatz.

Man könnte natürlich jetzt mit der CD/DVD das Fedora installieren, doch muss das System dann auch wieder konfiguriert werden. Eine Alternative wäre einfach ein Image von einem anderen Rechner einspielen, allerdings ist Fedora 9 noch sehr frisch und ich hatte noch kein Fedora 9 System.

Der Standard-Weg (fedora-release installieren und yum update) ist wegen den ganzen Abhänigkeiten wahrscheinlich umständlicher als eine Neuinstallation.

Ich habe mich für eine “brutale” Methode entschieden.

Als erstes benötigt man die Fedora Packages (~3.6GB), mit rsync und 16Mbit DSL liegt das Ganze recht schnell auf der Festplatte:

rsync --archive --verbose --progress rsync://ftp.crc.dk/Fedora/linux/releases/9/Fedora/x86_64/os/Packages/ .

Vielleicht hätte man sich ein rpm -qa von einem anderen Rechner holen sollen, aber wie gesagt, es war noch kein Fedora 9 System verfügbar.

rpm -Uvh * --nodeps --force

Vorher sollte rpm aber ohne –nodeps laufen, damit die Abhängigkeiten manuell geprüft werden können, bei mir kam es nur bei einigen unwichtigen Paketen zu Fehlermeldungen.

Während RPM die Pakete installiert treten viele Fehler auf, die Pakete werden nicht in der richtigen Reihenfolge installiert. Ich hab rpm einfach zweimal ausgeführt.

Wenn alles funktioniert hat, kann man noch die $config.rpmnew nach $config verschieben, sollte man bei /etc/passwd aber besser nicht machen

Man sollte beachten, dass nach dem Upgrade auch PATA-Festplatten sd*-Devices werden. Wenn es in Centos 5 eine Festplatte (/dev/hda3) gibt, wird diese in Fedora zu /dev/sda.

diss: Mach *das* mal mit Windows