ZENworks Middle Tier Server: Any Time Anywhere And Always On
Articles and Tips: article
01 Oct 2003
You've probably heard the standard marketing blurb about ZENworks for Desktops 4. You know the blurb I'm talking about: "ZENworks for Desktops 4 reduces desktop management costs and increases user productivity." Novell uses this blurb a lot for good reason. This simple sentence conveys the essence of what's cool about not only ZENworks for Desktops 4 but all versions of ZENworks for Desktops.
"ZENworks for Desktops 4 reduces desktop management costs and increases user productivity."
What's cool about ZENworks for Desktops 4 specifically is that it doesn't require Novell Client 32. (See Managing Pure Windows Desktop Environments with Novell ZENworks for Desktops in the May/June 2003 issue of Novell Connection.) Consequently, with ZENworks for Desktops 4, you can manage desktops and notebooks for more users in more places-at work or on the road. That is, with ZENworks for Desktops 4, you can distribute, configure, update and troubleshoot desktop and laptop software not only across your network for users inside your firewall but also over the Internet for users outside your firewall.
This new ability is made possible in part through an equally new ZENworks architectural element: the ZENworks Middle Tier Server. The ZENworks Middle Tier Server is software that you install on one of two server platforms:
A NetWare 5.1 or 6 server running Apache Web Server
A Windows 2000 server running Microsoft Internet Information Server (IIS)
Once installed, the ZENworks Middle Tier Server software modules plug into the Web server software, acting as a Web service. This Web service enables users inside and outside of your firewall to access Novell eDirectory as well as a NetWare and Windows file system. The ZENworks Middle Tier Server resides between eDirectory and your ZENworks for Desktops Management Agents (hereafter called Agents). These Agents must be running on every workstation where you want to deploy ZENworks for Desktops 4 functionality.
Because many Desktop Management Agents may be directed to the same Middle Tier Server, its performance and availability is critical. To avoid any potential problems, you need to understand the Middle Tier Server. Understanding the Middle Tier Server enables you to anticipate possible bottlenecks. With the help of a few simple configuration tips (described herein), you can prepare your server or network to better deal with potential problem areas.
Understanding the Middle Tier Server
The Middle Tier Server supports the Agents running on the workstations in a ZENworks for Desktops 4 environment. As with network clients, Agents need to authenticate to eDirectory and to retrieve policies and applications for the workstation and user. The Agent manages to do so by requesting this information from the Middle Tier Server via XML requests.
In response, the Middle Tier Server retrieves the information from eDirectory or from the file system and then returns the retrieved content to the requesting Agent using either XML or file transmissions through WebDav or HTTP.
Middle Tier Server and the File System
Agents resolve file references using one of three possible resources:
Novell Client 32 (if a drive mapping is referenced and this client is present on the workstation)
Microsoft Client (if a drive mapping is referenced and this client is present on the workstation)
Middle Tier Server
When an Agent wants to retrieve a network file and the file reference is a mapped drive, the Agent routes its request through the client to the file system. (See #2 in Figure 1.)
Figure 1
If a file reference is not a mapped drive, then the Agent routes its request through the Middle Tier Server. (See #1 in Figure 1.) The Agent passes the Universal Naming Convention (UNC) path to the Middle Tier Server, which then uses this path to retrieve and return the requested file to the requesting Agent.
This is the procedure for any file except an .msi file. As you probably know, .msi extensions denote installation packages created by the Microsoft Installer application. Agents handle .msi files differently than they handle other files because Microsoft Installer does not understand how to communicate through the Middle Tier Server. As a result, when an .msi file is referenced, the Agent passes the UNC path to the .msi process, which uses the Microsoft Client to make a connection and retrieve the files.
If you want to provide .msi-based applications to users who do not have the ability to connect to the file server holding the .msi file, you must set the force-cache flag for the MSI application object. The force-cache flag causes the ZENworks Application Launcher to immediately request the .msi files through the Middle Tier Server and store the retrieved .msi files in the local workstation's cache. When the application is launched, the Microsoft Installer process is called, passing the local path to the .msi files in the cache.
Middle Tier SERVER and eDirectory
The Middle Tier Server enables users to authenticate to eDirectory. To do so, the Agent first establishes a connection with the Middle Tier Server, which then establishes a connection to the eDirectory server.
To communicate with the Middle Tier Server, Agents open an HTTP connection to this server's Apache or IIS platform. (See Figure 2.) This connection is a standard connection that is terminated when the communication between the workstation and the server is complete.
Figure 2
However, to provide continuity between HTTP connections, the Apache server or IIS platform on which the Middle Tier Server software runs creates a session cookie that the workstation and server subsequently use. The Middle Tier Server terminates this session when the user logs out of eDirectory. Further, this session automatically terminates when no communication has transpired between the workstation and server for the length of time specified in the parameters you configure on the Apache server or IIS. Traditionally, these parameters dictate that sessions terminate when no communication has transpired for 15 minutes.
To enable the user to authenticate to the network, the Middle Tier Server establishes a connection to eDirectory. Because the cost of creating this connection is high, the Middle Tier Server maintains this eDirectory connection only for the length of a session rather than for the duration of an HTTP connection. When a session is terminated (either because it timed-out or because the user logged off of eDirectory), the Middle Tier Server puts the eDirectory connection into an avail-pool, which the server may use to establish a connection for another user. If this connection is not used within five minutes, then the Middle Tier Server tears it down.
Configuration Tips That Ensure Adequate Performance
Armed with this understanding of how the Middle Tier Server communicates with Agents and eDirectory, you are now in a better position to anticipate potential bottlenecks that might affect performance.
Several factors can impact the performance that a Middle Tier server can provide, most notably the following:
Speed and number of CPU processors on the Middle Tier Server
Connectivity speed between the Middle Tier Server and eDirectory
Amount of data to push to each user and workstation, particularly force-cache applications and policies
Staggered login times and launcher refresh intervals
To improve the performance and availability of your Middle Tier Server, address the potential bottlenecks implied by the aforementioned factors.
For example, if you have only a few users accessing a single Middle Tier Server and find that the Server performance is not up to snuff, start by scaling up, that is, upgrading the hardware on the Middle Tier Server. (For more information, see Scaling Up and Scaling Out: Their Effect on Performance and Availability.)
If performance again slows as more users access this same server, consider increasing the speed of the connection between the Middle Tier Server and eDirectory.
Scaling Up
Novell conducted a series of tests in its SuperLab to test the affect that scaling up a Middle Tier Server can have on its performance. (For more information, see Testing the Results of Scaling Up.)
The results revealed that the ability of the Middle Tier Server to perform adequately depends, as suspected, on the CPU speed, the connection speed and data volume:
When the ZENworks team increased the speed of the CPU, the Middle Tier Server was able to handle significantly more Agent connections and better handle content delivery.
When the team reduced the connection between the Middle Tier Server and eDirectory server from 1 Gbps to 100 Mbps, this connection, expectedly, became the bottleneck. Although the Middle Tier Server successfully supported all of the Agents, the login times increased dramatically.
When the file server hosting the applications being delivered was running on the same machine as the primary eDirectory server, the team observed more failures during authentication. Moving eDirectory to a separate server improved the logging performance level.
Connecting at Random Intervals
You can reduce the load on (and therefore improve the performance of) an individual Middle Tier Server by enabling Agents running on workstations with LAN connections to retrieve application data from a local file server.
To accomplish this, begin by configuring a mapped drive on the local workstation. Thereafter, the application objects delivered to that workstation can reference that mapped drive to retrieve the application files.
However, this option is available only to those workstations with LAN connections. Workstations that are not connected to the LAN but instead retrieve information over the Internet must receive their distributions through the Middle Tier Server.
In these cases, you can help ensure adequate performance by putting to use the Random feature of the ZENworks Application Launcher. Using this feature, you can direct these workstations to connect to the Middle Tier Server at random intervals during a specified period of time and, therefore, better enable the Middle Tier Server to respond at adequate performance levels. Doing so will limit the number of users connecting at the same time (for example, first thing in the morning).
Scaling Out
Sending fewer users to a single Middle Tier Server predictably assures adequate performance levels. To accomplish this, add more Middle Tier Servers and direct different Agents to different Servers.
A registry key maintains the Domain Name System (DNS) name or IP address of the Middle Tier Server that Agents should use to contact the Server. When you are installing the Agent software, you can set this address differently for different sets of users.
Configuration Tips That Improve Availability
Adding more Middle Tier Servers to your network also can improve the availability of Middle Tier services. When you have more than one Middle Tier Server, use DNS round-robin addressing techniques or an L4 or higher switch to ensure that you get the most from your multiple servers.
Round-Robin Addressing
As you introduce more Middle Tier Servers into your network, use DNS round-robin addressing techniques to associate several IP addresses for a given DNS name.
With DNS round-robin addressing, when a client or Agent requests the IP address of a given DNS name, the DNS server can return one of several IP addresses. For example, you can configure your DNS server such that a single DNS associated with Middle Tier Services directs clients and Agents via IP addresses for several different Middle Tier Servers. When a client or Agent connects to one of the Middle Tier Servers, it uses that Server until the session is terminated.
Be warned, however: Round-robin DNS addressing has limitations. A DNS server configured in this way cannot detect when one of the servers associated with a given DNS name is disabled. This inability to detect a downed server can affect performance and availability of Middle Tier services.
Web Switching
Alternately, you can use an L4 or higher switch, a scalable solution that improves the availability of your Middle Tier services.
A switch can provide access to several servers being referenced by the same IP address. In this case, Agents can reference the same IP address but be routed to different physical Middle Tier Servers.
Using a switch improves upon the benefits provided by the DNS round-robin addressing technique. In addition to enabling you to route different Agents to different Middle Tier Servers, a load-balancing switch is aware of the loads of each server and can use that knowledge to distribute requests to the server best prepared to handle them. Load-balancing switches are also capable of detecting when a server is disabled and accordingly route requests to a different, fully-functional server.
A few good tips
Scaling up and scaling out can ensure adequate performance and availability of Middle Tier services. However, even with hardware improvements and more servers, you need to properly configure your Middle Tier Server and its environment to ensure respectable performance and availability.
When preparing your network for the Middle Tier Server, remember these performance and availability-enhancing tips:
Increase the CPU speed on your Middle Tier and eDirectory servers.
Run your Middle Tier Server software and primary eDirectory on two separate machines.
Increase the connectivity speed between the Middle Tier and eDirectory servers.
Direct Agents running on workstations with LAN connections to file servers (rather than the Middle Tier Server) for data.
Direct Agents running on workstations without LAN connections to connect to the Middle Tier Server at random intervals to minimize the number of simultaneous user logins.
Add more Middle Tier servers to limit the number of users connecting to any one server.
When you add more Middle Tier servers, improve availability by using either a DNS round-robin addressing technique or an L4 or higher switch.
Scaling up and scaling out
Their effect on performance and availability.
In standard industry jargon, scalability is defined as the ability of a hardware or software product to adapt to increased demands while working accurately and adequately. Scalability can also refer to the ability of a networking solution (comprised of several hardware and software products) to provide a constant, acceptable performance level even as the load or demand on this solution increases.
In a networking context, marketers and press members alike also frequently transform scalability into a verb form, as in scale up or scale out.
Scale Up is the process of adding hardware to a server in the form of processors or memory, for example.
Scale Out is the process of adding servers to share an increasing load.
Remember that as with the scalability of a product, scaling up and scaling out does not necessarily mean you will improve performance. Instead, whether you're scaling up or out, your main goal is to maintain an adequate performance level in the face of an increased load.
A secondary goal might be to improve availability. Availability refers to the accessibility of a resource. The higher the availability of a resource, the greater the likelihood that users will be able to access that resource-consistently.
Scaling up provides same or even better performance and might improve availability. However, when you scale up you upgrade a single server, which means a single point of failure still exists.
By scaling out, that is, adding more servers, you can better improve the availability of resources such as the Middle Tier Server.
Testing the results of scaling up
Middle tier server.
To test these and other suggested solutions to potential bottlenecks in a Middle Tier Server configuration, the ZENworks team at Novell took the Middle Tier Server to the Novell SuperLab. In the SuperLab, the ZENworks team pointed more than 1,000 workstations to a single Middle Tier Server, which the team pointed to an independent eDirectory server.
Baseline Performance Testing
To establish a baseline performance level, the ZENworks team configured the SuperLab workstations to perform a rolling login to a NetWare 6 Middle Tier Server and then to a Windows 2000 Middle Tier Server. That is, every minute, approximately 60 workstations logged into the Middle Tier Server until all workstations had logged in. They ran the test twice: Once with the Middle Tier Server running on NetWare 6, and a second time with the Middle Tier Server running on Windows 2000.
For this test, the hardware for the Middle Tier Server and eDirectory server was identical: Each of these machines was equipped with two Pentium III, 1.13 Ghz processors and 2 GB RAM. The team secured a 1 Gbps connection between the Middle Tier and eDirectory servers. The NetWare 6 server was running Apache, which supports only one CPU. The Windows 2000 Server was running IIS, which supports multiple processors.
In the first of two tests, each workstation logged into the Middle Tier Server, authenticated as a user and delivered and launched approximately 3 MB of data (policies and applications).
As shown in Figure 3, in this hardware configuration, the NetWare 6 Middle Tier Server supported 600 workstations logging in and downloading (via ZENworks Application Launcher) the 3 MB of data within one to two minutes. (See Figure 3.)
Figure 3
The Windows 2000 Middle Tier Server supported only 300 workstations under the same circumstances.
In the second test (performed in an identical lab configuration), the workstations again performed a rolling login. However, in this test, the Agents simply logged in to the Middle Tier Server without delivering or launching any data at login time.
Without the additional data to download to the Agents, the NetWare and Windows servers were each able to support the 1,000 workstations and login time improved.
Scaling Up
Next, the ZENworks team tested the performance effects of scaling up a Middle Tier Server. In this test, the Middle Tier and eDirectory servers were scaled up to two Pentium IV, 2.6 Ghz processors (with HyperThreading activated) and 2 GB RAM. The team first tested this scenario using a 100 Mbps connection between the Middle Tier and eDirectory servers.
In this test, each of 740 workstations logged in to the Middle Tier Server, after which the system delivered a 66 MB Oracle client .msi file, distributed through the Middle Tier without caching the application.
This configuration revealed a bottleneck at the 100 Mbps connection, serving up the application in two minutes. When this 100 Mbps connection was upgraded to a 1 Gbps connection, the login times were significantly reduced to an acceptable speed: 30 to 40 seconds per login.
When the ZENworks team changed the configuration to deliver the .msi files over a mapped drive, the launching of ZENworks Application Launcher and login times again were significantly reduced, this time to fewer than 20 seconds. (See Figure 4.)
Figure 4
In this same configuration, the Middle Tier Server successfully supported over 740 Agents for each Windows 2000 Middle Tier Server.
By increasing the process speeds and the connection speed between the Middle Tier Server and the eDirectory server, the ZENworks team significantly improved login speeds and more than doubled the amount of Agents supported on the Windows 2000 platform.
* 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.