c0t0d0s0.org

I got some questions regarding Heartbleed and Oracle products from blog readers. In this regard i just want to link to the entry in the Oracle Security Blog: "‘Heartbleed’ (CVE-2014-0160) Vulnerability in OpenSSL ". The author states:

Oracle recommends that customers refer to the My Oracle Support Note Doc ID 1645479.1 for information about affected products, availability of fixes and other mitigation instructions.

Markus Flierl writes in "Don't miss the announcement of Solaris 11.2":

It's very hard to find time for writing a blog these days: I've been quite busy working with my team on getting the final features into Solaris 11.2, making sure that we address any remaining critical defects while getting ready for the announcement of Solaris 11.2 in NYC on April 29. I find the latter particularly hard: Trying to squeeze all of the new capabilities of Solaris 11.2 into a 45 min preso feels like trying to squeeze four elephants into a VW Beetle. The current plan for April 29 is to start by ringing the bell and open up the stock market in the morning followed by the announcement event after lunch at the Metropolitan Pavilion on 639 W. 46th Street.

In a some customer situation i'm using a number of Oracle Sun Flash Accelerator F40 PCIe Cards or F80 PCIe cards to create flash storage areas inside a server. For example i had 8 F40 cards in a server by using a SPARC M10 and a PCIe Expansion Box which enables you to connect up to 11 F40/F40 cards per expansion box.

The configuration with 8 F80 cards for example is a configuration i'm using on very special occasions and for special purposes, in this case it was a self-written application of a customer needing a lot flash storage inside the server. I won't disclose more. On the other side: I'm sizing quite frequently systems with two F80 cards for "separated ZIL" purposes . Either if you use the SSD as data storage or as separated ZIL: When you do mirroring you have to ensure that mirrors are not using mirror halves on the same card.

From the systems perspective you see four disk devices per F40/F80 card with 100 respective 200 GB capacity per disk and thus you can just add them to your zpool configuration. However configuring the system was a little bit unpractical. The problem: It's not that easy to create a configuration that ensures that no mirror has it's two vdevs on a single F40/F80 card. Perhaps there is an easier way, however I didn't found it so far.

It's a little bit hard to find acceptable disk pairs when you are looking on PCI trees like /devices/pci@8000/pci@4/pci@0/pci@8/pci@0/pci@0/pci@0/pci@1/pci@0/pci@1/pciex1000,7e@0/iport@80:scsi. Well, at two cards it's not that hard, but still not a nice job. After doing this manually a few times, i thought that at 8 or 22 cards doing this manually is a job for people who killed baby seals, listen to Justin Bieber or equivalent horrible things.

But i didn't committed to such crimes and this problem is nothing that a little bit of shell-fu can't solve. You can do it in a single line of shell. Well ... a kind of a single line of shell.

Ich habe ja schon vor einigen Tagen geschrieben, das Anfang Mai ein Oracle Business Breakfast zum Thema Oracle DB Tuning auf Solaris 11 in München stattfindet. Es ist nunmehr die Einladung da und der Anmeldelink aktiv. Ihr könnt euch hier anmelden.

Zum Inhalt:

Zwar sind die Defaults von Solaris und der Oracle Datenbank für den durchschnittlichen Anwendungsfall gut gewählt, doch manchmal möchte man seine Datenbank doch noch weiter tunen und mehr herausholen oder auf die Spezialitäten der eigenen Last anpassen. Dieser Vortrag wird eine Einführung in die Stellschrauben der Oracle Datenbank und von Solaris geben und erklären, wie sie funktionieren, warum sie funktionieren, wie sie interagieren und Hinweise für den Einsatz in der Praxis geben. Weiterhin soll der Vortrag erklären, wie man aus dem AWR-Report auf System- oder Hardwareprobleme schließen kann.
Abgerundet wird die Veranstaltung durch die Vorstellung der neuen Version des Oracle Enterprise Manager Ops Centers zur vereinfachten Administration - insbesondere für die Oracle VM auf SPARC (aka LDOMs).

Despite popular belief ethernet networks aren't lossless, on the long way between the TCP/IP stack from one side to the TCP/IP-stack of the other side there is a lot that can happen to the data. Datacenter Bridging is a mechanism to put some kind of losslessness on the network needed for shoehorning storage protocols on it (FCoE). That said most of the time ethernet networks appear as lossless, even to that extent that protocols are used for important traffic that were used once for traffic considered as "nah, not that critical, when the packet doesn't arrive" ... UDP for example.

But that are a lot of different stories. That said you can make some errors in configuration that make ethernet networks more lossy than necessary and those can even haunt you in relatively simple configuration like a link aggregation.

There is a new roadmap available about the future development of SPARC at oracle.com covering the time until 2019. Especially interesting because of the list of software in silicon features planed for the next-gen iteration of SPARC. At while i'm at it: Solaris 12 is on the roadmap as well.

Given that nothing important changes (world stops turning, leaving company, illness, forget to book a conference room, outbreak of the Minbari space plague) i will doing the Oracle Oracle DB Tuning presentation i have already held in DUS and will hold in HAM on 10.4. a third time. Current state of planing is the 9.5 in Munich. The registration link will follow as soon as it's available.

The event is a in depth presentation about the Service Management Framework in german language in Hamburg. Thus i will proceed in german language . Sorry.

Am 11.4. findet in Berlin ein Vortrag über die Service Management Facility statt. Anders als meine bisherigen Vorträge findet dieser nicht in den zuweilen recht schwierig zu Besprechungsräumen in Potsdam statt, sondern im Oracle Customer Visit Center Berlin (Humbold Carré , 3. Etage - Behrenstraße 42 / Charlottenstraße).

Worum geht es? Die Service Management Facility (SMF) von Solaris, obschon seit Version 10 enthalten, ist für die meisten Kunden immer noch ein Feld, das recht selten betreten wird und oft mit dem Schreiben eines init.d-Scripts umgangen wird. Dadurch verliert man jedoch Funktionalität. Dieses Frühstück will noch mal die Grundlagen der SMF aufrischen, Neuheiten erläutern, die in SMF dazu gekommen sind, Tips und Tricks zur Arbeit mit SMF geben und einige eher selten damit in Verbindung gebrachte Features erläutern. So wird auch die Frage geklärt, was es mit dem /system/contract-mountpoint auf sich hat und wie man das dahinterstehende Feature auch ausserhalb des SMF gebrauchen kann.

Anmelden für die Veranstaltung kann man sich hier.

The event is in german language in Hamburg. It's a presentation about Oracle DB Tuning on Solaris 11. Thus i will proceed in german language .

Ich möchte Euch auf eine Veranstaltung hinweisen, auf der ich sprechen werde. Sie findet am 10.4.2014 statt. Es geht um das Tuning von Oracle DB auf Solaris 11. Zwar sind die Defaults von Solaris und der Oracle Datenbank für den durchschnittlichen Anwendungsfall gut gewählt, doch manchmal möchte man seine Applikation doch noch weiter tunen und mehr rausholen.

Dieser Vortrag wird eine Einführung in die Stellschrauben der Oracle Datenbank und von Solaris geben und erklären, wie sie funktionieren, warum sie funktionieren und Hinweise für den Einsatz in der Praxis geben. Weiterhin wollen wir zeigen wie man aus dem AWR-Report auf System- oder Hardwareprobleme schließen kann.

Ihr könnt euch unter diesem Link anmelden.

Honglin Su just reported about the availability of Oracle VM for SPARC 3.1.1 in this blog entry. While a x+0.x+0.x+1-step may not sound that big, it has an important feature enhancement. SR-IOV is now supported for FC cards as well, thus increasing the number of domains with direct hardware access to storage without plugging in vast amounts of FC cards into the system. Makes my job really easier. And bandwidth limiting in the hypervisor is a plus, too.

You will find more information about the usage of FC SR-IOV at docs.oracle.com

You are virtuously using mdb -w to tune a system and type all the commands from memory ... however you can still fsck up the whole system with a single mistake while using it. The mistake in my case was thinking i'm in the left window whereas i was in the right window. In the left window i wanted to exit out of a shell. In the right window was a waiting mdb -kw(yes, the basic mistake to have it left open). At the end the system was doing a panic right after leaving mdb. An explanation for this behaviour can be found here. When using mdb -kw do it like Swigert in the Apollo 13 film ... put a Post-it on your screen saying "Don't exit". Control+D is your way to leave the mdb.

Ich möchte noch mal um Aufmerksamkeit für die Vorträge in Frankfurt und Hamburg bitten. Beide sind zwar schon gut besucht, aber mehr geht immer. In Frankfurt geht es um die in Solaris eingebauten Securitymechanismen. In Hamburg werde ich einen Grundlagenvortrag über die Service Management Facility geben. Idee hinter letztem Vortrag ist ein Einblick über das was mit SMF möglich ist, wie man damit umgeht, was seit Solaris 10 alles dazu gekommen ist und wie ich eigene SMF-Manifeste baue. Denn 9 Jahre nach der Einführung von SMF sind da einfach noch zu viele init.d-Scripte da draussen

I'm using the Sun Flash Accelerator F40/F80 PCIe Card quite frequently (as i've used the F5100 and F20 in the past) in the recent time for POCs. In my experience to get best performance you really should abide the tips on this page.

When you put F40 cards into your systems, add this line into /kernel/drv/sd.conf.

sd-config-list = "ATA     3E128-TS2-550B01","disksort:false, cache-nonvolatile:true, physical-block-size:4096";

The F80 card works best with this line in /kernel/drv/sd.conf

sd-config-list = "ATA     2E256-TU2-510B00","disksort:false, cache-nonvolatile:true, physical-block-size:8192";

When you use both cards you have concatenate both lines into a single one.

sd-config-list="ATA     2E256-TU2-510B00","disksort:false, cache-nonvolatile:true, physical-block-size:8192",\
"ATA     3E128-TS2-550B01","disksort:false, cache-nonvolatile:true, physical-block-size:4096";

The effects of this lines are quite simple, but very important. I'm simplifying the reasoning in the next paragraphs a little bit:

• disksort:false - This part deactivates the disk sort algorithm. The disk sort algorithm tries to resort disk accesses to minimise head seeks. However, with a disk without disk heads the use case is obviously somewhat limited and may even have an adverse effect ( when you have read requests for block 100, 150, 200, 180, then the execution is like 100,150,180,200. When an access for block 110 is requested before the request for 15 has been send to disk, the last new requests is actually executed before the older ones are send to disk ... normally a good thing as you you can assume that you don't have to move the head that much to get block 110 when you just was at block 100 and so get the block en-passant, however the requests for blocks 150,180 and 200 take longer than you would expect as the block 110 requests jumped the queue) that isn't offset by the positive effects of sorting the requests that minimise head movements.
• cache-nonvolatile:true - This part tells the system, that the device has a non-volatile cache. When you do not set this ZFS thinks it has to flush caches of the disk quite often to ensure that the data is really on disk and not just in the cache soldered to the disk. However the flash cards doesn't need this because it's ensured that the data written to the disks are persistent after a reboot. The additional unnecessary flushes cost performance ... so we can just deactivate them. As soon ZFS detects that the devices are flagged nonvolatile, ZFS automatically stops the flushes of the disk cache. You can gather some additional information at >docs.oracle.com
• physical-block-size:4096 respectively 8192 - The f40 cards are optimised for accesses with a block size of 4096 bytes, the f80 card is optimised for 8192 bytes. By setting this parameter, you override the data reported out of compatibility reasons by the disks and set a different block size. The system then assumes that the device is a 4k or 8k disk and aligns it's accesses accordingly

There are a lot of suggestions to increase the rsize and the wsize parameter for NFS to get better performance when doing large transfers. The idea is that NFS is transmitting larger chunks at once and thus improving the performance. However there is a step that you have to do before, when you want to increase both parameters.

There is another useful subcommand in svccfg:. You've installed your system, everything works nice ... however after a while you want see what you had customised in the past. And sometimes you want to remove this customisations ... the listcust and delcust subcommands can do those jobs for you.