Nakoma - The Future Looks Bright for Storage Management
Articles and Tips: article
01 Oct 2002
Does your company feel that its information is valuable? According to a recent poll conducted by CIO Magazine, most companies do. Of the more than 100 Chief Information Officers (CIOs) who responded to this poll, all agreed with the following statement: "Data is a valuable corporate asset and should be managed as such." (For more information about this poll, see "The Six Commandments of Ethical Data Management," CIO Magazine, July 1, 2002.)
Your company is also managing and storing more of this valuable information. In fact, according to industry analysts such as Arun Taneja, the amount of information the average company manages and stores doubles every year. (Taneja is a senior analyst for Enterprise Storage Group, an independent storage analyst firm. For more information about Enterprise Storage Group, visit http://www.enterprisestoragegroup.com/.)
Naturally, the cost of managing and storing information increases in proportion to the amount of information. Teneja estimates that most companies spend in the neighborhood of 70 percent of their IT budget on data management and storage--a figure that is up from approximately 30 percent in the early 1990s.
In better economic times, the cost of managing and storing increasing amounts of information wasn't particularly troubling. Companies simply added storage devices--such as Network Attached Storage (NAS) devices and Storage Area Networks (SANs)--as needed to accommodate the growing amounts of information.
However, current economic conditions give rise to a significant problem: The amount of money companies can spend to manage and store this information is shrinking.
Rather than purchasing new resources, more and more companies are looking at ways to better use the data-related resources they already have. As Taneja explains, these companies have little choice: With shrinking IT budgets, companies must either "let their incoming data figuratively drop on the floor" or use the resources they already have more efficiently.
If your company is using NetWare 6, you already have several tools to help your company store and manage its data more efficiently. For example, the Novell Storage Services (NSS) file system included in NetWare 6 enables you to create storage pools, which are collections of free storage space that can reside on one or more storage media, including SANs. This feature can help you make the most of the free storage space that your company already has. (For more information about storage features in NetWare 6, see "More to Store? NetWare 6 and NSS 3.0 Can Handle It," Novell Connection, Apr. 2001, pp. 6-16.)
NetWare 6 also includes products--such as Novell iFolder and Novell Native File Access--that expand the number of options users have for accessing your company's data. Novell iFolder is a web-based application that synchronizes users' data between one or more computers that are running Novell iFolder client software and a server that is running Novell iFolder server software. Novell iFolder also enables users to access data on a Novell iFolder server from a standard web browser.
Novell Native File Access enables Macintosh-, Windows-, and UNIX-based client computers to access files on NetWare without using Novell client software. (For more information about the latest version of Novell iFolder, see "Tip The Scales With Novell iFolder Professional Edition 2.0," Novell Connection, May 2002, pp. 20-30. For more information about Novell Native File Access, see "Native File Access Wanted: Client Software Need Not Apply," Novell Connection, Nov. 2001, pp. 6-26.)
INTRODUCING NAKOMA
Nakoma, which is Novell's code name for the next release of the NetWare operating system, will include several enhancements to the data management and storage features that are included in NetWare 6. Nakoma will also include new features that further help you make the most of your company's data management and storage resources. (Incidentally, Novell plans to release Nakoma next year.)
This article takes a sneak peek at the following data storage and management features that will be available in Nakoma:
Internet Small Computer System Interface (iSCSI) support
Software support for Redundant Array of Independent Disks (RAID) 5 and RAID 1 support
New storage resource management tools in Novell Remote Manager
Pool-level snapshots
Volume split/volume move
Read-only volumes for Novell Cluster Services
ISCSI SUPPORT
To help you take advantage of your existing network infrastructure when adding a SAN or other storage device (such as a NAS device), Nakoma will support iSCSI. An Internet Draft of the Internet Engineering Task Force (IETF), iSCSI specifies a protocol for carrying SCSI commands and data transfers over TCP/IP networks.
The SCSI protocol is the group of interfaces that most companies use to attach I/O devices (such as storage, CD ROM, and DVD devices) to workstations and PC-based servers. iSCSI maps SCSI commands and data transfers to TCP, which enables you to use your company's existing IP network to connect iSCSI devices.
Like the SCSI protocol, the iSCSI protocol defines the interaction between two devices--an initiating device, which sends requests to I/O devices, and a target device, which is the I/O device that responds to these requests. However, unlike traditional SCSI commands, which require specialized cable for data transmission over distances up to only 24 meters, iSCSI commands can travel over your company's existing IP-based network and over the Internet. Therefore, iSCSI enables you to connect an initiating iSCSI device to a remote iSCSI target device.
Nakoma will include software that can map SCSI commands to iSCSI, enabling Nakoma servers to function as iSCSI initiating devices. In addition to this software-based iSCSI support, Nakoma supports hardware devices, such as iSCSI host bus adapters. These devices offload the task of mapping SCSI commands to iSCSI, thereby freeing Nakoma's processors to perform other tasks. Of course, Nakoma also supports iSCSI target devices.
Novell plans to test Nakoma with the Adaptec ASA-7211 iSCSI Adapter, which fully offloads iSCSI protocol processing from a host server's CPUs. (For more information about the ASA-7211 iSCSI Adapter, visit http://www.adaptec.com/worldwide/product/markeditorial.html?sess=no&prodkey= ipstorage_asa7211&type=Common&cat=/Common/IP+Storage.)
Novell is also testing Nakoma with the CISCO SN 5420 Router, which is an iSCSI target device. (For more information about the SN 5420 Router, visit www.ciscosystems.com/warp/public/cc/pd/rt/5420.)
At the time this article went to press, the iSCSI protocol had not been ratified. (iSCSI was then in its 17th draft. You can download this Internet Draft from www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-17.txt.) The IETF is expected to ratify the iSCSI protocol before the end of this year. When this standard is ratified, Novell will update Nakoma hardware and software support for iSCSI to comply with the ratified standard. Likewise, CISCO and Adaptec plan to fully support the ratified iSCSI standard in the next release of their iSCSI products.
IT'S A RRRRRAID!
Nakoma also includes software RAID controllers to help you increase the availability and fault tolerance of your company's data without having to purchase expensive server hardware. (Servers that include hardware RAID controllers can cost as much as ten times more than servers that don't.) Specifically, Nakoma includes software RAID 5 and RAID 1 controllers.
Of course, if your company is already running NetWare on servers that include hardware RAID 5 and RAID 1 controllers or if your company has already attached a Fibre Channel or SCSI-based SAN to a NetWare server, Nakoma will support these devices. For example, Nakoma will support Compaq ProLiant servers that include hardware RAID controllers, just as NetWare 6 does.
Like NetWare 6, Nakoma will also support popular SAN devices--such as the MAGNITUDE SAN from XIOtech (http://www.xiotech.com/), the Storage Works SAN from Compaq (http://www.compaq.com/), and the Symmetrix SAN from EMC (http://www.emc.com//). Some of the drivers that enable these hardware devices to communicate with Nakoma's I/O resources will use NetWare Peripheral Architecture (NWPA) or Open Data-Link Interface (ODI), just as these devices do on NetWare 6. (NWPA is the I/O system that peripheral devices, such as storage devices, use to access I/O resources on NetWare. ODI is the I/O system that LAN devices, such as network interface cards, use.)
However, hardware devices don't necessarily have to use NWPA or ODI. Instead, these devices can use Novell Consolidated I/O System (CIOS), which is a new object-oriented I/O system that makes it simpler for hardware vendors to write drivers for Novell servers. (See Figure 1. For more information about CIOS, see "CIOS: A Gift to Novell's OEM Friends.")
Figure 1
CIOS also makes it easier for you to manage these drivers. Unlike NWPA and ODI, which do not use the NetWare registry, CIOS uses the NetWare registry. As a result, you can use Novell Remote Manager to manage these drivers through the NetWare registry. (Novell Remote Manager is Novell's web-based management utility for NetWare servers.) To manage NWPA and ODI drivers, in contrast, you must access these drivers' individual configuration files from the server console.
NEW TOOLS IN NOVELL REMOTE MANAGER
In addition to helping you manage devices that are attached to NetWare servers, Novell Remote Manager can help you manage your company's data. In NetWare 6 Support Pack 2, Novell Remote Manager includes a storage resource management tool that can help you manage the data residing on NetWare servers. (You can download support packs from http://support.novell.com/.)
This tool inventories the contents of volumes and subdirectories and then generates reports based on the results of these inventories. You can access this tool in one of the following two ways:
You can access this tool from the Volume Management page, which Novell Remote Manager displays after you authenticate. (For information about accessing and authenticating to Novell Remote Manager, see "Novell Remote Manager: Remote Control for NetWare Servers," Novell Connection, Sept. 2001, pp. 14-29.) To access this tool, you select the information icon next to the volume you want to inventory. Novell Remote Manager then displays a page containing information about this volume and several links. You select the Volume Inventory Report link on this page to inventory this volume.
You can select a particular volume from the Volume Management page. Novell Remote Manager then displays a page that contains a list of the subdirectories contained in this volume. You can select the Inventory icon located at the top of this page to inventory this volume. (See Figure 2.) If you want to inventory a particular subdirectory in this volume rather than the entire volume, select the subdirectory from this page. Novell Remote Manager then displays a page containing the contents of this subdirectory. Select the Inventory link located at the top of this page to inventory the contents of this subdirectory.
Figure 2
Location, Location, Location
As you may have gathered, the location from which you access the storage resource management tool determines the scope of this tool's inventory function. That is, when you access the storage resource management tool from a page containing information about a volume, this tool inventories the volume. When you access this tool from a page that contains information about a particular subdirectory, this tool inventories the subdirectory (including subdirectories within this subdirectory).
Novell distinguished engineer Dana Henriksen is currently in the process of adding another way to access the storage resource management tool. In the version of Novell Remote Manager that releases with Nakoma, Henriksen will include a way to access the storage resource management tool from the Reports/Log Files page, which enables you to view server-wide information. When you access the storage resource management tool from this page, it will inventory all of the volumes running on this server.
What this added option will enable the resource management tool to do then, explains Henriksen, is "generate reports that consolidate the volume information for all of the volumes on a server." This option, Henriksen adds, will be especially useful if you've got a server with a lot of volumes. If you have such a server, you probably don't want to access and then compile information from all of these individual volumes to get a server-wide view of your company's data.
When the storage resource management tool performs an inventory, this tool accesses each file in the volume (or subdirectory or, using the version of this tool that ships with Nakoma, server) that you select. As it does so, this tool creates an eXtensible Markup Language (XML) file that contains the inventory report. You can then refer to this file again and again to view this inventory report without first using the storage resource management tool to rescan these files. (To find out how much time the storage resource management tool takes to perform these tasks, see "About Time.")
These inventory reports contain information about the size and types of files, when the files were created, and when they were last accessed and modified. When the storage resource management tool has finished creating these reports, it stores the data in XML format at the root of the volume.
Note. The XML tags contained within these reports are then available to any application that knows what to do with them, including third-party storage resource management applications. Application developers can therefore create applications that can consume the data contained in these reports.
Have It Your Way
As Richard Jones, a Novell manager for storage projects, explains, the storage resource management tool then uses these XML tags to create a series of reports that collectively provide "a gazillion-and-one different views" of the data stored on the inventoried volume. This figure is, of course, a deliberate exaggeration.
The storage resource management tool actually provides 15 reports, 10 of which are displayed graphically. For example, one report is a graph that displays file types on one axis and the amount of space consumed by each type of file on the other axis. (See Figure 3.)
Figure 3_1
Figure 3_2
This graph can help you see at a glance the types of files, such as MP3 or MPEG files, that users are storing on this volume and how much space these files are consuming. Based on this information, your company can then implement data storage policies, such as policies that prohibit storing MP3 files on the network.
The remaining five reports are tables, each of which contains links to deeper levels of information. For example, in a table that lists the types of files stored on a particular volume, the names of these file types are actually links. (See Figure 3.) When you select a particular type of file, a link takes you to a page that displays detailed information about all files of this type. This information includes the name, location, owner, size, creation date, last-modified date, and last-accessed date of each of these files.
On this page, the names of individual files are links that take you to a page that displays even more detailed information about these files, such as the rights associated with these files. From this page, you can delete files, modify file rights, or add or remove file trustees.
Using previous versions of Novell Remote Manager, you can only view these rights. To add trustees or modify rights assignments, you have to use ConsoleOne.
The ability to add trustees and modify file rights within Novell Remote Manager, Henriksen says, "is nice if you are managing a file system" because you don't have to take time to run a separate utility. Being able to use Novell Remote Manager to set space restrictions on volumes is also nice--a feature that was also added to the NetWare 6 Support Pack 2 version of this utility. Using earlier versions of Novell Remote Manager, you can view volume quotas, but you must use ConsoleOne to change these quotas.
Incidentally, you don't need to be a network administrator with full administrative rights to use the storage resource management tool in Novell Remote Manager. Users can also use this tool to inventory files and create reports.
By selecting the Volume option under the Novell Remote Manager Manage Server menu, users can navigate to subdirectories in the NetWare file system. These users can then generate inventory reports for these subdirectories and the subdirectories within these subdirectories.
To safeguard information stored on your company's network, the storage resource management tool uses the identity of the users who are accessing this tool to scan files. This tool can therefore access only areas of the file system to which these users have rights.
How to Pick Up on a Trend
When you use the storage resource management tool to provide information about a volume, this tool also accesses Novell Remote Manager's trend graph feature. (The trend graph feature is available in the version of Novell Remote Manager included in NetWare 6 Support Pack 1. For more information about this feature, see "Beyond the Basics: New Features in the NetWare Remote Manager Utility as Found in NetWare 6 Support Pack 1," Novell AppNotes, June 2002.)
Every hour, the trend graph feature collects information about the size of NetWare volumes and stores this information in data files that are located on the particular volumes to which this information refers. (Lest you be concerned about the size of these files, you should know that these files consume only eight bytes per hour, or approximately 70 KB a year.)
At the storage resource management tool's behest, the trend graph feature retrieves the information stored in a particular volume's data file and displays this information as a graph, which is called the Available Space Trend graph. This graph illustrates the volume's size over time. Among other things, this graph can help you estimate the rate at which a volume is running out of space. (See Figure 4.)
Figure 4
Is Your Company's Data Secure?
An important part of managing data is keeping data secure. The version of Novell Remote Manager included with NetWare 6 Support Pack 1 includes a new security tool that can help you assess the security of your company's valuable data.
Like the storage resource management tool, this security tool accesses information from volumes running on NetWare servers. This tool also accesses information from Novell eDirectory, such as information about user passwords. In addition, this tool accesses information about server usage, such as information about IP and IPX ports that are open on this server.
The security tool then displays the result of this information-gathering process in a security report. As Henriksen explains, because all of this security-related information is consolidated in one report, "a quick look can tell you whether or not good security restrictions are in place." For example, you can see whether or not users are complying with password-security policies. You can also see at a glance the names of users who have admin-equivalent privileges and the names of users who are currently logged in to this server. (See Figure 5.)
Figure 5
To access the security tool, you select the Reports/Log Files icon on the Novell Remote Manager header. You then select View Security Report.
POOL-LEVEL SNAPSHOTS
As companies' storage needs have grown, the IT industry has responded to these needs by enabling companies to store greater amounts of data in less physical space. For example, you can now store a terabyte of data in a space that is only 4 Rack Units high (approximately seven inches).
In contrast, as little as two years ago, a terabyte of storage required 48 times this much space. "Two years ago, a terabyte of data took up a space fully seven feet high and 19 inches wide," Jones explains.
Because the demand for increased storage capacity also exists at the file level, file sizes have also increased over the years. To meet the demand for bigger file sizes, filing protocols in Nakoma will support files of more than 4 GB--in some cases up to 8 TB. Incidentally, Nakoma supports the following filing protocols: NetWare Core Protocol (NCP), Network File System (NFS), Apple File Protocol (AFP), and Common Internet File System (CIFS).
Note. The NSS file system has supported files and volumes of up to 8 TB since it was introduced in NetWare 5. However, filing protocols were then and are today only able to create and access files of less than 4 GB. There is one exception: NFS on NetWare 6 NSS volumes can create and access files of more than 4 GB.
Of course, as the size of files and volumes increase, so does the amount of time it takes to back up those files and volumes. This can present problems for companies that have large amounts of data on volumes that they must regularly back up.
Because backing up data while files are open can result in backing up data that is in the process of changing (which means this backed-up data could be bad data), companies must schedule time for backups when files aren't open. As a result, many companies have a limited window of opportunity for backing up data. The problem is, Jones explains, these companies sometimes have more data than the fastest backup technologies can back up within this window of opportunity.
For example, suppose a company's window of opportunity for performing backups is between 12 a.m. and 6 a.m. At all other times, users must have access to this company's data. Further suppose this company has more data than its state-of-the-art tape backup system can back up within this window.
One option for such a company is to rotate the volumes it backs up nightly. Another option is to take a snapshot of this data and then back up this data from that snapshot. Because users aren't accessing the data in a snapshot, companies can back up data from a snapshot at any time of the day or night.
However, as Rob Seely, a product manager for Novell, explains, some snapshot technologies are better than others. "Some snapshot technologies don't know if data is in a consistent state [not in the process of changing]," Seely says. Therefore companies that use these technologies must "assume that 80 percent of the time, snapshot data is in a consistent state and the other 20 percent of the time, the data is bad." Obviously, this 20 percent of bad data undermines companies' confidence when it comes to backing up data from these snapshots.
Fortunately, the NSS file system in Nakoma includes a technology--which Novell engineers have aptly named freeze-thaw--that snapshot engines can use to communicate with server-based applications, such as Novell GroupWise. Using this technology, the snapshot engine included with the NSS file system in Nakoma can request that these applications get their data into a consistent state. (Novell's freeze-thaw technology was developed for the NSS snapshot engine. However, this technology is also available for third-party software developers to use.)
After these applications put their data in a consistent state, the freeze-thaw technology stops all I/O operations, thereby freezing data in this consistent state so that the NSS snapshot engine can take a snapshot of the data. These snapshots, which are called pool-level snapshots, are virtual images of the data in an NSS storage pool as the data existed at a specific moment in time.
After the NSS snapshot engine takes its snapshot, the freeze-thaw technology resumes I/O operations, thereby thawing this data.
Novell's freeze-thaw technology helps ensure that data from server-based applications is good data--that is, data that isn't captured while it is in the process of changing. However, the freeze-thaw technology cannot communicate with applications running on users' workstations.
To ensure that data from these applications is in a consistent state before you take an NSS pool-level snapshot, you should therefore dismount the volumes that these applications use. By taking this precaution before you take a snapshot of the data in an NSS storage pool, your company can back up its data from this NSS pool-level snapshot with confidence.
VOLUME SPLIT/VOLUME MOVE
Suppose you are using the Available Space Trend graph in Novell Remote Manager to track available disk space on your company's servers and you discover, to your dismay, that one of these servers is nearly out of available space. A volume on this server has grown dramatically since you last checked.
You also discover that the volumes on another server are not growing at all. After two years, this second server still has more than 100 GB of available disk space. Because your company's IT budget is shrinking, you would obviously like to use this 100 GB of free space rather than purchasing new hardware for the rapidly growing volume that resides on the space-challenged first server.
However, reallocating your disk space poses a few problems. For one thing, you must copy files manually from the volume on the first server to a volume on the second server. This process could be rather time-consuming and, therefore, expensive.
For another thing, you must create new drive mappings for the users who need to access the files that you move. To complicate matters further, your company is quickly running out of available drive letters.
In Nakoma, Novell's Distributed File Services (DFS) includes a feature that can help you overcome these problems. The volume split/volume move feature enables you to split off a portion of an NSS volume and then move this split-off portion to another server, while still maintaining the file structure and drive mappings to which users are accustomed. You can also use this feature to move an entire volume from one server to another. (DFS is a feature set of the NSS file system. For more information, see the "Packed With the Power of NDS" section in "NetWare 6 Scales New Heights," Novell Connection, Oct. 2000, pp. 14-16.)
Note: If you don't like the structure of your company's current file system or if you want to transfer data from a NetWare 5 or 4 server to a NetWare 6 server, you can use the Novell NetWare Server Consolidation utility (www.novell.com/products/netware/server_consolidation). This utility, which is currently available as a free download (http://download.novell.com) will include new features for the Nakoma release. (For more information about new features that will be available with the Nakoma release of this utility, see "By Request: More Power to Change" on p. 19. For more information about the NetWare Server Consolidation utility, see "Novell NetWare Server Consolidation Utility: Moving Data the Easy Way, August 2002" Novell Connection, Aug. 2002, pp. 21-22.)
The volume split/volume feature supports NetWare 6 and above. When you transfer data from one Nakoma server to another Nakoma server, however, the volume split/volume move feature includes a crash recovery feature that enables you to recover from system crashes.
The crash recovery feature uses inter-server communications to checkpoint the progress of data transfers every two minutes. In the event of a system crash, this feature resumes data transfers at the last checkpoint. Because NetWare 6 does not include the volume split/volume move feature, the crash recovery feature cannot ensure full crash recovery capabilities for data transfers to NetWare 6.
Easy Access
You access the volume split/volume move feature from Novell iManager. (Novell iManager is Novell's web-based management utility. For more information, see "Novell iManager: Keeping eDirectory Management Simple," Novell Connection, July 2002, pp. 6-16. You can download this article from www.ncmag.com/past.)
To use the volume split capability, you first select the subdirectory at which you want to split this volume. (The volume split/volume move feature enables you to split volumes only at the subdirectory level.) This subdirectory is called the source directory.
You then select the location, which is called the target, to which you want to move the contents of the source directory. Finally, you use one or both of the following options to specify the time at which you want the volume split/volume move feature to begin the task of copying data from the source directory to the target server:
The Scheduling Feature. The scheduling feature is a global feature. The time period you specify using this feature applies to all volume split/volume move requests. For example, suppose that to save your company's workday bandwidth, you want data transfers to occur only between the hours of 12 a.m. and 6 a.m. If you use the scheduling feature to specify these hours, the volume split/volume move feature can perform the task of transferring data from one server to another only during these hours. Now suppose you use the scheduling feature to specify this 12 a.m. to 6 a.m. time period and the volume split/volume move feature cannot complete its tasks during this time. In this event, the scheduling feature pauses volume split/volume move operations when the specified time period is up. The scheduling feature then resumes volume split/volume move operations when this time period occurs again--at 12 a.m. the following morning.
Start Time. You can also select a time at which you want the volume split/volume move feature to begin a particular task. For example, if you want this feature to begin the task of moving a certain volume on Saturday evening, you can specify a Start Time of 7 p.m. on Saturday. Of course, if you've used the scheduling feature to allow data transfers only between the hours of 12 a.m. and 6 a.m., the volume split/volume move feature won't actually begin this task until 12 a.m. the following Sunday morning. The time you specify using the scheduling feature overrides the time you specify using the Start Time feature.
Finis!
When the task of copying data is complete, the volume split/volume move feature renames the source directory. This feature then creates an NSS Junction object to replace the source directory. A Junction object is an alias for a volume--in this case, for the target volume, which is the portion of the original volume that now resides on the target server. This Junction object links the original volume with the target volume. (For more information about NSS Junction objects, see the "One for All and All in One" section in "NetWare 6 Scales New Heights," pp. 16-18.)
By creating a Junction object in this subdirectory, the volume split/volume move feature enables users to continue using existing drive mappings to this data. That is, you don't need to create new drive mappings for users who need to access data that now resides on the target volume.
Finally, the volume split/volume move feature deletes the original (renamed) directory and all of its contents.
READ-ONLY VOLUMES FOR NOVELL CLUSTER SERVICES
Using Nakoma, you can create a read-only version of a read-write or master volume. Multiple servers can then simultaneously mount this read-only volume. This feature, which is initially available only for use with Novell Cluster Services, can simplify the task of managing data that is common to several servers.
For example, suppose that your company's web site is distributed across several load-balancing web servers, each of which serves the same set of static web pages. The applications running on these web servers also use the same set of Enterprise Java Beans (EJBs), static Java classes, and Java 2 Platform, Enterprise Edition (J2EE) components.
Because all of these servers need access to this information, you can consolidate this information in a single master volume, from which you can then create a read-only volume. All of these web servers can then simultaneously mount this read-only volume.
Further, if you subsequently need to update information (such as information in a static web page), you can update this information once in the master volume, which then replicates this change to the read-only volume. Therefore, you can update this web page only once (in the master volume), and this updated page will be available to all of the web servers that use it.
In contrast, using currently available technology, you must duplicate these static web pages, EJBs, Java classes, and J2EE components in one or more volumes on each web server. You must then manage and maintain data in each of these volumes separately. For example, if you update a web page, you must copy this updated web page to a volume on each web server.
Switching to Blades?
Many companies implement a group of web servers to provide load balancing for web applications. As a cost-cutting measure, more and more companies are running these applications on blade servers, which are pared-down servers that are designed to run a single application.
Several blade servers typically run in a single enclosure and share common I/O devices, such as a monitor, keyboard, and mouse. Blade servers also typically share common storage hardware, such as a SAN or NAS device. As a result, blade servers can cut hardware costs for the companies that use them.
Blade servers can also cut energy costs because companies pay to run one cooling fan for several servers, as opposed to one cooling fan for each server.
Of course, before you can run an application on a blade server, that blade server must have an operating system. Wouldn't it be nice if that operating system could be NetWare, which is renowned for its reliability and stability?
Either when Nakoma ships or shortly after, Novell plans to provide a version of Nakoma that runs on blade servers. You can then run your company's web applications on reliable, stable Nakoma blade servers, consolidate data storage for these blade servers on your company's SAN or NAS device, and simplify data management for the applications running on these blade servers using read-only volumes.
CONCLUSION
Because dollars for storage and data management are becoming scarce, several software developers have begun to offer products to help companies make the most of the resources that these companies already have. Not surprisingly, Taneja notes, "some of these storage management players have actually (relatively speaking) done pretty well" during the current economic crunch.
However, because Nakoma includes a plethora of features that can help you better manage your company's valuable data, your company may not need to purchase one of these storage resource management products separately. Instead, your company can upgrade its NetWare operating system to Nakoma, and in the process deploy most--if not all--of the tools it needs to better manage its data.
In addition, your company can reap the benefits of non-storage-related features that will be included with Nakoma--features such as enhanced J2EE support, which can help your company deploy web-based applications and web services.
Cheryl Walton works for Niche Associates, an agency that specializes in writing and editing technical documents. For more information about Niche Associates, visit www.niche-associates.com.
CIOS: A Gift to Novell's OEM Friends
If you are a software developer--particularly a software developer who creates device and adapter drivers for NetWare servers--Novell Consolidated I/O System (CIOS) will probably become one of your favorite Novell technologies. CIOS is a new object-oriented I/O architecture that all devices can use to access I/O resources on Novell servers, as opposed to the several I/O architectures that devices and applications must currently use.
Did you notice that I said Novell servers, rather than NetWare servers? Novell created CIOS for Modesto, which is Novell's code name for its new 64-bit operating system. Novell then back-ported CIOS to Nakoma, which will use this I/O architecture along with the I/O architectures that are traditionally available to devices and applications on NetWare. (Incidentally, Novell also used CIOS to provide Universal Serial Bus [USB] support for NetWare 6. However, in NetWare 6, the CIOS interface is not available for developers, as it is in Nakoma.)
IT'S SUPER!
Using CIOS, developers don't need to write code to support functionality that is available through super classes, which are classes that are higher in the CIOS class hierarchy. For example, because the highest class in the CIOS class hierarchy is the Object class, the Object class is a super class for all classes below it.
The Object class includes a method called Object-Get-Name, which returns an object's name regardless of the class from which this object is instantiated. That is, all of the classes below the Object class inherit the Object-Get-Name method.
Because developers use or extend existing classes that are below the Object class, these developers don't have to write code that duplicates functionality that this and other super classes provide. For example, suppose you want to write a driver for a Small Computer System Interface (SCSI) hard disk drive. To accomplish this task, you would use the SCSI Direct-Access Driver class, which is below the SCSI class in the CIOS class hierarchy and therefore inherits functionality that is available in the SCSI class. (See Figure 1.)
The SCSI class includes a SCSI command that all SCSI devices must share: the TestUnitReady command. Because the SCSI class already includes this command, you don't need to implement this command in your driver.
In other words, as Novell senior software engineer Ross Maxfield explains, if you're writing a driver for a particular device, "you don't have to duplicate functionality that is common to all devices of its type. Instead, you can concentrate on functionality that is specific to your particular device." In contrast, Maxfield adds, using traditionally available I/O architectures, you must duplicate this common functionality for your device.
IT'S SO EASY TO DEVELOP DRIVERS
Developing drivers that use CIOS is therefore easier and faster than developing drivers that use traditional NetWare I/O architectures, which, as Maxfield notes, present a much more difficult development environment than CIOS does. In fact, Maxfield estimates that, in some cases, it takes less than half as long for developers to write drivers that use CIOS than it does to write drivers that use traditional NetWare I/O systems. Of course, future NetWare operating systems, including Nakoma, will continue to use traditional I/O architectures to support existing NetWare applications and drivers.
CIOS presently includes more than 70 classes that all types of developers can use, including classes for adapter drivers such as LAN and storage adapter drivers. Developers can either extend existing CIOS classes or create new classes to support new (or proprietary) I/O technologies.
In addition to simplifying the task of writing drivers, these classes collectively represent a consistent set of methods (or application program interfaces [APIs]) that applications can use to query for and use available I/O resources. CIOS is also consistent over all Novell operating systems. If developers write drivers that use CIOS for Nakoma, these drivers will also work with Novell's new Modesto-based operating systems. (You can find more information about developing drivers that use CIOS at http://developer.novell.com/products_dev/cios.)
THAT'S NICE, BUT WHAT'S IN IT FOR NETWORK ADMINISTRATORS?
Admittedly, Novell created CIOS so that developing products for its operating systems would be simpler. Most of the direct benefits of CIOS are, therefore, for developers. However, CIOS also benefits you, the network administrator.
For one thing, this simpler development environment may lure more software and hardware vendors to develop products that run on Novell operating systems. As a result, CIOS may increase the number of products from which you can select.
For another thing, CIOS uses the NetWare registry, thereby making it easier to manage drivers. Like the Windows registry, the NetWare registry is a means by which applications can share information. Although few applications currently use the NetWare registry, CIOS will. As a result, you can access the NetWare registry to modify the behavior of drivers.
Furthermore, you don't need to access the server console to change the registry. Instead, you can use Novell Remote Manager to make these changes from any computer that has an Internet connection and a standard web browser. (Novell Remote Manager is Novell's web-based management tool for NetWare servers.)
If a driver uses a traditional NetWare I/O system, in contrast, you must access this driver's configuration file on the server to make changes. You must then reload the driver to put these changes into effect.
Because CIOS uses the NetWare registry and Novell Remote Manager can access this registry, developers can also create management tools that snap into Novell Remote Manager. For example, companies that provide Redundant Array of Independent Disk (RAID) products must currently provide separate management tools for these products. If these companies develop products that use CIOS, these companies can then provide management tools that you can access through Novell Remote Manager. As a result, you can manage more devices using fewer tools.
About Time
Because the storage resource management tool that is included in Novell Remote Manager gathers information from the individual files on NetWare volumes, you may wonder how much time performing this task takes. The amount of time it takes, of course, depends on the number of files from which this tool must gather information. That is, the storage resource management tool can scan volumes with fewer files faster than volumes with more files. Of course, the speed with which the storage resource management tool accesses files also depends on the speed of the storage media on which these files reside.
On average, Novell distinguished engineer Dana Henriksen estimates that it takes only two minutes for this tool to inventory half a million files, which is arguably not a significant amount of time. Volumes that include "a hundred thousand to a million files are quite common," Henriksen also notes, adding that the amount if time it takes the storage resource management tool to inventory volumes in this size range is "quite reasonable."
If a volume contains 10 million files, however, Henriksen estimates that it could take up to 40 minutes for the storage resource management tool to inventory this volume's contents. In this case, you can easily accomplish other tasks while the storage management tool is completing the inventory. Because the report that this tool generates is stored on the volume the tool scans, you can view it any time.
A WORD ABOUT THE COMPETITION
According to Novell manager for storage products Richard Jones, regardless of the number of files a volume contains, Novell's storage resource management tool can perform its task in less time than many third-party storage resource management applications. Unlike the storage resource management tool in Novell Remote Manager, Jones says many third-party applications actually open files to gather information about files' contents.
These types of storage resource management applications "basically just go out to the file system, open up the files, and do a brute-force scan in order to get data and information" about those files, Jones explains. Therefore, these applications take longer to inventory a file system than the storage resource management tool in Novell Remote Manager. Rather than opening files, the storage resource management tool in Novell Remote Manager reads information from the metadata that is stored with these files.
TIME IS MONEY
In addition to being more time-intensive than storage resource management applications that do not open files, applications that open files pose other significant problems. For example, to use these applications, you must often have full administrative privileges, which poses a potential security risk. These applications are also processor-intensive.
In addition, these storage resource management applications can affect system backups. For example, suppose your company's backup software backs up only files that have changed since the last backup. Because these applications open files to read data, this backup software may think that these files have been changed and may therefore back up files that have not actually been changed. In other words, third-party storage resource management applications that open files to obtain data can increase the amount of time and space needed to perform system backups.
ONE EXCEPTION TO THE RULE
In fairness, however, storage resource management applications that actually open files have one advantage: These applications can detect files that are masquerading as other types of files. For example, suppose your company has a policy that forbids users to store MP3 and MPEG files on its network. To thwart enforcement of this policy, users may rename their MP3 and MPEG files, giving these files extensions such as Word (.doc) extensions or PowerPoint (.ppt) extensions.
In this case, a storage resource management tool that actually opens these illicit files will report them as what they are--MP3 and MPEG files. Storage resource management tools that don't open these files, on the other hand, will report these files as what they say they are--Word or PowerPoint files. If you are concerned that users are trying to circumvent your company's storage policy in a similar way, the advantage of using a storage resource management application that opens files may outweigh the disadvantages.
* 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.