The forum will experience an outage sometime between February 10 at 7:00pm EST and February 12 at 11:59 EST for installation of security updates. The actual time and duration of the outage are unknown but attempts will be made to minimize the downtime. We apologize for any inconvenience.

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

asked 06 Nov '13, 15:45

mickeyHR's gravatar image

mickeyHR
76133
accept rate: 0%


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é

permanent link

answered 07 Nov '13, 05:33

ASchild's gravatar image

ASchild
777222740
accept rate: 14%

You may also want to observe what we officially say for SQL Anywhere:

permanent link

answered 08 Nov '13, 10:15

Jeff%20Albion's gravatar image

Jeff Albion
10.7k171174
accept rate: 24%

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 :)

permanent link

answered 07 Nov '13, 15:44

Breck%20Carter's gravatar image

Breck Carter
26.6k418575824
accept rate: 21%

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.

permanent link

answered 11 Nov '13, 11:25

Bill%20Aumen's gravatar image

Bill Aumen
2.0k294273
accept rate: 16%

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.

permanent link

answered 07 Nov '13, 05:19

Tom%20Mangano's gravatar image

Tom Mangano
587182234
accept rate: 6%

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:

  • Disk connectivity: direct - good, Fibre Channel - good, iSCSI - terrible, if any real load
  • Sharing with badly behaved / greedy applications on other VMs

For heavily loaded systems we insist on dedicated CPU, RAM and disk resources for the VM.

permanent link

answered 11 Nov '13, 13:49

Justin%20Willey's gravatar image

Justin Willey
6.4k101132197
accept rate: 20%

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.
Hope that all makes sense...I really do appreciate the candid feedback.

permanent link

answered 20 Nov '13, 11:27

mickeyHR's gravatar image

mickeyHR
76133
accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×238
×10

question asked: 06 Nov '13, 15:45

question was seen: 1,939 times

last updated: 20 Nov '13, 11:27