Book Review: Administering VMware Site Recovery Manager 5.0 by Mike Laverick

I’ve decided that I am going to review at least one book per quarter.  Four book reviews per year are not that much when you consider that I probably read four books (various subjects) per month.

So for my first book review of 2012, I am going to start with Administering VMware Site Recovery Manager 5.0 by Mike Laverick.  Many of you already know Mike (the guy is everywhere) or are at least familiar with his blog (RTFM-ed).

Let me start out by saying that I did not like this book after first reading it.  I felt that it was missing something; something that I couldn’t quite put my finger on.  Then it hit me.  Concepts are not necessarily discussed as concepts.  Yes, there are one/two page discussions on concepts, but most often they are discussed as working knowledge.  This should not have been a surprise to me because Mike clearly states (multiple times) that he expects his readers to have read the various manuals for detailed concept and background info on vSphere, Site Recovery Manager (SRM), your storage array, etc. He can’t teach everything needed to get SRM working so you have do some work on your own.   In other words, RTFM.  Once I came to grips with this, I re-evaluated the book in a new light and have decided that I like it.

As for the book itself, it has an interesting layout.  You get a little bit of history concerning vSphere’s DR and HA features and what SRM is, and is not.  Then comes a little detour into setting up a number of different storage arrays from Dell, EMC, HP, and NetApp.    This detour does serve a purpose in that it sets a baseline storage configuration for installing and configuring SRM, albeit in the most simple configuration possible.  It’s actually a smart move on his part because he is able to show how he setup his lab.  It also prompts the reader to go check various items in order to ensure a successful install of SRM.

Then you get to the good stuff: installing, configuring, and using SRM. There are plenty of screenshots and step-by-step instructions for doing a lot of the configuration tasks.  In fact, you could think of this book along the lines of a cookbook.   Follow along and you should end up with a usable (in a lab) install of SRM.

It’s clear that after reading this book, Mike knows SRM.  Peppered throughout the chapters are the various problems and errors he encountered as well as what he did to fix them.  In a few cases, he does a mea culpa for not following his own advice of RTFM.  If he had, a few problems would have been avoided.

Mike also hits home on a few simple truths.  For those involved with Active Directory in the early days, there was a truth that went something like this: “The question is irrelevant, the answer is DNS”.  In the case of SRM, substitute “Network and storage configuration” for “DNS”.  So many problems that may be encountered are the result of a network or storage configuration issue.  vSwitches need to be setup correctly, hosts need to see storage, vCenter needs to see hosts, etc.

I especially liked the bits of wisdom that he shares in regards to doing what I call “rookie maneuvers” (others call them stupid mistakes).  For example, once you have SRM up and running, it’s too easy to hit the button without realizing what it all really entails.  Mike warns you about this many times and prompts you to think about your actions ahead of time.

The later chapters of the book introduce customizations, scripting, more complex configurations, and how to reverse a failover.  There is a lot going on here and worth re-reading a few times.  A surprising amount of this info can be applied to basic disaster recovery principals regardless of whether or not SRM is in the picture.

Lastly, Mike walks you through upgrading from vSphere 4.1 to vSphere 5 and from SRM 4.1 to SRM 5.  Upgrading vSphere may sound a bit odd, but not when you take into account that it’s required in order to upgrade SRM.

All-in-all, this book is a worthy read and should be in your library if your shop uses (or plans to use) SRM.

One Year with VCE

Early January marked my one year anniversary with VCE.  I was hired to be a Program Manager on the virtualization team and my first project to lead was bringing vSphere 5 to the world of Vblocks.  I didn’t think this would be as difficult as it turned out to be.  I knew I would be herding cats, but I didn’t plan on herding cats from outside the herd.  About midway through the project, both Cisco and EMC informed us that they weren’t going to certify vSphere 5 on older levels of firmware.  In the case of Cisco, this meant the we were going to move all the Vblock platforms to UCS 2.0.  For EMC, it meant upgrading the firmware for all our supported storage arrays.  In essence, I was actually leading a project to upgrade all the components in a Vblock platform.

If I do say so myself, I did a great job.  But it wasn’t just me.  I worked with a great team of engineers, tech writers, product managers, trainers, and more.  This was truly a cross-functional project and involved over 50 staff across three companies by the time the project completed.

In this same one year, VCE had gone through tremendous change.  When I hired on, VCE was basically a startup.  About midway through the year, a certain level of operational maturity was needed.  We had achieved significant growth, both in sales and in head count. Thus began a series of reorgs.  There was basically one large reorg and a series of refining reorgs.  In my case, I went through two refinements.

The first reorg moved the virtualization team in with the rest of the Product Management team.  It also moved the bulk of our engineering staff into one engineering group.  This was a smart move as it removed barriers to introducing new product. Unfortunately for me, all Program Managers were moved into a formal Program Management Office.   While I did a great job on the vSphere 5 project, I found that this wasn’t the position for me.  Luckily, my managers recognized my talents and kept me on the virtualization team, which was now part of the Product Management group.

As the vSphere 5 project was winding down, the virtualization team was disbanded and we moved into the direct chain of Product Management.  Again, not a bad idea but it did leave me in a bit of limbo since Product Management does not have a need for a Program Manager.  Again, I got lucky.  The director of Product Management recognized my abilities in the areas of process management, barrier breaking, and general mayhem.  A product management operations team was created and I was assigned to it.   Our charter is simple: keep things moving.  Think of us a “fixers”.  If a project is in trouble, we show up and get it back on track.  If someone is not getting things done in a timely manner, we will.  We are also developing various policies, processes, and procedures for the Product Management team as well as working with other teams inside of VCE to develop company-wide policies and processes.

It’s been interesting to me because I am being exposed to areas of the business that I have not had previous exposure to.  For example, I am working with the marketing group on website redesign and developing launch materials.  I am also working with our supply chain managers on setting appropriate stocking levels.

I’ve had an exciting first year.  I’m betting the second is going to be even better.

Why I Am Going to VMworld

People go to VMworld for many reasons.  Some go because it’s their job to ”man the booth”.  Others go to party.  And still others go “just because”.  However, the most common reason why people go to VMworld is to learn about VMware products and its ecosystem.  If I were still in the position of IT Architect, that would have been my primary reason too.   This year is different.   I changed jobs at the beginning of 2011 and went from an IT position that held responsibility for the care and feeding of the virtual infrastructure platform to a Product Management position.   As such, my VMworld focus has changed from learning about VMware products to learning about VMware’s customers.

 

One of the basic tenets of Product Management/Development is to build products that customers want/need to buy.  So how does one go about finding out what customers want and/or need?  Simple.  Ask them.  I’ll be roaming the Solutions Exchange talking to attendees about their jobs, roadmaps, challenges, and desires (within the context of the datacenter).  I want to gather as much information as I can to help me excel in my new”ish” position.  I want to collect contact info so that I can reach out to folks later and see how things change as time passes.  I want to know if your efforts are successful or not.  Basically, I want to “know” and “learn” about you.

 

So if you happen to see me, introduce yourself.  Tell me about your company, your datacenter challenges, and more.  Help me develop a better product.

 

If you can’t find me, send a me a tweet  –  @ITVirtuality   – and let’s schedule a time to meet.

.