Thoughtput

Data Center In A Container

There has been lots of promotion of the data center in a container concept. Sun was one of the early proponents, and Rackable recently showcased their version at the LinuxWorld Expo.

I believe there is some significance to these configurations behind the basic promotional aspects. By putting a fixed amount of computing resources in a 8x8x40 box, it is very easy to concretely identify the space, power, and cooling requirements. Once you are within a building, it is often much more difficult to isolate those variables.

So even if a company does not buy the "container concept" I bet they are paying close attention to the environmental ratings of the configuration at that scale. Most customers do not buy just one server, or even one rack of servers...they buy multiple racks. The data center in a container concept makes the environmental ratings meaningful at a unit of measure suitable to large data centers.

Following is a super short video tour of Rackable's data center container at the LinuxWorld Expo. Enjoy.

Rackable Data Center in a Container from Gary O on Vimeo.

Super Structure

The GigaOM team hit the conference scene with a bang by hosting the Structure08 conference today. Here's a few things I enjoyed.

• The speaker roster and attendee list were top notch.
• The panels covered pertinent topics on the challenges of building web scale applications.
• It was a one day, one track conference. Densely packed and too the point.
• Coverage of the infrastructure supporting the boom in cloud computing applications is long overdue, as evidenced by the sell out crowd.

They have put practically the entire conference online. Best place to start might be the list of Live Coverage of Structure08.

The Quest for More Memory

This week's Network World Tech Update features a piece we wrote about centralized storage caching. It is short and straightforward, so hopefully you will enjoy the read. A key focus is on the use of open standards for caching which in the case of Gear6 scalable caching appliances is Ethernet, IP, and the Network File System (NFS).

I used this standards-based caching overview earlier this week at a software conference hosted by the 451 group. One panel was on software-as-a-service, or SaaS, with a couple of companies delivering SaaS discussing how they approach the market. At the end, an audience member from a large chip company asked what these SaaS companies might like to see from a hardware perspective to help them better deliver their offerings. One panelist responded, "More main memory. That is what we need to deliver our application effectively."

Adding more memory to computers is an age old quest. The issue is that adding more memory requires an intricate balancing act between vendors of processors, motherboards, memory chips, and operating systems. It isn't easy to get everything in sync as quickly as the market demand for more memory is increasing.

But while we wait for memory density to increase, there is a another straightforward way to increase memory to applications though a standards-based approach of centralized storage caching.

Instead of waiting for all of the starts to align on the processor, motherboard, memory chip, and operating system constellation, how about an open-systems approach to add more memory to the overall infrastructure?

By building a high-speed, high-capacity caching appliance that scales in the network, customers can do just that. The Network World article explains this in more detail.

This standards-based approach helped me explain why centralized storage caching is an important step for building scalable infrastructures. For companies delivering software-as-a-service, it might be worth a closer look.

Back from Oracle Users Group

We spent a few days earlier this week in Vegas at the Independent Oracle Users Group conference called COLLABORATE07. It is co-hosted with the Oracle Applications Users Group and the Quest Software Users Group.

There is nothing better than hobnobbing on the floor with tons of users and potential customers to share ideas about new products and solutions. By far the most compelling response was the near unanimous interest in solutions that increase performance.

Performance at the highest level is a simple and straightforward message. Get your job done faster. Be more efficient. Save time. Save money. It doesn't take long to explain this type of solution and for people to understand it.

But the best part is the next level of discussion. Do I need to change my applications? Nope. Database? Nope. How about my storage? Nope. Curiosity continues, then more questions and answers, and then a smile and a request for more information.

In the past, increasing performance for databases meant weeks or months of tuning; it meant long and arduous examination of every piece of the equipment in the overall equation, scrutiny across logs and tables, and maybe the opportunity to increase by single digit percentages.

Now with centralized storage caching, customers have a transparent way to get a big boost in I/O performance, and a corresponding improvement in database performance, without requiring a change-out or forklift upgrade to the rest of the infrastructure.

Oracle World: Oracle's Linux grid

Larry Ellison began his talk last week at Oracle World with this slide:

Oracle Grid Computing Strategy

Low Cost
    > Standard Intel and AMD hardware

High Performance
    > 64 PC server grid is faster than fastest mainframe
    > Capacity on demand - add servers as needed

Reliability
    > Fault tolerant architecture
    > No single point of failure

What was abundantly clear from the main news about Oracle supporting and re-distributing Red Hat Linux is that Oracle is aiming for more Linux deployments, and ultimately more Oracle deployments in the enterprise.

But the underlying news is how grid-based architectures based on industry standard hardware will drive storage performance needs. More grid deployments lead to a much higher number of concurrent clients accessing a single data set. This drives a requirement to deliver simultaneous I/O streams with the high throughput and low latency demanded by grid applications and databases.

To date, storage systems capable of matching grid performance have been few and far between. Complementing existing storage systems with centralized storage caching will take grid computing further.

Snapshot from StoragePlus 2006

The folks at Byte and Switch are on to something with their StoragePlus conference, most notably that storage in and of itself isn't nearly as interesting as looking at the "plus" picture that includes servers, applications, security and more. I hope they do well following the inaugural event in Burlingame, California this week.

There is a post on the site about the presentation by David Webster, manager for IT architecture and strategy at Yahoo, but I think they missed one of David's most interesting comments around virtualization of all resources at the server AND storage layer. I really think the term here should be provisioning as opposed to virtualization, but we can save that for another time.

Here is the important slide as scratched from my notes.

Virtualization
> Problem "solved" in the host space
    -resource allocation (e.g. memory/CPU)
    -redistribution
    -rapid provisioning
> Storage virtualization
    -new Quality of Service (QoS) potential
    -not easy to recover from over-provisioning of storage

The explanation was that it has been relatively easy to deal with bandwidth and memory constraints at the host layer. There are plenty of tools to manage the allocation of memory and CPU resources. And more importantly, in the event that those resources need to be redistributed elsewhere, that can be easily accomplished. On the networking side, tools to either rate limit or trunk connections allow easy tuning.

But on the storage side there is still a tremendous open opportunity for QoS. Most notably there are no easy ways to de-provision storage right now. In order to match the flexibility at the host layer, there needs to be a corresponding set of capabilities with storage that allow fine tuning and control for bandwidth and I/O access.

These themes indicate that not only is there a gap between server performance and the ability of storage to match that performance, but there is a gap between how resources are deployed. Most of the heavy lifting has been completed at the host layer, but the storage layer still needs the ability to rapidly deploy, provision, and de-provision predictable performance.