Dienstag Jan 06, 2015

What's up with LDoms - Verzeichnis der Artikel

In den letzten Jahren - ja, es sind schon Jahre - habe ich eine kleine Artikel-Reihe ueber LDoms und ihre verschiedenen Features geschrieben.  Es ist hoechste Zeit, auch ein kleines Inhaltsverzeichnis dafuer zu veroeffentlichen:

Ich werde dieses Verzeichnis aktuell halten, falls es neue Artikel in dieser Reihe geben sollte.

Dienstag Mai 20, 2014

LDoms: Verbesserte vDisk Performance

Bei der Leistung von virtuellem IO sollte man seine Erwartungen in realistischen Grenzen halten.  Darauf habe ich in all den Jahren in allen LDom Workshops hingewiesen.  Und ich werde jetzt nicht damit aufhoeren.  Virtuelles IO ist immer mit gewissen Kosten verbunden, einfach deswegen, weil es einen gewissen Aufwand bedeutet, die physischen IOs in virtuelle IOs zu uebersetzen.  Und bis zur Entdeckung der Zeitreise wird dafuer immer auch ein wenig Zeit gebraucht werden.  Soweit, so schlecht.  Es gibt aber auch gute Nachrichten:

Erstens ist der Overhead virtuellen IOs in vielen Faellen tatsaechlich kleiner als befuerchtet - die LDom Implementierung ist sehr effizient.  Und in vielen dieser vielen Faellen schaded dieser Overhead nicht.  Meist, weil es der Anwendung egal ist, bzw. das virtuelle IO schnell genug.

Zweitens gibt es natuerlich gute und weniger gute Arten, virtuelles IO zu konfigurieren.  Wenn man sich an die guten haelt (wie ich sie bspw. hier besprochen habe), kann man die Anzahl der Faelle, in denen virtuelles IO einfach gut genug ist, noch ein gutes Stueck erhoehen.

Aber es gibt natuerlich auch die Faelle, in denen es einfach nicht reicht.  Gluecklicherweise gibt es noch weitere gute Nachrichten:

Die Leistung des virtuellen Netzwerks wurde mit einer neuen Implementierung erheblich verbessert.  Durch den Einsatz von Large Segment Offload (LSO) und einiger anderer Techniken wurde der Durchsatz gesteigert und die Latenz reduziert - bis an einen Punkt, an dem die Leistung des virtuellen Netzwerks als Grund fuer Performanceprobleme weitgehend entfallen ist.  Das war in LDoms 3.1.  Jetzt ist virtuelles Disk-IO an der Reihe, mit ganz aehnlichen Verbesserungen.

Beim Thema Disk IO und Performance gibt es eine grundlegende Empfehlung:  Die IO-Last auf moeglichst viele LUNs verteilen.  Das war bereits so, lange bevor man auch nur an Virtualisierung gedacht hat.  Der Grund dafuer ist einfach die begrenzte Anzahl an IOPS, die eine einzelne LUN liefern kann.  Dabei ist es egal, ob es sich bei dieser LUN um eine einzelne physische Platte oder ein Volume eines groesseren Disk Arrays handelt.  IOPS einer einzelnen LUN sind begrenzt und IOs fuer diese LUN werden in einer sehr sequentiellen Warteschlange auf diese LUN warten.  Eine einzelne Platte liefert seit Jahren ca. 150 IOPS.  Oder auch 300.  Eine SAN LUN mit einem starken Array im Hintergrund liefert vielleicht 5000 IOPS oder ein paar mehr.  Aber das reicht nicht, heute so wenig wie gestern.  Deswegen hat man RAID 1 erfunden.  Und die Virtualisierung von Servern und Storage aendern nichts an dieser Situation.  Fuer LDoms bedeutet das nun einfach, mehrere LUNs, also mehrere vDisks pro Gast zu konfigurieren. In vielen Faellen ist das ausreichend, um gute IO Performance zu bekommen.  Leider gab es jedoch zu viele Faelle in denen das eben nicht gut genug war und man letzten Endes zurueck zu physischem IO musste.  Nun gibt es natuerlich diverse Moeglichkeiten, physisches IO und Server-Virtualisierung mit LDoms zu verbinden.  Aber befriedigend war die Situation nicht.

Mit der Freigabe von Solaris 11.1 SRU 19 (und einem entsprechenden Patch fuer Solaris 10 wenig spaeter) wird nun auch fuer den vds/vdisk Software Stack eine neue Implementierung eingefuehrt, die diese Situation grundlegend aendert.  Durchsatz und Latenz von virtuellem Disk-IO werden wesentlich verbessert, wie man an den folgenden Diagrammen ablesen kann.

Dieses erste Diagramm zeigt IOPS im Vergleich von Bare Metal mit virtuellem Disk-IO, sowohl mit der alten als auch mit der neuen Implementierung.  Wie man leicht erkennen kann gibt es erhebliche Verbesserungen, die neue Implementierung unterscheidet sich nur marginal von Bare Metal.  Die Unterschiede sind so gering, dass es sich auch um statistische Ungenauigkeiten bzw. normale Schwankungen zwischen zwei Messungen handeln koennte.  Zu beachten ist, dass die hier gezeigten Messwerte mit 28 SAN LUNs erzielt wurden.  Erwartungen, eine einzelne LUN wuerde nun ploetzlich 150k IOPS liefern, muss ich leider enttaeuschen.  Die Verbesserung gegenueber der alten Implementierung sind mit bis zu 55% erheblich.  Wichtig zu beachten ist allerdings, dass man mit nur einem IO Strom (den "Threads" im Diagram) und einer einzelnen LUN weniger offensichtliche Verbesserungen beobachten wird.  Das liegt daran, dass wesentliche Teile der neuen Implementierung sich auf die De-Serialisierung der IO-Infrastruktur konzentrieren, was man natuerlich nicht bemerken wird, wenn man nur einen einzelnen, seriellen IO-Strom misst.  Im wirklichen Leben sind die grossen, IO-hungrigen Anwendungen jedoch meist parallel unterwegs.  Auch wenn das eigene Storage-Backend mit den parallelen Anfragen ueberfordert ist (z.B. weil man aus Versehen auf der einen, internen Platte testet) wird man wenig Veraenderung feststellen.

Durchsatz ist somit kein Problem mehr (mit 150k IOPS und 1.1 GB/sec virtuellem IO in diesem Test meine ich das behaupten zu duerfen).  Aber wie sieht es mit der Latenz aus?  Dazu das naechste Diagramm:

Auch hier sieht man wieder, dass sich die Latenz der neuen Implementierung kaum von Bare Metal unterscheidet.  Der groesste Unterschied sind 4% im Fall von 2 parallelen Threads.   Das ist wenig genug um ueber den Begriff "Zero Overhead" nachzudenken, zumindest in Bezug auf IO Leistung.  Wo wir gerade von Overhead reden:  Ich nennen den Overhead, der durch Virtualisierung entsteht gerne auch "Virtualisierungssteuer" - die Ressourcen die man in die Virtualisierung selbst investiert, oder aber die Performance die durch oder wegen der Virtualisierung verloren geht.  Im Falle von LDoms Disk IO haben wir damit soeben eine erhebliche Steuersenkung erfahren:

Dieses letzte Diagramm zeigt um wie viel hoeher die Antwortzeit mit der alten Implementierung war und wie viel davon wir mit dieser beeindruckenden Programmierleistung  der neuen Implementierung zurueck bekommen.  Vorher musste man bis zu 55% Virtualisierungssteuer fuer virtuelles Disk-IO bezahlen, jetzt sind es 4% oder weniger.  Ein grosses "Danke Schoen!" an Engineering!

Natuerlich darf an dieser Stelle ein Haftungsausschluss nicht fehlen:  Ihre eigenen Ergebnisse werden sich von diesen Testergebnissen unterscheiden.  Die hier gezeigten Resultate wurden mit 28 LUNs aus einer irgendwie gearteten FC Infrastruktur gemessen.  Die Tests wurden mit vdbench in einer Mischung aus 60% lesendem und 40% schreibendem Random-IO gemacht, mit zwischen 2 und 20 parallelen Threads.  Das ist eine IO-Last, die jedes IO-System stark beansprucht und gleichzeitig das IO-Muster, bei dem die hoechste Virtualisierungssteuer beobachtet wurde.  Dennoch muss klar sein, dass sich die Ergebnisse von denen in anderen Tests oder tatsaechlichen Produktionsumgebungen unterscheiden werden und evtl. nicht die gleichen Verbesserungen erreicht werden koennen.  Auch wenn ich sehr optimistisch bin, dass sie sehr aehnlich sein werden.

Abschliessend kann man sagen, dass mit den neuen, wesentlich verbesserten Implementierungen fuer virtuelle Netzwerke und jetzt auch virtuelle Platten die Bandbreite der Anwendungen, die sich problemlos auf virtuellem IO betreiben lassen erheblich vergroessert hat.  Was den Erwartungen der Kunden entspricht, die ich in meinen Workshops treffe:  High End Performance ist eine Selbstverstaendlichkeit fuer SPARC Systeme, virtualisiert oder nicht.

Kurz vor Schluss: Was muss man eigentlich tun um in den Genuss dieser Verbesserung zu kommen?
  • Bei Solaris 11 muss der Update auf Solaris 11.1 SRU 19 in
    • Allen Gast Domains die die neue Implementierung nutzen wollen, und
    • Allen IO Domains die die Infrastruktur hierfuer bereit stellen, eingespielt werden.
    • Darin enthalten ist natuerlich auch der Update auf LDoms Manager 3.1.1
    • Es muessen beide Partner, Gast und IO-Domain aktualisiert werden, ansonsten wird die alte Implementierung weiter verwendet.
  • Einen Patch fuer Solaris 10 wird es in Kuerze natuerlich auch geben.

Update 2014-06-16: Patch 150400-13 fuer Solaris 10 ist nun verfuegbar.  Im Readme stehen die Details.

Donnerstag Jul 04, 2013

What's up with LDoms: Eine Artikel-Reihe zum Thema Oracle VM Server for SPARC

Unter dem Titel "What's up with LDoms" habe ich soeben den ersten Artikel einer ganzen Reihe veroeffentlicht.  Ziel der Artikelreihe ist es, das vollstaendige Feature-Set der LDoms zu betrachten.  Da das ganze recht umfangreich ist, werde ich hier von der Zweisprachigkeit abweichen und die Artikel ausschliesslich auf Englisch verfassen.  Ich bitte hierfuer um Verstaendnis.

Den ersten Artikel gibt es hier: What's up with LDoms: Part 1 - Introduction & Basic Concepts

Viel Spass beim Lesen!

2012-07-13 Update:

2012-11-06 Update:

2013-07-04 Update:

2015-01-06 Update:

Montag Jan 14, 2013

LDoms IO Best Practices & T4 Red Crypto Stack

Die DOAG Konferenz & Ausstellung 2012 war ja bereits im November.  Endlich finde ich die Zeit, die Slides zu den beiden Vortraegen auch hier zugaenglich zu machen.

  • In "LDoms IO Best Practices" geht es darum, die verschiedenen Varianten von Disk- und Netzwerk-IO darzustellen, zu vergleichen und Anhaltspunkte fuer einen optimalen Einsatz zu geben.  Der eine oder andere Performance-Hinweis ist natuerlich auch dabei.
  • In "T4 & the Red Crypto Stack" zeige ich, zusammen mit meinem Kollegen Heinz-Wilhelm Fabry, wie man Verschluesselung und andere Sicherheitsmechanismen in den verschiedenen Schichten des Red Stack benutzen kann, um eine recht gut abgesicherte Datenbank zu implementieren.

Ich hoffe, die Slides sind hilfreich und nuetzlich!

Montag Sep 10, 2012

Secure Deployment of Oracle VM Server for SPARC - aktualisiert

Vor einiger Zeit hatte ich ein Papier mit Empfehlungen fuer den sicheren Einsatz von LDoms veroeffentlicht.  In der Zwischenzeit hat sich so manche veraendert - eine Aktualisierung des Papiers wurde noetig.  Neben einigen kleineren Rechtschreibkorrekturen waren auch ettliche Links veraltet oder geandert.  Der Hauptgrund fuer eine Ueberarbeitung war jedoch das Aufkommen eines zweiten Betriebsmodels fuer LDoms.  Ein einigen wenigen kurzen Worten:  Insbesondere mit dem Erfolg der T4-4 kam es immer oefter vor, dass die Moeglichkeiten zur Hardware-Partitionierung, die diese Platform bietet, genutzt wurden.  Aehnlich wie bei den Dynamic System Domains werden dabei ganze PCIe Root-Komplexe an eine Domain vergeben.  Diese geaenderte Verwendung machte eine Behandlung in diesem Papier notwendig.  Die aktualisierte Version gibt es hier:

Secure Deployment of Oracle VM Server for SPARC
Second Edition

Ich hoffe, sie ist hilfreich!

Freitag Jun 29, 2012

Oracle VM Server for SPARC Demo Videos

Gerade bin ich ueber einige recht gut gemachte Demos neuerer LDom Features gestolpert.  Man findet sie im Youtube Kanal "Oracle VM Server for SPARC".  Insbesondere die beiden Videos ueber Cross-CPU Migration und Powermanagement sind sehenswert :-)

Donnerstag Mai 24, 2012

OVM Server for SPARC 2.2 verfuegbar!

Schon laenger erwartet, ist sie jetzt da:  Die neue Version 2.2 von Oracle VM Server for SPARC. Ohne hier die Dinge nur zu wiederholen, das wichtigste in Kuerze:

Eine gute Zusammenfassung gibt es im Oracle Virtualization Blog. Zusaetzlich natuerlich:

Froehliches Virtualisieren!

Donnerstag Jun 09, 2011

OVM Server for SPARC 2.1 ist da!

Die neueste Version von OVM Server for SPARC aka LDoms ist da!  Hier die Presse-Meldung...

Was, schon wieder eine neue Version?  Na ja, das am meisten vermisste Feature in den bisherigen Versionen wurde fertig, und da war ein Release einfach unumgänglich ;-)  In der neuen Version 2.1 wird aus "Warm Migration" endlich "Live Migration".  Was es sonst noch an Neuerungen gibt, steht in "What's New".  Weitere Details zur Live Migration werden sicherlich auch bald bekannt und ggf. auch hier erwähnt werden.  Den Download gibt es bei eDelivery, die Dokumentation wie immer auf OTN.

Donnerstag Nov 05, 2009

Link based IPMP fuer LDoms 1.2

Und schon wieder ein Patch fuer LDom Manager 1.2.  Diesmal nicht wegen echter Fehler, sondern eher ein Feature-Patch.  Er bringt die aktualisierte Kommandozeile mit, um die mit Solaris 10 update 8 bereits in den vnet/vswitch Treibern implementierte Unterstuetzung fuer link-based IPMP zu nutzen.

Dienstag Okt 27, 2009

Neuer LDoms Manager Patch fuer LDoms 1.2

Seit heute gibt es die neueste Version des LDoms Manager Patch fuer LDoms 1.2. Es werden damit alle bekannten Probleme mit Crypto DR, Elastic Power Mode, Domain Migration und der Zusammenarbeit mit Ops Center behoben. Daher wird dringend Empfohlen, alle LDom 1.2 Installationen damit zu patchen.

Mittwoch Okt 21, 2009

LDoms fuer OpenSolaris

Cloudcomputing ist ja in aller Munde.  Jede Form von Rechner, die im Internet buchbar ist, befindet sich derzeit in Wolken ;-)  Eine besondere Wolke gibt es fuer die Entwickler von OpenSolaris: Die OpenSolaris Testfarm.  Dort kann jeder Entwickler, der an einem OpenSolaris-Projekt mitarbeitet, sich einen Solaris Container oder auch einen ganzen Server zu Testzwecken reservieren.  Seit neuestem nun auch eine LDom.  Damit OpenSolaris auch in LDoms optimal laeuft (nicht, dass das heute nicht auch schon so waere).  Virtualisierung sinnvoll eingesetzt!

Donnerstag Okt 15, 2009

LDoms mit OpsCenter 2.5 verwalten

Seit letzten Freitag ist OpsCenter 2.5 verfuegbar.  Wesentliche Neuerungen sind die Unterstuetzung von LDoms und Solaris Containern.  Damit hat OpsCenter eine wirklich groesse Huerde genommen.  Auch viele "Kinderkrankheiten" sind inzwischen beseitigt.  Mehr ueber OpsCenter 2.5 auf der Produktseite.

Donnerstag Sep 24, 2009

Linux in LDoms - und es geht doch

Linux fuer SPARC gibt es ja schon laenger.  Mit Ubuntu 6.06 gab es auch, zumindest fuer einige Zeit, eine Version mit Support auf T[12]000.  Dass es immer noch funktioniert - gerade auch als Gast in einer LDom, zeigt jetzt Juanjo Amor auf seinem Blog mit einem schoenen Screenshot.  Wie er's gemacht hat, steht in einer knappen aber praezisen Anleitung.  Wer also - warum auch immer - Linux in einer LDom braucht: Viel Spass damit! :-)

Donnerstag Feb 26, 2009

LDoms und Container auf der Schacholympiade

"Brauchen .... 1.000.000  gleichzeitig gehaltene TCP Verbindungen" war die erste aber nicht letzte interessante Information bei der Unterstützung der Schacholympiade in Dresden.  Die Zahl basiert auf dem Ansturm von geschaetzten 1 Million gleichzeitiger "Zuschauer". Um diesen Zahlen  weltweit gewachsen zu sein, hat Sun den Veranstaltern der Schacholympiade 2008 in Dresden zwei T5240 zur Verfuegung gestellt.  Damit wurde der gesamt Webverkehr bedient, der durch die Liveuebertragung der Partien ueber das Internet entstand.  Es war die erste Schacholympiade, die vollstaendig live im Internet uebertragen wurde. 


Derartige Schätzunge basieren zumeist ersteinmal auf reinen Annahmen zur Anzahl von Benutzern. Im Falle der Schacholympiade war der Wert bestimmt nicht zu Tief angesetzt, da ein stabieler und performanter Auftritt auch entsprechend mit "headroom" geplant werden will. Nun lässt sich nicht immer direkt von der Anzahl der Benutzer auf die gleichzeitig gehaltenen TCP-Verbindungen schliessen, in dem vorliegenden Fall war allerdings die Anwendung welche die Darstellung bei den Zuschauern übernimmt entsprechend hinsichtlich des Netzwerkverkehrs optimiert. Zudem spielt auch noch die Antwortszeit auf einen Request eine signifikante Rolle, dazu aber später. 


Technisch ist das Hauptproblem bei einem solchen Webauftritt die Anzahl der gleichzeitig zu haltenden TCP-Verbindungen.  Ein einzelner TCP-Stack kann zwar rein theoretisch eine fast unbegrenzte Anzahl an eingehenden Verbindungen gleichzeitig halten, allerdings wird die Verwaltung der Sessions als auch der einzelnen Verbindungen zunehmend aufwändiger und damit langsamer. Je langsamer der Zugriff auf die einzelnen Sessiondaten, desto länger braucht der einzelne HTTP-Request innerhalb der TCP-Verbindung, desto mehr TCP-Sessions stehen am System an, desto.... will man mehr, benoetigt man mehrere TCP-Stacks (siehe auch die Warteschlangentheorie) .  Um hier Abhilfe zu schaffen bleibt eigentlich nur übrig, den Clients mehr TCP-Stacks zur Verfügung zu stellen. Das wird in solchen Faellen z.B. durch Reverse-Proxies erledigt, die dem eigentlichen Webserver vorgeschaltet werden.  Es könnten auch mehrere Web-Server zum Einsatz kommen, allerdings haben die Proxies diverse andere Vorteile wie z.B. die Verwaltung von grösseren Content-Caches als es dem normalen Web-Server möglich ist.


Um ausreichend viele solcher Proxies konfigurieren zu koennen, wurden die beiden T5240 mit je einer LDom mit 12 Cores konfiguriert.  In diesen beiden LDoms liefen jeweils 9 Solaris Container mit dedicated IP Stacks, womit dann ausreichend viele IP Stacks verfuegbar waren.  Die notwendigen Netzwerkverbindungen wurden ueber das "interne" Netzwerk der LDoms geliefert - extern waren pro Server eine 10GBit Ethernetverbindung im Einsatz.  Insgesamt sah die Konfiguration einer der beiden T5240 also so aus:



  • Eingesetzte Software:


    • JES Proxie- und Webserver

    • Solaris 10

    • ZFS

    • LDoms 1.0.3


Mit dieser Archtiktur wurde im Laufe der Veranstaltung einiges geleistet:


  • 960 Millionen Requests in 1.5 Wochen

  • 500000 eindeutig identifizierbare Hosts

  • Zusaetzlich natuerlich viele Zugriffe ueber die Proxies der grossen ISPs

  • Peak Leistung:


    • 11000 neue TCP-Sessions pro Sekunde

    • 200000 gehaltene Verbindungen

    • mittlere Antwortzeit 20ms


  • Hier noch ein Schnappschuss der Routerstatistiken von der Turnierwoche:


Die Auslastung der Server war dabei moderat:



  • Proxies: 15%  (96 Strands)

  • Service Domains: 6% (32 Strands)


Die erfreulich geringen Antwortzeiten waren ein direkter Erfolg der Gesamtarchitektur.  Die JES Proxie-Server hielten ihren Cache in einem ZFS Filesystem der LDom.  Der ARC des ZFS hatte nach einer gewissen Anwaermphase fast den gesamten Content gecached, so dass ein Grossteil der Anfragen direkt aus dem RAM der Server beantwortet werden konnte - es wurde also Antwortzeit durch RAM "gekauft".  Damit wurde es moeglich, die Anzahl der zu haltenden Verbindungen deutlich unter dem vorab geschaetzen Wert von 1 Million Sessions zu halten.


Ein sich ankuendigender Engpass war die Last auf dem einen VSwitch, der die Container mit virtuellen Netzwerkanschluessen versorgte und den gesamten Netzwerkverkehr bewaeltigen musste.  Hier konnte auf dem einzelnen Strand eine Auslastung von bis zu 80% beobachtet werden.  Waere die Last weiter gestiegen, haette die Konfiguration eines zweiten VSwitches und die Verteilung der vnet Ports auf beide VSwitches natuerlich schnell Abhilfe geschaffen.


Die Veranstalter waren nach Abschluss des Turniers hoch zufrieden mit der Leistung der Maschinen, die einen fluessigen und stabilen Webauftritt lieferten.  Dass dieser Webauftritt mit nur 2 Servern in insg. 4 Hoeheneinheiten realisiert werden konnte zeigt sehr anschaulich, wie effizient man mit Solaris, Containern, LDoms und ein wenig CMT-Hardware einen leistungsfaehigen Webauftritt realisieren kann.

Montag Feb 23, 2009

Oracle jetzt in LDoms supported

Lange erwartet, ist er nun da - der LDoms Support von Oracle.  Sowohl Single Instance als auch RAC sind seit gestern von Oracle fuer den Betrieb in LDoms (1.0.3 oder höher) freigegeben.  Noch sind LDoms nicht als "Hard Partition" im Sinne der Lizenzberechnung anerkannt, aber das ist nur eine Frage der Zeit.  Und schliesslich sind Solaris Container schon lange hierfür akzeptiert, so dass man als Übergangslösung auch einen Container in der LDom verwenden kann...


Die Supportstatements von Oracle findet man z.B. hier:
http://www.oracle.com/technology/products/database/clustering/certify/tech_generic_unix_new.html
oder in Metalink.

About

Neuigkeiten, Tipps und Wissenswertes rund um SPARC, CMT, Performance und ihre Analyse sowie Erfahrungen mit Solaris auf dem Server und dem Laptop.

This is a bilingual blog (most of the time). Please select your prefered language:
.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2015
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