Cool Solutions

ZENworks Configuration Management – scale and resilience – part 1



By:

January 22, 2008 4:10 pm

Reads: 11180

Comments:1

Score:0

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

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Categories: Uncategorized

Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

1 Comment

  1. By:mbruner1

    There is relatively NO documentation on how to best scale Zenworks Configuration Management. I’ve googled everything possible and haven’t found any good documentation on how to scale it. The best thread I’ve come across is http://newsportal.novell.com/article.php?id=1945&group=novell.support.zenworks.configuration-management.10.server-install#1945

    Surely someone has more on this. PLEASE post part 2 soon!

    Thanks!

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)

Comment

RSS