SAN DIEGO -- For enterprises kicking the tires on the OpenStack cloud management platform, there are still some...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
key ingredients missing from the current release.
These gaps include monitoring, high availability (HA), business continuity (BC) and integration with existing user management systems, as well as issues with upgrade support and documentation, according to attendees and presentations at this week's OpenStack Summit.
Monitoring is a key pain point for James Penick, an architect at Yahoo Inc., which is looking to deploy tens of thousands of nodes on OpenStack by 2014. "There are solutions out there you can pay for," he said, "but that's a huge gap in OpenStack right now."
Storage monitoring that's up to par with existing enterprise tools is also a missing element, according to Pete Johnson, an engineer at Hewlett-Packard Co. (HP). For example, if users today want to get the average age or size of objects in a Swift storage container, that information has to be gathered through individual queries; that process needs to be raised to the level of existing storage management tools used in enterprises, Johnson said.
Enterprises, however, shouldn't necessarily hold their breath waiting for low-level monitoring to become part of core OpenStack.
"It doesn't really make sense for us to build it," said Josh McKenty, OpenStack Foundation board member and CEO at Piston Cloud Computing Inc. "But we're also hard-pressed to pick which [existing open source monitoring tool] to include."
In his previous role at NASA, McKenty's team used multiple open source monitoring tools -- namely, Nagios, Munin and Ganglia -- to monitor different elements of OpenStack.
HA and DR: OpenStack hot potatoes
High availability and BC are two more areas of debate as to who should build which features for OpenStack. Right now, users are encouraged to integrate existing open source tools, such as the HA Pacemaker utility or DRBD [Distributed Replicated Block Device], an HA clustered storage file system.
But not everyone trusts these tools. "There are lots and lots of open comments [on them] and things [about them] that can break," Yahoo's Penick said.
While HA might be a no-brainer for enterprises, it might not be such a natural fit for OpenStack, which is focused on newer cloud-based applications that design for failure rather than requiring HA from the underlying infrastructure. Enterprises are also expecting integration into existing environments for user management, according to HP's Johnson, which means integration with Active Directory and Lightweight Directory Access Protocol (LDAP).
There are four packages for Active Directory integration currently submitted to OpenStack for future releases.
Database changes and documentation shortcomings
The rate of change in OpenStack in the two years it's been developed has been tricky to keep up with, Penick said. For example, there have been changes to the Nova database schema between the Essex and Folsom releases that streamline queries but also hinder upgrades.
"I absolutely don't disagree with changing [database] schema between revisions," he said. But converting between the Essex schema and the Folsom schema is easier said than done.
Currently, there are no tools to do this conversion.
"OpenStack cloud operators have to write the tools necessary to make this happen, do it by hand, or do nothing at all," Penick said. "I spend a good amount of time speaking with other OpenStack operators, listening to their stories," he said. "More than a few have answered the 'How do you upgrade?' question by saying, 'We don't. Build a new cluster. Tell everyone to recreate their VMs.'"
Another area of change between Essex and Folsom that's tripped up some users has been the extraction of block storage, previously known as Nova Volumes, into a separate application programming interface called Cinder.
"It used to be that data about volumes and instances could always be found in the same database," McKenty explained. Some users "cheated," in McKenty's words, creating certain method calls around that assumption, which no longer applies.
Finally, users are calling for better high-level documentation, which would be particularly helpful in troubleshooting problems for infrastructure operations teams, said one developer working as an independent contractor with a major European telecom. "If there's something wrong, you still have to find what's wrong," he said. "It's easy for me as a developer to look at the code, but it's not that easy for infrastructure operations people."
The OpenStack Foundation plans to publish documentation of this nature soon, McKenty said. Piston Cloud also offers an "OpenStack 101" white paper.
Beth Pariseau asks:
How important is it that low-level monitoring and high-availability features are part of OpenStack's core code?
0 ResponsesJoin the Discussion