03-31-2009 02:46 PM
03-31-2009 08:44 PM
All BUT SQL server are good candidates for Virtualization.
Several server types should never be virtualized:
A - SQL server
B - Domain Controllers
VMWare is the best way to go.
04-01-2009 06:50 AM
04-01-2009 07:18 AM
Thanks for the input! The virtual server team have the idea to keep the database and application servers in separate VM environments but I will go in being very critical of virtualizing the SalesLogix SQL server. BTW, they are using VMware.
We are also implimenting the SLX Mobile environment as well as a movement to the web product after we upgrade from 7.0.1 to 7.5.1 this summer. I am considering putting the SQL database associatied with SLX Mobile on a virtual server. Despite the statement that SQL servers should not be virtualized, since the SLX Mobile database appears to act as more of a pass through, I was thinking that the risk would be less to have that virtualized. Can you expand on why it is a bad idea to put a SQL server on VM?
Any thoughs about running the web services for SalesLogix web and SLX Mobile in the same VM environment for 600 SalesLogix users and 200 SLXMobile users is also appreciated. Any recommended horsepower or multiple environments?
04-02-2009 07:37 AM
04-02-2009 08:51 AM
It's NO problem...
Sage SalesLogix looks at VM as "soft" hardware. They test SalesLogix on various OS's and VM is not considered an "OS".
Sage SalesLogix Dev, QA and Tech Support use VMware every day and have done so for YEARS!
BP's use VMWare every day.. we have (large and small) clients that use VMWare for dev/test as well as production systems every day.
If you call Tech Support and tell them you are using VMware it's no big deal. They will support you.
Just make sure you have not under-configured or under-powered your VMware setup.
Our test/dev system is a Win2003 64 bit, quad-core, 16gb or ram, 3 1tb SATA II Drives (mirrored) and we run from 5 to 8 VM images on it all the time (XPPro, win2003, etc). We're moving our production SalesLogix to a VM image in the next few weeks (Keeping SQL server on real hardware ;-).
04-02-2009 09:16 AM
I feel I need to add that you will NOT receive as good of performance as you would on a non virtualized deployment with similar resources due to the layer vritualized machines encounter between their virtualized disks and the actual hard disks. The slower write times are noticeable for large deployments and will cause performance issues as you add more users to your system.
You must also plan on giving your virtualized deployment adequate root disk space as some current I.T. practices tend to only provide a minimum of Root drive space to the environment. This doesn't work in the case of the Sage Sync servers which use the root drive for their file operations as well as some other SalesLogix add-ons out there that only perform file I/O on the root drive. You should plan on providing atleast 2GB of free space solely for the use of SalesLogix. Note that this doesn't mean the root drive should have 2GB free, it means it should have 2GB free + free space for things like system restore, hard disk/virtual memory, etc.
Finally, RJ is right, I would never recommend virtualizing a SQL Server, mainly due to the points above - too many disk read/writes, too much system performance needed and a virtual machine is, at best, another layer between the actual OS and the hardware that actually does the work.
That being said, I must say I've been working with Hyper V on Windows 2008 server and it is phenomenal.
04-02-2009 09:31 AM - edited 04-02-2009 09:43 AM
From a Customer Support perspective: We help troubleshoot whether the environment is virtualized or not. However, depending upon the nature of the issue, we may ask that a test be performed in a non-virtualized setup so we determine if it is a contributing factor, which it may be if the issue is performance-related.
I agree with the posters who note that performance is the key concern. However, I'd like to know the group's thoughts on virutalizing the sync server if you have a large number of remote clients, i.e., can setting up a primary and secondary sync server on the same machine improve sync performance?