Nachdem inzwischen Festplatten mit einer Größe von 1 TB (1024 GB sind 1 TB) keine Seltenheit mehr sind, kam kürzlich ein RAID-Verbund mit solch großen Festplatten bei einem Kunden zum Einsatz. Doch wie bei vielen Stellen in der IT-Welt gibt es auch hier eine Grenze, die vor einigen Jahrzehnten bestimmt worden ist. Damals, als Festplatten nur wenige Megabyte groß waren, hat man festgelegt, dass eine normale Partitionstabelle maximal eine Festplatte mit 2 TB adressieren kann – technisch natürlich begrenzt durch die allseits bekannten 32 Bit.
Selbstverständlich gibt es eine Alternative zum derzeit fast überall eingesetzten Master Boot Record (MBR), diese Alternative heißt GUID Partition Table (GPT). Nun ist das Problem, dass die Unterstützung für GPT sowohl im BIOS als auch beim Bootmanager (z.B. Grub) vorhanden sein muss. Auf x86-basierenden Systemen (üblicherweise als x86, IA32, x86_64, AMD64, EM64T bekannt) ist eine Unterstützung von GPT bislang allgemein recht selten und aktuell unterstützt keine für den Unternehmenseinsatz optimierte Linux-Distribution die GPT von Haus aus.
Natürlich könnte man einen Grub 2 (der sowieso noch Zukunftsmusik ist) selbst compilieren oder den bestehenden Grub 0.x mit einem Patch aufbohren, aber das muss hinterher selbst gepflegt sowie gewartet werden und bei Problemen ist man auf sich selbst gestellt.
Die Lösung ist nun bei einem RAID-Controller den RAID-Verbund anderst aufzubauen: Hat man z.B. nur Festplatten mit jeweils 1 TB, so plant man üblicherweise ein RAID 5 mit 5 Festplatten und einer Hotspare-Platte. Eine mögliche, funktionierende Lösung wäre ein RAID 1 aus 2 Festplatten, sowie ein RAID 5 aus 5 Festplatten und eine globale Hotspare-Festplatte. In diesem Fall müsste man einfach noch zwei weitere Festplatten dazukaufen, um die gleiche Nutzkapazität zu erreichen. Auf das RAID 1 wird das Betriebssystem mit einem MBR installiert, auf das RAID 5 wird eine GPT eingerichtet und anschließend hat man 4 TB für Nutzdaten. Und die globale Hotspare springt entweder für das RAID 1 oder das RAID 5 ein – je nach dem, wo sie bei Bedarf benötigt wird.
Bei Verwendung eines Red Hat Enterprise Linux 5 (RHEL) bzw. CentOS 5 kann eine ganz normale Installation auf dem RAID 1 durchgeführt werden. Anschließend wird das RAID 5 mit GPT eingerichtet wie folgt:
[root@tux ~]# parted /dev/sdb
GNU Parted 1.8.1
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
(parted)
(parted) p
Model: DELL PERC 6/i (scsi)
Disk /dev/sdb: 3999GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
(parted)
(parted) mkpart
Partition name? []? BACKUP
File system type? [ext2]? ext3
Start? 0
End? -1
(parted)
(parted) p
Model: DELL PERC 6/i (scsi)
Disk /dev/sdb: 3999GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17.4kB 3999GB 3999GB BACKUP
(parted)
(parted) quit
Information: Don't forget to update /etc/fstab, if necessary.
[root@tux ~]#
Anschließend kann mit mkfs.ext3 ein Dateisystem angelegt werden. Wichtig ist noch, dass fdisk aktuell nur mit MBR-Partitionstabellen und nicht mit GPT umgehen kann. Somit muss in jedem Fall zu parted (GNU Parted) gegriffen werden. Übrigens, MBR-Partitionstabellen und Partitionen größer als 2 TB lassen sich problemlos anlegen, konfigurieren und selbst ein Dateisystem lässt sich darauf anlegen. Aber sobald Daten ins Spiel kommen, geht das ganze schief. Einige Leute beschreiben zudem, dass die Beschränkung sich lediglich auf Partitionen größer als 2 TB beziehen würde und Partitionstabellen größer als 2 TB möglich wären – dies habe ich so nicht nachvollziehen können: Egal ob Partition oder Partitionstabelle, sobald die 2 TB-Grenze erreicht war, gab es bei mir Probleme.
Bei RAID beziehe ich mich überall auf ein Hardware-RAID, da ein Software-RAID zum einen immer eine schlechtere Performance als ein Hardware-RAID liefert und zum anderen, da sich dieses Problem auch nicht mit einem Software-RAID lösen lässt.
Die Verwendung eines Logical Volume Managers (LVM) wäre sicherlich auch noch eine Möglichkeit, hätte es nicht im Linux-Kernel unter Verwendung von LVM2, wie er mit allen gängigen Enterprise-Distributionen mitgeliefert wird, bis vor kurze Zeit einen schwerwiegenden Fehler gegeben, der im Extremfall bei 100% Schreibgeschwindigkeit für lediglich 50% Lesegeschwindigkeit gesorgt hat. Das Problem wurde erst mit einer Testversion des Linux-Kernels in Version 2.6.27 behoben und wird aufgrund von Inkompatibilitäten vermutlich auch in keine bestehende Version einer Enterprise-Distribution zurückportiert werden. Red Hat behandelt dieses Problem aktuell im von mir geöffneten Bugreport 147679 und geht davon aus, es mit Red Hat Enterprise Linux 6 (und damit auch CentOS 6) zu beseitigen…
