Enterprises may get a cheaper disaster recovery alternative for portions of their infrastructure, with plans on...
the Puppet roadmap to add high availability for Puppet Enterprise master servers located in separate data centers.
Puppet master servers are the central control nodes for Puppet's configuration management system, which communicate with Puppet agents running on infrastructure servers. The multisite high availability (HA) feature for Puppet masters was discussed in a presentation at PuppetConf this year. However, it wasn't widely publicized until this week's release of Puppet Enterprise 2016.5, which officially introduced Puppet master server failover within the same data center.
Puppet Enterprise customers were lukewarm on failover between co-located Puppet masters, but some were enthusiastic about the future ability to set up failover between Puppet masters for disaster recovery at multiple data center locations.
Multisite HA is also possible with long-distance vMotion in VMware's vSphere 6.0, but only as a premium feature for vSphere users with an Enterprise Plus license. VSphere 6.0 Enterprise Plus with Operations Management prices starts at $4,395 per processor with one year of support. By contrast, Puppet Enterprise Standard, which includes access to all software updates, starts at $120 per node per year.
"VMware doesn't give us HA across data centers automatically," said Rob Nelson, a Puppet user at a large enterprise that he asked to not be named.
This is a different and possibly more affordable way of solving the same problem, said Forrester Research analyst Rob Stroud. Rather than moving workloads, this would create them at a secondary data center.
"For a large enterprise, it's a different way to approach replicating and scaling workloads between multiple environments," Stroud said.
While engineers at PuppetConf didn't give a time frame for multisite HA, and the company this week declined to specify a time frame for this portion of the Puppet roadmap, Nelson said he expects it within the next few enterprise releases, or in about six to 12 months.
"As we expand into additional data center locations, we'll keep that feature in mind and adjust our designs going forward," Nelson said.
Not every Puppet Enterprise user sees this as the most attractive feature on the Puppet roadmap, however. Previously, Puppet Enterprise has supported failover through third-party tools such as vSphere HA, a tried-and-true utility that many enterprises already have in their data centers.
"We're not so dependent on the Puppet master that it must be running," said a systems engineer at a large consumer products company who spoke on condition of anonymity. "Virtualization provides enough HA for us."
Puppet roadmap delivers on single-site failover
Puppet Enterprise 2016.5 was characterized in the PuppetConf presentation as a beginning for more failover features to come. Certain technical choices, such as app-level rather than database-level replication and failover, were made to support the multisite scenario in the future, according to Russell Mull, senior software engineer at Puppet.
"We're primarily testing for the first release for the same-data center scenario," he told an audience member during a Q&A session. That feature is the headliner for Puppet Enterprise 2016.5, generally available this week.
Previously, failover between Puppet masters within the same data center could be done through manual methods that required knowledge of PostgreSQL database replication and secure socket layer certificate directory replication, according to a part of the PuppetConf presentation given by Zack Smith, principal professional services engineer at Puppet.
This month will see another Puppet Enterprise milestone -- Puppet 3 will reach end of life on Dec. 31, which leaves users to navigate a potentially complex upgrade process to Puppet 4.
At a quarterly Puppethack this week, Nelson said he saw comments that indicated a few modules were contemplating dropping Puppet 3 support right away.
"More than the lack of corporate support, this is going to start affecting Puppet 3 users who find bugs in the modules they use, but the module author is only interested in patching the version that only supports Puppet 4," Nelson said. "I did not expect to see modules start to drop that support until the new year, but I think once a few prominent modules do it, it may start a trend that forces users to choose to maintain module forks or upgrade sooner than later."
Hopefully, users still on version 3 have at least started their work to move to 4, Nelson said, "but we know there are still people using version 2, so clearly some will be staying."
Features to watch in Puppet Enterprise
Puppet puts IT department in the know
Puppet's CEO talks plans to bridge gaps