 |
WINDOWS NASQUERADE |
|
 |
|
| Procom harnesses the power of BSD to build a NAS server that slips seamlessly into Windows 2000 domains and integrates into Active Directory. | ||||
 by
Jack Fegreus |
|
|
WINDOWS NASQUERADE |
|
|
|
| Procom harnesses the power of BSD to build a NAS server that slips seamlessly into Windows 2000 domains and integrates into Active Directory. | ||||
|
by
Jack Fegreus |
|
|
|
|
|
The explosive growth in storage has long changed what constitutes the system. It wasn’t very long ago when it was unthinkable to consider adding storage to a “system” without planning to take the system down, the hardware apart, and physically connecting each disk. Now everyone from SOHO power users to data center managers is looking for network attached storage (NAS) devices. |
|
|
|
|
|||||
|
Whether users are aware of the NAS device or not depends on just how aware they are of their network environment and how well the operations staff has hidden device configuration from view. Unix users may be aware of a new file mount point. Windows users may be aware of using a new or different drive letter. None need be aware that the device can be actively shared between Windows, Linux, and Unix systems. Looking inside the 5U Procom NetFORCE 1700 yields an entirely different view. The NetFORCE 1700 is a fully qualified file server with substantial power. The system is powered by network operating system (NOS) derived from BSD running on a 1GHz Pentium III processor with 512MB of RAM and stored on FLASH ROM. Most of the CPU power is dedicated to serving the disks across the Ethernet and to managing the ample cache provided by the 512MB of RAM. The file server’s hardware RAID capabilities are supplied by an IBM (a.k.a. Mylex) RAID controller with battery backup for the controller’s cache. Up to 10 173GB, hot-swap, SCSI drives can be connected to the controller. The network interface is typically fast (100Mbit) Ethernet, however, Gigabit Ethernet is optional via 1000BASE-SX fiber. On the initial boot, an administrator uses the front panel of the NetFORCE 1700 to set up TCP/IP with or without DHCP. Once the TCP/IP settings have been made, the storage server is rebooted and all other configuration options are implemented via web client software. There are four essential aspects to completing the setup using the web UI: Setting system and alert traps Configuring the disks Setting client connectivity Setting up backup options |
|
|
||||||
|
|
The system and alert settings are quite standard for any NAS device. The system time and date must be set along with the administrator’s password, and a means to notify the administrator of a critical system or hardware failure. What is far more interesting for understanding the nature of the NetFORCE 1700 at this point is the web UI, which in addition to device configuration provides a means to monitor NIC summary data, network activity, status summary, environmental parameters, event log contents and CPU utilization. Procom’s documentation explicitly states that the web UI can be run from Internet Explorer on Windows 95/98/NT/2000. Or it can be run from Netscape 4.7-based—but explicitly not Netscape 6.0—browsers on Windows 95/98/NT/2000 and Sun Solaris 5.7. That’s it! What’s more, these caveats are dead on. Whether we used Opera 5 from a Windows 2000 client or Netscape 4.73 from a RedHat 7.1 client, we were not able to successfully launch the web UI. Later when we configured the NetFORCE 1700 as part of a Windows work group and not a domain, we encountered the same problems that we’ve had when connecting to a Windows 2000 host in a workgroup setting via Samba with a number Gnome and KDE desktop Linux clients. Nonetheless, all of these problems immediately disappeared once we integrated the NetFORCE 1700 into an existing Windows 2000 domain. All of which reflects directly on the work that Procom has done to make a BSD-derived NAS device very Windows 2000 domain friendly—right down to the quirks of CIFS and SMB. While the NetFORCE OS has its roots in BSD, Procom has evolved the OS for NAS devices into what is ostensibly a new OS in its own right |
|
|
Disk configuration on the NetFORCE 1700 begins with assigning drives to a RAID-5 logical unit (lun). The web UI displays the ten drive slots as vertically aligned rectangles, which display the drive capacity in GB. Each logical unit configured must contain at least 3 drives. In addition, another drive can be assigned as a hot spare in case of a drive failure. While configuring a RAID-5 lun is quite easy, formatting the luns can be time consuming, as upwards of 1.7TB of storage may be present. In our test configuration, we set up one RAID logical unit (LUN) using eight 173GB drives and leaving a 9th drive as a hot spare. We then created four partitions—the maximum number of partitions allowed per lun—and assigned a file volume to each partition. We created test volumes to be exposed and shared via Samba and NFS, as well as, a volume for check pointing our public shares. |
|
|||||
|
Redundancy is essential to achieving the levels of reliability demanded by today’s systems. So in addition to hot-swappable fans, drives and n+1 power supplies, Procom adds a fully journaling file system. As a result, the NetFORCE 1700 provides for checkpoints—also dubbed Consistency Spots—which are used to retrieve mistakenly modified or deleted files. Either on schedule or on demand, system administrators can “draw a line” across file volumes. The NetFORCE server responds by writing incoming data to a different place. This preserves the data state of the file volume. When data is written to the volume by a client, the old data is copied to become a part of the checkpoint and the new data is flushed to disk where it is not a member of the checkpoint. It is important to note that a checkpoint is a virtual, or imaginary, copy of the file volume. The checkpoint file resides on disk along with all other data. It is not an online backup. If the file volume is lost, so are all the checkpoints. What’s more, an enormous amount of space and system memory is required for checkpoints. The more checkpoints there are on a system, the greater the potential for performance degradation. If you use disk checkpointing, use an automatic schedule, which sets a retention period and deletes out of date checkpoint files. |
|
|||||
|
If a device is to hold critical corporate data, that data must be saved at least daily. As we have noted, checkpoints provide an excellent adjunct to backups; however, they do not provide a substitute for backups. Procom solves this problem by including a SCSI port for an external tape drive and providing software support for scheduling and running a full panoply of both full and incremental backup operations via the NAS server’s web interface. In addition, the NetFORCE 1700 provides support for the Network Data Management Protocol (NDMP), which is an open protocol for network backup. NDMP provides a means tor NAS devices to be used with server-based backup administration applications that are NDMP-compliant. The most critical aspect for any NAS server, however, is how well it implements the security models of all of the clients that it is designed to service. The security challenge for the NAS server is to recognize user identity, map those identities to a protection scheme and then to implement access criteria on that basis. Whenever there is a boundary between systems, such as a network connection, there is the opportunity for the malicious user to change the way that security codes and security settings are interpreted. Procom provides for security in both Windows and Unix style. As a result, both Windows and Unix clients can access file volumes without loss of protection. The NetFORCE 1700 also creates a mechanism for mapping individual file protection between the two architectural schemes. As a result, this NAS device integrates easily and almost seamlessly into heterogeneous environments running both Windows and Unix. In the case of a Unix and/or Linux environment, the NetFORCE 1700 stores file permissions in native format—its OS is derived from BSD. Each file is stored with its inode meta-data, which includes file ownership (UID/GID) and file permissions, in the familiar read/write/execute form. The NetFORCE 1700 also allows the administrator to enable access to an NIS or NIS+ server, which maintains the same UID and GID mappings across Unix systems on the network. For Windows, the NetFORCE software supports 3 Windows domain models: single domains, master domains, and multiple master domains. Under a Windows domain security scenario, a domain controller authenticates users. More importantly for Windows 2000 domains, the Procom software integrates the NetFORCE into the Active Directory Service (ADS). |
|
ADS is a Windows 2000 namespace tightly linked into with the Domain Name System (DNS) and runs only on domain controllers. The ADS stores domain information, such as users, groups and shared resources, protects network objects from unauthorized access, replicates objects across domain controllers, and publishes that information to Active Directory clients in the domain. In the Windows model, device security has two parts. First, the owner or administrator of a device or volume must allow access. If access is permitted, then a deliberate step is required to “share” the device. In the case of Windows NT and Windows 2000, devices are always created with a default administrator share, which grants access to members of administrator groups. This is done using the Windows file-sharing services dubbed the Common Internet File System (CIFS). This service utilizes the Server Message Block (SMB) protocol to provide client systems with access to files on the server. When ADS is enabled the NetFORCE will automatically perform ADS updates and publish specific NetFORCE shares in the ADS directory. Objects are located within Active Directory domains in Lightweight Directory Access Protocol (LDAP) distinguished name (DN) notation according to a hierarchical path, which includes levels of "container" objects. Administrators enable ADS integration by entering the ADS path location of the Windows 2000 administrative user. |
|
|||||
|
Benchmarking the NetFORCE 1700 was an interesting exercise that yielded equally interesting results. Our goal was to characterize the performance of the NetFORCE 1700 by measuring the rate at which it could data to an application. Here, the problem with this device as with all NAS devices is the network. While internally the IBM RAID controller is theoretically capable of accessing and pulling data off of the disks at exceptionally high rates, the default 100Mbit Ethernet connection of most clients presents a much lower effective ceiling—theoretically 12.5MB per second—on data throughput. For our benchmarks, we utilized an HP 1000r NetServer 2400 server runnning Windows 2000 Server as our domain controller, an ASL Marquis K120 workstation running BearOps Linux as a client, and a Dell Optiplex GX150 as our Windows 2000 Pro client system and an HP Omnibook 6000 running Windows 2000 Pro as our domain administration system. Measuring actual disk throughput is complicated by the difficulty of isolating the effects of multiple data caches on the drives, the RAID controller, the NAS server, and the client system. These cache effects create orders-of-magnitude differences in disk subsystem performance for differing workloads. More importantly, attempting to measure raw I/O throughput, sidesteps the important issue of file system overhead. To accurately gauge what a user will experience, the benchmarks have to be run at the file rather than device level. For that reason, we chose to run our oblfileload benchmark. For both a Fast Ethernet and a Gigabit Ethernet connection, we launched 10 simultaneous client processes, which accessed data residing on the NetFORCE 1700in 8-KB blocks. Furthermore, we concentrated the bulk of our testing running SMB/CIFS connections rather than NFS because of the tight integration with ADS for Windows 2000 clients. |
|
While the graph tells the full story of the performance results, the summary is that for Fast Ethernet, the clear limiting factor was network bandwidth. We chose to run our tests first with 1 and then with 10 clients, each of which were sequentially reading 200MB data files. While the NetFORCE server is designed to service hundreds of client systems, the typical instantaneous load is likely to be much less. With or 10 clients, total network throughput increased by approximately 10% . The maximum variation in throughput per process was only 2%. Total throughput was 11.4MB per second. We then repeated the tests over a Gigabit Ethernet connection. In theory, throughput should have jumped by an order of magnitude. It didn’t. In our tests over a
Gigabit Ethernet connection, throughput for a single client was on the order
of 22MB per second. Total throughput for 10 client processes was 24.8MB per
second. Interestingly, the maximum variation among the 10 processes did
decline by an order of magnitude to a mere 0.1%.
|
|
|||||
