Licensing SAP SQL Anywhere in Virtual Environments – Updated
I am providing here an update to running SAP SQL Anywhere in a virtual environments (VE).
Is SAP SQL Anywhere Supported running in a virtual environment in production?
Yes. One of SQL Anywhere’s strengths is its support for a wide variety of platforms, including virtual ones. We will support our customers running SQL Anywhere on any OS in a virtual environment providing that OS is listed as supported (see link above). To ease tracking and diagnosis for technical support issues, our support team will sometimes ask customers to reproduce issues outside of the VM environment in order to remove as many irrelevant factors as possible when diagnosing a problem. If we do run into issues that are directly caused by running in a virtual environment, we can work with our customers and the virtualization vendor to diagnose and resolve these issues.
How is SQL Anywhere licensed in a virtual environment?
For user based licensing it makes no difference whether or not the server is running in a virtual environment.
For chip licensing, you purchase a license for each chip on which you wish to run SQL Anywhere. You are entitled to run as many instances of SQL Anywhere as you want on each chip you have licensed, regardless of whether or not virtualization is involved. This means you can run as many SQL Anywhere servers you want on as many VEs as you want on the chips that are licensed for SQL Anywhere. This is different from the Sybase licensing policy, which required a separate license for each VM, essentially treating each VM as an independent piece of hardware.
Here are some examples that will hopefully clarify things.
Example 1
This configuration shows a server machine with 1 physical CPU chip with 1 core. Two virtual environments (VEs) have been created. Two instances of SQL Anywhere are running on one VE and one instances is running on the other.
Licensing:
Chip based – Each physical chip on which you wish to run SAP SQL Anywhere must be licensed. In this case, a single chip license must be purchased. This permits an unlimited number of instances of the database server on that licensed chip.
Server & Users – Each VE running a database server needs a database server license. There are 2 VEs. Each licensed VE can permit an unlimited number of instances. Therefore, 2 database server licenses are required, plus a user license for each user connecting to each server.
Example 2
This configuration shows a box with 2 dual core CPU chips. Two VEs have been created. Two instances of SQL Anywhere are running on one VE and one instance is running on the other.
Licensing:
Chip based – Each physical chip on which you wish to run SAP SQL Anywhere must be licensed. There are 2 physical chips, therefore, 2 chip licenses are required.
Server & Users – Each VE running a database server needs a database server license. There are 2 VEs. Therefore, 2 database server licenses are required, plus a user license for each user connecting to each server.
Example 3
This configuration shows a box with 4 CPU chips. Five VEs have been created. Four VEs are running SQL Anywhere accessing a single CPU chip. The Fifth VE is running SQL Anywhere accessing two CPU chips.
Licensing:
CPU based – Each physical chip on which you wish to run SAP SQL Anywhere must be licensed. There are 4 physical CPU chips, therefore, 4 chip licenses are required.
Server & Seat – Each VE running a database server needs a database server license. There are 5 VEs. Therefore, 5 database server licenses are required, plus a user license for each user seat connecting to each server.
Thanks for the great overview.
However, for the latest SQL Anywhere licensing, I notice that there is only a "chip" and a "user" type license; I don't see any "server" license. Am I missing something? ASE still follows the licensing model you mentioned here, however.
Also, if I am correct that there's no "server" licensing, how does this impact the virtualization licensing model that you've described above?
IMHO for a user license (type "perseat") the licence count is the number of different "machines" that may connect to a server simultaneously, whereas for a server licences (type "processor") the licence count is the number of CPU sockets which can be used by the engine.
So I think "Server" and "User" may be seen as sales terms, while "seat" and "processor" differenciate the licence type technically.
Reimer is basically correct. The server is licensed either by "user" (a license for each user that connects to the server), or by the number of "chips" (physical CPUs) the server uses (with an unlimited number of users able to connect to it).
--Jason
Thanks for the replies!
So how does this impact the virtualization licensing examples shown above?
Let's take "Example 3". If I'm licensing by "user", I still need a user license for every user on every DB server... so 10 users per DB server means 10 users/DB server x 5 DB servers = 50 user licenses for the full environment?
And what if one of the "users" (devices) is the same for more than one DB server? Does it need to be separately licensed for each DB server it accesses? Or would it just be one license?
If you are licensing by server, one user license is good for one user connecting to one server. If that user connects to another server, they would need another user license for that server.
So in example 3, to license by user, you need to purchase a server edition for each VM (workgroup, standard or advanced). Each of those base server editions comes with a certain number of user licenses (workgroup and standard editions come with 5 user licenses, advanced edition comes with 25 user licenses). If you need more user licenses, you would purchase them separately as you need them.
You can see the various options for purchase on the sap store:
https://store.sap.com/sap/cpa/ui/resources/store/html/Search.html?pcntry=US&sap-language=EN&catID=&searchText=sql%20anyw…
A short discussion with a sales person would probably be a better/faster way to handle your more detailed questions, as they can change slightly based on your specific use case. For example, in some cases there is the possibility of volume discounts, and if you are OEMing SQL Anywhere (embedding it inside a product for resale) the way licenses are counted/purchased is a little different, etc...
--Jason
I've spent a fair amount of time with the SAP Store licensing write-ups, as they are quite good; although they didn't cover every area we wanted addressed.
Some of the other channels I've tried to get answers through, didn't work out as well as what I can get through SCN... PartnerEdge, etc.
Once again, I really appreciate the help. Feel free to PM me, if there's anything else you could suggest for us to explore.
Hi Jason,
In Example 2: When I'm only using VM1 and the 4 CPU's are divided over 2 blades (2 CPU's each, the VE uses 2 CPU's, but can switch from one blade to the other), do I still need 2 CHIP-licenses?
And if so, how do I use the two licensekeys? If I buy 2 CHIP-licenses I will probably get 2 keys, but there is only one input field during the installation....
Thanks in advance for your help!
Remy
If the VM is limited to 2CPUs, then licensing 2 physical CPUS would be fine.
As far as the license keys go, you can use either one for the install.
Thanks for the quick response.
If I understand you correctly this means that 1 CHIP license (Workgroup edition) will do, as long as the VE uses not more than 2 CPU's at once.
Can you confirm this?
What I meant was that you don't have to license all chips on both machines (ie. 4 chips).
If the VM uses 2CPUS, which map to 2 physical chips when it is running, then you need to license 2 chips to allow the server to use both of those VM CPUs.