Let’s start the new year right with one of my current favorite topics for discussion: automation. In this article, I concentrate on the second-day operations type of automation. Second-day operations is quite a different beast from build and decommission automation, in that it incorporates several different approaches to automation.
Articles Tagged with Performance
In the world of virtualization storage it seems all we talk about lately is flash and SSD. There is a good reason for that. Traditionally, storage capacity and storage performance were directly linked. Sure, you could choose different disk capacities, but in general you needed to add capacity in order to add performance because each disk, each “spindle” could only support a certain number of I/Os per second, or IOPS. This was governed by the mechanical nature of the drives themselves, which had to wait for the seek arm to move to a different place on disk, wait for the seek arm to stop vibrating from the move, wait for the desired sector to rotate underneath the read head, etc. There’s only so much of that type of activity that can be done in a second, and in order to do more of it you needed to add more drives. Of course that has drawbacks, like increased power draw, more parts so more chance of failure, and increased licensing costs since many storage vendors charged based on capacity.
Flash memory takes most of what we know about the physics of storage and throws it away. Because there are no moving parts, the act of seeking on a solid state disk is a completely logical one. There are no heads, no sectors, no rotation speeds. It’s all the speed of light and however fast the controller can go. As such, flash memory can do enormous numbers of IOPS, and if implemented well, it decouples storage performance from storage capacity. You save power, you save data center space, you save money in licensing fees, and your workloads run faster.
The previous post Secure Mutli-Tenant Virtualization – How to get there?, was only concerned with Infrastructure as a Service however the new announcement from VMware SpringSource and Google leads to one of the first Platform as a Service that has simplified the motion of applications between different cloud providers, provided the basis for the application exists within the environment. That basis is Spring. Applications built on Spring can now run on Google AppEngine, VMware Clouds such as VMforce, VMware vSphere infrastructures, and other participating clouds.
This is a Wow! moment for the adoption of Java based PaaS Cloud as any real kind of interoperability across these clouds has been lagging by a large margin. For PaaS and Applications built using the Spring PaaS a solution has been found.
When using virtualization technology system administrators have a lot of tools available to make our day-to-day operation and administration of our environments easier to work with and speeds up the time it takes to do a lot of administration tasks. Take for example, the ability we have to add resources to a virtual machine. You can add processors, memory and or increase disk space within a matter of minutes and very little downtime. On a physical host you would need to purchase the hardware first and wait for it to arrive and then schedule the downtime to add the resources to the machine. This speed and power can be both a blessing and a curse. Once application owners understand how easy it is to add resources to the virtual machines then comes the requests for additional resources any time the application owners think there is the slightest bit of need for any additional resources.
We have a series of posts (SpringSource/VMware, 3Tera, Eucalyptus, Hadoop/Cloudera…) about the application directly targeting a distributed virtual machine which is abstracting over the virtualization layer and/or operating system. Essentially these are targeted at those who are building or adapting applications for the cloud, rather than starting from the premise of a virtualization of existing infrastructures.
It must be said there is no clear model yet emerging for how you do this. The 3Tera solution is slick and allows you to define your infrastructure at a logical (application) level and grow or shrink your architecture graphically on commodity hardware, but ultimately there are limits to the horizontal scalability of the layers in the architecture that comprise your application. When we last looked at Eucalyptus it was driving in a similar direction with packaged VMs and its own scalable filesystem but wasn’t really dealing with the tiers of an application as logical entities.
We recently received a presentation on a combined solution from Eucalyptus and Terracotta. Initially we were suspicious because they clearly share an investor – Benchmark Capital. Was this a PowerPoint integration dreamt up by two Venture Capitalists over a power breakfast? However, the combined solution was presented by some very plausible techies with a real-live demo and does look as though it starts to provide a generally-useful abstraction over which to deploy scalable applications (specifically Java stacks), and it too works with commodity hardware. It’s not as slick as the 3Tera solution, more of a command-line approach, but it potentially has the edge in scalability.
I recently got called to examine some performance issues that were happening to a VMware VDI Cluster. I was told all the hosts in the cluster would run at 100% CPU utilization for an extended period of time and the client would like an explanation and recommendation. I pretty much had a good idea what the problem was before I ever started looking at hosts. I know this topic has been covered many times before but it does not seem like it has been covered enough.