Hello again! For the last, oh, almost year now, we've been trying to figure out how to deal with a rather unfortunate situation in our primary Datacenter in Edmond, Oklahoma. For some known-only-to-the-fire-marshall reason, we have a half-dozen sprinkler heads - wet-system sprinkler heads - perched right above about 6 racks full of IT gear. Our primary 12TB EMC SAN cabinet is there. Our 150TB Apple XSAN Cabinets are there. Our core routing switches, routers, firewalls, etc. are there. Our primary VMWare ESX Cluster and Cisco Callmanager Cluster is there. What do we do if the sprinklers go off?
Well, that's not the only thing we worry about, but, it's a start. We simply need to start working on a Business Continuity / Disaster Recovery plan in IT. So, for the last while, we've been incrementally improving our network and it's at a really good place. You can read more about our LAN/WAN Redundancy in this post. We're still - STILL - waiting on AT&T to figure out some circuitry stuff, but we're getting closer.
The Goods
In our DR Datacenter - our OKC Campus - we've got about 100TB (raw) of Nexenta SAN / Pogolinux.com storage. We've got two VMWare ESX 3.5u4 hosts there, in their own cluster. We can't upgrade to vSphere 4 yet because we run VMWare View - and it's not on the vSphere compatibility matrix yet. We've got lots of other stuff there, but the storage and ESX is the key part of this conversation.
The Problem
Well, in our Primary Datacenter, we've got four (4) VMWare ESX hosts in a DRS/HA cluster. We've got about 10TB of storage actively used spread over about 70 Virtual Machines - Application Servers, SQL Servers, Terminal Services, Exchange 2007, File Servers, VMWare View, etc. How do I get THAT from the Central Datacenter to the DR Datacenter in such a way that we can "bring it live" incase of emergency. Not only do I need the VMs copied (one time) but I need all the changes from those VMs - during reasonable replication intervals. Right? What's the point of having a DR Datacenter if you can't use it in case of emergency. I've got a solution for replicating the XSAN already - but what about the VMWare ESX stuff?
The Solution
Veeam Backup & Replication! Duh! Go read about Veeam Backup and come back. Cool, huh? I'm still working out whether I want to Backup or Replicate or both. Most likely I will be doing regularly scheduled - intervaled - "replication" for my core VMs. I will be doing "backup" at times to take things offsite, and that's an added bonus. I've been using Veeam products for a while now. I've blogged about them. I've done published case studies with Veeam. And no, I'm not paid to be a Veeam spokesman - I'm just a really happy customer. When it comes to Veeam Backup, I've played with the product for a year or more in labs, and in testing, but have not rolled it out into full production - until now. Let's get started.
Installation
As is my custom, let's walk through the installation of the product. Remember, if you're new, I blog for me mostly. I don't remember details as well as I once did, so, when blogging through some processes, it's helpful for me when I forget things - I can come back here and read why I did something.
The guest VM I'll be running Veeam Backup on is running Server 2008 X64 (64-bit) Enterprise. So, I downloaded the 64-bit Veeam Backup bits, and started the install.
Great. Click Next.
Accept the EULA. Click Next.
You'll be prompted for a license file. So, grab your trial license (you got it in an email when you downloaded Veeam Backup) or grab your full/purchased license if you have that. Click Next.
Where are you gonna install it? Click Next.
Okay, here's where you choose whether to use an existing SQL Server, or install a local instance of SQL Express. Let me <RANT> a moment. I love Veeam. A lot. My only gripe with them pertains to all my little-bitty SQL Express installs I have. I've got about 4 of them - all created because Veeam doesn't support SQL 2008 yet. Sure, this isn't a show stopper. I brought it on myself by having a large corporate "shared" SQL 2008 Server (details here). SQL 2008 is not in the compatibility matrix - so I know that going into the project and. I've reported my annoyance and received a reply that they are working on SQL 2008 compatibility - and that gives me some solace - but in full disclosure - it is rather annoying to have multiple SQL Express instances spread across my virtual infrastructure. </RANT> Click Next.
This is where you choose your Service Account. I use the "veeam.admin" account for all my various Veeam Services. Note this user must be a DB Owner on the database install - whether local SQL Express or shared "central" SQL box. Enter those credentials. Click Next.
Great. Let's Install.
W00t! We're done. Click Finish.
Now, let's launch Veeam Backup - I wanna see it.
Okay, there ya go. Stay tuned for Part 2 - We'll dive into adding hosts and targets, define some jobs, and get down to business.
For those of you reading, and using Veeam Backup, please post a comment linking to any blog / documentation you've done. I'm always interested in how others are using the product. If you have any "gotchas" you've discovered, please share.
That is good that people are able to get the home loans and it opens up new possibilities.
Posted by: FranksROSANNE19 | September 02, 2011 at 12:15 PM