Tag: migration

Sometime in 2016, I moved my blog (this one) to an AWS EC2 instance (t2.micro) running Amazon Linux. It seemed like a good idea at the time, since my prior hosting (Gandi.net) was shutting down their US-based datacenter. I had to move it somewhere, and running it on my own server for ~$10/mo had the added “benefit” of a dedicated host to tinker with. I think I was bored when I made that decision or I would have chosen something with less risk/overhead.

In the intervening months, I found myself returning to a time when server/application “health” was achieved by routinely rebooting the server running it. Apparently a t2.micro isn’t really enough for even a lightweight blog and LAMP setup like mine, because every few weeks, I’d refresh it to find the database connection failing (out of memory, maybe?). So I’d hit the AWS Console and reboot the instance (because it never happened when I had free time). That brought it back to life for another few weeks before it’d crash again. And so 2017 went.

The Christmas season presented me with a bit of time to finally escape this relatively expensive sub-par experience, so I finally executed on my plan to move my domain to Google Domains and my hosting to Namecheap. Fill in “Namecheap” with almost any generic hosting provider using cPanel, and you’ll be able to apply the steps below. There are other ways to do this (some surely easier), but this is the path I took. Feel free to chime in with others!

Step 1: Pre-move housekeeping

Just like moving apartments or houses, the shift can be easier if you get rid of junk you don’t need before you shovel it to your new home. In WordPress land, that can be achieved by:

  • Deleting unused themes
  • Deleting retired or unused plugins
  • Pruning your media library–especially unattached items

With the bit bucket full and your WP site lean, let’s move to Step 2.

Technology

As part of a project consolidating mission critical services, I am moving a few VMs between vSphere / vCenter datacenters. The keyword here is “datacenters” and for emphasis, they are managed by different vCenter servers operating in linked mode. Because of this setup, the migration isn’t a simple cluster & storage vMotion.

Here’s the process I am following. I hope it helps; if you use another method, feel free to comment.

migrate_services1. Enable SSH on an ESXi host in the source and destination cluster; on the source host, also open SSH outbound on the host firewall

  • In vSphere Client, go to the “Configuration” tab on each host
  • Under “Software” on the left side of the right pane, select “Security Profile”
  • In the top right under “Services”, click “Properties…”
  • Scroll down to “SSH” and click “Options…”
  • Select “Start and stop manually”, then click “Start” and return to the Security Profile page
  • On the source ESXi host, also click “Properties…” under “Firewall”
  • In Firewall Properties, check “SSH Client” and click “OK”

Technology Virtualization