The Beginning: Planning a Production OpenStack Cloud Presented by Ben Silverman - Cincinnati Bell Technology Services Monday, May 13, 2019
Before we plan, ask yourself… 1. What is my mission with this cloud? 2. Do you have an internal champion? Do they have budget? 3. Does OpenStack fit with your corporate culture? 4. Do you have talent in-house to plan, deploy and operate OpenStack? 5. Are you considering a distribution, managed, or a DIY solution? 6. What will run on this cloud? Will it be built for VM’s, containers, bare metal or all of the above? 2
Action Plan 1. Define what use cases your enterprise needs for your first production cloud. 2. Identify any technical use cases or specific challenges in the business use cases. 3. Collect the capacity data of the use cases you want to bring. 4. Determine the size of your cloud and remember, clouds are elastic, and so is capacity planning. 5. Research the openstack projects you will need to satisfy your requirements. 6. Determine what OpenStack projects will satisfy this cloud’s needs and any expansion before the next upgrade. 7. Create your hardware architecture from business and technical objectives. 8. Create your deployment and execution plans. 9. Run unit tests on all components. Test capacity and high availability. 3
The Design Document Summary : This is simply a detailed summary of the entire document. Ø Typically, this part of the deliverable will be used by managers, technology, and business leaders to understand the business impact of the overall recommendation. Requirements and the resulting architecture should be summarized. Design review: This is the meat of the document. Requirements can Ø be in whatever format is acceptable for your project management team. Some prefer the user story format others simply prefer stated items. Hardware architecture : This is an explanation of roles and physical Ø machines that take those roles. This should include a network diagram. OpenStack architecture : This is a summary of available services and Ø their relationships. This section should include a service diagram. Roadmap : This section is optional and often lives in another Ø document. It's an opportunity to identify areas for improvement in future releases of the platform. 4
The Deployment Plan Summary : This is simply a detailed summary of the entire document. Ø Typically, this part of the deliverable will be used by managers, technology, and business leaders to understand the business impact of the overall recommendation. Requirements and the resulting cloud deployment plan should be summarized. Deployment: What will be deployed. This section contains detailed Ø information about hardware, software, and networking. Detailed bill of materials for each type of server or network component should be included as well as a network diagram down to the port level. Physical information is also located in this section. Execution : This section focuses on the responsibilities matrix for the Ø complete cloud build. This will also include testing. Day 2 Operations : This will consist of the operational plans for after Ø the cloud is built including governance, security, high availability, business resumption and disaster recovery. 5
Point of Departure Business drivers: Why is there a need for change? Current state: This section is to be used as a What are the expected outcomes? What benefit is reference and comparison to any proposed cloud the organization looking to achieve by design. This data will include the point of departure implementing an OpenStack cloud? architecture, including compute, storage and network. It will also catalog some of the operational data. Examples: Component Configuration Company XYZ is finding itself behind competitors in • regard to innovation because it cannot deliver Number of regions 1 infrastructure to developers quickly. Total number of nodes 160 The current virtualization platform ABC enterprises is • Total number of unique users 1 running is non-directional and expensive. Total number of instances 320 ElDinero Bank has data that it needs to process quickly • Total number of tenants 1 but it cannot leave the datacenter. Scaling takes too long with traditional infrastructure. Block Storage backend VSAN Image backend vCenter Joe Telco wants to be able to scale in and out it’s • network functions and run them virtualized. Ephemeral storage ESX Object storage N/A College University has genome sequencing to process • but struggles with setting up the infrastructure for big Other storage NAS data. Guest OSes Centos 7 6
Point of Arrival Solution Principles: Specific principles that a solution Technical Principles/Requirements: Several will have to adhere to regarding capabilities and technical principles that need to be met regarding requirements. technical capabilities and requirements. Term Definition Term Definition Application Deployment of applications onto infrastructure Scalability Ability to support up to 320+ Compute nodes in 52 Deployment via a single tool that uses an open API Datacenters (52 clouds) initially. Growing to 450+ total nodes as a roadmap item with a 2-year Single-Region Authentication, authorization and access from outlook. an integrated solution in the same region Network Ability to support a private IPv4 tenant network Configuration Ability to have a persistent storage mechanism environment in a single cloud. That supports Portability to store configurations for each application in hundreds of Compute nodes. region. Storage Support persistent and ephemeral storage Elasticity Ability to scale up and scale down based on Upgrade Must be on a commercial OpenStack distribution increased tenant demand with a manufacturer documented upgrade path Faster, more Creating deployment methodology that and long-life releases. reliable IaaS supports repeatable and reliable deployments of the JBS application in all of its variations. 7
Putting It All Together Define the business challenges we’re trying to solve and outcomes we’re looking to achieve from the LOB owners: Reduce cost • Reduce time to market • Provide on-demand infrastructure on-premise (like AWS) • Record the technical objectives As a technology leader I want to: • Serve up multiple tiers of self-service storage • Provide a multi-tenant architecture with network • isolation Leverage commodity hardware for compute • Record any assumptions, capabilities or requirements of the platform: Need a single tier of storage with > 2000 IOPS of read/write • performance per instance Tenants must have network isolation • Must be able to deploy applications in a non-shared • compute manner for HA/DR (anti-affinity) Technical Architecture/OpenStack Architecture: Remember to support the business and technical objectives • Create a MVP design that supports the most pressing and • important business and technical objectives Keep it simple (KISS) • Cost is always a consideration, treat it like your money • 8
Physical Architecture Architecture Plan Ø Categories of hardware Ø Compute Ø Storage Ø Network Ø Role Categories (OpenStack Architecture Design) Ø Compute Plane Ø Control Plane Ø Should consist of everything needed by an OpenStack Engineer to deploy the cloud 9
OpenStack Architecture Most Common OpenStack Architecture Categories Ø Compute Plane Ø Requirements are defined by expected workloads Ø High availability is designed in by horizontal scaling and availability zones Ø Bigger isn’t always better, scale out, not up Ø Control Plane Ø Requirements are driven by the services that will be installed Ø Typically no less than three servers Ø High availability is handled by load balancing and clustering Others can include: Storage Plane, Dedicated Network Plane, Cell Structure, etc. 10
What is Network Functions Virtualization? Simply put, a new way to define, create, and manage multiple • network functions by replacing dedicated network appliances with software and automation The software that replaces the hardware function is called a Virtual • Network Function (VNF) Useful for mobile gateways and for related functions like MME, SGW, • and PGWs. NFV is not SDN but they can compliment each other. • 11
12
Special Use Architectures 13
14
Lab: Thinking about the future, especially about 5G and edge technologies… How does OpenStack fit? What are some of the challenges that might arise due to edge use cases? 15
Developing The Final Deployment Plan In review: Overview that includes: Business drivers • Operational and technical challenges • Design principles • Technical principles. • Technical Architecture Recommendations Compute, network and storage hardware • Rack layouts • Wiring and physical network layouts • OpenStack Architecture Recommendations Projects beyond OpenStack core • Setting up availability zones and failure domains • Logical network layout • Security concerns • Plug-ins for storage and network • 16
Recommend
More recommend
