Cisco Cloud Services (CCS) and Products
In the layer above the OpenStack platform, services and capabilities are added by the Intercloud to enable advanced services around networking, security, NFV, data, database, load balancing, and application policy. As you move up the stack, it is critical to focus on the API interfaces and capabilities. This layer is also where the Intercloud Fabric (iCF) product resides to enable point-to-point secure Intercloud connectivity.
Intercloud Network Products
The Cisco long-term vision of the Intercloud is a global network of cloud data centers, hosted by an alliance of service provider partners, that allows the collective customer base to run workloads or access valuable enterprise services anywhere across the globe. In order to achieve rapid adoption and increase customer loyalty, Cisco will enable its customers to reach these workloads and services in a secure, highly reliable manner. The users’ experience will appear to be a borderless extension of their corporate networks. Additionally, Cisco will equip its network service provider (NSP) partners with methods to easily and securely connect to these services. This approach will allow them to build and offer compelling service bundles to their customers and is called PrivateLink.
PrivateLink is a collection of secure network connection capabilities that provide customers with this dedicated, private, secure connectivity into Intercloud regions without the need to configure or manage any VPN technology in their on-premises networks. This makes it a perfect solution for customers with a large number of enterprise devices or users needing access to their cloud environment. It also gives cloud consumers a way to provide highly available, high-quality connections to their services running in Intercloud regions around the globe.
PrivateLink will play a major role within our broader connectivity strategy of private peering between Alliance Partner networks and creating a seamless mesh of Intercloud regions across the globe. Figure 2-3 shows this capability: a future customer attaches into an Alliance Partner network with PrivateLink and can reach private workload space in any region across the Intercloud.
)
Figure 2-3 Cisco Intercloud Alliance Partners Connected via PrivateLink
Intercloud Security
Securing the Intercloud is critically important as security is still the top concern for adoption of cloud services. Additionally, when one considers the global nature and interoperability of the Intercloud, the risk and threat profile warrant extra focus. Intercloud security consists of three layers: foundational security, security services, and security as a service.
Foundational security consists of controls at the infrastructure level to protect the provider and each tenant with a default level of security, segmentation, and access controls. The typical controls in this area consist of identity and access controls as well as network security groups and segmentation. This level is based on industry standards for security and segmentation.
Security services are products that are offered on top of the foundational baseline that enable customers to provide security controls for their deployment. These services typically consist of firewall, intrusion detection, encryption, and other security capabilities that customers need to protect their deployments and applications.
Security as a service consists of security capabilities that are provided in consumption and pay-for-use models as a service. These services are managed by the provider of the service and usually are called “managed services” since the provider manages and provides the security services at an additional cost to its customers through a subscription model.
Intercloud Network Functions Virtualization (NFV)
Networking and the importance of networking are diminishing as the industry considers the x-as-a-service model. This is primarily because of the complexity that network configuration can seem to inflict when the x-as-a-service model extends to public clouds. This has been by far the most-overlooked aspect required for the cloud computing model and is more important than ever before. The network is more critical to application performance and more importantly the customer experience than most any other aspect of cloud. To say the network does not matter is like saying that application behavior and customer experience do not matter. These aspects are intrinsically tied together. The network aspects of the application being delivered need not be overly complex or be explicitly defined at runtime. Application owners or developers do not have to know anything about the network, but they need to be able to define policies and business objectives about the performance, governance, compliance, and data classification.
Recently, SDN and NFV have been receiving attention to address the application performance and customer experience concerns posed by flat network and disconnected network approaches.
Another area that has been evolving over the last couple of years is NFVs. These can vary from network appliances to routers, to firewalls, to content delivery network (CDN) caches. The primary idea is to enable data to be processed in a virtualized manner that is similar to the physical network functions that used to be leveraged in the data center and service provider. These services can be leveraged in the Intercloud in several ways. The Intercloud Marketplace will provide a way for enterprises to purchase their NFV solution from a marketplace of Cisco partners and industry-leading solutions.
Enterprises that have their own NFV solution of choice and licenses can upload their NFV solution into the catalog and either enable the NFV solution as part of their project or make it available for certain projects to leverage. Last, the Intercloud will enable NFVs as a service within the Intercloud itself. In this model, Cisco will manage, operate, and support the NFV use cases.
Network services like server load balancing (SLB) with the ability to support elastic scaling of the application services based on application policies are a critical part of the Intercloud’s ability to enable better networking and performance for enterprises leveraging the Intercloud.
In many cases, to meet security and compliance requirements, firewall, IPSec (VPN), or advanced services like an intrusion detection/prevention system (IDS/IPS) or web application firewall (WAF) are required. This is a good example of NFV services that the application can leverage over the allocated network by definition of the business policies. Some tuning may be required to take full advantage of these NFV services; however, the general business rules can be deployed as the baseline policy.
Setting up initial and additional access to cloud is a major issue for all cloud deployments. Being able to connect to the “public” network and have your same policies, networks, and access controls in place can take weeks to months. To address this issue, the Intercloud creates an initial direct connection to the “public” network. In addition, the ability to create multiple network segments and leverage your existing private (RFC 1918) space as well as your existing public IP space is supported by default. Extending your internal enterprise network to cloud is as easy as setting up your internal network segment on the Intercloud and connecting it to your internal network through a software-defined gateway and overlay network.
With the Intercloud, Cisco has created a new demilitarized zone (DMZ) for enterprises that lets them securely interconnect from their internal network (“behind the corporate firewall”) to the external networks (“public”). This new DMZ is called the cloud edge gateway and provides a secure interconnection between the enterprise data center and the Intercloud.
Intercloud Cloud Services
Intercloud business models are primarily based on three uses cases:
Infrastructure that is ubiquitous
Basic network, compute, and security services
Value-added services that allow the admin or developer to enable applications seamlessly across the Intercloud
Services can be numerous, and dependencies are important to monitor. Many applications require external services, software components, or enhancements to enable their ecosystem to grow and adapt to changes in market conditions.
Enhancements can be in the form of ecosystem partners or industry-leading services (resell or as-a-service models), or developed as part of the service offering. This section will describe the primary use cases that are offered as a service today and how to evaluate their effectiveness and usefulness.
Data services are often an overlooked area due to the complexity of the requirements to manage them. This is a major focus of the Intercloud as it is the core platform that enterprises require to manage their application content and perform analytics to enable business decisions. The Intercloud model provides a ubiquitous infrastructure that consists of the basic compute, network, and storage services that infrastructure as code requires. In addition, the ability to add value-added services and to interconnect across various partner and public clouds to allow flexibility of the services to be consumed where they make the best business sense is preserved.
Database as a service is one such service that makes a great use case for value-added services.
Database as a Service Use Case
Databases are critical to all enterprise services, and today the need to scale out data with NoSQL databases is important for enterprises. The Intercloud supports several deployment scenarios when it comes to databases, the primary one being deploying into the project with the application. This keeps the application and database dependencies related to each other in the same project. The other scenario is to deploy in a hybrid manner where the database is in the enterprise behind the firewall and the application is in cloud. In this model, it is important to consider the networking as well as data latency requirements between the database and application(s).
Trove
Trove is an OpenStack project that provides a user interface (UI) and a command-line interface for periodic maintenance of the database, such as scheduling backups, restoring data from backups, automatically upgrading minor versions of the database software, setting up replication, and so on. The UI is a common front end for managing different databases in the back end. It should also provide customers the ability to monitor and send notifications when a certain database threshold is exceeded, such as maximum number of connections, storage filling up, and long-running queries, to name a few.
Trove provides a scalable and reliable cloud database-as-a-service provisioning functionality for both RDBMS (relational database management system) and nonrelational engines on top of OpenStack. Figure 2-4 shows a reference architecture of Trove.
)
Figure 2-4 Trove Reference Architecture
Trove interacts with various OpenStack components for provisioning a VM to set up databases; see Figure 2-5 to better understand how it interacts with OpenStack components.
)
Figure 2-5 Trove and OpenStack Interaction
Trove itself is based on a share-nothing messaging system, like Nova. Its components communicate over a message bus and can be run on different servers. It behaves very similarly to Nova in that you send a message over HTTP, that message is translated and sent over the message bus, and actions happen asynchronously. It is currently composed of the following major components:
API server
Message bus
Task manager
Guest agent
Conductor
Scheduler
Figure 2-6 gives a pictorial view of the components and an explanation of each of the components.
)
Figure 2-6 Interactions Among Various Trove Components
Intercloud Application Policy
A critical architectural component of the Intercloud is the ability to manage applications across a global connected world leveraging business policies. The Intercloud’s application policies enable enterprises to have a complete cloud strategy, allowing application visibility and control across private and hybrid clouds for both legacy and new applications. These applications can then be deployed securely and compliantly across hybrid clouds with application awareness, dynamic lifecycle management, and real-time automation. Through policy-driven management that is independent from infrastructure or systems management, the application-driven policy platform puts the application or business owner back in control.
This platform was developed to bring telco-grade reliability and trust to the data center. It enables IT to deliver the intent of the application anywhere via application-driven policies that are dictated by business needs of providing an abstraction layer between business objectives definition and the enforcement of policies within the application-centric infrastructure, as well as to introduce increased resiliency, providing a clear handoff between developers and operations.
Figure 2-7 presents the intent model as a set of configuration, fault/performance, security/governance, and accounting SLAs.
)
Figure 2-7 Application Policy Intent Model
To break down the application intent, it is best to separate the Intercloud innovation around application intentions from the existing policy models (TOSCA, OpenStack Congress, Group-Based Policy, and so forth). In the definition here, we introduce the business goal of sensitivity. Sensitivity is defined as the degree to which the performance and response time of the application influence the end users’ perception of the application’s performance. It is best to consider it a scale of no sensitivity to high sensitivity that can be adjusted in real time by the perceptions of the performance being measured by the system and end users.
The application intent sensitivities are defined as follows:
Compute
CPU sensitivity
Memory sensitivity
Storage
Latency sensitivity
Volume sensitivity
I/O
Latency sensitivity
Throughput sensitivity
Thresholds (optional numerical value—for example, 80 connections/sec)
Fault/performance
Recovery sensitivity
Availability sensitivity
Scale sensitivity
Accounting
Cost sensitivity
Given these sensitivities, the Intercloud policy system can create an SLA for the business objectives defined here. In addition to these sensitivities, there are attributes that the policy system needs to be aware of. The first one has to do with dependencies:
Services
Service affinity
Service anti-affinity
Security policies (data classification)
Placement policies
Host affinity
Host anti-affinity
Availability zones
Regions
Geography
Constraints—noncoexistence
The second has to do with limits and understanding the constraints on the policy:
Metering limits
I/O
CPU
Memory
Connections per second
Security governance
Organizational constraints (IT, human resources, legal, engineering)
Data type constraints (public, sensitive, confidential, top secret)
Operational constraints
Encryption
Auditing
Log retention
Given the sensitivities, dependencies, and limits, the developer can set the initial application intent, measure the performance of this initial intent, and make changes based on the actual performance. This is one aspect of the Intercloud that is important to understand, as deploying to any environment based on performance, compliance, data sovereignty, and internal enterprise security policy concerns is a first-order problem that the Intercloud addresses.