CD-ROM Aktiv 1/CDA1_96.ISO/novell/sft&mu.txt

Text File | 1996-01-01 | 16KB | 274 lines

SFT III vs Mirroring Utilities
16 July 1993
Fred W. Tims
NONSTOP NETWORKS LIMITED

This article will discuss the differences in concept and operation between
Novell's System Fault Tolerance Level III (SFT III) server mirroring product
and third party mirroring utilities (MUs), such as No*Stop Network from
Nonstop Networks Limited.  Since I am intimately familiar with
No*Stop Network, it will serve as the MU for the comparison.  The features
of other such products will, of course, not be identical to those of
No*Stop Network, but will, in general, be similar in concept.

SFT III is centralized in concept, all mirroring activity being instigated in the
Primary Server and being executed without reference to other elements of the
network proper.  File change activity is identified in the Primary Server and
is passed to the Secondary Server via a dedicated hardware link between the
two servers.  This link has no reference to the network proper and can be
thought of as connecting two halves of a single machine.  Although each
server is connected individually to the network, they have identical names.
As long as the Primary Server is functioning, the Secondary Server ignores
all network file access requests. The underlying means by which the mirror
is effected is the dedicated hardware.

MUs are decentralized in concept, all mirroring activity being instigated in the
client workstations, using local OS file services (e.g., DOS) and NOS shell
services to direct mirroring activity over the network.  The mirror is effected
via software alone, passing file changes first to the Primary Server and then
to the Secondary Server over the same cabling used for the network proper.

REQUIREMENTS

SFT III requires two identical 80386 class or better servers, each with at least
12MB RAM.  It may be that more RAM is required for adequate performance.
While there have been statements to the effect that the servers do not have
to be exactly identical (e.g., one may have more RAM than the other), it
appears that the requirement is fairly firm.  For instance, Novell have stated
that the rated speed as well as the screen drivers in the two servers must be
the same.  There are even indications that the server machines can be a bit
flaky if not designed with SFT III in mind (see "An SFT Safety Net", LAN
Magazine, August 1993).

The two servers must be connected by a dedicated fiber optic or coax link
(the Mirror Server Link or MSL), consisting of a cable with an adapter at each
end.  It is through this link that server updates are passed from the Primary
Server to the Secondary Server.  The adaptor is currently available from three
suppliers.

MUs typically impose no unusual requirements on the system.  They work
within the context of the existing network, using between 10KB and 30KB
RAM in each client workstation which will be mirroring its activity.

At least two drive letters must be supplied to the MU by the OS or the NOS
shell, one for each Primary Logical Drive to be mirrored and one for each
Secondary Logical Drive to receive the mirror.  As long as DOS compatible
drive letters are supplied, the servers can be anything - Netware, LANtastic,
Vines, a MAC system, a mainframe, or a mixture - it doesn't matter.

If mirroring between servers is to be done (as opposed to mirroring between
a server and local hard disk or between two local hard disks), two licenses
for the NOS are required.

LIMITATIONS

The limitations discussed here refer to functional capabilities rather than
efficiency or load bearing capabilities.  They will be dealt with later.

SFT III works only for Netware systems, currently only Netware 3.11.
Presumably at some future date it will be available for Netware 4.x.

With SFT III everything is mirrored.  While in some ways this is an advantage,
a price is paid for this approach, both in system hardware requirements (e.g.,
more disk space) and in system loading.

MUs are generally limited by the number of drives which can be represented
by the alphabet.  This imposes an effective limit of thirteen on the number of
volumes or subdirectories which can be mirrored by each client workstation.
This limitation can, in most cases, be mitigated by judicious assignment of
work areas and user hierarchies, or by simply mirroring from the root of a
volume.  Its most serious impact is with regard to Novell search drives, which
cannot easily be combined.  Should a server crash while the client
workstation is accessing a non-mirrored drive, the client will get a message
from the NOS offering "abort" or "retry" options and processing will have to
stop.  If there is a large number of Novell search drives, it may be impossible
to mirror them all.

NOS control structures, such as Netware binderies, are not generally
effectively mirrored by MUs during construction (such as adding a user).  This
is due to the machine-specific nature of these structures.  When using an
MU, system administration of the type offered by Novell's SYSCON should
be performed on each server separately and unmirrored.  In addition, NOS
control structures should be backed up for each server using NOS facilities
such as Novell's NBACKUP and BINDFIX.

RELATIVE ADVANTAGES

SFT III has a single point of specification.  Once installed, SFT III will mirror
all activity for all users.  By limiting options, this simplifies administration.

When operating under SFT III, there is a single point of access.  There is no
way in SFT III, presumably, to access the Secondary Server directly without
going through the Primary Server, unless, of course, the Primary Server is
down.  This is a good security and integrity feature.

SFT III needs to be "tuned" for only one environment - that of the Primary
and Secondary Servers.  Once running correctly there, it should be oblivious
as to the configurations of individual workstations attached to the network.

MUs offer multiple points of specification.  Each user can be mirroring as
appropriate to the task.  In some types of enterprises this capability can
reduce requirements for storage on the Secondary Server and can lower or
level load on the system.

MUs also offer multiple points of access.  It is possible for users to access
either server directly.  This characteristic, in conjunction with the ability to
tailor the mirroring activity to each client workstation's activity, makes it
possible, in some cases, to level the load between the servers by cross
mirroring.  For example, an engineering department could be performing
CAD/CAM activities, mirroring from SERVERA to SERVERB while the
accounting department is maintaining the books, mirroring from SERVERB
to SERVERA.  It also makes it possible to offload activities which do not need
to be mirrored to the Secondary Server, thus freeing up capacity on the more
heavily utilized Primary Server.

RELATIVE DISADVANTAGES

SFT III's single point of specification, while convenient for the system
administrator, can be wasteful of system resources in some cases.
Everything gets mirrored whether or not you want it to be.  This is fine if you
want everything mirrored, but you pay for it in terms of storage requirements
and system load in those situations where you do not need to mirror
everything.

SFT III has a single point of failure.  An error in the hardware or software of
the Primary Server can be mirrored to the Secondary Server.  For instance,
a bit dropped in the Primary Server data buffer will corrupt data on both
servers.

SFT III introduces additional hardware to fail.  The addition of hardware (the
dedicated link between the two servers) to the network to support mirroring
introduces more failure possibilities, thus lowering the MTBF of the mirroring
process.

MUs have multiple points of specification.  If your enterprise is such that all
or most of your users are doing the same or related tasks, it is a minor
nuisance to set them all up and to change them if the need arises.  Usually,
however, this can be handled effectively and easily via the use of login scripts
used in common (e.g., the System Login Script in Netware).

Since the Secondary Server in a network using an MU is, as far as the NOS
is concerned, just another server, multiple points of access are possible.
Unless some form of control over the users is enforced it will be possible for
them to log into the Secondary Server directly.  The system administrator
must take measures to ensure that no users can access data on the
Secondary Server that is being mirrored by other users.  Such access can
cause the data to become unsynchronized.  This control can be fairly easily
accomplished via the System Login Script on the Secondary Server by
checking to see if the Primary Server is online and, if so, refusing the login
request to all but the SUPERVISOR or some equivalent.

Each client workstation must be "tuned" for use of an MU in the same
manner it was tuned for the other software running in it.  Memory
management parameters may need to be altered; configuration parameters
specifying the number of such things as file handles and/or FCBs may have
to be increased.  The majority of installations are configured such that they
are already prepared to accept an MU without modifications.  Still others are
homogeneous in workstation function and equipment so that any changes
required are common to them all and easily made.  Large, heterogeneous
environments, where there are many workstations on the network and they
are of many different individual capacities, performing diverse functions can
be a headache to tune for an MU.  In these situations, documentation and
vendor support take on an added measure of importance.

Both SFT III and MUs are vulnerable to ill-behaved or buggy software which
cohabits their platforms.  A server is tightly controlled and the software which
runs on it is generally solid.  Because of the physical separation as well as
the resulting necessary high-level interface between a server and the
software running on client workstations, compatibility issues are lessened for
SFT III.  Anything can be put on a client workstation.  MUs can suffer from
this fact of life.

SYSTEM IMPACT

Activity in the Secondary Server is considered, for this discussion, irrelevant
as a comparison point since it is more or less common in terms of impact to
both approaches, and because it, in both cases, represents additional
resources rather than existing resources upon which additional load is being
imposed.

The two approaches, having differing system concepts, impact the system in
different ways.  Briefly, SFT III processing in support of the mirroring task is
performed in the Primary Server, and it is there, and presumably only there,
that the impact is felt.  MUs, on the other hand, running as they do in the
client workstations, distribute the load of mirror processing, impacting the
client workstations and the cabling, but not the Primary Server.

SFT III
        o      Primary Server Processor: Overhead figures in the 30% to
               40% range have been mentioned in the press.  This could
               cause a significant bottleneck.
        o      Cabling:  None.
        o      Client Workstations:  None.

MUs
        o      Primary Server Processor:  None.  As a matter of fact, if your
               enterprise is such that you can partition your users by the
               data they use, an MU will allow you to cross mirror, thus
               decreasing the load on the Primary Server, actually
               improving the performance of your network compared to its
               performance before mirroring was added.  Another
               possibility, in special cases, is that the Primary can be a local
               hard drive (even a RAM drive), thus removing all READs
               from the network.
        o      Cabling:  Doubles WRITE traffic.  This is normally not a
               problem unless an unusually large volume of writing is done
               (e.g., live satellite imagery downloads) and/or the cabling is
               already near saturation.
        o      Client Workstations:  Observed degradation in response time
               measured in various tests has been from 1% to 10%.  This
               is not noticed by the users in most installations.  Again, this
               depends on the volume of write traffic, most of the
               degradation being caused by the time to send a second
               WRITE and wait for confirmation. [note: this impact is indirect
               for the most part, and is suffered by SFT III as well. The
               direct impact is only that caused by forming the Secondary
               request and interpreting results.  This direct impact does not
               occur in SFT III in the workstation; it occurs in the Primary
               Server, but its effect and the effect of the wait for
               confirmation from the Secondary Server is felt at the
               workstation just as with MUs.]

SUMMARY AND CONCLUSION

In this article I have given a very high level description and assessment of the
relative merits of SFT III and mirroring utilities.  The broad generalities
concerning mirroring utilities might elicit some rather strong exceptions from
the community.  I can only say in my defense that it is difficult to extrapolate
all of the possible alternative implementations of a technology in a short
paper.  If I have misrepresented SFT III in any way, my defense is weaker.
I have, as might be presumed, studied everything I could find pertaining to
SFT III.  Any misrepresentations will be due to lack of understanding on my
part.  That said, here are the conclusions:

In concept, SFT III should be easier to administer due to its centralized
control and to the fact that it runs in a more benign environment (the servers)
than do MUs (the client workstations).  The question as to whether this ease
of administration has been realized will be answered over the next few
months.  Compared to MUs, SFT III has a high technical risk.  It is also much
later on the scene than MU technology, with probably a good number of bugs
still to iron out.

MUs should offer better performance than SFT III, but this is a difficult
assertion to prove.  It is anticipated that the typical SFT III installation will
employ much more powerful server equipment, such as 80486 and Pentium
machines with multiple processors and huge amounts of RAM, than will the
typical MU installation.  If the enterprise can afford SFT III, it can afford the
most powerful machinery.  Moreover, most installations, especially small-to
middle-sized ones, have excess capacity which will mask any performance
degradation.

The greater flexibility of MUs cannot be denied.  An MU can be grafted onto
just about any configuration, and its use can be tailored to meet the needs
of each individual client workstation.  Each client workstation can be mirroring
between its own assigned set of servers or local hard disks; its mirror pairs
can even be accessing different servers within the same session.  For many
enterprises this capability is irrelevant.  For others it is important.  Even for
those enterprises which do not need this flexibility on a day-to-day basis,
however, the cost of replacing a destroyed server should be considered.
Since the servers (in SFTII) must be essentially identical, it may become necessary to
find an exact replacement two or three years down the road.  If an exact
replacement cannot be found, two new servers (perhaps Sextium machines!)
will have to be purchased and installed.  With an MU, any machine of
adequate capacity can be plugged in.