NetWare 6 Scales New Heights
Articles and Tips: article
01 Oct 2000
Editor's Note: Novell recently announced the next generation of NetWare--NetWare 6. This article focuses on how the scalablity features in NetWare 6 can help you simplify and secure your company's network as well as accelerate your company's e-business strategy.
Suppose you'd been a king's guard in the 1400s or 1500s. When you were on the job and perched on top of one of several turrets, the fact that the castle wall was scalable might have left you feeling uneasy. Scalable, in this context, obviously had negative connotations. Of course, you're not a medieval king's guard: You're a network administrator in the 21st century. When you're on the clock and hanging out in your office (or cubical), knowing that your network is scalable is comforting.
Scalability, as you know, is a system's ability to expand to meet increasing demands that arise as your company's network grows--and expanding easily is a good thing. If the systems you purchase expand easily, the implication is that they won't require what press members and marketers call fork-lift upgrades. In other words, upgrading scalable systems doesn't require a lot of money and time spent purchasing and installing new hardware and software. Instead, scalable systems enable you to easily and inexpensively add such things as user connections, applications, and processors.
Of course, some systems expand in more ways and to larger degrees than other systems. NetWare 5.1, for example, is highly scalable on multiple levels. According to Novell, users report that NetWare 5.1 can support as many as 8,000 users per server and commonly supports 1,000 users per server. You can also credit NetWare 5.1 with including a scalable directory: NDS eDirectory, which supports as many as one billion objects per tree. In addition, NetWare 5.1 includes Novell Storage Services (NSS) 2.95, which essentially eliminates restrictions on the number and size of files and volumes that you can create on one server.
In fact, because NetWare 5.1 is scalable in so many ways, you may be surprised to hear that the upcoming NetWare 6, known by its code name 6 Pack , is more scalable than NetWare 5.1.
THE WHOLE SCALABILITY STORY
While working on the NetWare 5.x product line, Novell has been concurrently developing a new NetWare product line. As the first product in this new line, NetWare 6 made its debut as a closed beta that Novell released last month to approximately 30 organizations. You can expect to see NetWare 6 in open beta by February and on the shelves during the first half of next year.
The target audience for NetWare 6 is large companies that have approximately 1,000 or more employees. In such large companies, you'll likely find massive, centralized data centers, also called s erver farms. Many of these companies attempt to minimize the hardware and administrative effort required to run these server farms by standardizing on Intel-based, symmetric multiprocessor (SMP) server hardware.
SMP servers, as you probably know, are designed to use as few as two, as many as 32, but most commonly four CPUs to process data. Any of the available CPUs can handle any task, and all of them can work simultaneously. SMP hardware thus enables you to increase processing power without buying more servers. To reap the rewards of SMP hardware, however, you need an operating system that has been designed to run on SMP hardware.
Recognizing the needs of many of its customers, Novell designed NetWare 6 to make full use of SMP hardware. To this end, Novell started with the already MP-enabled NetWare 5.1 kernel (first MP-enabled in NetWare 5.0) and then MP-enabled NetWare's core components and key services, including an enhanced version of NSS. In addition, Novell decided to include with NetWare 6 an enhanced version of NetWare Cluster Services, which will enable you to create clusters with as many as 32 nodes for increased fault tolerance.
The net result of Novell's efforts is that NetWare 6 is more scalable than all earlier versions of NetWare--even NetWare 5.1. In fact, you could say, as does Novell product manager Tom Mallory, that NetWare 6 has the "whole scalability story."
THE CORE OF THE MATTER
The kernel in both NetWare 5.1 and 5.0 is MP-enabled, which means a couple of things: Saying that the kernel is MP-enabled means that it is multithreaded and that its individual threads can be processed simultaneously by multiple CPUs, where any CPU can process any thread. MP-enabled also means that the kernel recognizes the presence and number of CPUs on a server and distributes individual threads from multithreaded applications among the available CPUs.
In addition to MP-enabling the kernel, Novell MP-enabled several core components in NetWare 5.1 and 5.0, including the C-library (CLIB), RSA encryption, routing functions, and the Multiple-Link Interface Drivers (MLID) and Link-Support Layers (LSL) of the Open Data-Link Interface (ODI). As with the kernel, these components are multithreaded so that any CPU can process any individual thread.
Despite these giant steps toward MP-enabling NetWare, Novell did not MP-enable other important components in NetWare 5.1 and 5.0. For example, in NetWare 5.1 and 5.0, the IP stack is not MP-enabled, which means that this stack cannot take advantage of any additional CPUs that may be available. Because virtually every packet gets pushed through to the IP stack--either via the LSL or a direct hook from an application--the IP stack in NetWare 5.1 and 5.0 is a conspicuous bottleneck in multiprocessing environments.
NetWare 6 will essentially pick up where NetWare 5.1 and 5.0 leave off. In addition to the MP-enabled NetWare 5.1 kernel and its handful of MP-enabled components, NetWare 6 will include MP-enabled versions of essentially all other core components and services that benefit from being MP-enabled. For example, NetWare 6 will include MP-enabled versions of the IP stack, the NetWare Core Protocol (NCP) engine, the web and search engines, NDS eDirectory, and an enhanced version of NSS. (For a detailed list of MP-enabled components in NetWare 6, see "Spread the Threads: MP-Enabled Components.")
Of course, not all NetWare 6 components and services will be MP-enabled. Novell analyzed all of the NetWare components and services and found that some would improve by being MP-enabled and others would not. For example, print services don't have associated scale or performance issues that would benefit from being MP-enabled. Consequently, Novell did not MP-enable NetWare Distributed Print Services (NDPS).
However, NDPS and other NetWare components and services that are not MP-enabled in NetWare 6 will be MP-safe. MP-safe components and services are single-threaded and pose no threat to the system's stability, even when running on SMP hardware. (For more information, see "Upcoming NetWare Game Highlights," NetWare Connection , Nov. 1999, p. 6.) Furthermore, Novell has enhanced many of these MP-safe components and services, including NDPS. (For more information, see "You're Queue-less, but What's New?")
You will be able to run NetWare 6 on hardware from any major SMP vendor. When you install NetWare 6 on SMP hardware, NetWare 6 will automatically detect the number of CPUs available and will distribute individual threads from the kernel and MP-enabled components and services accordingly.
In addition, Novell will test NetWare 6 to ensure that it can detect and make use of as many as 32 CPUs. However, Mallory says, "from the standpoint of hardware availability and from what Novell OEM partners are saying, four-way scalability seems to be the sweet spot." In fact, for now, SMP hardware that scales to eight CPUs represents the high end of the multiprocessing spectrum, Mallory adds.
UP TO SCALE
When a system, such as NetWare 6, enables you to add more CPUs as the need arises, the system is said to provide vertical scalability. As you know, when you scale vertically by adding more CPUs, you increase processing power. However, the relative increase is not at a one-to-one ratio, as you may expect. That is, adding a second CPU to a server does not yield the same processing power that two servers with one CPU each would yield.
Nevertheless, the second CPU does significantly increase the processing power. As a general guide, Novell suggests that you can expect a server with two CPUs to offer 1.8 times as much processing power as a server with one CPU. Of course, CPUs are not solely responsible for the net result of a server's processing power. Several variables can affect the results you experience, including the application you are using, your input-output bandwidth per CPU, and the amount of memory available on the server. (See Figure 1.)
Figure 1: As you add CPUs to an SMP server, you increase processing power, but not at a one-to-one ratio. Of course, this is a general guide: Specific results may vary.
Increasing processing power enables you to run more services on each server and potentially improve the performance of those services. For example, suppose you had an MP-enabled database running on one CPU and that database committed 25 transactions per second at 80 percent CPU utilization.
Now suppose you added three CPUs, making a total of four CPUs available to this MP-enabled database. CPU utilization could then drop to as little as 20 percent on each of the four CPUs. Furthermore, because this database was now committing 25 transactions at only 20 percent CPU utilization, you could make available more input-output bandwidth per CPU. More bandwidth per CPU would, in turn, potentially enable this database to commit more transactions per second.
As a result, you could run more services on a single server. By running more services on each server, you could reduce your total number of servers. By reducing your total number of servers, you might be able to standardize on server hardware and thus minimize server management costs.
A 32-PACK CLUSTER
Of course, installing more CPUs on each server and ultimately reducing the number of servers you use has a potential downside, Mallory points out. For example, suppose you manage to reduce your total number of servers from 1,000 to only 300 SMP servers. In such a case, each one of these 300 servers is, in effect, more critical than any one of the 1,000 servers you had before. Why? Because each server is now responsible for more user connections, applications, services, and volumes than any single server you had in the 1,000-server environment.
Consequently, when "one SMP server goes down," Mallory says, to emphasize the obvious, "you have a big problem." NetWare 6 will include a solution to this problem: NetWare Cluster Services 1.6. As an enhanced version of the currently shipping NetWare Cluster Services 1.01, NetWare Cluster Services 1.6 ensures that critical server-based resources--including connection licenses, data volumes, services, and applications--remain continuously available. (For a list of enhancements in NetWare Cluster Services 1.6, see "A Cluster With Luster.")
In other words, NetWare Cluster Services 1.6 (and earlier versions of NetWare Cluster Services) ensures that if one of those 300 SMP servers unexpectedly fails (as if there is ever an expected failure), no one will notice--not even you, at least not until later or unless you want to know. (For one example of this, read the case study "Losing Weight at COMDEX With NetWare Cluster Services for NetWare 5," NetWare Connection , Mar. 2000, pp. 18-30.)
Furthermore, with NetWare Cluster Services, you won't have to wait until after everyone has gone home for the day to do standard maintenance on one of those 300 servers. You can down a server whenever you feel like it--even when network traffic is at its heaviest--and none of your users will know. NetWare Cluster Services continues to serve a downed or failed server's resources as steadily and quickly as your users have come to expect. (For more information about NetWare Cluster Services, see "Uptime in Real Time With NetWare Cluster Services for NetWare 5," NetWare Connection , Sept. 1999, pp. 6-18.)
Cluster Configurations
NetWare Cluster Services is software that you install on industry-standard hardware (not necessarily SMP hardware) to create a cluster. NetWare Cluster Services enables you to create a cluster by interconnecting as few as two or as many as 32 servers, called cluster nodes. (NetWare Cluster Services 1.6 in NetWare 6 will include a two-node license.) Typically (and as Novell recommends), you then connect these nodes to a shared disk storage system to form what is called a storage area network (SAN). (See Figure 2.)
Figure 2: NetWare 6 will include NetWare Cluster Services 1.6 to help you protect and easily distribute critical server-based resources. NetWare Cluster Services 1.6 enables you to create a cluster by interconnecting as many as 32 servers, which you may then connect to a shared disk storage system.
Using NetWare Cluster Services 1.01, Novell engineers demonstrated two SAN-configured clusters with 32 nodes each at BrainShare 2000, held in Salt Lake City during March 2000. One cluster was based on hardware from Dell Computer Corp. (www.dell.com), and the other cluster was based on hardware from Compaq Computer Corp. (www.compaq.com).
For the Compaq demonstration, Novell engineers installed NetWare Cluster Services 1.01 on top of 32 rack-mounted servers: four Compaq ProLiant 1850R servers and 28 Compaq ProLiant DL380 servers. (See Figure 3.) Each of these servers was also running NetWare 5.1.
Figure 3: At BrainShare 2000, Novell engineers demonstrated two 32-node clusters. This cluster featured four Compaq ProLiant 1850R servers and 28 Compaq ProLiant DL380 servers connected via Fibre Channel to eight Compaq RAID Array (RA) 4100s. (In case you are counting and curious, the racks also held five additional Compaq ProLiant 1850R servers, as well as four beta Compaq ProLiant DL360s, but these were used for other purposes.)
Novell engineers then connected these 32 nodes to three 100BaseTX hubs, which in turn were connected to one Fast Ethernet (100 Mbps) switch. This switch served as the forwarding device between the cluster nodes and four attached clients. The clients were running Novell Client 3.1 for Windows 95/98 (which ships with NetWare Cluster Services for NetWare 5).
Novell engineers then connected the 32-node cluster to eight Compaq RAID Array (RA) 4100s via five Fibre Channel switches from Brocade Communications Systems Inc. (www.brocade.com). Each RA 4100 held twelve 18.2 GB drives, collectively offering 96 drives with 1.75 TB of raw storage.
Keep the Server Side Up
If any one of the nodes in this 32-node, SAN-configured NetWare Cluster Services cluster had failed, one or more of the other nodes would have taken over the resources once provided by the failed node. This fault tolerance is the point of a NetWare Cluster Services cluster.
To detect potential failures, cluster nodes listen for heartbeat packets, which NetWare Cluster Services nodes transmit every second or so. In steady-state operation, these packets are essentially the only node-to-node traffic in a NetWare Cluster Services cluster. In fact, other than generating these heartbeat packets, NetWare Cluster Services does little work (except in times of failure, of course).
Consequently, NetWare Cluster Services "doesn't currently require SMP processing," explains Robert Wipfel, architect for Novell's high-availability solutions. Hence, Novell has not MP-enabled NetWare Cluster Services. Instead, "all cluster threads [in NetWare Cluster Services 1.01] are bound to CPU 0," says Wipfel. "This will likely remain true for NetWare 6 as well."
When surviving nodes take over resources for a failed node, the process is called a failover. Failovers typically take less than one minute and occur automatically when nodes unexpectedly fail. You can also manually invoke failovers when you want to upgrade or service a node without affecting users. You may also manually invoke a failover so that you can load balance the nodes in the cluster.
When a failover occurs, users probably won't know about it. NetWare Cluster Services handles failovers so quickly that users regain access to a failed node's resources within seconds--and, in most cases, without having to log in again. Users notice only the familiar hourglass on their monitor, indicating passing seconds.
Scaling Out
This failover process thus protects the resources running on cluster nodes. In fact, protecting your cluster's resources is arguably the raison d'etre of NetWare Cluster Services. But what does NetWare Cluster Services contribute to the NetWare 6 scalability story? The answer is this: Clustering contributes horizontal scalability.
Horizontal scalability is conceptually similar to vertical scalability. Vertical scalability means that you can add CPUs--as many as 32--to an SMP server on an as-needed basis. Similarly, horizontal scalability means that you can add cluster nodes--as many as 32--to your cluster on an as-needed basis. As with adding CPUs, adding cluster nodes does not affect users. Both processes are transparent (to use an overused industry term).
Just as vertical scalability enables you to increase the number of services running on each server, adding nodes to a cluster enables you to increase the number of services and size of volumes running in a cluster. Fortunately, horizontal scalability also enables you to distribute and balance a growing workload among cluster nodes. For example, if you have one large volume on a single server, NetWare Cluster Services enables you to split the volume and divide it between two (or more) nodes within the cluster.
STORE MORE
The fact that NetWare Cluster Services enables you to split a volume may be a particularly relevant point in the context of a NetWare 6 discussion. The point of relevance has to do with the fact that NetWare 6 will include NSS 3.0, an MP-enabled and otherwise enhanced version of NSS, as its default storage and access system. Like previous NSS versions, NSS 3.0 uses a 64-bit interface that enables it to support volumes as large as 8 TB--a size that would probably prompt a split.
Furthermore, all versions of NSS support thousands of volumes per server and trillions of files per volume. In fact, NSS supports more files and larger volumes than your company will probably generate within your lifetime. And certainly, no matter how much data your company generates and accumulates over the years, the network will not outgrow NSS.
What is equally exciting is that NSS volumes--regardless of their size--can be mounted in fewer than 60 seconds. The secret behind this mounting speed is the way NSS organizes storage. Rather than using File Allocation Tables (FATs) to organize storage (as the traditional NetWare file system does), NSS uses advanced journaling algorithms called balanced trees or B-trees. B-trees associate every change made to an NSS volume with a transaction. NSS records these transactions (which are comprised of a series of changes) in a journal on the server's hard drive.
If a server crashes before a transaction on an NSS volume is completed, NSS uses this journal to restore the volume by redoing or undoing the recorded transactions. Because the size of a journal is based on expected modification rates rather than on the NSS volume's size, these journals tend to be small. As a result, NSS can replay a journal quickly and, in turn, restore a failed volume (regardless of its size) in less than one minute. (For more information about B-trees, see "NetWare 5 Knows No Limits," NetWare Connection, May 1998, p. 18. You can download this article from www. nwconnection.com/past.)
NSS 3.0 and all earlier versions of NSS are fully backward compatible with the traditional NetWare file system, enabling you to upgrade at your own pace. Your company's cost to upgrade to NSS 3.0 will be minimal: You will not need new server hardware, and your company's servers will not need more memory. As with the traditional file system, NSS volumes require only 32 MB of RAM to mount, regardless of their size.
Yes, but What's New?
Of course, other than the fact that NSS 3.0 will be MP-enabled, nothing you've read thus far about NSS is unique to NetWare 6. Nor is it news to say that NSS 3.0 will support all media formats, including CDs, DVDs, and FAT32, -16, and -12. All NSS versions support these media formats.
NSS 3.0 also will support all major file-system protocols, including AppleTalk File Protocol (AFP), Network File System (NFS) protocol, and Common Internet File System (CIFS) protocol. But this too is old news.
Clearly, all versions of NSS are highly scalable in several different ways. NSS 3.0 will build on this already scalable infrastructure by supporting additional features previously supported only by the traditional NetWare file system:
NSS 3.0 will support SYS volumes in addition to the data volumes that all versions of NSS support.
NSS 3.0 will support file compression. NetWare 6 will be able to compress NSS files that are infrequently used or not used at all.
NSS 3.0 will support user and directory quotas. You will be able to limit the space one user consumes on an NSS directory and the space a directory consumes on an NSS volume.
NSS 3.0 will support the Transaction-Tracking System (TTS). As a result, TTS-enabled applications will be able to protect their transaction data.
In addition, NSS 3.0 will provide native support for software mirroring, a feature previously available only in a support pack. Consequently, NetWare 6 will be able to duplicate data from a NetWare partition on one hard disk drive to the NetWare partition on another hard disk drive, thus providing fault tolerance for NSS just as mirroring has always done for the traditional NetWare file system.
Packed With the Power of NDS
In addition to supporting these features, NSS 3.0 will include a new and optional set of features known within Novell as Distributed File Services (DFS). The DFS feature set is client-server software, the client portion of which will be built into the Novell Smart Client. (The Novell Smart Client will be available this December and will also be bundled with NetWare 6.)
In developing DFS, Novell applied the principles and power of NDS eDirectory to the file system. With NDS eDirectory, users are unaware of the location of NDS objects because the names of objects reveal nothing about the server and disk partition that host them. The DFS features in NSS 3.0 will apply the principle of location-transparent names to files and directories.
When you use the new DFS features, the names of file system resources do not need to reveal anything about the servers and volumes hosting them. In NSS 3.0 environments where DFS features will be at work, users will not need to know that a volume--or even a server--exists. All of the users' files will appear to be stored in directories and subdirectories.
One benefit of ensuring that file system names reveal nothing about the location of file system objects is that such transparency enables you to add or rename servers and volumes without affecting users. That is, depending on how you use DFS features, you will not have to broadcast the news about new or changed volumes or servers. For example, users will be able to access a new volume or renamed volume without having to map another drive to that volume.
What is equally (if not more) appealing is that location-transparent file-system naming eliminates the need for you to map a finite number of drives to the growing number of volumes on your company's network. In its first release, NSS 3.0 will enable you to map a drive to one volume. Users will then be able to access all of the volumes on your company's network to which they have rights. NSS also enables users to access these volumes without any drive mappings.
ONE FOR ALL AND ALL IN ONE
NSS 3.0 will enable you to create what will appear to users with the Novell Smart Client as one storage space (that contains no references to volume or server names). NSS 3.0 will accomplish this through the use of three new features within the DFS features:
A file system object called an NSS Junction object
An NDS object called an NDS Junction object
A database called the Volume Location Database (VLDB)
Creating A Volume Hierarchy
An NSS Junction object is one of several types of DFS-related persistent link objects. When using the Novell Smart Client, users will see these persistent link objects as ordinary file system objects. In fact, they will actually be aliases for other file system objects.
For example, the NSS Junction object, which is the focus of this discussion, is an alias for a volume. You will create an NSS Junction object to build a one-way link from one volume (the volume in which you create the alias) to another volume (the volume to which the alias refers). If you create NSS Junction objects, users who have the Novell Smart Client will see and access multiple volumes by mapping to only one volume. This one volume will include junctions to other volumes on your company's network.
If you are NDS savvy, you may correctly suspect that NSS Junction objects serve a similar purpose as NDS Subreference objects, also known as subrefs. NDS Subreference objects transparently tie disk partitions together into a single NDS space. Similarly, NSS Junction objects will transparently tie volumes together into a single storage space.
For example, suppose you wanted to build a one-way link from the DFS-DEMO1-ROOT to the DFS-DEMO2-USR volume. To do so, you would create an NSS Junction object for the DFS-DEMO2-USR volume within the DFS-DEMO1-ROOT volume.
NetWare 6 will provide two ways to create NSS Junction objects:
You will be able to use the DFS snap-in module for ConsoleOne.
You will be able to use the DFS shell extensions for Windows Explorer.
Regardless of which tool you use, the task of creating an NSS Junction object will be quite simple. For example, suppose you decided to use Windows Explorer to create the link between DFS-DEMO1-ROOT and DFS-DEMO2-USR. The shell extensions Novell created for the DFS feature set in NSS 3.0 would enable you to create this junction by right-clicking and dragging DFS-DEMO2-USR on top of DFS-DEMO1-ROOT. (See Figure 4.)
Figure 4: NetWare 6 will include shell extensions to Windows Explorer that will enable you to create NSS Junction objects by right-clicking and dragging a volume object to the location in the file system where you want to create a junction.
You would then select "Create junction" from a menu that appears, after which a dialog box would enable you to name this object. The default name for the object would be the volume's name, but you could change this name. For example, assume that you named the NSS Junction object USR. (See Figure 5.) After you clicked Okay, you would have created a link from DFS-DEMO1-ROOT to DFS-DEMO2-USR.
Figure 5: When you create an NSS Junction object, you will see a dialog box informing you of the results of your action and giving you the opportunity to name the Junction object you are about to create.
For users who had the Novell Smart Client, this new USR object (like all NSS Junction objects) would look like a directory within the volume where you created it. Thus, in this case, when users who had the Novell Smart Client double-clicked to open the DFS-DEMO1-ROOT volume, they would see what appears to be a new directory named USR. (See Figure 6.) Only you would know that the USR "directory" was an alias for the root of the DFS-DEMO2-USR volume. (If users did not have the Novell Smart Client, the USR NSS Junction object would appear as just another file within DFS-DEMO1-ROOT. These users' access to this volume would be unaffected by the use of the DFS feature set.)
Figure 6: Novell Smart Client will present NSS Junction objects as normal directories within your file system tree. For example, the USR "directory" in the DFS-DEMO1-ROOT volume shown here is actually an NSS Junction object.
NSS Junction objects will enable you to create what amounts to a volume hierarchy. In other words, NSS Junction objects will enable you to arrange your site's volumes into what will appear to be seamless trees (just as NDS subrefs enable you to string together NDS disk partitions). In fact, assuming you have at least one NetWare 6 server running NSS 3.0, you will be able to create NSS Junction objects that refer to any or all of the volumes on your company's NetWare 6 and 5 servers--even non-NSS volumes. Furthermore, creating junctions that refer to the volumes on the NetWare 5 servers will not require you to upgrade those servers.
Grafting Trees
The DFS features in NSS 3.0 will also extend the NDS schema to include (among other things) a new NDS object that will provide a transparent link from your NDS tree to your file system. The NDS Junction object is an alias in the NDS tree for a volume in the file system. After creating a volume hierarchy, you will create an NDS Junction object to transparently link users to the root volume of this hierarchy. As with the NSS Junction objects, you can name this NDS Junction object whatever you like.
To extend the previous example, after creating the volume hierarchy with the DFS-DEMO1-ROOT volume at the root of that hierarchy, you would create and name an NDS Junction object that refers to the DFS-DEMO1-ROOT volume. For example, suppose you named this NDS Junction object FS (for file system).
To users with the Novell Smart Client, this NDS Junction object would appear as an ordinary NDS container object named FS. Only you would know that this FS "container object" is actually an alias for the DFS-DEMO1-ROOT volume. When users with the Novell Smart Client opened the FS "container object," they would see a file system tree that contains several files and directories--including the set of seeming directories that are actually NSS Junction objects.
Thus, with the use of both NSS Junction objects and NDS Junction objects, users who have the Novell Smart Client will see a single storage space that includes any number of volumes and file servers. In other words, when you use DFS features in NSS 3.0, the particular server and volume hosting any given file or directory will become an irrelevant detail to users with the Novell Smart Client.
The Smart Client Knows
NSS Junction objects and NDS Junction objects will contain information that the Novell Smart Client can use to locate the actual volumes they reference:
The fully qualified name of the NDS container object in which the volume resides
The volume's NSS Global Unique Identifier (GUID)
The name of the volume's NDS container object is important because it enables the Novell Smart Client to find the nearest VLDB. The VLDB is a new type of database that the DFS features in NSS 3.0 will enable you to create. Basically, this database contains an always-current list of the locations of the volumes within a particular NDS container object or set of container objects.
Novell refers to the container objects or set of container objects that hold a VLDB as a management context. You can have several management contexts on your company's network. As a result, different departments will be able to create and manage their own VLDB.
NDS container objects that serve as the root of a VLDB management context will have a new attribute called DFS-VLDB-HOSTS. This attribute will identify the location of the server (or servers) running the VLDB for this management context. The Novell Smart Client will first check the volume's parent container object for the DFS-VLDB-HOSTS attribute. If the container object does not have this attribute, the Novell Smart Client will look at the next container object up the NDS tree and so on until the client finds a container object that has this attribute.
After finding the location of the corresponding VLDB server(s), the Novell Smart Client will ask for a list of locations associated with the volume's NSS GUID. An NSS GUID is a unique name that is unmistakably associated with an NSS file system volume. A VLDB server uses the volume's NSS GUID to look up and return the location of this volume. Armed with the proper location information, the Novell Smart Client will then access the volume normally.
In future versions of NSS, each volume may have multiple instances running on different servers. When this is the case, the VLDB will return a list of all of the servers hosting an instance of the volume with this NSS GUID. If the Novell Smart Client is unable to access the volume on one of these servers, this client will transparently connect instead to another instance of the same volume hosted on a different server. In this way, users will have continuous, uninterrupted access to volumes--even when a server running a volume fails.
You will be able to learn more about DFS features in NSS 3.0 in an upcoming issue of N etWare Connection. For now, the thing to remember about the new DFS features in NSS 3.0 is that the concepts of both servers and volumes will become administrative details. Most users will not need to know anything about such details.
CONCLUSION
NetWare 6 will be scalable on multiple levels. NetWare 6 will offer vertical scalability, enabling you to add as many as 32 CPUs to each SMP server. More CPUs per server will enable you to run more services per server and fewer servers overall.
NetWare 6 will also offer horizontal scalability, enabling you to incorporate as many as 32 servers in a NetWare Cluster Services 1.6 cluster. A cluster ensures that your resources are always available, providing users with steady access to those resources under any circumstances. In fact, with a NetWare Cluster Services cluster, users are unaware of server failures or other server down times.
In addition, NetWare 6 will offer storage scalability through NSS 3.0, enabling you to create more and larger files and volumes than you've been able to create in the past. Furthermore, with NSS 3.0, users will not need to know anything about the servers and volumes hosting their files and directories.
The bottom line is this: When you have NetWare 6 running your company's server farm, you will be able to kick back and relax, knowing you have an operating system that is scalable on multiple levels. In fact, with NetWare 6, you will have the whole scalability story--rest assured.
Linda Kennard works for Niche Associates, which is located in Sandy, Utah.
Spread the Threads: MP-Enabled Components
In NetWare 6, many of the core components and services upon which the NetWare kernel depends will be MP-enabled. These MP-enabled components will include the following:
Protocol Stacks
IP stack
HTTP
WebDAV
Lightweight Directory Access Protocol (LDAP)
NetWare News Server
NetWare Core Protocol (NCP)
Service Location Protocol (SLP) 2
Gigabit Ethernet/100 Megabit Ethernet/10 Megabit Ethernet
Token Ring 16
Storage-to-Wire-and-Back Services
Novell Storage Services (NSS) and Distributed File Services (DFS)
Fibre Channel disk support
Transport service request dispatcher
Protocol service request dispatcher
Miscellaneous Components and Services
NDS eDirectory
Novell Java Virtual Machine (JVM)
Search engine
Web engine
Servlet interface (part of NetWare Enterprise Web Server)
Security-Related Features
Authentication
Novell International Cryptographic Infrastructure (NICI)
GUI Audit (a ConsoleOne snap-in module)
You're Queue-less, but What's New?
In addition to the features discussed in the main text of this article, NetWare 6 will include Novell Distributed Print Services (NDPS) 3.0.0, which will incorporate the following new or improved features:
Portal Health for the NDPS Broker. The NetWare Management Portal included in NetWare 6 will enable you to monitor the health of NDPS Brokers.
IPP Gateway. NDPS 3.0.0 will include an IPP Gateway, enabling users to print from a traditional Novell client directly to an IPP printer. (For more information about IPP, see "NetWare Enterprise Print Services: Print Services Made Easy," NetWare Connection, Dec. 1999, pp. 24--35.)
Additional NDPS Gateways. In previous versions, NDPS has included gateways from Axis, Epson, Extended Systems, Hewlett-Packard, Kyocera, Lexmark, Tektronix, and Xerox. In addition to including gateways from these vendors, NDPS 3.0.0 will include gateways from several more printer vendors.
Remote Printer Management Enhancements. Using ConsoleOne or the NetWare Administrator (NWADMIN utility), NetWare 6 will enable you to install printers to a user's workstation based on NDS Group and User objects in addition to Container objects.
Installation Enhancements. Through either ConsoleOne or the NWADMIN utility, NDPS 3.0.0 will give you the option of creating NDPS Brokers manually and strategically placing them throughout your company's network. (In previous NDPS versions, NDPS created Brokers automatically if it was unable to discover and NDPS Broker during a server installation.
A Cluster With Luster
As the version of NetWare Cluster Services that will ship with NetWare 6, NetWare Cluster Services 1.6 will incorporate several new or improved features, including the following:
Resource manager enhancements (improving the way resources are defined and the way resources are handled during failovers)
Simple mail transfer protocol (SMTP) integration (enabling you to be notified of any cluster problems or events)
Simple network management protocol (SNMP) support
Better diagnostic tools
Portal-based management
New command-line cluster commands
Did You Know?
All versions of Novell Storage Services (NSS) support volumes (and single files) as large as 8 TB. Do you know how much information you can store on an 8-TB volume? According to Roy D. Williams, PhD, 1 TB provides enough storage space to hold all of the X-ray films you might find in a large technological hospital. An 8-TB volume is actually only 2 TB shy of being large enough to hold the printed collection of the U.S. Library of Congress, which Williams says would require 10 TB. (Williams, who is a staff member at the Center for Advanced Computing Research, maintains a site that lists these and other estimates on the quantities of data various media can contain. You can access Williams' site at www.cacr.caltech.edu/~roy/dataquan.)
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.