VMware Fundamentals Part 3

As I am on my flight to EMC World in Las Vegas, I can think of no more appropriate time to write about storage in a virtual environment.

Starting with the basics. Since we are dealing with VMware, we have several options available to us. To set the proper foundation, I would like to give a little thought on each one.

    Fiber Channel
    Fiber Channel over Ethernet (FCoE)

First of all, we need to group our protocols. The first three are block protocols. This means nothing more than the storage is presented at a block level which is to say it appears to be local to the host. Think of this very similarly to the hard drive in your laptop or desktop, only it lives somewhere else and is presented through a network protocol.

The NFS protocol is a *nix protocol which is used for file sharing. This is similar to a windows file share, if you go to a \\\ this is very similar to NFS.

On the block protocols, each has its own advantages and disadvantages. First of all Fiber Channel. This is an old protocol, used in many enterprise environments. It is currently spec’ed at 2,4, and 8 gbps. This is essentially sending the scsi commands over a fiber optic network. It is very fast, very efficient, and relatively expensive. It requires special adapters in the host server, as well as special fiber channel switches, and expensive fiber optic cable. The performance is good since it is a transport protocol, and dedicated to only one task.

FCoE is a newer protocol, designed to allow us to move to converged networks. This is typically run over one or more 10gbps connections. Modern implementations of this protocol run over a converged network using QOS and Storage and Network I/O control to provide maximum performance. The concept is similar, Fiber Channel, but does not require dedicated infrastructure. This also allows for backwards compatibility with legacy FIber Channel Networks.

iSCSI is not new, but is very enticing as a block protocol in the VMware environments. Operating at Layer 3 on the OSI model as opposed to Layer 2 as FCoE, there is a bit more overhead associated with iSCSI, but not enough to rule it out in a majority of environments. With the advent of 10GBe networks, we are now able to use iSCSI in a converged network similar to FCoE.

NFS stands out as very different. In the previous protocols, we use a dedicated network, or a subset of a converged network to present the storage using a block protocol. In the case of NFS, we use a file protocol. With the block protocol, we are present the storage and let VMware take over. With NFS, we present a file share. By definition, this must have an operating system on it already. VMware can take this file share and place the Virtual Machine files on it, and run as though it were a native and local file system.

Logically presenting a block protocol should be faster and more efficient, the OS get’s to manage the storage and handle everything internally. This is not always the case though. FCoE is the most efficient block protocol since we run it over a 10GBe network, and the protocol gives us more freedom than a native Fiber Channel Network. NFS on the other hand is simply a large open file. Rather than performing block writes, the NFS datastore is written as though it were a large open file. No write a block, write a block, write a block, as we find in the block based protocols.

So which protocol is best? Well the answer is as always, it depends. For Microsoft Exchange, and a few other applications, we have to use a block protocol for support reasons, though there is no performance impact and we expect this to change soon. For the majority of deployments, I recommend using NFS, with iSCSI for block requirements. If there is a specific need we can fall back to the Fiber Channel or FCoE protocols, but those are very specific use cases in very large environments. The additional advantage to NFS is simplicity of expansion, and it’s ease of deployment.

At the end of the day there is no right or wrong answer, but generally speaking multiple protocols are always nice to have.

VMware Fundamentals Part 3

VMware Fundamentals Part 2

A little behind, but better late than never. In my last post I covered the basic layout of VMware in modern terms.

Clustering in a VMware environment provides us with a number of benefits. The first of course is high availability. High availability simply put means if one host server dies, the virtual machines on that host are restarted on another host. This is excellent as it allows us to minimize downtime. Of course this feature in addition to a majority of the other excellent features in VMware require shared storage, but that is a post for another day.

If we can tolerate zero downtime, we can use the additional feature, Fault Tolerance. This enables us to have two virtual machines running in a master/slave configuration so if one dies the other picks up where it left off with no downtime. This is nice but it comes with a number of limitations and at significant cost since it doubles the number of virtual machines in use and thus the amount of resources required.

One of the coolest tricks, in my opinion, about VMware though is vMotion. We can actually take a live virtual machine, and move it between physical hosts without interruption, provided we have properly configured our network. This is excellent because it allows us to automate this process to keep the physical hosts balanced by moving live virtual machines around to ensure no one host is overloaded.

Taking it yet a step further, we often have multiple datastores in VMware. This is done to reduce contention on the file systems since we are seeing larger and larger deployments, with more and more virtual machines. Storage vMotion allows us to move the disk of the virtual machine between datastores. With the release of vSphere 5 we can now even automate this portion through clustered datastores, but that is again a topic for another day.

Migrating a virtual machine whether the live state, or the virtual disks is as simple as either dragging the virtual machine to a new host, or right clicking the virtual machine and selecting migrate.

Next post I plan to cover a little on the storage side, about how we configure datastores, and hopefully demystify why we chose different protocols in a VMware environment.

VMware Fundamentals Part 2

Choosing the right product

Today I am going to write about something which a number of my customers are currently experiencing. Vendor selection, or rather technology selection, is critical. Choosing the right virtualization and storage solution is not so simple as it used to be. With the number of new technologies available to us, it is difficult to determine what is best. So how do you decide, and which products should you use to virtualize your environment.

To be fair, this is a blog about EMC and VMware products, but at the same time, I want to be clear, I am writing this as a consultant, with a fairly agnostic mindset, I just happen to like those products best in general.

So a client I am working on currently now, purchased an excellent backup solution. They are running vSphere, and are very happy with it, we are getting ready to move them to vSphere 5 from 4.1, and we are working to implement some best practice changes. Unfortunately, prior to our involvement, they bought a storage array from a vendor. The sales rep came in and told them what they needed without actually doing any design work, or looking at their environment. The performance was acceptable, but the Implementation, again done by the vendor, did not even follow their own best practices. When the client engaged us, we immediately looked at the issues, ran some tools to get a baseline, and made a list of recommendations.

As we have begun to implement the recommendations, we have found there are more issues which continue to arise. The storage is not properly designed for the I/O profile. The limitations on the vSphere design is creating a number of problems which we are having to work around. The network is was not properly configured, by the vendor who sold it to them.

So what is the point here, and how does this relate to EMC/VMware? I cannot emphasize enough the value of having a good consultant, even if you get the right vendor. Beyond that, understand your environment and be up front about it. Understanding your I/O patterns, your network load, your processing requirements are almost always the difference between a successful deployment and what we like to refer to as a Resume Updating Event. I am not saying if you hire me, or bring in EMC/VMware, everything will be perfect, I am saying rather make sure you have someone working on your environment you trust. Don’t ever trust a sales person, question them, make them explain all your questions. Factor in things like additional load from backups, look at your 5 year outlook, what might you implement in the future.

The landscape is changing, think about what vendor is going to be able to keep up with your needs, and what you are trying to accomplish. At the end of the day, no one ever got fired for asking questions of their vendors. If they can’t answer them and won’t get you answers, be very cautious about that vendor.

Choosing the right product

Phases of Virtualization

Often times we hear from our customers, about how they are approaching virtualization. Most of the people I talk to are somewhat virtualized, and often times, from an IT perspective they consider themselves to be fully or at least mostly virtualized. We have learned to ask, what does fully virtualized mean to you? This is the million dollar question. The typical response is something about everything that can be virtualized is virtualized. This is the question I would like to explore.

To lay the groundwork for this, there are about 5 common phases of virtualization.

Phase 1 is typically just setting up some test servers and virtualizing them with local storage using free software. This is the introductory phase.

Phase 2 typically involves moving the development or test environments, depending on the companies line of business, but these are non-IT test servers typically.

Once IT gets comfortable with this phase they are then ready to move on to Phase 3. This typically involves virtualizing the things IT has complete control over, domain controllers, maintenance and monitoring servers, and sometimes even email.

This is one of the most common places for what we have begun to term virtual stall. Getting the business to trust virtualization is typically a challenge. The concept sounds good, but the risks seem high. This is where it takes a good consultant to help bridge the gap between the technical team and the business units.

Phase 4 typically is where we begin to move business critical applications. This is where VMware on the VNX really begins to shine. While I really like competitive products, Netapp’s FAS line, Hitachi’s AMS, and some of the others, EMC has really helped us out here with not only by finally introducing unified storage, but by giving us the option for storage tiering and additional caching options. I plan to go into more details on this in a future post, but suffice it to say this is an incredible benefit for virtualizing mission critical high resource demanding apps.

Finally, the holy grail of virtualization. Phase 5 is IT-As-A-Service enables end users to generate their own servers through a simple web interface such as vCloud DIrector, or similar software. This is really where we want to get so IT can get back to playing World of Warcraft, or doing more behind the scenes work rather than always focusing on processing user requests.

This is a brief overview of the VMware/EMC “Journey to the Cloud”, but this is important for us to understand. Virtual Stall is a real problem, and should be addressed to prevent wasted money and resources. As budgets shrink, EMC and VMware continue to give us new and innovative solutions to make our business more agile.

Phases of Virtualization

Micro Niche

Hello World! For anyone who has written code, that is something which will be quite familiar, something which should bring a smile, or a grimace depending on your experience. This is the beginning of a new foray into blogging for me, hopefully, this time a bit more focused one. A brief note about the name and title of this blog. Carpe Diem is of course Latin for Seize the Day. CarpeTech is a shameless ripoff, to grab your attention and point you to the title. I truly want technology to enable business, and be a positive thing for businesses, thus Seize the Technology, make it work for the business.

A bit about me, I am a Senior Datacenter Consultant for a EMC and VMware partner in the Pacific North West. Basically that means I love to talk about technology, and generally speaking about EMC and VMware products. In honesty though I am interested in evangelizing technology on a much broader level, products are commodities, some better than others, though the purpose of this blog is to focus around those two specifically. As a standard disclaimer, my opinions are my own and do not necessarily represent the positions of my employer, EMC, or VMware. I welcome feedback and if necessary correction. I strive for honesty and integrity in everything, so please feel free to take me to task if you feel I am in error.

So why Micro Niche. A friend and colleague recently told me that it is not enough to find your niche, but we need to find a micro niche. There are more than enough virtualization blogs, or storage blogs, it is time for consultants to start differentiating themselves. While we are always a jack of all trades to a certain extent, mostly due to our love of technology, we all have something that we are passionate about.

All this being said, I plan to focus on VMware vSphere best practices specifically on the EMC VNX product line. Now I know that Chad at Virtual Geek covers this space quite effectively, but he also covers many other topics. I hope to bring an outsiders perspective, with many links to his and others postings with a bit of my own perspective on things. So thanks for reading, and hopefully this provides some value to the community in general and specifically to the customers I work with.

Micro Niche