ZENworks Configuration Management - scale and resilience - part 1

0 Likes
over 13 years ago

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

Architectural overview

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

clip_image002

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[1] over http or https.

clip_image004

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[2] or Secure LDAP.
    • Novell eDirectory and Microsoft Active Directory are supported
    • Optional; ZENworks Configuration Management will function without identity integration
  • Data store
    • Uses a relational database, access from the ZENworks Primary Servers is using JDBC[3] via the Hibernate[4] abstraction layer
    • Microsoft SQL Server 2005 is fully supported
    • Sybase iAnywhere server is included with ZENworks Configuration Management
    • Oracle 10g support will be added in the future
  • File system
    • The file system houses the ZENworks Package Repository
    • Used for storage of rollup logs, bundles, images and policies
    • By default installed locally on each primary server and is replicated
    • Can use a shared SAN[5] and iSCSI[6] for resilience

[1] Simple Object Access Protoco

[2] Lightweight Directory Access Protocol

[3] Java Database Connectivity

[4] Hibernate Project – www.hibernate.org

[5] Storage Area Network

[6] SCSI over IP protocols

Labels:

How To-Best Practice
Comment List
Anonymous
Related Discussions
Recommended