Composable IaaS+ and future. Sergey Goncharov Solution Architect, Red Hat

Transcription

1 Composable IaaS+ and future Sergey Goncharov Solution Architect, Red Hat 11

2 Red Hat OpenStack Platform Core

3 OpenStack connects two worlds Tenant view Operator view Developers 3 Red Hat OpenStack Platform Administrators

4 Core Components in version 11 (Ocata) DATA PROCESSING TELEMETRY SHARED FILESYSTEM ORCHESTRATION SHARED SERVICES DEPLOYMENT and MANAGEMENT IDENTITY DIRECTOR IaaS+ CEILOMETER SAHARA STORAGE COMPUTE NETWORKING BLOCK IMAGE OBJECT GLANCE SWIFT KEYSTONE HEAT MANILA BARE-METAL PROVISIONING DASHBOARD IaaS NOVA CINDER NEUTRON IRONIC HORIZON Certified Red Hat OpenStack Platform plugins: 4 Red Hat OpenStack Platform TRIPLEO

5 OpenStack connects two worlds Tenant view the actual OpenStack IaaS user Limited by what the Operator decides to offer in that cloud Operator view often the same role that has root access to the systems Combines configuration files and API actions to create a working environment for his tenants. Tenant view Operator view 5 Red Hat OpenStack Platform

6 OpenStack connects two worlds Both can use Horizon, the CLI tools, a library (such as os_cloud in Ansible or boto in Python) or directly the API using HTTP and JSON/XML via curl/wget. OpenStack policy engine (Policy.json in Keystone) will filter which API calls require administrative privileges (i.e. the operator) or regular tenant privileges. The use of Keystone Domains (in v3) allows an intermediate role: domain_admin CloudForms also offers a Cloud Admin view and a User Portal with the available services. 6 Red Hat OpenStack Platform

7 Red Hat OpenStack Platform Composable IaaS and Director

8 Red Hat OpenStack Platform Director API driven deployment (and management) of Red Hat OpenStack Platform. Safely upgrade and update production OpenStack deployments with modular roles and upgrades. Integrated Ansible-based validations and upgrade logic. Configuration stored as YAML code; Operators can configure the datacenter's attributes accordingly (e.g VLAN, IP ranges). CLI based on standard OpenStack interfaces. Leverages best practices and reference architectures from our extensive field experience. Out-of-the-box Control Plane HA thanks to Pacemaker. External load balancer support. Ceph deployment and configuration as storage backend. Can connect to existing Ceph. Co-locate storage components on compute infrastructure - deploy Ceph OSD's on compute hosts from Director with full production support and tuning advise. Supported partner hardware integration (Ironic, Cinder, Neutron) Cisco UCS, Dell, Intel, HP, Fujitsu, SeaMicro, and Open CloudServer Cisco Nexus 1000v (networking) and other SDNs Netapp Data ONTAP (Cinder storage) and other Storage 8 Red Hat OpenStack Platform

9 Director: building scalable clouds Scales to hundreds of nodes, automating the whole hardware lifecycle. Pattern-based automatic discovery and selection of appropriate nodes from hardware inventory. Automatic Health Check can execute performance test before deployment to identify possible misconfigurations or faulty servers. Ability to validate installation post deployment using Tempest and Ansible scripting Easy to scale up and down - add compute and storage capacity (see deployment limits) Enhanced management via CloudForms, for both tenants and administrators. Increasing support for GUI-based deployments using the director UI. Flexibility to deploy HA services independently increasing architectural flexibility. Nova EC2 API deployable from director as a custom role. 9 Red Hat OpenStack Platform

10 Director Validations (Undercloud) Ansible-driven solution to catch potential hardware, networking and deployment issues - reduces deployment failures Simplify the burden on IT staff by providing recommended configuration solution settings when issues are detected Help customers to achieve production-ready deployments through entire process Pre-installation (prior to starting deployment) Post-installation (checks after deployment) 10 Upstream project: CLI and GUI compatability Red Hat OpenStack Platform

11 Default Roles 5 default roles cover the majority of deployment requirements: Controller Compute BlockStorage (cinder) CephStorage (OSD) ObjectStorage (Swift) Operators can easily customize and create their own roles! Further tuning available as post-installation scripts 11 Red Hat OpenStack Platform

12 Composable Roles and Custom Services Distribute services to individual nodes or group in ways specific to your data center and architecture requirements. 12 Red Hat OpenStack Platform

13 Composable Roles and HA Services MyController MyDatabase MyMessage HA Proxy Galera Cinder-vol Redis... RabbitMQ HA-managed (ie pacemaker) services can now be placed outside controller using a custom role. Still a single, primary pacemaker cluster per deployment; all constraints and cluster logic is managed for you. Flexibility in architectures for security, load, scale. Please note: Changing pacemaker-managed services in a running overcloud should only be done in consultation with Red Hat support services. 13 Red Hat OpenStack Platform

14 Composable Upgrades Each service's Heat template now has an upgrade_tasks parameter as part of its outputs section. This is a block of Ansible formatted code to handle all the upgrade procedures. Each Ansible task receives a tag value to allow heat to step through the code and execute in the correct order. Tags define an order of operations for running the tasks, ensuring full control of upgrades across services. Director puppet/services/service.yaml 14 Red Hat OpenStack Platform Outputs:... upgrade_tasks: - name: Check pacemaker cluster running before upgrade tags: step0,validation pacemaker_cluster: state=online check_and_fail=true async: 30 poll: 4 - name: Stop pacemaker cluster tags: step2 pacemaker_cluster: state=offline - name: Start pacemaker cluster tags: step4 pacemaker_cluster: state=online - name: Check pacemaker resource tags: step4 pacemaker_is_active: resource: "{{ item }}" max_wait: 500 with_items: {get_param: PacemakerResources} - name: Check pacemaker haproxy resource tags: step4 pacemaker_is_active: resource: haproxy max_wait: 500 when: {get_param: EnableLoadBalancer}

15 Composable Upgrades Director major_upgrade_steps.j2.yaml puppet/services/service.yaml Heat will iterate through the roles and services and join all the upgrade_tasks together into a playbook. It then executes the plays, by tag, moving through the upgrade procedure in the correct order. Service upgrades can be batched but default to one at a time. 15 Red Hat OpenStack Platform... # Upgrade Steps for all roles {%- for step in range(0, upgrade_steps_max) %} # Config resources for step {{step}} {%- for role in roles %} {{role.name}}upgradeconfig_step{{step}}: type: OS::TripleO::UpgradeConfig # The UpgradeConfig resources could actually be created without # serialization, but the event output is easier to follow if we # do, and there should be minimal performance hit (creating the # config is cheap compared to the time to apply the deployment). {%- if step > 0 %} {%- if role in enabled_roles %} depends_on: - {{role.name}}upgrade_step{{step -1}} {%- endif %} {%- endif %} properties: UpgradeStepConfig: {get_param: [role_data, {{role.name}}, upgrade_tasks]} step: {{step}} {%- endfor %}

16 Composable Upgrades Roles can be blocked from automated upgrade by using the disable_upgrade_deployment: True option in their role definition. By default Compute and ObjectStorage have this value set. Roles Controller CephStorage BlockStorage Etc major_upgrade_steps.j2.yaml Tag puppet/services/service.yaml ObjectStorage disable_upgrade_deployment: True Compute 16 Red Hat OpenStack Platform

17 Deploy new roles to running Overcloud Base Custom Post-deploy Roles can be deployed independently after initial deployment Allows for more scale out and customized architectures Cannot remove services from old roles; this is for addition only Please note: Changing pacemaker-managed services in a running overcloud should only be done in consultation with Red Hat support services. 17 Red Hat OpenStack Platform

18 NFV Installations with Director Director allows an operator to define advanced resource partitioning at deploy time with control of: NUMA/CPU pinning, Hugepages, IRQ isolation, SR-IOV, OVS+DPDK all via composable roles. SR-IOV Deployment (DPDK guest) 18 Red Hat OpenStack Platform OVS+DPDK Deployment (DPDK guest)

19 WIP

20 Implement Keystone Trusts for Glance Image store trust 4. trust_id Keystone In some cases Glance has long running operations for things such as large images or complex operations that outlive the time granted to a user token. If a user token has expired any request initiated by Glance which needs a valid user token will fail. This causes the original user s request to also fail, even though the token was originally valid when passed to Glance. In Red Hat OpenStack Platform 11 Glance introduces the use of Keystone Trusts to maintain this authentication and avoid token expiration. 3. trust_id 2. trust 1. Image 20 Red Hat OpenStack Platform How this works 1. Glance receives request for image upload. 2. Before upload begins Glance creates a trust with knowledge of token, roles, project, trustees 3. Glance gets token and trust_id and keeps for entire operation. Image upload is initiated. 4. If further authentication is required Glance requests the new token using the trust_id 5. The upload operation completes.

21 Co-Locate Ceph on Nova Compute Ceph compute co-location is now fully supported in production using composable roles and with increased documentation Co-locates Ceph OSDs on the Compute nodes - Useful for NFV use cases - Reduce hardware requirements - Requires performance tuning Updated Reference architecture Support for both converged and non-converged infra using custom roles 21 Red Hat OpenStack Platform

22 Features in Tech Preview* Storage features available but not fully supported yet. Not for use in production environments. RBD Cinder Volume Replication driver Cinder support for Ceph RBD Mirroring Uses latest Cinder replication API Support for DR more easily from API Cinder active/active service Run more than one Cinder service at a time Increase SLA and throughput Numerous improvements to Cinder Cinder Replication Cinder HA CephFS Native Driver Enhancements Manila Increases integration between Ceph and Manila. Read-only share support LBaaS v2 Octavia Implements LBaaS v2 via Virtual Machines. Deployed via Director Moving out of Neutron into standalone project *Tech Preview features are subject to change in GA release 22 Red Hat OpenStack Platform Red Hat Open

23 SR-IOV Partitions high-performance network cards (NIC) in Virtual Functions (VF), each with its own PCI IDs. Some NICs support hardware-based VLAN tagging and other offload techniques (IOMMU, etc) Nova doesn t understand SRIOV VFs, so in the past it could only perform a basic PCI Passthrough With Neutron, we can perform two things (not simultaneously, mutually exclusive) VF passthrough: Nova tells KVM to passthrough all IO from a VM to the unique PCI ID of the VF. Each active VM gets a fraction of NIC bandwidth PF passthrough: Nova will only allow one VM to use the NIC, thanks to passthrough of the root PCI ID. That VM gets all the physical bandwidth VM must use the NIC-specific driver. 23 Red Hat OpenStack Platform

24 DPDK-Accelerated OVS The Hypervisor now has a user-space only version of OVS accelerated by DPDK, transparent to tenants. It s an alternative to classical OVS (kernel datapath) It allocates a NIC and a CPU to execute the Poll Mode Driver, bypassing the kernel, dramatically increasing the overall performance It achieves maximum throughput with low latency, even with small packet sizes, for both net-to-vm (uses VFIO) and VM-toVM traffic (uses virtio vhost-user) Requires hugepages and CPU pinning No security-groups, linux-bridge, QoS, etc Flat or VLAN only. VXLAN not recommended Only certain NICs supported 24 Red Hat OpenStack Platform

25 OVS and DPDK Versions in Red Hat OpenStack Platform 11 DPDK Designated as a Long Term Support release (LTS) DPDK Brings NUMA-awareness to openvswitch-dpdk by upstream (does not affect OSP release cycle). Backported by Red Hat for ovs-dpdk (replacing DPDK 16.07) is the base release for all DPDK stable releases and guarantees a two-year upstream maintenance cycle. deployments. Virtual host devices comprise of multiple different types of memory which should all be allocated to the same physical node uses NUMA awareness to achieve this in some of the following ways: advanced supporte d intelligent OVS 2.6 Maintains currency and ensures feature set is updated. Paves the way for future performance improvements, enhancements and OVN support. 25 Red Hat OpenStack Platform removes the requirement for a single device-tracking node which often created performance issues by splitting memory allocations when VMs were not on that node. NUMA ID s can now be dynamically derived and that information used by DPDK to correctly place all memory types on the same node. DPDK now sends NUMA node information for a guest directly to OVS allowing OVS to allocate memory more easily on the correct node removes the requirement for poll mode driver (PMD) threads to be on cores of the same NUMA node. PMDs can now be on the same node as a device s memory allocations.

26 VLAN-Aware VMs Full Support A VLAN aware VM is an OpenStack instance with multiple VLANs presented to it on a single virtual network interface card (vnic). This is known as a Neutron TrunkPort. A Neutron TrunkPort is a subport to a normal Neutron port; each subport can carry a unique VLAN. The parent port then becomes a trunk, delivering the subport VLANs to the VM on a single interface. There are multiple use cases for this functionality, ranging from ease of operations around instance management to NFV VNF network isolation requirements. 26 Red Hat OpenStack Platform

27 VLAN-Aware VMs Full Support With Subports each VLAN can be presented to the instance via its own tagged interface. This greatly reduces complexity around the management of the instance. 27 Red Hat OpenStack Platform Image: Create Commons:

28 Ironic Highlights New ironic inspector plugin processes Link Discovery Protocol (LLDP) packets during introspection. Data is stored in Swift and can be used to see state and configuration of network equipment. This helps to greatly reduce deployment issues around network configuration and troubleshooting. Ironic services for the Overcloud now support deployment in a composable role. Resource intensive services can be placed on their own servers if required. pxe_ssh, used for power management of virtual servers in lab environments is now deprecated and replaced with VirtualBMC. This allows operators to use an ipmi-like interface with virtual hosts, improving ease of use of lab and non-production deployments and ensuring more correlation of procedure between production and non-production. The Ironic CLI gains graceful shutdown and NMI support. This allows baremetal to tenant users the ability to better control physical hardware power requirements. 28 Red Hat OpenStack Platform "switch_port_mtu": 9216, "switch_port_id": "554", "switch_port_physical_capabilities": [ "1000BASE-T fdx", "100BASE-TX fdx", "100BASE-TX hdx", "switch_system_name": "sw01-dist-1bb12.rdu2", "switch_port_link_aggregation_enabled": false, "switch_port_link_aggregation_support": true, "switch_system_description": "Juniper Networks, Inc. ex t, version 12.3R6.6 Build date: :38:30

29 VMWare support Red Hat OpenStack Platform supports the VMware vcenter hypervisor driver. See the VMware Integration Guide Networking must be provided by a combination of either Neutron/NSX or Neutron/Nuage Red Hat does not provide support for other Compute virtualization drivers such as the deprecated VMware "direct-to-esx" hypervisor, and non-kvm libvirt hypervisors. 29 Red Hat OpenStack Platform

30 THANK YOU plus.google.com/+redhat facebook.com/redhatinc linkedin.com/company/red-hat twitter.com/redhatnews youtube.com/user/redhatvideos