🚀 go-pugleaf

Server Scalability - Up or out?

By Craig W. Borysowich

As organizations large and small spend more money on distributed
computing, local and wide area networks, the question inevitably leads
to "Do we expand or add?" to the existing servers.  It can be a
daunting decision, which should weigh the many factors of cost,
manageability, and the reality of providing services to your customers
- the other employees in your company.

Companies invest thousands of dollars to provide file servers, print
servers, and application servers with one of two visions.  They either
want to put in the minimum required with the thought of expanding the
system or adding further servers later, or they put in a giant server
that can hold the whole gambit of functions and service all users.
Which ever theory is used, they usually are not thought out with
respect to the future cost, manageability, and user support
requirements the company may get in the years to come.  So, do we
scale up to a superserver or do we scale out to a large number of
smaller servers?

Scenario One:

Let�s look at the first model.  Buying cost effective servers and
letting them multiply as needs grow, is a great way to keep the bottom
line under control, but the administration and management of the
network can creep up on even the best of controlled network growth.
You can buy a standard Compaq Proliant 1500 with 133Mhz pentium, 64MB
ram, 2gig of SCSI2 fast and wide Raid5 hard drive, Network card, and
Windows NT server for less than $20,000.  A second CPU can be added
for either SMP operation or Fault tolerant CPU operation and still be
less than $20k.  A server like this might service 300 people
simultaneously at best on a well designed network.  Then, as you bring
more users on, you add more servers until you are looking at ten
servers to service 2200 users.  Now you have to manage the security,
adds and deletes of users, moves of users from one department or
location to another that need to be on a different server, and monitor
the network traffic to be sure that some servers are not being used
far above others.  This can be achieved for under $200,000 in
equipment plus a couple of support personnel.

Scenario Two:

In the second model, I priced together a top end server, with Quad top
end RISC CPUs, 128MB ram, high speed network connection, Fast
backplane motherboard, Windows NT in SMP mode, and 10gig SCSI2 fast
and wide raid5 hard disk.  This server ran a little over $170,000 -
but should service around 1100 users simultaneously.  Two of these
servers would have cost over $340K to service our same company of 2200
users.  Administration and management is going to be easier, and
possibly can be handled by one individual.

In both cases we have not made sure that enterprise administration
tools, network management software, and security audit tools have been
put in place.  This would put the first scenario just under $300k, but
probably push scenario two over the $400k mark.  These tools are
critical to the management, administration, and growth monitoring of
any network, and should be put in place regardless of the size or
scope of the network infrastructure, though less robust tools may be
used on smaller networks of less than 300 users.  Any self conscious
network manager would at least use some tool set to confirm traffic
flow, find bottlenecks, warn of server crashes or pending crashes,
centralize administration tasks, and audit security compliance.
Especially if they have to answer to the user community for security
breaches, slow response times, lost productivity, and slow turnaround
of administrative requests - which most do.

The actual costing of some components used in the high end machine are
much more costly than in the Intel based machines.  64MB can usually
be built from four 16MB ECC ram simms at $800 each.  The 128MB is
usually made up of four 32MB ECC ram simms which can run $4000+ each.
While the RAID drives are the same, high end RISC processors,
proprietary backplane technology, and high speed network hardware can
run quite a premium.

While in both Scenarios we are sure that the servers can handle the
user load through processing power, memory, and fast hard drive reads
and writes, the only real bottle neck becomes the speed of the network
card.  Even on an FDDI/CDDI server ring or even the fastest of ATM
segments, I am not aware of very many NICs that can handle up to 1100
simultaneous requests without bogging down and resulting in lost,
garbled, or timed out packets.  Multiple network cards is usually not
an option especially in a TCP/IP based network, where the two cards
would have to carry different IP addresses.  Only the most serious of
bit-heads on your network will go after a server by it�s IP address.
Most users will access their server by the server name, and even with
two IP addresses mapping to one name in the DNS, they will always get
routed to the first address in the list.  Applications almost always
address a server by name rather than by IP address.  Thus there would
have to be separate names on the server for each network card which is
not an easy feat and would bring back the complexity of splitting
users between two, three or four network cards to load balance the
traffic manually.

In scenario two, a server going down means that 1100 users cannot work
effectively and the cost of lost productivity accumulates very quickly
while the server is brought back online.  This is an area where
network managers should have more accountability.  In scenario one, a
crashed server only results in 300 unproductive users which would only
account for 1/5th of the lost productivity cost if the server was
brought back online in the same amount of time as the large or
"superserver".  But how plausible is that expectation?  If there is a
hard drive corruption, or some kind of hardware failure, the time it
would take to restore a superserver from backup would be 5 times as
long.  Thus you can ensure faster up-time to a smaller number of users
on a smaller server.

I try to match the superserver to the age of the Mainframe.  Lots of
users on a massive processing and storage system that is easy to
administer, but can cost a lot of  lost productivity when it goes
off-line.  Estimating these costs can be hard to fathom, but if you
take a simple calculation of a company with an average staff salary of
$40,000, and assuming the project management standard of 217 working
days, each having 7 hour in a year, to give us a rounded off hourly
rate of approx. $26.  Which translates to a loaded cost to the company
of approx. $55 per hour when you count space, utilities, benefits etc.
Based on IBM�s estimates.  Thus an hour of downtime for 1100 users
would cost the company $60,500. Whereas the 300 user server down for
an hour would only cost $16,500.  The chances of 5 of the 300 users
servers going down simultaneously too slim to bother calculating.
Sometime it feels like an MIS department has to be billed for this
time before they will take proper actions to avoid downtime and
install tools and management solutions to proactively stop network
problems and server crashes from occurring.  These estimates, of
course, are very conservative.

Enter Clustering.  Clustering will bring about the theoretical end to
server downtime, and likely the usage of the superserver.  Clustering
is currently available on Unix operating systems, and will soon be
available on Netware, Windows NT, Warp Server and Lotus Notes servers
as well.  What clustering provides is a mechanism to setup a group of
smaller servers to act as one big server with one server name and one
address.  This means that I can take $100k of my servers in scenario
one and create what appears to be a superserver to my users, by taking
five standard server machines and putting them in a cluster.  The
advantage is that the servers will load balance the inbound traffic by
splitting the workload among the five servers in the cluster, and the
five network connections.  

If one server in the cluster goes down, all users are still working
against the other four until the crashed server can be fixed and added
back into the cluster.  Only minor performance degradation may be
experienced by the users, but their connections are never lost, and
their work is never interrupted.  We agreed earlier that the chance of
five servers going down is very slim, so the chance of a cluster going
down is minimal, theoretically eliminating the chance of lost
productivity.  Clusters allow a group of more cost effective servers
to be used instead of costly superserver configurations.  Load
balancing of inbound requests can allow several slower network cards
fulfill the function of a single high speed card reducing the need for
costly FDDI or ATM network upgrades.  Administration and security is
managed as if there are only two servers providing the manageability
of scenario two yet having a total of ten servers sharing the
processing and network load.  

Increasing manageability, reducing cost of equipment, eliminating lost
productivity, and staying within existing infrastructures while not
increasing support requirements are the key targets for most MIS
departments in medium to large organizations today.  Clustering shows
that this is achievable, without moving distributed computing back to
the mentality of the mainframe.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Craig W. Borysowich
Senior Network/Workgroup Technologies Consultant 
LCNC, ECNE, MCSE 
TEL: (416) 410-0647    Internet: craigwb@hookup.net
FAX: (905) 472-2873    CompuServe: 74104,1467
=== RULE THE KEYBOARD, RULE THE WORLD ===
The Microsoft Network, Prodigy and America Online are prohibited from 
viewing or redistributing this work in any form, in whole or in part.  
Copyright (c) Craig W.Borysowich, 1995.  License to view or redistribute
this post is available to Microsoft, Prodigy or America Online for US$800.00ea.
Appearance without permission constitutes agreement to these terms.