Thoughts. Ideas. Photography.

Posts tagged “IBM

Perfect? Not really….

In summer, I had an interesting conversation with a colleague of mine, Jörg Möllenkamp. We analyzed performance numbers of IBMs 795 systems IBM published and were sure the numbers were a bit too perfect. Jörg mentioned this in his blog.

So it is time for a quick review of IBMs scaling. They have published their „really-big-iron“ benchmark results in the last weeks.

Let’s have a look:

  • IBM 795, 32 CPU, 4 TB RAM: 688630 SAPS (Certificate 2010046)
  • IBM 795, 16 CPU, 2 TB RAM: 384330 SAPS (Certificate 2010042)
  • for more benchmark results, please click on the certificate links. I will focus on SAPS in this article, if you prefer SD Users please check the certificates

Well, on the first view, both results are very impressive.  I have never ever seen a customer who needs such a power „in one piece“. But maybe IBM can find one. Good luck!

But I’m also interested in scaling factors: How much performance can I get if I double the CPUs of the overall system? And this factor includes more than only some CPU power, it also includes overhead for interconnecting, for memory access etc.

Okay… IBM doubled the number of CPUs/cores and… the SAPS went up by 1,79. Is this a good scaling factor?

Well, let’s compare this to other scaling factors. SPARC64 on M9000 with Oracle Database and Intels Nehalem-EX architecture and Oracle RAC. Oracle RAC realizes so called scale out, while large SMP systems like IBMs 795 or the M9000 scale up in the same box. In most cases, scaling out depends on a fast interconnect between the systems, while scaling up depends on a well scalling OS and a fast interconnect between all CPUs of the system. I also included a scale up comparison with Nehalem EX.

So, what are realistic scaling factors

Nehalem EX / Oracle RAC (scale out):

Nehalem EX / MS SQL (scale up)

SPARC64VII / Oracle 10g (scale up)

Power7 / DB2

In my opinion, this shows two important facts:

  1. Scale out and scale up are never perfect. You will always get some „penalty“ for having more than one simultaneous thread running.
  2. The mean value in my little, no representative calculation is around 1.82 – 1.83. So being above this value suggests a good scaling factor.

There also a little indication that scaling out performed better on x86 than scaling up. I don’t want to say it is better on RISC, because I did not found benchmark results using RISC and RAC at once.

At least, this figures show one thing we have expected:  IBM, the perfect linear scaling you claimed in summer is … not reached yet. Maybe you should start to build a better system for your world class CPU.


Just another funny benchmark…

Benchmarks sind was feines, insbesondere wenn man damit angeben kann. Ein richtig cooler Benchmark ist der TPC-C, mit dem man OLTP-Lasten simuliert und benchmarken kann. Der Benchmark ist so cool, dass IBM ihn selbst nicht mag und ihn gerne duch dessen Nachfolger ersetzen möchte: ftp://ftp.software.ibm.com/eserver/benchmarks/wp_TPC-E_Benchmark_022307.pdf . Dennoch nutzt IBM diesen Benchmark gerne, um die Leistungsfähigkeit ihrer Maschinen zu unterstreichen.

Gut, der Benchmark hat seine Schwächen. Er erlaubt Modifikationen an den verwendeten Datenbanken, die sich niemand für ein reales System erlauben würde. Er erlaubt auch Hardwarekombinationen, die sich kein Mensch leisten würde. Ein richtig krasses Beispiel hat IBM sich jetzt erlaubt – eine Konfiguration jenseits jedlicher Realität:

Der in 6 Monaten sogar erhältliche IBM Power 595 Server Model 9119-FHA hat das beeindruckende Resultat von 6.085.166 Transaktionen erreicht (Power 6 Prozessor mit 5 GHz. Liegt da ein Abo für Klimaanlagen-Upgrades bei?) .

Was aber klar sein sollte: TPC-C korreliert extrem mit der Anzahl der angeschlossenen Festlatten. Und davon hat IBM immerhin „nur“ 10.192 angeschlossen. Man stelle sich das mal bildlich vor: Angenommen IBM bekommt 48 Platten auf 4 Höheneinheiten unter, so braucht man 852 Rackunits, um die Platten unterzubringen. Das entspricht etwa 22 Racks mit 42 RU.

IBM bekommt aber 48 Platten nicht auf 4 Rackunits unter. IBM benötigt dafür 68 DS4800 (4RU) und 784 DS4000 EXP810 (3RU) . Das sind in Summe 2624 RU oder 63(!) Racks. Die Stellfläche hat nicht jedes Rechenzentrum zu Verfügung.

Alles vollgepackt mit surrenden Festplatten und in der Mitte ein großer Kubus mir Power-Prozessoren – bei einem gebündelten Abluftstrom würde ein durchnässter Admin (3 Liter Wasser in der Kleidung bei einer Körperoberfläche von 2m²) binnen 6 Sekunden getrocknet werden – allerdings müsste man ihn mit Seilen gegen Wegfliegen sichern. Klingt sehr nach einer Konfiguration aus dem wirklichen Leben.

IBM hat ja schon Erfahrung in der Kraft-Wärme-Kopplung. Vielleicht sollten sie mit ihrem Benchmarkcenter eine Großstadt mit Fernwärme versorgen.


TSM und ZFS

ZFS ist cool, das Backup eines ZFS mit TSM erinnert an die Steinzeit. Warum kann IBM seinen Backup-Client nicht erweitern, sodass dieser auch in der Lage ist, ZFS zu backupen?

Der Fehler oder das Fehlen scheint länger bekannt zu sein, und seit zwei Versionen des Clients passiert nichts. Irgendwie ist es extrem merkwürdig, dass IBM zuerst ewig braucht, um den Backup-Client für Solaris 10 x64 zu portieren, und dann brauchen sie vergleichbar lange, um ein richtig nettes Dateisystem zu unterstützen.
Wirft man den TSM-Client für ein inkrementelles Backup an, so kann man dies mit „dsmc i“ oder „dsmc incremental“ tun. Der Client schaut darauf in seiner dsm.sys nach, was er so abarbeiten soll, verbindet sich mit dem Server und fängt an, die Daten der verschiedenen Dateisysteme zu senden.

Naja, fast. Er ignoriert dabei sämtliche ZFS-Dateisysteme. Selbst wenn man sie explizit in der dsm.sys drin stehen hat, weigert sich das Teil, auch nur eine einzige Datei ins Backup zu senden. IBM sagt dazu was sehr klares: ZFS wird nicht gebackupt, weil es nicht gebackupt werden soll. (LINK seit Mitte September nicht mehr funktionstüchtig, Dokument nicht mehr zu finden)

Kommt man allerdings auf die Idee, und probiert den Pfad, unter dem das ZFS eingehängt ist, direkt als Parameter an den dsmc zu übergeben, so funktioniert das ganze ohne Probleme. Auch der Restore-Prozess funktioniert so ausgezeichnet.

Also muss man das Backup der ZFS-Dateisysteme über einen Cronjob erledigen, in dem man die einzelnen Mountpoints der ZFS-Dateisysteme als Parameter übergibt – wenig elegant aber effektiv. Natürlich kann man auch ein kleines Skript schreiben, dass sich mittels zfs mount eine Liste der Dateisysteme zusammensucht, diese zusammenkürzt und daraus Parameter für dsmc bastelt.

for mount in `zfs mount | awk ‚$0 ~ /.*\/.*\/.*/ {print $2}’`; do

dsmc i ${mount} -subdir=yes

done

Gut, die paar Zeilen sorgen auch für ein funktionierendes Backup, aber man könnte es wahrlich einfacher haben!

Merkwürdig an der Sache ist, dass dies zum wiederholten Male Ärger mit dem Backup-Client unter Solaris ist. Zunächst brauchte IBM ewig, bis sie einen Client für Solaris 10 x64 (also die 64bit Intel-Variante) auf dem Markt hatten. Einige Admins behalfen sich mit einem historischen Stück Software, welches perfekt funktionierte. Und nun bringt die Konkurrenz ein nettes Dateisystem auf den Markt, dass IBM erstmal nicht verarbeitet. Die Bemerkung von IBM, ZFS können „planmäßig“ nicht gebackupt werden, stammt aus dem Dezember 2006, und im Februar wurde ein Rechtschreibungsfehler entfernt.

UPDATE 5. Oktober 2007:

IBM hat nicht nur den Hinweis entfernt, ZFS würde „planmäßig“ nicht gebackupt werden, sondern es scheint einen neuen Client zu geben, der mit ZFS klarkommt, so schreibt es zumindest mattdey in den Foren von Open Solaris und so kann ich es nach einem ersten Test auch bestätigen. Merkwürdig ist aber, dass IBM es in den Handbüchern zu dem Client nicht „zugibt“ .


Scheduling von TSM

Der Admin des TSM-Servers der Uni bat mich, unsere Maschinen am Scheduling durch den Server teilnehmen zu lassen und in Zukunft nicht mehr per Cronjob die Daten ‚rüberzuschieben. Die Idee gefällt mir, insbesondere nachdem ich die Lastverteilung des TSM-Servers gesehen habe. Was ist eigentlich so attraktiv an 4:00 Uhr morgens als Zeit für’s Backup? Naja, jedenfalls war er ein wenig entsetzt, als er gelesen hat, dass ZFS und TSM nicht so richtig kooperieren. Damit war die Idee für einige Maschinen erst mal vom Tisch: Alle Maschinen, die irgendwo ein ZFS haben, müssen weiter per Cronjob ihr Backup schieben. Ich war aber so frei, und haben Termine ausserhalb der Spitzenzeiten gewählt.

Die ZFS-freien Maschinen stellen wir jetzt langsam, also eine nach der anderen, auf ge-schedule-tes Backup um. Eigentlich sind dafür nur zwei-drei zusätzliche Zeilen in der dsm.sys notwendig. Anschließend startet man einen kleinen Daemon names dsmcad, der sich dann die Backupzeiten mit dem Server vereinbart und entsprechend den dsmc startet. Ein guter Grund, sich endlich mal mit den Service-Definitionsfiles für das SVC zu beschäftigen, damit dieser Daemon automatisch bei Systemstart gestartet wird.

Schick ist auch, dass man vor und nach dem eigentlichen Ausführen des ge-schedule-ten Backups mit den Paramentern preschedulecmd und postschedulecmd irgendwelche Skripte ausführen lassen kann, beispielsweise um das Viele-MB-Logfile sich zurechzustutzen und als Mail kommen zu lassen.

Zu meiner großen Freude waren diese Optionen auch mal in der Doku sauber erklärt. Daher diesmal ein Lob an IBM, die Doku scheint zumindest an dieser Stelle was zu taugen (unser TSM-Server-Admin fluchte aber über einige andere Kapitel).

Update 31. Oktober 2007:

Da TSM jetzt ZFS anscheinend richtig unterstützt, werden wir nach um nach auch die übrigen Maschinen auf ein Scheduled Backup umstellen. Der Test auf den übrigen Maschinen war sehr erfolgreich, durch das Scheduling haben sich die Backup-Dauern stark verkürzt.