|
We develop an application that uses Sql Anywhere 11.0.1 as the database. Database size can be anywhere from 5GB to 25GB. My task has been to come up with specs for the application to run in a virtual environment. I'm not a virtual expert, but I do know there are many different ways to virtualize. We have small, medium and large/enterprise customers that use our application. We have tested extensively on physical hardware and specifically RAID and mulitple SSD drives, so we know what performance can/should be. We have recommended specs built for physical hardware. I read through many of the posts regarding MS SQL Server regarding virtualization(since I didn't find a lot specifically geared toward SQLanywhere). There are a number of ways to allow access to the DB (through shared storage on SAN, local storage on host machine, or possibly having multiple instances of the DB to share the load). So, my question is it plausible(from an industry standpoint) to not necessarily give VM requirements on our spec sheet, but have some fine print about DB performance "gotcha's" if running in a VM. thanks for your thoughts |
|
SQL Anywhere runs just fine in a VM environment, technical this is not a problem. Where it beginns to become interesting, is when you need good performance under heavy load (Whatever you consider heavy load) In VM's you can assign CPU/RAM to the virtual instance, just as on a real server, there is no notable difference here, you can use the same scaling guides for the server. The biggest difference between a real server and a virtual server is always the IO performance for the disks (Sometimes the network too) Since database performance is very IO sensitive, a performant disk IO is required, otherwise your whole database will just be slow. For example if you can have a dedicated local storage for that VM, they perform almost identical to a real server environment. On the other end of the performance scaling, when you put the image of your VM in a disk file on the host maschine, or even that disk file remotely on a (overloaded) iSCSI system. André |
|
You may also want to observe what we officially say for SQL Anywhere:
|
|
I have had a number of clients who experienced SQL Anywhere performance problems directly caused VMs. Generally the root causes are a combination of (a) the desire to get something for nothing, (b) the idea that a heavily-loaded database server behaves no differently from a lightly-loaded email server, and (c) the belief that powerful computer will automatically assign resources wherever and whenever they are needed with no prior thought, planning or preparation. Outside the office, (a), (b) and (c) go together with (d) the belief that any teenager can find anything on any computer in the world with only three keystrokes. Absent those, SQL Anywhere runs fine on a VM :) Failed trying to interpret "... together with (d) ...", seems to be a virtual topic 8-|.
(11 Nov '13, 09:08)
Reimer Pods
Replies hidden
Point (d) is "the belief that any teenager can find anything on any computer in the world with only three keystrokes."
(11 Nov '13, 10:14)
Breck Carter
The truth is they only need three touch gestures:) Don't forget that we are old-school...
(11 Nov '13, 11:12)
Volker Barth
|
|
Amen to Breck's experiences. Most of our clients use VMs these days. I would rate performance success at 50%. Half of them took exactly the approach Breck describes and now 1)management is happy that IT spent less, and 2) ALL the users hate the IT department even more for making their apps run so much slower! The other half read the technical material instead of the sales material, realized the realities, and configured servers that could handle the load. Their results are: FASTER response than before, improved reliability, far easier recovery from failures, and a lower budget than they would have needed to upgrade all the physical servers individually. VMs ARE a GREAT improvement. Unless as Breck notes, you are expecting to get something for nothing. |
|
I have a client running ASA 11.0.1 (don't remember the build) on a VM Windows 2008 server. It has 8 gigs of RAM, virtual disks, etc. They have 80 connected users throughout the day and Mobilink running on the same server. There are 65 salesman that connect (Mobilink) during the day. Not all of the salesman connect at one time. It has been working for the last 18 months without a problem. |
|
Our experience agrees with what everyone else is saying - Bill Aumen's comments about people believing sales spiel, and Breck's re "Something-for-Nothing" are horribly familiar. From our particular prespective the big pitfalls are:
For heavily loaded systems we insist on dedicated CPU, RAM and disk resources for the VM. |
|
Thanks guys. Unfortunately, when our sales team sells the app, they talk to the business side and of course, in order to make it most cost efficient, they always ask what the minimum requirements are. The ole' "something for nothing" as someone above stated. We generally don't give minimums, but when they try to virtualize and place the app on a host and then don't give it enough resources either because they don't know how or don't want to dedicate enough, then, this is where we obviously see performance issues.
So, going back to my original post. Is it good enough to just put physical server requirements on a spec sheet and adding some fine print about placing the app in a VM environment could cause performance issues. Part of my thinking is that I can't test every VM environment, nor can I dictate how our customers IT department inevitably deploy/provision the VM. |