1. Cấu hình HAProxy.
Phần này sẽ nói về cách cấu hình các dịch vụ không trạng thái (stateless) như API services và load balancer, cụ thể là HAProxy.
HAProxy là một reverse proxy và load balancer HTTP nhanh và đáng tin cậy cho các ứng dụng TCP hoặc HTTP. Nó đặc biệt phù hợp cho việc crawling web dưới tải rất cao trong khi cần duy trì hoặc xử lý tầng 7. Nó hỗ trợ thực tế hàng chục nghìn kết nối với phần cứng gần đây.
Tài liệu tham khảo https://docs.openstack.org/ha-guide/control-plane-stateless.html.
Mỗi phiên bản của HAProxy cấu hình phía trước của nó để chỉ chấp nhận kết nối đến địa chỉ IP ảo (VIP). Phía sau của HAProxy (điểm kết thúc) là danh sách tất cả các địa chỉ IP của các phiên bản để cân bằng tải.
Lưu ý rằng bạn nên đảm bảo cài đặt HAProxy của bạn không phải là một điểm đơn lẻ gây ra lỗi, nên có nhiều phiên bản HAProxy đang chạy.
Bạn cũng có thể đảm bảo sự sẵn có bằng các công cụ khác, sử dụng Keepalived hoặc Pacemaker.
Hoặc bạn có thể sử dụng một load balancer thương mại là phần cứng hoặc phần mềm. Chúng tôi khuyến nghị sử dụng load balancer phần cứng vì nó thường có hiệu suất tốt.
Để biết hướng dẫn chi tiết về cách cài đặt HAProxy trên các node của bạn, hãy xem tài liệu chính thức của HAProxy.
Tìm phiên bản HAProxy của bạn trên mỗi controller OpenStack trong môi trường của bạn. Dưới đây là một ví dụ về file cấu hình /etc/haproxy/haproxy.cfg. Cấu hình phiên bản của bạn bằng cách sử dụng file cấu hình sau, bạn sẽ cần một bản sao của nó trên mỗi node điều khiển.
global
chroot /var/lib/haproxy
daemon
group haproxy
maxconn 4000
pidfile /var/run/haproxy.pid
user haproxy
defaults
log global
maxconn 4000
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout check 10s
listen dashboard_cluster
bind <Virtual IP>:443
balance source
option tcpka
option httpchk
option tcplog
server controller1 10.0.0.12:443 check inter 2000 rise 2 fall 5
server controller2 10.0.0.13:443 check inter 2000 rise 2 fall 5
server controller3 10.0.0.14:443 check inter 2000 rise 2 fall 5
listen galera_cluster
bind <Virtual IP>:3306
balance source
option mysql-check
server controller1 10.0.0.12:3306 check port 9200 inter 2000 rise 2 fall 5
server controller2 10.0.0.13:3306 backup check port 9200 inter 2000 rise 2 fall 5
server controller3 10.0.0.14:3306 backup check port 9200 inter 2000 rise 2 fall 5
listen glance_api_cluster
bind <Virtual IP>:9292
balance source
option tcpka
option httpchk
option tcplog
server controller1 10.0.0.12:9292 check inter 2000 rise 2 fall 5
server controller2 10.0.0.13:9292 check inter 2000 rise 2 fall 5
server controller3 10.0.0.14:9292 check inter 2000 rise 2 fall 5
listen glance_registry_cluster
bind <Virtual IP>:9191
balance source
option tcpka
option tcplog
server controller1 10.0.0.12:9191 check inter 2000 rise 2 fall 5
server controller2 10.0.0.13:9191 check inter 2000 rise 2 fall 5
server controller3 10.0.0.14:9191 check inter 2000 rise 2 fall 5
listen keystone_admin_cluster
bind <Virtual IP>:35357
balance source
option tcpka
option httpchk
option tcplog
server controller1 10.0.0.12:35357 check inter 2000 rise 2 fall 5
server controller2 10.0.0.13:35357 check inter 2000 rise 2 fall 5
server controller3 10.0.0.14:35357 check inter 2000 rise 2 fall 5
listen keystone_public_internal_cluster
bind <Virtual IP>:5000
balance source
option tcpka
option httpchk
option tcplog
server controller1 10.0.0.12:5000 check inter 2000 rise 2 fall 5
server controller2 10.0.0.13:5000 check inter 2000 rise 2 fall 5
server controller3 10.0.0.14:5000 check inter 2000 rise 2 fall 5
listen nova_ec2_api_cluster
bind <Virtual IP>:8773
balance source
option tcpka
option tcplog
server controller1 10.0.0.12:8773 check inter 2000 rise 2 fall 5
server controller2 10.0.0.13:8773 check inter 2000 rise 2 fall 5
server controller3 10.0.0.14:8773 check inter 2000 rise 2 fall 5
listen nova_compute_api_cluster
bind <Virtual IP>:8774
balance source
option tcpka
option httpchk
option tcplog
server controller1 10.0.0.12:8774 check inter 2000 rise 2 fall 5
server controller2 10.0.0.13:8774 check inter 2000 rise 2 fall 5
server controller3 10.0.0.14:8774 check inter 2000 rise 2 fall 5
listen nova_metadata_api_cluster
bind <Virtual IP>:8775
balance source
option tcpka
option tcplog
server controller1 10.0.0.12:8775 check inter 2000 rise 2 fall 5
server controller2 10.0.0.13:8775 check inter 2000 rise 2 fall 5
server controller3 10.0.0.14:8775 check inter 2000 rise 2 fall 5
listen cinder_api_cluster
bind <Virtual IP>:8776
balance source
option tcpka
option httpchk
option tcplog
server controller1 10.0.0.12:8776 check inter 2000 rise 2 fall 5
server controller2 10.0.0.13:8776 check inter 2000 rise 2 fall 5
server controller3 10.0.0.14:8776 check inter 2000 rise 2 fall 5
listen ceilometer_api_cluster
bind <Virtual IP>:8777
balance source
option tcpka
option tcplog
server controller1 10.0.0.12:8777 check inter 2000 rise 2 fall 5
server controller2 10.0.0.13:8777 check inter 2000 rise 2 fall 5
server controller3 10.0.0.14:8777 check inter 2000 rise 2 fall 5
listen nova_vncproxy_cluster
bind <Virtual IP>:6080
balance source
option tcpka
option tcplog
server controller1 10.0.0.12:6080 check inter 2000 rise 2 fall 5
server controller2 10.0.0.13:6080 check inter 2000 rise 2 fall 5
server controller3 10.0.0.14:6080 check inter 2000 rise 2 fall 5
listen neutron_api_cluster
bind <Virtual IP>:9696
balance source
option tcpka
option httpchk
option tcplog
server controller1 10.0.0.12:9696 check inter 2000 rise 2 fall 5
server controller2 10.0.0.13:9696 check inter 2000 rise 2 fall 5
server controller3 10.0.0.14:9696 check inter 2000 rise 2 fall 5
listen swift_proxy_cluster
bind <Virtual IP>:8080
balance source
option tcplog
option tcpka
server controller1 10.0.0.12:8080 check inter 2000 rise 2 fall 5
server controller2 10.0.0.13:8080 check inter 2000 rise 2 fall 5
server controller3 10.0.0.14:8080 check inter 2000 rise 2 fall 5Để cấu hình HAProxy, bạn cần khởi động lại dịch vụ HAProxy.
Trong cấu hình Galera cluster, chỉ thị backup chỉ ra rằng hai trong ba bộ controller là các node dự phòng. Điều này đảm bảo chỉ có một node phục vụ các yêu cầu ghi vì OpenStack chưa hỗ trợ ghi nhiều node ở mức sẵn sàng cho prod.
Cấu hình dịch vụ API Telemetry không có tùy chọn chỉ thị httpchk vì nó không thể xử lý kiểm tra này một cách đúng đắn.
Cấu hình tham số kernel để cho phép ràng buộc IP không cục bộ. Điều này cho phép các phiên bản HAProxy đang chạy ràng buộc với một VIP cho failover. Thêm dòng sau vào /etc/sysctl.conf:
net.ipv4.ip_nonlocal_bind = 1Khởi động lại máy chủ hoặc, để thay đổi hoạt động ngay lập tức, gọi:
sysctl -pThêm HAProxy vào cụm và đảm bảo các VIP chỉ có thể chạy trên các máy nơi HAProxy đang hoạt động:
pcs resource create lb-haproxy systemd:haproxy --clone
pcs constraint order start vip then lb-haproxy-clone kind=Optional
pcs constraint colocation add lb-haproxy-clone with vipHoặc sử dụng crmsh:
crm cib new conf-haproxy
crm configure primitive haproxy lsb:haproxy op monitor interval="1s"
crm configure clone haproxy-clone haproxy
crm configure colocation vip-with-haproxy inf: vip haproxy-clone
crm configure order haproxy-after-vip mandatory: vip haproxy-cloneNhững chỉ thị này đảm bảo rằng HAProxy được khởi động trên các máy chủ phù hợp và rằng các địa chỉ IP ảo (VIPs) chỉ chạy trên các máy chủ nơi HAProxy đang hoạt động.
2. So sánh giữa Pacemaker và systemd trong việc quản lý dịch vụ Memcached.
Memcached là một hệ thống lưu trữ cache phân tán đa mục đích. Nó được sử dụng để tăng tốc độ cho các trang web dựa trên cơ sở dữ liệu động bằng cách lưu trữ dữ liệu và đối tượng trong RAM để giảm số lần phải đọc từ nguồn dữ liệu bên ngoài.
Memcached là một dịch vụ cache trong bộ nhớ mà hầu hết các dịch vụ OpenStack có thể sử dụng để lưu trữ dữ liệu tạm thời, chẳng hạn như tokens.
Truy cập vào Memcached không được xử lý bởi HAProxy vì việc truy cập được sao chép hiện đang ở trạng thái thử nghiệm. Thay vào đó, các dịch vụ OpenStack phải được cung cấp danh sách đầy đủ của các máy chủ đang chạy Memcached.
Client của Memcached thực hiện băm để cân bằng các đối tượng giữa các phiên bản. Khi một phiên bản gặp sự cố, chỉ có một phần trăm các đối tượng bị ảnh hưởng, và client tự động loại bỏ nó khỏi danh sách các phiên bản. Mức độ cam kết dịch vụ (SLA) là vài phút.
3. Highly available dịch vụ Openstack API.
Phần này sẽ hướng dẫn cách cấu hình dịch vụ Identity API của OpenStack để đảm bảo tính sẵn sàng cao (high availability) trên các hệ điều hành SUSE và Red Hat.
SUSE.
Sử dụng các agent OCF để điều khiển các dịch vụ OpenStack. Các lệnh được đưa ra để tải xuống tài nguyên Identity của OpenStack cho Pacemaker, sau đó thêm cấu hình Pacemaker cho tài nguyên này. Một tài nguyên mới p_keystone được tạo để quản lý dịch vụ Identity của OpenStack.
Hãy ddi chuyển đến thư mục cần thiết, tạo thư mục mới tên là ‘openstack’, sau đó tải xuống tài nguyên Identity từ OpenStack và cấp quyền thực thi cho nó.
cd /usr/lib/ocf/resource.d
mkdir openstack
cd openstack
wget https://opendev.org/x/openstack-resource-agents/raw/branch/master/ocf/keystone
chmod a+rx *Thêm cấu hình Pacemaker cho tài nguyên Identity của OpenStack, sử dụng lệnh crm configure để kết nối với cụm Pacemaker.
crm configureSau đó thêm tài nguyên cụm mới với tên p_keystone và các tham số cần thiết.
clone p_keystone ocf:openstack:keystone \
params config="/etc/keystone/keystone.conf" os_password="secretsecret" os_username="admin" os_tenant_name="admin" os_auth_url="http://10.0.0.11:5000/v2.0/" \
op monitor interval="30s" timeout="30s"Sử dụng lệnh commit để lưu các thay đổi cấu hình từ menu crm configure.
commitBạn có thể chỉnh sửa tài nguyên để phù hợp với địa chỉ IP ảo ưa thích của bạn bằng cách nhập edit p_ip_keystone từ menu crm configure.
Pacemaker sẽ bắt đầu dịch vụ Identity của OpenStack và các tài nguyên phụ thuộc trên tất cả các node của bạn.
Red Hat.
Đây là hướng dẫn cấu hình OpenStack Identity service (dịch vụ nhận dạng) trên Red Hat Enterprise Linux hoặc các bản phân phối Linux dựa trên Red Hat.
Bạn sử dụng lênh này để tạo một tài nguyên mới cho dịch vụ OpenStack Keystone sử dụng systemd và clone nó để có thể chạy trên nhiều node.
pcs resource create openstack-keystone systemd:openstack-keystone --clone interleave=trueBạn cần chỉnh sửa file keystone.conf để thay đổi các giá trị của các tham số bind(2). bind_host, public_bind_host và admin_bind_host đều được đặt thành địa chỉ IP 10.0.0.12. Tham số admin_bind_host cho phép bạn sử dụng một mạng riêng cho quyền truy cập quản trị.
bind_host = 10.0.0.12
public_bind_host = 10.0.0.12
admin_bind_host = 10.0.0.12Đảm bảo rằng tất cả dữ liệu được lưu trữ trong cơ sở dữ liệu MySQL (cũng có sẵn cao). Các phần [catalog] và [identity] trong file cấu hình đề cập đến việc sử dụng backends SQL cho Catalog và Identity.
[catalog]
driver = keystone.catalog.backends.sql.Catalog
# ...
[identity]
driver = keystone.identity.backends.sql.Identity
# ...Nếu dịch vụ Identity của bạn được cấu hình để gửi thông báo ceilometer (một dịch vụ trong OpenStack dùng để thu thập dữ liệu về việc sử dụng và hiệu suất của các dịch vụ khác) và bus tin nhắn (message bus – một thành phần trung gian trong việc truyền thông báo giữa các dịch vụ) của bạn cũng được cấu hình để hỗ trợ HA, bạn cần đảm bảo rằng dịch vụ Identity cũng được cấu hình một cách chính xác để có thể sử dụng HA.
Điều này đảm bảo rằng dịch vụ Identity sẽ tiếp tục hoạt động một cách ổn định và không gặp sự cố nếu một phần của hệ thống gặp sự cố, đồng thời nó cũng có thể gửi thông báo ceilometer một cách đáng tin cậy.
Cách cấu hình các dịch vụ OpenStack để sử dụng OpenStack Identity High Availability.
Các dịch vụ OpenStack của bạn giờ đây sẽ chỉ đến cấu hình OpenStack Identity thông qua địa chỉ IP ảo của cụm có khả năng sẵn sàng cao.
Đối với dịch vụ OpenStack Compute, nếu địa chỉ IP của dịch vụ OpenStack Identity của bạn là 10.0.0.11, hãy sử dụng cấu hình sau trong file api-paste.ini:
auth_host = 10.0.0.11Tạo Endpoint OpenStack Identity với địa chỉ IP này.
Nếu bạn sử dụng cả địa chỉ IP riêng và công khai, hãy tạo hai địa chỉ IP ảo và xác định endpoint. Ví dụ:
openstack endpoint create --region $KEYSTONE_REGION \
service-type public http://PUBLIC_VIP:5000/v2.0
openstack endpoint create --region $KEYSTONE_REGION \
service-type admin http://10.0.0.11:35357/v2.0
openstack endpoint create --region $KEYSTONE_REGION \
service-type internal http://10.0.0.11:5000/v2.0Nếu bạn sử dụng Dashboard (horizon), chỉnh sửa file local_settings.py để bao gồm dòng sau:
OPENSTACK_HOST = "10.0.0.11"Điều này đảm bảo rằng Dashboard sẽ kết nối với dịch vụ OpenStack Identity thông qua địa chỉ IP có khả năng sẵn sàng cao.
Cấu hình Telemetry API trong OpenStack để hỗ trợ High Availability – HA.
Telemetry polling agent: Đây là một thành phần của OpenStack Telemetry (còn được gọi là Ceilometer) dùng để thu thập dữ liệu về việc sử dụng và hiệu suất của các dịch vụ khác trong OpenStack. Agent này có thể được cấu hình để chia công việc thu thập dữ liệu giữa nhiều agent, cho phép HA.
Central và Compute agent: Cả hai đều có thể chạy trong môi trường HA, tức là có thể có nhiều instance của các dịch vụ này chạy song song và công việc được phân chia giữa các instance đang chạy.
Tooz library: Thư viện này cung cấp khả năng phối hợp giữa các nhóm của các instance dịch vụ. Tooz hỗ trợ nhiều driver bao gồm Zookeeper, Redis (đều được Tooz khuyến nghị) và Memcached (khuyến nghị cho việc kiểm thử).
Cấu hình Tooz: Bạn cần cấu hình một driver Tooz được hỗ trợ để triển khai HA cho các dịch vụ Telemetry.
Kiểm tra sự sẵn sàng của các instance: Được thực hiện bằng cách gửi các tin nhắn heartbeat. Khi mất kết nối với một instance, công việc sẽ được gán lại cho các instance còn lại trong chu kỳ thu thập tiếp theo.
Cấu hình Central agent: Đối với tương thích ngược và hỗ trợ các triển khai hiện tại, cấu hình central agent hỗ trợ sử dụng các file cấu hình khác nhau. Điều này dành cho các nhóm của các instance dịch vụ đang chạy song song.
Cấu hình Compute agent: Để cho phép compute agent chạy nhiều instance cùng một lúc với phân chia công việc, tùy chọn workload_partitioning phải được đặt thành True trong phần compute trong file cấu hình ceilometer.conf.
Ví dụ về cấu hình trong ceilometer.conf:
[DEFAULT]
...
coordination_url = redis://localhost:6379
...
[compute]
...
workload_partitioning = True
...Trong đó, coordination_url chỉ địa chỉ của backend Tooz (ở đây là Redis) và workload_partitioning được đặt thành True để kích hoạt phân chia công việc cho compute agent.
