Novell's NetWare 4.0 has been on the streets for six months now. After the initial hype has
faded, it is time for PC champions to give this product a closer look. Why? Because it is one
of the single products that will change the way corporate networks, and the applications that
run on them, will be built for the remainder of this century, and far into the next.
NetWare 4.0 could serve as the basis of corporate communications and application delivery
backbone for large and medium-sized businesses. Through the improvements that Novell has
made to the product such as an innovative implementation of a single enterprise-wise
directory structure, network security, and integration with Windows and Presentation
Manager, will serve corporate users well.
Windows NT, Unix, and other LAN operating system wannabes don't measure up to NetWare
4.0: applications aren't as plentiful, enterprise-wide support will be more difficult, and none of
these other products can come close to NetWare 4.0 in terms of supporting a wide mixture of
client operating environments such as Macs, OS/2, and Unix.
NetWare 4.0 is not for everyone. If your corporation currently owns less than five servers in
less than four locations, then stick with whatever networking gear you've got: NetWare 4.0
will be overkill. If you have strictly Windows clients, and you intend to leave character-mode
DOS applications in the dust, then you might want to consider what Microsoft has to offer
with its various NT and Windows for Workgroups products. If you can't afford to retrain your
network support staff to understand the new features and ways of doing business with
NetWare 4.0, or if you have more than 75 percent Macintosh clients, then stay with NetWare
3.x line.
However, if you've got more servers in more cities and want to cut the size of your support
staff, then the product is worth a try. The three biggest benefits of NetWare 4.0 are the
ability to run bigger networks with less resources, better integration with Windows clients,
and improved security if the product is used according to directions. Any one of these
benefits is reason alone to take a careful look at the product.
NetWare 4.0 is also a big departure from previous versions of NetWare. It looks at the
network as a single entity, rather than a collection of disparate servers and devices. It uses a
sophisticated directory services database, closely aligned with X.500 principles. It uses new
software on the client side as well, some of which can take advantage of graphical interfaces
to make network connections and administration much easier. And it builds in more
protection and security than anything Novell has ever done before. When you add niceties
such as the ability to support 1,000 clients per server (first demonstrated at the spring Interop
show in Washington, DC.) and the ability to support a variety of languages other than English
(first pioneered by Banyan), Novell has made it possible to spread large LANs across the
globe on a scale that few others can match.
All of these changes means that implementing NetWare 4.0 won't be a cakewalk. The view of
the enterprise as a single network is foreign to many of you who have grown up on earlier
versions of NetWare that were focused on single servers. Indeed, the best advice we can give
to a NetWare 4.0 neophyte is to hire someone who has been trained by Banyan: they have the
necessary mindset, skills, and view of enterprise networking that will help you get over your
biases of server-centric Novell.
Upgrading to NetWare 4.0, particularly if you have a wide range of earlier Novell products
stretching back to NetWare 2.0, will be painful, although Novell has done a reasonably decent
job of explaining all the options. (NetWare 2.x level servers cannot be upgraded in a single
step to 4.0, for example.) You will need to spend lots of time before you even install the first
server in understanding the new features and how to implement them within your
organization.
Novell, Inc.
122 E 1700 South
Provo, UT 84606
800 453 1267
801 429 7000
801 429 5373 fax
5 users $1395
10 users $3,195
25 users $4695
50 users $6295
100 users $8795
250 users $15,695
500 users $26,395
1000 users $47,995
INCLUDES TWO MANUALS, FOR THE FULL DOC SET ADD $349 TO EACH PRICE.
Dealing with Directories
The biggest difference between NetWare 4.0 and previous versions has to do with the way
servers and network resources are organized, what Novell calls NetWare Directory Service
(NDS). This is a completely new way of looking at NetWare.
In previous versions, you had a separate login identity to each NetWare server. If you wanted
to share files on three separate servers, you had to connect to each one individually. This
could get tiresome, particularly entering three passwords every time you needed to connect to
each server. It was tiresome as well for your network administrator to keep up to date, since
he or she had to connect to each server and maintain each account and file system on each
server separately as well. If you wanted to send your print jobs to another printer, you had to
type in the appropriate commands (keeping in mind the names of the print queues) or else
have your network administrator switch them for you.
All of this information was kept in what Novell called its Bindery, which was essentially a
flat-file database. Each server had its own Bindery, and they didn't share any information. A
user could have supervisor access (someone who can administer the entire server, create
directories, and create and delete user accounts) in one server, and be just an ordinary user in
another server. Indeed, a user could have two different user names, which made things
confusing. Information such as printer names, print queues, the various sets of file directories
each user had access to, and the allowable login times for each user for that particular server
were all kept in the Bindery.
The only way to really maintain any consistency among the various servers was by human
intervention. All of that has changed. NDS has become the enterprise network police,
enforcing this consistency across all servers and network resources.
With NDS, you see all network resources as a one-stop shop: you login once to the network,
not to any individual server. At login you connect to all of your network resources. No longer
do you have to seek out which server has what set of files or peripherals. If you want to
switch queues, you do so without having to know their names or with which servers the
queues are connected. NDS is essentially an enterprise-wide distributed directory of all
network resources: users, servers, printers, and other network peripherals. Gone forever is the
notion of a server-centric computing world.
Novell uses the metaphor of a tree to explain NDS: you start out at the root and grow various
departmental branches from the main trunk of your enterprise, until you get to the leaves or
end-points of the directory, which are objects such as user identities and shared directories
and printers. However, figuring out how to structure your tree will take some time, and you
may not get it right the first time (which is fine -- indeed, NDS is designed to change to
mirror changes in organizational structure).
How do you start? First off, make sure your network names and numbers are unique, and
that your organization has a systematic way to assign new ones to ensure this uniqueness.
Without this structure, NDS will be useless. If you plan on mixing 3.x and 4.0 servers, this
means using both the new NDS graphical utilities as well as the trusted RCONSOLE and
SYSCON to check each server.
Second, you should have standard set of application names and means of access across the
enterprise. Again, it doesn't do much good to implement NDS if every server stores a copy of
Word in a different way. You can still implement NDS without these standards, but now is
the time to start this process and it helps tremendously down the road.
Finally, your tree design should make sense and be carefully thought out. We recommend that
you try a test design out for a few months among a small group of users until you gain
experience: you most likely will have to change the initial design. Your design should follow
either geographical divisions (such as having separate organizational units for each physical
office) or departmental divisions, or a combination of both. Part of this planning process is
picking a structure so that all of the people in the New York sales office, for example can
have the same rights and access the same resources, to make things easier to administer. You
will also have to consider what portion of your users move about the company, and how they
will get access to network resources when they are away from home. NetWare 4.0 can take
care of these wandering users, provided the directory structure is set up properly.
There is more about NDS than we can reasonably go into here. The best treatment from
Novell is the April 1993 edition of NetWare Application Notes (a year's subscription costs
$95 and can be obtained by calling 800 377 4136). This is the most concise yet complete
explanation of NDS short of purchasing the NetWare 4.0 product itself.
Getting NDS right will require a great deal of up-front planning, and it could make NetWare
4.0 too costly for small organizations with only a few servers: the product is really designed
for businesses that have servers in many cities. It will take time to get this right.
Differences with VINES
At first blush, given its tree-structure and enterprise view of network services, NDS appears
to look alot like the features found in Banyan's VINES, or its incarnation for the Novell
world called Enterprise Networking Services (ENS). However, there are several distinguishing
features. In some sense, Novell has taken the original ideas from Banyan and expanded upon
them:
-- Levels in the directory tree. Both ENS and VINES have three:
user@department@organization. NDS has unlimited levels, although beyond say six it will
get cumbersome to administer. Some organizations have been hampered by having only three,
however.
-- Replication. The directory on any network partition can be replicated on any other. This
means some level of redundant operations if your "home" server is not operating, in that you
can still access network resources and do not have a single point of failure. Banyan has
read-only copies of the directory and a single server to login for each user; it is a distributed
directory but not a replicated one.
While every in theory this means that every server can contain a complete replica of the rest
of the network, in practice you probably don't want to have more than a few copies
replicated. (The more replicas, the lower the performance.) Directory partitions are not to be
confused with disk partitions: the two are independent of each other. Deciding on how to
partition your network will also take some time, to ensure that users who move about the
enterprise can still login locally: the goal here is to reduce traffic across slower WAN links
by designing the partitions appropriately so that users can get authenticated from a local
server.
Let's take an example. Assume your login identity in Vines is strom@edit@newyork. If the
server that handles the group edit@newyork goes down, then you and the rest of your group
can't connect to the network anymore. You have a single point of failure for the network.
This isn't the case with NDS.
-- 15 object types: volume, user, profile, printer, print queue, bindery, alias, computer, group,
etc. For NDS, everything is an object: a fax server, a conference room that gets scheduled,
and so forth. These object types are also extensible, so application developers can create their
own objects and add new items to existing objects. Banyan has only six object types that are
not extensible.
Like any good database, there is a great deal of information that can be entered for each
object type. For example, each user object has login name, password, telephone number, fax
number, office location, and so forth. This means that you can view details about your entire
corporation at a glance. Of course, this also means that you or your network administrator
will have to spend time setting things up, although Novell has made matters somewhat easier
by providing lots of default templates for various user and other common object profiles.
-- limited resource groupings. With Banyan, each group must reside on a single server. In
NDS, groups can be any collection of objects across the network.
Overall, NDS is more flexible and more reliable than the equivalent functions in either
VINES or ENS. But Banyan isn't standing still. Extensions to its Street Talk naming service
will include
New and Improved Security, Protection and Auditing
One of the biggest reasons to consider NetWare 4.0 is the improvements Novell has made to
the security and memory protection areas of the product. Of course, any security features are
useless unless your network administrator enables them and follows the guidelines to maintain
them: for example, it doesn't help overall security if every user has the option of not using a
password at login time. There are other options, which aren't new to NetWare 4.0 but should
be considered: forcing periodic password changes, enforcing a minimum number of characters
for a password, and preventing users from alternating between several passwords. We
strongly recommend that any NetWare 4.0 installation use all of these security features.
The new security features cover several areas: workstation security, file server security, and
multitasking application protection. In combination with the ones that exist for the 3.x line,
they provide for something akin to mainframe quality security for the LAN.
There are two added features to workstation security beyond what was already available in
NetWare 3.x. They are:
-- The ability to restrict logins to specific Macintosh network addresses (previously, these
restrictions only applied to DOS and OS/2 network addresses). This is helpful, particularly for
those organizations that want to tie particular users to particular computers: now it can be
done for most of the clients supported by NetWare.
-- RSA crypto keys for login. RSA stands for the three gentlemen that founded one of the
most popular cryptographic systems: Rivest, Shamir, and Adelman. Previous versions of
NetWare sent the password over the wire in clear text, making your login insecure for anyone
with a network analyzer who happened to be listening in at that moment. NetWare 4.0
encrypts this process, making snooping almost impossible. Why almost? If you tell others
your password, or choose something easy to guess (your spouse's name, your birthday), all
the security features are useless.
There are also several enhancements to both network and file server security:
-- The concept of a network auditor. New to NetWare 4.0 is the concept of a network
auditor. This is someone that independent of the supervisor or network administrator can keep
track of important events on the network, such as each time a particular user logs into the
network, or requests particular network services. Corporations like having a second person in
charge of auditing: it makes it harder for errant employees to get away with something that
they shouldn't be doing (unless of course the two cooperate). All of the auditing features are
implemented with a DOS-only command line AUDITCON, no graphical utilities are yet
available.
Given that this is the first instance of auditing with NetWare, it is a bit clumsy to use and
will take some training to understand how to make the best use of it. But give Novell an A
for effort here: this is something that LANs have lacked and need to have to be serious
contenders in the mainframe replacement market.
-- Transaction logs can be filtered, for easy viewing of critical events. Before, a network
manager had to sift through the entire log, which was a cumbersome process that few would
attempt. Now you can focus on particular events.
-- Remote console session security (password encrypt and callback). Previously, security for
the remote console (in other words, operating the file server from a network workstation or
over a phone line) was minimal: anyone with access to the SYS:SYSTEM directory could
figure the password quickly. New to NetWare 4.0 is the ability to encrypt the remote console
password, and indeed to go a step further and have the server call an administrator back at a
pre-set phone number.
-- Running NLMs in protected mode. Microsoft has long made hay about the fact that any
errant NetWare Loadable Module (NLM, the actual server-based applications such as fax
servers, protocol interpreters, and the like) can shut servers down, and we've seen rare
instances where it has happened -- such as an NLM that we copied from a commercial disk
that was corrupted somehow and brought the entire server down when it was loaded. With
NetWare 4.0, this is no longer as worrisome, since network administrators can set up a fence
around whatever NLMs you want, what Novell calls a protected domain. However, not all
NLMs will run in protected mode, and still the best advice we can give is to have a separate
test server for anything new that you want to add.
The reason why Microsoft has made so much noise about misbehaving NLMs is because NT's
(and for that matter OS/2's) server-based processes can run above the kernel layer of the
operating system. However, this is somewhat misleading, since any kernel-based process that
misbehaves can also bring the entire machine down, as we have experienced with both
products on rare occasion.
Is this important for users? Not really. Network administrators will figure out which NLMs
will run in which domains. However, we are glad Novell has addressed this issue.
Changes in the NetWare Client
Despite these changes in the directory and security services, the most important and most
noticeable changes for any user are what Novell has done to each NetWare 4.0 client. These
clients, by the way, can be installed separately from the NetWare 4.0 server side: they will
work just fine connecting to earlier 3.x and even 2.x servers, and many corporations have
begun the upgrade process to 4.0 by first installing all new client software throughout their
organizations.
The client changes are in several areas: configuration, user interface, and network
administration. Let's look at each.
First is configuration. By that we mean the way that CONFIG.SYS and batch files load
various network drivers, and how NetWare interacts with DOS, Windows, and OS/2. On the
DOS and Windows side, NetWare 4.0 clients are very different from previous versions.
Many of you are used to loading just two commands to connect to a NetWare server: IPX
and NETX. They are replaced with several new files:
-- a series of Open Data Link (ODI) drivers, which Novell used as an option in
previous versions but is now mandatory in NetWare 4.0 if you want full directory services
and secure authentication,
-- changes to CONFIG.SYS for DOS and Windows
-- new DLLs and other OS/2 and Windows-software,
-- a new client software called virtual loadable modules or VLMs that replace NETX.
ODI. The old IPX drivers will still work with NetWare 4.0 servers, but only under bindery
emulation mode. That means that if you want to access any of the directory services
functions, you'll have to upgrade, and the first step is to switch to the newer ODI-style
drivers.
Why bother, apart from the fact that the older stuff will eventually become obsolete and you
won't be able to get any benefits from NetWare 4.0? Three reasons: First, ODI allows you to
run multiple protocols and frame types over a single adapter. Want to connect to both
NetWare and Unix workstations? No problem. (Speaking of frame types, Ethernet has four
different ones for example, depending on whether you connect to minicomputers, Unix
workstations, Appleshare servers, or NetWare. New to NetWare 4.0 is to default to the 802.2
frame type, although NetWare 4.0 servers can speak all types to whatever client requires, as
did NetWare 3.x.)
Second, ODI comes as part of the package. Novell has shipped over 150 different ones right
on the same CD and disks that come with the 4.0 product: previous versions of NetWare had
many fewer, and usually required a trip to Compuserve to download the latest ones anyway.
Since they are readily available with the basic NetWare 4.0 package, it is easier to use and
find them.
Third, ODI drivers are easier to configure and administer, keeping costs down for distributed
networks. The older IPX drivers required the network administrator to set up each driver
depending on the particulars of the card. These are a thing of the past: network administrators
only need to change a single adapter driver depending on what is installed in the workstation,
rather than recreate a new IPX file for every card configuration. This configuration
information is stored in a file called NET.CFG and includes what frame types you want to
use , what should be the first network drive letter (typically, most people use "F:"), and other
arcana such as your machine's TCP/IP address and interrupts and I/O addresses.
Here how ODI works. Instead of loading IPX, you type three commands: LSL, the adapter
driver, and IPXODI. Each of these three files gets additional information from NET.CFG.
CONFIG.SYS. You'll need to edit your CONFIG.SYS file, and place a LASTDRIVE=Z
command inside it. This is new to NetWare 4.0, and a minor but necessary condition to use
the new DOS and Windows clients and be able to use any search drive mappings (that's
Novell lingo for setting up a path to various file server directories).
WINDOWS. Novell has done even more work integrating NetWare into Windows, and you'll
need a series of new DLLs and other files to support the NetWare 4.0 servers. All of this is
handled automatically by the NetWare 4.0 Windows client install software, including updating
the various .INI files and putting the files in the right places inside your Windows
subdirectories. That is, it is handled automatically provided you have a copy of Windows on
your local hard drive. If you run Windows from the network, you will first have to copy the
files that the installer puts into C:\WINDOWS\SYSTEM into wherever your system files are
stored on your network. Novell is working on fixing this, and may have done so by the time
you already read this. [TK: CHECK]
In addition, the new Windows client gives you an option to either load before Windows or
during Windows: the previous 3.x client had to be loaded before starting Windows.
VLMS. The final part of the quartet of enhancements is the VLM driver set. Basically, what
once was a "shell" software called NETX, a TSR that ran under DOS, is replaced with a new
series of software modules called the DOS Requestor and most visibly noted with VLMs.
There is an overall manager, called VLM.EXE, which loads a whole series of other files,
depending on what you have specified in NET.CFG. Different software, although the same
VLM architecture, is available for OS/2.
To give you an example of the modularity of VLMs, consider one called AUTO.VLM. When
this module is loaded, anytime a client connection is lost, then reconnected, NetWare will
rebuild the environment to the state prior to the loss of the connection. And the price of this
feature? An extra kilobyte of RAM required. It will only work with 4.0 servers and the
default is not to install it.
VLMs support up to nine printer attachments, provided you connect to a NetWare 4.0 server.
The previous versions of NetWare clients supported up to three.
MEMORY and PERFORMANCE. You would think with all these changes that the NetWare
client takes up much more memory, but not necessarily so. Actual mileage can vary
tremendously, and depend on what memory managers are available and how you have
configured your VLMs. Some guidelines are that the client could take anywhere from 10
kilobytes less RAM to 20 kilobytes more, when compared to NetWare 3.x ODI drivers.
GRAPHICAL UTILITIES. All of this plumbing is geared at making administering a large,
distributed network easier and more reliable. But this is just the first stage of client
improvement with Novell. The most visible changes to any user of NetWare 4.0 is a set of
new graphical utilities to help make things easier for users to gain access to network
resources. And, for the DOS character-mode diehards, there is even new client software for
them as well. The programs are called NWUSER (Windows), NETUSER (DOS), and
NWTOOLS (for OS/2). Macintosh clients will get their own software by the time you read
this according to Novell but they will be only able to access the NetWare 4.0 server under
bindery emulation and not be fully directory aware.
The graphical utilities augment, rather than replace, the traditional NetWare command line
utilities of CAPTURE, FILER, MAP, FLAG, and their brethern. Using these utilities makes
assigning a drive to a network directory or printer easy: you point and click until you find the
appropriate directory (or printer) then you drag the icon for the directory over to the drive
letter (or device) of your choice. You can change your password, again by filling in boxes on
a simple dialog box. There is one restriction we've uncovered: path names can't be any longer
than 64 characters in total, so if you have some long ones you'll have to use the MAP
command outside of the graphical utilities.
Indeed, Novell has greatly reduced the number of utilities with 4.0: down from approximately
130 different ones in 3.11 to about 50 in 4.0. It is a welcome consolidation, although for old
Novell hands it will take some getting used to locating where the new commands are now
living.
If you wanted to change options for your printer, for example to print a banner page or do a
form feed or whatever, again, it is a simple series of mouse clicks and you are done. No more
learning the syntax of MAP, SETPASS, or CAPTURE commands. You can still use these
and all the other NetWare command line utilities, depending on your own inclinations, but the
new graphical utilities will handle most of the day to day activities.
The final piece of client improvement deals with network administration. Previously, there
was a set of DOS character-mode utilities that administered NetWare servers: SYSCON,
PCONSOLE, and the like. Now Novell has put together new ones: NETADMIN for DOS or
NWADMIN for Windows and OS/2 machines. You'll need at least 6 Mb and 12 Mb of RAM
for Windows and OS/2, respectively, to run these utilities.
They build on the drop and click metaphor used in the end user utilities, and make moving
about the directory tree and assigning aliases and other administrative chores much easier than
in the days of running SYSCON and operating on each server individually. This will take the
most relearning for those network administrators who have taught themselves all the various
quirks of SYSCON -- but by the time you've built your tree several times (after many fits and
starts), you should be able to get the hang of the new graphical utilities.
Managing Storage
But new client software is not the only significant change to NetWare 4.0. Another important
feature has to do with how NetWare handles file storage. Novell has anticipated the need for
storing more than just spreadsheets and documents on its servers: desktop publishing, video
images, multimedia presentations, and other applications will require a new series of storage
devices for your networks. Why? Data storage for these types of applications can change
quickly and in big increments: a presentation can be created overnight and can occupy tens or
hundreds of megabytes of disk space. Once it is finished, these files may not be touched by
any user for many months -- in the meantime, it makes sense to move that data to a less
expensive parking spot, and free up those megabytes for other active applications.
To make things easier for you, the end user, network administrators will have to get more
involved in managing your storage needs: understanding the ebb and flow of the user data,
balancing between expensive and quick magnetic disks and slower but cheaper alternatives.
The added complexity of the network is offset by the savings realized in storage devices. If
your business is getting more involved in these kinds of applications, you should investigate
the benefits of NetWare 4.0's storage management features.
There are several aspects to NetWare 4.0's storage management, ranging from disk
compression to data migration.
First up is compression-on-the-fly. That means that the NetWare server itself takes care of
uncompressing your files at the time you access them on your server, and compressing them
after the file is closed. (Files stored on your own local hard disks of course are not handled
by NetWare's compression algorithms but by your desktop's operating system.) All of this is
done without you having to change anything -- it happens automatically and quickly, too.
This is the first server-based compression algorithms to ship: Neither earlier versions of
NetWare nor NT offers any form of compression built-in to the LAN operating system.
Novell states that compression can save more than 60 percent of space on average. This
means if you have filled up your server's 1 gigabyte disk, you will free up 600 megabytes of
space after you turn on compression. Actual mileage will vary tremendously, given some
preliminary research by ZD Labs. They took a variety of data files from various applications
and found that up to 90% of the space was reclaimed by compression, particularly
multimegabyte database files. A total of nine files that occupied over 17 megabytes were
compressed to less than 2 megabytes. This has powerful consequences for businesses that are
running out of storage space on their servers, and especially for servers that contain lots of
databases and documents that lend themselves towards compression. For example, prices for
external SCSI hard disks range from $1 to $2 per megabyte, so the return on this feature can
add up to several thousands of dollars across an enterprise.
You would think that compressed files would take more time to open up by an application,
given that NetWare has to first uncompress them. However, the reality is that in most cases,
opening compressed data files doesn't take any additional time. Most applications only open a
small part of a large file anyway: for example, database applications only read in the indexes
and the first few records, even for files that are megabytes in size. This means that the time
involved in uncompressing the relatively small amount of data that the application has to
initially access is imperceptible by the user compared to the time involved in accessing an
uncompressed file.
The biggest differences in file open times would be for spreadsheets and graphics
applications. In these situations, often the entire file is loaded into memory. We asked ZD
Labs to open a 1 megabyte Excel spreadsheet both compressed and uncompressed. The
compressed spreadsheet took 18 seconds to open while the uncompressed spreadsheet 14.5
seconds.
Every NetWare 4.0 server volume has the ability to automatically compress files -- indeed,
this is the default setting when the server is installed. But this doesn't mean that every volume
and every file on the server has to be compressed, or even that every file will be compressed.
You can select which directories and files should be candidates for compression if you are
uncomfortable about maintaining the data integrity for these directories, evidence of the
compression's reliability to the contrary.
There are two types of compression: one that occurs immediately, when a user designates a
particular file be compressed, and one that occurs in the background, when the server itself
decides. Both have a variety of parameters and options:
Users (or network administrators) can set their own compression routines via several
mechanisms: the FLAG command, through the FILER utility, or through the Windows and
OS/2-based NWADMIN utilities. Here there are two options: immediately compress (option
IC) or don't compress (option DC). For example, to set all files in the user directory
SYS:DATA\STROM to immediately compress, you would type in the following DOS or OS/2
command:
FLAG SYS:DATA\STROM IC
What happens if the network administrator has enabled compression for the entire volume,
and you want to change that for your files? You can do so, with any of the above commands.
The second option is to have the network server search through its own files at a designated
time and do the compression automatically. (The default parameters are for this searching to
take place from midnight to 6:00 am.) An alternative is to search for files that haven't been
touched for a certain number of days (the default is seven days) and then do the compression.
In either case, the compression happens in the background and is the lowest priority task that
the server tends to. This means that if there are spare CPU cycles left over from everything
else the server is doing, then it will attempt to perform compression. So the time invested in
compression is purely a server function, and shouldn't effect the overall performance that a
network user sees at all, at least from what we can see with our preliminary tests.
[NOTE TO MARTY: MULTIPROCESSING DOESN'T HAVE ANYTHING TO DO WITH
THIS. IT IS JUST ANOTHER LOAD ON THE SERVER. COMPRESSION STILL
HAPPENS WHEN THERE IS NOTHING ELSE GOING ON.]
NetWare 4.0 is actually very smart about its compression algorithms: it does a test calculation
before compression takes place: if no significant space will be saved by the compression
activity, it doesn't perform the operation. What amount is significant? That's up to your
network administrator, who has to set the parameter for each server (the default is two
percent).
There are some other considerations to compression, however: changes in the relative time in
file access, reliability, and how compression interacts with tape backups.
What about reliability? Although we haven't been running NetWare 4.0 for very long in either
our labs or our offices, we can state that we haven't had any problems with compression
corrupting files. What if a server is powered down or a disk drive crashes during the
compression? Novell has thought this through: the original file is not touched until the
compression routine is completed and checked for errors.
A third concern has to do with the interaction of the compression and tape backup routines.
Unfortunately, you can't run both concurrently: the compression should be completed before
any automated backup operations begin. That's a limitation of the way that Novell has
designed NetWare 4.0. Novell recommends that any compression take place two hours before
the backup cycle, which could affect your operations if you use the network at the off-hours
that these operations are taking place. The reason for the two hours is to give the
compression routines time to complete their activities before beginning the backup.
Even given these concerns, compression is a good idea: you save on disk space with little
impact on overall real-time use, and unlike the compression features in DOS, most of it can
be managed without much intervention by the user. It doesn't cost anything, in terms of time,
extra software options, and indeed it can save a few thousand dollars in the long haul by
deferring disk storage purchases.
But compression is just one of three important tools for managing network storage. The
others include migrating data from magnetic to optical devices and dynamic allocation of
block sizes.
Data migration means that files that haven't been accessed for a specific amount of time get
moved to less expensive (per megabyte, that is) storage devices such as an optical disk or
tape drive, keeping a pointer on the hard disk showing the way. When a user wants access,
the data is brought back to the magnetic disk. The migration works in conjunction with a new
file system, called High Capacity Storage System or HCSS. This file system uses the same
commands as NetWare to manage its storage. Files and directories look the same under this
file system as they do under whatever client operating system you are using, provided you are
using DOS. Currently, HCSS does not support migrating either OS/2 HPFS or Macintosh
files.
Current devices that support HCSS include Hewlett Packard's C17xx optical jukebox, and
SCSI devices that are attached to the server via one of Adaptec's host adapters. Novell is
testing at least three others that might be out by the time you read this.
Migration happens to each individual file according to the last time it was accessed by an
application. You can set various parameters, such as the time of day when files migrate (the
default is 1:00 am) and when to start and stop migrating based on how full your magnetic
disk is (the defaults are migration starts with less than 10 percent free space remaining on a
drive, and stops when there is more than 40 percent free space available). And, you can keep
certain files from migrating, such as your NetWare executables or your three most popular
databases. All that is required is a command choice (via the "DM" option in FLAG or the
equivalent graphical utilities).
This is still the beginning for this feature for Novell. The limited number of devices and file
systems that are supported show that it has a long way to go. Nevertheless, migration gives
network administrators powerful controls over managing their storage.
But it would be useless if another feature, called block size length, remained the same from
version 3.x. In previous versions of NetWare, files were stored with fixed block lengths, with
the length decided at the time the server's volume was installed. Say you store a file that is 10
kilobytes on a server with 4 kilobyte blocks (the usual choice). Your file took up 3 blocks,
and wasted 2 kilobytes of space. Choosing a fixed block size meant that network
administrators would have to guess as to the type of files that would ultimately be contained
on their servers: guess too high, and they got lots of wasted space and lower overall storage
capacity; guess too low, and their server is spending lots of time storing small chuncks of
files.
NetWare 4.0 has changed this guessing game, making things better for network
administrators. It works more efficiently and works with larger block sizes than previous
versions, carving up any partially unused blocks into 512 byte pieces that share the leftover
parts of files. In our example above, the 10 kilobyte file would take up two 4 kilobyte blocks
and four 512 byte pieces, leaving no wasted space.
NetWare 4.0 determines the default block size based on the size of disk storage and how
much memory your server has. [MARTY: THAT's JUST THE WAY THEY DO IT. SOME
OF THE RAM IN THE SERVER IS USED FOR CACHING PURPOSES.] The amount of
memory required is directly proportional to the block size, but the larger the block size the
faster your files will move from the disk to your workstation.
Other features
There is much more in this product than we have mentioned: a complete Asymetrix-based
Toolbook courseware to give you a broad overview of the product is available on the same
CD that comes with the product, for example. All of the manuals have been put on-line in a
format called Electro Text, which unlike earlier Folio-based help system is actually quite
usable, and visually is equivalent to the printed documentation. We liked the electronic
version because of how easy it was to search for particular terms in the entire set of manuals,
which we could then browse electronically or go to our paper copies. (Paper is an extra
charge, by the way.)
The Future
Novell isn't standing still, as you can imagine. They are hard at work on bringing complete
System Fault Tolerance level 3 to NetWare 4.0: this is the feature that two separate servers
work together, so that if one goes down the other continues, users don't see any interruption.
Novell won't have SFT3 ready for NetWare 4.0 (it is currently shipping for 3.x servers) until
later this year. Also expect more improvements in the non-DOS client arena, and continued
work by the hundreds of third-party vendors to incorporate the NDS features into their own
products that previously were Bindery-aware, such as fax and print servers and network
management utilities.
Who Should Buy NetWare 4.0? (box or sidebar)
Strongly consider purchase now if you have:
-- more than four servers in more than two locations
-- more than 2 gigabytes of total storage on your file server now
-- have more than 600 users
Steer clear from NetWare 4.0 if you have:
-- greater than 75 percent of your clients are Macintoshes
-- a single server in a single location
-- have VINES and are happy with your support and setup
Click here to return to the
previous
page
David Strom
Port Washington, NY 11050 USA
US TEL: 1 (516) 944-3407