In my previous post I briefly mentioned one of my cooler projects of 2020: closing down a datacenter and consolidated it to our other datacenters at Open Line. The complexity of this project was mostly on the network and “BU carve-out” side of IT, but also featured a very cool Pure Storage FlashArray ActiveCluster component. In fact, using ActiveCluster technology ensured that we kept it all very simple from a data migration and risk perspective. Let me explain why we did what we did, but also start with a disclaimer.
migration
8 posts
While updating this site and its plugins, I’ve noticed that my previous post is from May 2020. I couldn’t let that ticker go the full 365 days between updates, so here’s a keepalive post to let y’all know I’m still alive and well. A lot has happened in the last 12 months which has kept me from posting as much as previous years. Fortunately, much of it is good news, so no worries!
Last year we decommissioned a physical Avamar grid in London because it was both out-of-support and the location was about to close down. The Avamar was however still being used for desktop/laptop (dt/lt) backups. A separate project was taking care of replacing those laptops, but in the meantime we needed to keep the Avamar backup service running.
We did a quick calculation on the required capacity and deployed 4 new Avamar virtual editions in our central VMware farm. After configuring them and connecting them to the Avamar Enterprise Manager dashboard, we were able to move the majority of clients over.
Now, almost a year later, many of those laptops have been replaced and are no longer backed up by these 4 new Avamars. Which clearly shows in the utilization, as you can see. Three out of four systems are <10% utilized. Since these Avamars claim a fair bit of resources from the VMware farm, I set out to consolidate the systems into the first virtual Avamar. Thus, reclaiming 75% of the resources.
Several of our Data Domains are end-of-life and need to be replaced with new hardware. In most of the cases it’s a small site with a small Data Domain that only holds roughly 1 month of backups. In these cases we just install a new Data Domain next to it, reconfigure our our backup software, and that’s it. After a month, the old backups have expired and you can switch off the old Data Domain.
For the slightly larger sites, there’s more than one backup client/server writing to the Data Domain. There are Oracle RMAN backups, SQL dumps, etc. Plus the retention of backups on the Data Domain is much, much longer. In these cases you want to perform a proper Data Domain migration which retains the name and IP address of the old Data Domain, so you don’t have to touch all the clients. Here’s how you do that, and a DDBoost gotcha you should be aware of!
The last couple of months I’ve been busy consolidating a couple of European data centers to one location in The Netherlands. Technically this meant we had to migrate a large number of virtual machines with as little downtime as possible across WAN links with varying speeds (30Mbit up to 500Mbit). There are a number of methods to go about this, but we chose to use the vSphere Replication infrastructure which is included in vSphere 5.x for free. Unfortunately there are a couple of downsides in the management interface which become a pain if you have to manage several hundred replications…