Planning your Server Farm (Part 1)
"For a complete guide to security, check out ''Security+ Study Guide and DVD Training System'' from Amazon.com
Please read Planning your Server Farm (Part 2).
It’s very important to always plan and consider design when you do just about anything in your life. If you want to get a new bank account, you research what you want and select from options what best suits your needs. Buying a mobile telephone service is very much the same process, but at a different scope, instead of worrying about what accounts you need (checking, savings), you are worrying about different things, such as Phone type that services the needs you want, as well as the provider’s services, what do they offer and what does their competition offer? When designing a server farm, the amount of information needed, planning and design is unbelievably multiplied, especially if the size of the company you are working within is at the enterprise level with a global reach. How do you plan for access into your server farm to gain resources? Where do you place it? What are some of the considerations you should take into account? In this article we will cover as much about planning as possible, although each network (and situation) is unique – these tips are fairly generic and can be used in any company’s network, just make sure you tailor and tweak your plans beyond this article if you are deploying a real server farm.
What is a server farm?
As explained before, a server farm is nothing more than a ‘grouping (farm) or servers’. A more technical definition: A server farm is a group of networked servers that are housed in one location. Another way this term has been seen and used is when related to Clustering and Load Balancing. Clustered and Load Balanced servers when configured correctly, will streamline internal processes by distributing the workload between the individual components of the farm and expedites computing processes by harnessing the power of multiple servers. For failover scenario’s, when one server in the farm fails, another can step in as a backup. In any case, we will look at the design of both.
A server farm deployment is a large scale process, taking many team members, many different groupings of technical expertise (systems, development, project planning, technical supervision and management, networking, security…) all of which should be involved in the design and deployment of the solution. You should also know before-hand who will be managing the solution. You should also ensure that your team not only knows how to deploy it, but also has ongoing training on it for support. Since there are so many components to a server farm, its essential that you have help desk support if you have clients that rely on resources within it. For instance, if you have two nodes in a cluster and one fails, the clients may experience slowness in the applications or data they were working with, for that reason, they would need a place to call if problems were to come up, that has to be planned as well. Calls coming to the help desk need to be routed to the correct person and ‘slowness’ may be perceived as a network problem. Because of this, it's imperative to have ongoing support analysis, training before as well as after the deployment in key areas.
The plan is the key to your success. Great things come from great plans. It's a great way to pre-think what you need and get it done. Consider what goes into building a home or office building. The same level of care, effort, technical expertise goes into building a network. In some cases, depending on the size of the network, building a global network could be considered a chore compared to walking across 100 feet of blazing hot coals. All jokes aside, plan your deployment first, then deploy once you have your budget, resources and timeline in order.
You need to either have preexisting documentation, or create new documentation. You cannot plan a design without drawing it. You need to get this design to the rest of your team members; things brought up in conversation with them may alter the design. Make sure you have working documentation while you plan, deploy and after.
Now we get into the meat. Let's consider all the pieces you would commonly see on a computer network and let's build them into a server farm. These are the current resources:
- 25 Servers and 500 Clients
- Internet access and possible Proxy use, URL filtering
- Firewall protection at Internet access
- Routers in use
- Switching in use
- Remote Access Services (Client VPN)
- Naming services such as DNS and WINS
- Logical Addressing services such as DHCP
- Database services
- Application services
- Mainframe with ERP Software
- Mail services
- FTP services
- NAS services
- SAN services
- File and print services
- Fax services
- Web services
Please note that there may be more services to consider in your organization, please make sure that you do spend the time thinking about them and adding them to your own list that you can develop with the help of this one as a starting point. In the following illustration, you can see how I laid out the design for this company’s server farm.
Tips to Consider
In this section of the article,
- You have a main hub site; this is obviously where you want the bulk of your resources. Out of all the services listed, the company where the server farm is being implemented is in the Main NY site. Remote sites are Tokyo, Korea, UK and Italy. There are 25 users per remote site and the bulk of the remaining are located at the hub site. Obvious placement for the server farm would by in NY, where the main resources are.
- The main resources are 6 Windows Server 2003 servers that all run the following. You have a clustered File and Print Services solution that allows redundant access to data and printers 24 hours a day. If a server fails, then the other one takes over for the failed node. This is called 'failover'. You have 2 Domain Controllers, both running Active Directory, DNS (Primary and Secondary). You have one WINS server. You have one DHCP Server and you have one Intranet Web server.
- The 6 servers (although the cluster could be considered a farm in itself), are all added to one VLAN on the Layer 3 switch in the core of the network. This switch acts as a router as well, so this switches’ router is the default gateway for the LAN. This makes this set of redundant switches, the 'switching core' of the network, or 'the backbone'. The backbone is nothing more than a concept in speed… the center of your network should be the fastest, with the least amount of policies to hold you up, slow you down or causes 'any' delay whatsoever. Keeping servers in a single VLAN could be designed for enhanced security.
- You should have your backbone analyzed for what traffic really traverses it. Many switches have intelligence built in (or many network management products) that can tell you what percentage of bandwidth you are using. This is helpful in the design because you can start in the core (backbone) with Gigabit Ethernet running at 1000 Mbps, then have client access set at 10/100 Mbps. Access to your servers is not going to be the bottleneck. A bottleneck is the same as trying to push a basketball through a garden hose, the amount (or pressure) of the data coming in cannot be pushed out fast enough and serious issues could occur from this. Make sure you design the LAN speeds correctly.
In this article, we covered the fundamentals of what needs to be considered when building out a server farm. In this article we learned that it's important to plan and design, have the right people on the job, have a plan documented, and then deploy. Once deploying, consider other things such as, every network is different so there are many categories you may find or dig up that are specific to you. Make sure you keep your eyes open for that. We also covered server placement, logical design at the high level and switch and network design. In part 2 we will cover the server room build out, racking and other tips to help you build out a server room and server farm.
Please read Planning your Server Farm (Part 2).