Yellow Bricks

by Duncan Epping

BC-DR

SRM, it’s just too easy

· ·

You’ve probably also noticed a whole bunch of Site Recovery Manager(SRM) related articles popping up with people installing and configuring it in their home lab:

I love these articles because they are prove of the fact that SRM is really easy to set-up. But, and this actually scares me, it might seem a bit too easy. I said “too easy” because implementing a Disaster Recovery solution isn’t about the tools you are using. The tools, which will make your life a lot easier, are not the most important piece of the puzzle. Indeed PUZZLE.

There a whole bunch of SRM projects going on globally where VMware PSO, the department I work for, is assisting. These projects typically have a duration of 3 to 9 months, while it seems that with the ease of VMware Site Recovery Manager this should be a matter of days.

People tend to forget that the most important thing about Distaster Recovery / Business Continuity is the business. You need to know the organisation and IT environment very well before you can even start:

  • SLA’s? –> RPO / RTO?
  • Which services are most important to the business?
  • Which servers are part of the service?
  • In which order need these be started?
  • Which service have the highest priority?
  • Are there any dependencies between services?
  • What about the desktops?

And these are just a couple of questions one should normally have to answer before even going down the SRM road. The fact that SRM is so easy to setup makes it really hard to actually explain to a customer why a BCDR project will take much longer then he expected. And remember that although SRM is a great tool you would still need to create a Disaster Recovery Plan, SRM will be part of the plan but it needs to be in place!

I’m not saying that you should not go down the BCDR / SRM road, but be sure to be prepared. (read this e-book, it’s good and it’s free) Get to know your “business”, and be prepared for a long engagement… cause my experience is that normally people have a hard time answering really obvious questions.

You will talk to a lot of people who don’t have a clue of what the core business services / applications actually are. And the same goes for the sys admins, dependencies? Why would you want to know about that and how would I know?

Do you know which questions to ask, do you know how to get the right answers… This is why BCDR subject matter experts are needed for SRM engagements, so before you start give VMware a call, or your local VAC partner for that matter and make sure you get the best out of the SRM product.

VM Template best practices (Linux)

· ·

I was just reading up on my Google Reader. A lot of information been dropped over the last couple of days and more and more people are getting active on the VMware blogoshere. One of the articles that really caught my attention was the “VM Template best practices (Linux)” by Leo Raikhman.

Leo did a great job in explaining how to build up a decent Template. Leo even included a way to regularly zero out the Linux Filesystem for the purpose of VCB image level dumps with small footprints.

And although Leo’s article talks about Linux only this also applies for Windows. If you will be doing VCB then remember to zero-out your filesystem every once in a while. Linux doesn’t scrub the sectors where the files resided and neither does Windows. I wrote an article on how to do this from within Windows. Yes you can do it by hand via the “shrink disk” option in VMware Tools, but as Leo already pointed out there’s no way of scheduling that one, as far I have discovered.

So most of the stuff written about in Leo’s article applies to Windows, yeah also the partition alignment! DO IT! But the zero-out procedure won’t work, I’ve wrote one a while back and here it is:

Set WshShell = WScript.CreateObject("WScript.Shell")
Dim fso, d, dc
Set fso = CreateObject("Scripting.FileSystemObject")
Set dc = fso.Drives
WshShell.RegWrite "HKCU\Software\Sysinternals\", 0, "REG_SZ"
WshShell.RegWrite "HKCU\Software\Sysinternals\SDelete\", 0, "REG_SZ"
WshShell.RegWrite "HKCU\Software\Sysinternals\SDelete\EulaAccepted", 1, "REG_DWORD"
For Each d in dc
If d.DriveType = 2 Then
Return = WshShell.Run("defrag " & d & " -f", 1, TRUE)'
Return = WshShell.Run("sdelete -c " & d, 1, TRUE)
End If
Next
Set WshShell = Nothing

Be sure to download Sdelete before you start, and remember that this script also does a defrag. If you are running “thin” disks than doing a defrag might not be the smartest thing to do, if so just delete the following line from the vb script:

Return = WshShell.Run("defrag " & d & " -f", 1, TRUE)'

VCB and multipathing

· ·

VMware just changed their VCB multipathing support. Before the KB article stated “Powerpath and other multipathing software.” The KB article has been changed and contains specific version of Powerpath which are officially supported and the “other multipathing” has been removed. Still I’m no fan of multipathing software on the VCB host, I would prefer using 1 HBA for uploading to a holding tank and 1 HBA for downloading the images from the SAN.

VCB and identical LUN id’s

· ·

I get this question a lot:”Does the VMware Consolidated Backup proxy host need to have the same LUNs with the same ID’s presented?”. 

VMware Consolidated Backup needed to have identical LUN ID’s to be able to match LUN’s but that has changed. It doesn’t matter anymore which LUN ID your host and proxy server see cause VCB just compares VMFS signatures. So I can hear you guys thinks, what about my RDM’s? (Raw Device Mappings) Well obvious VCB can’t compare the VMFS signatures, but it can compare the NAA ID’s and that’s what it does as of VCB 1.1. So in other words, as long as you just publish all LUNs you want VCB to backup it doesn’t matter which LUN ID they have.

And if for some reason your SAN doesn’t support NAA ID’s, well then you will be stuck with the “matching LUN ID’s” method you have been using for a while.

By the way NAA stands for “Network Address Authority” and is a unique identifier for you LUNs.

VCB and independent disks

· ·

Most of you probably knew that it is impossible to snapshot an independent/persistent disk. And if you didn’t, in short: a disk that is in “independent/persistent” mode can’t be snapshot because it needs to write it’s changes immediately to the virtual harddisk. When using a snapshot(nonpersistent) writes go to a delta file.

So as I said in this article, using this mode on a specific disk is a nice way to get the full image VM without for instance that gigantic data disk. But some of you might need the snapshot functionality, and it’s not possible to change the disk state from the VirtualCenter client when the VM is up and running.

But it is possible to change the state via the command-line when the VM is running. So if you want to change the state in a VCB script for a specific disk, or want to change the state for a VM without shutting it down here you go:

Find out what the current mode is from the command line:

vmware-cmd <path to vmx file.vmx> getconfig scsi0:0.mode

Set the new mode from the command line:

vmware-cmd <path to vmx file.vmx> setconfig scsi0:0.mode “persistent”

Keep in mind that this is, as far as I know, not supported and should be tested thoroughly before using. I would prefer doing it manually and keeping it that way. Or you could always use the script that I blogged about a while back, it makes it possible to dump specific disks without having to resort to unsupported methods.

By the way, with the setconfig option you can set most vmx options!