Physical movement of machines preparation

Regina Obe lr at pcorp.us
Mon Sep 15 07:47:36 PDT 2025


> > Regardless what order we move the other servers, I think osgeo6 physical
> server should be moved first.
> > From what Lance mentioned, it sounded like we'd have at most a couple of
> hours downtime.
> 
> This should be done AFTER osgeo6 stops hosting any service, so AFTER its
> containerized version takes its place, right ?
> 

Correct.  Plan is
1) Containerize current osgeo6 (which is already done on osgeo9)
2) Confirm all is working on osgeo9 (we did not test the MTA too much but we did test mailing lists), and sending mail via new osgeo6
3) Production Switch to containerized osgeo6 on osgeo9
4) shut off osgeo6, make sure everything is still working
5) put in new disks in osgeo6 so it has a lot more space
6) reformat osgeo6 physical and bring back up as an lxd host


> I think that's the very first step to complete, probably worth its own thread to
> not mix it with the planning of physical movements.
> 
> > 2) Copy over all containers on osgeo9 to osgeo6 just before the move
> > of osgeo9  (note at this point osgeo6 server is already at its new
> > physical location)
> 
> Moving containers from a machine to another implies a change in the public IP
> address of the service, correct ? So we should also factor in the downtime due
> to DNS propagation. We should plan for it beforetime to have a quick way to
> update them (lowering TTL) - doing DNS via Ansible should help - see
> https://trac.osgeo.org/osgeo/ticket/3188
> 
> --strk;
> 
>   Libre GIS consultant/developer 🎺
>   https://strk.kbt.io/services.html

DNS wise I think our downtime is pretty low.  I've noticed it only takes like an hour or so.
Though we can't account for dns servers caching for longer than they should or client pcs caching.
But that said, this is a PLAN B - only would be done if osgeo9 for whatever reason doesn't  make the physical move 
And we are forced to restart all services back on osgeo6.

I'm hoping we wouldn't have to execute on this plan B.

The only case I was thinking was with secure, that we might want to switch it temporarily to osgeo6, but even that I think people can live for a couple of hours
without secure being live. Just means that only SAC would be able to ssh into the machines and that people wouldn't be able to upload plugins to QGIS for that time period
or log into any of our services.



More information about the Sac mailing list