Hi all
is there any guideline about the migration of an existing single server moodle instance towards an architecture with multiple servers?
In particular, my multiple servers architecture will use external database and NAS server to share the data.
Doing simply the backup - restore of the database and moving the /moodledata to the NAS is enough?
Thanks
Pasquale.
There's this:
https://docs.moodle.org/310/en/Moodle_migration
from which you'd have to make adjustments for your arch.
Multiple servers: how? Virtual Apaches by different FQDN's or sites in folders of one FQDN?
Multiple sites adds to DB server - different DB's per site. So the dedicated DB server should have enough resources (memory/processing power) to handle new DB's.
NAS has to be mounted on code server. How mounted and speed of such setup are potential issues. Couldn't tell ya what.
Then there is also the 'applications' server ... where code will reside. Resources/memory/connectivity.
All sites same or near same version so that one version of PHP and one version of MySQL/MariaDB is all that is needed to run them?
Then there is setup of those things after migration/up and running ... like cron job ... site backups ... automated course backups? ... search - Solr or simple ... Assignments (grading) - annotated? Document conversion - local unoconv/libreOffice or Google? and so on an so forth.
Sorry ... no one answer fits all here! Not with very specific details - after all, that's why you make the 'big bucks' in admin'ing such a system.
'SoS', Ken
Guess I was reading in-between the lines ... not understanding exactly ... but now I think I understand the setup will be for a single top level domain moodle instance with a load balancer in front. DB server dedicated and NAS used at least for moodledata//filedir/
Now an experienced (1st hand experience) quirk ... one was environment check.
In a load balanced setup (this one under KEMP) and admin level user would login to the moodle. Actually, due to load balancing admin user was on server3 of 5 backend code boxen's and did an environment check on server3. Admin user updated the compnoent. That acquires a new environment.php and environment.xml file on server3. If, later on during day, admin logs in during prime time when the spill over load is now on server5, the environment check wasn't the same.
In setup entity used server0 as their staging server. With load balancer in maintenaince mode, admins would access server0 via ssh and use git to acquire core code, manually update their customized theme, and customized code, then run the admin/cli/ upgrade.php script. Single DB now updated and has the newer version updates/settings. server0 then checked for errors. If none ... then entity used a 'shotgun' routine to scatter the updated code to all the other nodes in the load balanced system. All nodes then have the updated code. Once having done that, KEMP taken out of maintenance mode, and as clients come into site and each server reaches it's max client settings, clients begin to connect to which ever back ended code server is available.
A couple of more things ... monitoring nodes and troubleshooting ... if user reported an issue ... finding out which node user was on. Moodle Admin UX had no setting for an Admin level user to ID the server node. Problem for the user should be investigated in that context ... that node.
Do remember that networking comes before application and in things like a SCORM netchecks by clients in a SCORM have to focus on the node upon which the user was logged in.
Strongly suggest, documenting your own processes for updating plugins/themes/custom code as well as upgrading code, etc. and any quirks for the person who might replace you one day.
My 2 cents!
'SoS', Ken
