Novell Cluster Services 1.6: Keep the Server Side Up and the SAN Side Simple
Articles and Tips: article
01 Jun 2001
Purchasing storage devices to accommodate the ever- growing need for more space on your company's network is not, as you may assume, the main storage-related drain on corporate piggy banks. The real money hog is the cost of managing your company's network storage. In fact, analysts at Gartner Group told Novell Connection that storage management costs range from 0.4 (best of breed) to 3 or 4 times the cost of storage hardware acquisition.
Assuming that these analysts' claims are true for your company, its storage management costs are progressively (in fact, aggressively) rising. The question is, as a network administrator, what are you doing about your company's network storage situation? At the very least, you're probably hoping or actively looking for a storage solution that enables you to easily add the storage systems you need and manage the storage systems you already have.
NetWare 6 includes such a solution--Novell Cluster Services 1.6. This clustering software represents what is arguably the key to Novell's claim that NetWare 6 is the storage platform of choice. (For more information, see "Simplify SAN Management With a NetWare 6 Cluster." )
SERVER SIDE UP
As you may have guessed, Novell Cluster Services 1.6 for NetWare 6 is an enhanced version of Novell's clustering software for NetWare 5. (An updated version of the NetWare 5 clustering software, Novell Cluster Services 1.0.1, is scheduled to be available this summer. Check the Minimum Patch List on the Novell Support web site at http://support.novell.com/misc/patlst.htm.)
Both versions of Novell clustering software serve the same basic purpose: to ensure high availability of critical network resources, including connection licenses, data volumes, network services, and applications. (For more information, see "Uptime in Real Time With NetWare Cluster Services for NetWare 5," Novell Connection, Sept. 1999, pp. 6-18. You can test-drive Novell Cluster Services by visiting Novell's democity at http://democity.novell.com/.)
You create a cluster by first loading the clustering software on a group of NetWare servers. (Obviously, the version of the clustering software you load depends on which version of NetWare--NetWare 6 or 5--you are running.) This clustering software connects the servers, thereafter called nodes, which then function essentially like a single system--the cluster.
Using either version of Novell Cluster Services, you can create a cluster with as few as two or as many as 32 nodes. (NetWare 6 includes a two-node clustering license.) Typically, and as Novell recommends, you then connect the cluster to a shared storage system by way of a Storage Area Network (SAN).
FAIL-OVER EASY
Like Novell's clustering software for NetWare 5, Novell Cluster Services 1.6 ensures high availability of network resources through failovers. A failover occurs when one node in a cluster goes down and one or more surviving nodes take over and continue to provide the failed node's resources.
Failovers occur automatically when nodes unexpectedly fail. You can also manually invoke a failover when you want to load balance the cluster or down a node (perhaps for maintenance).
When you configure the cluster, you specify where resources should migrate if a server fails. (A resource is an application, file, or service that is located on one of the cluster nodes.) For example, in the event that Node A fails, you may specify that you want all of the resources on that node to migrate to Node B. Alternately, you may specify that you want only one or two of the resources on Node A to migrate to Node B. You may specify that the remaining resources migrate to Node C if Node A fails.
Regardless of how you configure the cluster to handle failovers, both versions of Novell's clustering software handle failovers so quickly that users regain access to a failed node's resources within seconds. In most cases, users regain access to those resources without having to log in to the system again.
Virtually everything you have read thus far is true of Novell's clustering software for both NetWare 6 and NetWare 5. After all, the products are understandably similar: Both ensure high availability and simplify storage management.
Nevertheless, the two products have differences, and these differences go beyond their obviously different platforms. Novell Cluster Services 1.6 is based on a revised architecture that enables a few notable features not available in the clustering software for NetWare 5. (For more information about the old and new architecture of Novell's clustering software, see "A Revised Architecture: Lose One Module, Gain a Few Others.")
In the broadest sense, the enhancements to Novell Cluster Services 1.6 make it an even easier tool for managing storage than its NetWare 5 counterpart. Most of these enhancements fall into one of three categories:
Improved support for Novell Storage Services (NSS). (NSS 3.0 is also included with NetWare 6.)
Improved tools for monitoring and managing the cluster.
Improved cluster resource policies.
CLUSTER SERVICES AND STORAGE SERVICES: TALK ABOUT SYMBIOSIS
In NetWare 6, Novell has improved its clustering software and NSS to better support each other and, as a result, to better serve the purpose of clustering. Specifically, Novell Cluster Services 1.6 and NSS 3.0 work together to protect shared storage devices from uncoordinated access.
Shared devices, as you undoubtedly know, are storage devices to which every SAN-attached server or, in this case, every cluster node has access. (In contrast, local storage devices are devices to which only a directly attached server has access.)
NSS 3.0 helps protect your shared storage devices using a flag that labels these devices as Sharable for Clustering. In the future, Novell plans to enable NSS to automatically detect and flag shared storage devices. For now, however, you can manually set the Sharable for Clustering flag.
To set this flag, you use ConsoleOne to open one of the NDS Server objects representing a cluster node that has access to the device you want to flag. (See Figure 1.) From the Properties screen for that node, you select the Devices option from the Media pull-down tab.
When you select the Devices option, you can view details about the storage devices to which this particular node has access. For example, you will find and can mark the Sharable for Clustering flag. (See Figure 1.)
Pool Protection
When NSS 3.0 detects a Sharable for Clustering flag, NSS 3.0 will not activate the storage pool (or pools) running on that device unless Novell Cluster Services 1.6 is also running. (By default, NSS 3.0 activates the pools on only local devices.)
As you may recall, storage pools are areas of storage space that you create using the free space available on one or more storage devices. Storage pools must be either purely shared or purely local: That is, the devices or portions of devices you use to create a storage pool must be either all shared devices or all local devices.
Storage pools are containers for logical volumes. Logical volumes are handy because they expand and shrink like balloons, using only as much space as the files and directories within them consume at any given moment. (For more information about storage pools and logical volumes, see "More To Store--NetWare 6 and NSS 3.0 Can Handle It," Novell Connection, Apr. 2001, pp. 6-16.)
Novell Cluster Services 1.6 provides protection for data in shared storage systems at the storage pool level. For example, when NSS 3.0 requests permission to activate a storage pool on a cluster node, Novell Cluster Services 1.6 grants or denies permission to do so. The rule on which Novell Cluster Services 1.6 bases this decision is simple: The cluster allows a shared storage pool to be active on only one cluster node at a time.
The reasons for this rule are self-evident and have to do with the potential for data corruption or data loss. For example, suppose (in a parallel universe where everything is upside down, backward, and just plain wrong) that NSS 3.0 enables Nodes A and B to activate the same shared pool. In fact, suppose both nodes mount one of this pool's volumes, which stores a file named CLUSTER.WPD.
As NetWare servers, Nodes A and B have in their local memory copies of this file's metadata, including end-of-file values. The nodes update their in-memory metadata from the metadata stored on the shared storage device whenever they activate a pool.
Now suppose that when Nodes A and B activate the shared pool, CLUSTER.WPD's end-of-file value is 2134. What happens when Node A updates CLUSTER.WPD's end-of-file value to 2345 and shortly thereafter, Node B writes to CLUSTER.WPD-- What happens is that Node B begins writing from the end-of-file value 2134 and, thus, overwrites data.
This relatively basic example is, in fact, a best-case scenario. If two nodes were allowed to activate a shared storage pool at the same time, the very structure of the file system could become corrupted.
Of course, in the context of a NetWare 6 cluster in a SAN configuration, such dire results are theoretical. Novell Cluster Services 1.6 and NSS 3.0 work together to guard against the type of uncoordinated disk access that could lead to such results.
Novell Cluster Services 1.6 further protects data by failing over pools. (In contrast, Novell Cluster Services for NetWare 5 fails over volumes.) For example, if Shared Storage Pool 1 (SHP1) is active on Node A when Node A fails, the cluster migrates SHP1 to another node (Node B). The clustering software then reactivates the pool and remounts the cluster-enabled logical volumes within that pool.
Cluster Enabling Volumes
Whether you fail over pools containing only one volume or pools containing hundreds of volumes, you will need to cluster enable the volumes the storage pools hold. Cluster enabling volumes ensures that users' access to the volumes is uninterrupted during a failover.
You cluster enable a volume in a NetWare 6 cluster in basically the same way you cluster enable volumes in a NetWare 5 cluster. (See Figure 2.) When you cluster enable a volume, the clustering software creates a virtual server on which to mount that volume. This virtual server ensures that the volume remains accessible to clients regardless of the physical cluster node on which the volume is mounted.
With Novell Cluster Services 1.6, you can customize the names of virtual servers. In contrast, Novell's clustering software for NetWare 5 assigns virtual server names that cannot be customized. These default virtual server names include an underscore character that some Domain Naming System (DNS) servers don't support and, therefore, are problematic in some cases. By enabling you to customize virtual server names, Novell Cluster Services 1.6 eliminates any such potential problems.
TRUSTMIG? Don't Need It
Best of all, with volume failovers in a NetWare 6 environment, the cluster does not have to migrate trustee IDs because none exist to migrate. Consequently, Novell Cluster Services 1.6 no longer includes the Trustee Migration (TRUSTMIG) module. (See Figure 3.)
As you may know, the traditional NetWare file system and versions of NSS prior to version 3.0 use 32-bit-long identification numbers called trustee IDs to identify User objects as trustees of the particular servers they use. User objects have trustee IDs for each server they use and different trustee IDs to indicate the files the User objects own on each server.
In other words, a User object's trustee IDs necessarily differ, depending on the server of which the user is a trustee. Consequently, when a NetWare 5 cluster fails over a data volume, the cluster must do two things: First, the cluster must migrate the trustee IDs on the failed node to the node that remounts the data volume; second, the cluster must translate the trustee IDs so they will be valid on this new node.
This process works relatively efficiently on most systems and, in fact, is unique to Novell's clustering software: Competing solutions don't even attempt to migrate trustee IDs. However, translating trustee IDs can take a little too long to be practical on some systems, according to Novell engineer Randy Stokes.
Furthermore, translating trustee IDs that indicate file ownership would require a system to scan all of the files being failed over. Novell concluded that this process would be very time-consuming. After all, "extensive research has shown that doing nothing is faster than scanning the entire file system," says Stokes, tongue in cheek.
Thus, not surprisingly, NetWare 5 clusters do not translate file-ownership IDs. Consequently, user space restrictions are not enforced on data volumes in NetWare 5 clusters.
With NetWare 6, these potential drawbacks don't exist because trustee IDs don't exist. Instead, User objects (and all other NDS objects) in a NetWare 6 environment have globally unique identifiers (GUIDs). A User object has only one GUID, and this single GUID remains the same across all servers on which the user is a trustee.
As a result, when a NetWare 6 cluster fails over NSS and traditional NetWare volumes, it doesn't need to translate User object's GUIDs. Regardless of the node mounting that volume, these GUIDs remain the same and are always intact and accessible in NDS.
This same GUID also associates User objects with the files they own. As a result, user space restrictions are enforced in NetWare 6 clusters.
More important, because Novell Cluster Services 1.6 does not have to translate trustee IDs, it can fail over data volumes faster than versions of Novell's clustering software for NetWare 5. How much faster? The answer, of course, depends on many variables, including how many trustees you have on a given cluster node.
For example, Novell has "customers with thousands of trustees on a single [node]," says Novell product manager Dan Lawyer. In a NetWare 5 cluster, failing over volumes on cluster nodes with trustee lists of this length can take "seven minutes or even longer to migrate," Lawyer says, basing his estimate on customer reports.
Of course, these situations are very rare. Nevertheless, in a NetWare 6 cluster, regardless of the length of the trustee list, "volumes migrate in a matter of seconds," Lawyer claims.
In addition to efficiently failing over volumes (and supporting user space restrictions), NetWare 6 clusters simplify backup and restore processes, which can be "kind of painful," Lawyer points out. When you back up a NetWare 5 cluster volume, Lawyer explains, you have to restore that volume to the same physical node from which you backed the volume up. If you don't, you corrupt the trustee ID list.
In contrast, when you back up a NetWare 6 cluster volume, you can restore that volume on any node. Whichever node you choose, the trustee ID list and user space restrictions will remain intact.
MANAGEMENT IS A BREEZE WITH A BROWSER
In addition to improved support for NSS 3.0 and faster volume failovers, Novell Cluster Services 1.6 includes several new features that make managing NetWare 6 clusters easier.
For example, Novell Cluster Services 1.6 includes NetWare Remote Manager, which allows you to manage NetWare 6 clusters from a Java-enabled web browser. Formerly known as NetWare Portal Management, NetWare Remote Manager provides a fully functional alternative to ConsoleOne for configuring and managing NetWare 6 clusters.
Novell made the cluster management interface in NetWare Remote Manager as similar to the ConsoleOne interface as possible. For example, the Cluster Status screen in NetWare Remote Manager looks similar to the Cluster View screen in ConsoleOne. (See Figure 4.) This screen also reveals the same details about the status of a cluster, including the following:
The number and names of cluster nodes
Which of the nodes is the master (indicated with a yellow dot)
The names and locations of cluster resources
The status of resources (for example, running or offline)
The Cluster Status screen in NetWare Remote Manager and the ConsoleOne Cluster View screen also displays an Up Since log. This log shows the start date and time of each resource's current life.
You can use NetWare Remote Manager to manage the cluster, regardless of which nodes are running because Novell Cluster Services 1.6 now has a special Cluster IP address. You create this Cluster IP address when you install the clustering software. You use either ConsoleOne or NetWare Remote Manager to edit this address later. When you enter the Cluster IP address from your browser, you can configure and manage any node in your cluster.
During installation, Novell Cluster Services 1.6 also automatically generates a special cluster resource called the Master IP Address. The Master IP Address binds the Cluster IP address and also binds this address to NetWare Remote Manager. After Novell Cluster Services 1.6 generates the Master IP Address, it runs on the master node and can't be controlled or edited.
E-MAIL ME!
Novell Cluster Services 1.6 supports Simple Network Management Protocol (SNMP) through management information base (MIB) extensions developed by Compaq. As with any MIB extension, Compaq's clustering MIB defines the entities, in this case cluster entities, you can monitor using SNMP.
For example, the MIB enables you to use SNMP for cluster discovery (to detect the cluster's name as well as node names and IP addresses). In addition, the MIB enables you to monitor node traps (such as when nodes join, leave, or fail). Because the cluster supports this MIB, you can use SNMP-compliant cluster management software. For example, you can use Compaq Insight Manager (CIM).
Unlike other versions of Novell's cluster software, Novell Cluster Services 1.6 uses Simple Mail Transfer Protocol (SMTP). Consequently, you can now configure the cluster to send messages to up to eight e-mail addresses when various cluster events occur. For example, Novell Cluster Services 1.6 can notify you by e-mail when a node joins, leaves, or fails. In fact, Novell Cluster Services 1.6 can notify you any time the status of a cluster resource changes. (For example, a cluster resource's status may change from loading to running.)
Novell Cluster Services 1.6 sends either plain-text or XML-formatted messages, depending on which format you select. The XML format is a forward-looking option. In the future, Novell plans to create intelligent software designed to take advantage of the XML management interface that NSS provides. Such software could receive XML-formatted e-mail messages from the clustering software and act on those messages by automatically making any necessary changes to the file system.
KEEP A FINGER ON THE CLUSTER'S PULSE
Novell Cluster Services 1.6 also includes new diagnostic tools, including a persistent cluster event log of significant cluster events such as a cluster resource status changing from running to "comatose." You can view this log from NetWare Remote Manager or from ConsoleOne.
Novell Cluster Services 1.6 also includes a new heartbeat statistics tool. (See Figure 5.) The cluster's "heartbeat" refers to a group protocol that cluster nodes use to transmit heartbeat packets at regular intervals over the Ethernet LAN that connects the nodes. (The default setting is once every second.) These heartbeat transmissions enable nodes to keep track of one another and to detect potential node failures.
Cluster nodes also use the heartbeat protocol to write to a special partition on the SAN. This partition, or rather the data the nodes post to this partition, play a role in avoiding what is called a split brain. (For more information, see the explanation of the SBD module in "A Revised Architecture: Lose One Module, Gain a Few Others.")
The heartbeat statistics tool enables you to view and tune heartbeat settings on both the LAN and SAN. For example, using the heartbeat statistics tool, you can change the 8-second heartbeat threshold on the LAN. Eight seconds marks the default period of time a node can go without transmitting heartbeat packets over the LAN before the other nodes detect and take action based on the node's silence. Depending on your LAN situation, you may need to change this setting.
TEMPLATES, PRIORITIZATION, AND ONE-CLICK ONLINE
In addition to improved support for NSS and improved management tools and policies, Novell Cluster Services 1.6 includes a few enhancements that simplify creating and managing resources. Specifically, Novell Cluster Services 1.6 includes new resource templates for the following:
File Transfer Protocol (FTP)
Novell Internet Messaging System (NIMS)
Network File System (NFS)
ZENworks �
As you probably know, resource templates simplify the process of creating resource objects. These templates contain much of the information you would otherwise need to complete yourself.
After you have created resources, Novell Cluster Services 1.6 gives you the option of allotting a priority value to each resource. The cluster then loads resources based on their priority so these resources always load in the appropriate order.
For example, suppose you are running Dynamic Host Configuration Protocol (DHCP) and GroupWise in a cluster. Using this resource prioritization feature, you can ensure that DHCP, which is smaller and loads more quickly than GroupWise, always loads first.
Novell has also simplified the process of creating cluster resources. Using Novell Cluster Services for NetWare 5, you create a resource and then return to the Cluster State View to select the resource and bring it online. With Novell Cluster Services 1.6, you simply check the Online Resource After Create option when you are creating a new resource. The cluster automatically brings online the new resource when it creates that resource.
Granted, this enhancement saves only a few mouse clicks. Nevertheless, based on BrainShare 2001 attendees' response to the news, eliminating a few mouse clicks is good news. Novell high-availability architect Robert Wipfel "got great applause," Lawyer says, when he announced this seemingly minor enhancement.
SIMPLER SAN MANAGEMENT
By providing improved support for NSS, Novell Cluster Services 1.6 ensures that the data in the shared storage pools you create remains intact and always available. Furthermore, because trustee IDs have been replaced by GUIDs in NetWare 6 environments, Novell Cluster Services 1.6 fails over data volumes faster than previous versions of Novell's clustering software and simplifies backup procedures.
In addition, you don't have to be at work to manage a NetWare 6 cluster. You can manage a cluster from anywhere you have access to a browser and an Internet connection.
Furthermore, you don't have to launch either ConsoleOne or NetWare Remote Manager to learn about significant cluster events: You can configure the software to notify you of cluster events via e-mail.
Finally, with Novell Cluster Services 1.6, creating cluster resources is a little easier. The new templates are easier to use, and you can bring new resources online with a single click of the mouse.
Wipfel says that many customers install Novell Cluster Services (either for NetWare 6 or NetWare 5) less for the product's promise of high availability and more for its ability to simplify SAN management--and no wonder. After all, as Wipfel points out, Novell Cluster Services 1.6 is "the killer SAN application."
Linda Kennard works for Niche Associates, which is located in Sandy, Utah.
A Revised Architecture: Lose One Module, Gain a Few Others
The revised architecture underlying Novell's clustering software is reflected by the new enhancements in Novell Cluster Services 1.6. Although the essential architecture remains the same, Novell's latest version of its clustering software has lost one module--TRUSTMIG--and gained a few others. (See Figure 3. For an explanation of why Novell Cluster Services 1.6 was able to ditch TRUSTMIG, see the "TRUSTMIG? Don't Need It" section of the main article.)
A brief description of the purpose of each module--new and old alike--follows.
CLUSTER CONFIGURATION LIBRARY (CLSTRLIB)
The CLSTRLIB module stores NDS cluster data. The CLSTRLIB module located on the first node in the cluster accesses NDS eDirectory to locate cluster objects and to store them in its own memory. This first node then becomes the master node, and its CLSTRLIB module sends the NDS cluster data to all other cluster nodes.
GROUP INTERPROCESS COMMUNICATION (GIPC)
The GIPC module runs the cluster group membership protocols, including the heartbeat protocol. At regular intervals, the cluster nodes transmit and listen for heartbeat packets on the LAN. By doing so, nodes can detect potential failures when one or more nodes fails to transmit its regular heartbeat packets.
The nodes also use the heartbeat protocol to write periodically to a special partition on the SAN. (For more information, see the description of the SBD module below.)
SPLIT BRAIN DETECTOR (SBD)
The SBD module detects and protects against split brains, which can occur when a node loses its Ethernet connection. This node is then unable to transmit or listen for heartbeat packets over the LAN. In such a case, the other cluster nodes assume that the silent node is dead and, therefore, attempt to take over the presumably dead node's resources. However, because the node is not actually dead (but rather has only lost its Ethernet connection), this node thinks it is the only node alive and thus attempts to restart the cluster's resources single-handedly.
The SBD module detects such situations and notifies the cluster, which acts immediately to kill off one side of this split brain. The cluster kills off either the smaller half of the split brain or the half that is not running the master node.
In two-node scenarios, however, neither half is smaller, and each node thinks it is the master node. To address this potential problem, Novell Cluster Services 1.6 (and Novell Cluster Services 1.0.2, an enhanced version of clustering software for NetWare 5) now has the ability to detect LAN failure. This ability enables the cluster to protect against split brains in two-node clusters by killing off the node that lost its Ethernet connection.
VIRTUAL INTERFACE ARCHITECTURE LINK LAYER (VLL)
The VLL module provides an interface for the GIPC, SBD, and CRM modules. If the GIPC module detects silence from one of the nodes, the GIPC module contacts the VLL module. The VLL module, in turn, shares this information with the SBD module. The SBD module then determines whether a presumably dead node is alive or dead and informs the VLL module of its decision. The VLL module shares this decision with the CRM module.
VIRTUAL INTERFACE PROVIDER LIBRARY EXTENSIONS (VIPX)
The VIPX module is a Novell extension of the provider library for the Virtual Interface (VI) Architecture specification. The VI Architecture specification defines an industry-standard architecture for communication within clusters of servers and workstations. (For more information about the VI Architecture specification, visit http://www.viarch.org/.) Novell's VIPX makes it easier to use the standard VI Provider Library to write programs for Novell Cluster Services 1.6.
CLUSTER SYSTEM SERVICES (CSS)
The CSS module provides a generic application program interface (API) that any distributed, cluster-aware application can use to enable distributed-shared memory and distributed locking. Distributed-shared memory allows cluster-aware applications running across multiple servers to share access to the same data as though the data were on the same physically shared RAM chips.
Distributed locking protects cluster resources by ensuring that if one thread on one node gets a lock then another thread on another node cannot get the same lock. For example, distributed locks could be used to ensure that pools are active on only one server at a time. When one node activates a shared pool, the pool releases its lock to that node. When another node attempts to activate the same pool, that node finds that it cannot do so because the pool has already released its lock.
CLUSTER RESOURCE MANAGER (CRM)
The CRM module is responsible for keeping track of where the cluster resources are actually running and for restarting resources in the event of a failure. The CRM executes the failover policies specified in the NDS configuration data (that the CLSTRLIB module reads into local memory when you install the cluster).
CLUSTER VOLUME BROKER (CVB)
The CVB module is a cluster-aware application that enables you to make a change to an NSS volume on one node only, after which CVB distributes that change across all nodes. In other words, CVB ensures that each node in the cluster has the same image of the storage situation at all times.
CLUSTER MANAGEMENT AGENT (CMA)
The CMA module interfaces with ConsoleOne, enabling you to manage a cluster from any workstation running the Novell Cluster Services snap-in modules for ConsoleOne. (For more information about managing cluster services with ConsoleOne, see the sidebar titled "Cluster Control With ConsoleOne," from the article "Uptime in Real Time with NetWare Cluster Services," Novell Connection, Sept. 1999, p. 16.)
PORTAL CLUSTER AGENT (PCLUSTER)
The PCLUSTER module interfaces with NetWare Remote Manager, enabling you to manage a cluster from any computer with a browser and Internet access. Anything you can do in ConsoleOne, you can do using NetWare Remote Manager.
Simplify SAN Management With a NetWare 6 Cluster
Novell Cluster Services 1.6 plays a key role in realizing Novell's claim that NetWare 6 is the storage platform of choice--but Novell Cluster Services 1.6 doesn't act alone. The NetWare 6 Native File Access components, Novell Storage Services (NSS), and, of course, NDS eDirectory also help actualize this claim.
With Novell Native File Access components running on a NetWare 6 server, Windows, Macintosh, and UNIX workstations--and application servers--can access files in NSS 3.0 using their native file-access protocols: Common Internet File System (CIFS), AppleTalk, and Network File System (NFS), respectively. (See Figure 6.)
This capability implies several things: For one thing, you don't have to install NetWare client software on these workstations. Users at Windows, Macintosh, and UNIX workstations and application servers access NSS 3.0 using the networking software to which they are accustomed. For example, Windows users can use Windows Explorer to attach to a NetWare 6 server over TCP/IP.
For another thing, the users at these workstations are represented in NDS as objects. Consequently, you can manage these User objects and assign them trustee rights and access controls in the same way you manage the User objects representing users at NetWare clients.
More important (in the context of this article, at least), the Novell Native File Access components also potentially enable a simpler approach to storage management. For example, you can set up a NetWare 6 cluster on which you can run (among other things) the Novell Native File Access components for each of the workstation and application server operating systems on your company's network. Then you can place this cluster in front of a Storage Area Network (SAN) that you can dedicate to NetWare.
By doing so, you not only spare yourself the time and hassle of installing NetWare client software on each workstation and application server, but you also make managing the network simpler. With this type of network arrangement, you can use NDS eDirectory to centrally manage the SAN, application servers, and users' workstations.
In addition, because your SAN is dedicated to a single operating system, managing that SAN is a bit easier. When you set up the SAN, you don't have to guess how much storage to allot to each operating system because all of it is dedicated to NetWare. When you have to add storage, you simply add storage--without the hassle of reconfiguring the SAN and divvying up the added storage space among the operating systems.
That level of simplicity is "the big story," says Novell product manager Dan Lawyer in summary. And that simplicity is "what makes NetWare 6 the storage platform of choice."
* 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.