Because your servers share a disk array, this implementation can't be used for the technique in which each server has its own copy of the files. Instead, you'd have to set up the servers in such a way that the server any particular user utilizes for an application depends on which groups they belong to. If a user's assigned server were to fail, another server in the cluster could pick up the slack and respond to the user's request. Because all the servers in the cluster use the same hard disk array, there's no danger of a user losing access to a particular database record they're working on just because a server goes down. Knowing what you're trying to accomplish before you start building a server cluster is a requirement from a technical standpoint, because of the various types of server clusters.
Advanced planning is also a requirement from a business standpoint.
In most of the companies that I've worked for, upper management tends to be a little afraid of computers. They often see new technology as expensive, unproven, and as a great opportunity to lose critical data and productivity during a crash. If you want to install a server cluster server in your organization, you'll usually end up having to convince the upper management that the server cluster isn't simply a expensive new toy for the IT department. To win your argument, you'll have to plan which type of server cluster is right for your environment so that you can explain to management how that type of clustering system can benefit your organization. For the sake of clarity, I'll refer to these as NLB clusters and server clusters for the duration of the article.