by James Causey
A glance at any current computer industry magazine will show you the recent upheaval in desktop system LAN/WAN (Local Area Network/Wide Area Network) products. Upstart products, such as Microsoft's Windows NT, have caused a firestorm of competition and activity in the PC networking market and have even threatened to encroach upon the territory of such high-end operating systems as UNIX.
However, such competing products all owe their market, and much of their history, features, and functionality, to the long-term reigning king of the LAN: Novell's NetWare. NetWare deserves the lion's share of the credit for elevating PC-based local area networks from being cute toys to providing powerful, reliable, and serious network services. NetWare was the first Intel-based network operating system to provide a serious alternative to mainframe-based server networks, providing critical reliability and security features needed in the modern enterprise.
Recently, Novell seems to be undergoing a great deal of difficulty competing with companies such as Microsoft in the server market. However, the vast majority of installed LAN servers still run one version or another of NetWare, and this will continue for some time into the future. NetWare can still be an excellent choice for use as a network operating system, and even if you choose to use another OS, chances are you will run into NetWare servers in the modern enterprise. This chapter will help you to understand the features and limitations of NetWare, both so that you can decide whether or not to go with NetWare as an NOS (Network Operating System) and so that you will be more prepared for future encounters with NetWare networks.
Early on in the rapid expansion of the PC desktop market, it was realized that networking PCs together into a LAN would be a very good thing. It would allow the computing power on those desktops to be used not only to replace the networks of dumb terminals used to communicate with enterprise back-end mainframes, but creating LANs would also give users of those desktop systems a much easier way to share resources, such as files, applications, and printers.
One of the earliest vendors to innovate in this market was Novell. Novell's first NOS product was called S-Net. S-Net was an entirely proprietary NOS, relying on a star-based network whose center element was a specialized computer running the S-Net OS on a Motorola 68000 processor. Needless to say, this solution hardly revolutionized the market.
Novell quickly realized the inherent limitations of such a solution, however, and released the first product in the NetWare line: NetWare 86. NetWare 86 was designed from the beginning to provide a multitasking, centralized file, print, and application server, running on the IBM PC XT with an Intel 8086 processor. NetWare was, and still is, a custom-designed operating system, specifically written to perform the tasks of a central LAN server. It is not designed (nor is it suitable) for use as a workstation operating system; NetWare is a dedicated server operating system.
NetWare immediately provided a huge advantage over the competition at the time it was introduced: It was a multitasking operating system, allowing it to perform as a server for multiple connections at once. Competing products, such as Microsoft's MS-NET, could not perform in this role, based as they were upon MS-DOS. In addition, NetWare provided security comparable to that of mainframe systems, with user and group authentication, and file- and volume-level security restrictions. When compared to the rudimentary (or nonexistent) security implementations of competing LAN NOSs, this level of security proved a real boon to LAN managers.
NetWare rapidly took off and gained dominance over the PC LAN market. To take advantage of improvements in PC hardware architecture (see Figure 22.1 for a timeline), NetWare continued to be rewritten and revised to add more functionality.
FIGURE 22.1. The NetWare product family.
NetWare's next major release was NetWare 286. For NetWare 286, Novell rewrote the OS in 80286 assembly language to take advantage of the performance and architecture advantages of that processor. In addition, a new version of NetWare was added to the product line: SFT (System Fault Tolerant) NetWare 286. SFT NetWare was designed to include still more features in a LAN server previously unseen outside the mainframe market: the ability to provide levels of fault tolerance. Standard NetWare 286 was retitled Advanced NetWare 286, and both products were available for some time.
By this time, other NOS vendors had risen to the challenge and released competing products to try to reduce NetWare's market dominance. Microsoft and IBM collaborated on LAN Manager (or LANMAN) based NOSs, running on top of their multitasking OS/2 operating system. LAN Manager-based NOSs enjoyed a great deal of success in many markets (due to the marketing power of Microsoft and IBM, and LANMAN's suitability and performance in some specific network configurations), but NetWare's feature set and better networking support helped it continue to lead LANMAN networks by a large margin.
NetWare's other major competitor at that time was VINES from Banyan. VINES is a NOS based on a highly modified UNIX System V core. VINES uses industry-standard internetworking protocols, such as TCP/IP, and as such performed better in integrated LAN/WAN situations than did NetWare. In addition, VINES included a directory service by which all network services could be accessed by a symbolic name with centralized management and user login, no matter where their location on the network. These features helped Banyan compete well against Novell in many markets, but NetWare continued to lead the market.
As the LAN market grew, interoperability between desktop operating systems became more and more important. Novell began to address this issue by adding the ability to serve files and printers to Macintoshes in a release of SFT NetWare 286. Novell also tried to take over the peer-to-peer networking market with a product called ELS NetWare, which eventually proved to be a market failure.
When Intel released the 80386 processor, Novell took a look at their product and made a number of significant changes to it. First, they realized that reliance on assembly language, while providing excellent performance, would make the process of updating their products more and more difficult as hardware architectures advanced and changed. In addition, Novell wanted the ability to port certain NetWare services to other platforms to increase NetWare's interoperability with other NOSs. In order to achieve this goal, NetWare was rewritten entirely in C for the 80386 and released as NetWare 386. NetWare 386 included all the features of NetWare 286, including the fault tolerance additions made to SFT NetWare. NetWare 386 also included the ability to more easily design and install add-on products called NLMs (short for NetWare Loadable Modules).
In order to reduce the confusion inherent in their vast array of products, Novell later merged and retitled their product lines. All versions of NetWare 286 were merged into a new version of NetWare designed primarily for 80286 processors, called NetWare 2.2. NetWare 386 became the NetWare 3.x series of operating systems. ELS NetWare was scrapped, and Novell released NetWare Lite to provide simple peer-to-peer NOS services between workstations. Figure 22.2 illustrates this merging of lines, with the latest version numbers of the merged products.
FIGURE 22.2. The merging of NetWare's product lines.
The next version of NetWare provided the most significant leap forward of any version so far. NetWare version 4 introduced a number of improvements to the OS itself, including better memory management and a vastly improved file system. Its most significant addition, however, was the introduction of NetWare Directory Services, or NDS for short. NDS was designed to compete with the directory services provided by products such as Banyan VINES, giving a centralized login and network management model for a NetWare network (we'll talk more about NDS later on in this chapter). This radical change in network design and management also caused the tools, both on the server and on the client, to change as well. NetWare 4 also required a new set of workstation clients in order to utilize the features of NDS (though Version 4 could emulate the network model used by 2.x and 3.x servers, and older clients could be used with that emulation). NetWare 4 required much more powerful hardware than did earlier versions of NetWare, and required a new set of installation, support, and administrative skills to be developed by the LAN administrator.
At the same time, the most significant competitor for NetWare yet to appear began rapidly gaining industry support and popularity: Windows NT. (For more information on Windows NT, see Chapter 21, "Windows NT 4.") Novell began seeing a sharp decline in sales and popularity as competitors such as Windows NT began to gnaw at their market share. While the majority of LAN servers still run Novell products, NetWare continues to decline in popularity compared to more modern operating systems. In order to combat this, and provide a competitive set of features, Novell recently released IntranetWare, a product designed to bridge the gap between LAN-centric NetWare networks and Internet/intranet services provided by OSs such as UNIX and Windows NT. It remains to be seen whether or not IntranetWare can stem the tide of shifting popularity. Novell has also worked with a number of vendors to port NetWare to other platforms, such as Apple's Macintosh Workgroup Server. Most of these porting efforts have been abandoned, while Novell focuses on their current core market: Intel-based LAN/WAN servers.
Despite Novell's current woes, NetWare is still a highly viable NOS product, with many advantages and features still not seen (or not implemented as well) in competing products. In order to better understand NetWare's pros and cons, let's take a look at the system architecture behind the current NetWare product line.
NetWare's architecture is rather simple and easy to understand. It has been refined to provide a higher level of service and a greater level of reliability, but it still retains the simplicity of its original, dedicated server design.
NetWare utilizes a monolithic design model, much like operating systems such as MS-DOS. A NetWare server consists of only two major components: the system's kernel and additional application and service process NLMs. Figure 22.3 contains a depiction of NetWare's system architecture.
This simplicity belies one of the core architectural flaws in NetWare: there is no inherent modularity or protection for the operating system built into the system's design. A NetWare server's reliability relies on the proper behavior of each application; therefore, NetWare applications must be very carefully designed and debugged, lest they severely limit the reliability of a mission-critical NetWare server. This simplicity, however, allows NetWare servers to achieve very high levels of raw performance and throughput.
FIGURE 22.3. NetWare's system architecture.
NOTE: NetWare's sheer speed as a file and print server has been well respected for many years, and cannot yet be matched by competing products such as Windows NT Server; in fact, it was once said that on many systems, accessing files over a drive redirected to a NetWare volume was faster than accessing those same files on a local hard drive. This speed, however, comes at the potential cost of reliability and modularity.
The NetWare kernel provides the operating system's essential services. The services include such essential functions as process creation and destruction, memory allocation and release, hardware manipulation, and input/output functions. See Figure 22.4 for an illustration.
FIGURE 22.4. The NetWare OS kernel.
The kernel is responsible for management of individual processes, or instances of instructions that execute applications or perform services. These processes are cooperatively multitasked by the OS kernel; in this model, the kernel launches or awakens each individual process. Each of these processes, in turn, has a monopoly over the CPU and other system resources until they choose to release them, at which time the kernel awakens another process.
NOTE: This form of multitasking differs from preemptive multitasking, where the operating system has complete control over system resources and can actively switch resources between each running process. Each process receives a priority rating, which designates its access priority to and length of time for which it receives system resources. If an application locks up, hangs, or dies, the operating system can destroy that process and continue running. This form of multitasking is the most fair to each process, which is important in multiuser operating systems such as UNIX, as well as workstation operating systems where a user needs to run many applications at once.In a cooperative multitasking system, however, each process can monopolize system resources until done with them. This allows critical processes to complete essential tasks more rapidly, or in real-time if necessary. However, if a process hangs or dies while monopolizing those resources, the entire system can hang. According to Novell, cooperative multitasking is more appropriate for a server operating system, because it provides the highest level of performance; however, poorly written services or NLMs can crash the entire server. For this reason, it is critically important that NLMs be well written and very well tested.
Each process running on a NetWare server, whether a system service or a subprocess of an NLM, receives the same cooperative treatment, as well as having complete access to the server's entire memory pool. See Figure 22.5 for an illustration.
FIGURE 22.5. NetWare processes have unlimited resource access.
NetWare's lack of operating system-enforced memory protection is, again, an enhancement to performance, because each access to memory does not have to be verified by the OS as being part of an application's own memory pool. The possibility of an application modifying memory locations used by other applications, however, and therefore causing them to return unpredictable data or even crash is significantly increased.
Nonetheless, steps have been made to increase NetWare's reliability, at least from the perspective of memory management. First, let's look at how NetWare 3.x and 4.x allocate memory.
NetWare 3.x divides memory into six pools (see Figure 22.6).
FIGURE 22.6. NetWare 3.x memory allocation.
During the life of a system, however, these pools may need additional memory beyond that originally allocated to them. In order to provide for this growth, each pool can gradually take memory away from the file cache buffer pool. This memory is not, however, returned when the allocating process terminates. This has the effect of both impacting server performance (when the file cache buffer pool is severely depleted, fewer data blocks can be cached from disk, thus requiring more disk input\output) and potentially limiting stability (by making memory management tasks for writers of NetWare NLMs more difficult).
NetWare 4.x addresses this problem while not impacting performance. It does this by treating all memory as one contiguous memory pool (see Figure 22.7).
FIGURE 22.7. NetWare 4.x memory allocation.
As processes are launched, they allocate memory by borrowing pages from the file cache buffer pool. When this memory is no longer needed, and/or the allocating process terminates, the allocated pages are returned to the cache buffer pool. The inexorable memory leakage found under NetWare 3.x is therefore eliminated, both reducing the damage to server file caching performance and allowing more efficient use of allocated memory by other processes. This simpler memory management is also faster, thus actually increasing memory management performance.
In addition, NetWare 4.x takes better advantage of the Intel processor family's design to provide better system memory protection. The Intel x86 processor family uses a series of hard-coded protection layers, called rings, in which applications can execute (see Figure 22.8).
Each ring provides a reduced subset of the processor's set of instructions; in addition, code running in a ring can only directly manipulate memory allocated to it and to other processes running within that ring.
NetWare 3.x does not take advantage of the memory and instruction security provided by this ring architecture; all processes on a NetWare 3.x server run in Ring 0 (see Figure 22.9).
Because all instructions are available to each process, however, and no context switches between rings have to be performed, NetWare 3.x servers perform CPU-intensive tasks very rapidly.
NetWare 4.x maintains the performance abilities of a Ring 0 operating system, while adding the ability to force individual NLMs to run in an outer ring (as illustrated in Figure 22.10).
FIGURE 22.8. The Intel x86 processor ring architecture.
FIGURE 22.9. NetWare 3.x runs entirely in Ring 0.
While those NLMs are then forced to perform context switches to access OS services, they cannot manipulate the memory used by the kernel, therefore increasing reliability. Once an NLM is proven to be reliable, it can then be moved to Ring 0 for better performance.
We've examined some issues behind NetWare's architectural design, as well as the pros and cons of those decisions. Now, let's examine NetWare's networking.
FIGURE 22.10. NetWare 4.x can place NLMs in outer rings.
NetWare has been designed as a network operating system, and specifically, as a file, print, and application server operating system. In order to better understand its value as a server OS, let's take a look at how NetWare networking is performed. We'll look at a NetWare server's networking stack, examine the differing models for setting up a NetWare network, and discuss the issues involved in integrating NetWare with other network products.
NetWare's network stack was originally designed for optimum server performance using Novell's proprietary IPX/SPX protocol. The vast variety of network card drivers, and the desirability of supporting other protocols (such as TCP/IP), later caused Novell to modify the NetWare network stack to be more modular.
NetWare 3.x and above uses a mechanism called the Open Data Link Interface (ODI) to layer and modularize its network stack. The ODI specification, developed by Novell and Apple Computer, allows vendors to provide protocol and network drivers that can plug into the ODI network stack without the need for protocol- or system-specific customization. This modularity makes the processes of designing and implementing network protocols and network card drivers simpler, and causes fewer headaches for the server administrator.
Let's take a look at the ODI stack NetWare uses, from the top down. Figure 22.11 contains an illustration of NetWare's network stack.
FIGURE 22.11. The NetWare ODI network stack.
At the top of our diagram we have the NetWare Core Protocol (NCP) services. NCP is the application layer of the NetWare protocol stack, providing generic networking API that NetWare's services and NLMs can call to gain network access and to perform networking tasks. These basic services, originally oriented toward providing the services needed by a NetWare client/server network, have recently been expanded to also provide access to TCP/IP socket services, for performing Internet/intranet services such as serving WWW (World Wide Web) pages and acting as an FTP (File Transfer Protocol) server.
Directly below the NCP layer lies the Streams interface. The Streams interface was originally designed for UNIX System V. Streams provides a generic, modular interface for network and transport protocols, so that they can be plugged into a network stack without requiring protocol-specific programming either higher up in the stack or in the stack's lower levels. In NetWare 3.x and higher, the streams interface abstracts access to two protocols: the standard IPX/SPX, used most commonly for NetWare networks, and TCP/IP, used for Internet/intranet services as well as NetWare/IP (which we'll discuss later).
Beneath the Streams interface, we find the Link Support Layer (LSL). The Link Support Layer is one of the most important pieces of the ODI specification. The LSL acts to provide a virtual interface between network cards and card drivers and higher-level protocols. Before virtualizing layers such as the LSL became commonly used, operating systems required a new network stack for each network interface card, making administration of network operating systems (and the design and programming of network stacks) difficult and time-consuming. The LSL allows each vendor to design the drivers for their network cards to plug into a common interface, which in turn provides a common interface into which upper-level network stacks can be plugged. Designers of the various portions of the network stack do not need to be familiar with the exact design specifics of modules that lie at higher or lower levels in the stack, as long as they understand the virtual interfaces provided by those modules.
Finally, at the bottom of our stack, we have various MLID (Multiple Link Interface Driver) drivers. Each MLID driver is designed specifically to operate with a given NIC (Network Interface Card) or series of NICs and provides a common interface that the LSL can use to transfer data back and forth from the card to the operating system. The LSL allows multiple MLIDs to be loaded at once, allowing for servers that use multiple network cards (such as multi- protocol routers).
NetWare 3.x was designed to serve as a standalone file, print, and application server, using the IPX/SPX protocol. Individual groups and organizations can maintain individual NetWare 3.x servers, each of which has its own resources (such as data volumes and print queues). See Figure 22.12 for an illustration of this concept.
FIGURE 22.12. An example of a NetWare 3.x network.
In addition, each NetWare server maintains its own security database, known as the bindery. The bindery contains users and groups, along with those users' passwords and rights to server objects (such as files, printer queues, volumes, and other resources). This model works fine when individual departments maintain their own IS departments, and each user only needs access to NetWare resources within their department. However, if those users need to access resources located on multiple NetWare servers, the administration of those users rapidly becomes complex. Each user needs either to maintain a long list of passwords for each server's resources, or the user will need to tackle the complex and difficult (and potentially insecure) process of synchronizing their various passwords across the network (see Figure 22.13 for an example).
Because of the rapid growth in popularity in large enterprise networks, Novell decided that the use of individual binderies on servers was impractical. With NetWare 4.x, Novell introduced a new network model: NetWare Directory Services (NDS).
FIGURE 22.13. NetWare 3.x servers each maintain a local security bindery.
NDS is designed to provide the same types of advantages as competing products, such as Banyan VINES: a single, global database of network resources accessible through one login. All network resources, whether users, groups, or servers, are treated as objects. These objects exist within a tree architecture (see Figure 22.14).
FIGURE 22.14. An example of a NetWare directory services tree.
An NDS tree is organized into two different object types: containers, and resources. Containers can be used to organize resources by type (for example, you could have containers named users, printers, and servers), or by organization (as in Figure 22.14--administration, infrastructure, and marketing).
Each user in an NDS tree logs into the entire tree rather than logging into an individual server. When logging into the tree, users specify a default context, which defines the container in which their user object lies. For example, in Figure 22.15, user JOEBOBFRANK would specify the default context SALES.SANJOSE.USERS at initial login time.
FIGURE 22.15. An example of a user logging into an NDS tree.
The NDS tree, and all objects within it, are stored in a database. This database is replicated to all servers within the tree, which enhances login performance (each user can be authenticated to the tree by the most local, fastest responding server) and makes the tree more fault tolerant (no one server failure can bring down the entire tree). See Figure 22.16 for an illustration.
Changes to an object, such as password revisions or server removals, can take a long time to be recognized by the entire tree, as the update is carried around from server database update to server database update.
Because of the many changes in network access brought about by the advent of NDS, newer network clients must be used on client workstations in order to authenticate to an NDS tree. In order to provide services to Bindery NetWare clients, a NetWare 4.x server can be run in bindery emulation mode, in which NDS database objects are translated into bindery objects, which can then be accessed with older NetWare clients. This process imposes a serious performance hit on any servers performing bindery emulation, however.
FIGURE 22.16. Database replication in an NDS tree.
NDS provides a number of advantages. Network resources can be organized, viewed, and managed in a logical format, without regard to physical location. In addition, a single network login is available to all users within the tree, and resources from any container can be accesses by any user in the tree, as long as appropriate rights are granted. The complexity of this model, however, limits its scalability in very large organizations, as it becomes difficult for servers to manage and update the massive NDS databases. In addition, the complexity of the model, and its many differences from previous versions of NetWare, can make it difficult to manage, especially for LAN administrators familiar only with NetWare 3.x and older.
NetWare's prevalence as a server operating system does not eliminate the utility, or necessity, of other major network operating systems. Though NetWare was originally designed to serve Intel-based MS-DOS and Windows clients, in order to make the product more successful Novell (and third-party companies) has added the ability to integrate NetWare servers and networks with networks using many other network operating systems:
Novell has traditionally provided clients for all Microsoft desktop operating systems to access both bindery and NDS resources, and they continue to do so for Windows NT. Microsoft also includes products that allow NT users to access NetWare networks, but due to Novell's closed network architecture, they traditionally lack some functionality (for example, the Microsoft NDS client for Windows 95 cannot run NetWare Administrator, a graphical tool for managing NDS networks). Novell's products do not have these limitations, though they often face some issues with reliability and interoperability with other operating system modules.
Novell has also integrated Windows NT into their Windows desktop management products, such as ManageWare. Novell also produces an NT-based administration tool for NDS networks.
One very recent product from Novell addresses one of Windows NT's current weaknesses: the complexity and potential lack of scalability of Windows NT Domains (see Chapter 21 for more information). The Novell Administrator for Windows NT allows Windows NT resources, such as users, groups, shares, and print queues, to be integrated into NDS by synchronizing NT domain and workgroup SAM databases with an NDS database.
The current wars that rage in the industry about the viability of NetWare as an operating system often obscure the facts. NetWare is an older, monolithic operating system, with an architecture and system design that lacks some modern features. However, Novell believes that some of these features (such as preemptive multitasking) do not belong on the file server. In any case, it cannot be argued that Novell servers, with proper care and the use of high-quality third-party products, cannot be used as reliable, high-performance network servers. Indeed, due to some of the architectural decisions we've looked at above, a NetWare server can often outperform any other competing product in raw throughput.
There are a few advantages to NetWare not currently provided by any other major competitor:
There are a few circumstances, however, in which NetWare may not be the right choice for you:
Novell's recent troubles, and the massive growth in popularity of Windows NT Server, have caused the industry to cast a disparaging light on NetWare-based network solutions. While NetWare currently suffers a number of disadvantages when compared to more modern operating systems, NetWare also has a number of advantages unmatched by any of its major competitors. Whether or not NetWare is right for you will depend on your specific needs and future plans.
© Copyright, Macmillan Computer Publishing. All rights reserved.
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}