Your servers are either provisioned or racked, your sys admin has taken care of installing the Failover Clustering feature and creating the cluster itself, so you’re good to go to start installing SQL Server right? Not quite – you still need a few other things and unless you’re a in a jack-of-all-trades role, you may need to request some of them from others.
Each clustered instance that you install will have a network name attached to it so that you don’t have to know exactly which node the instance resides on in order to connect to it. To create the network name, you’ll need an IP. Check with your network admins – they most likely have a subnet range dedicated to SQL Server and should be able to provide this to you quickly.
Computer Objects Created in Active Directory
Along with an IP address, a computer object is also required for the network name portion of the install. So if the full name for the instance you’re installing is SQL-123\MyInstance, a computer object with the name SQL-123 needs to be created. Alternatively, this can be done as part of the install if the account you’re using has permissions to do so.
Service accounts should not be passed down through generations of DBAs at your company like old family recipes. Request a new one for each new SQL Server service you install. This reduces expsosure of any single account so that an accidental lockout or password expiration is an isolated event instead of a disaster.
Lastly, you’ll need some SAN storage to host the databases your users are about to take advantage of (in more ways than one). I recommend requesting, at minimum, five volumes – a small, 1GB volume for the root/drive letter, and then a separate volume for data, log, system, and tempDB. Make use of mount points and attach each data, log, system, and tempDB volume to its own folder under the root so you don’t need to use additional drive letters. Scared to talk to your SAN admin? Check out my previous post on how to make your storage administrator your best friend.