Monthly Archive for August, 2009

Blade Server Upgrade

Wird mal wieder Zeit für einen Artikel aus meinem Heim-RZ. ;)

Habe am Freitag vier HP BL20p G3 Server bekommen und natürlich sofort ausprobiert. :) Bilder sprechen mehr als Worte:

dsc02784h

Details zur Ausstattung der Geräte demnächst in meiner Keller Rubrik. Ansonsten hab ich das Wochenende mit VMware ESX 4i und Windows Server 2008 gespielt. Läuft hervorragend auf den Dinger, lediglich Arbeitsspeicher muss ich deutlich nachrüsten.

Sun StorageTek 2540 + VMware ESX + Windows Server 2008

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. 8)

Sun Common Array Manager

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.

Windows Server 2008

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.

HP BladeSystem Install Party ;)

Gestern trudelte ein sehr großes Paket bei mir auf Arbeit ein, das lang ersehnte HP c-Class BladeSystem. Vor etwas über einem Jahr empfahl ich schon für unsere neue IT an unserem neuen Standort in Ingolstadt ein HP BladeSystem und nach sehr langem Warten durfte ich nun ein ordentlich ausgestattetes System entgegennehmen. Geduld ist schon eine Tugend. :)

DSC02768
Heute hat der Tag mit dem Besuch unseres Elektriker begonnen. ;) 2x 32A Stromanschluß war angesagt… der Querschnitt ist schon sexy. He he he. ;)

DSC02770
In der Mittagspause trudelte dann das neue Rack mit reichlich Zubehör ein. Natürlich konnte ich mich nicht zurück halten und musste das gute Stück gleich an seinem neuen Bestimmungsort verfrachten.

DSC02771
Danach ging die mühselige Verkabelung an. Ich hab für das neue BladeSystem passende 32A PDUs von HP mit je 4 Ausgängen bestellt. Eine PDU haben wir direkt an das Stromnetz gehängt. Die zweite PDU wird hoffentlich bald von einer schöne dicken USV gespeist. ;)

DSC02772
Mein Kollege – liebevoll “Meister Egen” von mir genannt – musste natürlich die hübschen Turbinenlüfter bewundern. Aber er war mir daneben auch eine prima gute Hilfe. Wie man sieht die dicke Kuh hängt schon im Rack. ;) Ach ja, wenn ich schon von Helfern rede, dann darf ich unseren Denis nicht vergessen. Hab leider kein Bild von ihm, aber ich wollt ihn zumindestens namentlich genannt haben!

DSC02774
Und hier das feine Stück von vorne. Die Ausstattung kann sich sehen lassen: Vier Stück BL685c werden eine schicke VMware ESX Umgebung abbilden und zwei Stück BL465c die Torwächer, sprich jeweils ein Microsoft ISA Server. Ein Glück das ich nur die Infrastruktur mache und das Windows Gedönse anderen Leute überlasse. ;)

DSC02776
Die Verkabelung des HP BladeSystems ist abgeschlossen. Die Ausstattung der Interconnects ist auch üppiger als gedacht ausgefallen. ;) Vier mal 1/10Gb Virtual Connect Ethernet Module und zwei 4Gb Virtual Connect Fibre Channel Module sorgen für die Verbindung an die Aussenwelt. Leider fehlt noch der redunte Edge Swicth, wie auch die 10GbE Ethernet Module für die HP ProCurve Switche, damit das Ganze ein stimmiges Bild abgibt. Aber die Geduld wird es schon richten. ;)

DSC02775
Ein paar Storage Systeme dürfen nicht fehlen, diesmal von Sun. Hab da nen super netten Vertriebler den ich einfach auch etwas glücklich machen wollte, andernfalls hätte ich ja alles von HP nehmen können. Aber ich finde die silbernen Büchsen ebenfalls cool. Ach ja, kurze Erklärung, unten ein Sun StorageTek 2540 mit 12x 300 15k SAS und ob darüber ein brand aktueller Sun Fire X4275 Server mit “noch” 4x 1TB Platten. Das Gerät darf als D2D Backup System herhalten um im Laufe des Tages gemütlich die Daten an einen LTO4 Auto Loader zu schicken.

DSC02778
Nach rund 4 Stunden Arbeit konnte ich diesen Anblick geniesen. ;) Wie man links hinten deutlich erkennen kann, hab ich mir nach getaner Arbeit ein gutes Hofmühl Helles gegönnt. Ich finde das sieht soweit nicht schlecht aus, es fehlt noch die dicke USV und ein paar ordentliche Blenden. ;)

Rubrik Keller aktualisiert!

Habe nun mit der Beschreibung meiner Sun Systeme begonnen. Den Anfang macht die Sun Fire 3800. Hier geht’s zu den Sun Systemen.

BTW. Wer ein Sun Fire 3800 Rack übrig hat oder weiß wo ich eines bekommen kann, bitte Mail oder Kommentar !!! Danke… Ebenso nehme ich gerne ein altes graues StorEdge Rack für meine 6120 Arrays für einen fairen Preis entgegen. Nicht zu vergessen wenn möglich Abholung im Raum Bayern.

Solaris Jumpstart Server auf OpenSolaris 2009.06

Da im Moment OpenSolaris 2009 auf meiner Sun Fire 3800 nicht booten will, hab ich mich dazu entschlossen fix Solaris 10 U7 aufzuspielen. Logischerweise macht man das über einen Jumpstart Server, sofern kein DVD-ROM vorhanden ist. Leider ist der Jumpstart Server nicht so ohne weiteres auf einer OpenSolaris 2009.06 Maschine eingerichtet. Also musste wie so oft Freund Google herhalten und die zwei wesentlichen Probleme möchte ich hier natürlich verewiegen.

Problem 1: Kein Bootparams Daemon (RARP)

Entgegen der Empfehlung die Pakete SUNWbsu und SUNWbsr zu installieren, genügt ein:

# pkg install SUNWbs

Problem 2: Timed out waiting for TFTP reply

Der TFTP Daemon unter OpenSolaris 2009.06 muss wie folgt angepasst werden:

# echo tftp dgram udp6 wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot >> /etc/inetd.conf
# inetconv

ggf. noch ein:

# svcadm restart svc:/network/tftp/udp6:default

Joa und das wars eigentlich schon. Der Rest ist wie gehabt. ;) Im Schnelldurchlauf heißt das:

./setup_install_server /export/installserver/sol-10-xx
echo 08:00:20:e9:3a:fc ius0013 >> /etc/ethers
echo 192.168.209.13 ius0013 >> /etc/hosts
./add_install_client ius0013 sun4u

OpenSolaris Local Repository Mirror

Quelle: http://blogs.sun.com/observatory/entry/local_repository_mirror

In my previous entry I wrote about creating a portable version of the repository using a USB stick. That option is great for taking the repository on the road and even sharing it with folks at conferences where the Internet connection usually sucks.

However, a more practical use of this repository image to many of you may be setting up a local mirror. In this situation, you get the best of both words – fast access to the repository with continued access to updates as they become available.

Setting Up the Local Repository

If you haven’t already, download the ISO image of the repository (about 7 GB). After the download completes, mount the ISO:

pfexec mount -F hsfs `pfexec lofiadm -a ~/Download/osol-repo-0906-full.iso` /mnt

In order for the mount to persist across reboots, we’ll move it to a new file system, which we first need to create:

pfexec zfs create -o compression=on rpool/repo

Then copy the repository to the file system (this will take a little over an hour to complete):

bleonard@opensolaris:~$ pfexec rsync -aP /mnt/repo /rpool/repo
...
repo/updatelog/2009071315
       67506 100%  150.17kB/s    0:00:00 (xfer#304859, to-check=1/609926)
repo/updatelog/2009071316
       24956 100%   55.26kB/s    0:00:00 (xfer#304860, to-check=0/609926)

sent 6669164656 bytes  received 8537336 bytes  1368521.77 bytes/sec
total size is 6630966532  speedup is 0.99

Configure the package server to use the local repository:

svccfg -s application/pkg/server pkg/inst_rool=/rpool/repo/repo
(Korrektur: svccfg -s application/pkg/server setprop pkg/inst_root=/rpool/repo/repo )
svccfg -s application/pkg/server setprop pkg/readonly=true

Edit the repo/cfg_cache file, changing the origins property from http://pkg.opensolaris.org/release to http://<domainname>, where <domainname> is network accessible. For example:

origins = http://opensolaris

You can also choose a port number different from the default of 80, which I did because I’m running apache on port 80:

svccfg -s application/pkg/server setprop pkg/port=81

Then refresh the package server service to pick up the configuration changes and start it:

svcadm refresh application/pkg/server
svcadm enable application/pkg/server

Accessing the Local Repository

Now all those wishing to use the local package server simply need to make the following change:

pfexec pkg set-publisher -m http://opensolaris:81 opensolaris.org

Which will result in the following:

bleonard@opensolaris:~$ pkg publisher
PUBLISHER                             TYPE     STATUS   URI
opensolaris.org          (preferred)  origin   online   http://pkg.opensolaris.org/release/
opensolaris.org          (preferred)  mirror   online   http://opensolaris:81/

If you only want to use the local repository, first remove the mirror:

pfexec pkg set-publisher -M opensolaris.org http://opensolaris:81

Then:

pfexec pkg set-publisher -O http://opensolaris:81 opensolaris.org

For more information see the README.

Sun Fire 3800 und StorEdge 6120

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.

Sun Fire 3800 und StorEdge 6210 Array