Capacity Planning for the IntranetWare IPX/IP Gateway
Articles and Tips: article
Senior Research Engineer
Novell Application Notes
01 Dec 1996
Details the performance characteristics of Novell's IPX/IP Gateway to help you determine where and how to deploy the Gateway in your organization.
Thanks to Steve Bannister, Darin Cable, Diane Heckman, Richard Lamplugh, Alan Mark, John Michalek, Kevin Pikus, Mala Ranganathan, Mark Shapiro, Henry Sprafkin, Larry Supino, and Kris Widman for their help with this AppNote.
- Introduction
- IPX/IP Gateway Theory of Operations
- Performance Characteristics of the IPX/IP Gateway
- Capacity Planning Recommendations
- Conclusion
Introduction
One of the components included with Novell's IntranetWare is the IPX/IP Gateway. This gateway software allows a NetWare network to connect transparently to an intranet or to the Internet without the administrative overhead of deploying a TCP/IP protocol stack on each client workstation. Due largely to the efficiencies of the NetWare operating system, many existing NetWare servers have the necessary resources to support an IntranetWare IPX/IP Gateway, thus providing both intranet and Internet capabilities without any additional equipment expense.
This AppNote details the performance characteristics of Novell's Intranet-Ware IPX/IP Gateway so that you can determine where and how to deploy the IPX/IP Gateway's services in your organization. Sections include:
A theory of operations to help you understand the underlying processing involved in IPX/IP Gateway operations.
A discussion of the IPX/IP Gateway's performance characteristics and the impact those characteristics will have on your server and network resources.
Six real-world IPX/IP Gateway configuration scenarios, with our recommended approach to capacity planning.
For an overview of IPX/IP Gateway features, components, and configuration options, see "An Introduction to Novell's IntranetWare IPX/IP Gateway," Novell Application Notes, September 1996, p. 3.
For a step-by-step guide to connecting the IPX/IP Gateway to an Internet Service Provider (ISP), see "Connecting to the Internet from a Novell Network" on page 33 in this issue.
IPX/IP Gateway Theory of Operations
When planning the installation and configuration of the IPX/IP Gateway, it is helpful to have a basic understanding of how the product works. This section provides a brief overview and theory of operations for the IPX/IP Gateway, covering the following areas:
Architecture of the IPX/IP Gateway
Gateway Client and Server interaction
NDS security and access controls
PING compatibility
It also includes a sidebar that provides some tips for working with the IPX/IP Gateway.
IPX/IP Gateway Overview
The IPX/IP Gateway provides IPX clients controlled access to TCP/IP services. The Gateway's design makes use of facilities which are already part of the TCP/IP standards to multiplex up to 250 IPX clients' IP requests through a single IP protocol stack and IP address located on the IPX/IP Gateway (see Figure 1).
Figure 1: IPX/IP Gateway system view. The IPX/IP Gateway Client represents WinSock running in gateway mode and a 16- or 32-bit Gateway Task.
The IPX/IP Gateway serves as a central access point for Internet and intranet services, making it a natural firewall against unauthorized access. Using this centralized access point, administrators create and administer a single security and access policy which is stored in their organization's Novell Directory Services (NDS) tree. This NDS-object centric approach allows an administrator to provide a consistent user access policy regardless of which IPX/IP Gateway, within a multi-gateway configuration, a client uses to access TCP/IP resources.
The IPX/IP Gateway supports WinSock v1.1 applications written to the connection-oriented Transmission Control Protocol (TCP). This means that the Gateway supports web browsers, FTP, TelNet, and other applications written to the WinSock interface. WinSock applications written to the connectionless User Datagram Protocol (UDP), such as NFS, are not currently supported. DOS-based TCP applications aren't supported because they are not written to the WinSock API.
|
Note: Although Real Audio is UDP based, it has an option that allows you to use TCP andoperate successfully over the IPX/IP Gateway. |
Architecture of the IPX/IP Gateway
Novell's IPX/IP Gateway includes two components--a client piece and a server piece (see Figure 2). It is through these two components that the IPX/IP Gateway provides IPX clients remote access to a TCP/IP stack and services such as DNS (Domain Name Service).
Figure 2: Novell's IPX/IP Gateway includes two components--a client piece and a server piece. Requests from Gateway Clients all pass through a single TCP/IP stack on the Gateway Server.
The server piece, called the Gateway Server, is implemented as a NetWare Loadable Module (IPXGW.NLM) that runs on top of an IntranetWare server and multiplexes up to 250 Gateway Clients' requests through a single TCP/IP stack located within the server.
The client piece, called the Gateway Client, is installed on each IPX client that wants access to the IPX/IP Gateway's TCP/IP services. In Windows 3.1x, the Gateway Client is the Client 32 WINSOCK.DLL. In Windows 95, the Microsoft WINSOCK.DLL and WSOCK32.DLL are renamed and replaced with the Client 32 WINSOCK.DLL from Novell.
The protocol used to communicate between the Gateway Client and Gateway Server is TCP implemented on top of IPX (referred to as TCP/IPX in this AppNote). This protocol implementation allows the IPX/IP Gateway to provide the same guaranteed delivery to its Gateway Clients that is provided by TCP/IP on the other side of the Gateway Server.
Gateway Client and Server Interaction
With the IPX/IP Gateway software enabled on a network, the Gateway Client (WinSock running in gateway mode) is automatically loaded whenever a WinSock application is loaded. During initialization, WINSOCK.DLL spawns a Gateway Task to administer a special client-server control connection with the Gateway Server.
|
Note: When the NetWare Administrator (NWAdmin) utility is configured with the IPX/IPGateway snap-in, it makes DNS database calls that use WinSock. In this case,NWAdmin will spawn a Gateway Task. |
Figure 3 shows an example of the events which occur between the Gateway Client and the Gateway Server when a user loads an application such as the Netscape Navigator web browser.
Figure 3: The IPX/IP Gateway Client and Server communicate over both command and data channel connections.
Event 1 - The Netscape Navigator application is loaded by the user.
Event 2- Navigator loads WinSock.
Event 3 - WinSock spawns a Gateway Task that attempts to obtain the IPX address of a Gateway Server.
The Gateway Client uses the following search order to locate a Gateway Server:
Locate the preferred Gateway Server through NDS.
The distinguished name of the preferred Gateway Server must be specified for this to work properly. Otherwise the search for the preferred Gateway Server is restricted to the user's context.
Locate any Gateway Server through NDS.
Locate the preferred Gateway Server through the Bindery.
Locate any Gateway Server by making Service Advertising Protocol(SAP) requests.
After locating a Gateway Server, the Gateway Client passes the following information to the Gateway Server: its version, whether it's a 16-bit or 32-bit Gateway Client, and the user's NDS login ID.
Event 4 - The Gateway Server and Client then create, at most, two "command" connections for the Gateway Client: one for the 16-bit Gateway Client and one for the 32-bit Gateway Client (the two Gateway Tasks count as a single licensed IPX/IP Gateway user). The Gateway Server uses the user's NDS login ID to locate and process the user's security rights and access restrictions stored in the Directory. Once these command connections are in place, the Gateway Client and Server are ready to service requests from the client application.
Event 5 - From then on, each time the application requests a socket, the Gateway Client creates a data connection with the Gateway Server. To do this, the Gateway Client performs a local socket and bind call to allocate a dynamic IPX port. The Gateway Client forwards this IPX port as part of a socket request to the Gateway Server via the command connection. The Gateway Server then allocates a TCP/IP socket and associates it with the TCP/IPX socket created when the Gateway Client connected to the Gateway Server. This new TCP/IP socket becomes the end-point for communications with the destination host requested by the application.
All Gateway Clients share the Gateway Server's IP address, but each one has a unique port assignment. When the Gateway Server receives a response from the Internet or from an intranet service, the response is addressed to a port number, which maps to a specific Gateway Client socket. It is this mechanism which allows the Gateway Server to multiplex up to 250 IPX clients' IP requests through its single IP address.
When the last WinSock application terminates, the Gateway Client closes all open sockets, terminates, and unloads.
|
WinSock Calls WinSock calls made by the client application are handled three different ways, depending on their classification: 1. Local administrative, bookkeeping, and utility calls are handled entirely by the Gateway Client (WinSock and the Gateway Task) and are not passed to the Gateway Server. 2. Calls related to IP socket management and name database access are passed from the Gateway Client to the Gateway Server, via the command connection, where they are resolved. 3. All other calls to send and receive data are simply relayed through the Gateway Client and Server to the host requested by the application via the approapriate data channel. |
|
IPX/IP Gateway Tips |
|
|
Checking IPX/IP Gateway Status The Gateway Client reports the status of its search for an IPX/IP Gateway server until it finds one. If the application fails to connect or open a socket, check the status of theGateway Task by maximizing its window. NDS Access Controls If Access Control is enabled on every Gateway Server, users must be logged into an NDS tree to access the IPX/IPGateways. SAP Filtering When the preferred Gateway Server is located in a different NDS tree than you're logged into, the Gateway Client will use Novell's Service Advertising Protocol (SAP) to locate the Gateway Server. If you're using SAP filtering (enabled via FILTCFG.NLM), make certain that the Gateway Server's SAP ID (0x027F) is allowed to pass through the SAP filter. Otherwise, Gateway Servers on the other side ofthe SAP filter will be invisible to your Gateway Client. |
Trace Files You can trace Gateway Client operations and view them in two log files when you enable the Gateway Client's trace facility. The 16- and 32-bit Gateway Clients both use a Windows Initialization file called NOVWS.INI for settable parameters. To enable the trace facility, editNOVWS.INI and add the following section: [GwTraceInfo] TRACE=4 TRACE allows settings from 0 to 4. 0 disables the trace facility; 1 through 4 enable the facility, with 1 producing the least amount of information and 4 producing the most. 4 is the most useful setting for following WinSock events handled by the Gateway Client. Trace information is stored in a file named GWDBG32.TXT by the 32-bit Gateway Client and in GWDBG16.TXT by the 16-bit Gateway Client. An example 16-bit client trace file is shown below. These files are overwritten each time the Gateway Client initializes. Remember to disable the tracefacility when you're finished. |
|
|
NDS Security and Access Controls
The IPX/IP Gateway's access controls are deployed in the NDS tree as part of any user, group, Organizational Unit, or Organization. These controls are administered via the NetWare Administrator utility using a special snap-in DLL supplied with the IPX/IP Gateway software (IPXGW3X.DLL for IntranetWare, IPXGW.DLL for NetWare 4.1 environments). Installing the IPX/IP Gateway without controls or operating with access control disabled provides clients unrestricted access to the connected TCP/IP network.
|
Note: The IPX/IP Gateway provides integration into NDS by extending the NDS schemawith an "IPXGW:IPX/IP Gateway Access" stream attribute. |
Since the Gateway's access controls are integrated into NDS, they can be inherited. The most efficient placement of access controls is to attach the restrictions to one or more containers as high in the tree as possible. This design allows the greatest number of users to share one or more centralized control lists, thereby simplifying the administrative burden and reducing the performance overhead of the access control system. The least efficient placement of these controls within an NDS tree is to create individual access controls for each IPX/IP Gateway user. Because this inefficient design makes more work for the administrator and takes up more memory in the Gateway Server, it should be avoided unless absolutely necessary.
PING Compatibility
The PING (Packet InterNet Groper) utility is a standard tool used to determine whether a particular host is responding on the network. However, the Gateway Client does not support the ICMP echo request used by PING from native TCP/IP workstations. In place of the native PING utility, the IPX/IP Gateway includes a custom PING utility called WINPING, which can be run from IPX clients that have access to a Gateway Server. WINPING sends a request to the Gateway Server, which then performs a PING process using the native ICMP echo request. Results of the PING are then returned to the requester.
Performance Characteristics of the IPX/IP Gateway
As with all software, the IPX/IP Gateway has a unique set of performance characteristics. In this section, we discuss some of those characteristics to help you plan appropriately and be better prepared to understand the performance of your configuration. These characteristics are:
The "performance cost" of the IPX/IP Gateway versus native IP
Impact of the IPX/IP Gateway workload
Server memory requirements
CPU utilization
Access control performance
Performance Cost of the IPX/IP Gateway versus Native IP
The main purpose of the IPX/IP Gateway is to leverage your installed base of IPX protocol stacks in NetWare clients. You benefit by not having to implement TCP/IP, by having a centralized access point, and by centralizing security and access controls in NDS. However, there is a "performance cost" --the latency, or delay induced by the Gateway Server as it processes connection setup and socket requests, and relays data between each Gateway Client and their host connections.
To measure the additional latency involved with using the IPX/IP Gateway compared to using native IP, we tested two intranet configurations:
For the native IP configuration, we configured native IP at each client workstation and on the IntranetWare server. Thus each client had native TCP/IP access to the IntranetWare Web Server.
For the IPX/IP Gateway configuration, we configured both the clients and the IntranetWare server with IPX. In this configuration, the IPX clients used an IPX/IP Gateway (also installed on the IntranetWare server) to access the IntranetWare Web Server.
The intranet testbed consisted of 250 client workstations and an IntranetWare Web Server. The test results showed that, in our native IP configuration, 250 native IP clients can load HTML documents of various sizes in approximately 3 seconds. When we repeated the test using IPX clients going through the IPX/IP Gateway, each IPX client took approximately 4.5 seconds to load the same documents. These results suggest that the performance cost of the IPX/IP Gateway equates to an increase in HTML document load times of approximately 50 percent.
The 50 HTML documents we used in our tests were more typical in makeup than those used in traditional benchmark tests. Each of our HTML documents incorporated a graphic or PERL script; 25 of the documents were AppNotes ranging in size from 0.5MB to 2MB with multiple graphic images. Although our results can't be directly compared to other benchmark results, ours are more likely to resemble the results you'll see in an actual production environment.
While we did not do any performance testing of other TCP/IP services besides HTTP, we would expect similar results to the HTTP response times (with only slight variations).
If your configuration will include a WAN link (56Kbps to T1), the latency produced by the IPX/IP Gateway will be less noticeable because it will be overshadowed by the significant delays imposed by the WAN link.
|
Superlab Test Configurations The performance characteristics and capacity planning recommendations in this AppNote are based on performance tests conducted in Novell's Superlab facility. The test environment included a 10Mbps Ethernet with 250 Windows 95 clients connected to a 100Mbps Ethernet backbone. The server, located on the 100Mbps backbone, was a single Pentium Pro/200 IntranetWare server with 130MB of RAM. We used the shipping version of IntranetWare. Our test workload was a simple NetScape Navigator HTTP script that requested HTML documents one after the other without any delay. As soon as the previously requested document was loaded, another request was issued. The documents ranged in size from 0.5MB to 2MB. |
Impact of the IPX/IP Gateway Workload
The IPX/IP Gateway supports a wide variety of TCP/IP services and protocols. Each of these services and protocols has a unique personality-- a unique workload signature.
HTTP is the most popular protocol used on the Internet, making up an estimated 95% of all Internet traffic. Typical use of HTTP produces a light workload not much different from the well-known NetWare file and print services workload. Thus the workload produced by your users to access intranet web servers will resemble the workload produced by your typical word processor, database, or spreadsheet users.
Of course, from a packet-level perspective, you'll see some significant differences. However, these differences are due not so much to the addition of the IPX/IP Gateway, but to the addition of TCP/IP applications to which the Gateway provides access.
Different Traffic Patterns. If you're familiar with NetWare traffic, you're probably accustomed to the minimal traffic signatures produced by the request and reply banter between client and NetWare server. The efficiency of NetWare communications is the result of Novell's service protocol--the NetWare Core Protocol (NCP)--using a connectionless, datagram protocol (IPX) as its transport protocol. WinSock applications, on the other hand, use TCP--a connection-oriented protocol.
One of the fundamental differences between the two environments is that NetWare embeds its receive acknowledgements in its reply messages. TCP, on the other hand, requires that an additional packet be sent to acknowledge the receipt of every request and reply packet. This translates into a workload that looks very different from workloads found in traditional NetWare environments. TCP/IP and WinSock applications produce a far greater number of small packets per operation than is required to carry out a similar operation in a NetWare setting.
Let's look at some of the traffic patterns you can expect to see with various IPX/IP Gateway configurations.
IPX Traffic. On the IPX side of the Gateway Server, the Gateway Server carries on a client-server conversation with each Gateway Client. This conversation is made up of the following exchanges:
Requests--and their associated replies--to set up the initial IPX/IP Gateway command connections
Requests related to IP socket management and name database access
Send and receive data on separate logical data channels
IP Traffic Isolated within a NetWare Server. If the sole purpose of the IPX/IP Gateway is to provide access to an IntranetWare Web Server running on the same server, IP traffic sent between the Gateway Server and Web Server will not appear on any external LAN segment (see Figure 4).
Figure 4: When the IPX/IP Gateway talks only to a Web Server on the same NetWare server, IP traffic is isolated within the server.
In this scenario, the IP traffic is isolated to the logical network segment inside the server on which the two services communicate.
IP Traffic Isolated to an Internet Service Provider via WAN. If the Gateway Server is running in the same server as the WAN link, all IP traffic will be isolated to the WAN link connected to the ISP (see Figure 5).
Figure 5: When the IPX/IP Gateway is on the same server as the WAN link to an ISP, IP traffic is isolated to the WAN link.
IP Traffic in a Local Intranet. If the IPX/IP Gateway provides access to any TCP/IP services not on the same server, IP traffic will appear on the server's LAN segments on which those services are located (see Figure 6).
Figure 6: When the IPX/IP Gateway provides access to TCP/IP services not on the same server, IP traffic will appear on the LAN.
In this case, you will see the same type and intensity of traffic on the IP segments as if the requesting clients were speaking native IP. However, none of the IPX traffic used for negotiating command and data connections between the Gateway Client and the Gateway Server is seen on the IP side of the Gateway Server.
Ethernet Collisions. In large installations with hundreds of Gateway Clients, TCP communications can have a significant effect on the packet size distribution of your network. By themselves, these "chatty" communications result in a packet size distribution with as much as 90% of the packet lengths averaging 77 bytes. The rest of the distribution is made up of data packets; for example, 3% in the 255-byte range, 3% in the 511-byte range, and 4% in the 1023- to 1514-byte range. This very small packet size distribution increases the probability of collisions.
In our tests of from 100 to 250 Gateway Clients, we noticed a healthy increase in Ethernet collisions. Under the heaviest load in the Superlab (250 Gateway Clients simultaneously making back-to-back HTTP requests), the LAN adapter in the Gateway Server was reporting several hundred collisions per second. To put this into perspective, remember that collisions are a natural phenomonon when the workload is made up of many very small packets. This seemingly excessive number of collisions can't be viewed as unhealthy when you consider that a 10Mbps Ethernet LAN can potentially handle upwards of 16,000 of these 77-byte packets per second. The point to remember: if you notice higher-than-usual collision rates after you deploy 100 or more Gateway Clients, the source is most likely your TCP traffic--not malfunctioning hardware.
In some configurations, collisions are difficult to measure due to hub and switching equipment hiding the fact that collisions are occurring. If you're operating Ethernet over coax cabling without any hub or switching equipment, you'll see all the collisions. But if you employ any kind of equipment that hides collisions by not retransmitting the back-off signal, or that "avoids" collisions using buffering techniques, you won't be able to see the collisions, even with a protocol analysis tool.
One way to monitor collisions is to watch the collision statistics reported by the LAN adapter in the Gateway Server. Look for these statistics in MONITOR.NLM, by selecting the LAN/WAN Information option, and then selecting the adapter that connects to your Gateway Clients. The names of each vendor's statistics will vary, but most export one or more collision statistics.
For a complete discussion of the Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and the Physical Layer Specification of Ethernet, see ANSI/IEEE Standard 802.3-1985(ISBN 0-471-82749-5).
|
LAN Driver Collision Terminology Local Collision. A collision that was detected by the LAN adapter when it was sending or transmitting. Remote Collision. A collision detected by the LAN adapter when someone else is sending or transmitting. Single Collision. A transmission that encountered only one collision. Multiple Collision. A transmission that encountered more than one collision. |
What If the Workload Is Too Much? Occasionally, you may run into a situation where one or more aggressive users, or the widespread use of a particular service, is producing a heavier workload than you are willing to support. You can identify the offending users or services by reviewing log files (SYS:\GW_AUDIT.LOG) or by monitoring your clients' bandwidth utilization using a protocol analyzer's station monitor. Once this is done, you have several options:
Educate your users on the impact of various network services on the network and request that they limit their use of one or more IPX/IP Gateway services during busy hours.
Restrict individual users' access to the specific hosts or services that can't be justified with a business case.
Restrict your user community's access to services that can't be justified with a business case.
Upgrade your server or network infrastructure to handle the additional workload, depending on which component you identify as the bottleneck.
Server Memory Requirements
When the IPX/IP Gateway is initially loaded into server memory, it requires 300KB of RAM. This is the IPX/IP Gateway's basic memory requirement for IPXGW.NLM and NETDB.NLM. Once the Gateway Server is operational, it allocates memory for socket management on a per-socket basis and memory for access controls on a per-client basis:
Each socket requires 5KB of memory (3KB for I/O buffers and 2KB of stack space).
Access control memory requirements are variable.
To see the real-world tendencies of the Gateway Server's memory allocator, we tracked server memory allocation in our tests. We used NetScape Navigator, which allocated two to four sockets depending on the type of HTTP request it was preparing to transmit. During a test with 250 clients, the Gateway Server allocated 7,717,440 bytes (beyond its basic memory requirement) which equals 30,870 bytes or approximately 30KB per user.
Depending on your application's allocation of sockets, a single IPX/IP Gateway user will impose a server memory requirement of from 25KB to 40KB of memory. 30KB is a good average that we'll use in future server memory calculations.
|
Socket Allocation Tip Netscape Navigator includes a "Max Connections" setting in Preferences that defaults to four. This setting controls the number of sockets the application may open simultaneously. |
CPU Utilization
Server CPU availability is an important factor in determining whether existing NetWare servers have the needed resources to support a new service. The Gateway Server includes several CPU-intensive tasks:
One of the tasks involves the coordination of two separate request-response conversations for each Gateway Client: one in IPX, the other in IP.
Access control is another task that can use CPU resources if the user restrictions are not implemented efficiently (see the section on "NDS Security and Access Controls" in this AppNote).
The rest of the CPU utilization stems from the Gateway Server's architecture. The Gateway Server transfers all of its inbound and outbound traffic into separate memory pools, from which the IPX/IP Gateway provides its connection and access control services. These data movement operations are CPU-intensive.
None of these tasks is significant when the IPX/IP Gateway is configured to serve small user communities with light workloads such as web browsing. But if the IPX/IP Gateway is configured to handle greater numbers of users or heavier workloads, you will need to plan your deployment of the Gateway Server accordingly.
What If My Server Needs More CPU Power? If you need more horsepower for your Gateway Server, you have several options:
Move the Gateway Server to a production server that has enough CPU resources to handle your expected workload.
Dedicate an IntranetWare server and its CPU entirely to running IPX/IP Gateway services.
Upgrade your server platform to a faster CPU.
Access Control Performance
The potential for performance degradation during the IPX/IP Gateway's processing of user access controls is minimized by caching each user's access restrictions. When the Gateway Client initiates its IPX/IP Gateway connection, the Gateway Server scans the user's object properties and inherited rights for IPX/IP Gateway access controls. The Gateway Server then caches those controls so that subsequent IPX/IP Gateway requests do not result in repeated scans of the NDS directory.
Capacity Planning Recommendations
Many NetWare servers have spare CPU cycles and enough memory to accommodate an IPX/IP Gateway. In most cases, existing NetWare servers in your organization will be able to support this new service. However, because the IPX/IP Gateway will have at least some impact on your server's resources, we do not recommend that you indiscriminately place Gateway Servers on existing servers.
General Planning Guidelines
The following is a list of facts and figures you'll need to gather before you install an IPX/IP Gateway on an existing production server:
Questions to ask concerning your existing server:
How many simultaneous users does the server currently support?
What is the server's CPU utilization trend?
Plot the server's CPU utilization for a normal day's workload, as well as for peak periods such as end-of-month processing.
Does your server have sufficient memory for its existing workload?
Compare your server's memory to the amount of memory recommended by the Server Memory Worksheet, Novell Application Notes, January and November 1995.
Does your server have extra memory?
Tune the server's cache and determine whether your server has sufficient, insufficient, or more than enough memory. See "Tuning Cache with the NetWare 4 LRU Sitting Time Statistic," Novell Application Notes, March 1995.
What types of workloads are the server's users placing on the server?
Take into account attached network-productivity applications such as spreadsheet and word processing, e-mail, database access, and other types of workloads.
Are the server's response times acceptable?
Find out how the server's users feel about the typical response times they experience on a daily basis, and which events, if any, interrupt their expectations.
Questions to ask about how your user community plans to use the IPX/IP Gateway:
How many users will need access to the IPX/IP Gateway?
Which Internet or intranet services and protocols will the IPX/IP Gateway support?
What kinds of workloads will the IPX/IP Gateway's users produce, and how often?
If your present server is underutilized, you can skip the worry of capacity planning and install the IPX/IP Gateway.
If your user community is already pushing the server to its limits, consider one of your other options (placing the Gateway Server on a more powerful or less resource-bound server, or running the Gateway Server on a dedicated server).
Remember that you can use the IPX/IP Gateway's access controls and the Preferred Gateway setting to limit who uses the Gateway Server, when they use it, and what IP hosts and services they can access at those times. These controls can help you limit the impact of the IPX/IP Gateway on your server's performance.
Simultaneous Versus Supported User Counts
Another issue to keep in mind is the difference between "simultaneous" users and "supported" users. Simultaneous users refers to the number of users an IPX/IP Gateway can handle at any given point in time. Supported users refers to the total number of users an IPX/IP Gateway might support over an extended period of time, such as during an hour or a day.
Most of your users won't be actively using the Gateway full-time. Even if they were, actual data transfers would likely be infrequent and sporadic, similar to other file service traffic patterns. Many IPX/IP Gateway users will access the Gateway's services for less than a half-hour per day. This means that, if user access is spread evenly over the workday, one IPX/IP Gateway may be able to support 1000 users. As usage patterns begin to show signs of peak access times, you may have to plan IPX/IP Gateway resources accordingly, or add a Gateway Server to offload the work during peak utilization periods.
The capacity planning scenarios below all refer to simultaneous user counts to help you plan for periods of peak usage.
Six Capacity Planning Scenarios
In this section, we provide six capacity planning scenarios to help you plan the deployment of the IPX/IP Gateway in small, medium and large configurations:
Small Workgroup Internet with a 56Kbps ISP connection
Small Workgroup Intranet with no Internet connection
Small Workgroup with Internet and Intranet access
Medium-sized Workgroup Internet with a T1 ISP connection
Medium-sized Workgroup Intranet
Dedicated IPX/IP Gateway
Since even large organizations with tens of thousands of clients are made up of many smaller workgroups and departments, we intend all of these scenarios to be applicable to organizations of any size.
IPX/IP Gateways for small workgroups require less planning because many workgroup and small department servers have sufficient resources to support the IPX/IP Gateway in addition to their existing workloads.
Medium and large (dedicated) configurations are a little trickier because the IPX/IP Gateway requires substantial server resources as the number of users and workload intensity increase. Pay close attention to the capacity planning facts and figures above as you decide whether to deploy the IPX/IP Gateway on existing production servers or dedicate the service on its own server platform.
Small Workgroup Internet with 56Kbps ISP Connection. The Small Workgroup Internet scenario applies to any small group of approximately 25 users (IPX clients) who want intermittent access to the Internet via a 56Kbps link through an Internet Service Provider (see Figure 8). The majority of traffic will be web browsing, with occasional FTP file transfers and TelNet use.
Figure 8: A small workgroup Internet configuration with a 56Kbps link to an Internet Service Provider.
For groups of this size, your capacity planning tasks will be minimal. If the existing server's CPU utilization trend is at or below an average of 50%, you can add the IPX/IP Gateway services to the server without reservation. The impact of this new workload on the server will be minimal.
The bottleneck in this scenario is not the server's CPU or the IPX/IP Gateway, but the 56Kbps WAN link. Generally, a 56Kbps link will support no more than 10-12 simultaneous users. However, depending on the access frequency and the workload types and intensity, the number of supported users could be up to several hundred. The IPX/IP Gateway's response times will also depend on the type and intensity of your users' TCP/IP workloads.
In our tests (up to 50 Gateway Clients simultaneously making back-to-back HTML requests), we achieved the best performance and response times with fewer than 15 clients. Under these conditions, CPU usage by the IPX/IP Gateway and WAN routing services will be in the 0-45% range, depending on the workload pattern and the efficiency of the WAN interface.
As we added more Gateway Clients, we were able to achieve a peak of 43 HTTP requests to the web server in one second. However, as we entered the 20 to 50 client range, response times became significantly poorer. Of course, these Gateway Clients were simultaneously accessing web documents. In real-world scenarios, your users will be accessing the IPX/IP Gateway intermittently.
For more information on connecting your network to an Internet Service Provider, see "Connecting to the Internet from a Novell Network" on page 33 in this issue.
Small Workgroup Intranet with No Internet Connection. This intranet scenario is similar to the Small Workgroup Internet scenario above, except that the TCP/IP services are locally connected via a LAN. This scenario does not include a connection to the Internet. It represents a small group or organization of approximately 25 users (IPX clients) who want intermittent access to a web servers or other intranet services (see Figure 9).
Figure 9: A small workgroup intranet configuration with no Internet connection.
If the server's current CPU utilization trend is below an average of 50%, you can add the IPX/IP Gateway services to the existing NetWare server. Since all of the intranet services are local, the Gateway Server is able to respond faster to Gateway Client requests. If your server is a Pentium-class system running at or above 133MHz, it can service all 25 users simultaneously in this scenario (depending on the type and intensity of their TCP/IP workloads).
In this scenario, CPU utilization for the Gateway Server and LAN routing services can range from 0-50%, depending on the workload. However, if the intranet users are the same users who would otherwise be accessing the NetWare file system, you may not see a significant increase in CPU utilization at all. This is because the workload created by local web server access is the same as traditional file service. Most of your users will access one or the other, but not both services at the same time.
Small Workgroup with Internet and Intranet Access. This scenario is the combination of the Small Workgroup Internet and Small Workgroup Intranet scenarios above. This scenario applies to any small group of approximately 25 users who want intermittent access to both Internet and intranet resources (see Figure 10).
Figure 10: A small workgroup configuration with a web server and a link to the Internet.
If the existing NetWare server's CPU utilization trend is below 50%, you can add the IPX/IP Gateway services, including a WAN link to an ISP, to the existing NetWare server.
As in the Small Workgroup Internet scenario above, the bottleneck for Internet users will be the 56Kbps WAN link. Generally, a 56Kbps link will only support 10-15 simultaneous users (depending on the type and intensity of their TCP/IP workloads). If your WAN link is slower, fewer users will be able to access the Internet with satisfactory performance. Your users' access of intranet services through the IPX/IP Gateway will be much faster.
CPU utilization for the Gateway Server and WAN routing services in this scenario will range from 0-50%. Having both Internet and intranet services visible to your users may not have a significant effect on your server's CPU utilization for three reasons: (1) your user count is low, (2) your users specified they would be using the IPX/IP Gateway intermittently, and (3) most users won't actively use traditional file service applications at the same time they're accessing the IPX/IP Gateway. Of course, all of this depends on the actual frequency of use and the type and intensity of their workloads.
Medium-Sized Workgroup Internet with T1 ISP Connection. This scenario applies to any group or organization of approximately 25 to 100 IPX clients who want intermittent access to the Internet via a T1 link to an ISP (see Figure 11).
Figure 11: A medium-sized workgroup with a T1 connection to an ISP.
Although the T1 link is the bottleneck, the IPX/IP Gateway can require significant resources in this configuration. Again, this depends on the number of simultaneous users and their workload type and intensity.
In our tests (up to 234 Gateway Clients simultaneously making back-to-back HTML requests), we first allowed up to 72 simultaneous Gateway Clients to share access of the T1 link to a remote web server. With 72 or fewer clients, response times ranged from 5 to 7 seconds--not much of an impact. However, as we increased the client count to 90 and eventually to 234, we watched HTTP response times climb into the 17 to 20 second range. We also encountered timeout events in the Navigator application.
These "stress test" results suggest that our test configuration was more than adequate to handle simultaneous requests for up to 72 Gateway Clients. In a real-world scenario, far fewer simultaneous requests will be made from a medium-sized user community.
CPU utilization by the IPX/IP Gateway and WAN routing services ranged from 75-85% at 72 clients. You'll want to make sure the server you choose to support the IPX/IP Gateway and ISP connection has sufficient resources. If an existing server can not successfully support the IPX/IP Gateway, you have the option of running the service on its own dedicated NetWare server.
For more information on connecting your network to an Internet Service Provider with a T1 WAN link, see "Connecting to the Internet from a Novell Network" on page 33 in this issue.
Medium-Sized Workgroup Intranet. This intranet scenario is designed for a group or organization of approximately 25 to 100 IPX clients who already have a NetWare server and want intermittent access to intranet services (see Figure 12).
Figure 12: A medium-sized workgroup within an intranet.
The IPX/IP Gateway in this scenario is providing a sufficiently demanding network service to warrant an in-depth capacity plan, followed by close observation after installation.
As your IPX/IP Gateway user community grows beyond 25 users and enters the range of 50 to 100 active Gateway Clients, your IPX/IP Gateway's CPU utilization will cross the 50% threshold. If your host server was operating at or below 50% CPU utilization before the IPX/IP Gateway was added to the mix, 50 to 100 active clients should not have a significant effect on the server. The IPX/IP Gateway will simply make use of your server's idle CPU cycles.
However, as you continue to add users, your server may peak in the 90% range. Operating in this range is all right as long as no other bottlenecks occur. Many servers operate consistently at 90% utilization and still provide their users optimal performance and response times. Of course, this depends on the users' workload and a few other variables. But running a NetWare server at or above the 90th percentile is not a certain indicator that the server is overburdened. Response time trends are a more accurate indicator of whether the server has adequate horsepower for the production workload.
If you continue to add users when the server is fully utilized, the CPU will eventually become the bottleneck. When this happens, response times will begin to increase and at some point users will begin complaining of a recognizable decrease in performance. This performance degradation will affect your IPX/IP Gateway's performance and the performance of the server's pre-existing workload--your users' file, print, directory, security, mail, database, and web activities. The point at which this occurs will vary with every configuration. It depends on the server's horsepower, the number of users, and their workload type and intensity.
The point is that, while the IPX/IP Gateway can gracefully co-exist on NetWare servers, you need to know the performance characteristics of an existing server before you add the IPX/IP Gateway. Only then will you know how many resources the IPX/IP Gateway can safely consume before response times increase. You will also need to monitor the system's performance until you feel comfortable with its responsiveness to the load you have designed it to support. If an existing server can not successfully support the IPX/IP Gateway, you have the option of running the IPX/IP Gateway on a dedicated NetWare server.
Dedicated IPX/IP Gateway. Some organizations have enough users to justify the installation of a dedicated IPX/IP Gateway. This dedicated service can satisfy the needs of a large department or act as a centralized service for a collection of users throughout an organization (see Figure 13). A dedicated IPX/IP Gateway is also an alternative if you don't have any existing NetWare servers that you feel comfortable burdening with the added overhead of IPX/IP Gateway services.
Figure 13: A dedicated IPX/IP Gateway with access to TCP/IP services.
In our tests (up to 250 Gateway Clients simultaneously making back-to-back HTML requests), we achieved maximum throughput with 175 Gateway Clients. The IPX/IP Gateway was running on a 200MHz Pentium Pro with CPU utilization at that maximum ranging from 90 to 100%. However, very few, if any, production IPX/IP Gateways will encounter this kind of stressful workload. Even if an IPX/IP Gateway encountered 175 to 250 simultaneous users, web browsing (which makes up an estimated 95% of Internet traffic) tends to produce sporadic requests and relatively light workload compared to our test workload.
To make this configuration easier, all IPX/IP Gateways--even those shipping with the 5-user version of IntranetWare-- include a 250 Gateway Client license. Thus you can build a dedicated 250-user IPX/IP Gateway on top of even the smallest (5-user) IntranetWare server. From a licensing standpoint, a 250-user IPX/IP Gateway can service up to 250 Gateway Clients, as long as the users are licensed somewhere within the network.
In a NetWare 4 environment, the IPX/IP Gateway authenticates users in the NDS tree so they need not be attached to the server where the IPX/IP Gateway resides. However, they must be logged into the NDS tree in which the IPX/IP Gateway resides.
In a NetWare 3 environment, a single IntranetWare server (4.11) can provide IPX/IP Gateway services in two ways: (1) if Access Controls are disabled, the IPX/IP Gateway can be located by Gateway Clients via Novell's Service Advertising Protocol (SAP) and used by up to 250 Gateway Clients, (2) if Access Controls are enabled, the IPX/IP Gateway will only service Gateway Clients whose users are logged into the Intranetware server's NDS tree.
Conclusion
Our scenario testing in the Superlab proved that, with appropriate resources, the IPX/IP Gateway can support up to 250 simultaneous Gateway Clients. We also saw the IPX/IP Gateway service small user communities with a negligible impact on the server. In fact, once we understood the performance characteristics of the IPX/IP Gateway and planned appropriately, all of the scenarios proved successful.
How you implement the IPX/IP Gateway is up to you. This AppNote has demonstrated the need for you to carefully plan for the needs of your users and the resource requirements to meet those needs with the IPX/IP Gateway.
* Originally published in Novell AppNotes
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.