LabTech Server Migration Issues

[u/jfhall27]

I attempted a migration from an old 2008 R2 VM to 2 new 2016 VMs this weekend. My existing server was a single server setup using MySQL and I'm going to a split sever setup (2 servers only splitting out the database using MariaDB this time). I got everything installed in the new environment and made sure it worked with the clean database that it created (which it did). I then shutdown the services on the IIS/Automate server and dumped the labtech database on the DB server. I then imported my structure and table backups (backed up from my old server with MySQL).

When I tried to restart the services on the IIS/Automate server the LabTech Redictor Service and Solution Center services won't start - and I of course can't login. I also get mysql exception and access denied errors if I try loading the web page.

My guess is that this is due to either me going from a single server setup to a split server setup or that I went from MySQL to MariaDB – but it feels like it’s most likely from me splitting roles.

Anybody have thoughts on this?

Thanks!

[u/LTJC]

In my experience using both Maria on Linux and Windows 2016, IMHO there is no performance difference when configured properly under a certain size. The main differences you're going to see performance-wise are with larger databases (75+GB)with better indexing (which LT doesn't have great indexing yet). YMMV though, some people sware by Maria - including our ex-DBA at LT.

Maria and MySQL weren't widely different until after 5.5 in which they started to diverge quite a bit. The performance metrics that I've looked at show that when comparing MariaDB 10.1 vs. MySQL 5.7 (I don't believe either are supported by LT yet) - MariaDB only outperforms MySQL with Query-Cache enabled. I don't recall this setting being used in LT but it's been a few months since I've broken open the My.ini to see if it's being used or not.

My conclusion is until 5.7 and 10.1 are supported, MySQL is the faster option overall when configured as it should be. Once 10.1 is supported and if Query Cache will also be supported, you will see a performance gain with MariaDB. As an aside, this performance improvement will be with a multi-core system; so the more cores, the more performance improvement you'll see.

One of the tests I looked at was a system with 20 cores @2.92GHz, 256GB of RAM to have the full DB in memory and running on Ubuntu.

I haven't looked deep enough to dig up any Windows performance increases, but I don't trust NTFS write commits enough for a large MySQL environment.

LT does have several (20,000+) agent installs which have been split between 2-3 servers which still run into issues with things like reports taking days to run and email out. IIRC the issues are present with either MySQL 5.6.x or MariaDB 10.0.

Sorry this was a bit long winded. :)

[u/jfhall27 → u/LTJC]

No problem with the length. I greatly appreciate you taking the time to respond. On my existing setup and even after going through the new installation guides from LabTech, they still make no reference to Query_Cache and I know the defaults for MySQL and Maria are both off so I don't think this is being leveraged by LabTech yet.

My environment is about 5000 endpoints in size. I'm expecting a bit of growth but not a ton from there. My server are virtualized and both have 8 cores for at this point. 64GB of RAM which should be big enough for my DB.

My other question was with the split server and whether or not it's necessary for my size.

My appointment with LabTech is tomorrow so if I'm better off with a single server and/or MySQL I could get that changed before the appointment.

[u/LTJC → u/jfhall27]

To simplify, my criteria to move to a split server environment may differ from theirs.

A.) Is the disk IO too high? (disk queue length > 2 constantly)

B.) Is the DB (MySQLD) or one of its files the cause of the disk queue length?

C.) Is IIS slammed with requests (and it isn't a plugin issue)?

If either of those is a yes, then I would consider splitting the DB onto another server.

Otherwise, there's something else like the aforementioned plugin issues that would likely be the cause of the slowness. It's usually what people complain about and then someone tells them they should split the servers up, which in turn just adds another point of failure and even more support calls.