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.
For my next trick, I am going to review another Cisco Press book titled “Enterprise Network Testing”. I think I can sum this up in two sentences: “Holy Crap!” and “This book has PLENTY of cowbell!”.
Now I am not currently a network guy by profession, but if I was, this book would be on my desk with copies on my teammates’ desks too. It is literally THE blueprint for how to test your network.
The journey into network testing begins with a discussion on why you need to test your network. Most people only think of one or two reasons. This book provides a few more to help you make your business case. BTW, the authors make it very clear that testing your network is not a one-time event. Testing should be done whenever changes are made, for compliance, introduction of new technologies, etc. In other words, plan on testing regularly.
One area where this book and I completely agree is where testing should first take place: in the lab. There is whole chapter devoted to lab strategy. Topics covered include staffing, facilities planning, test methodologies, power, and more. I must say that I was surprised at how good this chapter turned out to be. Most books give basic guidance on lab setup, but like I said at the beginning of this review, this book has plenty of cowbell.
So now you have your lab setup, what are you going to do? Simple, read this book because it provides guidance for “crafting the test approach” (actual chapter title). Briefly, this chapter discusses several reasons/objectives for testing and how to craft your strategies to set you up for success. This includes setting your test targets, what tools are you going to use, writing a test plan, allocating resources, etc. It’s a very well thought out approach.
Business case approved? Check. Lab resources allocated? Check. Test plan created? Check. Great, now go execute your plan. Need help? No problem, this book will walk you through a sample lab setup, finding the appropriate tools, and a few different methodologies for measuring different network characteristics. This is the point in the book where the authors stress the need to understand what you are testing, the tools you are using, and how to interpret the results. In other words, if you don’t know what you are doing you will not be successful.
Speaking of knowing your tools, this book does a credible job discussing network toolsets that are available for free and for purchase. Even non-Cisco products are covered which is something I am not used to seeing in a Cisco Press book. Usually, these books are oblivious to other companies’ products. Kudos to the authors for being thorough.
The next six chapters are where you will find plenty of test case examples. There are individual chapters devoted to six types of testing. They are: Proof of concept testing, network readiness testing, design verification testing, migration plan testing, new platform and code certification testing, and network ready for use testing. They are written in a case study format and are quite readable.
Nerdgasm time. This is where the book gets hairy…Are you too lazy to develop your own plans from scratch? You want to cheat? Just borrow the DETAILED test plans that are in the next seven chapters. There is enough meat here that Cisco Press could copy & paste into a shorter book to sell. We are talking over 200 pages of test plans covering seven areas. That’s a lot of cowbell!
The book ends on a high note. Since you went through the trouble of setting up a lab, why not use it for training/learning purposes. Step-by-step instructions are provided to setup a lab. This chapter may not be useful to a large number of folks since the equipment covered is pure Cisco, including UCS. In fact, many of the directions provided center around setting up a UCS environment. I happen to like this chapter because one of my last major implementations before joining VCE was installing UCS for the organization at which I worked. Sort of brings back memories.
To sum this review up: If you are in the network field, you need this book.
I just finished reading “IPv6 for Enterprise Networks”, published by Cisco Press. All I can say is that unless you have the hots for IP protocol discussions, this book will not rock your world. It’s not that it is a poorly written book, it’s just that I don’t find IPv6 to be exciting. That being said, the authors do a very good job in covering the material.
As is typical of tech books, we start with the obligatory history lesson. Why should we transition to IPv6? Simple, we are running out of IPv4 addresses. Lesson over. There is more to it in the book, but let’s be real here: The largest driver is the lack of IPv4 addresses.
With that chapter out of the way, the book covers the basics of network design. This is a chapter that appears in a number of Cisco Press books. It’s a good reinforcement of network design principles that we should all do well to remember.
Now that two basic chapters are out of the way, the authors delve into IPv6 itself, how it is different from IPv4, and how to get from here to there. This is where the book shines. It’s a great reference for making the transition from IPv4 to IPv6.
As part of making the transition, the authors discuss the pros/cons of many of the various migration strategies such as running a dual protocol stack, running a hybrid network, and more as they relate to the different types of networks (campus, branch, data center, and so on). It should be noted that each network type has its own chapter. There is simply too much information that the readers need to be aware of that it would be a disservice to cover them together.
The authors simply could have ended the book there, but that would have made for incomplete book in my opinion. Thankfully, they kept going and included a chapter on managing an IPv6 network. While much remains the same, there are differences that may arise that readers should be aware of. In some cases, it’s just how to enable the monitoring/reporting capabilities of the equipment. In other cases, IPv6 just handles things differently.
As with most Cisco books, there are plenty of screen shots, command lines, and such given that the reader should be able to copy from to get from point A to point B. I like this. Far too many books out there have too few examples.
The last item covered turns out to be my favorite: setting up a lab. While it is not a monkey script type of chapter (type this, click this) it still gives the reader enough detailed information to be successful. Personally, I think that if you need a monkey script, then maybe this is one area where you shouldn’t be working. What really surprised me in this chapter was the inclusion of screenshots from an ESXi host showing how to configure it for IPv6. Talk about timely and relevant.
Would I recommend this book? Yes. While not exactly a page turner for most people (again, we are talking IPv6 here), it is a very good reference guide for making the transition from IPv4 to IPv6.
How do you rate/review a technical book? I could go on and on about different methodologies, but basically, I think a technical book is good if I can read it without having to take a ton of breaks, if I walk away with an understanding of the technology, and if it meets the needs of why I read it in the first place.
What makes me take breaks? Really dry, super-down-in-the-weeds writing. I am not a PhD candidate, nor do I live for reading IEEE RFCs. It’s been said that if you want to write for the masses, it has to be at an 8th grade level (I may be wrong, it could be 6th or 10th grade). Techies are generally not “the masses”, but we still don’t want to be bored. Nor do we want to see if you can use every word in the dictionary that has more than six syllables.
Even when writing at a level that the masses can follow, a good technical writer still needs to be able to impart the desired information in such a way that it can be retained and be of value. Good writers provide clear examples, use analogies when appropriate, and know when enough is enough.
One could argue that if I end up with an understanding of the technology, then it is a good book regardless of how hard it was to read. But since this my blog and I am writing the review, my rules win.
Now on to the review…
I just finished reading PKI Uncovered: Certificate-Based Security Solutions for Next-Generation Networks from Cisco Press. All-in-all, it’s a decent book. Just for grins, I read the intro/preface to see who was the intended target audience and I think it misfired in that sense. It’s not technical enough for the die-hard techies (thankfully – see above about taking breaks) and it’s too technical for the C-level (and other managerial types) it listed.
This book follows a traditional chapter layout approach: theory, examples, troubleshooting, and integration with other products.
The first chapter is a refresh on cryptography. It explains what it is, characteristics, and the major components. I would have liked more info in this chapter, but it really is just meant to be a quick refresh before delving into PKI.
The next few chapters focus on components of a public key infrastructure, how to set it up, troubleshooting, and design.
The final chapters deal with integrating PKI with other Cisco technologies/product such as VPNs, Unified Communications, and such. As mentioned on the back cover, the book “offers specific, detailed guidance on using PKI with Cisco ..” products and it does not disappoint.
So what did I like about this book? I really liked the fact that this book has plenty of examples and screen shots. Being Cisco-centric, this book does a great job of explaining how to setup PKI on Cisco gear. There is also a very good chapter on how to troubleshoot your public key infrastructure. The authors provide numerous process flow charts, log parsing examples, and more to help troubleshoot a technology that can be very cryptic (no pun intended) to figure out. If you are a Cisco shop, consider certain aspects of this book to be like a cookbook: follow the examples shown, you should end up with a working public key infrastructure.
This is also the book’s downside. Once you get past the first few chapters, this book is heavily Cisco focused. This isn’t a problem if you know that before purchasing. After all, it is a Cisco Press book. I’ve only read about 10 Cisco Press books and I read them because I wanted to know about Cisco product. And to be fair, the back cover does state that the book is for “Cisco customers”.
Another positive quality of this book is that it provides some very good design principles, such as having multiple/redundant certificate servers (in the proper hierarchy). Too many times I’ve seen tech books provide designs that have many built-in single points of failure. This isn’t one of those books.
In my opinion, there are only two areas for improvement: writing style and technical depth. The writing style is dry. If you’ve read some of my other blog posts, you will undoubtedly have noticed that I’m very informal most of the time. I also like to inject some humor into my writings every now and then. That being said, this book could use some could use some lightening up.
As for technical depth, I would have liked a bit more on just a few topics. Not super-techie, but a bit more. For example, the book mentions Diffie-Hellman but doesn’t get into the workings of it. Same can be said for a few other items. I figure if you are going to mention something, then do it justice and not just cover it in a line or two. I would hazard a guess that D-H isn’t discussed in much detail because it really isn’t germane to the book’s topic. For those topics that are germane, the authors do a good job. Deep enough, but not so deep as to put the average techie to sleep.
So would I recommend this book? If you are a Cisco shop looking to implement PKI, then most definitely. If you are not a Cisco shop, then half of this book may not be of value. For theory and principles, I think you would see value in it. It’s a judgment call at this point. As for myself, I would consider this book a good buy just for the first few chapters. The rest of it is bonus material.