Cisco Blogs


Cisco Blog > Data Center and Cloud

Bridging Business and IT: The Value and Virtue of a Business Directory

According to Dr. Barry Devlin, amongst the foremost authorities on business insight and one of the founders of data warehousing, “Data without context is meaningless. It is also valueless. Without a well-understood business context, any derived information and subsequent decisions are open to multiple interpretations or, worse, misinterpretation. It is the context—and, by extension, a Business Directory that manages this context— that promotes the value and virtue of data.”

Data, Data Everywhere, Self-Service BI Can Help

Businesses that successfully leverage their data will be the leaders. Those who don’t will fall behind.

However analytics, big data, the cloud and the Internet of Everything are are drastically changing today’s data landscape. Gone are the days when business users would ask for information and wait patiently for IT to modify the data warehouse and then write the new reports.

To gain the insights required for competitive success, business users today visualize and analyze data without IT’s help using a new class of easy-to-use, self-service business intelligence (BI) tools such as Qliktech, Spotfire, Pentaho and Tableau, as well as the increasingly powerful and ubiquitous Excel.

However finding and accessing that data remains a big challenge. From the business user point of view, data lacks proper business context, thus obscuring its relevance. Instead data is too distributed, too diverse, too IT-focused in how it is described, organized, and stored.

As with self-service BI for visualization and analysis, business users today are seeking self-service approaches to finding, understanding and accessing data. This requires not only new tools that provide data in a business context, but also a new approach to business and IT collaboration.

Business Directory -- Self-Service Data for Business 

On October 1, 2014 at Data Virtualization Day 2014 in New York City, Cisco introduced Business Directory, as part of Cisco Information Server 7.0 (CIS 7.0), the latest version of our flagship data virtualization offering.

Unknown

Business Directory is the first data virtualization offering designed exclusively for business self-service. Through a business context lens, users apply search and categorization techniques to quickly find and understand the data they’re looking for. From there, they can use their self-service BI tool of choice to query it. The result is far faster time to insight which translates to better business outcomes sooner.

With Business Directory, business and IT align the people, processes and technology for competitive success. IT provides secure, curated, business-context organized data sets to the business, with business adding domain knowledge and analytic value on the path to insight.

 

Learn More

For a third party point of view on the benefits of Business Directory’s, download Dr. Barry Devlin’s recent white paper, Putting Data In Business Context: The Value and Virtue of a Business Directory.

To learn more about Cisco Data Virtualization, check out our page.

Join the Conversation

Follow us @CiscoDataVirt.

Tags: , , , , , ,

The Top Five Myths about Cisco ACI

October 22, 2014 at 5:30 am PST

It’s been almost a year since Cisco publicly unveiled its Application Centric Infrastructure (ACI). As we’ve noted in the past, ACI had to overcome a number of preconceived notions about Software Defined Networking (SDN), and without some detailed explanation, it was hard to get your head around how ACI worked and how it related to SDN. As we continue to clarify the message, there are still a number of ACI myths running around out there that we have to spend a good amount of time dispelling, so I thought I’d summarize them here. (Like Centralized Policy Management, Centralized Myth Handling can lead to greater efficiency and increased compliance. :-)).

1.      MYTH:  Cisco has limited software expertise and can’t deliver a true SDN solution because ACI requires Cisco switches (hardware) as well as the APIC controller (software).
REALITY: Cisco believes data centers require a solution that combines the flexibility of software with the performance and scalability of hardware. ACI is the first data center and cloud solution to offer full visibility and integrated management of both physical and virtual networked IT resources, all built around the policy requirements of the application. ACI delivers SDN, but goes well beyond it to also deliver policy-based automation.

2.      MYTH: ACI requires an expensive “forklift upgrade” Cisco customers must replace their existing Nexus switches with new ACI-capable switches.
REALITY: ACI is actually quite affordable due to the licensing model we use and because customers can extend ACI policy management to their entire data center by implementing a “pod” with a cost-effective ACI starter kit. On July 29, Cisco announced four ACI starter kits which are cost effective bundles that are ideal for proof-of-concept and lab deployments, and to create an ACI central policy “appliance” for existing Cisco Nexus 2000-7000 infrastructure to scale out private clouds using ACI. Customers who compare ACI to SDN software-only solutions discover that operational costs, roughly 75 percent of overall IT costs, are substantially lower with ACI — so the total cost of ownership is compelling. Along with the fact that the existing network infrastructure can still be leveraged.

3.      MYTH:  The ACI solution is not open; Cisco doesn’t do enough with the open community. 
REALITY: Openness is a core tenet in ACI design. We see openness in three dimensions: open source, open standards, and open APIs. This naturally fosters an open ecosystem as well. Several partners like F5 and Citrix already are shipping device packs for joint deployments. Customers experience tremendous benefits when vendors come together to provide tightly integrated solutions engineered to work together out of the box.

ACI is designed to operate in heterogeneous data center environments with multiple vendors and multiple hypervisors. ACI supports an open ecosystem covering a broad range of Layer 4-7 services, orchestration platforms, and automation tools. One of the key drivers behind this ecosystem is OpFlex, an open standards initiative that helps customers achieve an intelligent, multivendor, policy-enabled infrastructure. Additionally, through contributions to OpenStack Neutron with our Group-Based Policy model, we are offering a fully open source policy API available to any OpenStack user. Cisco is also working with open source Linux vendors like Red Hat and Canonical to distribute an ACI Opflex agent for OVS, and contributing the Group-based Policy model to Open Daylight.

4.      MYTH: Customers want SDN solutions for their data center networks, but ACI is not an SDN solution.
REALITY:  We believe that SDN or even software defined data centers are not the sole results customers are looking for – it is the policy-based management and automation provided by ACI that delivers tremendous benefits to application deployment and troubleshooting– and provides a compelling TCO by cutting operational costs.  Channel partners agree with us:  a recent study by Baird Equity Research surveyed 60 channel solution providers and found that they would recommend the Nexus 9000 portfolio and ACI to their customers.

5.      MYTH:  Cisco can’t compete against cheap commodity “white box” switches – they are the future of data center networks.  
REALITY:  The truth is that only a handful of companies can effectively deploy white boxes because they require a great deal of operational management and troubleshooting, which is more expensive than the upfront costs of non-commodity hardware. Deutsche Bank published a report last year titled “Whitebox Switches Are Not Exactly a Bargain” which explains how the total cost equation changes when you take into account operational costs. In addition, white boxes don’t include the rich features and capabilities that most companies want. Channel solution providers know this very well. The same Baird Equity Research study of 60 channel solution providers cited above indicated that only 2% would recommend NSX running on white-box or non-Cisco networking gear.

In the data center, “one size does not fit all”, so Cisco offers a variety of switch configurations to match customer needs. For example, customers can start with merchant silicon-based line cards and migrate to an ACI environment with ACI-capable line cards and APIC, if and when they wish.

BOTTOM LINE:  We believe that Cisco will continue to win with our partners in the data center by delivering innovation through a highly secure and application centric infrastructure.  Through training, support, and new certifications, we are empowering over two million networking engineers and thousands of channel partners worldwide to succeed with ACI in the data center and cloud.

Tags: , , , , , , ,

Application Configuration Management: What’s your Approach?

October 21, 2014 at 7:27 pm PST

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).

cisco-iac-agent-bootstrapping

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 number of Puppet or Chef servers.

Cisco IAC System Health - ACM

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.

Cisco IAC CloudSync Finite State Machine

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 give 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 -- Chef

Cisco IAC Cloud Object Model - Puppet

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.

Cisco IAC My Servers - Manage Applications - Node Classification

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

Cisco IAC CloudSync'ed Application Infrastructure

CloudSync’ed Applications

  • Integration with Puppet and Chef
    • Connections to 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
  • Multi-tenancy
    Financial Management - Application Pricing & Showback

    Financial Management -- Application Pricing & Showback

    • Tenant-specific application catalogs
    • Tenant/application consumption dashboards
  • Provisioning
    • 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

    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: , , , , , ,

Meaningful IT Automation Is The Goal

Automation was a major theme at VMWorld 2014 in Barcelona this month and it was clear that IT professionals are discovering that they can’t keep pace with business using manual provisioning and de-provisioning processes. The problem is that with the physical boundaries of time and space, there simply isn’t enough staff to meet the need. As a result, there is a renewed interest in automation at all levels of the organization, to utilize automation allowing IT to scale beyond their current capabilities.

There are a lot of solutions on the market today aimed at this problem, but you have to be careful. Many of them are point solutions, have limited coverage or functional scope.

Cisco has been talking about automation for years and their approach is to deliver heterogeneous management – because your data center is heterogeneous. These tools allows your subject matter experts to transfer their knowledge into automated workflows allowing your business to respond to market changes faster than ever before. Meaningful automation that spans your enterprise with unified management allows you to manage your data center as an interrelated whole. Read More »

Nexus 9000/7000 Series Switches No Longer Vulnerable to Shellshock Bug

What is Shellshock?

Recently a bug called Shellshock was discovered that could potentially allow remote attackers access to Linux, Unix, and Mac OS X operating systems. This bug, also called Bash Bug because it exploits vulnerabilities in the bash shell of *nix based systems, is rated a 7.5 on the Common Vulnerability Scoring System, the highest score a bug may get. It also has a low difficulty rating making it a very serious vulnerability.

How Does it Affect Nexus 9000 Series Switches?

Cisco Nexus 9000 switches are not vulnerable out of the box. The NX-OS image includes a version of bash that is affected by the Shellshock bug. In order for this vulnerability to be exploited a user must successfully SSH into a switch and successfully log in. The Common Vulnerability and Exposure IDs for these vulnerabilities are:

  • CVE-2014-6271
  • CVE-2014-7169
  • CVE-2014-6277
  • CVE-2014-6278
  • CVE-2014-7186
  • CVE-2014-7187

Shellshock could potentially allow attackers to log in to the switch and send remote commands to attack the network or possibly set up attacks for later exploitation. However, as long TACACS or local authentication has been used to secure the login, the vulnerability is not exploitable. Nexus 9000 Series switches can run in NX-OS mode or ACI mode. The bug affects all current releases of the NX-OS mode image for the Nexus 9000 Series. The ACI image for the Nexus 9000 Series has been analyzed and is not vulnerable to Shellshock. Even though the ACI image is not affected, it does now contain a patched version of the bash shell as well.

Shellshock Fixed in Recent Patches

The Nexus 9000 NX-OS team was one of the first, if not the first, in the networking industry to fix these issues with hot patches. Hot patches that fix all six of the above listed CVEs have been released by Cisco for the existing NX-OS software and Guest Bash Shell. These patches are currently available for download from http://software.cisco.com/download/navigator.html

There’s a very helpful configuration guide posted on our website on how to perform NX-OS software maintenance upgrades (SMU) as well as using the downloadable RPM to patch the Guest Bash Shell.

Shellshock Fixes for Nexus 3000, 5000, 6000 and 7000.

A Shellshock fix has already been released for the Nexus 7000 Series in NX-OS release 6.2. For the remaining platforms, we will be providing fixes through upcoming NX-OS software releases by the end of this month.

Tags: ,