we would like to move the current ON front-end from the current host (an old machine) to a newer and much more powerful front-end. All users, VM images, and any type templates should be preserved, if possible.
What is the suggested approach to do this ?
If your OpenNebula (oned) and storage (NFS, Ceph, Shared LVM) are not on the same machine as Sunstone, then it is easy. In fact, you can get away with a relatively small machine to run Sunstone, as all Sunstone does is to pull data from ones via RPC, and process the data, and vice versa.
However, for serious deployment, you really should do active-active MySQL + proper fencing on HA or LB (which in my case, three machines running LB active active), and your ones will uses this HA setup as the database back end.
(Back to Sunstone again, you can do a LB setup with shared
redis memcache session)
Without your (detailed) current setup, it is hard to recommend an action plan for you.
Our current setup is quite basic: oned and sunstone run on the same machine.
We have a NAS device that is mounted via NFS on a different host.
I would suggest that you run some sort of lightweight virtualization on the powerful host and run your services in there. Current I have them running in SmartOS’s LX-Branded zone.
Of course you can run them on bare metal, but I generally consider it wasteful.
Would you rather go for LXC or Docker containers to run the oned and sunstone services ?
Well, in a sense, Solaris zones and LXC are similar. Go with whichever you are more comfortable with.
Here are some ideas for you:
1x memcache instance
1x MySQL with persistent
Or if you are very fancy, you can throw all of them in Kubernetes
for what would you use memcache ?
I’m not sure to see, what you mean by 3x sunstone: if they all run on the same powerful machine (yet executed by containers), what is the advantage ?
But all in all, I still remain with the open question of how to migrate the current oned and database to this new dockerized version of the system without losing content.
Is it enough to dump and recreate the MySQL database into the container with persistent storage volume ?
To be fair, I wasn’t being specific. For now, you will need one Sunstone, yes? Say for some reason you will need to expand your operation, then you can just spin up more Sunstone if you have memcache enabled. (Future proofing).
systemctl stop opennebula, then do a dump. Unless you are doing a sqlite to MySQL migration, then you should look at the official docs.