Freitag Aug 10, 2007

Die Zeit schreibt über Sun

Von Rolf Kersten bekam ich gerade einen Hinweis , das die Zeit über Sun schreibt. So schreibt die Wochenzeitung in Der Fußabdruck des Surfers:
Allein der optimierte Code eines neuen Betriebssystems (Solaris 10 von Sun), so heißt es bei Strato, mache die Server um 30 Prozent sparsamer.
und
Zum Beispiel laufen neue, für Strato speziell ausgestattete Server der Firma Sun um 90 Prozent sparsamer als ihre Vorgänger.
Sun predigt das Problem des Energieverbrauchs von Servern schon seit zwei bis drei Jahren. Und nunmehr kommt das Thema auch in den technikfremden Medien und damit auch beim weniger durch schiere Groesse mit dem Problem "Strom und Abwärme" befassten Kunden an. Dabei sollten die Firmen schon aus eigenem Interesse (Strom ist ja nun nicht eben günstig) daran interessiert sein, schon sehr viel weiter zu sein als die Medien. Denn eigentlich ist es recht einfach in einem RZ Strom und damit ziemlich direkt Geld zu sparen.

Mittwoch Aug 08, 2007

What we´ve announced yesterday ...

What did we announce yesterday? In my opinion, the most important chip for Sun. It´s even more important than Rock. When you look around, the loads for single threaded performance decrease, and as the complete industry turns in the direction of "more cores" (even IBM talks about this in the Power7 timeframe). Rock will be important for the highest end. But the future of general purpose computing begins right here, right now. So, why is Niagara 2 so important. Niagara 1 had it´s weak points for general purpose computing. We decided to design a processor with such weaknesses, as we designed it with a certain workload in mind: Internet, a niche according to IBM and HP, but hey ... it´s a really big niche. Niagara 2 was designed as a general purpose CPU. The problem of the single FPU? Addressed ... the N2 has 8 of them? The issue of SSL-centric Crypto-circuits. Addressed ... they were subsituted by full-fledged crypto accelerators. You get 64 threads, you get two 10 Gigabit Ethernet interfaces with chipsets specifically designed for multi core processing, as they implement the processing tasks in a similar multithreaded way. You get eight lanes of PCI Express. 2 Gigabyte/s in and 2 Gigabyte/s out. Solely for storage attach, as you have already two really big fat pipes of Ethernet directly connected to the inner crossbar of the chip. 60 GB/s worth of memory bandwith. The point of beeing only capable to run in single socket systems will be solved soon by Victoria Falls. Imagine a system of two or four this processors. Running on an operating system really capable to handle such large amounts of computing threads because four processor with 64 threads each means scheduling you processors on 256 hardware processor. Not an easy task. Now many people will say: Each thread will only run on 1.4 Gigahertz. This is half as fast as a modern x86 CPU. But is this really a factor? Maybe you can do more cycles in a second, but what´s the gain, when you wait most cycles for memory. A T1/T2 swiches simply to a non-memory starved thread. This is one the reason why a 1.4 GHz CPU can be faster than a 4.7 GHz CPU in SPECfp rate and SPECint rate . It´s like my sister and me at playing racing games on her PC. I´ve lost every time in spite of having the faster car. The problem: I´ve lost traction in every curve of the race track and had to reaccelerate while my sister was able to take the curve without no problems. And: 1.4 Ghz is just the beginning. IBM want´s to tell to plays it´s virtualisation card by saying: "But we have better virtualisation, we can do more than 64 LDOMS". But the decision for limit was a sentient one: When ever you want to switch to a virtual machine, you have to save the actual register sets and restore the stored register contents of the next vm into the register sets. Takes a vast amount of clock cycles. Now: A 64 threads processor has 64 register sets. By limiting the number of domains to the number of threads - i hope you´ve already got the point - you get an important advantage: Switch from a VM to the next in a clock cycle. Neat, isn´t it ?At the end, it´s not important to be able to partition the cpu into smallest fragments. It´s important that the performance isn´t evaporated by the VM layer. Or didn´t you asked your self, why there´s no benchmark result for a virtualized system in the large benchmark portfolio of IBM or why the VMware licence prohibits benchmarks? LDOMs virtualisation is virtualisation done right. Now, as the N2 hasn´t the problem of the single FPU, that prevented N1 of beeing a general purpose CPU, the game changes again. 18 month after we did it with N1 the first time. With Niagara II you get a processor suitable for almost all tasks of computing. And as Jonathan said: You´ve ain´t seen nothing yet. But you see the future of computing today. And really soon in your datacenter. PS: Maybe some statements are really bold ones. But when you´ve read, what i´ve read in the past, when you know what i know, when you saw what i saw you would be so enthusiastic as well.

Pride goes before a fall.

It´s definitly fear. Or do you know a different explanation for such a major malfunction of good sense. Andrew Morton went as far as:
He didn’t mince words. “It’s a great shame that OpenSolaris still exists. They should have killed it,” said Morton, addressing one attendee’s question about the possibility of Solaris’ most notable features being integrated into the kernel. “It’s a disappointment and a mistake by Sun.”
I have an idea, how it came to this comment. I assume he was asked "When do we get ZFS and DTrace for Linux" all day long and at the hundreth time, he lost his nerves.

PS: Mr. Morton, until the developers of SystemTap don´t understand the ideas and concepts behind dtrace, SystemTap won´t be anything near of dtrace.

Dienstag Jul 31, 2007

Hardware für mysql-Server mit der Sun-Brille

Kris hat mal wieder einen seiner gewohnt guten Texte auf die Menschheit losgelassen: Wie gestaltet man einen anständigen mysql-Server?. Ich will da eigentlich nichts gross zu sagen, sondern den Text ein wenig mit der Sun Brille betrachten. Ich lasse dabei mal die Systeme weg, die es auch in ähnlicher Art und Weise bei allen Hersteller gibt. Die X4600 lasse ich auch mal etwas aussen vor. Wir sind da mit 16 schwergewichtigen Cores (demnächst 32 Cores) schon bei Groessenordnungen, die ich nicht mehr mit mysql machen würde.



ZFS
Kris schreibt, das lineare Writes gut sind und hat damit recht. Das macht ZFS von Haus aus. Ein nettes Feature von ZFS ist das Gruppieren von Writes. Writes gelangen aus dem ZIL immer in linearer Art und Weise auf den rotierenden Rost, auf dem sie dann persistieren sollen, sofern natürlich der Platz am Stück da ist. Zudem hat man seit Opensolaris Build 68 zusätzlich die Möglichkeit, das ZFS Intent Log auf eigene Spindeln auszulagern. Auch das bringt noch einmal ein Plus an Performance, inbesondere wenn diese Auslagerung auf Solid State Disks erfolgt.

Zum Thema RAID: RAID-Z ist eine wesentlich bessere Idee als RAID-5, da der full stripe read/full stripe read-Zyklus wegfällt. Das hängt unter anderem damit Zusammen das ZFS ein copy-on-write-filesystem ist in Tateinheit mit der Tatsache, das ZFS mehr über die interne Struktur des Volumes weiss, als herkömmliche Filesysteme. Änderungen werden nie an die selbe stelle geschrieben, deswegen muss man auch nicht die alten Stripes ändern. Dadurch und durch das Write Grouping wird die Anzahl der IOPS wesentlich reduziert, die Entscheidung für oder gegen RAID-Z wird dadurch etwas komplexer. Habe ich viele Spindeln zur verfügung, kann man ich überlegen, eine Reihe von RAID-Z Volumes zu stripen, um mehr IOPS zur Verfügung zu haben. Der Nachteil kommt so potentiell weniger zum Tragen. Trotzdem: Für Datenbanken ist RAID-10 immer noch die performantere Wahl. Ich würde sagen, das für RAIDZ+seperated LOG ungefähr das gilt, was Kris zu RAID-5 mit NVRAM-Haltigen Controller gesagt hat, nur halt ohne RAID-Controller.

Einige andere Features von ZFS sind zudem administrativ ziemlich nützlich: Compression um Test und Developmentdatenbanken möglichst platzsparend vorzuhalten. Checksummen zur Garantierung der Datenvalidität und Snapshots um auf die Schnelle Testdatenbanken zu erzeugen, die keinen zusätzlichen Platz verbrauchen. Schlussendlich gibt es auch noch Hotspot Relocation, die Schreibrequests immer versucht auf die am niedrigsten auszugelastete Platte durchzuführen. Damit wird die Last statistisch gesehen gleichmaessig auf die Platten verteilt.

Obwohl ZFS ein sehr junges Filesystem ist gemessen am Alter von UFS bespielsweise, so konnte bereits in Benchmarks die selbe Leistung wie bei UFS mit directio erreicht werden. Bei diesen Benchmarks war das "seperate logging" noch nicht verfügbar, so das hier nochmals ein positiver Effekt zu erwarten ist.

Hilfreiche Tuningtips für Datenbanken auf ZFS findet man im Solaris Internals Wiki. Eine tiefer gehende Analyse zum Thema ZFS und mysql findet sich nebst einigen Tuningtips in der Website von Dimitri


UltraSPARC T1/Niagara II
Systeme, wie die T1000/T2000 stellen sehr leistungsfähige Datenbankserver dar. Ein recht guter Artikel zu diesem Thema ist bei Digitar zu finden, die über Ihre Erfahrungen. Die Herren schliessen damit, das für Ihren Workload eine T2000 die 13,7 fache Geschwindigkeit einer 2 Prozessor HP Opteron Maschine aufweist. Auch wenn der Test etwa ein Jahr alt ist, hege ich zweifel, das Opterons im letzten Jahr 13 mal schneller geworden sind ;)

Das mysql gewisse Skalierungsprobleme über viele CPU hat, kann ich uebrigens ein Stück weit bestätigen. Auf der T2000 wurde festgestellt, das mysql bei Läufen über 32 threads etwas ins Rudern kommt.Nicht viel, aber feststellbar. Wenn man in 32 Threads gleichzeitig laeuft, treten die lock contention Probleme häufiger auf. Es hat sich herausgestellt, das die Maschine in gewissen Sinne zu schnell für bestimmte Applikationen sein kann. Die Probleme sind allerdings weitestgehend beseitigt.

Sollte man trotzdem auf diese Probleme laufen, kann man den Trick mit der Aufteilung in mehrere Datenbanken auch auf einer Maschine machen. Entweder installiert die beiden Datenbanken in eine Zone (funktioniert auf allen UltraSPARC, SPARC64 und x86-Prozessoren) oder in einer Logical Domain (funktioniert nur mit sun4v). Diese kann man dann auf die Prozessoren binden. Die Replikation findet dann innerhalb des Systems statt. Anders als VMware oder XEN laufen beide Virtualisierungsmethoden auf Solaris mit nur sehr wenig Overhead, so das das ein valider Weg ist.

Wichtig ist: Die T2000 wird für einen einzelnen Query wahrscheinlich langsamer sein. Interessant wird die Maschine dann, wenn ich viele gleichzeitige Querys ausführe. OLTP-artige Lasten für Webserver oder ähnliches rennen normalerweise wie der Teufel auf der Kiste. Datawarehousing ist dann eine gute Idee, wenn die Loader- und Analyse-Prozesse multithreaded sind. Ansonsten ist eine Opteronmaschine für kleine und SPARC für grosse DWH mit Sicherheit eine bessere Wahl.

Die Listenpreise für die Systeme finden sich hier. Aber wer zahlt schon Listenpreise. Ausserdem gilt es zu bedenken, das eine T2000 full-blown etwa 350 Watt schluckt. Das braucht die Marktbegleitung teilweise alleine, um die Prozessoren warm zu bekommen ;)



Allgemeine Systemarchitektur
Michael Fucknerhat ja in seinem Blog eiinen Vorschlag gemacht, wie er sich eine mysql-Maschine vorstellt.Ob ich wirklich 26k für ein solches System ausgeben moechte ... ich weis nicht ... am Ende ist es auch nur eine heftig gepimpte Opteronmaschine. SPARC können im RAS-Sektor noch einige Dinge mehr ... Opterons sind doch ziemliches best-effort-computing ;)

Nein ... mal ernsthaft: Ich würde nicht die internen Plattenbays nutzen, weil dadurch ein Clusterfailover nicht möglich ist. Wenn ich die Platten extern habe, kann ich über ein SAN einen Clusterfailover durchführen, der auf jeden Fall bis zur letzten abgeschlossenen Transaktion aktuell ist. Interne Platten sind zum Booten und für Systemlogs. Alles andere gehoert auf Speicher, der im Cluster wandern kann.

Ein sehr gutes Clusterfamework ist übrigens Sun Cluster, das es jetzt auch als Cluster Express in einer OpenSource-Version gibt. Sun Cluster Express ist sozusagen das Gegenstück zu Solaris Express. Grosse Teile sind schon offen, Rest kommt bald.

Braucht man wirklich keinen Clusterfailover, ist eine Sun Fire X4500 auch eine gute Alternative. 48 Spindeln um damit rumzuspielen, zwei Dualcore-Opterons und 16 GB Hauptspeicher. Gibt einen ziemlich guten Datenbankserver ab, insbesondere, wenn der Workload schreiblastig ist.



You ain't seen nothin' yet.
Richtig gespannt bin ich auf die NiagaraII Systeme. Ich habe zwar schon Benchmarks gesehen, deren Veröffentlichung mir unter den Nägeln brennt, aber ich darf ja nicht. Da kann man sich noch einiges on top erwarten.

Freitag Jul 27, 2007

FlashSSD for a seperated ZIL

I´ve reported about the separated ZIL a few days ago. The problem of the described NVRAM PCI card is, that you can´t do a clusterfailover with such a device. How do you want to failover the seperate log, when the log is on a card in the failed server? Sun had a product called Prestoserve, that was used to accelerate NFS and DB. It was static RAM with a battery. It was great for benchmarks, but suffered by the cluster problem.

Thus you should use some external device, that can failover with the rest of your storage. The obvious choice would be a RAM-based Solid State Disk(SSD). But these are quite expensive: You need the RAM, you need a harddisk to keep the data persistent when power fails, and you need a rechargeable battery or an capacitor that´s able to power the SSD until all data is written to the hard disk.
A Flash-Based SSD would be a more sensible choice, as Flash is a non-volatile memory by nature. Such a disk costs you approximatly 400$. But most people think "Oh no, wear will destroy it within a few days". Experiences with el-cheapo CF-cards underline this assumption.

But let´s calculate with the specifications of a leading brand flash disk. Let´s assume: A 32 GB flash-based SSD is specified for 2.000.000 write cycles. We have a sustained stream of 40 MB per second (conservative assumption). The wear leveling is perfect (perhaps supported by a seperate ZIL algorithm, that looks at the flash SSD as a cyclic buffer). Okay, a little math:


So this flash SSD wouldn´t fail by wear within the usable live of the storage and the server, even when you write 40 MB every second to it. I´m sure, that a flash disk doesn´t run such a long time, but this is not a wear problem, it´s the problem, that modern electronic hasn´t the build quality of former times.
Based on this considerations, a flash SSD would be an interesting choice for the separated ZIL. Or at least: Wear isn´t a reason for not using Flash SSD


PS: There is one point, i´m not perfectly sure, but i interpret the 2 million write cycles as the ability to erase and write the full disk 2 million times.
About

user13366125

Search

Top Tags
Categories
Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute