The document discusses challenges in migrating from a traditional infrastructure to OpenStack. It outlines some initial steps such as mapping current infrastructure components to OpenStack services and identifying initial workloads. It also covers some technical challenges around deploying and managing OpenStack components like Compute, Networking, Storage, Identity Management and upgrades. The document shares a case study of Oracle Product Development IT's migration of 14,000 VMs to OpenStack.

2. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Thinking of Migrating your Traditional
Infrastructure Management to
OpenStack?
Avi Miller: Product Management Director
OpenStack Australia Day 2017

3. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
3

4. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Creating a cloud infrastructure
4

5. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Challenges Involving OpenStack Adoption
• Deployment is perceived to be difficult
• Concerns over downtime during implementation and maintenance
• Rapidly changing solution – how does an enterprise mitigate risk?
• Understanding how to integrate OpenStack with existing business
requirements and practices
• Concerns involving interoperability Issues
• Finding resources with the right skills to implement, deploy and maintain
5

6. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Where to begin?
• OpenStack delivers a number of services for creating private cloud
infrastructure – begin by mapping services available to your datacenter
• What does your current infrastructure look like? Begin with an inventory:
– Bare metal, virtualized, containers, all of the above?
– Deployment and provisioning; systems management
– Networking topology
– Storage solutions – what vendors are you using today
– Identity management
– ISVs and IHVs
• What workloads should you target for your first phase of deployment?
6

7. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Example of Workloads Deployed in OpenStack
1. Software development / Test / QA / CI
2. Web services and e-commerce
3. Network Functions Virtualization
4. Storage / Backup / Archiving
5. Big Data Analytics / Data Mining
7
Listed in the order of highest to lowest in production
http://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf

8. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Compute Services
• Multiple options for compute services
– Bare metal
• Ironic (Technology Preview)
– Virtualization
• KVM
• Oracle VM Server
• Hyper-V
– Containers
• Docker
• LXC
Note: Automation in deployment options is still evolving.
8
Bare metal, virtual machines or containers

9. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Managing Compute Nodes
• Overcommitting memory
– Can lead to big performance problems
– Not supported under Oracle VM Server
• Oracle Database
– CPU overcommit with RAC is unsupported – you can receive node evictions
• Ephemeral Storage
– If you do not use shared (CEPH) backend you cannot live migrate instances
9

10. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Networking with Neutron
• Best Practices
– Use Distinct Physical Networks if at all possible
• Management
• API
• Guest (Tunnel)
• Storage
• External
• Known Issues
– Large Deployments
• Neutron Gateway or Network node
10

11. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Storage with Cinder and / or Swift
• Cinder
– Default storage is LVM
• For optimum performance and management you actually need an array (ZFSSA, FS1)
• Swift
– Backend file system does matter
• Optimize storage nodes for inode and dentry caching
11

12. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
MySQL and High Availability
• Known issues
– Large OpenStack deployments require significant amount of performance from the
backend MySQL database
– Bottlenecks communication between services
– Implemented MySQL Cluster to help mitigate the issue, but it still exists
12

13. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Identity Management with Keystone
• Known Issues
– Today UUID tokens are the default, which go into the MySQL database, the token
table needs to be monitored and managed
– Emerging - Fernet tokens do not use the same process
• This will be the standard beginning with Newton
• Available in Mitaka – we will migrate to this at some point
• Integration with identity management like Active Directory, LDAP
– In most cases will require engineering effort to work properly
13

14. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Upgrades and Migrations to OpenStack Infrastructure
• Docker vs RPM based distro
– How does Docker help with upgrades and migrations?
– RPM distro involve hundreds of packages and dependencies
– Docker simplifies this from an upgrade/migration perspective
– Allows us to focus on individual services
14

15. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Case Study: Oracle Product Development IT
Building a cloud infrastructure to support devops at Oracle
15

16. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Oracle Product Development IT
• Oracle PDIT moved 14,000 VMs from traditional IT infrastructure to
OpenStack Cloud in two datacenters
– Goal: 150,000 VMs by end of CY2017 in 8 data centers
• Why transition to cloud ?
– Transforming IT to a self service organization
– Translating everything IT provided to DevOps to self service
• Change DNS name, change network, Add firewall, Remove firewall, storage services,…….
• DevOps are used to working with API
– Supplying an API to them versus doing it for them. A huge library of services with
OpenStack API http://developer.openstack.org/api-ref.html
• Although initially skeptical of the Open Source, internal DevOps customers were very excited with
the rich set of services with the extensive API in OpenStack
16

17. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Transitioning Obstacles
1. Fear of failure by many in IT’s internal staff
– Skepticism and lack of confidence: OpenStack is new and it will fail. We will need to
add layers of IT people to correct errors
– Industry statistics >75% of OpenStack private clouds fail within one year
–How it was addressed?
• Set-up a separate test environment, for the IT org only, that they could use to get used to OpenStack
and test out any control plane changes.
17

18. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Transitioning Challenges
• Biggest Challenge: Mindset and cultural change
– Internal Customers: Mentality of HW Ownership and Control.
• In the traditional IT infrastructure the Business Units purchased the infrastructure HW and had
control on which HW their VMs were running
• In cloud - they do not control or know where their VMs run. Fear of
– Giving-up control on their infrastructure HW and transitioning from the physical to logical world
– Depending on the pool of resources (that are up all the time)
• What won them over?
• Extensive education on how to adopt to the changes and benefits
• Little change in the approach for DevOps – it is still API based
– Availability of very large and flexible choice of OpenStack API services
– Less manual intervention and automation
18
Cultural Change

19. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Transitioning Challenges
• Biggest Challenge: Cultural Change
– Quota
• Legacy: Largely defined by ownership of hardware.
• Private Cloud: Ownership transitions from physical to guaranteed allocations.
– Tools
• Huge investment over the years in the legacy tools used to set up the environment in a certain way
• Transition to OpenStack tools that provide, out of the box, tools which are superset to legacy
– Different than what they were used to.
– Understanding of multi-tenant and how it can be applied to their environment.
19
Cultural Change (Cnt’d)

20. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Transition Challenges
• Mix of early adopters and skeptical late followers
– Majority (over 50%) were immediately interested in consuming new API end points.
Saw the advantages of multi-tenant environment.
– However a few smaller groups insisted on adding an abstraction layer to make it look
like their legacy environment (just a web interface for service tickets and a farm of
hypervisors)
• More education, compromises until these groups and management saw the evidence of benefits
• Take away:
– Different degree and different timelines for adoption within different groups. Need to
make a compromise and provide an interim step for some of them
• until they are convinced with evidence from the early adopters to justify the change
20
Technology adoption

21. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Traditional IT Infrastructure
• A lot of manual interaction
– Web interface but for creating service
tickets (not self service)
• Lack of flexibility
– Legacy VM was very primitive with rigid
disk and 4 hrs to provision
OpenStack Cloud
• Storage for VM any size and resize
by the end user within 30 seconds
• Cinder allows multiple back-end
solutions
– Premium charge customers can get
connected to ZFSSA for high IOPS and
performance
– Customers needing storage and lots of
storage (majority of the customers)
could use CEPH
21
Examples of Automation and New Services: Storage

22. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Traditional IT
• Lead time of a few days to weeks to
provision VLANs, subnets, firewalls
OpenStack Cloud
–Instant self service to Dev Ops.
OpenStack API for
• Create/delete networks, subnets, ports, routers
• Load balancers, firewalls, security groups
• VLANs, VXLANs, GRE
22
Example of Automation and New Services: Networking

23. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Traditional IT
• Separate teams and owners for
– Servers
– Networking
– Storage
• Network IT staff knows how to
directly manage the networking
hardware (switch, router)
OpenStack Cloud
• Team members need expertise in
both server and networking to
diagnose issues
– With SDN the demarcation is blurred
between servers and networking
– Storage is also more integrated with
servers and networking
23
Operational – Resources

24. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
General Comments
24

25. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
• Elasticity and Demand
– Cloud computing offers better elasticity
than traditional infrastructure models.
• Require more attention to capacity
management to ensure resources are
available as service demands scale
• Chargeback or Showback
– Accounting decision
• Should not impact your operations
– Provides insight into IT resource
consumption to the lines of business.
• Help to control cost, justify consumption and
demonstrate business value
• Staffing you will need
– Cloud architect
• Works with the OpenStack distro provider
and datacenter architects to design the
control plane.
– Service Transition
• Install and configure cloud services based on
design specs.
• Develop operational procedures appropriate
to the design.
– Cloud operator
• Day-to-day management and responsible for
performance and capacity monitoring,
troubleshooting and security.
25
Cloud Elasticity, Chargeback and Staffing
https://www.openstack.org/assets/path-to-cloud/OpenStack-6x9Booklet-online.pdf

26. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
Stay connected
26
@ORCL_Linux
Facebook.com/OracleLinux
Blogs.oracle.com/linux
Oracle Linux Experts Group
YouTube.com/OracleLinuxChannel
Or visit us at: www.oracle.com/linux
@ORCL_Virtualize
Facebook.com/OracleVirtualization
Blogs.oracle.com/virtualization
Oracle VM Group
YouTube.com/OracleVirtualization
Or visit us at: www.oracle.com/virtualization

27. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | 27