I’m out in Italy this week meeting with partners and bringing them up to date with ZENworks product information, vision, roadmap and competitive information. We’ve also spoken at length about the Intelligent Workload Management ( IWM ) strategy that Novell has recently announced. One of the reasons behind the emergence of IWM is how workloads, that form business services, located on physical hardware in your data centre, virtualized in a private cloud or running in a public cloud. Regardless of where those workloads reside, they require management.
How does that relate to ZENworks?
For end points, customers want them to be managed regardless of where the configuration management workload resides. To date, this has been within the customer data center, either on hardware or virtualized. But there are many customers who don’t want to maintain yet more workloads or the hardware that they reside on for a number of reasons; they may not have the headcount or budget, they may not have the physical space or more bluntly, they really don’t want the hassle.
One answer is for configuration management workloads to be placed into a public cloud with the managed devices communicating over the internet. And for the hell of it, I decided to see how easy ( or not ) this would be with ZENworks Configuration Management.
Oh and I needed a demo system.
I selected Amazon EC cloud for no other reason than I already had an account, plus they have an offer for free inbound traffic until June 2010 so I would only pay for running the workloads at a princely sum of 0.12 cents per hour per workload.
Creating the virtual machines was straight forward using the Amazon toolset and I quickly had 3 Windows 2003 servers running with a security policy set to allow all network traffic between the servers but only http / https from outside the cloud. Final step was to allocate Elastic IP addresses to them. Elastic IP allows you to have a static public IP address + DNS name which are assigned to inidividual virtual machines within the Amazaon cloud.
Installation of ZENworks Configuration Management posed no challenges with the initial ISO download running at 2Mb/s from download.novell.com which is what you’d expect from a location with high speed links, but nice all the same.
Post installation and system update to 10.2.1, some configuration changes to ZENworks Configuration Management were required. Firstly the primary servers needed the Elasic IP and DNS details adding to them as the inventory collector is unable to detect these. This is achieved from a configuration option within ZCC.
Next is the ZENworks Configuration Management agent. An edit is required for the ZENworks Configuration Management agent so that is communicates using the Elastic IP / DNS entry of the Primary servers, rather than the internal cloud IP addresses. Another change later in ZCC and I was ready to install the agent on a device.
So with bated breath, the agent was downloaded from a Amazon cloud primary, installed and then the device rebooted.
ZCC revealed that the device was registered and had inventory information. Whoopie.
Disclaimer: None of the following are official support statements for a cloud based ZENworks Configuration Management system
Limited testing shows that bundles, policies and patches all function correctly for device based relationships as I don’t have a directory service to readily available at the moment.
So what’s the use case for cloud based ZENworks Configuration Management systems?
The initial one which comes to mind is our partners can now provide managed services, using an outsource service themselves, to customers who want the benefits of end point management but without the backend workloads to host, administer, maintain etc…
or you can have a demo system that you can access anywhere in the world