Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

License SQL 2014 - Cores Expand / Collapse
Author
Message
Posted Tuesday, April 8, 2014 10:49 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, July 8, 2014 7:45 AM
Points: 163, Visits: 602
Hi -

Hypothetical situation:

I have a 32 core server. SQL 2014 enterprise installed. The server licensed for 32 cores.
Question raised - can we decrease the cores licensed down to 16, and do it quickly?

Any information provided is greatly appreciated.
Post #1559580
Posted Wednesday, April 9, 2014 4:55 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 3:38 AM
Points: 1,853, Visits: 2,961
Assuming it's 4 octocore processors, take out 2 of them.

Edit: Sorry, that's a bit abrupt but it's the quickest way I can think of

Alternatively create a VM on the server, assign max 16 cores to it & install SQL on that.

I'm not up on SQL 2014 licensing but in earlier version MS didn't allow you to use processor affinity to control licensing so can't think of other ways.
Post #1559870
Posted Wednesday, April 9, 2014 7:14 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, July 16, 2014 2:07 AM
Points: 21, Visits: 183
There is some information regarding this under the Read the SQL Server 2014 Licensing Datasheet
Post #1559925
Posted Wednesday, April 9, 2014 7:47 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 3:05 PM
Points: 325, Visits: 3,187
Gazareth (4/9/2014)
Assuming it's 4 octocore processors, take out 2 of them.

Edit: Sorry, that's a bit abrupt but it's the quickest way I can think of

Alternatively create a VM on the server, assign max 16 cores to it & install SQL on that.

I'm not up on SQL 2014 licensing but in earlier version MS didn't allow you to use processor affinity to control licensing so can't think of other ways.


Unfortunately, even you have 16 vcores max, if those 16 vcores can hit 32 pCores you have to license all the pCores. At least that's what I was told last time I spoke to MS.


I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
Post #1559947
Posted Wednesday, April 9, 2014 8:07 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 3:38 AM
Points: 1,853, Visits: 2,961
andrew gothard (4/9/2014)
Gazareth (4/9/2014)
Assuming it's 4 octocore processors, take out 2 of them.

Edit: Sorry, that's a bit abrupt but it's the quickest way I can think of

Alternatively create a VM on the server, assign max 16 cores to it & install SQL on that.

I'm not up on SQL 2014 licensing but in earlier version MS didn't allow you to use processor affinity to control licensing so can't think of other ways.


Unfortunately, even you have 16 vcores max, if those 16 vcores can hit 32 pCores you have to license all the pCores. At least that's what I was told last time I spoke to MS.


I was a bit unsure on that myself, but from the Licensing Datasheet:

"To license a VM with core licenses, purchase a core
license for each virtual core (virtual thread) allocated to
the VM (with a minimum of 4 core licenses per VM)."
Post #1559965
Posted Wednesday, April 9, 2014 8:45 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 2:28 AM
Points: 1,223, Visits: 9,619
Gazareth (4/9/2014)
andrew gothard (4/9/2014)
Gazareth (4/9/2014)
Assuming it's 4 octocore processors, take out 2 of them.

Edit: Sorry, that's a bit abrupt but it's the quickest way I can think of

Alternatively create a VM on the server, assign max 16 cores to it & install SQL on that.

I'm not up on SQL 2014 licensing but in earlier version MS didn't allow you to use processor affinity to control licensing so can't think of other ways.


Unfortunately, even you have 16 vcores max, if those 16 vcores can hit 32 pCores you have to license all the pCores. At least that's what I was told last time I spoke to MS.


I was a bit unsure on that myself, but from the Licensing Datasheet:

"To license a VM with core licenses, purchase a core
license for each virtual core (virtual thread) allocated to
the VM (with a minimum of 4 core licenses per VM)."


Yep, I don't think you need affinity on the underlying physical cores, as long as the number of vCPUs matches the licensed cores.

Incidentally, the vCPU cores are tied to a single physical host, so you are not entitled to use vMotion or similar technology within a VM farm, where you may move between different physical hosts from time to time. You need Software Assurance to be allowed to do that.
Post #1559997
Posted Wednesday, April 9, 2014 8:57 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Wednesday, July 16, 2014 2:50 AM
Points: 2,854, Visits: 3,174
Our discussions with Microsoft and its license resellers have shown that the following is accepted:

If you set processor affinity to match the number of cores you have licensed, then you can validly license fewer cores than are available to Windows. This applies to both physical and virtual instances of Windows.

The licensing must cover all cores that you are using. If you have a 32-core box and you use affinity to set 8 cores for IO usage and a different 8 for CPU workload that is 16 cores you must have a license for.


Original author: SQL Server FineBuild 1-click install and best practice configuration of SQL Server 2014, 2012, 2008 R2, 2008 and 2005. 29 May 2014: now over 29,000 downloads.
Disclaimer: All information provided is a personal opinion that may not match reality.
Concept: "Pizza Apartheid" - the discrimination that separates those who earn enough in one day to buy a pizza if they want one, from those who can not.
Post #1560006
Posted Wednesday, April 9, 2014 9:03 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 2:28 AM
Points: 1,223, Visits: 9,619
EdVassie (4/9/2014)
Our discussions with Microsoft and its license resellers have shown that the following is accepted:

If you set processor affinity to match the number of cores you have licensed, then you can validly license fewer cores than are available to Windows. This applies to both physical and virtual instances of Windows.

The licensing must cover all cores that you are using. If you have a 32-core box and you use affinity to set 8 cores for IO usage and a different 8 for CPU workload that is 16 cores you must have a license for.


I've spoken to a few people who have had similar conversations with resellers and still found themselves coming unstuck when they got audited.

Unless something's changed since we last looked at this, setting processor affinity is not valid. For one, that only affects the core database engine, not other elements (like SSIS, SSAS for example) and I think even CLR and service broker. There's nothing on paper from Microsoft declaring these settings have any impact on licensing.
Post #1560009
Posted Wednesday, April 9, 2014 9:08 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Wednesday, July 16, 2014 2:50 AM
Points: 2,854, Visits: 3,174
The moral is that you need to work this out with your license reseller. Be up-front about what you plan to do, and get their agreement. If the license reseller gets things wrong, Microsoft should stick to the agreed terms of your contract for the life of the license.

Original author: SQL Server FineBuild 1-click install and best practice configuration of SQL Server 2014, 2012, 2008 R2, 2008 and 2005. 29 May 2014: now over 29,000 downloads.
Disclaimer: All information provided is a personal opinion that may not match reality.
Concept: "Pizza Apartheid" - the discrimination that separates those who earn enough in one day to buy a pizza if they want one, from those who can not.
Post #1560011
Posted Saturday, April 12, 2014 6:14 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 3:05 PM
Points: 325, Visits: 3,187
HowardW (4/9/2014)
EdVassie (4/9/2014)
Our discussions with Microsoft and its license resellers have shown that the following is accepted:

If you set processor affinity to match the number of cores you have licensed, then you can validly license fewer cores than are available to Windows. This applies to both physical and virtual instances of Windows.

The licensing must cover all cores that you are using. If you have a 32-core box and you use affinity to set 8 cores for IO usage and a different 8 for CPU workload that is 16 cores you must have a license for.


I've spoken to a few people who have had similar conversations with resellers and still found themselves coming unstuck when they got audited.

Unless something's changed since we last looked at this, setting processor affinity is not valid. For one, that only affects the core database engine, not other elements (like SSIS, SSAS for example) and I think even CLR and service broker. There's nothing on paper from Microsoft declaring these settings have any impact on licensing.


Aye, we were told that any core you can hit, you license. If someone ballses up and hits non licenced cores by accident, as long as you show reasonable efforts have been made to prevent it, they reserve the right to go easy. It's not guaranteed they will. Apart from anything else, your cores should be SQL Server only. You shouldn't be having your SQL Server VM's, for example, wandering all over your server farm. For about (or aboot if you're Canadian) a million reasons. Brent Ozar covers this very well


I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
Post #1561246
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse