Openstack for Openstack, Study Guides, Projects, Research of Mathematics

Download Openstack for Openstack and more Study Guides, Projects, Research Mathematics in PDF only on Docsity!

HPE Helion OpenStack

Traditional Enterprise Workloads in an

OpenStack cloud

Technical white paper

HPE Helion OpenStack

• Executive summary................................................................................................................................................................................................................................................................................................................................ Contents
• Pets and Cattle—Reality....................................................................................................................................................................................................................................................................................................................
• Pets on cloud—Enterprise needs..............................................................................................................................................................................................................................................................................................
  • Single infrastructure for cloud-native and traditional workloads ..........................................................................................................................................................................................................
  • Agile and cost-effective alternative for compute vending machine and storage solutions ..........................................................................................................................................
• How does OpenStack enable Pets on clouds?..............................................................................................................................................................................................................................................................
  • Deployment architecture............................................................................................................................................................................................................................................................................................................
  • Storage ........................................................................................................................................................................................................................................................................................................................................................
  • Performance and latency ...........................................................................................................................................................................................................................................................................................................
  • Business continuity ..........................................................................................................................................................................................................................................................................................................................
• What Pets are suitable to move to an OpenStack cloud?...............................................................................................................................................................................................................................
  • Suitable Pets ......................................................................................................................................................................................................................................................................................................................................
  • Pets not fit for the cloud
  • Pets on an HPE Helion OpenStack cloud
• References and related information

Refer to slideshare.net/randybias/pets-vs-cattle-the-elastic-cloud-story for detailed Pets vs. Cattle discussion, by Randy Bias, from the DevOps Chicago Meeting, February 26, 2014.

In the early years of cloud, cloud infrastructure services focused only on the cattle breed of applications. In more recent years, and as enterprises have been gearing up to go mainstream on private cloud deployments, there has been an increasing need to utilize the cloud infrastructure for traditional pets.

Pets on cloud—Enterprise needs

Single infrastructure for cloud-native and traditional workloads

During early days of cloud-native development, majority of enterprise customers have been comfortable deploying separate infrastructure for cloud-native and for traditional applications. As the development of these new cloud-native applications is now reaching production state, the enterprise customers are concerned with managing separate infrastructure clouds and adding operational complexity and cost to their already stretched teams and budgets. Enterprises are now looking at migrating workloads from these disparate environments to a unified cloud environment.

Here is a reference from April 2016 OpenStack survey [1]: “..., being able to support both

traditional and cloud-native workloads is very important because large enterprises don’t

have the luxury of dropping their legacy applications and forklifting them into the micro

services-type designs from day one. The benefits of the cloud are too great to only allow

new workloads onto the platform,” said one user from a global financial institution.

Agile and cost-effective alternative for compute vending machine and storage solutions

One of the primary use cases and benefits of traditional virtualization solutions in enterprise IT environments is its ability to serve as compute (virtual server) vending machine. But the licenses can have huge CAPEX and the processes for vending are not self-service and needs manual/semi-automated process.

OpenStack cloud provides a cost-effective alternative (KVM hypervisor) and agile (on-demand, automated, API driven) methods to order and operate servers, storage and networks. This will help enable DevOps and IT-as-a-Service and improve productivity of the IT department and lines-of-businesses.

OpenStack also enables scalable & cost-effective alternatives (Swift or Ceph Object storage) to address storage aspects of traditional Backup, Archive and Disaster Recovery solutions. See Backup and Disaster Recovery sections for details.

How does OpenStack enable Pets on clouds?

Traditional enterprise workloads have various dependency levels on the infrastructure. Let’s explore the top four topics that come up in every customer conversation: deployment architecture, storage, scale and performance, and business continuity. There are obviously many additional considerations and topics that could also be explored in this white paper, such as manageability, monitoring, security and compliance. We will explore these in future white papers.

Deployment architecture

Figure 1. Three-tier traditional architecture

Traditional applications are normally deployed in three-tier architecture (Presentation, Business/App, and Database). Figure 1 illustrates a traditional three-tier architecture widely deployed in the enterprise today. It has served as the backbone for enterprise mission critical applications since the introduction of the intranet in the late 1990s. “Three-tier architecture is a client–server software architecture pattern in which the user/Web interface (presentation), functional process logic (business rules), computer data storage and data access are developed and maintained as independent modules, most often on separate servers and platforms.” (en.wikipedia.org/wiki/Multitier_architecture). Often middleware (example, Messaging, Queuing, Protocol middleware) is used to connect the separate tiers.

3-tier deployment The OpenStack cloud infrastructure can support three-tier architecture and its variations to enable easy deployment and management of the traditional enterprise applications. As enterprises migrate applications to the cloud, they need to replicate their existing physical resources (Compute, Storage, VLANs, Firewalls, Load Balancers) in the cloud and integrate into their existing datacenter infrastructure.

Compute and networking are important aspects in all three-tier architectures and storage is a critical/vital piece in the Business/Data logic tiers. OpenStack provides various compute options—virtual compute aka hypervisors, bare metal, and containers, virtual networks with VLAN/VXLAN, Routing, NAT capabilities and virtual network services like DNS, Load balancer, Network firewalls, Security-Groups (for instance specific firewall), IPSec VPN, and storage options (block storage, filesystem) to enable deployment of basic functional three-tier architecture.

A common use case is for different tiers to be managed by different departments in the same organization. This can be achieved by mapping each tier as a different OpenStack project. On the contrary, if a single department (central IT department) wants to manage all the 3-tiers, OpenStack lets the enterprise manage all the tiers as a single project with the ability to flexibility share virtual resources across all tiers with ease.

In summary, OpenStack has reached a level of maturity that now makes it a viable platform to run a large number of applications developed with a 3-tier deployment architecture. In the following section, we will discuss deployment options that cater to the workload nature (characteristics) of applications across each of the tiers.

Load balancing: Certain traditional application’s Web tier or business logic tier is stateful (i.e., the application session state of the end-user is maintained only in one server). This means that the load balancer has to be sticky (i.e., it has to load balance a particular TCP/HTTP session to the same server until the transaction is completed). This is supported in the reference load balancer (haProxy) supported by OpenStack as well as other industry-standard hardware and software load balancers. Some traditional applications have tight dependency on load balancing features supported specifically by third-party vendor load balancers in the market. Load Balancer as a Service (LBaaS) in OpenStack supports different industry-standard load balancers as a plugin via the standard APIs. This enables easy integration of traditional applications into the OpenStack cloud environment.

Special deployment use cases VLAN: Some embedded networking applications’ needs specific Layer 2 connection at the provider network (e.g. VLAN ID) to integrate with traditional networking packet core elements (e.g. mobile packet core). Provider-VLAN feature of OpenStack is very crucial to enable these type of applications.

Storage

Traditional applications use filesystems and relational databases for storing data. OpenStack provides the following options to support their storage needs.

Block storage: Block storage (aka volume storage) provides users with access to block-storage devices. Users interact with block storage by attaching volumes to their running VM instances—only a single VM instance attaches to a volume at a time. The operating system running in the VMs formats the block device (volume) to the necessary filesystem and uses it for permanent-storage for application data. The OpenStack Block Storage project is called Cinder. Cinder allows RAID configuration for each volume to improve availability of data and performance.

Block level storage is usually deployed in SAN (storage area network) environment for better manageability and cost. Block Storage on local hard disk of computes can be used for better performance for traditional applications. OpenStack supports both these options.

Block Storage is the recommended storage option for databases (e.g. Oracle) used in traditional applications.

Shared file system: Shared file system refers to the ability to share the same file system across various server/VM instances (NAS protocols like NFS, SMB/CiFS). OpenStack provides support for shared file system via the Manila project. Distributed traditional applications running on multiple server instances utilize shared-file-system to simplify file-shares across servers and centralize logging.

Mix of Block/Object/File System Storage: Normally, traditional workloads use block or file system storage and cloud-native workloads use object Storage for their massive scale and distributed nature. Object Storage is also helpful for traditional workloads for backup/recovery and application image-management use cases. For a cloud with both traditional and cloud-native workloads, OpenStack concurrently supports block storage (Cinder) and object storage (Swift). A cost-efficient option is Ceph which supports block, object and file system storage.

Performance and latency

In a traditional computing, applications’ performance, scale and latency are designed based on the performance of the compute, storage and networking infrastructure. Here are some example use cases

• Networking software need high performance and low latency packet processing
• Business critical applications (Stock/Finance/Banking Applications) are dependent on performance and enterprise-grade features supported in operating systems like NonStop Operating Systems
• Media processing applications (Video rendering) need to utilize the hardware GPU (Graphic Processing Unit) capabilities

In the subsections below, we will cover the various OpenStack features that facilitate migration of these high performance applications to the cloud.

Virtual Compute performance OpenStack Compute Service (Nova) supports the following features which allow the Guest VM (Operating System and applications) to utilize the HW capabilities of the compute node. This allows migration of performance-hungry and traditionally hardware dependent applications to virtualized servers in the cloud.

Hardware CPU Model at Guest: Enables the Guest OS (and applications) running in the VMs to use special HW-CPU instruction set of the underlying physical server and improve performance through hardware acceleration; example are cryptography and video transcoding.

Non-Uniform Memory Access (NUMA): Enables NUMA model of the host to the Guest OS to provide faster memory access times.

VCPU/Thread Pinning: Enables the vCPU of the Guest VM to be mapped to underlying HW CPU or hyper-thread to improve CPU performance.

Huge-Memory-Pages: Enables the Guest OS to utilize the huge memory page supported by the underlying HW.

PCI-PT (PCI PassThrough): Exposes the PCI device hardware directly to the VM’s Guest OS to improve I/O performance of networks, disk access, and graphics.

All the above-mentioned functionalities enable networking software (VNF) and nonStopOS’s (vNonStop) business applications to run in the VMs.

Virtual Storage performance Virtual Storage performance depends on better storage device performance (different storage array, raid and disk/flash storage technologies, QoS features). The OpenStack Cinder service provides a pluggable driver architecture to use appropriate storage device depending on the performance/cost need of the application.

Virtual Networking Acceleration SR-IOV/PCI-PT (Single Root—IO Virtualization): SR-IOV is a NIC technology that allows a single physical interface to be mapped to multiple virtual IO devices, each of which can be assigned to an individual VM. PCI-PT delivers a single interface to a VM, and is typically used on when a server is allocated to a single virtualized function. These technologies bypass the kernel vSwitch, improving on the I/O performance of the VMs (at the possible cost of vSwitch functionality). OpenStack can now manage these types of NIC drivers.

Data Plane Development Kit (DPDK): This is an industry standard hardware-agnostic API and software-development framework from Intel® that improves the performance of networking applications without locking to specific NIC hardware. OpenStack supports DPDK at the hypervisor level by integration with OVS (Open vSwitch), delivering optimization in user space handling of packet data. Networking applications can enable DPDK in the Guest OS as well to improve performance.

Stateless offload of VXLAN traffic: This is the ability to offload compute intensive operations (like L2/IP/TCP checksum) of the workload traffic to hardware NICs when the traffic is tunneled within VXLAN tagged packets, enabled by the underlying Linux® kernel.

Bare metal Compute (Ironic) Certain enterprise applications cannot afford the overhead sometimes experienced when deploying on virtual infrastructure; extensive IO with direct access to the underlying OS or specialized hardware is sometimes more important. This is often the case for GPU rendering applications and database workloads like Oracle DB. OpenStack offers the ability to dynamically provision bare metal servers via Ironic, with the customer’s choice of operating system.

The advantages of managing bare metal servers in the cloud are: a) the ability to co-exist with virtual servers (running related applications), virtual storage and network; b) the ability to provision and modify capacity of bare metal workloads on demand; and c) improved performance for performance-sensitive applications.

Customers requiring ultra-low networking latency and maximum CPU performance (with no hypervisor overhead), such as those running high-performance databases or telco functions, often find this particularly attractive. The IT admin is still able to manage these machines, however, because they are all part of the OpenStack fabric, it’s a win-win for the traditional application’s owner as well as the IT admin.

Business continuity

Every enterprise customer has well-defined policies defining the business service level availability of their critical applications. SLAs are highly dependent on several business continuity factors of the infrastructure such as high availability configurations, live migration capabilities for the workloads, backup and restore procedures, and disaster recovery practices.

Traditional applications expect the infrastructure to be configured in a high availability configuration to not be impacted by single points of failure and deliver a 99.999% availability for their services. In this section, we will explore the various options supported in OpenStack to enable high availability for the applications and services.

VM/Volume Migration VM live migration and resize: Planned maintenance activities like upgrade/patching and hardware maintenance with reduced downtime is a critical expectation to improve the availability of enterprise applications without reserving passive servers for high-availability. Robust and reliable live migration helps in improving the availability of enterprise IT services during planned maintenance. Customers adopting OpenStack cloud have become dependent on the live migration feature. It reduces operational costs and increases the availability of IT services. Live migration provides the ability to copy “live” the memory state and disk state of a VM from its compute-node to another compute node. The failover/switchover happens when memory or disk changes slowdown on the source VM. The workload running in the VM is completely unaware of the migration as the storage and network configuration (volume mapping, ip addresses) of the VM are preserved after the migration. Live migration also helps improve the resource utilization of the datacenter by merging VMs running on under-utilized physical servers to single physical server.

VM resize is the ability to resize (increase or decrease) the VM’s CPU, memory or disk resources. This is very helpful and handy for the cloud operator to tailor resources needed on his virtual machine to improve the application’s scale and/or performance. It’s very useful to qualify an application in Pilot environment and later resize and deploy at scale in a production environment (Note—resize results in shutdown of the old VM and creation of a new VM). The value proposition: reduced cost needed to Pilot an application then having the ability to balance the hardware utilization of different physical servers when ready to deploy into production.

Volume migration: OpenStack has the ability to migrate volumes between back-ends which support its volume-type. Migrating a volume transparently moves the data from the current back-end for the volume to a new one. This is an administrator function, and can be used with functions including storage evacuation during maintenance or decommissioning, or manual optimizations for performance, reliability, or cost reasons.

Backup Backup traditional workloads to an OpenStack cloud: The compute and the storage cost-effectiveness of an OpenStack cloud makes backup and archiving of traditional application a good use case candidate. OpenStack supports two main options for backing up your traditional applications: a) enterprises can install the OpenStack Freezer backup and recovery service (freezer-agent and freezer-scheduler) on their traditional servers and let freezer back them up to the OpenStack Swift Object Storage backup-storage-target; or b) enterprises can integrate their existing backup and archiving application to use the OpenStack Swift Object Storage as the backup target.

Backup of traditional workloads in OpenStack cloud

Following are important backup related use cases applicable to traditional applications deployed in the cloud:

Admin—VM/Volume backups: Administrators of the cloud are interested in protecting the application (state and data) to provide better recoverability of their environment. OpenStack supports VM backups via Nova snapshots and volume backups via Cinder backups. This can be integrated with the OpenStack Freezer service to enable scheduling of backups and the ability to store to different storage targets.

Tenant—File System and Application-aware backups: Most applications need basic capability to backup and restore the files and directories in the VM. This is supported in OpenStack via the Freezer service. The recovery for most traditional applications depend on the consistency of the data that was backed up. This requires the backup software to be aware of the application and coordinate with the application during backup. For example, MySQL DB, Elastic Search DB, Microsoft® Outlook, and Oracle DB have specific recommended methods to enable backup of their data. Freezer supports application aware (application-consistent) backups for MySQL DB and MongoDB without causing locking-related-delays on the applications using the database.

Tenant—Synchronized Distributed backup: Modern applications are distributed across many servers and require file backup to be time-consistent across those multiple servers. Freezer supports this by its ability to configure multiple jobs—one backup job per server—and link those jobs into a single session.

Disaster recovery Disaster recovery of traditional datacenter workloads from an OpenStack cloud Disaster Recovery (DR) agents (vendor/third-party agents) are installed on traditional datacenter environments to back up the application and application-data into an OpenStack cloud. In the case of failure of the traditional datacenters, the DR orchestration framework in the cloud can recover the applications and their data (e.g. HPE Helion Veritas DR-as-a-Service).

Disaster recovery of traditional applications running in an OpenStack cloud Disaster Recovery from backups: This is the cost effective way to recover applications and their data. It has lower recovery time (RTO) and recover point (RPO) compared to multi-site DR. The simplest way do to this in OpenStack would be to back up the VM and volume to an external site. The Freezer service enables scheduling VM and volume backups to external SSH servers or external Swift cloud. The recovery orchestration can then be executed manually or automated using third-party recovery solutions.

Multi-site Disaster Recovery: This is the ability to protect traditional workloads from one cloud or site to a remote DR site at metro/continental distance and recover the workloads or service in case of a primary site failure. In the traditional application scenario, the remote DR site could be completely passive with reserved resources or a mix of active workloads and passive resources. The main advantage over DR-from-backup is its ability to minimize RPO (~ 0) and RTO in case of disaster. The primary requirements for multi-site DR are the ability to synchronize the storage data across the two sites and the ability to orchestrate recovery of the workloads and control-plane infrastructure in case of primary-site failure.

OpenStack multi-region support is a good candidate to deploy multi-site clouds. OpenStack is still primitive in its ability to synchronize data across two sites (Cinder replication across sites or Swift sync across sites) and orchestration framework for recovery.

What Pets are suitable to move to an OpenStack cloud?

Suitable Pets

The following applications and use cases are suitable candidates for hosting in a cloud environment:

E-Commerce/Internal Enterprise websites: Small/Medium scale e-commerce websites and internal websites for enterprise IT fit well into the three-tier architecture discussed above.

IT (Compute/Storage/Network/Bare metal) Vending: IT applications used to order or reserve IT resources such as Compute and Storage where usage metering for charge-back/show-back to the consumers can be run in OpenStack with integration with third-party billing systems. Virtual Desktop Infrastructure software which simulates and manages desktop computers on virtual machines can also run in OpenStack for the virtual machines.

Backup applications and Storage: Traditional backup applications can be hosted in an OpenStack cloud and they can use scalable Object Storage as the backup target.

Disaster Recovery: Applications that recover traditional workloads from disasters can be hosted in an OpenStack cloud and can utilize Object Storage as their DR storage target.

Embedded/Networking software: Networking software which manage their HA at the Guest OS and application software can be virtualized to run on OpenStack clouds (note: automatic restart of VMs is not considered high availability for these applications).

Video processing applications: are suitable for the OpenStack bare metal clouds.

Office Applications and Business Services: Office applications such as enterprise email, collaboration, and unified communications and Business Services such as HR, CRM, ERP applications for small-medium businesses all fit this category.^1

Pets not fit for the cloud

Applications whose fault-tolerance architecture needs synchronization of in-memory application state are not well suited to run on upstream OpenStack today. Applications where each single transaction is critical, such as stock market and trading/financial software, is not recommended for OpenStack yet until additional innovations upstream provide the needed business critical stability. Some OpenStack vendors are investigating if high-performance related features in OpenStack can be utilized for these applications.

Pets on an HPE Helion OpenStack cloud

The table 2 provides general guidelines around what features might be required to run traditional or traditional and cloud-native application and whether these are available in OpenStack and HPE Helion OpenStack. It is important to note that not every feature is needed for every workload.

(^1) “Traditional versus Cloud Native Applications.” youtube.com. youtube.com/watch?v=osz-MT3AxqA.

HPE Helion OpenStack

Sign up for updates

© Copyright 2016 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. The OpenStack Word Mark is either a registered trademark/service mark or trademark/service mark of the OpenStack Foundation, in the United States and other countries and is used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community. Pivotal and Cloud Foundry are trademarks and/or registered trademarks of Pivotal Software, Inc. in the United States and/or other countries. Intel is a trademark of Intel Corporation in the U.S. and other countries. Microsoft is either a registered trademark or trademark of Microsoft Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle and/or its affiliates. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. 4AA6-6475ENW, July 2016

References and related information

“April 2016 OpenStack User Survey.” openstack.org. openstack.org/assets/survey/April-2016-User-Survey-Report.pdf.

“Maximizing the Value of Cloud for Small-Medium Enterprises: Applicable Workloads for Cloud.” opengroup.org. opengroup.org/cloud/cloud/cloud_sme/workloads.htm.

“Traditional versus Cloud Native Applications.” youtube.com. youtube.com/watch?v=osz-MT3AxqA.

“4 Benefits of Moving Traditional Enterprise Apps to the Cloud.” infoworld.com. infoworld.com/article/2683179/cloud-computing/4-benefits-of- moving-traditional-enterprise-apps-to-the-cloud.html.

“Are Your Apps Cloud Candidates?” cio.com. cio.com/article/2913956/cloud-apps/are-your-apps-cloud-candidates.html.

“Beware these pitfalls when moving enterprise applications to the public cloud.” zdnet.com. zdnet.com/article/beware-these-pitfalls-when- moving-enterprise-applications-to-the-public-cloud/.

“Cattle vs. Pets: An Analogy For Cloud And Enterprise IT.” tomsitpro.com. tomsitpro.com/articles/openstack-pets-and-cattle,1-1759.html.

“How Neutron builds network topology for your multi-tier application?” openstack.org. openstack.org/summit/vancouver-2015/summit- videos/presentation/how-neutron-builds-network-topology-for-your-multi-tier-application.

Learn more at

hpe.com/helion