Using webgisdr to migrate to new machine in the same datacenter.

[Randomapper]

Hello everyone,

I need to update a 10.6.1 base deployment to a new machine, as well as updating to Enterprise 11.2.  I understand that I could use the Join Site method and swap the machine out without an issue. And from there, maybe attempting an in-place upgrade to a newer version of enterprise.

I was instead considering the webgisdr method, so to keep the new site isolated for testing and then having IT make the switch to the new machine using DNS when ready.  In the documentation, I noticed that it says this method is usually used to replicate the environment to a different datacenter.  My question is, would I be able to use a webgisdr backup to restore the site to a new machine in the same datacenter?  Will it cause any problem with the active site to do this?  I understand the Enterprise versions need to be the same, so I would restore the 10.6.1 backup to the new machine, then perform the upgrade, then make the switch in DNS.

Any comments appreciated! 

[JonathanEpstein]

I've done this, migrating from 10.7.1 to 10.9.1 and am planning to do this again soon, migrating from RHEL7 to RHEL8 (and subsequently 10.9.1->11.1)

The key is that you must have complete control and command of DNS on the affected enterprise hosts.   In practice, you must use the same hostnames (but different IP addresses) in the old and new Enterprise cluster.   That's the bread and butter of how to effectively work with WebGisDR for situations like this.

For Linux hosts, this means writing tools to edit the /etc/hosts files on all the affected hosts.   I'm not sure whether editing the 'hosts' file in Windows is equally effective.

And I can almost guarantee that you'll run into issues nonetheless, but can't predict what they might be.

[ReeseFacendini]

WebGISDR doesn't preform any validation in terms of the datacenter. That comment is means that usually WebGISDR is used to replicate elsewhere in the event of a fail over. Keeping both environments in the same datacenter is okay.

Things to keep in mind when using this workflow to upgrade:

• Will there be a data freeze? Or is there an acceptable amount of data loss?
• Keep the primary administrator account credentials the same across both systems (i.e., portaladmin / siteadmin)
• Make sure to use the hosts file(s) to spoof the DNS while restoring the backup to the new set of machines

Like stated above, there is no way to fully predict the issues that may come up, but Esri Tech Support is equipped to help if needed.

[Randomapper]

Thank you, I was concerned about following best practices so if I got into trouble, technical support would be able to help me.  Also not wanting to disrupt the asset management software.  I will discuss the options with the team and see what method they would like to try first.

[Scott_Tansley]

Just something to check.  Last time I looked into it the webgisdr tool was actually not supported…yes it’s part of the Portal install but it is/was an unsupported  optional extra in use.

[Scott_Tansley]

First have a read of this:

 https://enterprise.arcgis.com/en/portal/latest/administer/linux/overview-backup-restore-web-gis.htm#...

when you restore the environment to the new machines, then the public URLs, registered datastores etc will all be pointing to the existing connections.

This next bit sounds naive, so bear with me.   While you could stand it up and test it, you probably wouldn't know if you're communicating with the old or the new.  It gets messy.  If you tested the new, then you could be editing live data in your databases.

So if you're standing it up in same datacentre you would need a dedicated Virtual LAN or equivalent, effectively firewalling it off.  You'd need DNS in that environment or Host file rules (yuck) to allow you to connect, test, upgrade etc...

Theoretically, you could upgrade within the VLAN and then swap out the DNS as you said.  It just needs planning, testing and a great deal of care IMHO.  

Also as suggested above, you'd need to take a data freeze during the process.  Because you'll end up with old 10.6.1 and new 11.2, and the portal items, and any new services won't rollover automatically, so you'd either have to 'freeze' or recreate them.  

It's a method I've never used, I've worked on the join approach or seen Operating Systems upgraded over the top/in-situ.  The other thing I'd mention is that I only support clients that use Windows Server, and not LINUX.  I don't believe that changes things in the grand scheme of things though as it's still more on the networking/firewalling side of the equation.  I cannot comment on the viability of in-situ RHEL upgrades, but I've seen Windows Server go from 2016-2019 recently.

[JonathanEpstein]

Among other issues, if your datastore's database is very large, then enabling incremental backups in preparation for the webgisdr backup(s) can be performance-crushing.     If you're unable/unwilling to take that performance hit, then you must consider whether you can manage a backup/restore while losing some incremental data, or incurring a lot of read-only semi-downtime.

[Randomapper]

Thank you so much everyone for the comments.  Fortunately, this site is not very big, and is only reference services.  The main catch being we don't want to lose connection to the existing URLs because they are associated with an asset management software that we'd rather not have to touch.

We can do a data freeze so I'm not anticipating data loss to be an issue.

I read the instructions about editing the hosts file and have done something similar in the past, so I understand the purpose of that.  @Scott_Tansley comment about the dedicated Virtual LAN, that is kinda where my thinking was going.  I assumed that I would not be accessing the "new" site through the public URLs and working from the local connections right on the VM itself. (i.e. localhost:6443 and :7443).  Using the hosts file to spoof the site to import correctly.

Sounds like a can of worms!  I like the idea of an inplace upgrade of the existing VM more and more.

[Scott_Tansley]

I’ve taken first client from 10.7.1 through 10.8.1 to 10.9.1 and 11.1 all in-site.  Just need 24-36 hours over a weekend