SharePoint Scalability comes up in most conversations we have with customers. What do you do if you outgrow your environment? Plan for it!
We host quite a few SharePoint farms here at Fpweb.net and typically, our customers opt to start with a single server or a smaller farm with the intention of adding resources on an as-needed basis. We make it clear that each SharePoint environment is ‘flexible’ and can be scaled easily. It’s a sensible approach to hosting.
Why pay more for what you need until you need it?
Eventually the time comes when a SharePoint farm is maxed out and requires more resources. At this point, one of the dedicated SharePoint Engineers here at Fpweb.net works with the client to determine what resources are needed. Sometimes it’s a matter of increasing RAM, VPU, or Hard Drive storage. On occasion, however, a farm will require something more than just additional memory or storage… it needs new servers.
Now in farms that already consist of multiple servers, this isn’t a problem. Spin up the new server, join it to the farm, and assign the appropriate roles and services to it. Easy scalability is one of SharePoint’s strong suits.
But when a single server farm suddenly needs to break into a two server farm… well, that’s an entirely different story. Some of our customers choose to introduce themselves to SharePoint with our SharePoint Enterprise plan. This is simply a single VM (virtual machine) which has all roles necessary for SharePoint: Active Directory, Microsoft SQL, and SharePoint.
So in these instances we have a couple options:
- We can create a new WFE (Web Front End), join it to the farm and then remove SharePoint from the original server. The problem with this approach is if custom components or 3rd party solutions have been installed, they will have to be re-installed on the new WFE. And sometimes, this isn’t easy.Maybe a consultant company originally set up the environment and the client wasn’t given detailed installation directions so they can’t replicate it. Sometimes, a developer installed the solution and is now no longer with the company. Basically, there’s any number of reasons why installing 3rd party solutions and web parts can be problematic. Best to avoid the need for re-installation, if possible (it is possible though – read on…).
- We can create a new database server, make it a domain controller in the environment, move the FSMO (Flexible Single Master Operation) roles, and then move the databases. We can then remove SharePoint from the old farm and add it to the new farm.The problem with this approach is that it can be time consuming and moving Active Directory FSMO roles sometimes doesn’t work as expected. And in my personal opinion, I never feel comfortable removing a server from the farm. I’ve had too many problems when trying to rejoin it.
The approach we take depends on the environment. If there are no SharePoint customizations and it’s a pretty vanilla installation, we’ll take the first approach.
If SharePoint has been customized, we’ll take the second approach.
…Or, at least, this is how we use to do it.
Now, we just configure SharePoint with the expectation that a client will need to upgrade in the future.
How we configure SharePoint so it can be scaled easily:
We create a SQL Alias in Active Directory. This allows us to create a new SQL Server, copy the databases, and point SharePoint to the new SQL Server without making any changes to SharePoint. This approach makes upgrades, migrations, and troubleshooting easier.
So now when we have to move a SharePoint’s SQL Database, it can easily be done by simply adjusting the record.
How to create an alias
The ideal situation is to have an alias created before you install SharePoint. Doing so will make life much easier down the road if you have to make changes to SQL Server.
- Open DNS Manager.
- Expand Forward Lookup Zone.
- Right-click on the domain and choose New Alias (CName)
- The New Host dialog box will open.
- In the Name field, type the alias you want to use.
- In the IP Address field, type the IP address to the SQL Server.
Now, whenever you use the alias, it will resolve to the configured IP address.
So when you run the SharePoint Configuration Wizard and create the configDB, use the alias name.
If later on you need to move SQL Server, all you need to do is update the IP address in the Alias name. No changes necessary in SharePoint. In fact, SharePoint won’t even know the SQL Server was moved, because it’s still using the alias you’ve configured to access SQL.
That’s all fine and great… but what if you’ve already installed SharePoint without an alias and need to move SQL Server?
There’s an easy way to do that… but you’ll have to wait for my next blog for the solution! Thanks for reading. As always, please let me know if you have any questions!