In order to calculate what infrastructure is required and where it should be located, you need to plan for the scalability of ZENworks.Based on the connection information, the number of ZENworks Primary Servers and Satellite devices needed to support thousands of devices can be calculated. The important things to consider when designing your ZENworks infrastructure include the following:
Each Primary Server must be connected to all other Primary Server, the database, and the user source by LAN speed or close links. Placing Primary Servers behind strong links allows for content synchronization, credential verification from the user source, and access to the ZENworks Database Server to occur quickly and efficiently. Performance suffers, including response times when you use ZENworks Control Center (ZCC) to perform administrative tasks, if there are any barriers or slow links between Primary Servers and the Database Server.
IMPORTANT:The Primary Server and the Database server MUST be connected by a low-latency, 100 Mbp/s or higher connection to ensure proper operation. Micro Focus does not support anything slower than this and recommends a 1 Gbps connection between the Database and its attached Primary Servers.
The following scale assumptions can be made when building the design of the infrastructure. These actual scale assumptions might be different based on the services you are providing and how you break up the services across multiple servers.
ZENworks Primary Server: A single ZENworks Primary Server can provide all ZENworks services (content, collection, authentication, and configuration) for as many as 10,000 devices in a ZENworks Management Zone. For planning, Micro Focus recommends the following:
A Primary Server for the first 5,000 devices
Additional Primary Servers for more than 5,000 devices at a rate of 10,000 per Primary Server
Thus, an organization with 15,000 devices would require a minimum of two Primary Servers.
This is general guidance. Depending on how Primary Servers are used, and based on the hardware specifications in your environment, you might see variations in the number of devices that a Primary Server can support. For additional details on how these figures can change, and what you need to consider to ensure that you are scaling to meet the needs of the organization by building a proper design, and tuning your Primary Servers to perform at an optimal level, see Scaling Primary Servers in the Real World. Understanding the scalability of the individual components that make up the ZENworks infrastructure is very important. You need to understand the limitations and where you can expect to see performance degradation to ensure that you build an infrastructure that can perform well, regardless of the load that your end-user community places on it.The first area that you need to consider is the scalability of the Primary Server. It is important to design your Primary Server placement based on the information that you collected during your assessment phase and what you anticipate your overall design will require. You should design your infrastructure so that there are always Primary Servers available to service devices and the administrators that are managing the system.
The main physical factors that govern the scalability of the Primary Servers are as follows:
CPU: The number of processors/cores and the speed will have an impact on the number of operations that a CPU can handle simultaneously.
RAM: Majority of the operations are performed by zenserver and zenloader. Each of these services can consume the appropriate amount of RAM, based on how you have tuned the server.
Disk I/O: Disk I/O is used when serving content for applications and updates.
Network I/O: Network I/O can become a bottleneck when a device is serving a large number of content requests or clients. If you face this issue, consider using NIC teaming to improve network I/O.
The minimum hardware recommendations are listed in the Primary Server Requirements
section in the ZENworks Server Installation
. If you can provide hardware that exceeds these recommendations, your system will perform better. Additional processing power and faster drives can make the systems more responsive. For example:
Using a quad core processor, which is almost a minimum standard these days.
Using 16 GB RAM (recommended)
Allocating as much disk space as you can (such as RAID 5 with separate physical drives to separate content and ZENworks from the OS)
You also need to consider the following requirements:
Device refresh frequency
Number of Primary Servers being used to deliver content to the managed devices (software, policies, images, patches, inventory collection, and so forth)
Number of administrators who have access to ZENworks Control Center
Frequency of uploading content in the ZENworks Content Repository
Number and frequency of reports run by administrators
Whether the server (JVM/HTTP) is tuned to perform at an optimal level
Amount of collection (inventory, messages, status, audit) getting uploaded from managed devices.
Number of subscriptions being performed or provided.
Number of users logging in to the devices or querying the server, almost simultaneously.
Scalability is achieved through the proper placement of services, a well thought-out design, and the proper configuration of services within the ZENworks system itself.
For example, even though a Primary Server can manage 10,000 devices, you should never deploy only one Primary Server in a 10,000-device environment. In fact, the rules have changed a little for this type of scenario. For this situation, we recommend the following as a starting point:
Two Primary Servers to manage the load and build a system that is fault tolerant
A dedicated Database Server using Oracle or Microsoft SQL Server
This system should be further enhanced by considering the following:
Using a ZENworks Server Group or an L4 switch to manage fault tolerance and load balancing.
Using DNS and aliases for managing the load placed on Primary Servers during deployment and registration.
Using Closest Server Rules in ZENworks locations or network environments to designate certain servers for specific functions (for example, content and collection), and to exclude servers from specific functions or all functions. If a Primary Server is not listed in the Closest Server Rule of a location for a particular role, then devices do not attempt to connect to it for that feature.
Using a dedicated Primary Server or Satellite Server for imaging.
Using a dedicated Primary Server for ZENworks Control Center. This is done mainly to control where the administrators upload content to ensure that the load is dedicated to a single Primary Server.
Using Satellite devices for the distribution of content.
Primary Servers are the heart of your ZENworks environment. You want to protect these systems from major disruption. Primary Servers can be used for distribution of content, but this needs to be factored into your design.
Some of the major factors that you need to consider with ZENworks and Primary Servers are as follows:
Each Primary Server can handle many concurrent connections based on the amount of RAM installed. For more information about tuning a Primary Server, see Tuning the ZENworks Primary Servers.
Each Primary Server can manage up to 10,000 devices that are registered with the ZENworks Management Zone.
A ZENworks Management Zone can scale to 40,000 devices when using either Microsoft SQL Server Standard or Enterprise, or Oracle. A ZENworks Management Zone can scale up to 100,000 devices when using Oracle Enterprise (with partitioning). For information about partitioning, see Oracle Enterprise with Partitioning.
We also recommend that Primary Servers and the Database Server be on the same network, in the same data center. We do not recommend spanning WAN links with Primary Servers because replication of the Content Repository can cause utilization issues. Placement of services in a multi-site environment is done by utilizing the Satellite role, which is discussed in more detail in Scalability of Satellite Servers.
When you configure Satellite devices, consider the following:
Currently, Satellite devices are primarily designed to reduce the load on the network, not to reduce the load on the Primary Servers, although they do this as well to a certain degree.
Consider a scenario in which a Primary Server is located at Site1 and 10 managed devices are located at Site2. Site1 is connected to Site2 over a WAN or a slow link. The managed devices are on a LAN or a high-speed link. If you do not choose to configure a Satellite at Site2, then each managed device must traverse the network to get content from the Primary Server. If you choose to configure a Satellite Server at Site2, then only the Satellite traverses the network to get content from the Primary Server and all the managed devices get the content that is locally available at the Satellite. This example can be further expanded by introducing a Site 3 that talks to Site 2. You can configure a Satellite Server at Site 3 to talk to the Satellite Server at Site 2 in order to get content (and other information), rather than have to go all the way back to a Primary Server at Site 1.
In other words, use Satellite Servers to the fullest.
Bandwidth calculations are based on ZENworks having access to a known percentage of the total bandwidth for a given link.
Satellite devices should be located at remote sites in order to provide content local to devices on the local network.
Depending on the Satellite Server hardware you use, you can plan on servicing a different number of devices. For planning, consider the following:
Server-grade Satellite Servers: A single ZENworks Satellite Server (dedicated server) can provide content services for as many as 1,000 concurrent devices.
This is not real-world. See Satellite Scaling in the Real World for additional details on how these figures can change and what you need to consider to ensure that you are scaling to meet the needs of the organization.
Workstation-grade Satellite Servers: A single ZENworks Satellite (dedicated workstation) can provide content services for as many as 250 concurrent devices.
This is not real-world. See Satellite Scaling in the Real World for additional details on how these figures can change and what you need to consider to ensure that you are scaling to meet the needs of the organization.
The second area that you should carefully consider is the scalability of the Satellite Servers. Satellite Servers are primarily designed to reduce the load on the network, not to reduce the load on the Primary Servers. Satellite Servers help reduce redundant traffic, load, and utilization from the WAN. Even if devices are located at a remote site, they connect to the central site to check with the Primary Servers if there is any work to be done. The actual work should be performed with remote Satellite devices strategically placed to service work requests from managed devices
The major factors influencing the scalability of Satellite devices include the following:
Disk I/O and the requests that the Satellite device is concurrently managing
Size of the subnets and their respective network speed
Services that the Satellite device is performing (imaging, inventory collection, and distribution)
Disk capacity (the Satellite device must have enough capacity to cope with the required content)
Physical memory (RAM) installed on the Satellite device
Number of managed devices that the Satellite device is managing
Frequency of distributions and the number of concurrent connections
Whether inventory collection or software distributions are randomized
Whether an L4 switch fronts the Satellite devices at a particular location
Whether Satellite device groups are used
Class of hardware (server-class hardware performs better than workstation-class hardware)
Class of operating system (a Satellite device running on a Windows server can handle more requests and workload than a Satellite device running on Windows XP or Windows)
Keeping these factors in mind, you should build your design to manage the known devices and estimated ongoing workload.
Each organization is unique and has very different needs when it comes to managing devices at a remote site, but it is safe to assume that by performing the following tasks, you can achieve the level of scalability that you need:
For larger sites (more than 250 managed devices):
Have a dedicated Satellite device for imaging purposes.
Have a dedicated Satellite device for inventory collection if the collection frequency is high. In other words, if you are collecting daily, you want the server to be dedicated; if you are collecting monthly, you can collapse this service into another Satellite device on-site.
Have a dedicated set of Satellite devices for software and patch distributions if the frequency of distributions is high. You want to randomize the distribution of software and avoid a massive number of devices hitting the Satellite device at the same time.
Randomize the refreshes of managed devices at the site with Satellite devices.
For smaller sites (fewer than 250 devices):
Have multiple Satellite devices that share the load and responsibility.
Do not be significantly concerned about designating specific servers for specific functions.
Randomize the refreshes of managed devices at the site with Satellite devices.
Each ZENworks Satellite has to be tied to a defined parent Primary Server. This is done when you select a Primary Server in the Server Hierarchy snapshot and select Add Satellite Server. The Satellite’s parent Primary Server is used as follows:
For the Content role, the parent Primary Server acts as a safety net to make sure at least one Primary Server in the system has all the content its child Satellites might need. To enforce this, if you attempt to include a bundle or policy to a Satellite Server, the system automatically checks to ensure that it is also included on the parent Primary Server. If not, you will be prompted to add it to this server. Prior to ZENworks 11.2.3a, parent Primary Servers were the only servers that a Satellite Server would pull content from. However, in later versions you can now choose to have the Satellite Server use its closest server rules to retrieve content.
For the Imaging role, the parent Primary Server acts as the configuration server for imaging requests. When a device PXE boots from its local imaging server, it is necessary for the Satellite Server to make configuration calls to some Primary Server. In ZENworks these calls are always directed to the parent Primary Server.
For the Collection role, the parent Primary Server acts as the target for collection roll up. When a Satellite Server receives content and then rolls it up, it always rolls the content to the parent Primary Server.
The parent Primary Server has no impact on the Join Proxy or Authentication server roles.
There are several different roles that servers in the ZENworks environment can perform. Primary Servers always have the capability to act in all roles, while Satellite Servers can perform only a limited set of roles. The following table lists the roles and indicates which devices can perform that role.
|
Role |
Description |
Types of Servers |
|---|---|---|
|
Configuration |
This role is responsible for reading configuration metadata, such as bundle information and policies, from the ZENworks Database. |
Primary Servers |
|
Content |
This role is responsible for providing the actual file contents required to install bundles and updates, as well as apply policies. Content is automatically replicated to the Satellite Servers based on assignments. |
Primary Servers Satellite Servers |
|
Collection |
This role is responsible for collecting inventory data from clients and then rolling that data up to either a Primary Server or the Database. |
Primary Servers collect and store in the database. Satellite Servers collect and forward to the parent Primary Server. |
|
Authentication |
This role performs an LDAP bind or Kerberos 5 request to authenticate the end user to the attached user source. |
Primary Servers Satellite Servers |
|
Imaging |
This role provides Proxy DHCP, TFTP, and ZENworks Imaging services. |
Primary Servers Satellite Servers (must be able to contact Primary Servers for work to do check) |
|
Join Proxy |
This role is used to provide remote management behind a NAT. Both the managed device and the administrator’s PC must be able to reach this device. |
Primary Servers Satellite Servers |
As indicated in the table above, a majority of roles can be hosted by a Satellite device. The ZENworks Authentication role was previously restricted to ZENworks Primary Servers. However, the role has been available on Satellite devices from ZENworks 10 SP3 Configuration Management or later. Configuring the Authentication role on a Satellite device allows for additional connections to be made to an eDirectory or Active Directory user source through a device that is local to the devices at a given location. For example, a customer using eDirectory will most likely create partitions dedicated to the resources for a given site and store a replica of the partition on a local server.
If a remote site has a local Directory server with LDAP enabled, a Satellite device can be configured with the Authentication role so that the authentication process can occur locally on the LAN. The authentication process is as follows:
The user authenticates to eDirectory or Active Directory as part of the Windows logon process.
The credentials are intercepted and passed to a ZENworks server hosting the Authentication role.
The Authentication server searches for the user in the user source via LDAP(s). This information is used to determine the policies and bundles that should be applied for users, based on their location in the directory and their group memberships.
The process of configuring local Satellite authentication is as follows:
Define an additional connection to the User Source.
Assign the User Source Connection to the Satellite device.
For more information on how to configure Authentication Satellites, see Authentication Role
in the ZENworks Primary Server and Satellite Reference.
As a part of your design, you will need to determine the database platform that you want to use and how to configure that database. In most cases, this will be dictated by two factors. First, whether there are existing database licenses and DBA skills in your organization and second, the number of devices you expect to manage with ZENworks. The high-level guidance for ZENworks administrators is as follows:
If you have 1,000 or fewer devices, you can safely use any of the database options available, including Microsoft SQL Server or Oracle.
If you have 1,000-5,000 devices, you can safely use any of the external database options.
If you have 5,000-40,000 devices, you can use Microsoft SQL Server or Oracle.
If you have more than 40,000-100,000 devices, you need to use the Oracle Enterprise Edition (with partitioning). For information about partitioning, see Oracle Enterprise with Partitioning.
For more information about database sizing and scaling see, Section II, Database Administrator.