Mittwoch Jan 26, 2011

Logical Domains - aber sicher

LDoms Oracle VM Server for SPARC werden schon lange eingesetzt.  Und ich bekam immer mal wieder die Frage zu hoeren, wie sicher sie denn eigentlich seien.  Ein Kunde wollte es ganz genau wissen, und so beauftragten wir einen unabhaengigen Gutachter.  Das Ergebnis war erfreulich, aber leider nicht als Bettlektuere geeignet.  Deswegen, und um die eigentliche Untersuchung um Empfehlungen zum Betrieb zu erweitern, schrieb ich auf dieser Grundlage ein Whitepaper.  Dank der Uebernahme durch Oracle verzoegerte sich die Veroeffentlichung etwas.  Das hat aber den Vorteil, dass es jetzt auch auf dem aktuellesten Stand ist.  Ich bin deshalb froh, endlich vorstellen zu koennen:


Secure Deployment of Oracle VM for SPARC


Meinen Dank an Steffen Gundel von der Cirosec, der mit seiner Untersuchung die Grundlage fuer dieses Papier schuf!


Ich hoffe, das Papier hilft dem einen oder anderen weiter!


Viel Spass beim Lesen!

Donnerstag Okt 28, 2010

Ist T3 nun doppel so schnell oder halb so teuer ?

Eigentlich ist es ja unfein, andere die Arbeit machen zu lassen und dann nur darueber zu berichten.  Diesmal jedoch bin ich einfach dankbar, dass jeman anderes die etwas muehsame Arbeit der Preis- und Leistungsvergleiche uebernommen hat, und verweise deswegen gerne auf einen Artikel im "Register", in dem die neuen T3 Systeme in Bezug auf Preis und Leistung mit ihren Vorgaengern verglichen werden.  Bleibt eigentlich nur noch die Frage: Ist T3 nun doppelt so schnell oder halb so teuer? Was fuer eine angenehme Frage!

Dienstag Sep 21, 2010

Keine Entschuldigung fuer keine Sicherheit

Schon seit der UltraSPARC T2 gibt es eigentlich keine Entschuldigung mehr, einen Web- oder Applicationserver nicht mit sicherem SSL zu betreiben.  Die in die CPU integrierte Crypto-Beschleunigung, die kostenfrei verwendet werden kann, ermoeglicht schon seit Jahren Sicherheit per SSL.  Mit der neuen T3 CPU wurden nicht nur die moeglichen Algorithmen modernisiert.  Auch die Anleitungen, wie dieses Feature zu nutzen ist, wurden auf den neuesten Stand gebracht.  Hier die ersten beiden - mehr kommt vermutlich in Kuerze:


Frohes Verschluesseln!

Donnerstag Aug 12, 2010

LDoms und LDCs

Oracle VM for SPARC, wie sie jetzt heissen, verwenden bekanntlich eine ganze Anzahl von Logical Domain Channels (LDC) fuer den Datenfluss der virtuellen Geraete. Ich werde immer mal wieder gefragt, wie man denn feststellen kann wieviele LDCs verwendet werden, und wofuer.  Hier ein paar Hinweise dazu:



  1. Wie viele LDCs gibt es ueberhaupt, und wie werden sie verbraucht?
    In den Release Notes zu LDoms 3.0 findet man die Antwort.  Zum Beispiel:


    • UltraSPARC T2 hat 512 LDCs pro Domain

    • UltraSPARC T2+ hat 786 LDCs pro Domain

    Sie verbrauchen sich nach folgender Formel:
    Summe LDCs = 15 + 1 + g + g \* ( n + d + c ), wobei


    • g die Anzahl der Gast Domains,

    • d die Anzahl der in jedem Gast konfigurierten virtuellen Disks,

    • n die Anzahl der in jedem Gast konfigurierten virtuellen Netzwerk Ports und

    • c die Anzahl der virtuellen Consoleports fuer jeden Gast (=1) ist.

    Falls g und n nicht in jedem Gast gleich ist, wird die Berechnung etwas weniger elegant. Aber das Prinzip bleibt das gleiche.


  2. Wie kann man sehen, wofuer die LDCs verwendet werden?


    1. In der Control Domain gibt das Kommando ldm list-bindings -e eine Auflistung aller konfigurierten Ressourcen, unter anderem auch der LDCs.  Das sieht dann fuer die virtuellen Konsolen bspw. so aus:

      VCC
      NAME PORT-RANGE
      vconsole 5000-5050
      CLIENT PORT LDC
      debian@vconsole 5001 0x18
      rivermuse@vconsole 5002 0x1c
      gentoo@vconsole 5000 0x11
      demo@vconsole 5008 0x3d
      install@vconsole 5012 0x50
      rac1@vconsole 5005 0x35
      rac2@vconsole 5006 0x66
      Eine mit Scripten verwertbare Ausgabe gibt der Switch "-p", das Kommando ldm list-bindings -e -p|grep ldc=0|awk -F\\| '{print $NF}' gibt einem damit eine knappe Liste aller verwendeter LDCs, die man bspw. mit wc auch zaehlen kann.


    2. Wichtig zu beachten ist, dass LDCs pro Domain, nicht pro System gezaehlt werden!

    3. Kstat hilft auch noch weiter:
      Sowohl in der Control Domain als auch in den einzelnen Gaesten gibt es fuer die jeweiligen Netzwerk-Komponenten kstat-Zaehler.  Diese findet man mit kstat|grep ldc und kann dann ggf. weitere Werte abfragen.




Das alles ist insofern interessant, als es einem die Planung einer Plattform erleichtert.  Die Anzahl der LDCs sollte in den meisten Faellen keine wirkliche Beschraenkung darstellen.  Mit obiger Formel kann man leicht ausrechnen, dass man selbst auf T2 bereits 124 Gaeste betreiben kann.  Auf T2+ waeren es 193, hier wird also die supportete Anzahl von 128 bereits ueberschritten.  Allerdings werden in der Realitaet mehr als nur die 3 notwendigen Geraete pro Gast konfiguriert werden, so dass die moegliche Anzahl der Gaeste ggf. geringer sein wird.  Wenn daher jetzt die Frage gestellt wird, wie viele zusaetzliche Gaeste moeglich sind, kann man mit diesen Mitteln leicht nachsehen, wieviele LDCs noch verfuegbar sind, und wie viele man fuer den neuen Gast brauchen wird.


(Dieser Eintrag wurde am 19.2.2013 und erneut am 27.1.2014 aktualisiert)

Dienstag Jun 01, 2010

Eignung einer Anwendung fuer CMT

CMT-CPUs gibt es ja nun schon eine ganze Weile.  Und die Tatsache, dass diese CPUs fuer parallele, durchsatzorientierte Anwendungen entwickelt wurden, wurde auch schon haeufig diskutiert und beschrieben.  Die Frage, ob eine spezielle Anwendung nun aber geeignet ist oder nicht, bleibt bestehen und wird mir immer wieder gestellt.  Ich will hier versuchen, ein paar Hilfestellungen zu geben, wie man diese Frage selbst beantworten kann.


Erstes und letztlich wichtigstes Kriterium sind immer die Antwortzeiten der Anwendung.  Sind diese zufriedenstellend, ist die Anwendung CMT-geeignet.  Sind sie es nicht, und liegt der Grund dafuer in der CPU und nicht etwa in der Latenz sonstiger Komponenten (remote Database, etc.) muessen andere CPU-Architekturen getestet werden.

Darueber hinaus ist es natuerlich von Vorteil, wenn die Anwendung multi-threaded ist, und die einzelnen Threads der Anwendung auch wirklich \*parallel\* Arbeit verrichten.  Nur dann kann die Anwendung eine CMT-CPU auch wirklich auslasten. Dabei ist es wichtig zu verstehen, dass Server-Auslastung niemals als Kriterium fuer gute Anwendungsleistung gelten kann.  Diese kann nur mit Anwendungs-Mitteln festgestellt werden, indem man den Durchsatz oder die Antwortzeiten oder beides misst.  Server- oder CPU-Auslastung kann lediglich ein Hinweis dafuer sein, ob die verfuegbaren Resourcen auch tatsaechlich genutzt werden, um Anwendungsleistung zu liefern.


Um festzustellen, ob eine Anwendung multi-threaded ist, und die Threads auch parallel beschaeftigt sind, kann man bspw. das Tool threadbar verwenden.  Alternativ kann man das Kommando "prstat -L" verwenden.  Dabei werden die einzelnen Threads der Prozesse nach Ihrer CPU-Belastung sortiert angezeigt.  Wuenschenswert sind hier viele Threads, die mehr als 0% CPU-Auslastung anzeigen.  Wichtig ist jedoch auch festzustellen, ob einzelne Threads durch die Single-Thread Leistung der CPU  begrenzt wird.  Dies kann man naeherungsweise ebenfalls mit prstat beobachten.  Die "%CPU"-Spalte von prstat  bezieht sich auf alle im System aktiven CPUs.  Bei einer T5120 sind das bspw. 64.  D.h. dass ein Strand 1/64, oder ca.  1.5% entspricht.  Wichtig ist nun, dass kein einzelner Thread der Anwendung dauerhaft 1.5% der CPU belegt.  Dies  waere ein Hinweis darauf, dass die Prozessleistung durch die Single-Thread Leistung begrenzt wird.


Diese Hinweise und ein paar Beispiele dafuer habe ich in einer kleinen Praesentation zusammengefasst.  Vielleicht hilft es ja dem einen oder anderen ;-)

Freitag Jan 22, 2010

Threadbar

Dieses Tool ist einen Blogeintrag ueber den Blogeintrag wert.  Wer kennt ihn nicht, den guten alten perfbar? Thrbar (eigentlich wohl Threadbar) ist ein Perfbar fuer die Threads eines Prozesses.  Damit wird es endlich moeglich, den Unterschied zwischen einem aktiven und einem existierenden Thread zu visualisieren.  Warum mussten wir eigentlich bis 2010 auf dieses Tool warten?  Dabei ist die Idee wirklich naheliegend.  Aber so ist es ja oft mit guten Ideen - wenn sie mal bekannt sind, schlagen wir uns alles ans Hirn und wundern uns, warum wir da nicht selbst schon lange darauf gekommen sind.  Deswegen meine doppelt ausgesprochene Hochachtung an Rickey Weisner fuer dieses Tool!

Nicht jedes Performance-Problem ist ein CMT SingleThread Problem!

Als einer der Performance-Experten in unserem Team bin ich immer wieder beim Kunden, um den beruechtigten "Performance=ON" Knopf zu druecken.  Dass dieser entgegen aller Geruechte nicht existiert und auch weder in den alten noch den neuen Versionen von Solaris jemals eingebaut wurde, hat sich ja leider immer noch nicht ueberall herum gesprochen.  Was es jedoch gibt, sind relativ viele "Performance=OFF" Knoepfe ;-)  Sie verstecken sich oft an immer den gleichen Stellen, und mit ein wenig Erfahrung kann man sie meistens auch finden, oft auch ohne das Zaubermittel DTrace.  Manchmal jedoch gelingt es, diese Knoepfe hinter einer Wand aus Taeuschungs-Nebel so gut zu verbergen, dass auch altbekannte Varianten wieder ganz neu entdeckt werden wollen.


 Genug der Vorrede - In diesem Fall bestand die Nebelwand aus dem Verdacht, dass -- mal wieder -- die Singlethread Leistung der CMT CPUs, hier auf T5240, nicht ausreicht, und der verwirrenden Beobachtung, dass der selbe Test in einem Container 3x schneller ablaeuft als in einer Global Zone.  Zu untersuchen war das Anlegen eines Datenfiles fuer die Informix Datenbank.  Das verwendete Filesystem war UFS und kam aus einem "SAN" - was ja auch stets mit hoher Leistung assoziiert wird.  Mit zur Verwirrung trug weiterhin bei, dass aus Betriebsgruenden fuer die beiden Tests unterschiedliche Systeme und unterschiedliche LUNs verwendet werden mussten, was natuerlich die Menge der moeglichen Ursachen erheblich vergroessert.


Um die Sache abzukuerzen: Es war nicht die Singlethread Leistung der CPU.  Es war auch nicht ein Performance-Artefakt in der Container-Implementierung.  Es war die Mount-Option "forcedirectio", die einmal gesetzt war, und einmal nicht.  Versteckt wurde dieser Umstand durch die Container-Konfiguration.  Diese Mount-Option ist fuer den Betrieb von Informix empfohlen, da diese Datenbank aehnlich wie Oracle oder DB2 ein eigenes Space-Management hat und die "Hilfe" des Dateisystems hier keine Hilfe waere.  Das Anlegen von Datenfiles ist aber offenbar eher eine Dateisystemoperation wie bspw. tar oder cp, und profitiert daher stark von den Puffermechanismen von UFS.  Hier gab es nun also in der Tat einen "Performance=OFF" Schalter.  Je nachdem, ob man ihn betaetigte oder nicht, war das Anlegen der Datenfiles schnell oder langsam.  Mit CMT und dessen Singlethread-Schwaeche hatte das ganze nichts zu tun. 


Warum blogge ich darueber?  Weil dieser Fall ein schoenes Beispiel dafuer ist, dass Performance-Probleme meistens verstanden werden koennen, wenn man sie holistisch angeht und am Anfang keine der Vermutungen glaubt, die im Vorfeld natuerlich entstehen.  Und das Verstehen des Problems ist der Schluessel zur eventuellen Loesung.

Donnerstag Dez 03, 2009

LDom Gaeste als SunCluster Data Service - Flying LDoms!

Flying Containers gibt es ja schon lange. Und seit es LDoms gibt, hatten wir intern von Flying LDoms geredet.  Jetzt endlich sind sie da!  In SunCluster 3.2 11-09 gibt es den Sun Cluster Data Service for LDom Guest Domains.


Das Transportieren einer LDom von einem Server auf einen zweiten war ja von Anfang an nicht wirklich schwierig.  Zur Not per USB-Stick Weitwurf konnte das Boot-Image transferiert werden, die Konfiguration kurz nachgezogen werden, und fertig war die wandernde LDom.  Fuer den Betrieb als BlackBox im Cluster, so wie das schon seit langem fuer die Solaris Container geht, waren jedoch einige technische Details auszutuefteln.  Besonders aergerlich - aus Sicht des Clusters - war es, dass eine Gast-LDom weiterlaufen kann, wenn die Control-Domain in die Brueche geht.  Damit war es praktisch unmoeglich sicherzustellen, wann denn nun ein Failover der LDom zu geschehen habe, und wann nicht, bzw. auszuschliessen, dass die LDom nicht versehentlich auf beiden Knoten gestartet wird, der Albtraum aller Cluster... 


Mit der in LDoms 1.2 eingefuehrten Moeglichkeit, Abhaengigkeiten zwischen verschiedenen LDoms zu konfigurieren (master/slave Beziehungen) und einer konfigurierbaren Aktion im Fehlerfall (failure-policy) ist diese Schwierigkeit nun umschiffbar.


Ich freue mich schon auf viele "Flying LDom" Projekte!

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.

Donnerstag Okt 15, 2009

Patch fuer LDom Manager mit Solaris 10 update 8

Leider haben sich ein paar Fehler in den LDom Manager 1.2 eingeschlichen, die in Zusammenhang mit Solaris 10 update 8 zutage treten.  Einige davon sind bereits behoben, hierfuer gibt es Patch 142840-01.  Noch offen sind einige Fehler in Zusammenhang mit dem Power-Management.  Wer dies aktiviert hat, sollte die Controll Domain derzeit nicht auf Solaris 10 update 8 upgraden - ein Fix ist jedoch bereits in Arbeit.

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 Sep 03, 2009

Ebenfalls am Horizont: Mehr Threads

...und natuerlich auch mehr Leistung.  Auf der HotChips Conference in Stanford wurden Details der naechsten CMT-CPU vorgestellt.  Die (wohl schon bekannten) Rahmendaten: 16 Kerne, 128 Threads wurden dabei mit zwei Praesentationen mit ettlichen technischen Details unterfuettert.  Diese Praesentationen sind inzwischen offentlich verfuegbar - Links dazu, sowie eine kleine Uebersicht ueber die Pressekommentare gibt es hier:

Auf den starken Durchsatz dieser CPU darf man sich freuen - wenn man nicht gerade auf "Power" oder andere heisse CPUs gesetzt hat... ;-)

Freitag Aug 28, 2009

Rekorde am Horizont

Ob nun gekauft oder nicht, die Zusammenarbeit von Sun und Oracle funktioniert schon lange praechtig.  Dabei kommt immer wieder Hoechstleistung heraus.  Manchmal auch mit ungewoehnlichem wie TPC-C!  Neugierig:  Schon mal spicken ;-)

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 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