I've long found the Federal Communications Commission to be a curious body. With a track record of commissioners coming from or going to high positions in industry, it's hard not to wonder about impartiality and whether commissioners are always acting completely in the interest of the public good. On occasion, the FCC comes across as a cheerleader for a specific technology or company, while at least partially turning blind eyes to strong technical evidence that counters the viability of some of the agency's pet initiatives.

Broadband over Power Lines (BPL) is a recent example, where the FCC wasn't very serious or consistent about enforcing its own regulations on interference that was disruptive to a range of licensed radio services. While the agency was out busting low-power community "pirate" radio stations, they often bordered on being a free advertising agency for BPL, regardless of the significant problems related to the technology in certain common configurations, as proven repeatedly by qualified experts. BPL as an initiative now is somewhere between death and life-support, having not survived its own flaws, despite the FCC's efforts to champion it.

Back to Lightsquared, and yet another weird vibe from the FCC. Lightsquared is an LTE broadband startup that employs technology that has been proven by a number of qualified groups to interfere with GPS signals. We're talking consumer, scientific, and military GPS applications at risk from Lightsquared's emissions. Typically, new technologies have to prove themselves to be non-problematic before the FCC will approve them going forward. Lightsquared however, was given conditional approval by the FCC's Democratic commissioners early on, with technical validation to follow. And here's how we got to the mess things are in today.

One prevailing version of the story (greatly simplified for brevity) has Phil Falcone, head of Lightsquared's owning company Harbinger Capitol, donating large amounts of money to the Democratic Party in advance of the FCC giving the go-ahead to Lightsquared in advance of the company actually proving its ability to be a radio good neighbor. But sooner or later the testing would come, and the results were not pretty. At least nine government agencies and the GPS industry have shown evidence that Lightsquared's approval would be devastating to a wide range of civil, consumer, and defense applications that that use the long-successful GPS system. The FCC (having little choice) has had to slow down the momentum of Lightsquared's unusually fast approval process in response, while the company attempts to address if and how they are going to get around the interference issues.

In the inevitable back-and –forth, Lightsquared has countered it's critics with a few well-publicized arguments. Talk of an inexpensive filter that could be added to high-end GPS receivers to mitigate the effect of Lightsquared's signals didn't go very far, as no real examples of the solution were offered and the strategy wouldn't help the millions of consumer-GPS-equipped products in use. Lightsquared has also claimed that the GPS system itself is problematic, and operating outside the tolerances of its approved frequency ranges. Whether this has been independently verified is unknown to me, but the GPS landscape is so entrenched at this point, Lightsquared's argument is almost moot.

And now the latest. Sprint is the biggest-named partner to sign on with Lightsquared, having done so early on. Sprint had originally given Lightsquared until February to get final FCC approval, which was derailed because of pushback by all of those who will feel the impact of a performance-compromised GPS system. Now, as Lightsquared (again with FCC cooperation) throws a Hail Mary pass by actually challenging whether GPS is legally entitled to protection from interference, Sprint has extended Lightsquared's approval deadline into mid-March. The FCC is gathering public comments on a fundamentally idiotic question, and we'll have to wait a few weeks to find out if this circus is finally over or whether this is just another turn along a very strange road paved by the FCC.

Anyone who follows the goings-on with spectrum-related issues and broadband growth in the US would agree that we have to have an eye to the future and look for new technologies. But if the FCC is going to be the agency that helps the country move forward, they are going to have to de-politicize their playbook, leave the technical decisions to experts, and start doing what's right for a change.

Leaving aside the irony that competitor Hitachi Data Systems used Thunder and Lightning as codenames for their high-end disk arrays that were a thorn in the side of EMC's Symmetrix sales, EMC seems to be building a comprehensive portfolio of flash-based technologies. Their arrays can use flash as dedicated volumes, sun-LUN tier with FAST, and use flash as a cache with FASTcache. VFCache extends caching, at least read caching, to the server and Thunder promises all-flash arrays delivering millions of IOPs.

VFCache is an off-the-shelf PCIe flash card from Micron (the P320) or LSI (not, as rumored, Intel), with EMC's special sauce caching software. The software, which is available for Red Hat Linux and Windows, with support for VMware and Hyper-V, installs as a filter driver in the server's, or virtual server's, operating system and uses the flash it's been allocated as a write-through cache. Since all writes are forwarded to the back-end storage immediately, snapshots and other functions that access data directly on the back-end storage will work properly.

However since it's a write-through cache, VFCache will only speed reads. Since many mainstream applications like database servers do 2-5 times as many reads as writes, just caching reads can still result in a significant performance boost, as much as 80 percent for Oracle in some EMC benchmarks. In the VMware environment, system administrators can slice and dice the 300GB of SLC flash on the card and allocate it to VMs to use as cache. Since the cache is local to the host, when an admin wants to vMotion a virtual machine to another host, they have to manually disable caching before moving the workload.

For the future EMC promises "a rich roadmap of VFCache technologies", including deduping and compressing data in cache to increase its effective size, MLC based PCIe cards, mezzanine cards for blade servers, SSD formats, and of course the array integration that made Lighting more interesting than standalone caching solutions like those from Flashsoft, Fusion-IO's IOturbine, or Nevex. With array integration, a host could tell the back-end array not to use its valuable flash to cache data that's already in the local server cache, or specifically to cache to flash as the VM is about to be vMotioned to another host. They also promise to address clusters and vMotion by making the cache in multiple servers coherent, though only time will tell if that's worth the CPU and network overhead.

This announcement points out one of the limitations of Cisco's UCS blade servers that's always bothered me. The standard UCS blades have only one mezzanine slot per blade and no LAN on motherboard, so the mezzanine slot has to be used for network and storage I/O, which means converged networking is required. That's opposed to other blade systems where it's just a good idea. More significantly, it means UCS blades, other than the double-wide blades that take two of the eight slots in a UCS chassis, have no available I/O expansion. I would hazard a guess that one of the primary drivers for making the VFCache software work with SAS/SATA SSDs is that they can be used in UCS blades, though the disk interface bottleneck will mean SSD VFCache will never be as quick as PCIe flash.

As the EMC guys said, after the Lightning comes Thunder, so EMC previewed a new all-flash storage system as "Project Thunder". The system holds several PCIe flash cards and connects to multiple servers. In order to hold down latency, the server-to-storage connection is via RDMA (Remote Direct Memory Access) over InfiniBand or 40Gbps Ethernet. One Thunder can deliver millions of IOPS to the kinds of customers now considering solutions from the likes of SolidFire, Nimbus or Pure Storage.

As usual EMC wouldn't say anything on price but that it would be competitive with solutions from Fusion IO.

Disclaimer: EMC is not currently a client of DeepStorage, LLC. Though they have been in the past and may, if they don't mind me picking on Lightning, be one again.

Product differentiation can be tricky. Recall the words from a Carly Simon song: "What has she got that I haven't got?" When one vendor makes a claim, another will claim the same capability (checklist marketing, anybody?), even though there may be fundamental, inescapable differences. So please bear with me while I lay a foundation for dinCloud's story.

dinCloud offers just about everything in a set of cloud-based services that you would find in a regular data center, but the gem of its empire is its virtual desktop solution. One way of thinking of the dinCloud offering would be VDI (virtual desktop infrastructure) in the cloud, but the company disavows that term because it is too limiting. Instead, dinCloud provides what it calls the hosted virtual desktop (HVD) service--"hosted" because the service can be provided on premises (private cloud), off premises (public cloud) or in combination (hybrid cloud).

Now, HVD is not all that clouds can be, obviously, since there are other important uses of the cloud, such as test and development and disaster recovery as a primary service. (In fact, dinCloud does perform data protection and disaster recovery for its HVD and other services.) So how is HVD different from VDI, and why is that difference important?

VDI is a variant of the longstanding client-server model where a desktop operating system is hosted on a virtual machine (VM) that runs on a centralized server. All processes, applications and data are kept on and run on a central server. Although there are variants, one view is that PCs and laptops would be replaced by thin clients (which in the past would be called dumb terminals, but the name was changed to be a more marketing-friendly and less pejorative--dumb vs. intelligent--term). The primary benefit to IT includes reduced administrative burdens, since trying to upgrade, provision and manage thousands of desktops can be a real hassle. The challenges of VDI from an IT perspective are security, downtime (if not running a clustered file system), and just the general complexity and high initial costs of VDI purchase and deployment.

Fundamentally, the physical infrastructure of a data center with servers, such as blade servers, networking, such as Ethernet, and storage, such as the use of Fibre Channel SANs, is not designed to handle VDI deployments that can easily run into thousands of users. Trying to apply VDI software tools on an existing infrastructure runs into a wide range of technical issues that essentially make scaling of VDI untenable within its necessary performance requirements. For example, a single LUN on iSCSI or Fibre Channel SAN storage can handle only up to 64 virtual machines/users. Moreover, a key question to ponder is whether the infrastructure can handle the I/O demand patterns that VDI requires. Hint: The answer is likely no.

The requirement then is to create a separate, purpose-built VDI infrastructure--which is what dinCloud has done--that can be deployed as either a private or public cloud. A key part of dinCloud's success is InfiniBand. It has much lower latency than Ethernet, it virtualizes all of the network connectivity, it doesn't require a hypervisor reboot when provisioning/de-provisioning I/O to the host, and it doesn't involve the same sheer mess of cables. This is only one of many, many changes that dinCloud (in conjunction with its 20-plus dinStack coalition partners) has done to optimize for virtual desktops.

Quite frankly, IT organizations could try to roll their own, but they would have to reinvent the wheel where both the learning curve and the cost could very easily be too high. Moreover, individual organizations are unlikely to be able to have all the skills, resources or time to do the job as well. dinCloud's intellectual property (IP) is its secret sauce--allowing the company to embrace a new generation of cloud-oriented data center requirements and also making it unlikely that the company's solutions will be replicated by individual enterprise efforts.

In its purpose-built cloud, dinCloud provides the key elements of a central service for all processes, applications and data, but does not require the users to change their current way of working. But how does dinCloud provide the necessary infrastructure at an affordable cost?

The virtual desktop concept requires a bit more of an explanation since it, too, often has more than one connotation. Typically, virtual desktop infrastructures or interfaces refer to network or Internet-connected devices in which a partial or substantial amount of processing is performed or data resides in a central data center. Thin- or zero-client devices are used as endpoints to utilize these centralized resources. Yet, dinCloud doesn't use either--citing the high cost yet inability of most such devices to equal, much less surpass, the physical desktop experience many users enjoy today.

dinCloud expands the virtual desktop concept to include any personal computing device a worker uses to access information from/for his or her employer. That could be a desktop located in a company office, but it could also be a mobile device, such as a laptop or tablet, or even a smartphone. (Android support is available today, with Windows and Apple support coming.) It could also include public computers that an individual uses for a short period of time, such as those at a library or a hotel. Note that one individual may use multiple devices, and that the company may not own or control who has access to many or even most of the devices that any individual employee uses. Note also that not only do users expect to use a device at any geographical location, but they also want to enjoy an experience that reflects their needs.

In fact, user experience is critical to the overall value of any VDI solution. Recall that each device has physical (such as screen size), software-hardware (mouse vs. touch screen) and software (user interface functionality) characteristics that distinguish it. That does not mean that all issues have been solved; standard business apps such as Word and PowerPoint can be easily displayed on an iPad, but many common video capabilities (such as Adobe Flash support) available for Windows clients are not natively available on Apple's iPads or iPhones. In addition, devices must allow users to securely access information meant for them alone, such as some email (and that can be commingled between business and personal e-mail communications). Users must also be able to share common internal data (such as HR forms and documents) as well as information that is company-external, like communications with partners or customers.

The user may also make use of public communications and collaboration services (such as Twitter and LinkedIn) and information sites (such as Google searches) that may be commingled, as employees often use business devices for private use. Finally, the user should be able to personalize the look and feel of the device (what icons are displayed, what size they are, and so on). The bottom line is that each individual worker has unique requirements that must be preserved (no master clone will be allowed). Failure to respect those requirements may find users chafing at the constraints at first, but will eventually (if not much sooner) result in the business equivalent of an immune system "rejection" of the proposed system.

Obviously, dinCloud respects and preserves mandatory and inevitable requirements for uniqueness as it provides the HVD cloud-based services for businesses. If it didn't, the company wouldn't stand much of a chance. That gets us to the second connotation of the company's HVDs, where the "desktop"--including corporate data, personalized preferences and so on--actually resides securely in the cloud. Since an individual device may be lost, stolen, suffer from irreparable hardware failure, be confiscated either temporarily or permanently by customs officers, or suffer any number of other common and exotic fates, workers must to be able to quickly and seamlessly access business information using a new device. This is possible if the information is stored on a central system somewhere in the "cloud."

The only way to manage, control and provide support to all those devices is centrally in what is called a cloud. This HVD approach (not just for dinCloud, but in general) is not a nice-to-have; it is a must-have. Why? IT-as-a-service (which is often seen as the end stage of the cloud) is a chimera unless end users can have access to applications and data that they need when they need it on any device, any time and anywhere. This view of end user computing may be seen as the tail that wags the IT dog, but so be it.

Although enthusiastic in general, I still tend to be a bit conservative, so you know I have strong feelings when I say that this approach is a killer app for the cloud. Note that this is not the only use of the cloud (as previously mentioned) nor the only possible killer app. Nor does it mean that dinCloud is perfect and has all the answers or that others might not have or be able to come up with attractive solutions. What it should say is that dinCloud has addressed an issue that is of critical importance and that others would do well to do the same.

Rather than businesses and employees having to adjust their habits and expectations according to the limitations of a given technology/device, dinCloud offers a common infrastructure that allows multiple classes of technology to seamlessly support the needs of the business and its employees.

The dinCloud solution may be easy to describe, but it conceals the need for a rich and robust infrastructure to deliver end user-centric computing as a service. The dinCloud architecture looks somewhat like a next-generation data center with all its various virtualized servers, networking and storage capabilities. The architecture deals with security, data protection and disaster recovery issues in a way that dinCloud feels provides a very secure (solving common concerns that otherwise cloud the cloud) solution, as well as one that is highly available (because the infrastructure has to provide a mission-critical, enterprise class level of reliability).

How in the world is a young company like dinCloud able to do all this? Because it has facilitated the creation of an ecosystem called the dinCloud Coalition. For example, NetApp provides the storage infrastructure that supports data, information and storage management capabilities, including snapshots and disaster recovery. Trend Micro provides its security capabilities. Microsoft is another close partner that is working closely with dinCloud and with other partners in the coalition (such as Cisco and NetApp) to improve existing technologies, including cloud protocols, that can further improve performance.

Now, you can see the benefits to dinCloud from working with established (and sometimes much, much larger companies) in that it doesn't have time to invent all of the infrastructure technology wheels on its own and it can use the enterprise-class capabilities of its partners in the ecosystem. But the question might be why would the larger partners, such as Microsoft, want to participate (in more than an "I'll lend you my name so that you can say that you work with me" partnership)? The reason is that dinCloud's solution preserves the Microsoft hegemony as Microsoft Exchange (and other Microsoft products) can be used in the central cloud just as before and there is no incentive to switch to competing applications. Moreover, dinCloud can run Windows apps on non-Windows devices, such as Apple's iPad and Android tablets.

An ecosystem works well if each partner clearly sees its self-interest today and no threats to that self-interest in the future. For the other partners, dinCloud provides a valuable service in facilitating and gluing a very complex infrastructure together. These partners will ride the rising tide if the dinCloud solution takes off. Note that dinCloud works with service providers to provide its service rather than trying to manage all clouds themselves, and the company states that even at this early stage, 98 data centers in 39 locations use the dinCloud service.

Still, even if the infrastructure works as advertised, could there not be some other problems? The answer is yes, but, if so, they are not obviously intuitive. dinCloud feels that its solution scales as needed, but the question of latency arises. When a user is working with data and applications that may be physically housed thousands of miles away, are there any latency delays that might range from simple annoyance (noticeable delays in response time to response time sensitive requests) to total frustration in not being able to perform a given task? dinCloud emphatically states that latency is not an issue. Coast-to-coast latency over the Internet is only 120 ms, so connecting the purpose-built dinCloud to the public network known as the Internet is not a problem. (For example, recently I downloaded an iPad2 app from another company that demonstrated the use of medical images over the Internet from a distance of thousands of miles, and there was no apparent latency issue.)

A key remaining issue is price. Given the breadth and depth of the infrastructure required and the players involved, how much does the service cost? dinCloud offers the HVD service for $65 per month per user for use of the full infrastructure. By doing so, a customer's IT investment changes from a capex (capital expense) model to an open (operating expense) model, which makes life easier for IT in the budgeting process.

Is that a good price? The answer is that this is a much lower price than is typically quoted. So how can dinCloud do it? Economies of scale (where quantity discounts are obtained for larger volumes) and the famous Boston Consulting Group's learning curve model (where costs per unit supplied go down because of learning how to do things better) applies, but there is more than that. The price of computing and storage is still plummeting. Wouldn't $65 for a single month be enough to pay for protected storage for a single user for a long time? So there are ways to cut costs, and dinCloud has apparently found them.

Many (if not most) of us may feel about the cloud similar to how Mark Twain felt about the weather: "Everybody talks about it, but nobody does anything about it." While we shouldn't go to that extreme (as there is a lot of action happening in cloud), we might wonder if there can be any way to inspire more action and less talk. Well, dinCloud has shown some action in an unexpected area.

On the surface, one might not consider the subject of HVDs as being a primary candidate for the cloud, and while I don't want to indulge in hyperbole, it could very well become a killer cloud application. That is because the raison d'etre of the cloud is IT as a service, and that is not possible if the user cannot access the same applications and data whenever and wherever necessary across multiple computing devices. And that is possible only if a public cloud (a central data center available via multiple networks) is part of the deal.

dinCloud's solution is of value to three key constituencies: to IT, which can't cost-effectively manage the end user computing revolution on the way to providing IT-as-a-service in the cloud without a purpose-built solution like this one; to end users, who need this type of solution so that they can have it their own way, using their own computing devices anywhere at any time; and to CFOs (that is, the bean counters), who have a solution that saves the company money while users have smiles instead of complaints about what they had to give up.

Now, dinCloud may not have the only solution (as it is unlikely that any company offers anything totally unique) for personalized employee computing, but with HDV it has thrown down a gauntlet competitors will have to take seriously.

At the time of publication, dinCloud was not a client of David Hill and the Mesabi Group.

Juniper's QFabric, in a nutshell, distributes the traditional chassis switch into discrete components. The top-of-rack (ToR) switches, called QFNodes, are line cards. The QFinterconnect, which the QFNodes are connected to via OM-4 or OM-5 fiber, is the back plane, and the QFdirector(s) are the supervisors (in Cisco parlance), or managers. Each QF node is connected to between two and four QFInterconnects via 40-Gbit links, and there are two QFDirectors that are connected to QFNodes and interconnect via an out-of-band 1-Gbit link.

Greg Ferro, who does network design and consultation for large organizations and also contributes to Network Computing, has written a nice explanation of QFabric and explains some benefits.

Here's why I like it. It's operationally simple. The distributed chassis metaphor is apt and means that multi-switch management is greatly simplified. You can manage up to 128 switches as if they were a single switch, which for all intents and purposes, they are. Think about that for a moment. You don't have to maintain credentials across 128 switches or authentication configuration if you are using RADIUS or some other authentication server.

You don't have to integrate 128 devices into your network management system (NMS), hypervisor management system or other IT systems. Even with scripting or an NMS, making sweeping changes to 128 individual switches in a network is dicey. Granted, you can aggregate multidevice management to simulate a single pane of glass, but that means introducing more servers and management protocols that can get in the way or breakdown. As the number of things you need to manage grows, the simpler your management framework needs to be.

Traffic-wise, you don't have to worry about multiple paths, spanning tree, building N-tiers, or deciding where to set-up routing since QFabric also routes (although Juniper is quick to point out that you likely wouldn't replace your edge or core router with a QFabric, just like you wouldn't replace them with a 1U ToR L2/L3 switch). Any two points in the QFabric is a mere 5 microseconds away. Unless your company requires ultra low latency, anything below 1 millisecond (typically, the granularity that latency is measured and reported in enterprise switches) is probably fine. But, hey, less is better in any case. If you need more capacity at the edge, you can add additional switches fairly cost effectively, as Ferro points out.

Bear in mind that, currently, each QFNode 3500 can be oversubscribed at 3 to 1, based on 48 10-Gbit ports facing the access devices and 4 by 40 gigabit uplink ports facing the QFInterconnects. 480 Gbits inbound going into a 160-Gbit uplink makes 3-to-1. However, engineers at Juniper said the limitation today is the interface speed of the uplink ports. There is no limitation to the QFInterconnect, so speeds can increase in the future provided Juniper ships QFInterconnect cards and QFNodes that support higher capacities.What gets interesting with QFabric is the migration path to and from QFabric, and how QFabric can fit into the data center. In a fit of whiteboard craziness, we mapped out some scenarios. A couple of things come clear:

• To the rest of the network, QFabric is just a L2/L3 switch. It's one bridge in a spanning tree, and outside QFabric, it's just Ethernet. That means you can plug a QFfabric into the rest of your network and it will be loop-free.
• All the rest of your L2/L3 network will behave just fine, and you can run any other network equipment, like a Cisco Nexus side-by-side.
• Any requirements such as reaching hosts defined by routes on an external router or passing traffic through a load balancer mean traffic many have to pass out and back in to QFabric.

If you have already invested in Juniper's QF 3500s, the EX line is not supported and you want to migrate to QFabric, you need a QFInterconnect and a QFDirector, although Juniper recommends pairs for redundancy. You can cable to your existing QF 3500s and they become part of the Qfabric. Take them out of the QFabric, and they become l2/L3 switches. Pretty nice investment protection.

I like it. QFabric is a fairly simple design—simple is good. No need to worry about mutlipath Ethernet protocols like TRILL, SPB, LAG or MLAG. It only scales to 6,144 10-Gbit ports with over subscription, 2,048 if you want non-blocking (that's 16 10-Gbit ports per QFNode). If you dual-home your servers, that only 3,072 servers. I say only tongue in cheek. That's a lot of servers for most organizations, and I will go out on a limb and assume that if you're looking at that kind of scale, it's either a special-purpose computing center or a hosting or cloud provider.

The other elephant in the room is cost. That's a topic I will take up later, as well as digging a little deeper into the design scaling issues. Of course, there are a number of other things to consider, like distance limitations of the OM-4 cable, cable layout and designing the L2/L3 network within QFabric. But if you are looking at upgrading from a 1-Gbit to a 10-Gbit network and you want to take advantage of the new features that network fabrics such as Brocade's VCS, Cisco's Fabricpath and Juniper's QFabric offer, it's worth a long hard look. And I bet the proprietary features will be less important the deeper you look.

Disclosure. I traveled to Sunnyvale on my company's dime. Juniper fed me a hamburger, chips and a soda, and gave me a pen.

While it's always fun to be able to drive the conversation deep in the interactive briefings that are the core of tech days, I was already familiar with most of the HP storage lines, having worked with several of them. However HP did manage to bring out a few products that piqued my interest.

HP has decided to focus most of its storage development on what it's calling "converged storage," which primarily means that products from Lefthand iSCSI arrays to iBRIX scale-out NAS and StoreOnce backup appliances are implemented as applications running under a common Linux kernel on x86 server hardware. This approach combined with HP's broad server portfolio lets HP offer systems with an interesting mix of packages, like the P4800 Lefthand that combines blade servers and HP's high-density MDS600 shelf that crams 70 3.5-inch drives in just five rack units by using pull-out drawers.

The storage guys even have a neat little package all their own. The X5000 G2 NAS runs a Windows Storage Server cluster in a 3U package that holds two BL460 blades. The blade's SmartArray controllers are connected to 16 internal drives on a pull-out drawer, and maintain cache coherency like a modular SAN array to provide shared storage for the Windows cluster. Since WSS can host virtual server guests with Hyper-V, the X5000 chassis could be all the compute infrastructure a branch office needs.

The bloggers in the room all agreed we'd like HP to offer this server package for additional applications, such as SQL Server clusters or VMware hosting. Personally, I think there's a market for a Proliant version of the X5000 chassis.

We also took a deep look at the StoreOnce B6200 backup appliance. Holding up to 768 Tbytes of disk and ingesting 28 Tbytes per hour, the B6200 is HP's home-grown entry into the heavyweight ranks of the deduplicating appliance market that HP's been using OEMed Sepaton VTLs to address. The B6200 combines StoreOnce's deduplication engine with the iBRIX file system and data distribution technology. Up to four redundant pairs of controllers can be managed as a single system, but backup targets, and therefore deduplication realms, are constrained to a single two-node cluster. While StoreOnce may not have the mindshare of some of the other deduping appliances, it's No. 2 in the market, in no small part because of HP customer loyalty.

For me, the best part of the event was the lab tour--not just because it's the biggest data center I've been in for a long time, at 50,000 square feet with racks of servers and storage as far as the eye could see, but because it's an HP Labs test site dedicated to exploring how to reduce data center power consumption.

As you would expect for a green data center, HP has kept the cold aisles at 72 degrees and used hot aisle containment to keep hot air from recirculating back into server inputs. While one would assume that free air cooling would be a good solution high in the Rockies, it turns out that the dry air year-round makes evaporative cooling a better bet. When we were there, the outside temperature was about 50 degrees and the chillers weren't needed at all.

HP also manages to avoid the 10% to 30% overhead of power conditioning equipment like UPSes. Since this is a lab, not a production data center, the HP folks have made the decision that the projected outage costs of downtime don't justify the additional cost of backup power. They've even built cool vented tiles for their raised floor that have remotely controlled motorized dampers. When the computer that monitors the whole place, through a 3D interface that frankly gave me a momentary CA Unicenter flashback, sees a hot spot, it can open the dampers further--a better solution than just adding more vented tiles and running the blowers faster to move air everywhere.

HP's tiles are a project of HP Labs and not commercially available. The closest I've managed to come is Tate's SmartAire.

Our host, Calvin Zito, made a video of a previous lab tour that's on YouTube.

While HP is a client of DeepStorage.net, the trip was not conditioned on my blogging, tweeting or otherwise mentioning Tech Day. HP paid all my expenses for Tech Day, including airfare, hotel and meals.