Last week I introduced some of the new concepts and architecture within ZENworks Configuration Management.
Part 2 of this series will investigate more of the architecture and some of the optimisation steps made within the Primary Server to deliver good scale and resilience.
Next week I hope to give the rules-of-thumb for scale; and some further guidelines on resilience.
Written at: GWAVACon, San Diego, CA
One major design concern related to the move to a SOA is the change in where actions are processed. This is the major function that impacts scalability and availability.
In the traditional ZENworks 7 two tier architecture model the client device processes the majority of work. This led to a distributed and extremely scalable infrastructure. Much of the scale and distributed capability were a direct result of the close integration and reliance on Novell eDirectory.
Figure 2 - ZENworks 7 block architecture
In the ZENworks Configuration Management three tier model the client is more passive and the impact moves to the application server tier – the ZENworks Primary Servers.
Significant work has been invested to make sure that these ZENworks Primary Servers deliver appropriate scale and resilience:
o Persistence, caching and ‘time to live’ of data from the database
o Database abstraction
o Database design optimization
o ZENworks Control Center access to the database via the Data Model rather than via the web services interfaces
o Enterprise Reporting via the published reporting universe
One piece of core technology under pinning the ZENworks Primary Server architecture is the use of an open-source set of technologies from the Hibernate Project. This enables database connection pooling, storage of database query results and allows the Business Logic to be isolated from the specifics of the database platform itself.
The other component that directly affects scalability is network bandwidth availability. Applications delivered via the ZENworks Configuration Management content system are passed via a servlets. ZENworks Images for OS deployment are delivered from the imaging server. Both of these functions are very scalable; in testing the network bandwidth from a ZENworks Primary Server proved to be the limited factor on scale.