WIXLIB

TECH GUIDEOpenStackDeployment Models

IntroductionTECH GUIDE:OpenStackDeployment ModelsOpenStack’s phenomenal growth has made it the industry’s defacto private cloud management platform and the second largest opensource project of all time. As OpenStack adoption has grown, several OpenStackdeployment models have emerged, each with its own pros and cons. This guide providesan overview of OpenStack private cloud architecture, explains some of OpenStack’s limitations,and explores several OpenStack deployment alternatives.OpenStack Architecture OverviewOpenStack’s design is inspired by Amazon Web Services (AWS), with well documented REST APIs that enable a self-service, elasticInfrastructure-as-a Service (IaaS) cloud. In addition, OpenStack is fundamentally agnostic to the underlying infrastructure, integratingwith various compute, virtualization, network and storage technologies.(identity)Basic StorageBasic LI / ToolsGlanceClarity UIBlockStorageFigure 1: OpenStack architecture is loosely coupled, and extensible to support any hypervisor / container, storage, and network system2

Mismatched Expectations with OpenStackOpenStack has multiple advantages overother private cloud platforms, such as simple REST APIs, an AWS-like service-orientedarchitecture, and a management platformthat works across multiple virtualizationtechnologies. Despite these advantages,OpenStack adoption suffers from thefollowing limitations:OpenStack TCO is Variable5,000,0003,750,000VMware vCloudOpenStack PerceptionOpenStack Total Cost2,500,00025 rack infrastructure1,250,000Analyst estimated20 Engineers neededfor OpenStack0 Deploying OpenStack in production isa challenging and resource-intensiveexercise. Analysts estimate that a team of20 engineers would be required to deploy OpenStack for a 25-rack infrastructure.1 Figure 2shows that the actual cost of deploying OpenStack is much higher than the perceived costof deploying the software.Figure 2: Perceived cost ofdeploying OpenStack Actualcost of deploying OpenStackUpgrade IssuesUpgrading from one version of OpenStack to another is a difficult task often plaguedwith unplanned downtimes arising from unexpected issues. Troubled by past upgradeprocesses, many organizations are hesitant to migrate to the latest OpenStack release. Thisis evident in the user sentiment expressed in the OpenStack User Survey, as summarized inthis verbatim quote:2“I feel difficulties like deployment of OpenStack at a very large level are still not so easy.the migration of whole infrastructure with a new release of OpenStack is challenging.”OpenStack Doesn’t Work Out of the BoxIt takes a lot ofwork to decide ondeployment architecture,deploying, and maintainingthe software.OpenStack User, 2016OpenStack FoundationUser SurveyOpenStack is an open source project, not a packaged and production-ready product. Thismakes deploying OpenStack directly from source code an arduous and engineering-intensive task compared to deploying a packaged product from a distribution vendor orconsuming OpenStack as a service. In fact the most recent OpenStack Foundation Surveyrevealed that “complexity to deploy and operate” presented a challenge for many users.33

Deployment Models for OpenStackThere are various ways to deploy OpenStack in your data center, each of which has itsown strengths and drawbacks. The following architectural diagrams highlight severalof these approaches: on-premises distribution, private cloud in a box, hosted privatecloud, and OpenStack-as-a-service. radegpU Monitoring: Who will monitor the OpenStack software (control plane anddata plane) to ensure that it is healthy and operating as planned.Troubleshooting: Who will take care of problems - be it an OpenStack bug,a misconfiguration, etc. - to resolve these issues quickly when they arise.Upgrades: When it’s time to upgrade to the next OpenStack release, who willbackup the controllers, roll out the upgrade, and validate it prior to committing.tingoo TroubleshAn important factor in each of these models is the question of who is responsiblefor the OpenStack lifecycle. Beyond the initial setup of the OpenStack environment, private cloud management includes:MonitoringOn-Premises DistributionIT ManagedAdministerSelf-serviceOn-premises is the most commonly adopted deploymentmodel, and can be implemented in a do-it-yourself (DIY)manner using Homebrew, or utilizing a particular vendor’sOpenStack distribution.VM VMVM VMWith this model, OpenStack controllers run on-premises,as does the underlying compute, networking and storyinfrastructure. IT is responsible for installing, configuring,monitoring, and troubleshooting their OpenStack privatecloud. In-house personnel customize OpenStack to meetorganizational requirements. This deployment model canbe cost effective for organizations but only when implemented successfully.Typical vendors for this model are:Mirantis, Rackspace, Red Hat.UsersIT AdminData Center 1Data Center 2Enterprise FirewallWho is responsible for the OpenStack lifecycle:Internal IT teamFigure 3: An on-premises OpenStack distribution uses in-housesecure infrastructure4

On-Premises Distribution Pros: Security: No workload data leaves your network perimeter.Customizable: OpenStack can be customized to suit an organization’s requirements.Hardware independence: There is no requirement to utilize hardware from a particular vendor.On-Premises Distribution Cons: High operational costs: There are high costs associated with configuring, monitoring, backing up, and upgrading OpenStack,exacerbated by the cost associated with the scarcity of skilled OpenStack personnel available on the market.Time to value: Homebrew projects are prone to stall due to technical challenges and lack of skilled staff; implementation with avendor-supported distribution have the same challenges, but a packaged distribution can help somewhat.Creates silos: Having different OpenStack deployments across multiple geographies can create infrastructure silos. It’s possiblebut challenging to avoid with this model, and there is likelihood of creating redundancy and complexity that is difficult tomanage.AdministerSeveral hardware vendors have shipped products basedon this model, since it increases their margins (anddifferentiation from commodity, off the shelf hardware) andmore customer “stickiness” (difficult to change hardwareproviders if your cloud platform locks you in).Self-serviceThis model of OpenStack deployment involves avendor-provided hardware appliance that is installed onpremises, and ships with a vendor-supported OpenStackdistribution tailored to run on that hardware. Your compute, networking and storage infrastructure also runs onpremises.IT or Vendor ManagedPrivate Cloud in a Box?VM VMVMVM VMTypical vendors for this model:Cisco Metapod, Stratoscale, ZeroStackWho is responsible for the OpenStack lifecycle:Internal IT teamUsersIT AdminData Center 1Data Center 2Enterprise FirewallPrivate Cloud in a Box Pros: Time to value: Since vendors package hardware and OpenStack into a tightlyintegrated bundle, this model could offer very quick time to value.Potential reduction in operational risk: Operational risk reduction in this model issomewhat variable and vendor dependent. It is possible for this model to substantially reduce the operational risks in running OpenStack, provided the vendor hasthe right backend automation and support infrastructure.Figure 4: With private cloud in abox, a vendor-provided hardwareappliance is installed on premises,tying OpenStack to specifichardware nodes.5

Private Cloud in a Box Cons: Creates silos: Since OpenStack is now tied to specific hardware nodes, this model creates new infrastructure silos and doesn’tintegrate with existing or other hardware deployments; or other virtualization deployments in the enterprise.Hardware dependence: This model is restricted to the vendor-provided hardware, which may be suboptimal forenterprises that prefer a particular hardware provider, or can get preferential pricing on other solutions such as commodity-off-the-shelf-solutions. Often, this hardware dependence creates near- and longer-term pricing disadvantages for customers.Vendor lock-in: If the vendor were to go out of business, get acquired or have a change in strategy, customers risk endingup with a substantial investment that may no longer be supportable. For instance, early customers for some first-generationOpenStack providers had to write off their investments following the corporate developments at those vendors.Hosted Private CloudWho is responsible for the OpenStack lifecycle: VendorVM VMServiceProviderManagedService ProviderAdministerTypical vendors for this model are:IBM Bluebox, RackspaceData lives outsideyour premise Self-serviceThis model of deploying OpenStack involves using aservice provider to deploy a hosted private cloud in theservice provider’s data centers. The service provider isresponsible for installing, configuring, monitoring, upgrading and troubleshooting OpenStack as well as the customer’s compute, networking and storage infrastructure.This contractual model is usually based on service levelagreements (SLAs) and makes it simpler for organizationsbecause they are able to leverage the service provider’sdata centers, hardware, and OpenStack expertise.Untapped existing infrastructureVM VMVM VMHosted Private Cloud Pros: Time to value: Organizations who want a dedicatedprivate cloud without owning the hardware canquickly and conveniently deploy one.Operational risk: This model saves organizationsfrom the operational complexity of OpenStack, andvendor-provided SLAs reduce operational risk.UsersIT Admin Data Center 2Enterprise FirewallHosted Private Cloud Cons: Data Center 1Figure 5: In a hosted private cloudmodel, data lives outside theorganization’s premisesHardware dependence: The service provider’s choice of hardware dictates thehardware on which your private cloud will run.Creates silos: Existing infrastructure might be unused, leading to fragmentationand redundancy.Security: Workload data leaves your network perimeter; organizations must dependon the service provider to build a secure and operational OpenStack.Lock-in: There is 100% vendor lock-in with this model.6

OpenStack-as-a-ServiceWho is responsible for the OpenStack lifecycle: VendorAdministerTypical vendors for this model: Platform9Platform9ManagedSelf-serviceThe OpenStack-as-a-service approach combines theadvantages of the on-premises OpenStack distribution andthe hosted OpenStack models. Unique to Platform9, theOpenStack-as-a-service model provides the economics,data locality, and infrastructure choice of an on-premisesdeployment model with the convenience and operationalefficiency of hosted private clouds. Organizations that usePlatform9 Managed OpenStack host their data on theirown infrastructure while Platform9 hosts and manages theOpenStack control plane.Platform9ManagedOpenStackWorkload and data stay on premiseVM VMVM VMOpenStack-as-a-Service Pros: Set up in minutes: IT team members can build anOpenStack private cloud in minutes.UsersIT Admin Data Center 1 Data Center 2Eliminates silos: Platform9 provides a single paneof glass across geographies and differentEnterprise Firewallvirtualization platforms such as KVM, VMwarevSphere, and Docker.Figure 6: Platform9 manages theSecure: No workload data leaves the user’s network perimeter.OpenStack control plane in the cloudGreenfield and brownfield: Works seamlessly with existing or new infrastructurewhile leveraging and organization’sVendor independence: Since customers own the hardware and data, they are noton-premises infrastructurelocked into the OpenStack provider.Low operational risk: A guaranteed SLA removes operational risk for the OpenStackcontrol plane.OpenStack-as-a-Service Cons: HTTPs access: This model requires outbound, secure HTTPS access from theorganization’s servers to the Platform9 OpenStack controller.7