Audience: Advanced About: The “infrastructure as code” configuration management in Helion OpenStack 2.1 is done using Ansible. This session will explore the step by step approach to deploy 4 popular use cases configuring advanced Neutron Deploy a Load Balanced 2 tier infrastructure (Using Oracle and Tomcat) that leverages LBaaS v2. How to perform proactive autoscaling by code – and bypassing the LBaaS v2 lack of integration with Heat / Ceilometer. FWaaS use case to block by code certain ports in our two tier infrastructure while allowing your end users to still reach the core services. Configure a VPNaaS across two separate OpenStack clouds. In this use case our web services are running in one OpenStack cloud (could be a public cloud) while our database services are running safely on premise in a separate private cloud. VPNaaS will allow the comminication between Tomcat in our “public” cloud and Oracle in our “private” cloud. This is transparent to the end user. Baremetal provisioning with Ansible playbooks: A quick demo to showcase the configuration management capabilities of Ansible when dealing with baremetal provisioning leveraging cobbler and IPMItools. Speaker Bio: Anthony Rees – Cloud Technical Consultant / Architect, Hewlett Packard Enterprise Anthony has over fifteen years experience in software design, architecture, cloud solutions and development activities. During this time he has utilised his consulting skills as a support to major organisations around the world. Anthony has a keen interest and vast experience in Continuous Delivery working with many teams in various countries to implement Test Driven Development techniques, Feature Toggling best practices, Platform as a Service designs, Infrastructure as a Service, Build Automation, OpenStack and leverage DevOPS methodologies. He is experienced in Agile methodologies such as Lean, XP, Scrum and certified as a Scrum Master and SAFe Scaled Agilist. Speaker Bio: Alex Tesch – APJ Cloud Consultant, Hewlett Packard Enterprise Alex has been working with Open Source enterprise technologies for the better part of his 12 years IT career in companies like Hewlett-Packard Enterprise, Red Hat and IBM. He started his OpenStack journey with Grizzly, delivering the first HPC cloud in APAC for a Singapore University making use of SRIOV technologies combined with big data. He has extensive deployment experience on configuration management and automation of private cloud based on OpenStack. Alex is currently an APJ Cloud Consultant in the Helion Cloud team at Hewlett-Packard Enterprise, where he evangelizes the OpenSource side of the Helion portfolio (OpenStack / Cloud Foundry / Ceph). He enjoys running workshops and seminars in the APJ region for cloud adopters. OpenStack Australia Day Sydney 2016 https://events.aptira.com/openstack-australia-day-sydney-2016/

1. OpenStack® Summit Austin 2016
OpenStack® Summit Austin 2016
Infrastructure as Code in OpenStack
with Ansible
Alex Tesch
Cloud Consultant
@tesch75
Anthony Rees
Cloud Consultant
@anthonyrees

2. Advanced Neutron Use Cases
What will we cover ?
– LBaaS
– Proactive auto Scaling
– FWaaS
– Dynamic security
– VPNaas
– Connecting two clouds
– Bare Metal as a Service
2

3. LBaaS
Load Balancer as a Service
3

4. Load Balancer as a Service
Why was the customer interested in LBaaS?
– Auto scaling via threshold
– Variety of load balancers supported
– Control load balancers by code
4

5. Current Neutron Limitations
How do we overcome them?
LBaaS v2 Limitations in current enterprise distros
– Lack of Autoscaling capabilities using the traditional scaling group approach.
– Instead of using Ceilometer / heat to trigger the autoscaling, we decided to use an
enterprise monitoring tool to keep track of the CPU utilisation in the Tomcat instances
and use scripts to trigger the scale up / down once thresholds are reached.
– No HA capabilities for LBaaS v2 control plane and data plane.
– An external HW Load Balancer with supported LBaaS v2 API can be used to achieve
HA in the data plane. HA for the control plane remains a concern…
5

6. Current Neutron Limitations
How do we overcome them?
LBaaS v2 Limitations in current enterprise distros
– The LBaaS agent runs inside the kernel namespaces of the network node or
compute (when DVR is used). If the network node is down, the kernel
namespace is gone and there is no way to bring up the load balancer in an
alternate network node.
– This limitation will be addressed by Octavia in the next Enterprise release.
6

7. Current Neutron Limitations
How do we overcome them?
LBaaS v2 Limitations in current enterprise distros
– No Horizon integration
– LBaaS needs to be managed from neutron CLI or using API (This is not a bad thing).
– LBaaS v2 has no integration with Heat. (This is a bad thing…)
– The work around presented in the demo makes possible to orchestrate a full two tier
infrastructure (Tomcat / Oracle) combining heat orchestration templates with neutron
API calls driven from a single Ansible playbook or a single shell script.
7

8. FWaaS
Fire Wall as a Service
8

9. Fire Wall as a Service
Why was the customer interested in FWaaS?
– Simple interface for Firewall
– Dynamic changes applied | No restart required
– Control the Firewall via code
– Advantages beyond what’s offered by Security Groups for LBaaS
9

10. Current Neutron Limitations
How do we overcome them?
FWaaS v1 Limitations in current enterprise distros
– This is by no mean an Enterprise HW firewall replacement.
– External FW support is in place for major vendors (checkpoint, Brocade,
– If DVR is enabled the firewall service does not filter east / west traffic, only
north south traffic is filtered.
– A combination of security group policies / FWaaS can be used to address this.
10

11. Current Neutron Limitations
How do we overcome them?
FWaaS v1 Limitations in current enterprise distros
– Security groups are not able to block ICMP targeting the LBaaS floating IP
(since the LBaaS is an agent, not a VM) FWaaS can address this (as shown in
the demo).
11

12. VPNaaS
Virtual Private Network as a Service
12

13. VPN as a Service
Why was the customer interested in VPNaaS?
– Securely connect two clouds to create a ‘region’ like experience
– Enable ‘Back-end’ as a Service
– Enable ‘Bi-Modal’ IT
– A way to link legacy systems of record, databases etc. to cloud instances
13

14. VPN as a Service
How it works
14
Site A
(Private Cloud)
Site B
(Public Cloud)
DB
Web
Web
Web
IPSec Site Connections

15. Current Neutron Limitations
How do we overcome them?
VPNaaS limitations in current enterprise distros
– VPNaaS doesn’t work with FIP if DVR is being used.
– VPNaaS currently supports only Pre-shared keys (PSK).
– If certificate based security is required, VPNaaS is not a viable option in the current
enterprise distributions.
15

16. Current Neutron Limitations
How do we overcome them?
VPNaaS limitations in current enterprise distros
– The VPNaaS implementation is based on OpenSwan which runs an ipsec
process as root in the network nodes. A vulnerability in this process could lead
to a root compromise in the network nodes.
– If this is a major concern, operators should consider deploying additional protection
mechanisms.
16

17. BMaaS
Bare Metal as a Service
17

18. Bare Metal as a Service
Why was the customer interested in Bare Metal?
– Automated way to add compute nodes to their cloud
– Automated way to provision Bare Metal for applications that don’t perform on
cloud instances
– Control bare metal via code
– One code base to control cloud instances or bare metal
18

19. Bare Metal Provisioning
Provisioning new servers into the cloud
The Ansible Model
– The model holds existing and new
bare metal servers
19

20. – Ansible passes the metadata required
to Cobbler
– Ansible configures the DHCP server
for the new bare metal machine
20
Bare Metal Provisioning
Provisioning new servers into the cloud
The Ansible Model

21. – Ansible powers up the new bare metal
machine
21
Bare Metal Provisioning
Provisioning new servers into the cloud
The Ansible Model

22. Thank you
22