This is one part of a 5 part series highlighting where DBAs can deploy SQL Server databases. The 5 places where your SQL database can live are:
- Physical server
- Virtual server
- Cloud server :IaaS – Azure VM or AWS EC2
- Cloud instance :PaaS – Azure Managed Instance
- Cloud database :DBaaS – Azure SQL Database or AWS RDS
Now, installing the SQL Server database on a physical server may take us back to the “(g)olden days” of data centers, the pre-ESXi days, the days of racks, and MORE racks of servers and storage and networking and cables… remember the cables?!?!??! I took pride in my cabling, measured and ordered the lengths, colors, proper wraps, and even labeling. I actually found it therapeutic on some projects to make the cabling flawless.
But we don’t think of installing SQL Server on physical servers just for old-timers and relics shouting obscenities at Clouds, there are real use cases for physical servers today!
Top 5 (or 6) Pros to installing SQL Server database on a physical server
- Zero performance loss
- No “vmware tax”, no noisy neighbors, etc
- Exact processor selection
- Performance improvement every year from Intel
- Glenn Berry writes FANTASTIC blogs on this
- As few as 4 cores up to 56 cores in a basic 2-socket server – nothing too fancy here
- Your total SQL Server cost is directly tied to the processor you select – CHOOSE WISELY
- Capitalized/Depreciated expense
- Accountants love this, and most companies are more comfortable with this method of purchasing in IT
- One-time cost (mostly)
- Depreciated over 2 or 3 years?
- If performance really is crucial enough to be going with physical hardware, why not upgrade every year if you care about Pros 1 and 2.
- Comfort level
- You can go pet it!
- 100% control of entire stack – OCD much?
- Securing your data
- When done properly (read: expensively with a team of security engineers) everyone in the organization can be 100% confident no one has access to your data besides you
- New technologies
- Buying a physical server will be the only way you can take advantage of some great new hardware
- Intel’s 3D-Xpoint Optane NVMe SSDs
- New persistent memory class of devices
Top 5 (or so) Cons to a physical SQL Server Database
- Performance may not match the workload exactly
- Means we must upgrade again OR we spent too much money initially
- Some upgrades are easy – RAM, add more disks
- Some upgrades are difficult
- Add more disks and have to rebuild RAID?
- Add more CPU – replace processors, no returns!!
- And pay additional licensing…
- Means we must upgrade again OR we spent too much money initially
- High availability challenges
- Can’t do Failover Cluster without shared storage… adds expense
- Can still use replication, mirroring, Availability Groups
- Backups
- How fast can we get your data OFF that physical server and land it somewhere else?
- How fast can that backup be restored to another box?
- Think about SPOFs beyond the database
- Datacenter power? A/B power?
- Backup power – diesel delivery…
- Redundant power supplies
- Redundant networking, switching
- Fire suppression?
- Video surveillance
- HVAC… and more I’m sure!
- Datacenter power? A/B power?
- Physical security
- May not be able to pass SOC 1/2 audits!!!
- Move to colocatiuon facility for some ease
- Significant effort will be required if the business mandates compliance
- Spare parts in stock?
- What spare parts do we keep on-site?
- Do we pay the vendor extra for 4HR parts support vs next business day?
- Location
- Are the physical servers close to the application servers and are they close to your users where they work?
- Is that also in a location that also has good power, not prone to flooding, managed by a company that pays its bills and has multiple ISPs?
If we must absolutely, positively have the fastest SQL server for the money – we can build it ourselves selecting the exact CPU, high performance RAM, get the latest technology in persistent memory and NVMe goodness and eliminate every know bottleneck! There are still LOTS of applications for this, don’t think that because we are considering buying a server for SQL that we are already down the “wrong” path.
Tips:
- NEVER take an older server and install SQL Server on it for production
- Licensing and ALL the reasons (every single one) are too important to waste money here
- DISKs will be your slowest part of the stack
- Invest in RAM where you can to cache as much data as possible
- RAID10 everything (no BUTs about it)
- NVMe PCI-Express SSDs for all you can afford
- NO SATA SSDs (even if they are superfast in your laptop)
Here are two recent SQL Server database builds of mine for clients with very specific requirements for performance, proximity to application servers, and licensing restrictions.
Use cases:
- Small 200GB database in an OLTP system
- ~$17,000 to do it RIGHT
- Dell PowerEdge R340 – ~$6000
- Single Xeon E3-2174G with 4 cores at 3.8GHz
- 128GB RAM
- Redundant PSU, Intel NICs, all the Enterprise basics
- Add mirrored 1TB PCI-Express based NVMe – $3,000
- Intel Optane 905P (x2 remember)
- SQL Server Standard licensing ~$8,000
- Yes you can go cheaper on the hardware
- but WHY if you’re paying $8k JUST for the license… DON’T DO IT!!!!
- Large 1.2TB database for a mixed workload (transactional, reporting, and SSIS)
- ~$206,400 to get a very nice solution in place
- HPE DL380 Gen10 – $30,0000
- 2x Xeon Gold 6146 with 24 cores at 3.2GHz
- 576GB RAM
- 96GB pMem for TempDB and Log files
- All the Enterprise basics
- Add 4x Optane NVMe based SSDs – $8,400
- RAID10
- SQL Server Enterprise licensing ~$168,000
- Required to use more than 128GB of RAM
- No other hardware enabled features
- Lots of other goodies (for another blog)
- AGAIN – DO NOT HESITATE to upgrade that hardware component for $5,000 if it does not affect licensing
- PBITPro can help you calculate your CPU core requirements to get that CPU selection and licensing cost nailed down
- The rest of the build is <10% of the total cost so DON’T SKIMP
- High Availability
- Take your “small” or “large” server build and double it!
- Works as a failover replica for mirroring, log shipping, replication, and Availability Groups
- For Failover Clustering, shared storage is the best way to get there
- Add-on SAS based storage like HPE MSA 2050
- Add-on iSCSI based storage like Nimble AF1000
- This gains additional features as well like storage snapshots and tiering
- Take your “small” or “large” server build and double it!
Choosing physical servers for your SQL Server deployment does have its advantages, but as we learn more about modern implementations of databases we might find some better methods to storing our data! Did you recently deploy SQL Server this way? What was the biggest reason you selected this implementation?