It’s difficult to put into words how exciting, and how overwhelming the idea of moving to a virtualized infrastructure was for me. In 12 months, I went from investigating solutions, to presenting our options to our senior management, onto the procurement process, followed by the design and implementation of the systems. And finally, making the transition of our physical machines to a virtualized environment.
It has been an incredible amount of work, but equally as satisfying. The pressure to produce results was even bigger than the investment itself. With this particular project, I’ve taken away a few lessons I learned along the way, some of which had nothing to do with virtualization. Rather than providing endless technical details on this post, I thought I’d share what I learned that has nothing to do with vswitches or CPU Utilization.
1. The sell. I never would have been able to achieve what I achieved without the support of our Management Team. I’m an IT guy, and do not have a gift of crafty PowerPoint slides, and fluid presentation skills. But there was one slide that hit it out of the park for me. It showed how much this crazy idea was going to cost, but more importantly, how it compared against what we were going to spend anyway under a traditional environment. We had delayed server refreshing for a few years, and it was catching up to us. Without even factoring in the projected growth of the company, the two lines intersected in less than one year. I’m sure the dozen other slides helped support my proposal, but this one offered the clarity needed to get approval.
2. Let go. I tend to be self-reliant and made a habit of leaning on my own skills to get things done. At a smaller company, you get used to that. Time simply didn’t allow for that approach to be taken on this project. I needed help, and fast. I felt very fortunate to establish a great working relationship with Mosaic Technologies. They provided resources to me that gave me the knowledge I needed to make good purchasing decisions, then assisted with the high level design. I had access to a few of the most knowledgeable folks in the industry to help me move forward on the project, minimizing the floundering on my part. They also helped me with sorting out what could be done, versus real-world recommendations on deployment practices. It didn’t excuse me from the learning that needed to occur, and making it happen, but rather, helped speed up the process, and apply a virtualization solution to our environment correctly. There is no way I would have been able to do it in the time frame required without them.
3. Ditch the notebook. Consider the way you assemble what you’re learning. I’ve never needed to gather as much information on a project as this. I hated not knowing what I didn’t know. (take that Yogi Berra) I was pouring through books, white papers, and blogs to give myself a crash course on a number of different subjects – all at the same time because they needed to work together. Because of the enormity of the project, I decided from the outset that I needed to try something different. This was the first project where I abandoned scratchpads and binders, highlighters (mostly) and printouts. I documented ALL of my information in Microsoft OneNote. This was a huge success, which I will describe more in another post.
4. Tune into RSS feeds. Virtualization was a great example of a topic that many smart people dedicate their entire focus towards, then are kind enough to post this information on their blogs. Having feeds come right to your browser is the most efficient way to keep up on the content. Every day I’d see my listing of feeds for a few dozen or so VMware related blogs I was keeping track of. It was uncanny how timely, and how applicable some of the information posted was. Not every bit of information could be unconditionally trusted, but hey, it’s the Internet.
5. Understand the architecture. Looking back, I spent an inordinate amount of time in the design phase. Much of this was trying to fully understand what was being recommended to me by my resources at Mosaic, as well as other material, and how that compared to other environments. At times, grass grew faster than I was moving on the project at the time, (exacerbated by other projects getting in the way) but I don’t regret my stubbornness to understand what was I was trying to absorb before moving forward. We now have a scalable, robust system that helps avoid some of the common mistakes I see occur on user forums.
6. Don’t be a renegade. Learn from those who really know what they are doing, and choose proven technologies, while recognizing trends in the fast-moving virtualization industry. For me there was a higher up front cost to this approach, but time didn’t allow for any experimentation. It helped me settle on VMware ESX powered by Dell blades, running on a Dell/EqualLogic iSCSI SAN. That is not a suggestion that a different, or lesser configuration will not work, but for me, it helped expedite my deployment.
7. Just because you are a small shop, doesn’t mean you don’t have to think big. Much of my design considerations surrounded planning for the future. How the system could scale and change, and how to minimize the headaches with those changes. I wanted my VLAN’s arranged logically, and address boundaries configured in a way that would make sense for growth. For a company of about 50 employees/120 systems, I never had to deal with this very much. Thanks to another good friend of mine whom I’d been corresponding with on a project a few months prior, I was able to get things started on the right foot. I’ll tell you more about this in a later post.
The results of the project have exceeded my expectations. It’s working even better than I anticipated, and has already proven it’s value when I had a hardware failure occur. We’ve migrated over 20 of our production systems to the new environment, and will have about 20 more up online within about 6 months. There is a tremendous amount of work yet to be completed, but the benefits are paying for themselves already.
vmpete.com 