We’ve reached the 8th installment of our blog series on Cisco’s Big Data and Analytics vision (beginning with Scott Ciccone’s blog on September 23). No doubt by now you have either seen or heard about Cisco’s broad data and analytics portfolio presented at Strataconf in New York on Oct. 15. And if you missed our October 21st executive webcast ‘Unlock Your Competitive Edge with Cisco Big Data and Analytics Solutions,’ please check it out. Now you’re probably eager to know how to make the most of our approach to data analytics. How can you benefit the most—and the most quickly—from data analysis in your organization?
Customers come to us to ask for support in extracting valuable and actionable business insights from their large stocks of network data. Their goal is always to drive both operational efficiencies and new revenue opportunities. Rapid changes in the business environment increase pressure on time-to-value: savings and revenues need to be brought in as quickly as possible. But traditional ways to extract value from data, complicated by volume, velocity and variety issues, often have a very long time-to-value. In fact, data analytics consulting projects historically take a year or longer to complete. Customers get handed large scale implementation plans and, by the time the program is implemented, the wind has changed: the market opportunity has closed, and the business has moved on.
That’s why for some time now I’ve been a student of accelerating time to value for data analytics. Our job is not just to show our customers the hidden business value of their data, but also to bring that value to them fast. We have developed a rapid prototyping, iterative approach that continuously develops actionable insights from network and other sources of data. Our approach contains four steps to help our customers quickly develop, test, and implement business ideas and processes:
Step One: We start by working with customers and identify key use cases through an “Internet of Everything” iterative planning approach. Our experts don’t just present an idea, but a complete, ready-to-test hypothesis, using visualization techniques and an analytics design approach to discover new ways to do business, based on analytics insights.
Step Two: We use a rapid data extraction approach to capture the data needed to test that hypothesis. We fully leverage Cisco’s Connected Analytics platform, enabling automated data collection and simple correlations exploration.
Step Three: Once we have the data we need, we apply a data science approach to build an “analytics sandbox” in which we test the proposed use cases and measure its outcomes. We use rapid prototyping to test theories, quickly working through iterations to develop a truly working business model for our customers’ unique situations. In the process we are able to identify new insights that became the basis for the next use cases.
Step Four: The result is a set of modular Business Insights, which we interpret and thoroughly test, and turn into an actionable plan that we execute. This makes it relatively easy for our experts to integrate insights and actions into our customers’ transformation initiatives—and in a fraction of the time of traditional data-driven solutions.
The world of top down, outside-in consulting, where value comes from individuals’ experience, is gone. Value today is enabled by the capability of companies like Cisco to extract and interpret data about our customers’ core business, enabling agile decision making and rapid process transformation.
As the Internet of Everything becomes a pervasive reality, we see that analytics is what creates value from all of these connections value. To learn more about Cisco’s vision for the Internet of Everything, read Joseph Bradley’s blog on Thursday, October 23! #UnlockBigData
Tags: analytics, Big Data, consulting, Internet of Everything, unlock big data
One hundred is one of the most ubiquitous numbers in life. We see it on money, best-of lists, memorials, compilations, scoring systems, and many other benchmarks. Cisco Unified Computing System™ reached this significant milestone as Cisco UCS claimed its 100th world-record performance result with the fastest 2-socket server on the SPECjbb®2013 MultiJVM benchmark for the max-jOPS metric.
A Cisco UCS® C220 M4 Rack Server powered by the Intel® Xeon® processor E5-2600 v3 family delivered four times the max-jOPS rate that Cisco measured using previous processor generations to set a new world record. This dramatically increased performance of 195,119 max-jOPS is the top 2-socket MultiJVM score for maximum Java operations (max-jOPS).
This world-record of 195,119 max-jOPS is more than three times better than Cisco UCS C240 M3 with Intel Xeon processor E5 v2 family-based result from just 10 months ago, and more than four times better than our Intel Xeon processor E5 family –based result from 18 months ago. This consistent record-setting performance from Cisco UCS blade and rack servers ensures that Cisco will stay ahead of competitors in delivering high performance for Java virtual machines (JVMs) and throughput-intensive Java applications.
The JVM instances ran on a Cisco UCS C220 M4 Rack Server powered by two 18- core Intel Xeon processor E5-2699 v3 CPUs running Red Hat Enterprise Linux (RHEL)Server 6.5 and Oracle Java HotSpot 64-Bit Server Virtual Machine (VM) Version 1.8.0_20. Check out the Performance Brief and the detailed official benchmark disclosure report for additional information on the benchmark configuration.
Let’s see, what does this latest result mean for our customers? This result proves that IT departments that deploy Java applications on Cisco UCS can deliver more throughput and support more users while reducing the complexity of the data center. For customers assessing infrastructure for Java applications, this result demonstrates Cisco’s capability to consistently deliver record-setting performance with every new generation of processor.
It is interesting to note that although all vendors have access to same Intel processors, only Cisco UCS unleashes their power to deliver high performance to applications through the power of unification. The unique, fabric-centric architecture of Cisco UCS integrates the Intel Xeon processors into a system with a better balance of resources that brings processor power to life. . For additional information on Cisco UCS and Cisco UCS Integrated Infrastructure solutions please visit Cisco Unified Computing & Servers web page.
SPEC, and SPECjbb, is registered trademarks of Standard Performance Evaluation Corporation. The benchmark results used to establish world-record status are based on those available at http://www.spec.org as of October 6, 2014.
Tags: Cisco UCS, Cisco UCS Performance Benchmarks, World-record performance
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.
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.
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: analytics, Big Data, Business Directory, Cisco Data virtualization, Cisco Information Server, cloud, Internet of Everything
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: ACI, APIC, Application Centric Networking, Nexus 9000, Open Daylight, OpenStack, OpFlex, SDN
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