Chuck: Great observations about trust in the cloud. I would also submit that CSC's Trusted Cloud Orchestration strategy is another viable means of achieving the desired degree of visibility into the operation of cloud services. Our approach is documented here: http://assets1.csc.com/cloud/downloads/Knode_digital_trust_in_the_cloud_final_090709b.pdf The author Ron Knode is active in cloud standards development with a particular emphasis on IT Security (although CSC's cloud ourchestration vision is a superset of more than just IT security, audit and compliance functions). CSC's vision of this "Trusted Cloud" is summarized as follows: "What we desire is nothing less than a trusted cloud – i.e., a cloud that harmonizes the security for transactions and data with comprehensive transparency of control and result, such that it conveys evidence-based confidence that systems within its environment operate as advertised, and that no unadvertised functions are occurring." It is a pretty cool vision and I am heartened by our progress in instantiating key components of it as we develop our Orchestration Core. Thanks again for an interesting and timely posting. ~Randy

A couple of thoughts on the whole NetApp vs EMC as a Virtual Infrastructure storage back end Twitterstorm of Thursday night. Let me start off with this disclaimer. I am speaking only for myself and not as a representative of CSC management. Furthermore, let me also say that both EMC and NetApp are valued alliance partners for CSC and we do good business worldwide with both parties. I must confess a bias towards NAS storage for Virtual Infrastructures as opposed to Block access protocols. I believe that the abstraction of NAS greatly reduces the amount of administrative effort required to configure and support the VMWare storage environment. There are fewer places where defects (misconfigurations) can be injected in the process and therefore reliability is higher. Working for a service provider, I want simple, reliable and cheap. Because you are dealing with objects in a file system, there are fewer administrative touches required. The overall level of staff training can be lower. Properly engineered, NAS should generate a cheaper overall virtual infrastructure than one based on shared storage connected via a SAN. Although I hear that FC performance has been improved in vSphere, in ESX 3, NFS demonstrated superior performance characteristics under higher concurrent I/O workloads with more graceful degradation as more VM-s were added. NFS was only edged out in raw throughput by FC when a single virtual machine was running. There are workloads where FC is the right choice, but the vast majority of VMWare workloads work just fine on NAS. With NAS, there is no need to go for FCoE in order to get to a converged datacenter network fabric: you already have one in your existing data center LAN. Everyone’s mileage varies, but most “average” VM-s in our environments seem to generate on the order of 25 I/O-s per second at 8KB block sizes. If you multiply these rates by 320 (or more) virtual machines in a single blade chassis, our experiences bear out Chuck’s statement that (paraphrased) spindle count will be the biggest determinant of how the back end storage performs at these I/O densities. Flash Drives and FAST-like in box tiering will be welcome improvements (shoutout to AmberRoad ;-) ), but Cache or Flash drives are still comparatively scarce resources that can eventually be saturated. I think the number of spindles will still matter going forward but perhaps not as much as today. As to the dread “boot storm”, CSC designed its first iteration of Dynamic Desktop (VDI) infrastructure around NetApp with Cache (PAM) accelerator boards. Chuck implied that the cache memory would be prohibitively expensive, but we found that the additional cost of the cache was far offset by the 5X scaling factor we were able to get. So in our case, paying for the additional cache was a significant net cost saving to us. For me, the critical attributes of VI back-end NAS storage are as follows: 1) Writeable snapshots – Create a generic, gold image of an operating system and stamp it out so there is minimal storage consumed by each new VM instance. Just the blocks with different data between images are consumed. 2) Data deduplication – As you patch each image, each “branch” of the writable snapshot will have a lot of duplicate data added to it. To optimize storage consumption, you need a process to come along behind and collapse these blocks to reclaim the duplicate space. 3) Tight integration between the storage device and Virtual Center to ensure consistent snapshots of virtual machine images in can be efficiently generated without human intervention as workload moves around the server farm and replicated (if required). In my opinion, NetApp has historically had the edge in these categories but EMC’s Celerra team is catching up rapidly. I believe that today, NetApp will likely retain a modest edge if all it comes down to is a NAS functionality shootout with Celerra for the VI back-end. But that is not the ground that EMC is choosing to fight the battle for long-term VI back-end supremacy on. Far more worrisome for NetApp it seems to me is that EMC is positioning itself to leapfrog NetApp in terms of fundamental enabling technologies on a couple of fronts. First, EMC has acquired FastScale. And that technology takes DeDupe to a whole new level for VMWare. Will there be teething pains? Of course, but for Virtual Infrastructures, this technology works at a much higher level and yields memory savings in additions to disk space reductions. This will be pretty cool if EMC can get the price and reliability right for this technology. Chuck has circled back a bunch of times on the barriers to vApp mobility. Data movement is the big problem he keeps coming back to. I have seen a spate of recent posts of his on the subject. Solving this is key to getting VMWare’s vCloud world off the ground. ATMOS is certainly looking to handle the lower I/O tier apps and aspires to be the file/object store of choice in the vCloud that can facilitate workload mobility and be a persistent object store. But what about distributed storage for high performance block applications like data bases that need to move between datacenters in a hybrid cloud? What about VMDK mobility? There is still a gap in the technology to address these high I/O needs and really permit the vCloud ecosystem to take off. I have to believe that given the increasing levels of cooperation and integration between VMWare and EMC (compared to the past) that EMC will be well positioned to leverage or influence development of new hypervisor capabilities to address this high performance cloud I/O functionality gap. Since the hypervisor knows about “dirty” blocks and I/O hot spots it is probably the layer best positioned to exploit shortcuts to keeping VMDK or vApp images in synch over a distance. To me, this seems to be the logical place to start looking at optimizations. That doesn’t preclude NetApp or other storage vendors from playing, but it probably means EMC will be first to market with a comprehensive set of solutions across all classes of I/O workloads in the vCloud. It also probably means that NetApp’s traditional strength in terms of efficient, low-cost distance replication will be to some extent be negated by a combination of hypervisor functionality, advances by network equipment vendors or refinements to array based replication targeted at virtual server environments from other storage players like EMC, IBM and HDS. For me, the questions come down to simple ones. How do new EMC and NetApp storage innovations enable me to lower the cost of delivering each virtual server instance? How do these storage technologies facilitate the widest range of vCloud application mobility? It does me no good to have cheap vCloud compute resources that are prohibitively expensive to access either because of onerous network requirements or massively expensive storage infrastructure. If the infrastructure is cheap but complex and hard to support, that does me no good either. I think bun fights over the gory technical details of today’s storage technologies (let’s face it - all of which are fit for purpose, reliable enough, perform well enough) are really proxy wars over which technical approach yields the best “real world” TCO today and whether or not the various vendor approaches will best facilitate workload mobility in the vCloud ecosystem going forward. Both companies have a good technical solutions and sound value propositions. It will be interesting to see how their different approaches play out over the next couple of years. I would welcome any comments on the above to improve my understanding of these issues. Cross posted to (http://chucksblog.emc.com/chucks_blog/2009/09/a-quick-note-on-primary-data-dedupe-and-io-density.html)

A couple of thoughts on the whole NetApp vs EMC as a Virtual Infrastructure storage back end Twitterstorm of Thursday night. Let me start off with this disclaimer. I am speaking only for myself and not as a representative of CSC management. Furthermore, let me also say that both EMC and NetApp are valued alliance partners for CSC and we do good business worldwide with both parties. I must confess a bias towards NAS storage for Virtual Infrastructures as opposed to Block access protocols. I believe that the abstraction of NAS greatly reduces the amount of administrative effort required to configure and support the VMWare storage environment. There are fewer places where defects (misconfigurations) can be injected in the process and therefore reliability is higher. Working for a service provider, I want simple, reliable and cheap. Because you are dealing with objects in a file system, there are fewer administrative touches required. The overall level of staff training can be lower. Properly engineered, NAS should generate a cheaper overall virtual infrastructure than one based on shared storage connected via a SAN. Although I hear that FC performance has been improved in vSphere, in ESX 3, NFS demonstrated superior performance characteristics under higher concurrent I/O workloads with more graceful degradation as more VM-s were added. NFS was only edged out in raw throughput by FC when a single virtual machine was running. There are workloads where FC is the right choice, but the vast majority of VMWare workloads work just fine on NAS. With NAS, there is no need to go for FCoE in order to get to a converged datacenter network fabric: you already have one in your existing data center LAN. Everyone’s mileage varies, but most “average” VM-s in our environments seem to generate on the order of 25 I/O-s per second at 8KB block sizes. If you multiply these rates by 320 (or more) virtual machines in a single blade chassis, our experiences bear out Chuck’s statement that (paraphrased) spindle count will be the biggest determinant of how the back end storage performs at these I/O densities. Flash Drives and FAST-like in box tiering will be welcome improvements (shoutout to AmberRoad ;-) ), but Cache or Flash drives are still comparatively scarce resources that can eventually be saturated. I think the number of spindles will still matter going forward but perhaps not as much as today. As to the dread “boot storm”, CSC designed its first iteration of Dynamic Desktop (VDI) infrastructure around NetApp with Cache (PAM) accelerator boards. Chuck implied that the cache memory would be prohibitively expensive, but we found that the additional cost of the cache was far offset by the 5X scaling factor we were able to get. So in our case, paying for the additional cache was a significant net cost saving to us. For me, the critical attributes of VI back-end NAS storage are as follows: 1) Writeable snapshots – Create a generic, gold image of an operating system and stamp it out so there is minimal storage consumed by each new VM instance. Just the blocks with different data between images are consumed. 2) Data deduplication – As you patch each image, each “branch” of the writable snapshot will have a lot of duplicate data added to it. To optimize storage consumption, you need a process to come along behind and collapse these blocks to reclaim the duplicate space. 3) Tight integration between the storage device and Virtual Center to ensure consistent snapshots of virtual machine images in can be efficiently generated without human intervention as workload moves around the server farm and replicated (if required). In my opinion, NetApp has historically had the edge in these categories but EMC’s Celerra team is catching up rapidly. I believe that today, NetApp will likely retain a modest edge if all it comes down to is a NAS functionality shootout with Celerra for the VI back-end. But that is not the ground that EMC is choosing to fight the battle for long-term VI back-end supremacy on. Far more worrisome for NetApp it seems to me is that EMC is positioning itself to leapfrog NetApp in terms of fundamental enabling technologies on a couple of fronts. First, EMC has acquired FastScale. And that technology takes DeDupe to a whole new level for VMWare. Will there be teething pains? Of course, but for Virtual Infrastructures, this technology works at a much higher level and yields memory savings in additions to disk space reductions. This will be pretty cool if EMC can get the price and reliability right for this technology. Chuck has circled back a bunch of times on the barriers to vApp mobility. Data movement is the big problem he keeps coming back to. I have seen a spate of recent posts of his on the subject. Solving this is key to getting VMWare’s vCloud world off the ground. ATMOS is certainly looking to handle the lower I/O tier apps and aspires to be the file/object store of choice in the vCloud that can facilitate workload mobility and be a persistent object store. But what about distributed storage for high performance block applications like data bases that need to move between datacenters in a hybrid cloud? What about VMDK mobility? There is still a gap in the technology to address these high I/O needs and really permit the vCloud ecosystem to take off. I have to believe that given the increasing levels of cooperation and integration between VMWare and EMC (compared to the past) that EMC will be well positioned to leverage or influence development of new hypervisor capabilities to address this high performance cloud I/O functionality gap. Since the hypervisor knows about “dirty” blocks and I/O hot spots it is probably the layer best positioned to exploit shortcuts to keeping VMDK or vApp images in synch over a distance. To me, this seems to be the logical place to start looking at optimizations. That doesn’t preclude NetApp or other storage vendors from playing, but it probably means EMC will be first to market with a comprehensive set of solutions across all classes of I/O workloads in the vCloud. It also probably means that NetApp’s traditional strength in terms of efficient, low-cost distance replication will be to some extent be negated by a combination of hypervisor functionality, advances by network equipment vendors or refinements to array based replication targeted at virtual server environments from other storage players like EMC, IBM and HDS. For me, the questions come down to simple ones. How do new EMC and NetApp storage innovations enable me to lower the cost of delivering each virtual server instance? How do these storage technologies facilitate the widest range of vCloud application mobility? It does me no good to have cheap vCloud compute resources that are prohibitively expensive to access either because of onerous network requirements or massively expensive storage infrastructure. If the infrastructure is cheap but complex and hard to support, that does me no good either. I think bun fights over the gory technical details of today’s storage technologies (let’s face it - all of which are fit for purpose, reliable enough, perform well enough) are really proxy wars over which technical approach yields the best “real world” TCO today and whether or not the various vendor approaches will best facilitate workload mobility in the vCloud ecosystem going forward. Both companies have a good technical solutions and sound value propositions. It will be interesting to see how their different approaches play out over the next couple of years. I would welcome any comments on the above to improve my understanding of these issues. Cross posted to (http://blogs.netapp.com/virtualstorageguy/2009/09/run-everything-virtualized-and-deduplicated-aka-chuck-anti-fud.html )