|
Not quite three years ago, I first tested Access NFS Gateway for Windows NT. Windows NT 4.0 was the rising star of many IT shops and the issue was how to integrate the newcomer into an existing Unix environment. In other words, the problem was how to make Windows NT play into an NFS environment.
Three years later, the tables have turned. The buzz in information technology is all about Open Source. And thanks in part to the Web, Linux is the hot new item, trying
to muscle into an environment dominated by the deeply entrenched Windows NT.
Worse yet, Windows NT is being replaced by Windows 2000, which is notorious for not
playing well with others.
For anyone trying to integrate Linux into a corporate Windows 2000 network, the choices are not at all different from what they were three years ago. Either it is necessary to make Linux dance to the tune of Windows using SMB, or it is necessary to put Windows 2000 in step with an open industry-standard protocol. In terms of IT infrastructure, it comes down to putting Samba on Linux or NFS on Windows 2000. Beyond IT infrastructure lays IT politics: He who owns the protocols owns the servers that choreograph IT.
For small Microserf environments with casual integration needs, Samba is perfectly adequate for allowing Windows 2000 clients to move data back and forth. In fact, such environments are far more likely to be characterized by clients of Windows 9x lineage. If that's the case, then Samba slides Linux in without missing a beat. It's only when you introduce a few more operating systems, say Solaris, HP-UX, or maybe even OpenVMS, that you require a more exacting distributed-security system, or start to build an enterprise IT architecture on top of a SAN, that the Windows Samba solo proves inadequate.
Just consider the minefield of file security. Linux's, like Unix's, file systems apply ownership and security from a completely different perspective than Windows NT/2000, which is built on the NT File System (NTFS). Under Linux, only individual users own files. Under Windows NT/2000, individuals and the groups to which they belong may own files. For NTFS, Windows 2000 begins applying security from a global perspective-Everyone-and then begins to look at membership in subset groups-Domain Administrators, Domain Users. Linux, on the other hand, starts with the UID, then turns to the GID, and finally looks at "other."
That being the case, OpenBench Labs set out to examine a scenario in which Linux would go beyond simply integrating into an existing Unix-based NFS environment, to serve as the foundation of a full-fledged, highly available NFS network. The scope of this question turned out to be far broader than we suspected and brings us into primary technology issues, which include topics such as the new Linux kernel and Linux clustering. What's more, these primary issues lead to secondary issues, such as the ability to efficiently back up files over NFS mount points. In short, we began to get a better appreciation for NFS as a core technology for winning the broader IT political battles over the control of infrastructure. As a result, consider this the first in a series of OpenBench Labs reviews for which NFS will be a core technology.
For this assessment, OpenBench Labs concentrated on how well current base Linux technology supports an NFS environment that integrates large numbers of Windows 2000 systems in a secure corporate environment. In coming months we will test and analyze the issues seen with high availability, which center on the handling of NFS files locking in cluster-failover scenarios, and the enhanced I/O throughput of NFSv3 coming in new distributions based on the Linux 2.4 kernel.
Having defined the protocol for distributing file data as NFS, we next had to consider user authentication. The IP address of an NFS client along with the UID and GID of the user are the controlling factors when gaining access to an NFS server. Once these credentials have been established, the NFS server is able to control read, write, and execute privileges during file access. We wanted to be able to easily manage the user-account information-UID and GID-for a large network from a central core of replicated systems. In essence, we needed to implement an analog to the domain security of Windows NT/2000 on a Linux server.
For this task we chose Sun's Network Information Service (NIS), popularly dubbed the Yellow Pages. Under this scheme, an NIS master server-with possible replicated slave servers-maintains a distributed database system that lets NIS client computers share password files, group files, host tables, and other files-referred to as NIS maps-over the network.
The maps correspond to files stored in the /etc directory, such as /etc/passwd, /etc/hosts, and /etc/services, and are normally built from these files resident on the master server. NIS clients are redirected to the NIS master through the use of a plus sign, "+", in their configuration files. For example, adding the entry "+::0:0" to the /etc/passwd file triggers the reading of the passwd map on the master. This mechanism makes it possible to tailor the information imported from an NIS server down to the field level.
Nonetheless, the combination of NFS and NIS is not a miracle panacea. By their very nature, distributed file systems provide wonderful functions and equally spectacular headaches. Both NFS and NIS have some well-known implementation flaws for which hacker toolboxes are available with programs to exploit them.
The first line of defense is a serious assessment of whether all the flexibility and power of a distributed system such as NFS is really needed. The first question that must always be asked is: Can you configure your systems to avoid NFS and its security problems completely? If, like many sites, your answer is no, then you absolutely need to be up-to-date on vendor patches and bug fixes. If the first three principles of successful real-estate investment are location, location, location, then the first three principles of successful file distribution are support, support, support.
After one, two, and three, there are a few good heuristics for implementing NFS. The first is to prohibit users for logging into the NFS server. The next is to minimize the number of NFS servers that each client mounts. A system is usually far more reliable and more secure if it mounts two hard disks from a single NFS server. Finally, any network file system is a poor choice for sharing a large database because of the difficulty of locking the database and synchronizing updates.
In particular, NFS is a stateless protocol: No information is kept on the server to indicate whether or not a client is performing a remote file operation. So, here's the state of things:
- oClients can crash and reboot without having to recover state information.
- oServers can crash and reboot while their clients continue to run as if nothing happened.
Given those parameters, OpenBench Labs configured two distinct Linux servers as the foundation for our tests. On one server, we installed SuSE Linux 7.0, ran NIS, and configured the oblabs NIS domain. On the second server, we installed Red Hat 7.0 and ran NFS server.
For any NFS server, the most important component is the I/O subsystem. Hardware-based RAID is critical here. The key is to maximize streaming throughput and not random access-databases are not good candidate for NFS-by creating a single physical stripe-set. Nonetheless, to minimize security headaches on the server, this single stripe-set needs to be presented to the Linux operating system as a collection of individual disks. To be able to accomplish this, a host-based RAID controller such as ICP-Vortex's ICP GDT7663RN or an external RAID subsystem such as Winchester System's FlashDisk is essential.
We chose to implement the host-based ICP-Vortex controller solution because of its cost effectiveness in a streaming-data scenario. Locally on the server, we were able to present a logical JBOD SCSI storage configuration in which each drive streamed data in a range of 26 to 30 MB/sec using our obldisk benchmark, which varies read sizes from 1 KB up to 135 KB.
Our next task was to make NFS-aware a collection of client and server systems running Windows 2000 Professional and Advanced Server. For this task, we used three products from Shaffer Solutions: DiskAccess for Windows, DiskShare for Windows, and AccessNFS Gateway for Windows. If the names of these products sound a bit familiar, then you probably remember them as Intergraph products. The division that created these products recently spun out as their own company. As in the past, all of these packages come with a wealth of software extras. For example, DiskAccess comes with two NFS utilities (RPC Information and Show Mounts), two TCP services (NTP Server and RSH Server), five TCP utilities (Finger, FTP Client, DNS Query, Ping, and NTP Client), a text-conversion utility (Dos2Unix), and three terminal-emulation utilities (Telnet, Telnet3270, and Telnet5250).
On computers running Microsoft Windows 9x or Windows NT/2000, DiskAccess enables users to mount any NFS volume to which they have access; DiskShare enables users to share any disk, partition, or folder as an NFS volume. Both products
use NFS remote procedure calls (RPC) and Sun's external data representation (XDR) protocol to ensure portable data transmission. For Windows NT/2000 servers, AccessNFS Gateway extends
the capability to attach to NFS file and print resources by resharing these devices over Microsoft SMB-based networks as standard Windows objects. As a result, clients running only the NetBUI protocol can use NFS-hosted services.
We installed DiskAccess and DiskShare on a number of standard laptop and desktop computers
running Windows 2000 with service pack 1. As with our NFS server, it's with AccessNFS Gateway software that hardware choice is significant. For security reasons, you will want to maximize the number of clients on a minimal number of gateways. Given that dictum, OpenBench Labs installed AccessNFS Gateway on a dual-processor Siliconrax-Sliger Rax2100 server with 512 MB of RAM.
We began our Windows 2000 integration investigation with DiskAccess, which targets the power user who needs direct access to NFS resources. Via DiskAccess, users can connect to and disconnect from remote NFS volumes through Network Neighborhood, Explorer, or File Manager. Using these same standard interfaces, users can then employ drag-and-drop features to copy, move, rename, and delete remote files.
Once DiskAccess is installed, it's up to the user to configure methods of authentication and NFS access. Setting up authentication is a deceptively trivial process that involves filling in a very uncomplicated property sheet. The problem is that there are two nearly identical sheets-the only difference in appearance is in the title bar.
One sheet is accessed via the DiskAccess applet in the Control Panel and the other is accessed via the Administrator Utility in the program menu. Filling in the sheet from the Administrator Utility sets defaults for all future sessions for all users of the workstation. It does not change any options for the current session. Filling in the sheet from the Control Panel applet sets the current session and all future sessions, but only for the current user. For those who have not mastered the fine art of reading documentation, these differences in behavior can be very disconcerting.
Even curiouser, this same duality exists for the code sibling of DiskAccess, AccessNFS Gateway. In AccessNFS Gateway, the property sheets are the same as in DiskAccess; however, the program under the Start menu is called Universal Options.
In all cases, the property sheets provide two options to establish the user's credentials with a server running either Linux or Unix. One method is via the PC-NFS daemon (PCNFSD), with the other is through NIS Domain services-the ypserv daemon. In the latter case, the user must provide the name of either the NIS domain or the NIS server. If the authentication process fails or if the site uses
neither of these authentication methods, then DiskAccess will default to making an NFS connection as an anonymous user (UID -2, GID -1).
Because AccessNFS Gateway redirects the shared NFS resource as a shared Windows networking object, the program must also have a way to map each Windows NT/2000 user account with access to the resource onto a Linux/Unix user account. This task is carried out by a User Manager program, demonstrating yet another advantage to using NIS as the authentication scheme.
Since AccessNFS Gateway only runs on a Windows NT/2000 Server, any user configuring the Gateway who is a member of Domain Administrators will have network access to the Windows Domain user database in order to set up a dynamic link. The same is true if NIS security is being utilized in the Linux/Unix space. Otherwise, it will be necessary to copy the /etc/passwd file from the Linux NFS server to the Windows 2000 Server in order to build a static map. Just the thought of multiple versions of password files floating about a LAN should be triggering countless alarm bells.
To test read performance on network-attached volumes, we used OpenBench Labs' fileload benchmark. The tests were conducted on the same storage volume attached via Samba, DiskAccess, and AccessNFS Gateway over a 100-Mbit/sec LAN. This benchmark reads a file-for these tests, we used a 200-MB file-sequentially, randomly, or in a pattern designed to simulate database activity. Since sequential access is by far the most typical use, as well as the technically recommended use, there was no question that we would perform this test. Nonetheless, as a means of identifying other key performance characteristics, we also chose to run a database simulation in each test case.
We began by running our fileload in sequential mode over Samba. Here, performance ranged from 7.8 MB/sec using 2-KB reads up to 8.8 MB/sec using 64-KB reads. Recall that directly on the Linux server, we pegged native performance in the range of 26 to 30 MB/sec. During the test, we observed CPU overhead on the Linux server to be on the order of 9-10%. Repeating the test with NFS, throughput ranged from 6.5 to 7.0 MB/sec over the same range of read-block sizes. Overhead on the Linux server, however, was only on the order of 2.5%. Here we had our first indication that NFS would tend to scale better than Samba in a heavily accessed network.
More importantly, this was done with an NFSv2 connection. Version 3 of NFS incorporates many performance improvements, but does not significantly change the way that NFS works or the security model used. In particular, NFSv3 provides for a maximum transfer buffer of 64 KB vs. 8 KB for NFSv2. NFSv3 support is provided in the new Linux kernel and is currently supported by all of the Shaffer Solutions packages that we tested.
To get a flavor of the performance improvement, we shared an NFS volume from a Windows 2000 server via DiskShare. We then measured the performance from the same Windows 2000 client that was used to test the Linux-based NFS shares. Throughput performance jumped 15% to just over 8 MB/sec.
Next we repeated these tests, this time using 8-KB reads in a simulation of database activity. Once again, we got a higher throughput on Samba, 7.6 MB/sec vs. 5.9 MB/sec. And once again, CPU overhead on our Linux server was significantly higher on Samba, 13.5% vs. 8%.
To examine the vulnerability of a Samba connection to increased CPU use, we repeated the database simulations while running our oblcpu load benchmark on the server. As expected, there was no perceptible difference in performance over an NFS connection. Over a Samba connection, however, we measured significant perturbations in throughput.
Next, we connected to our NFS share using the AccessNFS Gateway and repeated our tests while measuring overhead on the gateway. In this configuration, we had an NFS connection between the Linux NFS server and the AccessNFS Gateway system, which redirected the data over a Windows SMB connection to our client. Given the similarity of the NFS server to gateway link with DiskAccess, we fully expected to measure I/O throughput at similar levels. Instead, we measured throughput more in line with Samba at 9.4 MB/sec for 64-KB reads. Furthermore, there were no indications of any bottlenecks on the gateway system.
Our joy turned to consternation, however, when we tested database access over AccessNFS Gateway. Throughput on the client plummeted to a sludge-like 2 MB/sec and CPU overhead on the client bounced up and down. Meanwhile, the gateway showed no signs of being bottlenecked; the performance collapse was all on the client.
Analyzing the properties of each connection revealed significant insights into all of the performance differences we had measured. All three of the connections-Samba, DiskAccess, and AccessNFS Gateway-presented our Windows 2000 client with a different logical view of the volume's structure. Samba presented our volume as an NTFS device, DiskAccess presented the share volume as an NFS device, while AccessNFS Gateway presented the shared volume as a FAT device.
The rationale for the choice of FAT was simple: Since AccessNFS Gateway was designed for typical rather than power users, the applications that they would be running would almost universally be accessing the volume sequentially. As the lowest-common-storage denominator, every possible client would recognize FAT drives. As a result, Shaffer Solutions chose FAT to provide the fastest interface to the greatest number of users.
OPENBENCH LABS SCENARIO
Under examination
NFS filesharing with Windows 2000 clients
What we tested
DiskAccess for Windows o DiskShare for Windows · AccessNFS Gateway for Windows · www.ssc-corp.com
How we tested
Siliconrax-Sliger Rax2100 Web server running Red Hat Linux v7.0 · www.siliconrax-sliger.com
ICP GDT7663RN, Six Channel Ultra 160 SCSI Disk Array Controller · www.icp-vortex.com
Red Hat Linux v7.0 · www.redhat.com
SuSE Linux v7.0 · www.suse.com
OpenBench Labs oblcpu v1.0 benchmark
OpenBench Labs fileload v1.0 benchmark
Key findings
- NFS provides an excellent mechanism to share files bidirectionally with Windows 2000.
- Implementing an NIS domain for authentication is a must.
- A well-implemented gateway is a good alternative to loading NFS on each Windows client.
|
