Im aktuellen ADMIN Magazin 03/2010 (www.admin-magazin.de) gibt es einen Artikel zu OpenSolaris COMSTAR von mir. Viel Spaß beim lesen. 
Archive for the 'Storage' Category
Mal wieder was zum Nachschlagen. 
[root@ius022 install]# /opt/VRTS/bin/vxdisksetup -i sdb
[root@ius022 install]# vxdg init datadg disk01=sdb
[root@ius022 install]# vxassist -g datadg maxsize
Maximum volume size: 83695616 (40867Mb)
[root@ius022 install]# vxassist -g datadg make datavol 40000m layout=nostripe
[root@ius022 install]# mkfs -t vxfs /dev/vx/rdsk/datadg/datavol
version 7 layout
81920000 sectors, 40960000 blocks of size 1024, log size 65536 blocks
largefiles supported
[root@ius022 install]# mkdir /data
[root@ius022 install]# mount -t vxfs /dev/vx/dsk/datadg/datavol /data
[root@ius022 install]#
[root@ius022 install]# /opt/VRTS/bin/vxdisksetup -i sdb [root@ius022 install]# vxdg init datadg disk01=sdb [root@ius022 install]# vxassist -g datadg maxsize Maximum volume size: 83695616 (40867Mb) [root@ius022 install]# vxassist -g datadg make datavol 40000m layout=nostripe [root@ius022 install]# mkfs -t vxfs /dev/vx/rdsk/datadg/datavol version 7 layout 81920000 sectors, 40960000 blocks of size 1024, log size 65536 blocks largefiles supported [root@ius022 install]# mkdir /data [root@ius022 install]# mount -t vxfs /dev/vx/dsk/datadg/datavol /data [root@ius022 install]#
Was tun wenn man 3 Stück Sun StorEdge 6020 Arrays (eigentlich 6 Stück. 
) mit je 14 Stück 146 GB Fibre Channel Festplatten hat? Eigentlich klar, die Arrays konfigurieren und an das SAN klemmen. Tja, was ist aber wenn die installierten RAID Controller einfach nur grausam in der Bedienung sind, man maximal 2 Volumes pro Disk Array erstellen kann und die Geschwindigkeit mit ZFS einfach nur lausig ist?
Dumm in die Wäsche schauen?
Ich habe versucht 4 Volumes (entspricht 2 Disk Arrays und 28 Platten) in diversen Konfigurationen (verschiedene Kombinationen aus Block Size, RAID-Level, etc.) passend für ZFS zu konfigurieren. Alle Ergebnisse waren ziemlich ernüchternd und der Weg dahin langwierig und schwierig.
Keine Lust mehr….
Die neue Idee war fix geboren. Ein StorEdge 6020/6120 kann auch zum Expansion Disk Array umgebaut werden, d.h. Controller ausbauen. Das riecht doch offensichtlich nach FC-AL. Für viel Geld hab ich mir also spezielle Kabel für die HSSDC2 Anschlüsse besorgt. Doch alle Versuche das 6020 als JBOD zu nutzen sind kläglich gescheitert.
Frust macht sich breit. :-/
Lange Zeit passierte nichts mehr und es schwirrte lediglich die Idee in meinem Kopf, die 42 Platten irgendwie in ein EMC CLARiiON CXx00 zu stecken. Nur ohne aktuelle Flares schwierige Sache. Hinzu kommt die Unsicherheit ob eine EMC CLARiiON die Platten überhaupt erkennt. Meine HP EVA tut es jedenfalls nicht so recht. Sie erkennte zwar die Platten, aber verweigert dessen Nutzung! Wieder einmal keimte der Gedanke JBOD auf. Aber woher ein JBOD nehmen? Fibre Channel JBODs sind halt alles andere als gängig. Was tun?
Ins kalte Wasser springen?
Nach einigen Überlegungen und Recherchen sagte mir mein Bauch, NetApp macht doch eigentlich auch nichts anderes, als das was ich im Sinn habe? Die haben schlaue Software in ihren Filer Köpfen und brauchen doch eigentlich nur dumme JBODs mit vielen schnellen Platten, oder? Nachdem ich auch noch Verkabelungspläne für einen NetApp FAS3050 entdeckte, war ich mir immer sicherer, dass das NetApp DS14 mk2 Disk Enclosure ein dummes FC-AL JBOD sein muss. Lediglich die IO Module auf der Rückseite bereiteten mir kurzfristig Bauchschmerzen. Nach einigem hin und her entschloß ich mich für das sog. ESH2 Modul. Wie ich finde, eine gute Entscheidung.
Aus UK habe ich mir dann für einen fairen Preis ein NetApp DS14 mk2 Disk Enclosure mit 2 Stück ESH2 Modulen besorgt. Frisch angekommen, habe ich das Enclosure mit 14 Platten aus einer meiner 6020 Arrays bestückt. In die Sun Fire X4100 hab ich einen Emulex FC HBA installiert und diesen direkt mit dem IO Modul verbunden. Das Ergebnis sieht so aus:
locadm@ius002:~$ pfexec luxadm probe
Found Fibre Channel device(s): Node WWN:500000e010731c30 Device Type:Disk device Logical Path:/dev/rdsk/c0t500000E010731C30d0s2 Node WWN:2000000087014896 Device Type:Disk device Logical Path:/dev/rdsk/c0t2000000087014896d0s2 Node WWN:500000e010730550 Device Type:Disk device Logical Path:/dev/rdsk/c0t500000E010730550d0s2 Node WWN:2000000c509a551e Device Type:Disk device Logical Path:/dev/rdsk/c0t2000000C509A551Ed0s2 Node WWN:2000000c509a5621 Device Type:Disk device Logical Path:/dev/rdsk/c0t2000000C509A5621d0s2 Node WWN:500000e0107325c0 Device Type:Disk device Logical Path:/dev/rdsk/c0t500000E0107325C0d0s2 Node WWN:20000000871a4524 Device Type:Disk device Logical Path:/dev/rdsk/c0t20000000871A4524d0s2 Node WWN:2000000c509a553f Device Type:Disk device Logical Path:/dev/rdsk/c0t2000000C509A553Fd0s2 Node WWN:500000e0107323e0 Device Type:Disk device Logical Path:/dev/rdsk/c0t500000E0107323E0d0s2 Node WWN:2000000c509a4f64 Device Type:Disk device Logical Path:/dev/rdsk/c0t2000000C509A4F64d0s2 Node WWN:500000e010730b90 Device Type:Disk device Logical Path:/dev/rdsk/c0t500000E010730B90d0s2 Node WWN:20000000871ae23b Device Type:Disk device Logical Path:/dev/rdsk/c0t20000000871AE23Bd0s2 Node WWN:2000000c50860c5d Device Type:Disk device Logical Path:/dev/rdsk/c0t2000000C50860C5Dd0s2 Node WWN:500000e0107311b0 Device Type:Disk device Logical Path:/dev/rdsk/c0t500000E0107311B0d0s2
Ein paar Tests belegen mir eine Schreibgeschwindigkeit von durchschnittlich 140 MByte/Sek. und eine Lesegeschwindigkeit von 210 MByte/Sek. Cool ! Es wird Zeit für 3 weitere NetApp DS14 mk2 Disk Enclosures. Die neue Idee ist geboren und schimpft sich:
“NoNapp Data ONZFS”
Alles weitere demnächst hier in diesem Kino.
So, geschafft ! Die Preise für Platten sind endlich mal in Keller gepurzelt – außer bei den ganzen Traumtänzern *räusper* Resellern in eBay.de – und ich hab meine zwei M5214 Diskshelves endlich voll gemacht. Nun dürfen 28 Stück 73 GB 15k Fibre Channel Platten in einer Diskgroup rackern und mir jedesmal ein Lächeln ins Gesicht zaubern.
HP EVA 5000 28 Stück 72 GB 15k
Ich hab ein paar Benchmarks durchgeführt und kriege durchweg konstant unter allen Umständen mind. 120 MByte/Sek. schreibend und 180 MByte/Sek. lesend hin. Unter sehr idealen Bedingungen sind auch über 300 MByte/Sek. schreibend bei einem Vraid-0 möglich. Das ist natürlich schon ziemlich extrem bei maximal 2 GBit/s Fibre Channel. Wie auch immer, jede LUN die ich angelegt und getestet habe, fühlte sich wirklich verdammt schnell an. Echt cooooooooool.
Für unsere neue ESX Server Landschaft (siehe HP BladeSystem Install Party) habe ich ein Sun StorageTek 2540 Array geholt. Das Array ist mit 12 Stück 300 GB 15k SAS Platten ausgestattet. Pro Controller stehen 512 MB Cache Memory bereit. Angebunden ist alles konsequent über 4 GBit/s Fibre Channel.
Mein erster Versuch ein ordentliches Volume zu bauen ist natürlich kläglich gescheitert, d.h. die Performance war unter aller Kanone. Nach Klick-Admin Manier hab ich einfach mal 11 von 12 Festplatten zu einem großen Raid-5 Pool zusammengefasst. Die verbleibende Festplatte hab ich als Hot-Spare deklariert. Diese unprofessionelle Aktion wurde dann mit Transferraten von 40 bis 70 MByte/s. quittiert.
Daraufhin habe ich meinen Arsch hingehockt und mich dem Thema etwas genauer gewidmet. An dieser Stelle herzlichen Dank an das Stiefkind – alias Wolfgang, siehe www.synapseninferno.org – der mich professionell zum Thema Stripe Unit Size, Stripe Size, Block Size, etc. beraten hat.
Ich beschloss also im zweiten Anlauf auf dem Storage System zwei Virtual Disks im Format 4+1 RAID-5 mit 512 KB Segment Size anzulegen. Damit erreiche ich die optimale Ausnutzung des Storage Systems, 10 Datenplatten und 2 Hot-Spares. Und 4 x 512 KB Segment Size ergibt dann per Virtual Disk eine Stripe Size von 2 MB, aber auch nur unter der Annahme das die von Sun benannte Segment Size der Stripe Unit Size entspricht, wovon ich jetzt einfach mal ausgehe. 
Im vSphere Client hab ich die exportierte 500 GB LUN mit VMFS und einer Block Size von 2 MB formatiert. Wenn man direkt über den vSphere Client ein Datastore erstellt wird die Partitionstabelle mit richtigem Alignment erstellt, andernfalls sollte man bei Anlage der Partition darauf achten. Ein
fdisk -lu
sollte in etwa folgende Ausgabe haben:
Disk /dev/disks/naa.600a0b80005bbc16000002954a8ea048: 536.8 GB, 536870912000 bytes
255 heads, 63 sectors/track, 65270 cylinders, total 1048576000 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/disks/naa.600a0b80005bbc16000002954a8ea048p1 128 1048562549 524281211 fb VMFS
Die Angabe Start muss bei 128 stehen, andernfalls ist die Partition nicht optimal ausgerichtet.
Im nächsten Schritt habe ich einer vorhanden virtuellen Maschine mit Windows Server 2008 eine neue 10 GB große virtuelle Festplatte hinzugefügt. Diesmal habe ich die Partition manuell angelegt, hierfür startet man die Eingabeauforderung und geht wie folgt vor:
C:\> diskpart ... DISKPART> select disk 1 ... DISKPART> create partition primary aligned=64 ... DISKPART> exit
Danach formatiert man im Disk Management die erstellte Partition mit NTFS und einer Allocation Unit Size von 32 KB.
All die Mühen werden dann mit einer recht konstante Transferrate von 150 MB/s. belohnt. So gefällt mir das natürlich umso besser.
Und was lernen wir nun daraus? Mit ein bisschen Nachdenken und ein paar Mühen kann man die Storage Geschwindigkeit gut und gerne verdoppeln und verdreifachen. Ein genauer Blick auf die Themen Stripe Unit Size, Stripe Size, Block Size, etc. pp schadet ebenso nicht. Hier ist wohl leider oft die Ursache mangelnder Performance von eigentlich schnellen Arrays begraben.
Nach langem Warten endlich wieder ein neuer Blog Eintrag. Heute war mir danach meine Sun Fire 3800 mal anzuwerfen um die kürzlich erworbenen Speicherriegel zu testen. In diesem Zug hab ich gleich ein Sun StorEdge 6120 dazu geklemmt. Von dem hübschen Ding soll unter anderem die Maschine booten. Ärgerlich ist lediglich das ich nur 1GBit/s FC HBAs in der Fire stecken habe, und das Array eigentlich 2GBit/s unterstützt. Na ja, irgendwann schnapp ich mir schon den 2GBit/s Compact PCI Emulex FC HBA.
Beim Starten der Domain A ist beim Testen der Systemboards prompt ein defekter DIMM entdeckt worden (/N0/SB0/P3/B0/D1). Den habe ich natürlich gewechselt und die Tests sind erfolgreich durchgelaufen. Blöd ist nur das trotzdem die Reparatur LEDs leuchten. Hmmm…
In wenigen Minuten sollte meine OpenSolaris 2009.06 Repository DVD geladen sein, danach werde ich einen Local Repository Server einrichten und meine Sun Fire 3800 mit OpenSolaris betanken. Mal schauen ob ich das heute noch schaffe.
Der Banner darf natürlich nicht fehlen:
Sun Fire 3800 OpenFirmware version 5.20.12 (01/16/09 07:08) Copyright 2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. SmartFirmware, Copyright (C) 1996-2001. All rights reserved. 9216 MB memory installed, Serial #15284988. Ethernet address 8:0:20:e9:3a:fc, Host ID: 80e93afc.
In der Rubrik Keller präsentiere ich euch meine kleine IT Sammlung die ich in meinem Keller so betreibe. Einfach oben auf “Keller” klicken und schon kann es los gehen.
Neuigkeiten und Veränderungen kündige ich selbstverständlich an.
Vor einiger Zeit hab ich schon im Twitter von meiner Storage Zicke berichtet. Heute nun die ersten Informationen dazu in meinem Blog.
Bei der Storage Zicke handelt es sich um eine Sun StorEgde 6120 Array, auch bekannt unter dem Synonym T4 und damit dem Nachfolger der Sun StorEgde T3/T3+ Systeme. Seit einiger Zeit tummeln sich 3 von 6 Arrays, ausgestattet mit je 14 Stücke 146 GB 10k FC Festplatten, in meinem Keller. Verglichen zu meiner HP EVA 5000 sind die Geräte alles andere als intuitiv und flexibel, aber die riesige Menge an Platten macht den Einsatz in meinem Keller dennoch attraktiv.
Aktuell habe ich zwei Arrays zu einer Partner Group zusammengefasst, d.h. Master und Alternate Master Controller. Die Firmware ist auf den letzten Stand 3.2.7 geflashed und die zwei LWL Kabel klemmen direkt an einem Dual Port Fibre Channel HBA in einem HP ProLiant DL380 G4. Auf dem 6120 System hab ich ingesamt 4 LUNs gebildet. Jede LUN entspricht einem RAID-5 Volume bestehend aus 6 Platten + Hotspare. Alle 4 LUNs sind auf dem HP Server unter OpenSolaris 2009.06 zu einem ZFS RAID-Z zusammengefasst. Ergibt recht ausfallsichere 2,64 TB Kapazität. Mit aktiviertierter Komprimierung erreiche ich z.B. mit Bonnie++ recht imposante Ergebnisse.
locadm@ius0009:~# zpool status -v
pool: pool0
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
pool0 ONLINE 0 0 0
raidz1 ONLINE 0 0 0
c0t60003BA4E89880004A6C598500010163d0 ONLINE 0 0 0
c0t60003BA4E89880004A68C2B70007FB7Bd0 ONLINE 0 0 0
c0t60003BA4E89880004A67867D000100CDd0 ONLINE 0 0 0
c0t60003BA4E89880004A678660000F380Fd0 ONLINE 0 0 0
locadm@ius0009:~# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
pool0 2.64T 554K 2.64T 0% ONLINE -
rpool 33.8G 5.47G 28.3G 16% ONLINE -
locadm@ius0009:~/src/bonnie++-1.03d# ./bonnie++ -d /scratch/ -s 8192m -u root
Using uid:0, gid:0.
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.03d ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ius0009 8G 123144 75 218942 61 134630 54 99725 84 299677 46 8059 44
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 13398 99 +++++ +++ 22955 99 14016 99 +++++ +++ 23678 99
Als nächstes Schritt werde ich mittels OpenSolaris COMSTAR über einen zweiten FC HBA bedarfsgerecht LUNs in meiner Fabric präsentieren. Daneben hole ich rasch die drei verbleibenden Arrays und vor allem ausreichend HSSDC2 Kabel ab, damit ich die Partner Group um zwei sog. Expansion Arrays erweitern kann. Danach sollte ich doch hier und da über 500 MB/s. sehen.
Zum Abschluß noch ein kleines Bildchen:
