Dienstag Okt 01, 2013

CPU-DR fuer Zonen

In meinem letzten Beitrag habe ich beschrieben, wie man die Memory-Konfiguration einer Zone im laufenden Betrieb veraendert.  Die naheliegende Frage ist natuerlich, ob das auch mit einer eventuellen CPU-Begrenzung funktioniert.  Die Antwort lautet natuerlich "Ja".

Manch einer wird sich fragen, warum das ueberhaupt notwendig ist, kann man Zonen doch bspw. mit dem Fair-Share Scheduler ganz hervoragend mit CPU versorgen und gleichzeitig unter Kontrolle halten.  Es gibt jedoch auch Gruende, Zonen mit exklusiven CPUs auszustatten - Lizenzierung oder  SLAs, die eine eher physische Partitionierung der Resourcen vorschreiben.  In solchen Faellen werden Zonen mit einer festen Anzahl von CPUs (oder vielmehr Strands) konfiguiert.  Und dann kann es natuerlich auch wuenschenswert sein, diese Konfiguration zu aendern, ohne die Zone dabei zu booten.  Wie das geht, soll hier beschrieben werden.

Grundsaetzlich gibt es zwei Moeglichkeiten, eine Zone mit einer festen Anzahl von CPUs zu betreiben.  Die klassische ist ein Resource Pool mit einem dazu gehoerenden Prozessorset, an den die Zone gebunden wird.  Eleganter geht das mit der Einstellung "dedicated-cpu" direkt in der Zonenkonfiguration.  In diesem zweiten Fall wird beim Start der Zone ein temporaerer Pool angelegt.  D.h. in beiden Faellen ist die Umsetzung die gleiche.  Und damit ist auch klar, wie die Loesung in beiden Faellen aussieht:  Die Konfiguration des Pools wird geaendert.  In der klassischen Variante ist diese Aenderung persistent.  In der zweiten Variante muss zusaetzlich die Konfiguration der Zone angepasst werden, damit die neue Anzahl von CPUs auch nach einem Zonen-Neustart erhalten bleibt.

Wird eine Zone mit "dedicated-cpu" konfiguriert, wird beim Start der Zone ein temporaerer Pool angelegt.  Dieser, und auch das dazu gehoerende Prozessorset, heisst idR. SUNWtmp_<zonenname>.  Das weitere Vorgehen ist damit fuer beide Faelle gleich:

Nehmen wir an, unsere Zone heisst orazone und hat derzeit 1 CPU.  Sie soll auf 2 CPUs erweitert werden.  Die aktuelle Pool-Konfiguration sieht wie folgt aus:

root@benjaminchen:~# pooladm                

system default
	string	system.comment 
	int	system.version 1
	boolean	system.bind-default true
	string	system.poold.objectives wt-load

	pool pool_default
		int	pool.sys_id 0
		boolean	pool.active true
		boolean	pool.default true
		int	pool.importance 1
		string	pool.comment 
		pset	pset_default

	pool SUNWtmp_orazone
		int	pool.sys_id 5
		boolean	pool.active true
		boolean	pool.default false
		int	pool.importance 1
		string	pool.comment 
		boolean	pool.temporary true
		pset	SUNWtmp_orazone

	pset pset_default
		int	pset.sys_id -1
		boolean	pset.default true
		uint	pset.min 1
		uint	pset.max 65536
		string	pset.units population
		uint	pset.load 687
		uint	pset.size 3
		string	pset.comment 

		cpu
			int	cpu.sys_id 1
			string	cpu.comment 
			string	cpu.status on-line

		cpu
			int	cpu.sys_id 3
			string	cpu.comment 
			string	cpu.status on-line

		cpu
			int	cpu.sys_id 2
			string	cpu.comment 
			string	cpu.status on-line

	pset SUNWtmp_orazone
		int	pset.sys_id 2
		boolean	pset.default false
		uint	pset.min 1
		uint	pset.max 1
		string	pset.units population
		uint	pset.load 478
		uint	pset.size 1
		string	pset.comment 
		boolean	pset.temporary true

		cpu
			int	cpu.sys_id 0
			string	cpu.comment 
			string	cpu.status on-line
Wir sehen in der Definition von pset SUNWtmp_orazone, dass CPU #0 diesem zugeordnet ist. Um den Pool um CPU #1 zu erweitern, sind folgende Kommandos notwendig:
root@benjaminchen:~# poolcfg -dc 'modify pset SUNWtmp_orapset \
                     (uint pset.max=2)' 
root@benjaminchen:~# poolcfg -dc 'transfer to pset \
                     orapset (cpu 1)'

Um umgekehrt diese CPU wieder aus dem Pool zu entfernen, diese Kommandos:

root@benjaminchen:~# poolcfg -dc 'transfer to pset pset_default \
                     (cpu 1)'
root@benjaminchen:~# poolcfg -dc 'modify pset SUNWtmp_orapset \
                     (uint pset.max=1)' 

Nun bleibt nur noch, die korrekte Anzahl von CPUs fuer den naechsten Zonen-Neustart in die Zonenkonfiguration einzutragen.

Fuer den Fall eines eigenen Pools fuer die Zone (klassische Variante) ist in diesem Verfahren lediglich der entsprechende Poolname zu verwenden.

Literatur:

Montag Aug 19, 2013

Memory-DR fuer Zonen

Zonen bieten unter Anderem die Moeglichkeit, den Hauptspeicher zu begrenzen.  Das geht idR. mit dem Zonen-Parameter "capped-memory", bei dem man die drei Werte "physical", "swap" und "locked" jeweils einzeln setzen kann.  "Physical" entspricht dabei der Resource-Control "zone.max-rss", also dem tatsaechlich belegten Hauptspeicher.  "Swap" entspricht "zone.max-swap" - dem belegten Swapspace und "locked" entspricht "zone.max-locked-memory", dem nicht pagebaren Speicher, typischerweise sind das shared memory Segmente.  Swap und Locked Memory sind dabei recht harte Grenzen, beim physischen Speicher ist es etwas "weicher".   Der physische Speicher wird durch rcapd ueberwacht, der ggf. versucht, Speicherseiten jenseits der erlaubten Menge auf das Swapdevice auszulagern.  Je nach Aktivitaet der Prozesse, die diesen Speicher verwenden, ist das mehr oder weniger erfolgreich, hat aber in jedem Fall zur Folge, dass diese Prozesse durch Paging stark beeintraechtigt werden.

Aendert man diese Werte mittels zonecfg, werden die neuen Werte erst nach einem Neustart der Zone wirksam.  Wirklich dynamisch, wie man das z.B. bei LDoms gewohnt ist, ist das nicht.  Es geht aber auch anders, wie ich an einem kleinen Beispiel zeigen moechte:

Gegeben sei eine kleine Zone, deren Speicherkonfiguration wie folgt aussieht:

root@benjaminchen:~# zonecfg -z orazone info capped-memory
capped-memory:
    physical: 512M
    [swap: 256M]
    [locked: 512M]

Um diese Werte im Betrieb zu aendern, muss an zwei verschiedenen Stellen eingegriffen werden.  Fuer den physischen Speicher beim rcapd, der diesen verwaltet.  Fuer swap und locked memory mit dem normalen Resource Control Kommando prctl.  Um also bspw. alle drei Grenzen zu verdoppeln, brauche ich folgende Kommandos:

root@benjaminchen:~# prctl -n zone.max-swap -v 512m -r -i zone orazone
root@benjaminchen:~# prctl -n zone.max-locked-memory -v 1g -r -i zone orazone
root@benjaminchen:~# rcapadm -z orazone -m 1g

Diese neuen Werte werden sofort, bzw. nach dem naechsten Rekonfigurations-Intervall des rcapd wirksam. Dieses kann man ebenfalls mit rcapadm veraendern. Wichtig ist dabei, dass diese Aenderungen nicht persistent sind. D.h. fuer den naechsten Zonen-Neustart gelten die Werte, die mittels zonecfg gesetzt wurden. Will man beides - persistente Aenderung und sofortige Wirkung, muss man an beiden Stellen eingreifen.

Literatur:

  • Solaris Admin Guide:
    http://docs.oracle.com/cd/E19683-01/817-1592/rm.rcapd-1/index.html

Mittwoch Jun 12, 2013

Den root pool erweitern

Zwischendurch mal ein wenig Laptop-Erfahrung...  Ich habe endlich entschieden, dieses zweite OS von der Platte zu verbannen (Ich hatte es so selten benutzt, dass ich regelmaessig das Passwort zuruecksetzen musste...).  Der Ertrag waren 50g wertvoller Laptop-Plattenplatz - gluecklicher Weise an der richtigen Stelle auf der Platte.  In der Theorie muesste ich also nur die Solaris-Partition erweitern, ZFS Bescheid sagen und den Platz geniessen.  Aber natuerlich gibt es da so verschiedene kleine Fallen.

Um Verwirrung vorzubeugen - es geht hier um x86.  Bei einem normalen SPARC Server hat man die Probleme, fuer die ich hier Loesungen beschreibe gar nicht.

Erste Lektion: Man sollte nicht versuchen, mit fdisk die Partition zu veraendern solange Solaris darauf noch laeuft.  Das funktioniert zwar, aber es gibt freundlichere Varianten des Shutdowns.  (Was hier passiert ist, dass fdisk nicht nur die Partition neu anlegt, sondern auch ein dazu passendes Label schreibt.  Das bedeutet allerdings, dass ZFS den Slice fuer den rpool nicht mehr findet.  Und das wiederum fuehrt zu einem sehr introvertierten Solaris...)  Richtig macht man das, indem man von irgendetwas anderem bootet (PXE, USB, DVD, etc) und dann die Partition veraendert.  Danach nicht vergessen, den Slice fuer den ZFS pool wieder anzulegen.  Wichtig dabei ist, dass dieser Slice wieder mit genau dem gleichen Zylinder anfaengt.  Die Laenge ist natuerlich eine andere.  (Ich zumindest musste das so machen, da  mein rpool in s0 lag.)

Danach ging es weiter wie im Handbuch:  Solaris booten und entweder  "zpool set autoexpand=on rpool" oder zpool online -e rpool c0t0d0s0" und schon waren da 50g mehr Platz.

Habe ich vergessen zu erwaehnen, dass ich doch tatsaechlich vor all dem ein volles Backup gemacht habe?  Ich werde doch langsam alt...

Dienstag Apr 17, 2012

Solaris Zones: Virtualisierung beschleunigt Benchmarks!

Wenn ich mich mit Kunden ueber Virtualisierung unterhalte ist eine der ersten Fragen oft die nach dem Overhead.  Nun wissen wir ja alle, dass Virtualisierung mit Hypervisoren nicht ohne Overhead zu machen ist.  Was wir ebenfalls alle wissen sollten ist, dass es stark vom Lastprofil und dem verwendeten Hypervisor abhaengt, wie gross dieser Overhead jeweils ausfaellt.  Zwar gab es schon einige Versuche, dies in standardisierten Benchmarks zu quantifizieren.  Dennoch bleibt die Antwort auf diese Frage noch immer in den Nebeln von Marketing und Benchmark-Unschaerfe verborgen.  Erstaunen erlebe ich jedoch regelmaessig, wenn ich zu Solaris Zonen (bei Solaris 10 hiessen sie noch Container) als Alternative zur Virtualisierung mit Hypervisoren komme. Solaris Zonen sind, grob vereinfacht, nichts weiter sind als eine Menge von Unix Prozessen, abgegrenzt durch einen Regelsatz der vom Solaris Kernel durchgesetzt wird.  Daher ist es einleuchtend, dass hier nicht besonders viel Overhead anfallen kann.  Dennoch wird die Behauptung von "Zero Overhead" oft angezweifelt, gerade auch weil vielen heute Virtualisierung per Hypervisor sehr nahe ist.  Und so sehr ich die Erklaerung mit technischen Details ueberzeugend finde, so sehr verstehe ich auch, dass sehen viel besser ist als glauben.   Daher:

Die Benchmark-Teams bei Oracle sind so ueberzeugt von den Vorteilen der Solaris Zonen, dass sie diese fuer die veroeffentlichten Benchmarks verwenden.  Das Solaris Resource Management funktioniert natuerlich auch ohne Zonen, aber Zonen machen es so viel einfacher, insb. in Verbindung mit den teilweise recht komplexen Benchmark-Konfigurationen.  Es gibt zahlreiche Benchmark-Veroeffentlichungen bis zurueck in die Tage der T5440, in denen Solaris Container zur Anwendung kommen.  Einige aktuelle Beispiele, alles Weltrekorde, sind:

Die genaue verwendung der Zonen ist in der jeweiligen Benchmark-Beschreibung dokumentiert.

Darueber hinaus hat das Benchmark-Team in einem Blogeintrag beschrieben, wie sie das Solaris Resource Management und Zonen verwenden, um die Anwendungsleistung zu erhoehen.  Das verleitet fast dazu, von "negativem Overhead" zu sprechen, waere der Begriff nicht so irrefuehrend.

Mittwoch Apr 04, 2012

Folien von den Solaris Tech Days

Mehr ein "oeffentlicher Bookmark" als ein eigener Beitrag:  Die Folien von den deutschen "Solaris Tech Days" sind hier zu finden.  Die Agenda und eine Sammlung von Links zum Thema Solaris 11 als Antwort auf diverse Nachfragen gibt es im Solarium.

Dienstag Mrz 13, 2012

Ein lokaler AI Server - mit Solaris 11 mal eben aufgesetzt

Solaris 11 macht vieles neu, unter anderem auch den Installserver.  Wer, wie ich, seit (gefuehlten) 200 Jahren Jumpstart kennt, muss hier umlernen.  Dabei ist das ganze gar nicht so kompliziert.  Nur eben neu.

Mein Ziel war es, einen AI-Server zu bauen, den ich fuer Demo-Zwecke auch mal im Zug benutzen kann.  Damit sind auch die Hardware-Voraussetzungen klar: Tragbar sollte es schon sein.  Aber schoen der Reihe nach.

Als Erstes braucht man natuerlich ein OS-Image.  Das heisst in der neuen Solaris 11 Welt jetzt Repository.  Das Original dafuer kann man sich von der Solaris 11 Seite bei Oracle herunterladen.  Man braucht dazu das zweiteilige "Oracle Solaris 11 11/11 Repository Image", das man sich dann natuerlich mit cat zusammensetzt.  Die MD5 Pruefsummen gibt es uebrigens ebenfalls auf dieser Seite, nur etwas weiter oben.

Damit ist nun das Repository ganz schnell gemacht:

# zfs create -o mountpoint=/export/repo rpool/ai/repo
# zfs create rpool/ai/repo/sol11
# mount -o ro -F hsfs /tmp/sol-11-1111-repo-full.iso /mnt
# rsync -aP /mnt/repo /export/repo/sol11
# umount /mnt
# pkgrepo rebuild -s /export/repo/sol11/repo
# zfs snapshot rpool/ai/repo/sol11@fcs
# pkgrepo info -s  /export/repo/sol11/repo
PUBLISHER PACKAGES STATUS           UPDATED
solaris   4292     online           2012-03-12T20:47:15.378639Z
Und schon ist das Repository fertig. Zur Sicherheit gleich einen Snapshot anlegen, man weiss nie, wozu der noch gut ist. Um das Repository zu verwenden, koennte man es nun als Publisher auf Dateibasis eintragen:
# pkg set-publisher -g file:///export/repo/sol11/repo solaris
Falls ich das Repository spaeter auch per (virtuellem) Netzwerk verwenden moechte, jetzt noch schnell den Repository-Server aktiviert:
# svccfg -s application/pkg/server \
setprop pkg/inst_root=/export/repo/sol11/repo
# svccfg -s application/pkg/server setprop pkg/readonly=true
# svcadm refresh application/pkg/server
# svcadm enable application/pkg/server

Und schon kann man mit dem Browser auf http://localhost/ einen huebschen Repository-Server bewundern. Schritt 1 ist geschafft.  Das alles ist uebrigens in einem README, das im Repository-Image enthalten ist, gut beschrieben. 

Inzwischen gibt es natuerlich Updates, zu finden in MOS im Oracle Solaris 11 Support Repository Updates (SRU) Index.  Je nach Bedarf kann man diese Updates einfach in das bestehende Repository einpflegen oder sie als eigenstaendige Repositories betreiben.  Diese Updates sind jeweils selbststaendig, d.h. SRU4 enthaelt auch die Updates aus SRU2 und SRU3.  Mit einem kleinen ZFS-Trick kann man auch beides bekommen: Ein Gesamt-Repository und gleichzeitig fuer jedes Update ein eigenes:

# mount -o ro -F hsfs /tmp/sol-11-1111-sru4-05-incr-repo.iso /mnt
# pkgrecv -s /mnt/repo -d /export/repo/sol11/repo '*'
# umount /mnt
# pkgrepo rebuild -s /export/repo/sol11/repo
# zfs snapshot rpool/ai/repo/sol11@sru4
# zfs set snapdir=visible rpool/ai/repo/sol11
# svcadm restart svc:/application/pkg/server:default
Damit ist das normale Repository jetzt auf dem Stand von SRU4. Gleichzeitig gibt es dank der ZFS Snapshots in /export/repo/sol11/.zfs/snapshot/fcs ein gueltiges Repository ohne den Update. Wer moechte, kann dazu natuerlich auch einen zweiten Repository-Service auf einem zusaetzlichen Port betreiben.

Jetzt aber zum Installserver.  Mit nur wenig Lektuere der entsprechenden Dokumentation wird klar, dass man hierzu einen DHCP-Server betreiben muss.  Da ich vermeiden wollte, dass dieser meinem bereits bestehenden DHCP-Server (Teil meiner SunRay Installation) in die Quere kommt, und weil das fuer einen solchen Service sowieso eine gute Idee ist, soll er in einer eigenen Zone installiert werden.  Also erst mal schnell eine Zone erzeugen:

# zfs create -o mountpoint=/export/install rpool/ai/install
# zfs create -o mountpoint=/zones rpool/zones
# zonecfg -z ai-server
zonecfg:ai-server> create
create: Using system default template 'SYSdefault'
zonecfg:ai-server> set zonepath=/zones/ai-server
zonecfg:ai-server> add dataset
zonecfg:ai-server:dataset> set name=rpool/ai/install
zonecfg:ai-server:dataset> set alias=install
zonecfg:ai-server:dataset> end
zonecfg:ai-server> commit
zonecfg:ai-server> exit
# zoneadm -z ai-server install
# zoneadm -z ai-server boot ; zlogin -C ai-server
Beim ersten Boot dann einen Hostnamen und IP-Adresse vergeben, fertig ist die Zone.  Als Publisher fuer Solaris Pakete wie z.B. die AI Pakete verwendet sie dabei zwingend den Publisher der Global Zone. Das Filesystem /export/install ist natuerlich fuer den Installserver gedacht. Diesen gilt es jetzt aufzusetzen:
#zlogin ai-server
root@ai-server:~# pkg install install/installadm
root@ai-server:~# installadm create-service -n x86-fcs -a i386 \
-s pkg://solaris/install-image/solaris-auto-install@5.11,5.11-0.175.0.0.0.2.1482 \
-d /export/install/fcs -i 192.168.2.20 -c 3

Damit ist der Installserver selbst eigentlich schon fertig. Was ist hier passiert? Nun, natuerlich muss man erst einmal die notwendige Software installieren. Mit IPS ist das einfach, ggf. wird auch gleich der benoetigte DHCP-Server mit installiert. Achtung, es gibt zwei verschiedene DHCP-Server in Solaris 11, den aus Solaris 10 und frueher bekannten, und den von ISC. Letzterer wird fuer AI gebraucht. Die SMF-Namen der beiden unterscheiden sich nur wenig, der "alte" DHCP-Server heisst in SMF "svc:/network/dhcp-server:default". Der ISC-Server bringt verschiedene SMF-Services mit. Davon brauchen wir mindestens den Service "svc:/network/dhcp/server:ipv4". Mit dem Kommando "installadm create-service" wird nun ein Installations-Service aufgebaut. Er hat den Namen "x86-fcs", bedient die Architektur "i386" und bezieht sein Boot-Image aus dem Repository des System-Publishers in der Version 5.11,5.11-0.175.0.0.0.2.1482, das entspricht Solaris 11 11/11.  (Die Option "-a i386" in diesem Beispiel ist optional, da der Installserver auf einer x86-Maschine laeuft.) Die Boot-Umgebung fuer die Clients wird in /export/install/fcs angelegt, und der DHCP-Server wird fuer 3 IP-Adressen ab 192.168.2.20 konfiguriert.  Diese Konfiguration findet man in leicht verstaendlicher Form in /etc/inet/dhcpd4.conf.  Auf die gleiche Weise koennte man nun noch einen Service fuer SPARC Systeme aufsetzen.

Jetzt koennte man bereits den ersten Client registrieren und installieren.  Er bekaeme den Standard "solaris-large-server" mit dem Publisher "http://pkg.oracle.com/solaris/release" installiert und wuerde nach dem ersten Booten seine Konfiguration interaktiv abfragen.  Damit wird klar:  Der AI-Server ist eigentlich nur ein Boot-Server, die eigentliche Quelle fuer Pakete kann eine andere sein.  Da ich das so jedoch nicht haben moechte, konfiguriere ich mir meinen Client erst noch ein wenig zurecht.

Die Konfiguration von Install-Clients wird ueber sogenannte Manifeste und Profile gesteuert.  Dabei enthaelt das Manifest Informationen ueber zu installierende Pakete und Dateisystem-Konfiguration (und entspricht damit ein wenig der "rules.ok" Datei von Jumpstart).  Die Profile enthalten darueber hinausgehende Konfigurations-Angaben wie bspw. Root-PW, Primaerer User, IP-Adresse, Tastatur-Layout etc. und entsprechend damit in etwa der alten sysid.cfg. 

Am einfachsten kommt man an ein Template fuer ein Manifest, indem man sich das Default-Manifest vom Installserver geben laesst, dieses modifiziert und das Ergebnis dem Installserver bekannt gibt:

root@ai-server:~# mkdir -p /export/install/configs/manifests
root@ai-server:~# cd /export/install/configs/manifests
root@ai-server:~# installadm export -n x86-fcs -m orig_default \
-o orig_default.xml
root@ai-server:~# cp orig_default.xml s11-fcs.small.local.xml
root@ai-server:~# vi s11-fcs.small.local.xml
root@ai-server:~# more s11-fcs.small.local.xml
<!DOCTYPE auto_install SYSTEM "file:///usr/share/install/ai.dtd.1">
<auto_install>
  <ai_instance name="S11 Small fcs local">
    <target>
      <logical>
        <zpool name="rpool" is_root="true">
          <filesystem name="export" mountpoint="/export"/>
          <filesystem name="export/home"/>
          <be name="solaris"/>
        </zpool>
      </logical>
    </target>
    <software type="IPS">
      <destination>
        <image>
          <!-- Specify locales to install -->
          <facet set="false">facet.locale.*</facet>
          <facet set="true">facet.locale.de</facet>
          <facet set="true">facet.locale.de_DE</facet>
          <facet set="true">facet.locale.en</facet>
          <facet set="true">facet.locale.en_US</facet>
        </image>
      </destination>
      <source>
        <publisher name="solaris">
          <origin name="http://192.168.2.12/"/>
        </publisher>
      </source>
      <!--
        By default the latest build available, in the specified IPS
        repository, is installed.  If another build is required, the
        build number has to be appended to the 'entire' package in the
        following form:

            <name>pkg:/entire@0.5.11-0.build#</name>
      -->
      <software_data action="install">
        <name>pkg:/entire@0.5.11,5.11-0.175.0.0.0.2.0</name>
        <name>pkg:/group/system/solaris-small-server</name>
      </software_data>
    </software>
  </ai_instance>
</auto_install>

root@ai-server:~# installadm create-manifest -n x86-fcs -d \
-f ./s11-fcs.small.local.xml 
root@ai-server:~# installadm list -m -n x86-fcs
Manifest             Status    Criteria 
--------             ------    -------- 
S11 Small fcs local  Default   None
orig_default         Inactive  None

Die wesentlichen Punkte in diesem Manifest sind:

  • Es wird "solaris-small-server" installiert
  • Es gibt ein paar Locales weniger (die ich nicht haben wollte)
  • Als Publisher wird mein in der GZ laufender Package Service auf Adresse 192.168.2.12 verwendet
  • Von dort wird die FCS-Version von Solaris 11 installiert:  pkg:/entire@0.5.11,5.11-0.175.0.0.0.2.0

Auf ganz aehnliche Weise wird jetzt aus einem interaktiv erzeugten Default-Profil eine kleine Menge von Profil-Schnipseln erzeugt, was die Konfiguration von mehreren Clients spaeter leichter macht:

root@ai-server:~# mkdir -p /export/install/configs/profiles
root@ai-server:~# cd /export/install/configs/profiles
root@ai-server:~# sysconfig create-profile -o default.xml
root@ai-server:~# cp default.xml general.xml; cp default.xml mars.xml
root@ai-server:~# cp default.xml user.xml
root@ai-server:~# vi general.xml mars.xml user.xml
root@ai-server:~# more general.xml mars.xml user.xml
::::::::::::::
general.xml
::::::::::::::
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="profile" name="sysconfig">
  <service version="1" type="service" name="system/timezone">
    <instance enabled="true" name="default">
      <property_group type="application" name="timezone">
        <propval type="astring" name="localtime" value="Europe/Berlin"/>
      </property_group>
    </instance>
  </service>
  <service version="1" type="service" name="system/environment">
    <instance enabled="true" name="init">
      <property_group type="application" name="environment">
        <propval type="astring" name="LANG" value="C"/>
      </property_group>
    </instance>
  </service>
  <service version="1" type="service" name="system/keymap">
    <instance enabled="true" name="default">
      <property_group type="system" name="keymap">
        <propval type="astring" name="layout" value="US-English"/>
      </property_group>
    </instance>
  </service>
  <service version="1" type="service" name="system/console-login">
    <instance enabled="true" name="default">
      <property_group type="application" name="ttymon">
        <propval type="astring" name="terminal_type" value="vt100"/>
      </property_group>
    </instance>
  </service>
  <service version="1" type="service" name="network/physical">
    <instance enabled="true" name="default">
      <property_group type="application" name="netcfg">
        <propval type="astring" name="active_ncp" value="DefaultFixed"/>
      </property_group>
    </instance>
  </service>
  <service version="1" type="service" name="system/name-service/switch">
    <property_group type="application" name="config">
      <propval type="astring" name="default" value="files"/>
      <propval type="astring" name="host" value="files dns"/>
      <propval type="astring" name="printer" value="user files"/>
    </property_group>
    <instance enabled="true" name="default"/>
  </service>
  <service version="1" type="service" name="system/name-service/cache">
    <instance enabled="true" name="default"/>
  </service>
  <service version="1" type="service" name="network/dns/client">
    <property_group type="application" name="config">
      <property type="net_address" name="nameserver">
        <net_address_list>
          <value_node value="192.168.2.1"/>
        </net_address_list>
      </property>
    </property_group>
    <instance enabled="true" name="default"/>
  </service>
</service_bundle>
::::::::::::::
mars.xml
::::::::::::::
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="profile" name="sysconfig">
  <service version="1" type="service" name="network/install">
    <instance enabled="true" name="default">
      <property_group type="application" name="install_ipv4_interface">
        <propval type="astring" name="address_type" value="static"/>
        <propval type="net_address_v4" name="static_address" 
                 value="192.168.2.100/24"/>
        <propval type="astring" name="name" value="net0/v4"/>
        <propval type="net_address_v4" name="default_route" 
                 value="192.168.2.1"/>
      </property_group>
      <property_group type="application" name="install_ipv6_interface">
        <propval type="astring" name="stateful" value="yes"/>
        <propval type="astring" name="stateless" value="yes"/>
        <propval type="astring" name="address_type" value="addrconf"/>
        <propval type="astring" name="name" value="net0/v6"/>
      </property_group>
    </instance>
  </service>
  <service version="1" type="service" name="system/identity">
    <instance enabled="true" name="node">
      <property_group type="application" name="config">
        <propval type="astring" name="nodename" value="mars"/>
      </property_group>
    </instance>
  </service>
</service_bundle>
::::::::::::::
user.xml
::::::::::::::
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="profile" name="sysconfig">
  <service version="1" type="service" name="system/config-user">
    <instance enabled="true" name="default">
      <property_group type="application" name="root_account">
        <propval type="astring" name="login" value="root"/>
        <propval type="astring" name="password" 
                 value="noIWillNotTellYouMyPasswordNotEvenEncrypted"/>
        <propval type="astring" name="type" value="role"/>
      </property_group>
      <property_group type="application" name="user_account">
        <propval type="astring" name="login" value="stefan"/>
        <propval type="astring" name="password" 
                 value="noIWillNotTellYouMyPasswordNotEvenEncrypted"/>
        <propval type="astring" name="type" value="normal"/>
        <propval type="astring" name="description" value="Stefan Hinker"/>
        <propval type="count" name="uid" value="12345"/>
        <propval type="count" name="gid" value="10"/>
        <propval type="astring" name="shell" value="/usr/bin/bash"/>
        <propval type="astring" name="roles" value="root"/>
        <propval type="astring" name="profiles" value="System Administrator"/>
        <propval type="astring" name="sudoers" value="ALL=(ALL) ALL"/>
      </property_group>
    </instance>
  </service>
</service_bundle>
root@ai-server:~# installadm create-profile -n x86-fcs -f general.xml
root@ai-server:~# installadm create-profile -n x86-fcs -f user.xml
root@ai-server:~# installadm create-profile -n x86-fcs -f mars.xml \
-c ipv4=192.168.2.100
root@ai-server:~# installadm list -p

Service Name  Profile     
------------  -------     
x86-fcs       general.xml
              mars.xml
              user.xml

root@ai-server:~# installadm list -n x86-fcs -p

Profile      Criteria 
-------      -------- 
general.xml  None
mars.xml     ipv4 = 192.168.2.100
user.xml     None
In "general.xml" sind fuer viele Clients gueltige Einstellungen wie bspw. DNS-Server festgelegt. In "user.xml" die User, die einzutragen sind. Beide Profile gelten jedoch erst einmal ohne weitere Kriterien, also fuer alle Clients. Anders mars.xml, in dem die IP-Adresse fuer den Client mars festgelegt wird. Dieses Profil gilt nur fuer Install-Clients, die vom DHCP-Server die passende IP-Adresse bekommen haben. Damit das klappt, nun der letzte Schritt:
root@ai-server:~# installadm create-client -e 08:00:27:AA:3D:B1 -n x86-fcs
root@ai-server:~# vi /etc/inet/dhcpd4.conf
root@ai-server:~# tail -5 /etc/inet/dhcpd4.conf
host 080027AA3DB1 {
  hardware ethernet 08:00:27:AA:3D:B1;
  fixed-address 192.168.2.100;
  filename "01080027AA3DB1";
}

Damit ist der Client nun auch fertig vorbereitet. Damit der DHCP-Server keine Dummheiten macht, habe ich den Host-Eintrag in /etc/inet/dhcpd4.conf noch um die IP-Adresse fuer diesen Client ergaenzt. Damit bekommt dann nur dieser Install-Client diese Adresse, und nicht etwa ein unschuldiger anderer Rechner in diesem Netz...

Bemerkung: Das obige Beispiel zeigt die Konfiguration fuer ein x86-System.  Bei einem SPARC-System sieht die DHCP-Konfiguration etwas anders aus.  Hier wieder ein Beispiel mit kleinen manuellen Aenderungen, damit der DHCP-Server mir keine Sorgen macht ;-)

subnet 192.168.2.0 netmask 255.255.255.0 {
  range 192.168.2.200 192.168.2.201
  option broadcast-address 192.168.2.255;
  option routers 192.168.2.1;
  next-server 192.168.2.13;
}

class "SPARC" {
  match if not (substring(option vendor-class-identifier, 0, 9) = "PXEClient");
  filename "http://192.168.2.13:5555/cgi-bin/wanboot-cgi";
}

host sparcy {
   hardware ethernet 00:14:4f:fb:52:3c ;
   fixed-address 192.168.2.202 ;
}

 

Da die Installation aber natuerlich wirklich "Hands Off" ablaufen soll, muss nun noch das Boot-Menue fuer den Client leicht modifiziert werden.  Es steht in /etc/netboot.  Dort wird fuer jeden Client ein eigenes, ueber die MAC-Adresse identifiertes menu.lst angelegt.  Das Template dafuer steht in einem Verzeichnis, das den Namen des Install-Service traegt, in meinem Fall als in /etc/netboot/x86-fcs.  Wer das Boot-Menue also nicht fuer jeden Client einzeln aendern moechte, kann auch das Template selbst anfassen.
root@ai-server:~# cd /etc/netboot
root@ai-server:~# cp menu.lst.01080027AA3DB1 menu.lst.01080027AA3DB1.org
root@ai-server:~# vi menu.lst.01080027AA3DB1
root@ai-server:~# diff menu.lst.01080027AA3DB1 menu.lst.01080027AA3DB1.org
1,2c1,2
< default=1
< timeout=10
---
> default=0
> timeout=30
root@ai-server:~# more menu.lst.01080027AA3DB1
default=1
timeout=10
min_mem64=0

title Oracle Solaris 11 11/11 Text Installer and command line
	kernel$ /x86-fcs/platform/i86pc/kernel/$ISADIR/unix -B install_media=htt
p://$serverIP:5555//export/install/fcs,install_service=x86-fcs,install_svc_addre
ss=$serverIP:5555
	module$ /x86-fcs/platform/i86pc/$ISADIR/boot_archive

title Oracle Solaris 11 11/11 Automated Install
	kernel$ /x86-fcs/platform/i86pc/kernel/$ISADIR/unix -B install=true,inst
all_media=http://$serverIP:5555//export/install/fcs,install_service=x86-fcs,inst
all_svc_address=$serverIP:5555,livemode=text
	module$ /x86-fcs/platform/i86pc/$ISADIR/boot_archive

Einer Installation (mittels PXE-Boot) steht damit nichts mehr im Wege. Fuer meine Demo-Zwecke ist das natuerlich ein Client aus der Virtualbox. Bei einem SPARC-System wuerde man statt dessen das bekannte "boot net:dhcp - install" am OK Prompt eingeben und dann genuesslich der Installation zusehen.

Und auch, wenn dieser Blogeintrag ein wenig laenger ist - so schwer ist das nun auch wieder nicht ;-)

Donnerstag Mrz 01, 2012

Die Solaris Fingerprint Database - Neuauflage in Solaris 11

Einige erinnern sich sicher an die Solaris Fingerprint Database. Sie war eine hervoragende Moeglichkeit, um die Integritaet eines Solaris Binaries zu pruefen.  Leider wurde sie zusammen mit dem Rest von Sunsolve abgeschaltet und im Nachfolger "My Oracle Support" nicht wieder in Betrieb genommen.  Die gute Nachricht nun ist:   In Solaris 11 gibt es sie wieder, und besser als jemals zuvor!

Um die alte Datenbank zu benutzen, musste man den MD5 Fingerprint eines Binaries auf der Webseite der Datenbank eingeben und pruefen.  Es gab zwar ein Tool fuer die Massenpruefung, aber umstaendlich war das allemal.

In Solaris 11 ist alles das in den Paket-Manifesten von IPS integriert.  Diese Manifeste enthalten u.A. die SHA1 and ggf. ELF Hashes aller Binaries und Scripte, die in dem jeweiligen Paket enthalten sind.  Damit ist eine manuelle Pruefung bereits moeglich.  IPS geht aber weiter und stellt auch eine Methode zur Verfuegung, mit der die Integritaet der gesamten Installation geprueft werden kann.  Hier einige Beispiele, was damit moeglich ist:

  • Was ist der SHA1 Fingerprint eines Binaries?
    digest -a sha1 /usr/bin/vim
  • Aus welchem Paket stammt es?
    pkg search -f $(digest -a sha1 /usr/bin/vim)
    (Die Option "-f" braucht man, damit das Paket auch dann gefunden wird, wenn das Binary aus einer aelteren Version stammt.)
  • Gibt es noch mehr Details?
    pkg info -r $(pkg search -f -H -o pkg.fmri $(digest -a sha1 /usr/bin/vim))

Falls das alles funktioniert hat, ist das die Bestaetigung, dass das Binary, in diesem Fall "vim" gueltig ist und aus dem Paket "vim-core" stammt.

Die Daten fuer diese Pruefungen liefert der im System konfigurierte Publisher.  Welcher das ist, kann mit dem Kommando "pkg publisher" nachgesehen werden.  Eine typische Ausgabe waere dabei:

PUBLISHER TYPE STATUS URI
solaris origin online https://pkg.oracle.com/solaris/support/

Natuerlich kann man einen einzelnen SHA1 Digest auch direkt auf der Webseite des Publishers nachschlagen.  Das geht direkt im Browser auf der URL des Publishers.  Ganz aehnlich hatte das auch mit der alten Fingerprint Database funktioniert.  IPS kann allerdings noch sehr viel mehr als das:

Mit dem Kommando "pkg verify" kann man jedes einzelne installierte Paket gegen das entsprechende Repository pruefen lassen.  Je nachdem, um was fuer Dateien es sich handelt (Binary, Script, Konfigurationsdatei), werden dabei unterschiedliche Verfahren angewandt:

  • Binaries werden mittels eines ELF Hashes geprueft.
  • Scripts dagegen mit ihrem SHA1 Hash.
  • Konfigurationsdateien koennen, ihrem Wesen entsprechend, nicht geprueft werden.  Sie sind ja gerade dazu gedacht, von einem Administrator veraendert zu werden.
  • Darueber hinaus werden auch Besitzer, Gruppe und Rechte aller Dateien geprueft.

Die Ausgabe von "pkg verify" wird jede Abweichung von den Vorgaben aus dem Paket-Manifest melden.  Damit werden z.B. veraenderte Scripte oder Binaries oder geaenderte Ausfuehrungsrechte aufgedeckt.  Diese Pruefung kann man gegen die gesamte Installation, aber auch fuer ein einzelnes Paket durchfuehren lassen.  Je nach Ergebnis kann man dann entscheiden, wie weiter verfahren werden soll:

  • Nichts tun
  • Abweichungen von Hand reparieren, bspw. weil man weiss, wie sie zustande gekommen sind.
  • Die Abweichungen automatisch durch das Paketsystem reparieren lassen.

Diese letzte Moeglichkeit ist in diesem Zusammenhang das eigentliche "Power Feature" von IPS.  Da das Paketsystem genau weiss, wie die Dinge sein sollten kann man es auffordern, diesen definierten Zustand wieder herzustellen.  Im Vergleich zu den Moeglichkeiten von BART und der Fingerprint Database ein enormer Fortschritt.

Insgesamt kann IPS damit eine bestehende Installation mit den Originaldaten des verwendeten Repositories vergleichen.  Die Integritaet des Repositories selbst muss jedoch zusaetzlich gesichert werden.  Beim "Master Repository" wird dies durch Oracle sichergestellt.  Die Pakete selbst, genauso wie die Binaries, sind kryptographisch signiert.  Bei einem eigenen, lokalen Repository sollte man das ISO-Image mittels der bereitgestellten SHA1/MD5 Fingerprints pruefen, bevor man das Repository aufbaut.  Fuer den Schutz desselben ist man dann selbst zustaendig - BART hilft hier ggf. weiter.

Zum Schluss noch ein kleines Beispiel fuer all die erwaehnten Dinge:

 root@benjaminchen:/usr/bin# ls -l vim

-r-xr-xr-x   1 root     bin      2225532 Feb 23 14:31 vim
root@benjaminchen:/usr/bin# digest -a sha1 vim
f2495fa19fcc4b8a403e0bd4fef809d031296c68
root@benjaminchen:/usr/bin# pkg search -f f2495fa19fcc4b8a403e0bd4fef809d031296c68
INDEX                                    ACTION VALUE       PACKAGE
f2495fa19fcc4b8a403e0bd4fef809d031296c68 file   usr/bin/vim pkg:/editor/vim/vim-core@7.3.254-0.175.0.0.0.2.537
root@benjaminchen:/usr/bin# pkg verify -v vim-core
PACKAGE                                                                                                    STATUS
pkg://solaris/editor/vim/vim-core                                           OK
root@benjaminchen:/usr/bin# cp vim vim.org
root@benjaminchen:/usr/bin# cp ls vim
root@benjaminchen:/usr/bin# pkg verify -v vim-core
PACKAGE                                                                 STATUS 
pkg://solaris/editor/vim/vim-core                                        ERROR
    file: usr/bin/vim
        Elfhash: 20acbb006d5331660dc026483533c29137318673 should be f301bd9d798c4bdd8edebb001fbf4317380383a9
root@benjaminchen:/usr/bin# pkg fix --accept vim-core
Verifying: pkg://solaris/editor/vim/vim-core                    ERROR          
    file: usr/bin/vim
        Elfhash: 20acbb006d5331660dc026483533c29137318673 should be f301bd9d798c4bdd8edebb001fbf4317380383a9
Created ZFS snapshot: 2012-02-29-09:27:49
Repairing:
 pkg://solaris/editor/vim/vim-core                 
                                                                             
DOWNLOAD                                  PKGS       FILES    XFER (MB)
Completed                                  1/1         1/1      0.8/0.8
PHASE                                        ACTIONS
Update Phase                                     1/1 
PHASE                                          ITEMS
Image State Update Phase                         2/2 
 root@benjaminchen:/usr/bin# ls -l vim vim.org
-r-xr-xr-x   1 root     bin      2225532 Feb 29 10:28 vim
-r-xr-xr-x   1 root     root     2225532 Feb 29 10:27 vim.org
root@benjaminchen:/usr/bin# digest -a sha1 vim
f2495fa19fcc4b8a403e0bd4fef809d031296c68

Montag Feb 20, 2012

Solaris 11 fuer EAL4+ Zertifizierung eingereicht

Solaris 11 wurde offiziell zur Zertifizierung nach dem Canadian Common Criteria Scheme im Level EAL4+ eingereicht. Geprueft wird auf das Protection Profile "Operating System Protection Profile (OS PP)" sowie die Erweiterungen

  • Advanced Management (AM)
  • Extended Identification and Authentication (EIA)
  • Labeled Security (LS)
  • Virtualization (VIRT)

EAL4+ ist die hoechste typischerweise fuer kommerzielle Software erreichbare Ebene und gleichzeitig die hoechste Ebene, die von insg. 26 Laendern, darunter Deutschland, gegenseitig anerkannt wird. Wann die Zertifizierung abgeschlossen sein wird, liegt in den Haenden der Zertifizierungsstelle.

Den aktuellen Stand dieser Zertifizierung (und auch weiterer zertifizierter Oracle Software) findet man auf der Seite Oracle Security Evaluations.

Freitag Nov 11, 2011

Einstieg in Solaris 11

Fuer alle die, die jetzt mit Solaris 11 anfangen wollen, gibt es eine gute Zusammenfassung der Neuerungen und Aenderungen gegenueber Solaris 10.  Zu finden als Support Dokument 1313405.1.

Auch in OTN gibt es ein ganzes Portal zu Solaris 11.  Besonders hervorheben moechte ich hier die umfangreiche "How-To" Sammlung. Und nicht zuletzt gibt es natuerlich die "ganz normalen" Admin Guides.

Freitag Okt 07, 2011

Solaris 11 Launch

Schon lange wird geraetselt und gefragt, wann Solaris 11 angekuendigt wird.  Jetzt ist es soweit: Am

9. November 2011
um 19:00 Uhr Deutscher Zeit

wird es einen Webcast zur Ankuendigung von Solaris 11 geben. 

Herzliche Einladung zur Teilnahme!

(Neuigkeiten von der OpenWorld, insb. alles um T4, werde ich hoffentlich auch bald hier zusammenfassen...)

Montag Aug 01, 2011

Oracle Solaris Studio 12.3 Beta Program

Das Beta-Programm fuer Oracle Solaris Studio 12.3 ist jetzt verfuegbar.  Offen fuer jeden, kann man hier den neuesten Compiler testen.  Man darf in vielen Faellen einen Performance-Vorsprung gegenueber aelteren Versionen und auch gegenueber GCC erwarten.

Viel Spass beim Testen!

Mittwoch Jun 08, 2011

Platten richtig und sicher löschen

Eigentlich ist sowohl die Frage als auch die Antwort schon alt und lange bekannt.  Aber da solche Dinge auch wieder in Vergessenheit geraten und deswegen immer wieder gefragt werden, hier eine Auffrischung:

Eine Platte so zu löschen, dass die Daten auch mit aufwendigen Methoden nicht wieder herzustellen sind, ist unter Solaris ganz einfach.  Das Kommando format (1M) kennt als Unterkommando "analyze/purge".  Damit wird der gewählte Plattenbereich (idR. natürlich s2) insgesamt vier mal mit unterschiedlichen Bitmustern überschrieben.  Das dauert je nach Plattengröße zwar so seine Zeit, ist dafür aber so sicher, dass es den Vorschriften des amerikanischen Verteidigungsministeriums zum sicheren Löschen entspricht. 

Details finden sich hier:

Wichtig zu wissen ist, dass diese Methode u.A. nicht für SSDs aller Art geeignet ist!  Und wer das Risiko, daß seine Daten auf der Platte mitsamt der Platte abhanden kommen könnten von vorneherein ausschliessen möchte, darf natürlich auch verschlüsseln.  Das geht z.B. mit ZFS oder Oracle TDE ganz einfach :-)

Donnerstag Mrz 31, 2011

Neugierig auf Solaris 11?

Neugierig auf Solaris 11?  Was sind die Highlights?  Was genau bringt das neue Package Format, wie funktioniert der neue Installer?  Wie sehen Analysten die Entwicklung?


All diese Fragen werden im Solaris Online Forum am 14. April ab 18:00 Uhr deutscher Zeit behandelt.  Die Veranstaltung ist live - es koennen Fragen gestellt werden. (Eine Aufzeichnung wird spaeter verfuegbar sein.)  Die Sprecher sind hochkaraetige Mitglieder aus Entwicklung und Produktmanagement.


Alle weiteren Details direkt auf der Ankuendigungsseite.

Freitag Dez 17, 2010

Solaris versteht die Hardware - pgstat erklaert sie

Motiviert durch die recht hohen Latenz-Unterschiede beim Zugriff auf Memory innerhalb der E25K wurde Solaris 9 9/02 um die sogenannten Locality Groups (lgrp) erweitert.  Damit wird die Memory-Hierarchie des Systems beschrieben, die je nach Hardware sehr stark verschieden sein kann.   Beim Erzeugen von Prozessen sowie beim Scheduling wird dann versucht, die CPU und den jeweils verwendeten Speicherbereich moeglichst nahe zueinander zu bringen.  Dieses Feature, als Memory Placement Optimization (MPO) bekannt, kann, je nach Anwendungsfall und Hardware, erhebliche Performance-Verbesserungen realisieren.

Der Solaris Kernel bietet, neben vielem Anderem, auch tausende von Zaehlern, die mit kstat, cpustat oder mit bekannteren Kommandos wie mpstat oder iostat abgefragt werden koennen.  Insbesondere die Werte, die cpustat liefert, sind dabei stark von der Hardware abhaengig, da nicht jede CPU jeden Typ Zaehler bietet. Die Auswirkungen auf die Performance, bzw die Auslastung der diversen Hierarchie-Teile konnte bisher jedoch kaum sinnvoll ausgewertet werden.  Hier gab es mit corestat bisher lediglich fuer die T-Serie ein Perl-Skript, das verschiedene Zaehler mit Hilfe von cpustat auswerten konnte.  Das ist mit Solaris 11 Express nun endlich Geschichte.

Es gibt drei neue Kommandos: lgrpinfo, pginfo und pgstat.

lgrpinfo zeigt die Hierarchie der L-Groups an, also die NUMA-Struktur der Hardware.  Immer dann, wenn man bspw. mit Solaris Containern und Resource-Gruppen einzelne CPUs zu Prozessor-Sets verbinden moechte, ist diese Information recht hilfreich.

pginfo zeigt, etwas anders orientiert als lgrpinfo, eine Baum-Sicht des gesamten Systems an.  Die Blaetter dieses Baumes sind die einzelnen Interger- und Floatingpoint Pipelines der einzelnen Kerne.  Hier ein kleines Beispiel aus einer T2 LDom, bestehend aus 16 Strands, die auf verschiedenen Cores ausgefuehrt werden:

# pginfo -v
0 (System [system]) CPUs: 0-15
|-- 3 (Data_Pipe_to_memory [chip]) CPUs: 0-7
| |-- 2 (Floating_Point_Unit [core]) CPUs: 0-3
| | `-- 1 (Integer_Pipeline [core]) CPUs: 0-3
| `-- 5 (Floating_Point_Unit [core]) CPUs: 4-7
| `-- 4 (Integer_Pipeline [core]) CPUs: 4-7
`-- 8 (Data_Pipe_to_memory [core,chip]) CPUs: 8-15
`-- 7 (Floating_Point_Unit [core,chip]) CPUs: 8-15
|-- 6 (Integer_Pipeline) CPUs: 8-11
`-- 9 (Integer_Pipeline) CPUs: 12-15

Hier wird die Zuordnung der verschiedenen Strands zu Pipelines und Cores sehr schoen deutlich.

pgstat letztlich ist ein wuerdiger Nachfolger fuer corestat und zeigt die Auslastung dieser einzelnen Komponenten sehr uebersichtlich an.  Hier wieder ein Beispiel, das gleichzeitig eine fast 100%ige Kern-Auslastung zeigt - etwas, was es recht selten zu beobachten gibt...


# pgstat -Apv 1 2
PG RELATIONSHIP HW UTIL CAP SW USR SYS IDLE CPUS
0 System [system] - - - 100.0% 99.6% 0.4% 0.0% 0-15
3 Data_Pipe_to_memory [chip] - - - 100.0% 99.1% 0.9% 0.0% 0-7
2 Floating_Point_Unit [core] 0.0% 179K 1.3B 100.0% 99.1% 0.9% 0.0% 0-3
1 Integer_Pipeline [core] 80.0% 1.3B 1.7B 100.0% 99.1% 0.9% 0.0% 0-3
5 Floating_Point_Unit [core] 0.0% 50K 1.3B 100.0% 99.1% 0.9% 0.0% 4-7
4 Integer_Pipeline [core] 80.2% 1.3B 1.7B 100.0% 99.1% 0.9% 0.0% 4-7
8 Data_Pipe_to_memory [core,chip] - - - 100.0% 100.0% 0.0% 0.0% 8-15
7 Floating_Point_Unit [core,chip] 0.0% 80K 1.3B 100.0% 100.0% 0.0% 0.0% 8-15
6 Integer_Pipeline 76.4% 1.3B 1.7B 100.0% 100.0% 0.0% 0.0% 8-11
9 Integer_Pipeline 76.4% 1.3B 1.7B 100.0% 100.0% 0.0% 0.0% 12-15
PG RELATIONSHIP HW UTIL CAP SW USR SYS IDLE CPUS
0 System [system] - - - 100.0% 99.7% 0.3% 0.0% 0-15
3 Data_Pipe_to_memory [chip] - - - 100.0% 99.5% 0.5% 0.0% 0-7
2 Floating_Point_Unit [core] 0.0% 76K 1.2B 100.0% 99.5% 0.5% 0.0% 0-3
1 Integer_Pipeline [core] 79.7% 1.2B 1.5B 100.0% 99.5% 0.5% 0.0% 0-3
5 Floating_Point_Unit [core] 0.0% 42K 1.2B 100.0% 99.5% 0.5% 0.0% 4-7
4 Integer_Pipeline [core] 79.8% 1.2B 1.5B 100.0% 99.5% 0.5% 0.0% 4-7
8 Data_Pipe_to_memory [core,chip] - - - 100.0% 99.9% 0.1% 0.0% 8-15
7 Floating_Point_Unit [core,chip] 0.0% 80K 1.2B 100.0% 99.9% 0.1% 0.0% 8-15
6 Integer_Pipeline 76.3% 1.2B 1.5B 100.0% 100.0% 0.0% 0.0% 8-11
9 Integer_Pipeline 76.4% 1.2B 1.5B 100.0% 99.8% 0.2% 0.0% 12-15

SUMMARY: UTILIZATION OVER 2 SECONDS

------HARDWARE------ ------SOFTWARE------
PG RELATIONSHIP UTIL CAP MIN AVG MAX MIN AVG MAX CPUS
0 System [system] - - - - - 100.0% 100.0% 100.0% 0-15
3 Data_Pipe_to_memory [chip] - - - - - 100.0% 100.0% 100.0% 0-7
2 Floating_Point_Unit [core] 76K 1.2B 0.0% 0.0% 0.0% 100.0% 100.0% 100.0% 0-3
1 Integer_Pipeline [core] 1.2B 1.5B 79.7% 79.7% 80.0% 100.0% 100.0% 100.0% 0-3
5 Floating_Point_Unit [core] 42K 1.2B 0.0% 0.0% 0.0% 100.0% 100.0% 100.0% 4-7
4 Integer_Pipeline [core] 1.2B 1.5B 79.8% 79.8% 80.2% 100.0% 100.0% 100.0% 4-7
8 Data_Pipe_to_memory [core,chip] - - - - - 100.0% 100.0% 100.0% 8-15
7 Floating_Point_Unit [core,chip] 80K 1.2B 0.0% 0.0% 0.0% 100.0% 100.0% 100.0% 8-15
6 Integer_Pipeline 1.2B 1.5B 76.3% 76.3% 76.4% 100.0% 100.0% 100.0% 8-11
9 Integer_Pipeline 1.2B 1.5B 76.4% 76.4% 76.4% 100.0% 100.0% 100.0% 12-15

Die Interpretation der diversen Werte ist, nach einem kurzen Blick in die Manpage, eine einfache und klare Angelegenheit.  Damit macht Performance-Analyse, insbesondere auf T2 und T3 Systemen, jetzt noch mehr Spass :-)

Mittwoch Nov 24, 2010

Dateisystem verschluesseln mit ZFS und AES128

Mit Solaris 11 Express ist nun auch die Dateisystemverschluesselung mit ZFS verfuegbar.  Damit schliesst Solaris eine Luecke, die zumindest fuer all jene Festplatten die man ueblicherweise mit sich herumtraegt, dringend geschlossen werden musste.  Aber natuerlich gibt es auch viele gute Gruende, die im RZ gut gesicherten Festplatten zu verschluesseln - schliesslich werden auch diese irgendwann einmal das RZ verlassen...

Genug der Vorrede - so einfach geht das Ganze: 

  1. Der Zpool, der das zu verschluesselnde Dateisystem enthalten wird, muss mindestens auf Version 30 gebracht werden.  Das geht mit einem einfachen "zpool upgrade <poolname>.  Bei einem neu installierten Solaris 11 Express entfaellt dieser Schritt natuerlich.
  2. Jetzt kann man ein neues Dateisystem anlegen: zfs create -o encryption=on <poolname/newfs>
    Das Kommando fragt jetzt interaktiv nach einem Passwort, aus dem der Schluessel fuer das Dateisystem erzeugt wird. Und schon ist es fertig.  Ein Dateisystem nachtraeglich verschluesseln geht nicht.  Natuerlich gibt es weitere Optionen fuer den Schluessel, die in der Manpage beschrieben sind.

Ebenfalls gibt es diverse Wahlmoeglichkeiten bei der Schluessellaenge fuer AES.  Die einfache Variante mit "encryption=on" waehlt AES-128 im CCM Modus.  Alternativ koennen auch 192 oder 256 Bit Schluessel verwendet werden.  Bei der Entwicklung von ZFS crypto wurde diskutiert, welche Schluessellaenge als Default verwendet werden sollte.  Die Wahl fiel aus zwei Gruenden auf 128 Bit:  Erstens ist die Verschluesselung, insbesondere wenn keine Hardware-Beschleunigung wie bei der SPARC T2/T3 oder Intel 5600 CPU vorhanden ist, bei 128 deutlich weniger aufwendig als bei den groesseren Schluessellaengen.  Zweitens gibt es neue Untersuchungen und auch erfolgreiche Angriffe auf AES256 und AES192 mit Aufwaenden von nicht mehr als 2\^39.  Diese Angriffe greifen bei AES128 nicht, weswegen diese Variante nicht nur schneller, sondern auch sicherer ist als die Variante mit groesserer Schluessellaenge.

Weitere Details zu ZFS Crypto gibt es im ZFS Admin Guide.

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