We are looking at retiring our aging servers and moving our Matrix install (3.24.4) over to our cloud as a VM and I have a few questions.
Are there any issues with running the webserver and db on the same VM, since we can basically give it as much RAM as we want?
Can Squid run on that same VM?
I am assuming we would have to install our current Matrix version on the VM, push in a backup file, then do upgrades on that to get to the current 4.4.0 version?
When using a backup file on a new install, will all of our Asset ID's stay the same?
Any other issues that I might not be thinking about with a move to VM like I have described?
Hey Nic, not an official reply by any means but just my 2p…
Our IT set us up two VMs (web/db) only because we have always had that setup in the past with physical servers. Squiz now provide Matrix as a VM on their Squiz Suite site and they chose to package the web server and database together. Can't actually answer this question without benchmarking anything, but I would hazard a "yes" to your question. Thinking points may be a> separation of concerns (matrix is an application in its own right, so why separate into two servers), b> server load (throw more ram at it) c> query latency (VM linux sockets probably faster than emulated networking between two VMs)
Squid can be many things, but when used with Matrix it takes the role of a web accelerator (aka reverse proxy). It handles requests that Matrix shouldn't have to, and by doing so it reduces the load on that machine. As such I would keep it separate (though you don't have to). Treat it a bit like a web app firewall: it can prevent your Matrix server becoming unresponsive, preventing editors to update it, if the server is getting slashdotted.
That's what we did. Move the whole installation as-is, and treat the upgrade path as a separate task you do after everything is complete and tested. (Or upgrade today and move servers at a later date - depending on your timescales.)
Yes, the backup contains all the php files, uploaded documents, and database records (with correct ids and foreign keys). Looking at my documentation, this is the process we took to move everything over (instructions assume the database is on a different server to show the -h flag being used):
make backup:
me@oldserver:~> mysource_matrix/scripts/backup.sh /path/to/mysource_matrix /path/to/backup_location
restore backup:
me@newvm:~> wget http://oldserver/backup/mysource_matrix-date-backup.tar.gz
me@newvm:~> tar xvf mysource_matrix-date-backup.tar.gz
me@newvm:~> rm mysource_matrix-date-backup.tar.gz
me@newvm:~> ls mysource_matrix # note the two database *.dump files (we won't need the *-schema.dump one)
restore database:
me@newvm:~> createdb -h newdbvm -U postgres -O matrix -E SQL_ASCII mysource_matrix
me@newvm:~> psql -h newdbvm -f mysource_matrix/mysource_matrix-date.dump
fix permissions:
me@newvm:~> chmod -Rv 755 mysource_matrix/
me@newvm:~> chmod -Rv a+w mysource_matrix/data/ mysource_matrix/cache/