Giới thiệu

Hướng dẫn này sẽ chỉ cho bạn cách tạo thiết lập cân bằng tải sẵn có sẵn cao trên DigitalOcean, với sự hỗ trợ của một IP nổi và ngăn xếp cụm Corosync / Pacemaker. Các cân bằng tải HAProxy sẽ được cấu hình để phân chia lưu lượng giữa hai máy chủ ứng dụng phụ trợ. Nếu cân bằng tải chính bị hỏng, IP nổi sẽ tự động được chuyển sang cân bằng tải thứ hai, cho phép dịch vụ tiếp tục.

High Availability HAProxy setup

Chú thích: DigitalOcean Load Balancers là một dịch vụ cân bằng tải có sẵn, được quản lý hoàn toàn. Dịch vụ Cân bằng tải có thể điền vai trò tương tự như thiết lập tính khả dụng cao thủ công được mô tả tại đây. Theo dõi hướng dẫn thiết lập cân bằng tải nếu bạn muốn đánh giá tùy chọn đó.

Điều kiện tiên quyết

Để hoàn thành hướng dẫn này, bạn sẽ cần phải hoàn thành Làm thế nào để tạo một thiết lập sẵn sàng cao với Corosync, Pacemaker và IP nổi trên Ubuntu 14.04 hướng dẫn (bạn nên bỏ qua tùy chọn Thêm tài nguyên Nginx phần). Điều này sẽ để lại cho bạn hai giọt, chúng tôi sẽ gọi là sơ cấpthứ hai, với một IP nổi có thể chuyển đổi giữa chúng. Nói chung, chúng tôi sẽ tham khảo các máy chủ này cân bằng tải. Đây là những giọt mà chúng tôi sẽ cài đặt một cân bằng tải, HAProxy.

Bạn cũng sẽ cần để có thể tạo thêm hai 14.04 giọt Ubuntu trong cùng một trung tâm dữ liệu, với mạng riêng được kích hoạt, để chứng minh rằng thiết lập cân bằng tải HA hoạt động. Đây là những máy chủ sẽ được cân bằng tải bởi HAProxy. Chúng tôi sẽ đề cập đến các máy chủ ứng dụng này, mà chúng tôi sẽ cài đặt Nginx trên, như ứng dụng-1app-2. Nếu bạn đã có máy chủ ứng dụng mà bạn muốn tải số dư, vui lòng sử dụng các máy chủ đó để thay thế.

Trên mỗi máy chủ này, bạn sẽ cần một người dùng không phải root được cấu hình với sudo truy cập. Bạn có thể theo dõi Ubuntu 14.04 hướng dẫn thiết lập máy chủ ban đầu để tìm hiểu cách thiết lập những người dùng này.

Tạo các giọt ứng dụng

Bước đầu tiên là tạo hai giọt Ubuntu, với mạng riêng được bật, trong cùng trung tâm dữ liệu làm cân bằng tải của bạn, sẽ hoạt động như ứng dụng-1app-2 máy chủ được mô tả ở trên. Chúng tôi sẽ cài đặt Nginx trên cả hai giọt và thay thế các trang chỉ mục của họ bằng thông tin nhận dạng duy nhất chúng. Điều này sẽ cho phép chúng tôi một cách đơn giản để chứng minh rằng thiết lập cân bằng tải HA đang hoạt động. Nếu bạn đã có các máy chủ ứng dụng mà bạn muốn tải cân bằng, vui lòng điều chỉnh các phần thích hợp của hướng dẫn này để thực hiện công việc đó (và bỏ qua bất kỳ phần nào không liên quan đến thiết lập của bạn).

Nếu bạn muốn làm theo các thiết lập ví dụ, tạo ra hai Ubuntu 14.04 giọt, ứng dụng-1app-2và sử dụng tập lệnh bash này làm dữ liệu người dùng:

Example User Data

#!/bin/bash

apt-get -y update
apt-get -y install nginx
export HOSTNAME=$(curl -s http://169.254.169.254/metadata/v1/hostname)
export PUBLIC_IPV4=$(curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
echo Droplet: $HOSTNAME, IP Address: $PUBLIC_IPV4 > /usr/share/nginx/html/index.html

Dữ liệu người dùng này sẽ cài đặt Nginx và thay thế nội dung của index.html bằng tên máy chủ và địa chỉ IP công cộng của giọt (bằng cách tham chiếu dịch vụ Siêu dữ liệu). Truy cập vào Droplet sẽ hiển thị một trang web cơ bản với tên máy chủ Droplet và địa chỉ IP công cộng, sẽ hữu ích cho việc kiểm tra máy chủ ứng dụng nào mà các cân bằng tải đang hướng lưu lượng truy cập đến.

Thu thập thông tin mạng máy chủ

Trước khi chúng tôi bắt đầu cấu hình thực tế các thành phần cơ sở hạ tầng của chúng tôi, tốt nhất là thu thập một số thông tin về từng máy chủ của bạn.

Để hoàn tất hướng dẫn này, bạn sẽ cần có thông tin sau về máy chủ của mình:

  • máy chủ ứng dụng: Địa chỉ IP riêng
  • cân bằng tải Địa chỉ IP riêng và Anchor

Tìm địa chỉ IP riêng

Cách dễ nhất để tìm địa chỉ IP riêng của Droplet của bạn là sử dụng curl để lấy địa chỉ IP riêng tư từ dịch vụ siêu dữ liệu DigitalOcean. Lệnh này nên được chạy từ bên trong các giọt của bạn. Trên mỗi giọt, gõ:

curl 169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address && echo

Địa chỉ IP chính xác sẽ được in trong cửa sổ đầu cuối:

Private IP address:10.132.20.236

Thực hiện bước này trên tất cả bốn giọt và sao chép địa chỉ IP riêng ở đâu đó mà bạn có thể dễ dàng tham khảo.

Tìm địa chỉ IP neo

Các neo IP là địa chỉ IP riêng cục bộ mà IP nổi sẽ liên kết với khi được gắn với máy chủ DigitalOcean. Nó chỉ đơn giản là một bí danh cho thường xuyên eth0 địa chỉ, được triển khai ở cấp độ hypervisor.

Cách dễ nhất, ít bị lỗi nhất khi lấy giá trị này là trực tiếp từ dịch vụ siêu dữ liệu DigitalOcean. Sử dụng curl, bạn có thể liên hệ với điểm cuối này trên mỗi máy chủ của mình bằng cách nhập:

curl 169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address && echo

IP neo sẽ được in trên dòng riêng của nó:

Output10.17.1.18

Thực hiện bước này trên cả hai cân bằng tải của bạn Droplets, và sao chép các địa chỉ IP neo ở đâu đó mà bạn có thể dễ dàng tham khảo.

Định cấu hình máy chủ ứng dụng

Sau khi thu thập dữ liệu ở trên, chúng tôi có thể chuyển sang định cấu hình dịch vụ của mình.

Note

Trong thiết lập này, phần mềm được chọn cho lớp máy chủ web là khá hoán đổi cho nhau. Hướng dẫn này sẽ sử dụng Nginx vì nó là chung chung và khá dễ cấu hình. Nếu bạn cảm thấy thoải mái hơn với Apache hoặc một máy chủ web dành riêng cho ngôn ngữ (có khả năng sản xuất), hãy sử dụng nó thay thế. HAProxy sẽ đơn giản chuyển các yêu cầu của máy khách đến các máy chủ web phụ trợ có thể xử lý các yêu cầu tương tự như cách nó xử lý các kết nối máy khách trực tiếp.

Chúng tôi sẽ bắt đầu bằng cách thiết lập các máy chủ ứng dụng phụ trợ của chúng tôi. Cả hai máy chủ này sẽ chỉ phục vụ tên và địa chỉ IP công cộng của chúng; trong một thiết lập thực sự, các máy chủ này sẽ phân phối nội dung giống nhau. Họ sẽ chỉ chấp nhận các kết nối web qua địa chỉ IP riêng của họ. Điều này sẽ giúp đảm bảo rằng lưu lượng truy cập được hướng độc quyền thông qua một trong hai máy chủ HAProxy mà chúng tôi sẽ cấu hình sau.

Thiết lập máy chủ ứng dụng phía sau trình cân bằng tải cho phép chúng tôi phân phối gánh nặng yêu cầu trong số một số máy chủ ứng dụng giống hệt nhau. Do nhu cầu lưu lượng truy cập của chúng tôi thay đổi, chúng tôi có thể dễ dàng mở rộng để đáp ứng nhu cầu mới bằng cách thêm hoặc xóa máy chủ ứng dụng khỏi cấp này.

Cấu hình Nginx chỉ cho phép các yêu cầu từ các cân bằng tải

Nếu bạn đang theo dõi ví dụ và bạn đã sử dụng dữ liệu người dùng khi tạo máy chủ ứng dụng, máy chủ của bạn sẽ được cài đặt Nginx. Bước tiếp theo là thực hiện một vài thay đổi cấu hình.

Chúng tôi muốn cấu hình Nginx để chỉ lắng nghe các yêu cầu trên địa chỉ IP riêng của máy chủ. Hơn nữa, chúng tôi sẽ chỉ phục vụ các yêu cầu đến từ các địa chỉ IP riêng của hai cân bằng tải của chúng tôi. Điều này sẽ buộc người dùng truy cập vào máy chủ ứng dụng của bạn thông qua bộ cân bằng tải của bạn (mà chúng tôi sẽ định cấu hình để chỉ có thể truy cập thông qua địa chỉ IP Nổi).

Để thực hiện những thay đổi này, hãy mở tệp chặn máy chủ Nginx mặc định trên mỗi máy chủ ứng dụng của bạn:

sudo vi /etc/nginx/sites-available/default

Để bắt đầu, chúng tôi sẽ sửa đổi listen chỉ thị. Thay đổi listen chỉ thị để nghe dòng điện địa chỉ IP riêng của máy chủ ứng dụng trên cổng 80. Xóa thêm listen hàng. Nó sẽ giống như thế này:

/etc/nginx/sites-available/default (1 of 2)

server {
    listen app_server_private_IP:80;

    . . .

Ngay bên dưới listen chỉ thị, chúng tôi sẽ thiết lập hai allow chỉ thị cho phép lưu lượng truy cập bắt nguồn từ địa chỉ IP riêng của hai cân bằng tải của chúng tôi. Chúng tôi sẽ làm theo điều này với deny all quy tắc cấm tất cả lưu lượng truy cập khác:

/etc/nginx/sites-available/default (2 of 2)

    allow load_balancer_1_private_IP;
    allow load_balancer_2_private_IP;
    deny all;

Lưu và đóng các tệp khi bạn hoàn tất.

Kiểm tra các thay đổi mà bạn đã thực hiện đại diện cho cú pháp Nginx hợp lệ bằng cách gõ:

sudo nginx -t

Nếu không có vấn đề gì được báo cáo, hãy khởi động lại daemon Nginx bằng cách gõ:

sudo service nginx restart

Hãy nhớ thực hiện tất cả các bước này (với địa chỉ IP riêng của máy chủ ứng dụng thích hợp) trên cả hai máy chủ ứng dụng.

Kiểm tra các thay đổi

Để kiểm tra xem máy chủ ứng dụng của bạn có bị hạn chế chính xác hay không, bạn có thể thực hiện yêu cầu bằng cách sử dụng curl từ các địa điểm khác nhau.

Trên chính máy chủ ứng dụng của bạn, bạn có thể thử một yêu cầu đơn giản về nội dung địa phương bằng cách nhập:

curl 127.0.0.1

Do các hạn chế mà chúng tôi đã đặt ra trong các tệp khối máy chủ Nginx của chúng tôi, yêu cầu này thực sự sẽ bị từ chối:

Outputcurl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused

Điều này được mong đợi và phản ánh hành vi mà chúng tôi đang cố gắng thực hiện.

Bây giờ, từ một trong hai cân bằng tải, chúng tôi có thể yêu cầu một trong hai địa chỉ IP công khai của máy chủ ứng dụng của chúng tôi:

curl web_server_public_IP

Một lần nữa, điều này sẽ thất bại. Các máy chủ ứng dụng không nghe trên giao diện công cộng và hơn nữa, khi sử dụng địa chỉ IP công khai, máy chủ ứng dụng của chúng tôi sẽ không nhìn thấy các địa chỉ IP riêng được phép trong yêu cầu từ bộ cân bằng tải của chúng tôi:

Outputcurl: (7) Failed to connect to app_server_public_IP port 80: Connection refused

Tuy nhiên, nếu chúng tôi sửa đổi cuộc gọi để thực hiện yêu cầu bằng cách sử dụng máy chủ ứng dụng địa chỉ IP riêng, nó sẽ hoạt động chính xác:

curl app_server_private_IP

Nginx index.html trang phải được trả lại. Nếu bạn đã sử dụng dữ liệu người dùng mẫu, trang phải chứa tên và địa chỉ IP công khai của máy chủ ứng dụng đang được truy cập:

app server index.htmlDroplet: app-1, IP Address: 159.203.130.34

Kiểm tra điều này từ cả hai cân bằng tải cho cả hai máy chủ ứng dụng. Mỗi yêu cầu cho địa chỉ IP riêng sẽ thành công trong khi mỗi yêu cầu được gửi tới các địa chỉ công cộng sẽ không thành công.

Một khi hành vi trên được chứng minh, chúng ta có thể tiếp tục. Cấu hình máy chủ ứng dụng phụ trợ của chúng tôi hiện đã hoàn tất.

Loại bỏ Nginx khỏi Load Balancers

Bằng cách làm theo điều kiện tiên quyết Thiết lập HA với Corosync, Pacemaker và Floating IPs hướng dẫn, các máy chủ cân bằng tải của bạn sẽ được cài đặt Nginx. Bởi vì chúng ta sẽ sử dụng HAProxy làm cân bằng tải proxy ngược, chúng ta nên xóa Nginx và bất kỳ tài nguyên cụm liên quan nào.

Xóa tài nguyên cụm Nginx

Nếu bạn đã thêm tài nguyên cụm Nginx trong khi làm theo hướng dẫn điều kiện tiên quyết, hãy dừng và xóa Nginx tài nguyên với các lệnh này trên một trong những cân bằng tải của bạn:

sudo crm resource stop Nginx

sudo crm configure delete Nginx

Điều này cũng nên xóa mọi cài đặt cụm phụ thuộc vào Nginx nguồn. Ví dụ: nếu bạn đã tạo clone hoặc là colocation tham chiếu đến Nginx tài nguyên, chúng cũng sẽ bị xóa.

Xóa gói Nginx

Bây giờ chúng tôi đã sẵn sàng gỡ cài đặt Nginx cả hai máy chủ cân bằng tải.

Đầu tiên, dừng dịch vụ Nginx:

sudo service nginx stop

Sau đó, xóa gói bằng lệnh này:

sudo apt-get purge nginx

Bạn cũng có thể muốn xóa các tệp cấu hình Nginx:

sudo rm -r /etc/nginx

Bây giờ chúng ta đã sẵn sàng để cài đặt và cấu hình HAProxy.

Cài đặt và cấu hình HAProxy

Tiếp theo, chúng tôi sẽ thiết lập cân bằng tải HAProxy. Chúng sẽ từng ngồi trước máy chủ web của chúng tôi và chia các yêu cầu giữa hai máy chủ ứng dụng phụ trợ. Các cân bằng tải này sẽ hoàn toàn dư thừa, trong một cấu hình chủ động thụ động; chỉ có một người sẽ nhận được lưu lượng truy cập tại bất kỳ thời điểm nào.

Cấu hình HAProxy sẽ chuyển yêu cầu tới cả hai máy chủ web. Các cân bằng tải sẽ lắng nghe các yêu cầu về địa chỉ IP neo của chúng. Như đã đề cập trước đó, đây là địa chỉ IP mà địa chỉ IP thả nổi sẽ liên kết với khi được đính kèm vào Droplet. Điều này đảm bảo rằng chỉ có lưu lượng truy cập bắt nguồn từ địa chỉ IP nổi sẽ được chuyển tiếp.

Cài đặt HAProxy

Phần này cần được thực hiện trên cả hai máy chủ cân bằng tải.

Chúng tôi sẽ cài đặt HAProxy 1.6, không có trong kho lưu trữ mặc định của Ubuntu. Tuy nhiên, chúng tôi vẫn có thể sử dụng trình quản lý gói để cài đặt HAProxy 1.6 nếu chúng tôi sử dụng PPA, với lệnh này:

sudo add-apt-repository ppa:vbernat/haproxy-1.6

Cập nhật chỉ mục gói cục bộ trên các cân bằng tải của bạn và cài đặt HAProxy bằng cách gõ:

sudo apt-get update

sudo apt-get install haproxy

HAProxy hiện đã được cài đặt, nhưng chúng tôi cần phải cấu hình nó ngay bây giờ.

Cấu hình HAProxy

Mở tệp cấu hình HAProxy chính:

sudo vi /etc/haproxy/haproxy.cfg

Tìm defaults và thêm hai dòng sau vào nó:

/etc/haproxy/haproxy.cfg (1 of 3)

    option forwardfor
    option http-server-close

Các forwardfor tùy chọn đặt HAProxy để thêm X-Forwarded-For tiêu đề cho từng yêu cầu - hữu ích nếu bạn muốn máy chủ ứng dụng của mình biết địa chỉ IP nào ban đầu đã gửi yêu cầu và http-server-close tùy chọn giảm độ trễ giữa HAProxy và người dùng của bạn bằng cách đóng các kết nối nhưng vẫn duy trì trạng thái giữ liên tục.

Tiếp theo, ở cuối tệp, chúng tôi cần xác định cấu hình giao diện người dùng của mình. Điều này sẽ quyết định cách HAProxy lắng nghe các kết nối đến. Chúng tôi sẽ liên kết HAProxy với địa chỉ IP neo cân bằng tải. Điều này sẽ cho phép nó nghe lưu lượng truy cập bắt nguồn từ địa chỉ IP nổi. Chúng tôi sẽ gọi giao diện người dùng của chúng tôi là "http" để đơn giản. Chúng tôi cũng sẽ chỉ định một chương trình phụ trợ mặc định, app_pool, để chuyển lưu lượng truy cập đến (mà chúng tôi sẽ định cấu hình trong giây lát):

/etc/haproxy/haproxy.cfg (2 of 3)

frontend http
    bind    load_balancer_anchor_IP:80
    default_backend app_pool

Chú thích: IP neo là phần duy nhất của cấu hình HAProxy nên khác nhau giữa các máy chủ cân bằng tải. Đó là, hãy chắc chắn để xác định IP neo của máy chủ cân bằng tải mà bạn hiện đang làm việc.

Tiếp theo, chúng ta có thể định nghĩa cấu hình backend. Điều này sẽ xác định các vị trí hạ lưu nơi HAProxy sẽ vượt qua lưu lượng truy cập mà nó nhận được. Trong trường hợp của chúng tôi, đây sẽ là địa chỉ IP riêng của cả hai máy chủ ứng dụng Nginx mà chúng tôi đã định cấu hình:

/etc/haproxy/haproxy.cfg (3 of 3)

backend app_pool
    server app-1 app_server_1_private_IP:80 check
    server app-2 app_server_2_private_IP:80 check

Khi bạn hoàn tất việc thực hiện các thay đổi ở trên, hãy lưu và thoát tệp.

Kiểm tra xem các thay đổi cấu hình mà chúng tôi đã thực hiện có biểu thị cú pháp HAProxy hợp lệ hay không bằng cách gõ:

sudo haproxy -f /etc/haproxy/haproxy.cfg -c

Nếu không có lỗi nào được báo cáo, hãy khởi động lại dịch vụ của bạn bằng cách nhập:

sudo service haproxy restart

Một lần nữa, hãy chắc chắn để thực hiện tất cả các bước trong phần này trên cả hai máy chủ cân bằng tải.

Kiểm tra các thay đổi

Chúng tôi có thể đảm bảo cấu hình của chúng tôi hợp lệ bằng cách kiểm tra curl lần nữa.

Từ máy chủ cân bằng tải, hãy thử yêu cầu máy chủ lưu trữ cục bộ, địa chỉ IP công cộng của trình cân bằng tải hoặc địa chỉ IP riêng của máy chủ:

curl 127.0.0.1

curl load_balancer_public_IP

curl load_balancer_private_IP

Tất cả những điều này sẽ không thành công với các thông báo trông giống như sau:

Outputcurl: (7) Failed to connect to IP_address port 80: Connection refused

Tuy nhiên, nếu bạn thực hiện một yêu cầu cho cân bằng tải địa chỉ IP neo, nó sẽ hoàn tất thành công:

curl load_balancer_anchor_IP

Bạn sẽ thấy Nginx index.html trang của một trong các máy chủ ứng dụng:

app server index.htmlDroplet: app-1, IP Address: app1_IP_address

Thực hiện lại yêu cầu curl:

curl load_balancer_anchor_IP

Bạn sẽ thấy index.html trang của máy chủ ứng dụng khác, vì HAProxy sử dụng cân bằng tải round-robin theo mặc định:

app server index.htmlDroplet: app-2, IP Address: app2_IP_address

Nếu hành vi này khớp với hệ thống của bạn, thì cân bằng tải của bạn được định cấu hình chính xác; bạn đã thử nghiệm thành công rằng các máy chủ cân bằng tải của bạn đang cân bằng lưu lượng giữa cả hai máy chủ ứng dụng phụ trợ. Ngoài ra, IP nổi của bạn nên đã được gán cho một trong các máy chủ cân bằng tải, như được thiết lập trong điều kiện tiên quyết Thiết lập HA với Corosync, Pacemaker và Floating IPs hướng dẫn.

Tải xuống tài nguyên HAProxy OCF

Tại thời điểm này, bạn có một chuyển đổi dự phòng cơ bản ở cấp máy chủ nhưng chúng tôi có thể cải tiến thiết lập bằng cách thêm HAProxy làm tài nguyên cụm. Làm như vậy sẽ cho phép cụm của bạn đảm bảo rằng HAProxy đang chạy trên máy chủ mà IP Nổi của bạn được gán cho. Nếu Pacemaker phát hiện rằng HAProxy không chạy, nó có thể khởi động lại dịch vụ hoặc gán IP Floating cho nút kia (cần chạy HAProxy).

Máy tạo nhịp tim cho phép bổ sung các tác nhân tài nguyên OCF bằng cách đặt chúng vào một thư mục cụ thể.

Trên cả hai máy chủ cân bằng tải, tải xuống tác nhân tài nguyên HAProxy OCF với các lệnh sau:

cd /usr/lib/ocf/resource.d/heartbeat

sudo curl -O https://raw.githubusercontent.com/thisismitch/cluster-agents/master/haproxy

Trên cả hai máy chủ cân bằng tải, làm cho nó có thể thực thi được:

sudo chmod +x haproxy

Vui lòng xem lại nội dung của tài nguyên trước khi tiếp tục. Nó là một kịch bản lệnh shell có thể được sử dụng để quản lý dịch vụ HAProxy.

Bây giờ chúng ta có thể sử dụng tác nhân tài nguyên HAProxy OCF để định nghĩa haproxy tài nguyên cụm.

Thêm tài nguyên haproxy

Với tác nhân tài nguyên HAProxy OCF của chúng tôi đã được cài đặt, chúng tôi có thể định cấu hình một haproxy tài nguyên sẽ cho phép cụm quản lý HAProxy.

Trên máy chủ cân bằng tải, tạo haproxy tài nguyên nguyên thủy với lệnh này:

sudo crm configure primitive haproxy ocf:heartbeat:haproxy op monitor interval=15s

Tài nguyên được chỉ định yêu cầu cụm theo dõi HAProxy sau mỗi 15 giây và khởi động lại nếu nó không khả dụng.

Kiểm tra trạng thái tài nguyên cụm của bạn bằng cách sử dụng sudo crm_mon hoặc là sudo crm status:

crm_mon:...
Online: [ primary secondary ]

 FloatIP    (ocf::digitalocean:floatip):    Started primary
 Nginx  (ocf::heartbeat:nginx): Started secondary

Thật không may, Pacemaker có thể quyết định bắt đầu haproxyFloatIP tài nguyên trên các nút riêng biệt vì chúng tôi chưa xác định bất kỳ ràng buộc tài nguyên nào. Đây là một vấn đề bởi vì IP nổi có thể trỏ đến một giọt trong khi dịch vụ HAProxy đang chạy trên giọt khác. Việc truy cập IP Nổi sẽ chỉ cho bạn một máy chủ không chạy dịch vụ phải sẵn sàng cao.

Để giải quyết vấn đề này, chúng tôi sẽ tạo bản sao tài nguyên, xác định rằng một tài nguyên nguyên thủy hiện có nên được bắt đầu trên nhiều nút.

Tạo bản sao của haproxy tài nguyên được gọi là "haproxy-clone" với lệnh này:

sudo crm configure clone haproxy-clone haproxy

Trạng thái cụm giờ sẽ trông giống như sau:

crm_mon:Online: [ primary secondary ]

FloatIP (ocf::digitalocean:floatip):    Started primary
 Clone Set: haproxy-clone [Nginx]
     Started: [ primary secondary ]

Như bạn có thể thấy, tài nguyên nhân bản, haproxy-clone, bây giờ đã bắt đầu trên cả hai nút của chúng tôi.

Bước cuối cùng là định cấu hình ràng buộc vị trí, để xác định rằng FloatIP tài nguyên nên chạy trên một nút có hoạt động haproxy-clone nguồn. Để tạo ra một hạn chế colocation gọi là "FloatIP-haproxy", sử dụng lệnh này:

sudo crm configure colocation FloatIP-haproxy inf: FloatIP haproxy-clone

Bạn sẽ không thấy bất kỳ sự khác biệt nào trong đầu ra trạng thái CRM, nhưng bạn có thể thấy rằng tài nguyên colocation được tạo bằng lệnh này:

sudo crm configure show

Bây giờ, cả hai máy chủ của bạn nên có HAProxy chạy, trong khi chỉ có một trong số chúng, có tài nguyên FloatIP đang chạy.

Thử dừng dịch vụ HAProxy trên máy chủ cân bằng tải:

sudo service haproxy stop

Bạn sẽ nhận thấy rằng nó sẽ bắt đầu lại một lần nữa trong vòng 15 giây tiếp theo.

Tiếp theo, chúng tôi sẽ kiểm tra thiết lập HA của bạn bằng cách khởi động lại máy chủ cân bằng tải hoạt động của bạn (máy chủ mà FloatIP tài nguyên hiện đang "bắt đầu" trên).

Kiểm tra tính sẵn sàng cao của cân bằng tải

Với thiết lập HAProxy có sẵn cao, bạn sẽ muốn kiểm tra mọi thứ hoạt động như dự định.

Để hình dung quá trình chuyển đổi giữa các cân bằng tải tốt hơn, chúng tôi có thể theo dõi nhật ký Nginx của máy chủ ứng dụng trong quá trình chuyển đổi.

Vì thông tin về máy chủ proxy nào đang được sử dụng không được trả lại cho máy khách, nơi tốt nhất để xem nhật ký là từ các máy chủ web phụ trợ thực sự. Mỗi máy chủ này nên duy trì nhật ký về việc khách hàng yêu cầu nội dung nào. Từ quan điểm của dịch vụ Nginx, khách hàng là trình cân bằng tải mà yêu cầu thay mặt cho khách hàng thực sự.

Theo dõi trạng thái cụm

Trong khi thực hiện các bài kiểm tra sắp tới, bạn có thể muốn xem xét trạng thái thời gian thực của các nút và tài nguyên cụm. Bạn có thể làm như vậy với lệnh này, trên máy chủ cân bằng tải (miễn là nó đang chạy):

sudo crm_mon

Đầu ra sẽ trông giống như sau:

crm_mon output:Last updated: Thu Nov  5 13:51:41 2015
Last change: Thu Nov  5 13:51:27 2015 via cibadmin on primary
Stack: corosync
Current DC: secondary (2) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
3 Resources configured

Online: [ primary secondary ]

FloatIP (ocf::digitalocean:floatip):    Started primary
 Clone Set: haproxy-clone [haproxy]
     Started: [ primary secondary ]

Điều này sẽ cho bạn thấy các nút cân bằng tải nào đang trực tuyến và các nút nào FloatIPhaproxy tài nguyên được bắt đầu vào.

Lưu ý rằng nút mà FloatIP tài nguyên là Started trên, sơ cấp trong ví dụ trên, là máy chủ cân bằng tải mà IP nổi hiện được gán cho. Chúng tôi sẽ gọi máy chủ này là máy chủ cân bằng tải hoạt động.

Tự động hóa yêu cầu đối với IP nổi

Trên máy cục bộ của bạn, chúng tôi sẽ yêu cầu nội dung web ở địa chỉ IP nổi 2 giây một lần. Điều này sẽ cho phép chúng ta dễ dàng xem cách cân bằng tải hoạt động đang xử lý lưu lượng truy cập đến. Tức là, chúng ta sẽ thấy máy chủ ứng dụng phụ trợ nào đang gửi lưu lượng truy cập đến. Trong thiết bị đầu cuối cục bộ của bạn, nhập lệnh này:

while true; do curl floating_IP_address; sleep 2; done

Cứ sau hai giây, bạn sẽ thấy một phản hồi từ một trong các máy chủ ứng dụng phụ trợ. Nó có lẽ sẽ thay đổi giữa ứng dụng-1app-2 vì thuật toán số dư mặc định của HAProxy mà chúng tôi chưa chỉ định, được đặt thành vòng tròn. Vì vậy, thiết bị đầu cuối của bạn sẽ hiển thị một cái gì đó như thế này:

[secondary_label curl loop output:
Droplet: app-1, IP Address: app_1_IP_address
Droplet: app-2, IP Address: app_2_IP_address
...

Giữ cửa sổ đầu cuối này mở để các yêu cầu liên tục được gửi đến máy chủ của bạn. Chúng sẽ hữu ích trong các bước kiểm tra tiếp theo của chúng tôi.

Đuôi nhật ký trên máy chủ web

Trên mỗi máy chủ ứng dụng phụ trợ của chúng tôi, chúng tôi có thể tail các /var/log/nginx/access.log vị trí. Điều này sẽ hiển thị mỗi yêu cầu được thực hiện cho máy chủ. Vì cân bằng tải của chúng tôi chia lưu lượng truy cập đồng đều bằng cách sử dụng vòng xoay vòng, mỗi máy chủ ứng dụng phụ trợ sẽ thấy khoảng một nửa số yêu cầu được thực hiện.

Địa chỉ khách hàng là trường đầu tiên trong nhật ký truy cập, vì vậy nó sẽ dễ tìm. Chạy các mục sau đây cả hai của các máy chủ ứng dụng Nginx của bạn (trong các cửa sổ đầu cuối riêng biệt):

sudo tail -f /var/log/nginx/access.log

Trường đầu tiên sẽ hiển thị địa chỉ IP riêng của máy chủ cân bằng tải hoạt động của bạn, cứ bốn giây một lần (chúng tôi sẽ giả định đó là sơ cấp cân bằng tải, nhưng nó có thể là thứ hai một trong trường hợp của bạn):

Output. . .
primary_loadbalancer_IP - - [05/Nov/2015:14:26:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
primary_loadbalancer_IP - - [05/Nov/2015:14:26:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

Giữ cái tail lệnh chạy trên cả hai máy chủ ứng dụng của bạn.

Ngắt dịch vụ HAProxy trên cân bằng tải chính

Bây giờ, hãy khởi động lại sơ cấp cân bằng tải, để đảm bảo rằng các chuyển đổi dự phòng IP nổi hoạt động:

sudo reboot

Bây giờ hãy chú ý đến các bản ghi truy cập Nginx trên cả hai máy chủ ứng dụng của bạn. Bạn sẽ nhận thấy rằng, sau khi chuyển đổi dự phòng IP nổi xảy ra, nhật ký truy cập cho thấy rằng các máy chủ ứng dụng đang được truy cập bởi một địa chỉ IP khác với trước đây. Nhật ký phải cho biết rằng thứ hai máy chủ cân bằng tải đang gửi yêu cầu:

Output. . .
secondary_loadbalancer_IP - - [05/Nov/2015:14:27:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
secondary_loadbalancer_IP - - [05/Nov/2015:14:27:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

Điều này cho thấy sự thất bại của cân bằng tải chính đã được phát hiện, và IP Nổi được gán lại cho bộ cân bằng tải thứ cấp thành công.

Bạn cũng có thể muốn kiểm tra đầu ra của thiết bị đầu cuối cục bộ của bạn (truy cập IP Nổi hai giây một lần) để xác minh rằng trình cân bằng tải thứ cấp đang gửi yêu cầu tới cả hai máy chủ ứng dụng phụ trợ:

[secondary_label curl loop output:
Droplet: app-1, IP Address: app_1_IP_address
Droplet: app-2, IP Address: app_2_IP_address
...

Bạn cũng có thể thử chuyển đổi dự phòng theo một hướng khác, khi bộ cân bằng tải khác trực tuyến trở lại.

Định cấu hình Nginx để ghi địa chỉ IP thực tế của máy khách

Như bạn đã thấy, các bản ghi truy cập Nginx cho thấy tất cả các yêu cầu của khách hàng là từ địa chỉ IP riêng của cân bằng tải hiện tại, thay vì địa chỉ IP thực của máy khách ban đầu đã thực hiện yêu cầu (tức là máy cục bộ của bạn). Nó thường hữu ích để đăng nhập địa chỉ IP của người yêu cầu ban đầu, thay vì máy chủ cân bằng tải. Điều này có thể dễ dàng đạt được bằng cách thực hiện một vài thay đổi đối với cấu hình Nginx trên tất cả các máy chủ ứng dụng phụ trợ của bạn.

Cả Hai máy chủ ứng dụng, mở nginx.conf tệp trong trình chỉnh sửa:

sudo vi /etc/nginx/nginx.conf

Tìm phần "Cài đặt ghi nhật ký" (trong http chặn) và thêm dòng sau:

add to /etc/nginx/nginx.conf

log_format haproxy_log 'ProxyIP: $remote_addr - ClientIP: $http_x_forwarded_for - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent "$http_referer" ' '"$http_user_agent"';

Lưu và thoát. Điều này chỉ định định dạng nhật ký mới được gọi là haproxy_log, cho biết thêm $http_x_forwarded_for valueâ € "địa chỉ IP của máy khách đã tạo yêu cầu ban đầu cho các mục nhập nhật ký truy cập mặc định. Chúng tôi cũng đang bao gồm $remote_addr, đó là địa chỉ IP của trình cân bằng tải proxy ngược (tức là máy chủ cân bằng tải hoạt động).

Tiếp theo, để đặt định dạng nhật ký mới này để sử dụng, chúng ta cần phải thêm một dòng vào khối máy chủ mặc định của chúng tôi.

Trên cả máy chủ ứng dụng, mở default cấu hình máy chủ:

sudo vi /etc/nginx/sites-available/default

Trong server khối (ngay bên dưới listen chỉ thị là một nơi tốt), thêm dòng sau:

add to /etc/nginx/sites-available/default

        access_log /var/log/nginx/access.log haproxy_log;

Lưu và thoát. Điều này cho Nginx viết nhật ký truy cập của nó bằng cách sử dụng haproxy_log định dạng nhật ký mà chúng tôi đã tạo gần đây.

Trên cả máy chủ ứng dụng, khởi động lại Nginx để đưa các thay đổi có hiệu lực:

sudo service nginx restart

Bây giờ các bản ghi truy cập Nginx của bạn nên chứa các địa chỉ IP thực tế của các yêu cầu của máy khách. Xác minh điều này bằng cách điều chỉnh nhật ký máy chủ ứng dụng của bạn, như chúng tôi đã làm trong phần trước. Các mục nhập nhật ký sẽ trông giống như sau:

New Nginx access logs:. . .
ProxyIP: load_balancer_private_IP - ClientIP: local_machine_IP - - [05/Nov/2015:15:05:53 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

Nếu nhật ký của bạn trông tốt, bạn đã hoàn tất!

Phần kết luận

Trong hướng dẫn này, chúng tôi đã đi qua toàn bộ quá trình thiết lập cơ sở hạ tầng cân bằng tải sẵn có cao. Cấu hình này hoạt động tốt vì máy chủ HAProxy hoạt động có thể phân phối tải tới nhóm máy chủ ứng dụng trên chương trình phụ trợ. Bạn có thể dễ dàng mở rộng hồ bơi này khi nhu cầu của bạn tăng lên hoặc co lại.

Cấu hình IP nổi và Corosync / Pacemaker loại bỏ điểm hỏng đơn tại lớp cân bằng tải, cho phép dịch vụ của bạn tiếp tục hoạt động ngay cả khi bộ cân bằng tải chính hoàn toàn không thành công. Cấu hình này khá linh hoạt và có thể thích ứng với môi trường ứng dụng của riêng bạn bằng cách thiết lập ngăn xếp ứng dụng ưa thích của bạn phía sau các máy chủ HAProxy.