A few weeks ago, it looked like IBM was going to make a deal to purchase Sun. That fell through when the Sun board could not come to agreement. On April 20th, with very little rumor in the marketplace, Oracle announced they were buying Sun for $7.4B in cash. What does this mean for the new company?

• To quote a recent Oracle publication, “Oracle plans to engineer and deliver an integrated system – applications to disk – where all the pieces fit and work together, so customers do not have to do it themselves.” Sun is already shipping Infiniband switches and blades with InfiniBand on the motherboard. They have also mentioned IB is on the roadmap for the Sun 7000. Andy Bechtolsheim mentioned it at the Sun product announcement on April 14th. What about an integrated Oracle appliance running on Nehalem blades, Solaris x64,  Sun 7000 storage, and using Infiniband switches. It should not be a major technology leap to put it all together. What would this mean for the Oracle/HP appliance?
• Sun SPARC processors are at an Oracle pricing disadvantage to IBM Power processors in the current Oracle pricing model. Oracle has never been afraid to use pricing to move the market in their direction. Watch for them to use their pricing model to encourage customer to buy Sun servers.
• Solaris x64 has been intentionally neglected by Oracle. Oracle delivers patches on Solaris SPARC and Linux immediately. Then, they have historically waited up to 6 months to release that same patch for Solaris x64. In the past, this has helped Oracle push their Linux agenda in the marketplace. Given the ease of porting the Oracle patches to Solaris x64, there is no logical technical reason for this lag. Watch for Solaris x64 to become a first class citizen in the Oracle OS support matrix now that growth of Solaris x64 means growth for Oracle.

Read more…

I’ll be teaching two days of my Solaris tutorials at the Usenix ATC conference in San Diego during the week of June 15th. Hope to see you there!

My April 2009 column has been published in ;login: Magazine. This month it’s The Sun Virtualization Guide- making sense of and decisions about the various Sun virtualization options. LDOMs, Containers, Domains and Xen are all options worth considering, and this guide leads you through what each does and when to use them. Some ;login: contents is freely available at ;login:, but my column this month is not one of them. I’ve posted the .pdf here for those without a USENIX membership (although I strongly recommend you get one if you are interested in all things Unix).

There is no debating that duplication is one of the hottest topics in IT. The question is if the hype has started to become bigger than the technology. Today, there are two primary use cases driving deduplication in the marketplace. The first is backup to disk and the second is virtual guest operating systems (VMware, Hyper-V, and Xen guests). (I will talk a bit about the disk to disk scenario in this article and the virtual guest topic in the next one.) These are both logical markets to adopt deduplication because they suffer from a common challenge. They both create a tremendous amount of redundant data on the disk array. The goal in both cases is to pack more data onto a disk drive and reduce the cost per GB. This is the first and most obvious use case for deduplication.

Disk drive capacity is growing exponentially, but disk performance is increasing at a much slower rate. In many cases, when helping customers size for their workload, performance drives the spindle count and not capacity. It is easy to meet the capacity needs with large drives, but will they meet the performance requirement? That is the problem. Often performance is what dictates the spindle count. It is no longer sufficient to size a storage device based solely on capacity requirements. This is a general challenge that must be taken into account when sizing a storage array.

Read more…

Some folks have asked about the sources of Nehalem’s performance improvements. Certainly a major contributor is its new on-board memory controller and the new QuickPath Interconnect (QPI).  Rather than having multiple sockets (each possibly containing multiple cores) of CPUs sharing a bus to get to memory in a Unified Memory Access (UMA) model, Intel with Nehalem has moved to a Non-Uniform Memory Access (NUMA) architecture. As the number of cores of compute power within a system increase, the more the need to have fast interconnects between the cores and their memory. Unfortunately at scales of greater than 4 or more cores, its unfeasible to have all components talking directly to all other components (uniformly). A single bus can be overwhelmed and become a bottleneck, and just cranking up CPU and bus speeds has failed to solve the problem because the amount that the crank can turn is limited.  Rather, components connect to other components, which then connect to other components. Each connection is very fast (especially when it is non-shared and there is no contention to have to mitigate), but a component take multiple hops across these fast connections  to reach some other components.  Some components are “closer” than others, so communication is faster. Thus the creation of NUMA architectures.

Read more…