General

Oracle published an interesting whitepaper - "Using Oracle® Solaris 10 to Overcome Security Challenges". It's not a security cookbook, but it summarizes the security features in Solaris 10 nicely. Worth a read.

Lisa Simpson marries today. Or tries to

The migration is postponed to mid auf August ... just recognized a problem, that i have to solve beforehand ... comments are open now again ....

Comments are closed down at the moment due to website migration ....

Bitte die Augen auf den rechten Rand des Bildschirmauschnitts:



(via: bildblog.de)

An interesting ARC case found it's way into the case log: Stephen Lawrence proposed the zonestat to the architecture review comitee.

This feature consists out of two components. The zonestatd and the zonestat command. Stephen writes about the zonestatd:

A new smf service svc:/system/zones-monitoring:default will execute a zones monitoring daemon. This daemon will implement monitoring the system configuration, managing extended accounting, and computing memory utilization on behalf of clients.

This zonestatd is queried by the zonestat command to deliver data about the resource utilization of zones.

# zonestat 5 1
    SUMMARY
                        -----CPU------------- ----PHYSICAL--- ----VIRTUAL----
                   ZONE USED %PART %CAP %SHRU USED  PCT  %CAP  USED  PCT %CAP
                [total] 9.74   30%    -     - 7576M  23%    - 11.6G  24%    -
               [system] 0.28  0.8%    -     - 6535M  19%    - 10.4G  21%    -
                 global 9.10   28%    -     -  272M 0.8%    -  366M 0.7%    -
              kodiak-ab 0.32  1.0%    -     -  256M 0.7%    -  265M 0.5%    -
             kodiak-rie 0.00  0.0%    -     - 22.7M 0.0%    - 49.4M 0.1%    -

Due to the implementation with a daemonized part, you can even tell the daemon to compute a report about the utilization in certain intervals:

# zonestat -p -r memory -q -R average,high 30s 24h 1h

Please read Stephens case document for for more information.

Another nice example to show the pitiful state of the IT media, is article you can read at eWeek. I should use the words "exclusive" or "scoop" more frequently. I don't want to sound bitchy because eWeek doesn't read my blog. I just want to make fun out of them. I don't like most journalists and i assume, the journalists reading my blog doesn't like me.

This morning i read "Oracle Prepares Network Convergence for Its Red Stack". At first, i want to remember you of this article article i wrote on 2nd of July. It was about the new 10 GbE CNA in the Oracle product portfolio. 20 days ago. In IT news time this is close to the eternity.

Now let's look into the article of eWeek:

Word about this leaked out during QLogic's earnings call July 22 and was first blogged about by Wikibon analyst Stuart Miniman and Silicon Angle's John Furrier. But neither obtained comment or perspective from QLogic, the supplier of Oracle's—as well as other systems makers'—server and storage adapters that enable FCOE.

No, it "leaked" by the announcement mail of Oracle to partners. From there i did a quick search on the Sun web page and found the card within a few seconds and put it to the blog, datasheet included. You even find this card, when you just look at the matching category.

"To date, Oracle has not announced any converged networking support for any of its servers [or storage]," Steve Zivanic, QLogic senior director of corporate communications, told eWEEK. "The news is that now they are bringing network convergence to this stack. We're enabling them to have the connectivity for these new virtual data centers."

Not for any of our servers? Well, the publicly available datasheet states that the card is supported in Sun Fire X2250, Sun Fire X2270, Sun Fire X4140, Sun Fire X4150, Sun Fire X4170, Sun Fire X4270, Sun Fire X4275, Sun Fire X4240, Sun Fire X4250, Sun Fire X4640, Sun Fire X4440, Sun Netra X4450, Sun Fire X2200 M2, Sun SPARC Enterprise T5120, Sun SPARC Enterprise T5220, Sun SPARC Enterprise T5140, Sun SPARC Enterprise T5240, Sun SPARC Enterprise T5440, Sun SPARC Enterprise M3000, Sun SPARC Enterprise M4000, Sun SPARC Enterprise M5000, Sun SPARC Enterprise M8000 and Sun SPARC Enterprise M9000. Enough?

Oracle, like several other systems providers, brands its stack as its own and doesn't broadcast what components it licenses to put inside its boxes. But since the QLogic connection became public at the earnings call, the topic is now fair game.

The fact, that the CNE is from Qlogic isn't really new ... people fluent in the Sun sphere routinely look at the part number to find out, the vendor for the card: As written on the datasheet the part number is SG-XPCIEFCOE2-Q. Q doesn't stand for handsoldered by Q, her majesty best known quartermaster. People not so fluent in the Sun sphere just look at the whitepaper and will find "Full hardware offload for FCoE protocol processing based on QLogic architecture" on the very first page and when you look at the card featured on this document you can even recognize the Qlogic logo when you saw the Qlogic logo just once in the past.

So you find this photo of the FCoE card on the Oracle web site since the beginning of the month:


The datasheet for QLE8142 presents the following card:


Oh, thank you, dear eWeek, for disclosing this secret, thank you for being so fair just to publish, because Qlogic talked about that


So ... dear first commentator at this article ... this isn't a scoop as well as this this news is as secret as a webpage on a public webserver is.

More interesting than this CNE card story is the announcement of the switches (Top-of-rack and NEM) by Sun. Despite public perception the E in FCoE isn't the Ethernet you currently have in your datacenter. It's pretty much different as it has to implement tight flow controls as FC was never designed to work well with lost frames.

Anyhow ... i strongly believe this controllers will have a similar future then iSCSI implementations in hardware: A short active lifespan. Given the immense horsepower CPUs have today it isn't unreasonable that this functionality will move into the operating system as it happened with iSCSI. A few years ago i've got questions about my opinion about iSCSI hardware implementations once or twice a month. In the last 12 months i got the same question just once.

Since the advent of iBFT even the only point of this cards wasn't a problem: Booting. However i'm a strong proponent of "No-(SAN/LAN)-Boot". I like systems that boot on their own. With local boot disks you know in an instance that your server has a problem when it doesn't come back. With SAN/LAN-boot you have to root cause the problem to the network, to the switches, to the server/storage providing the boot images and finally to the client. Additionally i like my swap locally. But that's a different topic.

As soon software FCoE initiator implementations are as common as software iSCSI intitiators are today, the market for FCoE will go the same way than the one for iSCSI hardware.

Just to get back to the beginning of my article:I wonder how long it takes for the IT media to find HP's announcement of the inclusion of Oracle Support in their SMLS program. How many will declare that as a scoop, as exclusive If somebody wants to, he or she can leave a comment at eWeek