Kaseya Community

Splitting KServer to separate SQL box.....hoooo boy.

  • So, we have almost 2000 agents in place right now, and with our current growth I thought it would be a good idea to get the web front end and SQL server back end split off, while there is still time. The current single server setup is this:

    HP DL 380G5 - XEON E5440 4 core proc, 16GB RAM, RAID 1 setup for OS, RAID 5 Setup for separate SQL/Kaseya instance with the tempdb files located on the C Drive. (if any other config questions pop up, I can get more data) Server 2008 x64 Service Pack 2, SQL 2005 x64

    I have noticed that the server can be a little sluggish at times, especially if you are pushing out agents using LAN Watch to more than 10 end points at a time. Our company has a very hefty VM environment, so I built out a VM SQL box with: Same Virtual Proc type, 16GB RAM, similar RAID 1 and RAID 5 setups, Server 2008 x64 SP2, and SQL Server 2008 SP2.

    I got the instructions for backing up the KSUBSCRIBERS database, did the backup, and the restore on the new SQL server, and that went fine. Where I ran into the first hiccup was pointing the KServer at the new DB location. It started to finish its config changes, then kicked me out of the web interface and stopped the server. I tried to log back in, but got a ton of error messages, first saying the date on the SQL server and the KServer were different (how that is im not sure, bot hdate/time settings on server were identical), an error about a background task not completing for 4 hours, and the main screen showed this error:

    Error #6263: Execution of user code in the .NET Framework is disabled. Enable "clr enabled" configuration option. on line 134. Execution Duration: 10:48:40 AM - 10:48:42 AM SQL Command: Stored Procedure: dbo.sp_GetSession @PARTNERREF = @AdminName = @kSessionID = 62164436 @CultureCode = @PARTITIONID = @IsMasterAdmin = @AdminID = @LangID = @UserName = @IsAuthentic = @ScopeName = @RoleName = @ScopeID = @RoleID = @UserPref = @Theme = @firstFunctionId = @bookMarks = @partnerUserId = @initialLogon = True @agentGuid = 0 @anonAgentGuid = @appSessionID =

    After finding a setting to change the CLR ENABLED ability on the DB, I was able to login, but it was HORRIBLY slow, and the db schema reapply took close to 20 min. After that I was still getting errors for the date and background procedures, and being able to login from another actual machine other than the server itself was ridiculously slow. I am now in the process of just reverting back to the local SQL 2005 DB, and it did the same thing by kicking me out after changing the DB to point from the VM SQL box to the old box, and stopped the KServer. Has anyone done a migration from SQL 2005 to 2008 for Kaseya, and/or split their boxes from 1 single server to a web front end and backend SQL box and had similar errors? I am getting ready to reopen my support ticket, to see if there is something that was missed, because as of right now, I am trying to get back into the web interface for Kaseya, and it is crazy slow again. Any ideas or thoughts will be helpful. Thanks!

     

     

  • " Our company has a very hefty VM environment, so I built out a VM SQL box"

    @Justin.... I don't recommend a VM for your SQL, use a real machine, you'll need it for the I/O. The front end as VM not a problem, but the sql get's slammed pretty good for disk read writes and a VM won't keep up.

    as for your errors, check the time in the bios it may be what's causing the issue.

    I ran a test on my VM's here and I can point my sql to where ever I like with no issues. you may want to check the permissions as well on the new ksubscribers db  and ensure they match the old DB permissions.

    Hope this helps. I've split and migrated twice on my Kaseya servers so I feel your pain. Good luck

  • @danrche

    Thx for the input, I will check the perms on the SQL DB on the VM box, and I had my reservations about using a VM for SQL back end too, but we have another SQL box running a ton of production websites on it, and it is configured for much less resource utilization that the VM that is built now, so I didn't think there would be any issues with that. Now that I am seeing a bit more of how SQL intensive Kaseya is, I may have to go that route anyway....More to come as I try to figure out the options I have.



    [edited by: Justin Tison at 10:09 AM (GMT -8) on 2-14-2011] stuff about vms
  • we split ours and we are running both on a VM environment - 2500 agents currently. When we did the move we did it from system / configure - kaseya actually moves the DB for you assuming permissions etc are fine.

    However we were on SQL 2005 so when we split I split to SQL 2005 - I am planning on upgrading to 2008 shortly.

    As for performance things seem fine - we hit the wall every so often but usually due to large activity.

  • @ mmartin, you say you're running on all VM's? we tried that out before but the Disk I/O was too much for the VM to deal with. we started getting errors where our DB wouldn't accept anything until the load backed off. now on a real machine we don't have any issues. interesting that you're running on both VM's.

  • @mmartin -

    Ok, then I might actually just use SQL 2005 x64 on the VM, if I cant figure out what is bottlenecking the performance, and its NOT VM related on my side (configuration based, etc)

    Do you guys think logging a ticket with support would be fruitful for this? I don't see how it would hurt but it will probably take a bit for them to get back with any concrete answer or specs that I can use.

  • @Justin, you pay for support, might as well use it.

  • @justin yeah anything like that just log a ticket - then hit the forums sometimes its good to get both tracks working.

    If you are bottlenecking then you should be able to determine where.

    I will say that we are montoring the performance closely and if any change is to be made down the road it would be to convert the sql to physical but that would really be a last resort the benefits of the VM mean I will do all I can to keep it there.

  • Good point :) Time to at least log a ticket with them. Also, I guess for any other Kaseyans that read this, has anyone updated from SQL 2005 to 2008 for their prod/test boxes? I have a test environment with K2 setup on it (Running K2 6.1.0.0 with all hotfixes, should have put that in the OP) Any hiccups or craziness with that?

     

    Ninja edit - Everything in my prod environment is back to normal now, back on the one box. Debating on blowing my test KServer away, and rebuilding on SQL 2008, just to see if starting with SQL 2008 causes any changes or performance upgrades from the get go.



    [edited by: Justin Tison at 10:48 AM (GMT -8) on 2-14-2011] SQL stuff added.
  • Well I may have spoken too soon about being back to normal, now KLC doesnt work, giving me the old "Access False you dont have rights to access this page"

    :(

  • UPDATE: KLC Working now after server reboot, but Desktop Access part not working. Going to try and split off again after I get any info from Kaseya about upgading from SQL 05 to 08, to see if there are any hurdles.

  • ***UPDATE***: Got word from Kaseya support. Not only is using a VM for SQL not advised by them, using SQL Server 2005 x64 is the recommended version for this product. I am going to just uninstall SQL 2008 and go for 2005, more to come when that is done.....

  • vendors always say that about VM, just covering their ass they don't want to have to deal with disk bottlenecks or I/O issues. VM works fine as long as you can manage the back end and you have the necessary infrastructure.

    According to sys requirements for K2 - looks like 2008 is fine

    ■Microsoft SQL

    ◦SQL Server 2005 or 2008, 2008 R2, or (3)

    ◦SQL 2005, 2008, 2008 R2 Express Edition with Advanced Services (3)

  • I've got around 5K agents running in a split configuration, Win2K8 R2 w/ SQL 2008 X64 both front and back-end are VM's. Like mmartin said, vendors will always shy away from VM (although Kaseya does support it), but with the correct infrastructure you should not have any issue.