Continued from Part 1 – here.
8. DO use SCCM/WSUS for patching
For heavens sake, DON’T have firewall rules in your environment allowing all servers to talk outbound to the internet. WHEN they infiltrate your environment, you’ll have given them an easy exit with your data.
Block all internet bound traffic from your servers and monitor the blocking. Allow only key services and send them all via a proxy – by exception! Get WSUS to collect the patches you need and distribute them internally in a safe and controlled manner.
9. DO use VLANS on your Hyper-V switches – Get VMM to do the donkey work
Networks & IP pools in VMM are a wonderful thing. Set a VLAN, Static MAC and Static IP’s – all handled on build automatically. Make the most of this feature to keep tabs on your infrastructure. There’s no need to go back and forth to your IPAM tools for VM deployments.
Removing native networks and DHCP prevents a poorly configured VM from gaining access to anything it shouldn’t be talking to.
10. DON’T Mix and match CPU/Memory types in a cluster
Whilst it’s entirely possible to do so, you’ll end up compromising on performance of your VM’s. Everything will require CPU compatibility mode enabled (VM shutdown required to enable).
You will also be adding complexity to cluster capacity issues. Draining a host with 1tb of ram across a selection of 256gb hosts will be possible (provided no single VMs exist with memory assigned greater than 256gb), but sustaining node failures will become a complex calculation, rather than being able to tell at a glance.
If you are purchasing new nodes to expand your environment, then group them together and create a new cluster. Utilise live storage migrations between clusters – or – if using SMB3 storage, just simply live migrate the VM between clusters.
11. SQL per CPU host licencing on Hyper-V – beware!
Example: You have a Hyper-V cluster with 10 nodes, 2 processors per node (20 processors total) and you decide you want to use 2 nodes for SQL enterprise licensing on a per host CPU basis (4 CPU licences),
In short, a VM that has a licence covered by a host could potentially exist on any of the 10 nodes in your cluster. It does not matter about the settings on the VM defining the host it will reside on, it could be powered on, on any of the ten hosts and as such it is likely you would be seen to have fallen short of the required licences.
You would be best off removing 3 nodes from your existing cluster and creating a separate Hyper-V cluster dedicated for the SQL workloads and licences. Two nodes of running VM’s with a single empty host (which allows for a node failure/maintenance). This clearly shows your used hosts and your hot standby for a failure.
If in doubt – contact a licencing specialist company and get it checked and double checked. You do not want a bill in the post for the 8 remaining nodes 🙂
12. DO configure everything in PowerShell and DO retain it elsewhere
There’s many ways to automate the build of your hosts, SCVMM/SCCM or third party products, even LUN cloning (if boot from SAN). However, if you are manually building for any reason at all, then prepare the config and retain it afterwards. If the worst occurs, you can be back up and running in no time at all.
13. DO have a separate VLAN and address range for your host networks and DO keep them in step!
Make life easier for yourself. If you have 10 nodes, get 10 concurrent IP addresses from each of the ranges you may require (Management, Cluster-HB, Live Migration etc…) and make them the same last octet. Example:
- Mgmt: 10.0.1.11
- ClusterHB: 188.8.131.52
- Live Migration: 192.168.8.11
- Mgmt: 10.0.1.12
- ClusterHB: 184.108.40.206
- Live Migration: 192.168.8.12
And so on…. this will make your life easier in the long run. Keep these subnets away from any other use – so when you grow, you have more concurrent IP’s available.
If you ever need to revisit and reconfigure anything remotely via powershell, complexity will be reduced.
14. DO standardise your naming convention and use scripting/deployment tools!
As per the above points, name your network adaptors the same on every node – example:
- MGMT-Team-NIC1, MGMT-Team-NIC2 –> MGMT-Team
- LM-Team-NIC1, LM-Team-NI2 –> LM-Team
- SMB-NIC1, SMB-NIC2
- iSCSI-NIC1, iSCSI-NIC2
Again, when using PowerShell to build/configure it is easy to maintain convention and will save you countless config headaches over time.