Scalability is a hot topic in server technology today. Large companies want to use their hardware to maximum efficiency. They want servers that handle both everyday file exchange and spikes of high traffic.
At the most basic level, order a server must have access to the data a user needs and the capacity to deliver it. This becomes more difficult with increased demand from large numbers of users. Servers get bogged down with increased activity, creating headaches for users and IT departments equally. To ease the traffic load, more servers can be introduced in a network, to form a clustered environment with a load balancer. This system portions out the server requests to multiple servers.
But where do the servers get the data to answer client requests? Storing duplicate information on each server is impractical—it wastes disk space and invites unsynchronized content, which leads to mistakes and lost time.
To solve this scalability issue, many companies store all data on one machine—either one of the clustered servers, or a separate data storage unit—and use a UNC path to allow all of the clustered servers to access the same bank of data.
A UNC Path, or Universal Naming Convention, allows a user to store and access data on any server in a network. The UNC specifies a common syntax to describe location information for a resource. This could be a file or folder or even a printer, any asset that can be used by a network. This path is a fixed point on the network the server can locate in order to access data.
UNC syntax includes the computer name, share name, and optional subdirectory where the resource is stored. The UNC syntax for Windows systems is computernamesharedfolder
esource.
Another example: say you have a computer named SERV1 which has a shared folder called SrtData with a subdirectory called Cluster Test. The UNC referencing the location would be SERV1SrtDataCluster Test.
If a server is deployed in a scalable environment, one or more servers run in parallel and can access the same backend data storage to serve different clients.
For example, say you have multiple servers networked into a clustered environment.
SERV1 is the primary, or first, server installed. SERV2 will be a backup server to be added at a later date. With a multi?server environment, there are two scenarios, both of which require the same configuration:
- User data will be stored on a local fixed disk on the SERV1 primary server box. Both SERV1 and SERV2 will need access to this data.
- User data will be stored on a third hard drive on the network, a box that is neither SERV1 nor SERV2. In this case, we’ll call this NAS1.
For either scenario, the configuration setup is basically the same.