The first of a multi-part article discussing ZENworks Configuration Management and making your solution scalable and resilient.
Part 1 of this article will discuss the Architectural Overview of ZENworks Configuration Management with subsequent posts detailing resilience, scalability and SuperLab testing data.
Written at: Draper, UT
ZENworks 10 Configuration Management can be presented as a classic example of a three-tier, services-oriented architecture (SOA).
The three tiers are:
- Client-side application – ZENworks Adaptive Agent
- Application server – ZENworks Primary Servers
- Application infrastructure – database, filesystem and identity stores
Figure 1 – ZENworks 10 Configuration Management block architecture
The SOA architecture splits the different components of ZENworks – the modeling of relationships is split from the business logic; which is separate from the client component.
Key benefits include:
- Modular server architecture; can be extended quickly
- Modular client architecture; also extensible
- Clean protocols between client and application server – SOAP over http or https.
- Firewall friendly
- Known scalability and resilience options; similar to scaling out a web-server or application server farm
- Updates can be applied in a modular and controlled fashion
- Allows for a more agile product development discipline
The application server tier – the ZENworks Primary Servers – consists of a set of java servlets providing security, access control, ZENworks management functions and the ZENworks Control Center web interface.
All of the ZENworks functions are exposed via web-services – and the managed devices communicate with the primary servers using SOAP over http or https.
The web services layer communicates to an integrated business logic layer that is expressed within the various ZENworks Java servlets. The business logic determines the ‘what’ and the ‘how’ within ZENworks Configuration Management. Policies can be associated with users, groups, containers, workstations and workstation groups; whereas an operating system deployment bundle can be associated with a workstation or workstation group only.
Considerable consideration has been made to allow this architecture to be scalable, open and cross platform. One such consideration was the connectivity to the database. ZENworks Configuration Management is unique in needing to run on multiple server platforms and support a wide range of databases. A linked requirement was the need to make efficient use of the connectivity between the ZENworks Primary Servers and the shared database. To enable both of these requirements a database abstraction layer is added below the business logic layer. This enables connection pooling, query result caching and isolates the business logic from the specific nuances of the underlying database. ZENworks Configuration Management uses Hibernate to deliver this capability.
Together the Business Logic and Database Abstraction layers are known as the ‘Data Model’.
The application server tier also communicates with the storage and identity tier. This tier uses three main components:
- Identity store.
- Read-only, accessed using LDAP or Secure LDAP.
- Novell eDirectory and Microsoft Active Directory are supported
- Optional; ZENworks Configuration Management will function without identity integration
- Data store
- File system
 Simple Object Access Protoco
 Lightweight Directory Access Protocol
 Java Database Connectivity
 Hibernate Project – www.hibernate.org
 Storage Area Network
 SCSI over IP protocols