GALAXY TECH
Chuyên gia Công nghệ
Thứ năm, 05/11/2015 | 00:00 GMT+7

Cách tạo thiết lập HAProxy khả dụng cao với Corosync, Pacemaker và IP nổi trên Ubuntu 14.04

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

Cài đặt HAProxy sẵn có cao

Lưu ý: DigitalOcean Load Balancers là một dịch vụ cân bằng tải được quản lý đầy đủ, có tính khả dụng cao. Dịch vụ Cân bằng tải có thể thực hiện role tương tự như cài đặt tính sẵn sàng cao thủ công được mô tả ở đây. Làm theo hướng dẫn của ta về cách cài đặt Cân bằng tải nếu bạn muốn đánh giá tùy chọn đó.

Yêu cầu

Để hoàn thành hướng dẫn này, bạn cần phải hoàn thành Hướng dẫn cách tạo cài đặt tính khả dụ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 phần Thêm tài nguyên Nginx tùy chọn). Điều này sẽ để lại cho bạn hai Server , mà ta sẽ gọi là chính và phụ , với IP nổi có thể chuyển đổi giữa chúng. Nói chung, ta sẽ gọi các server này là bộ cân bằng tải . Đây là những server mà ta sẽ cài đặt bộ cân bằng tải, HAProxy.

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

Trên mỗi server này, bạn cần một user không phải root được cấu hình với quyền truy cập sudo . Bạn có thể làm theo hướng dẫn cài đặt server ban đầu Ubuntu 14.04 của ta để tìm hiểu cách cài đặt những user này.

Tạo server ứng dụng

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

Nếu bạn muốn làm theo cài đặt ví dụ, hãy tạo hai server Ubuntu 14.04, app-1 và app-2 và sử dụng tập lệnh bash này làm dữ liệu user :

Dữ liệu user mẫu
#!/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 Server: $HOSTNAME, IP Address: $PUBLIC_IPV4 > /usr/share/nginx/html/index.html

Dữ liệu user này sẽ cài đặt Nginx và thay thế nội dung của index.html bằng tên server và địa chỉ IP công khai của server (bằng cách tham chiếu dịch vụ Siêu dữ liệu). Việc truy cập vào một trong hai Server sẽ hiển thị một trang web cơ bản với tên server Server và địa chỉ IP công khai, điều này sẽ hữu ích cho việc kiểm tra server ứng dụng nào mà bộ 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 server

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

Để hoàn thành hướng dẫn này, bạn cần có thông tin sau về server của bạn :

  • server ứng dụng : Địa chỉ IP riêng
  • bộ cân bằng tải Địa chỉ IP riêng và cố định

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

Cách dễ nhất để tìm địa chỉ IP riêng của Server là sử dụng curl để lấy địa chỉ IP riêng từ dịch vụ metadata DigitalOcean. Lệnh này sẽ được chạy từ bên trong Server. Trên mỗi server , nhập:

  • 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ổ dòng lệnh:

Private IP address:
10.132.20.236

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

Tìm địa chỉ IP neo

IP neo là địa chỉ IP riêng local mà IP nổi sẽ liên kết với khi được gắn vào server DigitalOcean. Nó chỉ đơn giản là một alias cho địa chỉ eth0 thông thường, được thực hiện ở cấp siêu giám sát.

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

  • 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ó:

Output
10.17.1.18

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

Cấu hình server ứng dụng

Sau khi thu thập dữ liệu ở trên, ta có thể chuyển sang cấu hình các dịch vụ của bạn .

Ghi chú
Trong cài đặt này, phần mềm được chọn cho lớp web server có thể swap cho nhau. Hướng dẫn này sẽ sử dụng Nginx vì nó chung chung và khá dễ cấu hình. Nếu bạn thấy phù hợp hơn với Apache hoặc web server dành riêng cho ngôn ngữ (có khả năng production ), hãy sử dụng nó để thay thế. HAProxy sẽ chỉ chuyển các yêu cầu của client đến các web server backend , server này 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 client trực tiếp.

Ta sẽ bắt đầu bằng cách cài đặt các server ứng dụng backend của ta . Cả hai server này sẽ chỉ phục vụ tên và địa chỉ IP công cộng của chúng; trong một cài đặt thực, các server này sẽ phục vụ nội dung giống hệt 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 lưu lượng truy cập được chuyển hướng độc quyền qua một trong hai server HAProxy mà ta sẽ cấu hình sau này.

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

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

Nếu bạn đang làm theo ví dụ và bạn đã sử dụng dữ liệu user được cung cấp khi tạo server ứng dụng, thì server 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.

Ta 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 server . Hơn nữa, ta sẽ chỉ phục vụ các yêu cầu đến từ địa chỉ IP riêng của hai bộ cân bằng tải của ta . Điều này sẽ buộc user truy cập server ứng dụng của bạn thông qua bộ cân bằng tải của bạn (mà ta sẽ 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ở file khối server Nginx mặc định trên mỗi server ứng dụng của bạn:

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

Để bắt đầu, ta sẽ sửa đổi các chỉ thị listen . Thay đổi chỉ thị listen để lắng nghe địa chỉ IP riêng của server ứng dụng hiện tại trên cổng 80. Xóa dòng listen bổ sung. Nó trông giống như sau :

/ etc / nginx / sites-available / default (1 trong 2)
server {     listen app_server_private_IP:80;      . . .

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

/ etc / nginx / sites-available / default (2 trên 2)
    allow load_balancer_1_private_IP;     allow load_balancer_2_private_IP;     deny all;

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

Kiểm tra xem các thay đổi bạn đã thực hiện có đại diện cho cú pháp Nginx hợp lệ hay không bằng lệnh :

  • sudo nginx -t

Nếu không có sự cố nào được báo cáo, hãy khởi động lại daemon Nginx bằng lệnh :

  • 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 server ứng dụng thích hợp) trên cả hai server ứng dụng.

Kiểm tra các thay đổi

Để kiểm tra xem server ứng dụng của bạn có bị giới hạn đúng cách hay không, bạn có thể đưa ra yêu cầu bằng cách sử dụng curl từ các vị trí khác nhau.

Trên chính các server ứ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 local bằng lệnh :

  • curl 127.0.0.1

Do các hạn chế mà ta đặt ra trong các file khối server Nginx của bạn , yêu cầu này sẽ thực sự bị từ chối:

Output
curl: (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à ta đã cố gắng thực hiện.

Như vậy, từ một trong hai bộ cân bằng tải , ta có thể đưa ra yêu cầu cho một trong hai địa chỉ IP công cộng của server ứng dụng của ta :

  • curl web_server_public_IP

, điều này sẽ thất bại. Các server ứng dụng không lắng nghe trên giao diện công khai và hơn nữa, khi sử dụng địa chỉ IP công cộng, các server ứng dụng của ta sẽ không 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 ta :

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

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

  • curl app_server_private_IP

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

app server index.html
Server: app-1, IP Address: 159.203.130.34

Kiểm tra điều này từ cả hai trình cân bằng tải cho cả hai server ứ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 thực hiện cho 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, ta có thể tiếp tục. Cấu hình server ứng dụng backend của ta hiện đã hoàn tất.

Xóa Nginx khỏi Load Balancers

Theo Hướng dẫn cài đặt HA yêu cầu với Corosync, Pacemaker và Floating IPs , các server cân bằng tải của bạn sẽ được cài đặt Nginx. Bởi vì ta sẽ sử dụng HAProxy làm trình cân bằng tải Reverse Proxy , ta nên xóa Nginx và mọi tài nguyên cụm liên quan.

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 yêu cầu , hãy dừng và xóa tài nguyên Nginx bằng các lệnh sau trên một trong các bộ cân bằng tải của bạn :

  • sudo crm resource stop Nginx 
  • sudo crm configure delete Nginx

Thao tác này cũng sẽ xóa cài đặt cụm nào phụ thuộc vào tài nguyên Nginx . Ví dụ, nếu bạn tạo ra một clone hoặc colocation rằng tài liệu tham khảo các Nginx tài nguyên, họ cũng sẽ bị xóa.

Xóa gói Nginx

Bây giờ ta đã sẵn sàng gỡ cài đặt Nginx trên cả hai server cân bằng tải .

Trước tiên, hãy 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ể cần xóa các file cấu hình Nginx:

  • sudo rm -r /etc/nginx

Bây giờ 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, ta sẽ cài đặt bộ cân bằng tải HAProxy. Mỗi thứ này sẽ ngồi trước web server của ta và phân chia yêu cầu giữa hai server ứng dụng backend . Các bộ cân bằng tải này sẽ hoàn toàn dư thừa, trong cấu hình chủ động-thụ động; chỉ 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 đến cả hai web server . Bộ cân bằng tải sẽ lắng nghe các yêu cầu trên địa chỉ IP neo của chúng. Như đã đề cập trước đó, đây là địa chỉ IP mà địa chỉ IP nổi sẽ liên kết khi được gắn vào Server. Điều này đảm bảo chỉ lưu lượng truy cập bắt nguồn từ địa chỉ IP nổi mới được chuyển tiếp.

Cài đặt HAProxy

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

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

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

Cập nhật index gói local trên bộ cân bằng tải của bạn và cài đặt HAProxy bằng lệnh :

  • sudo apt-get update 
  • sudo apt-get install haproxy

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

Cấu hình HAProxy

Mở file cấu hình HAProxy chính:

  • sudo vi /etc/haproxy/haproxy.cfg

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

/etc/haproxy/haproxy.cfg (1 trong 3)
    option forwardfor     option http-server-close

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

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

/etc/haproxy/haproxy.cfg (2/3)
frontend http     bind    load_balancer_anchor_IP:80     default_backend app_pool

Lưu ý: IP neo là phần duy nhất của cấu hình HAProxy sẽ khác nhau giữa các server cân bằng tải. Đó là, hãy đảm bảo chỉ định IP neo của server cân bằng tải mà bạn hiện đang làm việc.

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

/etc/haproxy/haproxy.cfg (3/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 thực hiện xong các thay đổi trên, hãy lưu và thoát khỏi file .

Kiểm tra xem các thay đổi cấu hình mà ta thực hiện có đại diện cho cú pháp HAProxy hợp lệ hay không bằng lệnh :

  • 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 lệnh :

  • sudo service haproxy restart

, hãy đảm bảo thực hiện tất cả các bước trong phần này trên cả hai server cân bằng tải.

Kiểm tra các thay đổi

Ta có thể đảm bảo cấu hình của ta hợp lệ bằng cách thử nghiệm lại với curl .

Từ các server của bộ cân bằng tải, hãy thử yêu cầu server local , địa chỉ IP công cộng của bộ cân bằng tải hoặc địa chỉ IP riêng của server :

  • 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:

Output
curl: (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 đối với địa chỉ IP neo của bộ cân bằng tải, nó sẽ hoàn tất thành công:

  • curl load_balancer_anchor_IP

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

app server index.html
Server: app-1, IP Address: app1_IP_address

Thực hiện lại yêu cầu cuộn tóc tương tự:

  • curl load_balancer_anchor_IP

Bạn sẽ thấy trang index.html của server ứ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.html
Server: app-2, IP Address: app2_IP_address

Nếu hành vi này trùng với hành vi của hệ thống , thì bộ cân bằng tải của bạn đã được cấu hình chính xác; bạn đã kiểm tra thành công rằng server cân bằng tải của bạn đang cân bằng lưu lượng giữa cả hai server ứng dụng backend . Ngoài ra, IP nổi của bạn nên đã được chỉ định cho một trong các server cân bằng tải, vì điều đó đã được cài đặt trong hướng dẫn Cài đặt HA yêu cầu với Corosync, Pacemaker và Floating IPs .

Download HAProxy OCF Resource Agent

Đến đây, bạn đã có chuyển đổi dự phòng cấp server , cơ bản nhưng ta có thể cải thiện cài đặt 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 HAProxy đang chạy trên server mà IP nổi của bạn được chỉ định. Nếu Pacemaker phát hiện ra rằng HAProxy không chạy, nó có thể khởi động lại dịch vụ hoặc gán IP nổi cho nút khác (nút đó phải đang chạy HAProxy).

Pacemaker 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 folder cụ thể.

Trên cả hai server cân bằng tải , download tác nhân tài nguyên HAProxy OCF bằng 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 server cân bằng tải , hãy làm cho nó 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 tập lệnh shell được dùng để quản lý dịch vụ HAProxy.

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

Thêm tài nguyên haproxy

Với tác nhân tài nguyên HAProxy OCF của ta được cài đặt, giờ đây ta có thể cấu hình tài nguyên haproxy sẽ cho phép cụm quản lý HAProxy.

Trên một trong hai server cân bằng tải , hãy tạo tài nguyên nguyên thủy haproxy bằng lệnh sau:

  • 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 giám sát HAProxy 15 giây một lần và khởi động lại nó 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 status sudo crm_mon hoặc 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, máy tạo nhịp tim có thể quyết định để bắt đầu haproxy và FloatIP nguồn lực trên các node riêng biệt bởi vì ta chưa xác định bất kỳ hạn chế tài nguyên. Đây là sự cố vì IP nổi có thể đang trỏ đến một Server trong khi dịch vụ HAProxy đang chạy trên Server khác. Việc truy cập IP nổi sẽ chỉ bạn đến một server không chạy dịch vụ cần có khả năng cao.

Để giải quyết vấn đề này, ta sẽ tạo một tài nguyên nhân bản , tài nguyên này chỉ đị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 tài nguyên haproxy được gọi là “haproxy-clone” bằng lệnh sau:

  • sudo crm configure clone haproxy-clone haproxy

Trạng thái cụm bây 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 thấy , tài nguyên sao chép, haproxy-clone , hiện đã được bắt đầu trên cả hai nút của ta .

Bước cuối cùng là cấu hình hạn chế vị trí, để chỉ định rằng tài nguyên FloatIP sẽ chạy trên một nút có tài nguyên haproxy-clone đang hoạt động. Để tạo một hạn chế vị trí có tên “FloatIP-haproxy”, hãy sử dụng lệnh sau:

  • 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 kết quả trạng thái crm, nhưng bạn có thể thấy rằng tài nguyên vị trí đã được tạo bằng lệnh này:

  • sudo crm configure show

Bây giờ, cả hai server của bạn phải chạy HAProxy, trong khi chỉ 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ột trong hai server cân bằng tải:

  • sudo service haproxy stop

Bạn sẽ nhận thấy rằng nó sẽ khởi động lại trong vòng 15 giây tới.

Tiếp theo, ta sẽ kiểm tra cài đặt HA của bạn bằng cách khởi động lại server cân bằng tải đang hoạt động của bạn ( server mà tài nguyên FloatIP hiện đang “khởi động”).

Kiểm tra tính khả dụng cao của bộ cân bằng tải

Với cài đặt HAProxy Tính sẵn sàng cao mới, bạn cần kiểm tra xem mọi thứ có hoạt động như dự định không.

Để hình dung quá trình chuyển đổi giữa các bộ cân bằng tải tốt hơn, ta có thể theo dõi log Nginx của server ứng dụng trong quá trình chuyển đổi.

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

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

Trong khi thực hiện các thử nghiệm sắp tới, bạn có thể cần xem trạng thái thời gian thực của các node cụm và tài nguyên. Bạn có thể làm như vậy với lệnh này, trên một trong hai server cân bằng tải (miễn là nó đang chạy):

  • sudo crm_mon

Đầu ra sẽ 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 những nút cân bằng tải đang trực tuyến và có các node các FloatIP và haproxy nguồn lực được bắt đầu vào.

Lưu ý nút mà tài nguyên FloatIP được Started , chính trong ví dụ trên, là server cân bằng tải mà IP nổi hiện được gán cho. Ta sẽ gọi server này là server 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 local của bạn, ta 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 ta dễ dàng xem cách bộ cân bằng tải hoạt động đang xử lý lưu lượng đến. Đó là, ta sẽ xem các server ứng dụng backend mà nó đang gửi lưu lượng truy cập đến. Trong terminal local của bạn, hãy 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 phản hồi từ một trong các server ứng dụng backend . Nó có thể sẽ thay thế giữa app-1 và app-2 vì thuật toán cân bằng mặc định của HAProxy, mà ta chưa chỉ định, được đặt thành round-robin . Vì vậy, terminal của bạn sẽ hiển thị thông tin như sau:

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

Giữ cửa sổ terminal này mở để các yêu cầu liên tục được gửi đến server của bạn. Chúng sẽ hữu ích trong các bước thử nghiệm tiếp theo của ta .

Điều chỉnh log trên web server

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

Địa chỉ client là trường đầu tiên trong log truy cập, vì vậy sẽ dễ dàng tìm thấy. Chạy phần sau trên cả hai server ứng dụng Nginx của bạn (trong các cửa sổ terminal 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 server cân bằng tải đang hoạt động của bạn, cứ sau bốn giây ( ta sẽ cho rằng đó là trình cân bằng tải chính , nhưng nó có thể là địa chỉ phụ 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ữ lệnh tail chạy trên cả hai server ứng dụng của bạn.

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

Bây giờ, hãy khởi động lại bộ cân bằng tải chính , đảm bảo rằng chuyển đổi dự phòng Floating IP hoạt động:

  • sudo reboot

Bây giờ, hãy chú ý đến log truy cập Nginx trên cả hai server ứng dụng của bạn. Bạn nên lưu ý , sau khi chuyển đổi dự phòng Floating IP xảy ra, log truy cập cho thấy rằng server ứng dụng đang được truy cập bằng địa chỉ IP khác so với trước đây. Các bản ghi sẽ cho biết server cân bằng tải thứ cấp đang gửi các 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 lỗi của bộ cân bằng tải chính đã được phát hiện và IP nổi đã được chỉ định lại thành công cho bộ cân bằng tải thứ cấp.

Bạn cũng có thể cần kiểm tra kết quả của terminal local của bạn (đang truy cập IP nổi hai giây một lần) để xác minh trình cân bằng tải thứ cấp đang gửi yêu cầu đến cả hai server ứng dụng backend :

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

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

Cấu hình Nginx để ghi địa chỉ IP client thực tế

Như bạn đã thấy, log truy cập Nginx cho thấy rằng tất cả các yêu cầu của client là từ địa chỉ IP riêng của bộ cân bằng tải hiện tại, thay vì địa chỉ IP thực của client đã thực hiện yêu cầu ban đầu (tức là máy local của bạn). Thường hữu ích khi ghi lại địa chỉ IP của người yêu cầu ban đầu, thay vì server 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 server ứng dụng backend của bạn.

Trên cả hai server ứng dụng , hãy mở file nginx.conf trong editor :

  • sudo vi /etc/nginx/nginx.conf

Tìm phần “Cài đặt ghi log ” (trong khối http ) và thêm dòng sau:

thêm vào /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 một định dạng log mới có tên là haproxy_log , định dạng này sẽ thêm giá trị $http_x_forwarded_for — địa chỉ IP của ứng dụng client đã thực hiện yêu cầu ban đầu — vào các mục log truy cập mặc định. Ta cũng bao gồm $remote_addr , là địa chỉ IP của trình cân bằng tải Reverse Proxy (tức là server cân bằng tải hoạt động).

Tiếp theo, để sử dụng định dạng log mới này, ta cần thêm một dòng vào khối server mặc định của bạn .

Trên cả hai server ứng dụng , hãy mở cấu hình server default :

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

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

thêm vào / etc / nginx / sites-available / default
        access_log /var/log/nginx/access.log haproxy_log;

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

Trên cả hai server ứng dụng , hãy khởi động lại Nginx để các thay đổi có hiệu lực:

  • sudo service nginx restart

Như vậy, log truy cập Nginx của bạn phải chứa địa chỉ IP thực của các client đưa ra yêu cầu. Xác minh điều này bằng cách gắn thẻ log của server ứng dụng của bạn, như ta đã làm trong phần trước. Các mục log 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 log của bạn trông tốt, bạn đã sẵn sàng!

Kết luận

Trong hướng dẫn này, ta đã đi qua toàn bộ quy trình cài đặt cơ sở hạ tầng cân bằng tải, có tính khả dụng cao. Cấu hình này hoạt động tốt vì server HAProxy đang hoạt động có thể phân phối tải cho group server ứng dụng trên phần backend . Bạn có thể dễ dàng mở rộng quy mô group này khi nhu cầu của bạn tăng lên hoặc giảm xuống.

Cấu hình IP nổi và Corosync / Pacemaker giúp loại bỏ điểm lỗi duy nhất ở 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 bị lỗi hoàn toàn. Cấu hình này khá linh hoạt và có thể được điều chỉnh cho phù hợp với môi trường ứng dụng của bạn bằng cách cài đặt ứng dụng bạn muốn đằng sau server HAProxy.

Tags:

Các tin liên quan

Cách cài đặt Elasticsearch 1.7, Logstash 1.5 và Kibana 4.1 (ELK Stack) trên Ubuntu 14.04
2015-11-04
Cách cài đặt và cấu hình Elasticsearch trên Ubuntu 14.04
2015-10-26
Cách thiết lập server HAProxy khả dụng cao với các IP được lưu giữ và nổi trên Ubuntu 14.04
2015-10-23
Cách cài đặt Cassandra và chạy một cụm node đơn trên Ubuntu 14.04
2015-10-21
Cách tạo thiết lập tính khả dụng cao với Corosync, Pacemaker và IP nổi trên Ubuntu 14.04
2015-10-20
Cách tạo thiết lập tính khả dụng cao với Heartbeat và IP nổi trên Ubuntu 14.04
2015-10-20
Cách cài đặt và cấu hình server Salt Master và Minion trên Ubuntu 14.04
2015-10-05
Cách cài đặt và bắt đầu với Symfony 2 trên Ubuntu 14.04
2015-10-01
Cách cài đặt MemSQL trên Ubuntu 14.04
2015-09-30
Cách thiết lập xác thực đa yếu tố cho SSH trên Ubuntu 14.04
2015-09-29