Red Hat Summit이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 15. Configure Load Balancing-as-a-Service with the Networking LBaaSv2 API
Load Balancing-as-a-Service (LBaaS) enables OpenStack Networking to distribute incoming requests evenly between designated instances. This step-by-step guide configures OpenStack Networking to use LBaaS with the Open vSwitch (OVS) plug-in.
Introduced in Red Hat OpenStack Platform 5, Load Balancing-as-a-Service (LBaaS) enables OpenStack Networking to distribute incoming requests evenly between designated instances. This ensures the workload is shared predictably among instances, and allows more effective use of system resources. Incoming requests are distributed using one of these load balancing methods:
- Round robin - Rotates requests evenly between multiple instances.
- Source IP - Requests from a unique source IP address are consistently directed to the same instance.
- Least connections - Allocates requests to the instance with the least number of active connections.
| Feature | Description |
|---|---|
| Monitors | LBaaS provides availability monitoring with the PING, TCP, HTTP and HTTPS GET methods. Monitors are implemented to determine whether pool members are available to handle requests. |
| Management | LBaaS is managed using a variety of tool sets. The REST API is available for programmatic administration and scripting. Users perform administrative management of load balancers through either the CLI (neutron) or the OpenStack dashboard. |
| Connection limits | Ingress traffic can be shaped with connection limits. This feature allows workload control and can also assist with mitigating DoS (Denial of Service) attacks. |
| Session persistence | LBaaS supports session persistence by ensuring incoming requests are routed to the same instance within a pool of multiple instances. LBaaS supports routing decisions based on cookies and source IP address. |
LBaaS is currently supported only with IPv4 addressing.
LBaaSv1 has been removed in Red Hat OpenStack Platform 11 (Ocata) and replaced by LBaaSv2.
15.1. OpenStack Networking and LBaaS Topology
OpenStack Networking (neutron) services can be broadly classified into two categories.
1. - Neutron API server - This service runs the OpenStack Networking API server, which has the main responsibility of providing an API for end users and services to interact with OpenStack Networking. This server also has the responsibility of interacting with the underlying database to store and retrieve tenant network, router, and loadbalancer details, among others.
2. - Neutron Agents - These are the services that deliver various network functionality for OpenStack Networking.
- neutron-dhcp-agent - manages DHCP IP addressing for tenant private networks.
- neutron-l3-agent - facilitates layer 3 routing between tenant private networks, the external network, and others.
- neutron-lbaasv2-agent - provisions the LBaaS routers created by tenants.
The neutron-lbaasv2-agent (with HAProxy) is deprecated. See Chapter 16, Load Balancing-as-a-Service (LBaaS) with Octavia for the preferred load-balancing reference implementation with Octavia.
The following diagram describes the flow of HTTPS traffic through to a pool member:
15.1.1. Support Status of LBaaS
- LBaaS v1 API was removed in version 10.
- LBaaS v2 API was introduced in Red Hat OpenStack Platform 7, and is the only available LBaaS API as of version 10.
- LBaaS deployment is not currently supported in Red Hat OpenStack Platform director.
The neutron-lbaasv2-agent (with HAProxy) is deprecated and no longer supported. See Chapter 16, Load Balancing-as-a-Service (LBaaS) with Octavia for the preferred load-balancing reference implementation with Octavia. The neutron-lbaas RPMs are still available to support the API for third-party plugin support.
15.1.2. Service Placement
The OpenStack Networking services can either run together on the same physical server, or on separate dedicated servers.
Red Hat OpenStack Platform 11 added support for composable roles, allowing you to separate network services into a custom role. However, for simplicity, this guide assumes that a deployment uses the default controller role.
The server that runs API server is usually called the Controller node, whereas the server that runs the OpenStack Networking agents is called the Network node. An ideal production environment would separate these components to their own dedicated nodes for performance and scalability reasons, but a testing or PoC deployment might have them all running on the same node. This chapter covers both of these scenarios; the section under Controller node configuration need to be performed on the API server, whereas the section on Network node is performed on the server that runs the LBaaS agent.
If both the Controller and Network roles are on the same physical node, then the steps must be performed on that server.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}