Montag Dez 05, 2011

Hard Partitioning!

Gute Nachrichten fuer alle Nutzer von Oracle VM Server fuer SPARC (aka LDoms) mit Oracle Software:  Seit 2. Dezember gelten LDoms als "Hard Partitioning".  Damit ist es moeglich, nur die tatsaechlich benoetigten Kerne eines Servers fuer Oracle-Software zu lizenzieren.  Auskunft ueber die Details bekommt man bei License Management Services.

Donnerstag Sep 08, 2011

Core Factor fuer T4 veroeffentlicht

Oracle hat eine neue Version der Processor Core Factor Table veroeffentlicht, in der fuer die (noch nicht angekuendigte) T4 CPU ein Core Faktor von 0.5 angegeben wird.  Damit bleiben die Lizenzkosten pro Sockel im Vergleich zum Vorgaenger T3 gleich.  T4 spielt offenbar in der gleichen Liga wie SPARC64 VII+ und alle aktuellen x86 CPUs.  Fuer Performance-Angaben muessen wir bis zur offiziellen Ankuendigung warten.  Aber dieser Core Faktor (der allerdings keineswegs eine Bewertung der CPU-Performance ist!) scheint zu bestaetigen, was die wenigen anderen verfuegbaren Hinweise bereits andeuten:  T4 wird liefern, was Oracle versprochen hat.

Dienstag Jul 05, 2011

Ein paar Gedanken zur aktuellen SPARC Roadmap

Inzwischen duerfte die aktuelle Roadmap fuer SPARC Server ja allgemein bekannt sein.  Roadmaps sind, wie das Papier, geduldige Dinge, und wir alle wissen wie sich die Zeiten im Lauf der Dinge verschieben... Daher stellt sich die Frage, was diese Roadmap wert ist.

Als Oracle Sun gekauft hat, gab es einige grosse Versprechen bzgl. verstaerktem Engagement fuer SPARC und Solaris. Die ersten dieser Versprechen wurden ja auch bereits eingeloest:

  • Die SPARC T3 CPU hat den Durchsatz pro Sockel verdoppelt.
  • Mit Solaris 11 Express gibt es eine Vorschau auf das naechste Solaris - einschl. Support!
  • Die M-Serie erhielt erneut einen Performance-Schub von bis zu 20%

Alle diese Dinge sind in der aktuellen Roadmap mit huebschen roten Haeckchen markiert. Und all das war bereits mehr oder weniger fertig, als Sun gekauft wurde. Auch wenn T3 durch das verstaerkte Investment von Oracle deutlich schneller auf den Markt kam.  Die wirkliche Bewaehrungsprobe wird jedoch das naechste Versprechen der Roadmap sein. Dort heisst es: "3x Single Strand" fuer eine T-Serie CPU.  Inzwischen wissen wir ja alle, dass diese CPU vermutlich "T4" heissen wird.  Rick Hetherington erzaehlte uns vor einer Weile, dass der Chip 8 Kerne haben wird und single thread Lasten bis zu 5 mal schneller ausfuehren wird als T3.  Das waehre dann noch schneller als die versprochenen 3x der Roadmap.  Die einzige Frage die bleibt ist: Wird Oracle liefern?

Natuerlich kann das keiner sagen, bevor die CPU und Systeme nicht angekuendigt sind. Die Chancen dafuer stehen jedoch gut.  Warum sonst sollte Oracle seine Kunden einladen, an einem T4 Beta Programm teilzunehmen?

Zurueck zur ersten Frage:  Was ist diese Roadmap wert?  Nun, betrachtet man das bisher versprochene und gelieferte als Grundlage, dann steht der Roadmap-Pfeil auf einem festen Fundament. Oracle hat geliefert, und das sogar puenktlich. Das ist mehr, als manch anderer von sich behaupten kann.

Ein kleiner Disclaimer, damit alle zufrieden sind und bleiben: Dies ist meine persoenliche Meinung und keinesfalls die von Oracle.

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.

Dienstag Mai 24, 2011

ILOM fuer ALOM-Juenger

ALOM ist tot, es lebe ILOM.  Die aktuellen  T3 Systeme verwenden ILOM 3.0.  In dieser Version ist die aeltere ALOM Kommando-Syntax nicht mehr verfuegbar.  Das ist fuer all diejenigen, die sich an ALOM gewoehnt haben, eine Umstellung.  Eine Tabelle ALOM -> ILOM ist fuer den Uebergang natuerlich hilfreich.  Nur, wo findet man die?  In der Dokumentation!

Aber wer findet da schon immer gleich, was gesucht wird?  Daher hier einfach mal ein Verweis in eben diese Dokumentation, auf dass sie besser gefunden werde:

ALOM ILOM Kommando Vergleich

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.

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
« Februar 2016
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
      
       
Heute