We have a Solarwinds SQL server but the problem is it is not just a Solarwinds SQL server.
It has 12 other databases running on it.
It is 2008R2 with SQL 2008 R2 Standard.
So...Solarwinds is running really slowly because another database appears to be using all the resources on the current SQL server.
I decided I would try and spec a new SQL server for Solarwinds and i've slipped down the rabbit hole into SQL server licensing.
Any ideas, how I proceed, SQL cluster? or just a standalone SQL server?
I am trying to think of ideas about how to keep the existing database running despite it being stuck amongst other 200GB SQL databases on its existing home. I wish this was a 2016/17 SQL server... Maybe if I stare at it long enough it will upgrade and transform into something usable.
I've done some more research with my friend from Microsoft regarding SQL licensing for SQL Standard edition specifically.
There are 4 types of licenses I have seen for sale on SQL licensing websites.
SQL CPU Core
1. Processor Licensing Model
A license is required for each physical or virtual processor accessed by an operating system environment running SQL Server.
This license does not require any device or user client access licenses (CALs).
Under this structure, a customer acquires a separate Processor license for each processor that is located in the server running the SQL Server software.
If you have made a processor inaccessible to all operating system copies on which the SQL Server software is set up to run, you do not need a software license for that processor.
This licensing model is most appropriate for applications that are accessible through the Internet and for internal applications with a high client-to-server ratio.
So we have one Orion SQL server with loads of cores and this will cost a lot.
2. Server Plus Device CALs Licensing Model
Server plus device client access license (CAL) licensing requires a separate Server license (for either SQL Server 2005 Standard Edition or Enterprise Edition) for each server on which the software is installed, plus a CAL for each client device.
A SQL Server CAL is required for a device (for example, a personal computer, workstation, terminal, personal digital assistant, or mobile phone) to access or use the services or functionality of either edition of SQL Server.
So we have one SQL server and one Solarwinds poller server (device) so we need one SQL Server Standard license and one SQL device license. (BEST OPTION)
3. Server Plus User CALs Licensing Model
Server plus user client access license (CAL) licensing requires a separate Server license for each server on which the software is installed, plus a user CAL for each user accessing the server.
A SQL Server CAL is required for a user to access or use the services or functionality of either edition of SQL Server.
So we have one SQL Server and loads of users. This model is not good for us as we will have to pay per user instead of per device.
I've spoken to some licensing vendors who specify that you must have User CAL's as well as Device CAL's as well as CPU core licenses. It makes me laugh how misunderstood SQL licensing is, even the vendors have trouble.
If you have a Server CAL with Device CAL's you don't need user CAL's and you can utilise all of your 24 CPU Cores for Standard edition without buying those expensive CPU Core licenses.
You are licensing the server not the cores.
For Solarwinds using a Server+Device CAL is great because its cheap and all Solarwinds users go through this device so essentially its only one device (the main poller server) accessing the SQL database.
You can always buy more Device CAL's if you decide to separate out your Solarwinds functionality.
Also check out this advice reinforcing the Device CAL licensing route from Solarwinds : MS SQL Server licensing recommendations for SolarWinds products - SolarWinds Worldwide, LLC. Help an...
Okay, I've been talking to my friend at Microsoft the one that gave me the information above previously about Multiplexing. He pointed me here :
The Multiplexing Trap
You already know that most Microsoft server products require Client Access Licenses (CALs), which comprise a majority of total licensing costs for those products. In general, all employees or on-site contractors accessing instances of a server product that require user CALs need CALs for themselves or for the devices they use to access the server product.
What you may not realize is that a CAL is also required for users or devices that indirectly access server product instances through an intermediary, a scenario Microsoft refers to as multiplexing. This means that integrating two systems can obligate an organization to buy many more CALs than they might expect.
For example, an organization might synchronize cost and timesheet data between its enterprise resource planning (ERP) system and Microsoft’s Project Server, a project management server application. In that case, the organization needs Project Server CALs for all employees that use the ERP system, even if they never use Project Server directly.
So the question i'd like to ask Solarwinds is, do we have to go down the per core route after all because the solarwinds web server acts as a multiplex pooling hardware device?
Even Microsoft auditors and employees seem to be confused about this...
That's a really scary diagram. I'm currently quoting a client for a complete platform refresh, and one of the elements is moving to SQL Server 2016/17.
Trying to work out the licensing required for this is a nightmare before you even consider Multiplexing. If the Project Server example is correct, then effectively device which is sending NetFlow data to Orion would need a device CAL, since they indirectly communicate with the new SQL-based NFDB. Almost makes me want to quote for the per-core licensing, just to be on the safe side, since apparently if you're on per-core, it's all you can eat with regards to access to that SQL Instance and it's databases.
...or is it?
Why does Microsoft insist in shooting themselves in the foot? When the licensing vendors haven't got a clue, it's clearly not a fit for purpose system
If you go to Solarwinds and ask for help they won't comment. silverbacksays by the above logic we could determine that every single monitored device is communicating with SQL and in that case requires a device CAL too. Let us assume that Microsoft wouldn't do that... they wouldn't... or would they?
At this point I don't think we can assume anything. From SWI's perspective, the database portion of our all conquering software is out of scope of their support. Perhaps sqlrockstar could chime in with his Godly knowledge and experience with all things SQL, but this really is out of scope for SWI as a vendor. It's down to each end user to have their discussions with Microsoft or their chosen licensing vendor and wade through this themselves.
The closest thing we have to an official response is in the links you shared in the opening gambit, although that first link surprised me by advising how to license SQL if it's installed on the same server as the primary Orion polling engine. That's not supported in production by SWI, so why even give guidance on it? Madness!
Personally, I'd love to be able to recommend Server+CAL licensing, but I'm not so sure that works in the per-core era of MS licensing
The only thing I'm happy with is that if I license the cores, I can forget about worrying about CALs. But that's so hideously expensive for all but the largest organisations when specifying a server which meets the new 2018.2 orion core requirements, I'm sure it blows a lot of quotes out of the water right there, never mind the SWI licensing
SQL Server licensing (and most of Microsoft products) is intentionally vague. Here's a link to their guide for SQL 2016: http://download.microsoft.com/download/9/C/6/9C6EB70A-8D52-48F4-9F04-08970411B7A3/SQL_Server_2016_Li...
This entire thread is but one example of what I see whenever someone tries to figure out how to license SQL Server. My advice is always the same: talk to your Microsoft rep. 99% of the time they want to work out the details in order to keep you a customer.
As for CALs versus cores, I like to remind folks that you can license an entire VM host and then put as many SQL Server instances as you want attached to that host. It's a good way to reduce costs, as you only pay for the host, and not for the VM, or the instances. If you already have some database server hosts, just carve out some space. Sometimes people see this and suddenly realize they've been overpaying for their current SQL installs, and by building out two dedicated hosts they can save a ton of money.
Just don't tell Microsoft I told you this, and don't ask for a refund from the money you may have been overpaying.
"Server application software under the Per Core license model is licensed one of two ways: by virtual core or by physical core. VMs running Standard editions are licensed by virtual core only. VMs running Enterprise editions are licensed by virtual core or by physical core. In the case of virtual core licensing, each virtual core allocated to a VM requires a core license, with a minimum of four core licenses per VM. Customers may run any number of instances of the server software in each licensed VM. Alternatively, when all physical cores on the server are licensed for SQL Server Enterprise, customers can run an unlimited number of instances of the software in a number of VMs equal to the number of core licenses assigned to the server. Customer has the option to run SQL Server in the physical OSE in lieu of one of the permitted VMs. For example, a four-processor server with four cores per processor—fully licensed with 16 core licenses—could run SQL Server software in up to 16 VMs, regardless of the number of virtual cores allocated to each VM."
Small companies that I work with, would be forced to move to different monitoring platforms if we were forced to move to core licensing for SQL. It would be a horrible situation.
The main issue we have with trying to advise clients on SQL licensing, is what is and is not deemed as a connection to the database. It's a difficult question for many reasons:
If we had a baseline number to work from, presented in an official KB which is written in plain English, at least we could be confidant in a start point for SQL licensing. I'm working on a new quote at the moment which includes SQL licensing, and even my reseller is grasping at straws!
I've had to deploy on Express before now, when a client desperately needed the functionality of Orion, but couldn't afford the SQL licensing.
Minimal retention periods and careful node number balancing, but it can work. SL250 level licensing should run OK on it for a fairly long time before the database size limit becomes an issue. Just forget about using SysLogs in those environments, impact on the database size is too high to risk.
I've never done this willingly, I have to add. But as long as it's disclaimer heavy and the database size is closely monitored, it can be done.
We don't talk about SQL Express here. It is a dirty word.
Some of the companies i've worked for tend to be quite slow when managing their Solarwinds database mainly due to change control restrictions. At least with SQL express allowing 10GB of data its a little more useful.
There is definitely a requirement even though Solarwinds say it isn't on their technology roadmap, for an alternative to MS SQL.
Is that right? I'm not on any beta tests but I was under the impression it would be an option to continue with FastBit storage or migrate to SQL2016? Surely they can't just pull support for the flow storage and thus keep everyone on the current version? Purchasing an additional SQL Licence might not cut it with a lot of customers. I might have to pay more attention to the upcoming NTA release
We just have one polling engine. Total element count is :
NETWORK NODE ELEMENTS
SolarWindsOrion Platform 2017.1,
SAM 6.4.0, ---- 6.5 requires 2012.
We are currently on WIN 2008/SQL 21012, and moving to WIN 2016/SQL 2016 next month. We, over time have had to move to 128 GB RAM due to serious I/O on our system with 8 APEs and over 100,000 elements. After tweaking, we did get MEM down to an avg. of about 85 GB.
You should strive for a non-shared DB. Looks like you are a smaller shop, so my data is over the top.
You definitely want to try to upgrade to SQL 2016 if at all possible.
I do have the luxury of flash storage, so that is a plus.
* OS(WIN 2008) are already mapped to be deprecated for solarwinds support at EOY 2018, so that is a bullet point you can put in front of management too.
Will certainly mention that to management when proposing the upgrade path. You are right this shop is fairly small, mainly because a lot of the stuff they have isn't monitored. We are changing that slowly and as we do their requirements will grow along with the SQL database.
Based on the number of connections that will be made to the SQL server, I would recommend the following:
OS: Windows Server 2012R2/2016
SQL: SQL Server 2012/2014/2016 Standard
CPU: 4-8 Cores @ 3GHz, 8 Cores recommended
MEM: 16-32GB, 32GB recommended
Disk1 (OS): 40GB free space
Disk2 (DATA): the size of the Orion database x 1.5
Disk3 (LOG): 30GB free space
Disk4 (TEMP): 30GB free space
NIC: 1-10G, 4G recommended minimum
Licensing: If CAL based then it should reflect the number of users. If CPU based then either 4 or 8, depending on how many CPUs you will allocate.
Notes: The storage should preferably be SSD based for best performance, or else you should follow the recommendations documented in the NPM vXX.X system requirements under hard drive space.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.