Physical movement of machines preparation

[Regina Obe]

> We are only migrating: osgeo6, osgeo7, osgeo8 and osgeo9
> but osgeo6 is going to be reformatted so we can use it for virtualization.
> During the physical movement services on the moved machine will be
> shutdown.
> 
> My proposed way of doing the migration:
> - Migrate osgeo9
>   - this would keep alive tracsv
>   - when turning back on the services will continue running normally
> - Do the final steps, mentioned above,  for using the containerized mail
> server on osgeo9
> - Migrate osgeo7
> - Migrate osgeo8
> - Migration of osgeo6:
>   - A new disk needs to be bought and installed
>   - Lance will do us the favor of installing and formatting and initial
> installation of operative system for virtualization
>   - He can do on the current datacenter or the new datacenter
> - Migrate contents of osgeo3 and osgeo4
>   - staging can go directly to osgeo6
>   - The rest we can decide where to put the conainers
> - Shutdown osgeo3 and osgeo 4
> 
> Please let me know your comments
> 
> Regards
> Vicky

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.
Whatever services we can't handle that much downtime, should be moved to osgeo6 at least temporarily once osgeo6 server is at its new home.

If we agree no service will suffer from more than 3 or 4 hours downtime, then I would say 

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)

That way if anything goes wrong during the transport of osgeo9, we can hopefully restart them all on osgeo6 already moved.
We might want to have secure though running in osgeo6 for the duration of the move since that is the only service I can think of where it's really bad to have that much downtime, since qgis plugins and sshing into any server is impacted by that.


3) I really would like to reformat osgeo7 since it's gone thru like 3 ubuntu upgrades and needs to go thru 2 more and it has the oldest OS of all the hosts and was our first learning of lxd so I feel things aren't
setup in the best way.

If we don't do a reformat, then we should perhaps temporarily/permanently move tracsvn to osgeo9 

The other items on osgeo7 besides tracsvn /download/photoprism I feel should be moved to osgeo8 - so that would mean moving mapserver, pycsw, live to osgeo8

I've been thinking of osgeo8 like a project host, one that contains project specific vms/containers like the grasswiki, grass (already on there), the woodie-server (used mostly by sac and postgis), postgis-demo server, live vms etc.

Download is already replicated on osgeo8, so we could just repoint download.osgeo.org to osgeo8 during the osgeo7 (reformat/upgrade) and repoint back after.  During the migration we wouldn't allow uploads to upload.osgeo.org.

So osgeo7 during the move would have nothing on it.
Osgeo7 after the move we would move download back on to it. We would move some other items that are disk heavy to osgeo7 e.g. peertube, photoprism
And everything on osgeo3 would be moved to osgeo7

And then we get rid of osgeo3.  Osgeo6 becomes the new backup/staging server after all is said and done.

We also at this point after should start discussing use of Hetzner as in the board meeting, we did discuss at least for redundancy having a dedicated host at Hetzner.  The pricing seemed reasonable something like $100-$250 per month for something somewhat comparable to osgeo7.

I lost the link that was provided at the board meeting for pricing, but was very reasonable.  I was mostly concerned about the bandwidth cost as that tends to be what eats up your money.
Tom or Vicky you remember that link discussed in board meeting?