Last we spoke, it was about network device configuration management. Let’s move our focus up the stack to applications and management of their configuration. Whether enterprise or cloud-architected, running on physical servers, in virtual machines or in containers, how are you managing your applications?
Puppet, Chef, Ansible and Salt are popular answers to this question and leading contenders for initial provisioning and management of configuration drift of data center applications – whether they be common off the shelf (COTS) or custom built applications. Two of these configuration management technologies, Puppet and Chef, are supported by Cisco Intelligent Automation for Cloud 4.1. The collection of features enveloping these two Ruby-based technologies within Cisco IAC is referred to as Application Configuration Management (ACM).
Approach to Agent Bootstrapping
Puppet and Chef are similar in nature – in more ways that we’ll discuss in this post. An example of similarity being that both of these ACM technologies require an agent (Puppet) or client (Chef) installed on the server under management (node).
Agent Bootstrapping Methods
Both types of ACM technologies support client-only and client/server deployment models, referred to as agent/master for Puppet and client/server for Chef installations. Whether only using an agent-only (client-solo – Chef) or using an agent/master deployment model, unless your virtual or physical server image has the agent preinstalled, you’ll need to go perform the prerequisite work of agent installation.
IAC performs this dirty work by bootstrapping the appropriate agent (or client) whether on initial server provisioning or on-demand on any existing server when a user assigns an application to a server. Mechanics used to perform agent installation varies. The mechanics used within IAC are listed in the “Agent Bootstrapping Methods” chart. Initially, IAC used WinRM as its mechanism to bootstrap agents on Windows severs until customer feedback drove use of an alternative mechanism – psexec. We found that customer security teams were either uncomfortable with or had policy in place against the use of WinRM as a method to execute scripts remotely and made the switch to psexec, which “is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software”.
Part of the agent installation involves establishing a connection between the ACM server (Puppet Master or Chef Server) and the node (server with agent/client installed). IAC orchestrates the registration of the node with it’s respectively, assigned ACM server. This process is different depending on whether Puppet or Chef is used. In the case of Chef, IAC has the chef-client register with the Chef server using the private key assigned to the chef-validator, which IAC loads into the node during client installation. In the case of Puppet, IAC performs an initial puppet agent run, which lodges a certificate authorization request on the Master, which IAC subsequently orchestrates the signing of on the Master. With agent bootstrap complete and authorized, secure communication between the ACM server and client, attention is turned to the management of connections IAC may have established with n number of Puppet or Chef servers.
System Health – ACM
Connection and System Health
In the case of client/server deployments, IAC will establish connection to one or more Puppet Masters and one or more Chef Servers. Each connection is treated with care as the health of each connection facilitates IAC’s ability to successfully orchestrate applications. Connections are established using a service account permissioned appropriately. The health of the connection between each ACM server is evaluated once every 30 minutes by default. Connection health is determined by performing connectivity, authentication and authorization tests. Details of these tests and a screenshot of the System Health console can be seen in the “System Health – ACM” chart.
CloudSync Finite State Machine
Cloud Object Model and CloudSync
Immediately after establishing a healthy connection, CloudSync runs. CloudSync is a synchronization process driven by a finite state machine whose responsibility is to not only perform initial object discovery and granular fingerprinting – essentially a deep interrogation of cloud objects and their attributes – but also, manage ongoing reconciliation of infrastructure changes with respect to their representation of the provider’s cloud infrastructure as modeled within the service catalog. Note the “CloudSync Finite State Machine” chart, which is laced with Extension Points, where cloud administrators may insert custom logic on state transition for any given object within the model. Once collected, this inventory (e.g. a Chef Role) is presented to the cloud administrator for the ACM server for use within their cloud. Cloud administrators may choose to register the discovered objects for use by end users.
Cisco IAC Cloud Object Model – Chef
Cisco IAC Cloud Object Model – Puppet
For example, the cloud administrator may choose to register a Puppet Role as being available for end users to assign to a server. Registration of this role may include assignment of additional metadata, including price of the role as a one-time or recurring charge for use of the application and assignment of tenant permissions (whether to make the role available to all tenants or only select tenant(s)).
It’s through the relationships derived within the Cloud Object Model and assignment of tenant permissions that the specific applications are presented to a given end user. Service Resource Containers are used as a logical construct owned by the cloud administrator wherein tenant-specific resources may be hosted. Applications delivered to tenants may be created in a virtual data center that is serviced by either a Puppet Master or Chef Server. See the Cisco IAC documentation for further details on other constructs within these and other models.
Manage Applications – Node Classification
Approach to Node Classification
Once registered for use, applications become visible to end users, who may assign applications to their servers whether during initial server provisioning or to an existing server. Upon selection of application(s) by the end user, IAC classifies the node by writing a hiera file (Puppet) or by writing a run-list (Chef) on the respective ACM server and forces an immediate agent run to ensure application configuration is promptly enforced.
In this sense, IAC provides a common user experience for node classification irrespective of the underlying technology chosen by the cloud provider (the organization running and administering IAC). As the IAC product suite evolves, so has our approach in terms of classification via Puppet and the more programmatically effective use of a custom-written External Node Classifier, taking advantage of the ability for the node_terminus configuration to to interact with an ENC.
Application Configuration Management Highlights
- Integration with Puppet and Chef
- Connections to n number of servers
- System health checks for these servers
- Application infrastructure discovery (CloudSync)
- Bootstrapping of agents (green and brownfield)
- Financial Management
- Pricing of applications
- Showback for application orders
- Run rates including application consumption by user, org, tenant
Financial Management – Application Pricing & Showback
- Tenant-specific application catalogs
- Tenant/application consumption dashboards
- Application provisioning for virtual machines, physical servers
- “My Applications” interface for application management
- Service Offering Elections
- 3-tiers of control on enable/disable application configuration management services at provider, tenant and organization levels
- Multi-Cloud Platform Support
- Support same services ubiquitously across all platforms
Financial Management – Application Run Rates
- Application User Persona
- “My Application” interface for application management
- ACM Server and application usage dashboard
Cognizant of the plethora of application configuration management tools available to Cisco customers, including commercial, open source, and homegrown tools, we’re very interested to hear which ones you have found to be the best fit in your environment. Have you established revision control practices as you manage infrastructure as code?Having reviewed Cisco’s approach within its cloud management platform, IAC, whether you manage configuration of physical servers, virtual machines or use CM to build containers or hosts that run containers, how does your approach compare?
Tags: Chef, CIAC, cisco IAC, cloud-based applications, configuration management, enterprise applications, Puppet
We have to propel new use cases for cloud because customers want more than IaaS. And they don’t want to be tied to vendors’ annual product release cycles to get it. But, as they extend cloud-based service delivery beyond IaaS and aim higher in the sky, their heads smack into the ceiling of cloud management. Naturally, they want to prevent the ensuing organizational concussion—the confusion, the fuzziness, the regrouping. So they are turning to Cisco for more flexible and extensible cloud management capabilities. Ask and you shall receive.
In a previous blog I explained how Cisco Intelligent Automation for Cloud (IAC) can scale from single to multi-cloud deployments in addition to expanding into the richer application sets. Our support for the why wait if you don’t have to philosophy has created the cloud accelerator program for Cisco IAC. Cloud accelerators prevent those concussions. They are content modules, or cartridges, that insert into the IAC framework. Developers use them to test new application capabilities and deploy them into production, all without costly architectural revisions.
Cisco now gives you two new cloud accelerators: Application Stack Accelerator and Cisco UCS Director Accelerator.
Application Stack Accelerator
This module provides a blueprint designer onto which stack designers create whole application stacks or platforms to their precise specification, allowing consumption through Cisco IAC. This accelerator mirrors the software development process, allowing:
o Blueprint creation
o Blueprint testing
o Blueprint revision based on test results
o Review and approval
o Publication for consumption
An edit-and-copy function is available when hypervisor-specific blueprints are required or new blueprints need to be created with servers in the same network zone.
Cisco UCS Director Accelerator
Managing infrastructure within the whole cloud context is a success factor for cloud. Therefore, this accelerator lets Cisco IAC discover Cisco UCS Director as a node in the cloud and then provision physical NAS storage into an existing virtual data center—specifically NetApp storage. When applications need additional capacity, cloud administrators can add it using the IAC management portal. You will hear about the integration between Cisco IAC and UCS Director and our unified management approach over the next 60 days.
Cisco has transformed cloud management and the new-release waiting game for the better.
Cisco IAC is proving that organizations no longer need to hit their head on the cloud management ceiling and risk concussion.
To learn about Cisco IAC, go here
Click here to learn more about cloud accelerators. First time visitors will need to register.
Tags: CIAC, cloud, Cloud Management, devops, netapp, ucs director, VMware
Deploying Multi-Tier Application Stacks with Puppet and Chef
In a previous Cisco Data Center blog, we announced our configuration management accelerator for cloud to enable organizations to move beyond monolithic golden templates into a dynamic TOSCA-modeled application design canvas. Cisco Intelligent Automation for Cloud (IAC) has been working for months with PuppetLabs and OpsCode (Chef) and has had multiple successful customer proof-of-concept deployments.
The Cisco configuration management accelerator provides customers with a substantial improvement over the manual process of building and implementing multiple golden templates to build multi-tier application stacks. The application stack is now described, and the description drives implementation. Changes to the description apply to all future instances, and can even update running instances in continuous delivery scenarios. The benefit is that the description becomes the master plan and machines are consistently and automatically constructed from that master plan without intervention by IT. Software defines the application configuration.
Cisco’s cloud accelerator approach is true to an open philosophy that provides customers with a choice of solutions – not locking them into a single hypervisor, configuration tool, solution path, or even hardware selection. The configuration management accelerators follow directly in the footsteps of our multi-cloud accelerator released last year. That accelerator enabled Cisco IAC to provision, orchestrate and manage VMware vCloud Director, Amazon EC2, and OpenStack. It has also been extended by customers to include Hyper-V, Azure and Rackspace through the preplanned extensibility built into it.
Read More »
Tags: apps, Chef, CIAC, Cisco, cloud, configuration, epaas, IAC, intelligent automation, paas, Puppet, TOSCA, VMware
Cisco continues to roll out innovations that will enable the next generations of multi-cloud computing. I’m a product manager working on Cisco’s Cloud Management software, and we’re all about the high-level, self-service, automatic provisioning of services that the end-user cares about. The network just moves ones and zeros, and all protocols of interest (HTTP, SSH, RDP, SQL, etc.) work fine over TCP/IP. The hypervisor takes care of putting that pesky motherboard chipset and storage bus into a black box, right? The end-user doesn’t care about that stuff, or at least doesn’t want to have to care about it.
A common perspective, except among the engineers who manage the network, is that network infrastructure is a bunch of mysterious plumbing that “just works” and how it does what it does doesn’t matter. Indeed, many vendors in the “cloud” arena would like to perpetuate this perspective on the network. They would like you to believe a bunch of dumb pipes can carry traffic and that determination of the traffic (content, flow, etc.) is determined at higher levels in the stack.
In some cases, this is true, but operating this way doesn’t unlock anything new. The model they describe would be brilliant if all of your network requirements were defined in 1998. Few companies can afford to operate technology today like they did in 1998 and remain competitive.
Cisco is announcing a new Nexus 1000V (N1KV), and this one changes the game. In brief, the Nexus 1000V is the foundation of the networking services that Cisco brings to virtual computing. The N1KV can be managed using the same NX-OS commands and practices used to manage the Nexus 5K and 7K switches, and extends network control down to the VM and virtual port into which a VM is “plugged in”, even across different vendors’ hypervisors.
The N1KV is also the platform for additional L2 and L3 network services such as those provided by the vASA Firewall, vNAM, and VSG. The new Nexus 1000V InterCloud extends this ability to cloud service providers, such as Amazon, but is “cross-provider” (in fact, it doesn’t even depend on the Cloud Service Provider). For me, in my role as a Cloud Product Manager, this is an important new addition to basic networking capabilities, and is exactly the kind of thing that Cisco can and should do in its role as “Networking Giant” to open up the promise of hybrid or multi-cloud.
I have a mental image of what this can do, and I tried to put this into images to the right. Animation would have been better, I just don’t have the Flash skills to put it together for a quick blog post. I envision a virtual machine as a ghostly “physical” server tower with network cables plugged into it. These network connections can come from end-users in a client-server model, or any of our web-and-mobile constructs. After all, we still are end-users connecting to machines. Of course, the “client” for a compute function could be another compute function, so there is a network cable coming from another nearby ghost server. These ghost servers can today float from blade to blade thanks to most mainstream virtual machine managers (VMM) and a virtual switch like the N1KV, and the cords stay connected throughout. With the new N1KV, that VM can float right out of that VMM and into another VMM (such as across VMware datacenters, or even from VMware to Hyper-V), or out to a public or hosted provider. The cord just magically uncoils to remain connected wherever that machine goes! I love magic.
The N1KV provides that cable that can float after its ethereal virtual machine. It also provides the platform to maintain monitoring by the vNAM, even as the machine moves. You simply can’t economically achieve this using basic dumb pipes. Add to this the new Virtual Network Management Console (VNMC) InterCloud management capabilities. In order for that cord to stay connected, there do have to be network switches or routers along the way that understand how to make that network cable follow the machine. VNMC InterCloud manages these devices, but adds another particularly important capability: actually moving the workload.
VNMC InterCloud adds the ability to discover virtual machines, and convert them to a cloud-provider’s instance format, move what could possibly be a fairly large set of files, and get that machine started back up in a far-away environment, with seamless network consistency. VNMC InterCloud is like a puff of wind that pushes the ghostly VM from my corporate VMWare-based cloud to float over to my hosted private cloud. Remember, ghosts can float through walls.
This is groundbreaking. Workload mobility is one of those hard-to-do core capabilities required for all of us to realize the promise of multi-cloud, and it requires a network that is both dynamic and very high performing. I’ve been looking forward to this from Cisco for some time now.
Read More »
Tags: CIAC, cloud, cloud automation, Cloud Management, IAC, intelligent automation, Intelligent Automation for Cloud, InterCloud, Nexus 1000v, orchestration, unified management, VNMC
Customers have often said to me, “Joann, we have virtualization all over the place. That’s cloud isn’t it?” My response is, “Well not really, that is not a cloud, but you can get to cloud!” Then there is a brief uncomfortable silence, which I resolve with an action provoking explanation that I will now share with you.
Here’s why that isn’t truly a cloud. What these customers often have is server provisioning that automates the process of standing up new virtual servers while the storage, network, and application layers continue to be provisioned manually. The result is higher management costs that strain IT budgets, which are decreasing or flat to begin with. With this approach, businesses aren’t seeing the agility and flexibility they expected from cloud. So, they become frustrated when they see their costs rising and continue struggling to align with new business innovation.
If your IT department adopted widespread virtualization and thought it was cloud, my guess is you are probably nodding your head in agreement. Don’t worry, you’re not alone.
So then, what are the key elements an organization needs to achieve the speed, flexibility and agility promised by cloud?
1) Self-service portal and service catalog
The self-service portal is the starting point that customers use to order cloud services. Think of a self-service portal as a menu at a restaurant. The end user is presented with a standardized menu of services that have been defined to IT’s policies and standards and customers simply order what they need. Self-service portals greatly streamline resource deployment which reduces the manual effort by IT to provision resources.
2) Service delivery automation
After the user selects services from the portal service menu, then what? Well, under the hood should be automated service delivery—which is a defining characteristic of a real cloud environment. Behind each of the standardized menu items in the self-service portal is a blueprint or instructions that prescribe how the service order is delivered across the data center resources. This has been proven to appreciably simplify IT operations, reduce costs and drive business flexibility.
Read More »
Tags: amazon, CIAC, cloud, cloud infrastructure, Cloud Management, IAC, OpenStack, process automation, Self-Service Portal, UCS, vCloud Director, virtualization