Thứ sáu, 23/10/2015 | 00:00 GMT+7

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

Tính sẵn sàng cao là một chức năng của thiết kế hệ thống cho phép ứng dụng tự động khởi động lại hoặc định tuyến lại công việc sang một hệ thống có khả năng khác trong trường hợp có sự cố. Về server , cần có một số công nghệ khác nhau để cài đặt một hệ thống có tính khả dụng cao. Phải có một thành phần có thể chuyển hướng công việc và phải có một cơ chế giám sát sự cố và chuyển đổi hệ thống nếu phát hiện ra sự cố gián đoạn.

Daemon keepalived được dùng để giám sát các dịch vụ hoặc hệ thống và tự động chuyển đổi dự phòng sang chế độ chờ nếu sự cố xảy ra. Trong hướng dẫn này, ta sẽ trình bày cách sử dụng keepalived để cài đặt tính khả dụng cao cho các bộ cân bằng tải của bạn. Ta sẽ cấu hình một địa chỉ IP nổi có thể được di chuyển giữa hai bộ cân bằng tải có khả năng. Chúng sẽ được cấu hình để phân chia lưu lượng giữa hai web server 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.

Sơ đồ tính khả dụng 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 tạo bốn server Ubuntu 14.04 trong account DigitalOcean của bạn . Tất cả các server phải được đặt trong cùng một trung tâm dữ liệu và phải bật mạng riêng.

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ìm kiếm 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 :

  • web server : Đị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:

Output
10.132.20.236

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

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

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 web server backend của ta . Cả hai server này sẽ phục vụ chính xác cùng một nội dung. 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 qua một trong hai server HAProxy mà ta sẽ cấu hình sau này.

Việc cài đặt web server đằng sau bộ 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ố web server 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 các web server khỏi cấp này.

Cài đặt Nginx

Ta sẽ cài đặt Nginx trên các máy phục vụ web của bạn để cung cấp chức năng này.

Bắt đầu bằng cách đăng nhập với user sudo của bạn vào hai máy mà bạn muốn sử dụng làm web server . Cập nhật index gói local trên từng web server của bạn và cài đặt Nginx bằng lệnh :

  • sudo apt-get update
  • sudo apt-get install nginx

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

Tiếp theo, ta sẽ cấu hình các version Nginx của bạn . Ta muốn nói với 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 .

Để 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 web server của bạn:

  • sudo nano /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 web server hiện tại trên cổng 80. Xóa dòng listen phụ. Nó trông giống như sau :

/ etc / nginx / sites-available / default
server {     listen web_server_private_IP:80;      . . . 

Sau đó, 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
server {     listen web_server_private_IP:80;      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

Kiểm tra các thay đổi

Để kiểm tra xem web server 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 web server 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.

Bây giờ, từ một trong hai bộ cân bằng tải , ta có thể yêu cầu một trong hai địa chỉ IP công cộng của web server của ta :

  • curl web_server_public_IP

, điều này sẽ thất bại. Các web server không lắ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 cộng, các web server của ta 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 ta :

Output
curl: (7) Failed to connect to web_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 web server , nó sẽ hoạt động chính xác:

  • curl web_server_private_IP

Trang Nginx index.html mặc định sẽ được trả về:

Output
<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> . . .

Kiểm tra điều này từ cả hai bộ cân bằng tải cho cả hai web server . 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 web server backend của ta hiện đã hoàn tất.

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 backend . Những bộ cân bằng tải này hoàn toàn dư thừa. 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

Bước đầu tiên ta cần thực hiện trên bộ cân bằng tải sẽ là cài đặt gói haproxy . Ta có thể tìm thấy điều này trong repository lưu trữ mặc định của Ubuntu. 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

Cấu hình HAProxy

Mục đầu tiên ta cần sửa đổi khi xử lý HAProxy là file /etc/default/haproxy . Mở file đó ngay bây giờ trong editor :

  • sudo nano /etc/default/haproxy

Tệp này xác định xem HAProxy có bắt đầu khi server khởi động hay không. Vì ta muốn dịch vụ tự động khởi động mỗi khi server bật nguồn, ta cần thay đổi giá trị của ENABLED thành “1”:

/ etc / default / haproxy
# Set ENABLED to 1 if you want the init script to start haproxy. ENABLED=1 # Add extra flags here. #EXTRAOPTS="-de -m 16" 

Lưu file sau khi thực hiện chỉnh sửa ở trên.

Tiếp theo, ta có thể mở file cấu hình HAProxy chính:

  • sudo nano /etc/haproxy/haproxy.cfg

Mục đầu tiên ta cần điều chỉnh là chế độ mà HAProxy sẽ hoạt động. Ta muốn cấu hình cân bằng tải TCP, hoặc lớp 4. Để làm điều này, ta cần thay đổi dòng mode trong phần default . Ta cũng nên thay đổi tùy chọn ngay sau đây liên quan đến log :

/etc/haproxy/haproxy.cfg
. . .  defaults     log     global     mode    tcp     option  tcplog  . . . 

Ở cuối file , ta cần xác cấu hình giao diện user . Đ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à “www” để đơn giản hóa. Ta cũng sẽ chỉ định một chương trình backend mặc định để 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
. . .  defaults     log     global     mode    tcp     option  tcplog  . . .  frontend www     bind    load_balancer_anchor_IP:80     default_backend nginx_pool 

Tiếp theo, ta có thể cấu hình phần backend của bạn . Đ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 web server Nginx mà ta đã cấu hình . Ta sẽ chỉ định cân bằng vòng tròn truyền thống và sẽ đặt lại chế độ thành “tcp”:

/etc/haproxy/haproxy.cfg
. . .  defaults     log     global     mode    tcp     option  tcplog  . . .  frontend www     bind load_balancer_anchor_IP:80     default_backend nginx_pool  backend nginx_pool     balance roundrobin     mode tcp     server web1 web_server_1_private_IP:80 check     server web2 web_server_2_private_IP:80 check 

Khi bạn hoàn thành các thay đổi trên, hãy lưu 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

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 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 mặc định, được định tuyến từ một trong hai web server backend :

Output
<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> . . .

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.

Xây dựng và cài đặt Keepalived

Dịch vụ thực tế của ta hiện đang hoạt động. Tuy nhiên, cơ sở hạ tầng của ta chưa khả dụng cao vì ta không có cách nào chuyển hướng lưu lượng truy cập nếu bộ cân bằng tải hoạt động của ta gặp sự cố. Để khắc phục điều này, ta sẽ cài đặt trình keepalived trên các server cân bằng tải của ta . Đây là thành phần sẽ cung cấp khả năng chuyển đổi dự phòng nếu trình cân bằng tải hoạt động của ta không khả dụng.

Có một version keepalived trong repository lưu trữ mặc định của Ubuntu, nhưng nó đã lỗi thời và mắc phải một số lỗi khiến cấu hình của ta không thể hoạt động. Thay vào đó, ta sẽ cài đặt version mới nhất của keepalived từ nguồn.

Trước khi bắt đầu, ta nên nắm bắt các phụ thuộc mà ta cần để xây dựng phần mềm. Các build-essential meta-package sẽ cung cấp các công cụ biên dịch ta cần, trong khi libssl-dev gói chứa các thư viện phát triển SSL keepalived nhu cầu để xây dựng đối với:

  • sudo apt-get install build-essential libssl-dev

Khi các phụ thuộc đã sẵn sàng, ta có thể download tarball cho keepalived . Truy cập trang này để tìm version mới nhất của phần mềm. Nhấp chuột phải vào version mới nhất và sao chép địa chỉ liên kết. Quay lại server của bạn, di chuyển đến folder chính của bạn và sử dụng wget để lấy liên kết bạn đã sao chép:

  • cd ~
  • wget http://www.keepalived.org/software/keepalived-1.2.19.tar.gz

Sử dụng lệnh tar để mở rộng repository . Di chuyển vào folder kết quả:

  • tar xzvf keepalived*
  • cd keepalived*

Xây dựng và cài đặt daemon bằng lệnh :

  • ./configure
  • make
  • sudo make install

Daemon bây giờ sẽ được cài đặt trên cả hai hệ thống cân bằng tải.

Tạo tập lệnh khởi động Keepalived

Bản cài đặt keepalived đã di chuyển tất cả các file binary và file hỗ trợ vào vị trí trên hệ thống của ta . Tuy nhiên, một phần không được bao gồm là tập lệnh Khởi động cho hệ thống Ubuntu 14.04 của ta .

Ta có thể tạo ra một kịch bản Upstart rất đơn giản mà có thể xử lý ta keepalived dịch vụ. Mở một file có tên keepalived.conf trong folder /etc/init để bắt đầu:

  • sudo nano /etc/init/keepalived.conf

Bên trong, ta có thể bắt đầu với một mô tả đơn giản về chức năng mà keepalived cung cấp. Ta sẽ sử dụng mô tả từ trang man bao gồm. Tiếp theo, ta sẽ chỉ định các runlevel mà dịch vụ sẽ được bắt đầu và dừng lại. Ta muốn dịch vụ này hoạt động trong mọi điều kiện bình thường (cấp độ 2-5) và bị dừng đối với tất cả các cấp độ chạy khác (ví dụ: khi khởi động lại, khởi động máy hoặc chế độ một user ):

/etc/init/keepalived.conf
description "load-balancing and high-availability service"  start on runlevel [2345] stop on runlevel [!2345] 

Vì dịch vụ này không thể thiếu đảm bảo dịch vụ web của ta vẫn khả dụng, ta muốn khởi động lại dịch vụ này trong trường hợp không thành công. Sau đó ta có thể xác định thực tế exec dòng đó sẽ bắt đầu dịch vụ. Ta cần thêm tùy chọn --dont-fork để Upstart có thể theo dõi pid một cách chính xác:

/etc/init/keepalived.conf
description "load-balancing and high-availability service"  start on runlevel [2345] stop on runlevel [!2345]  respawn  exec /usr/local/sbin/keepalived --dont-fork 

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

Tạo file cấu hình Keepalived

Với các file Upstart của ta tại chỗ, bây giờ ta có thể chuyển sang cấu hình keepalived .

Dịch vụ tìm kiếm các file cấu hình của nó trong folder /etc/keepalived . Tạo folder đó ngay bây giờ trên cả hai bộ cân bằng tải của bạn:

  • sudo mkdir -p /etc/keepalived

Tạo cấu hình của bộ cân bằng tải chính

Tiếp theo, trên server cân bằng tải mà bạn muốn sử dụng làm server chính của bạn , hãy tạo file cấu hình keepalived chính. Daemon tìm kiếm một file có tên keepalived.conf bên trong folder /etc/keepalived :

  • sudo nano /etc/keepalived/keepalived.conf

Bên trong, ta sẽ bắt đầu bằng cách xác định kiểm tra tình trạng cho dịch vụ HAProxy của ta bằng cách mở khối vrrp_script . Điều này sẽ cho phép keepalived giám sát bộ cân bằng tải của ta để tìm các lỗi để nó có thể báo hiệu rằng quá trình đang hoạt động và bắt đầu các biện pháp khôi phục.

Kiểm tra của ta sẽ rất đơn giản. Cứ sau hai giây, ta sẽ kiểm tra xem quá trình có tên haproxy vẫn đang xác nhận pid :

/Etc/keepalived/keepalived.conf của server chính
vrrp_script chk_haproxy {     script "pidof haproxy"     interval 2 } 

Tiếp theo, ta sẽ mở một khối có tên vrrp_instance . Đây là phần cấu hình chính xác định cách thức mà keepalived sẽ triển khai tính khả dụng cao.

Ta sẽ bắt đầu bằng cách yêu cầu keepalived giao tiếp với các đồng nghiệp của nó qua eth1 , giao diện riêng tư của ta . Vì ta đang cấu hình server chính của bạn , ta sẽ đặt cấu hình state thành “MASTER”. Đây là giá trị ban đầu mà keepalived sẽ sử dụng cho đến khi daemon có thể liên hệ với đồng nghiệp của nó và tổ chức một cuộc bầu cử.

Trong cuộc bầu cử, tùy chọn priority được sử dụng để quyết định thành viên nào được bầu. Quyết định chỉ đơn giản dựa trên server nào có số lượng cao nhất cho cài đặt này. Ta sẽ sử dụng “200” cho server chính của bạn :

/Etc/keepalived/keepalived.conf của server chính
vrrp_script chk_nginx {     script "pidof nginx"     interval 2 }  vrrp_instance VI_1 {     interface eth1     state MASTER     priority 200   } 

Tiếp theo, ta sẽ chỉ định một ID cho group cụm này sẽ được chia sẻ bởi cả hai nút. Ta sẽ sử dụng “33” cho ví dụ này. Ta cần đặt unicast_src_ip thành địa chỉ IP riêng của trình cân bằng tải chính của ta . Ta sẽ đặt unicast_peer thành địa chỉ IP riêng của trình cân bằng tải thứ cấp của ta :

/Etc/keepalived/keepalived.conf của server chính
vrrp_script chk_haproxy {     script "pidof haproxy"     interval 2 }  vrrp_instance VI_1 {     interface eth1     state MASTER     priority 200      virtual_router_id 33     unicast_src_ip primary_private_IP     unicast_peer {         secondary_private_IP     }   } 

Tiếp theo, ta có thể cài đặt một số chứng thực đơn giản cho ta keepalived daemon để giao tiếp với nhau. Đây chỉ là một biện pháp cơ bản đảm bảo rằng người ngang hàng được liên hệ là hợp lệ . Tạo một khối phụ authentication . Bên trong, chỉ định xác thực password bằng cách đặt auth_type . Đối với thông số auth_pass , hãy đặt bí mật được chia sẻ sẽ được cả hai nút sử dụng. Thật không may, chỉ có tám ký tự đầu tiên là quan trọng:

/Etc/keepalived/keepalived.conf của server chính
vrrp_script chk_haproxy {     script "pidof haproxy"     interval 2 }  vrrp_instance VI_1 {     interface eth1     state MASTER     priority 200      virtual_router_id 33     unicast_src_ip primary_private_IP     unicast_peer {         secondary_private_IP     }      authentication {         auth_type PASS         auth_pass password     }   } 

Tiếp theo, ta sẽ yêu cầu keepalived sử dụng séc mà ta đã tạo ở đầu file , có nhãn chk_haproxy , để xác định tình trạng của hệ thống local . Cuối cùng, ta sẽ cài đặt một tập notify_master , được thực thi khi nào nút này trở thành "chủ" của cặp. Tập lệnh này sẽ chịu trách nhiệm kích hoạt việc gán lại địa chỉ IP nổi. Ta sẽ tạo tập lệnh này trong giây lát:

/Etc/keepalived/keepalived.conf của server chính
vrrp_script chk_haproxy {     script "pidof haproxy"     interval 2 }  vrrp_instance VI_1 {     interface eth1     state MASTER     priority 200      virtual_router_id 33     unicast_src_ip primary_private_IP     unicast_peer {         secondary_private_IP     }      authentication {         auth_type PASS         auth_pass password     }      track_script {         chk_haproxy     }      notify_master /etc/keepalived/master.sh } 

Khi bạn đã cài đặt thông tin ở trên, hãy lưu file .

Tạo cấu hình của bộ cân bằng tải thứ cấp

Tiếp theo, ta sẽ tạo tập lệnh đồng hành trên bộ cân bằng tải thứ cấp của ta . Mở file tại /etc/keepalived/keepalived.conf trên server phụ của bạn:

  • sudo nano /etc/keepalived/keepalived.conf

Bên trong, tập lệnh mà ta sẽ sử dụng phần lớn sẽ tương đương với tập lệnh của server chính. Các mục mà ta cần thay đổi là:

  • state : Điều này sẽ được thay đổi thành “DỰ PHÒNG” trên server phụ để nút khởi tạo sang trạng thái dự phòng trước khi cuộc bầu cử diễn ra.
  • priority : Giá trị này phải được đặt thành giá trị thấp hơn server chính. Ta sẽ sử dụng giá trị “100” trong hướng dẫn này.
  • unicast_src_ip : Đây phải là địa chỉ IP riêng của server phụ .
  • unicast_peer : Cái này phải chứa địa chỉ IP riêng của server chính .

Khi bạn thay đổi các giá trị đó, tập lệnh cho server phụ sẽ giống như sau:

/Etc/keepalived/keepalived.conf của server phụ
vrrp_script chk_haproxy {     script "pidof haproxy"     interval 2 }  vrrp_instance VI_1 {     interface eth1     state BACKUP     priority 100      virtual_router_id 33     unicast_src_ip secondary_private_IP     unicast_peer {         primary_private_IP     }      authentication {         auth_type PASS         auth_pass password     }      track_script {         chk_haproxy     }      notify_master /etc/keepalived/master.sh } 

Khi bạn đã nhập tập lệnh và thay đổi các giá trị thích hợp, hãy lưu file .

Tạo Tập lệnh chuyển đổi IP nổi

Tiếp theo, ta cần tạo một cặp script mà ta có thể sử dụng để gán lại địa chỉ IP nổi cho Server hiện tại khi nào cá thể keepalived local trở thành server chính.

Download Tập lệnh gán IP nổi

Đầu tiên, ta sẽ download tập lệnh Python chung (được viết bởi người quản lý cộng đồng DigitalOcean ) được dùng để gán lại địa chỉ IP nổi cho Server bằng API DigitalOcean. Ta nên tải file này xuống folder /usr/local/bin :

  • cd /usr/local/bin
  • sudo curl -LO http://do.co/assign-ip

Tập lệnh này cho phép bạn gán lại một IP nổi hiện có bằng lệnh:

  • python /usr/local/bin/assign-ip floating_ip server_ID

Điều này sẽ chỉ hoạt động nếu bạn đã đặt biến môi trường có tên DO_TOKEN thành mã thông báo API DigitalOcean hợp lệ cho account của bạn .

Tạo mã thông báo API DigitalOcean

Để sử dụng tập lệnh ở trên, ta cần tạo mã thông báo API DigitalOcean trong account của bạn .

Trong console , nhấp vào liên kết "API" ở trên cùng. Ở phía bên phải của trang API, hãy nhấp vào “Tạo mã thông báo mới”:

DigitalOcean tạo mã thông báo API

Trên trang tiếp theo, chọn tên cho mã thông báo của bạn và nhấp vào nút “Tạo mã thông báo”:

DigitalOcean tạo mã thông báo mới

Trên trang API, mã thông báo mới của bạn sẽ được hiển thị:

Mã thông báo DigitalOcean

Sao chép mã thông báo ngay bây giờ . Vì mục đích bảo mật, không có cách nào để hiển thị lại mã thông báo này sau đó. Nếu bạn mất mã thông báo này, bạn sẽ phải xóa nó và tạo một mã khác.

Cấu hình IP nổi cho Cơ sở hạ tầng của bạn

Tiếp theo, ta sẽ tạo và gán một địa chỉ IP nổi để sử dụng cho các server của bạn .

Trong console DigitalOcean, nhấp vào tab “Mạng” và chọn mục chuyển “IP nổi”. Chọn bộ cân bằng tải chính của bạn từ menu cho nhiệm vụ ban đầu:

DigitalOcean thêm IP nổi

Một địa chỉ IP nổi mới sẽ được tạo trong account của bạn và được gán cho Server được chỉ định:

Đã chỉ định IP nổi DigitalOcean

Nếu bạn truy cập IP nổi trong trình duyệt web của bạn , bạn sẽ thấy trang Nginx mặc định được cung cấp từ một trong các web server backend :

DigitalOcean mặc định index.html

Sao chép địa chỉ IP nổi xuống. Bạn cần giá trị này trong script bên dưới.

Tạo tập lệnh gói

Bây giờ, ta có các mục ta cần để tạo tập lệnh shell bọc sẽ gọi tập lệnh /usr/local/bin/assign-ip của ta với thông tin xác thực chính xác.

Tạo file ngay bây giờ trên cả hai bộ cân bằng tải của bạn bằng lệnh :

  • sudo nano /etc/keepalived/master.sh

Bên trong, hãy bắt đầu bằng cách gán và xuất một biến có tên DO_TOKEN chứa mã thông báo API bạn vừa tạo. Dưới đó, ta có thể chỉ định một biến có tên IP giữ địa chỉ IP nổi của bạn:

/etc/keepalived/master.sh
export DO_TOKEN='digitalocean_api_token' IP='floating_ip_addr' 

Tiếp theo, ta sẽ sử dụng curl để yêu cầu dịch vụ metadata cho ID server của server mà ta hiện đang sử dụng. Điều này sẽ được gán cho một biến được gọi là ID . Ta cũng sẽ hỏi liệu Server này hiện có địa chỉ IP nổi được gán cho nó hay không. Ta sẽ lưu trữ kết quả của yêu cầu đó trong một biến có tên HAS_FLOATING_IP :

/etc/keepalived/master.sh
export DO_TOKEN='digitalocean_api_token' IP='floating_ip_addr' ID=$(curl -s http://169.254.169.254/metadata/v1/id) HAS_FLOATING_IP=$(curl -s http://169.254.169.254/metadata/v1/floating_ip/ipv4/active) 

Bây giờ, ta có thể sử dụng các biến ở trên để gọi tập lệnh assign-ip . Ta sẽ chỉ gọi tập lệnh nếu IP nổi chưa được liên kết với Server của ta . Điều này sẽ giúp giảm thiểu các lệnh gọi API và sẽ giúp ngăn chặn các yêu cầu xung đột đối với API trong trường hợp trạng thái chính chuyển đổi nhanh chóng giữa các server của bạn.

Để xử lý các trường hợp IP nổi đã có một sự kiện đang diễn ra, ta sẽ thử lại tập lệnh assign-ip một vài lần. Dưới đây, ta cố gắng chạy tập lệnh 10 lần, với khoảng cách 3 giây giữa mỗi lần gọi. Vòng lặp sẽ kết thúc ngay lập tức nếu di chuyển IP nổi thành công:

/etc/keepalived/master.sh
export DO_TOKEN='digitalocean_api_token' IP='floating_ip_addr' ID=$(curl -s http://169.254.169.254/metadata/v1/id) HAS_FLOATING_IP=$(curl -s http://169.254.169.254/metadata/v1/floating_ip/ipv4/active)  if [ $HAS_FLOATING_IP = "false" ]; then     n=0     while [ $n -lt 10 ]     do         python /usr/local/bin/assign-ip $IP $ID && break         n=$((n+1))         sleep 3     done fi 

Lưu file khi bạn hoàn tất.

Bây giờ, ta chỉ cần làm cho tập lệnh có thể thực thi để keepalived có thể gọi nó:

  • sudo chmod +x /etc/keepalived/master.sh

Khởi động dịch vụ Keepalived và thử nghiệm chuyển đổi dự phòng

Daemon keepalived và tất cả các tập lệnh đồng hành của nó bây giờ sẽ được cấu hình hoàn chỉnh. Ta có thể bắt đầu dịch vụ trên cả hai bộ cân bằng tải của bạn bằng lệnh :

  • sudo start keepalived

Dịch vụ sẽ khởi động trên mỗi server và liên hệ với đồng đẳng của nó, xác thực bằng bí mật được chia sẻ mà ta đã cấu hình . Mỗi daemon sẽ giám sát quá trình HAProxy local , và sẽ lắng nghe tín hiệu từ điều khiển từ xa keepalived quá trình.

Bộ cân bằng tải chính của bạn, hiện phải có địa chỉ IP nổi được gán cho nó, sẽ lần lượt chuyển các yêu cầu đến từng server Nginx backend . Có một số phiên cố định đơn giản thường được áp dụng, khiến nhiều khả năng bạn sẽ nhận được phần backend tương tự khi thực hiện yêu cầu thông qua trình duyệt web.

Ta có thể kiểm tra chuyển đổi dự phòng theo cách đơn giản bằng cách tắt HAProxy trên bộ cân bằng tải chính của ta :

  • sudo service haproxy stop

Nếu ta truy cập địa chỉ IP nổi của bạn trong trình duyệt của bạn , ta có thể ngay lập tức gặp lỗi cho biết không thể tìm thấy trang:

http://floating_IP_addr 

Trang DigitalOcean không khả dụng

Nếu ta làm mới trang một vài lần, trong giây lát, trang Nginx mặc định của ta sẽ hoạt động trở lại:

DigitalOcean mặc định index.html

Dịch vụ HAProxy của ta vẫn không hoạt động trên bộ cân bằng tải chính, vì vậy điều này cho thấy rằng bộ cân bằng tải thứ cấp của ta đã tiếp quản. Sử dụng keepalived , server phụ có thể xác định rằng đã xảy ra gián đoạn dịch vụ. Sau đó, nó chuyển sang trạng thái “chính” và xác nhận IP nổi bằng API DigitalOcean.

Bây giờ ta có thể khởi động lại HAProxy trên bộ cân bằng tải chính:

  • sudo service haproxy start

Bộ cân bằng tải chính sẽ lấy lại quyền kiểm soát địa chỉ IP nổi trong giây lát, mặc dù điều này sẽ khá minh bạch với user .

Hình dung sự chuyển đổi

Để 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 một số log server của bạn 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.

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

Trên mỗi web server 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ì 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 tổng hợp, mỗi web server backend sẽ thấy khoảng một nửa số yêu cầu được thực hiện.

May mắn là địa chỉ khách hàng là trường đầu tiên trong log truy cập. Ta có thể extract giá trị bằng lệnh awk đơn giản. Chạy các bước sau trên cả hai web server Nginx của bạn:

  • sudo tail -f /var/log/nginx/access.log | awk '{print $1;}'

Những điều này có thể sẽ hiển thị chủ yếu một địa chỉ:

Output
. . . primary_lb_private_IP primary_lb_private_IP secondary_lb_private_IP secondary_lb_private_IP primary_lb_private_IP primary_lb_private_IP primary_lb_private_IP primary_lb_private_IP

Nếu bạn tham chiếu địa chỉ IP server của bạn , bạn sẽ nhận thấy rằng những địa chỉ này chủ yếu đến từ bộ cân bằng tải chính của bạn. Lưu ý phân phối thực tế có thể sẽ hơi khác một chút do một số phiên đơn giản mà HAProxy triển khai.

Giữ cho lệnh tail chạy trên cả hai web server của bạn.

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

Bây giờ, trên máy local của bạn, ta sẽ yêu cầu nội dung web ở địa chỉ IP nổi cứ 2 giây một lần. Điều này sẽ cho phép ta dễ dàng thấy sự thay đổi của bộ cân bằng tải xảy ra. Trong terminal local của bạn, hãy nhập như sau ( ta đang loại bỏ phản hồi thực tế, vì điều này sẽ giống nhau dù bộ cân bằng tải nào đang được sử dụng):

  • while true; do curl -s -o /dev/null floating_IP; sleep 2; done

Trên các web server của bạn , bạn sẽ bắt đầu thấy các yêu cầu mới xuất hiện. Không giống như các yêu cầu được thực hiện thông qua trình duyệt web, các yêu cầu curl đơn giản không thể hiện độ dính phiên giống nhau. Bạn sẽ thấy sự phân chia đồng đều hơn các yêu cầu đến web server backend của bạn .

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

Bây giờ, ta có thể tắt lại dịch vụ HAProxy trên bộ cân bằng tải chính của bạn :

  • sudo service haproxy stop

Sau một vài giây, trên web server của bạn, bạn sẽ thấy danh sách các IP chuyển đổi từ địa chỉ IP riêng của bộ cân bằng tải chính sang địa chỉ IP riêng của bộ cân bằng tải thứ cấp:

Output
. . . primary_lb_private_IP primary_lb_private_IP primary_lb_private_IP primary_lb_private_IP primary_lb_private_IP secondary_lb_private_IP secondary_lb_private_IP secondary_lb_private_IP secondary_lb_private_IP

Tất cả các yêu cầu mới được thực hiện từ bộ cân bằng tải thứ cấp của bạn.

Bây giờ, hãy khởi động lại version HAProxy trên bộ cân bằng tải chính của bạn:

  • sudo service haproxy start

Bạn sẽ thấy các yêu cầu của client chuyển trở lại địa chỉ IP riêng của trình cân bằng tải chính trong vòng vài giây:

Output
. . . primary_lb_private_IP primary_lb_private_IP primary_lb_private_IP primary_lb_private_IP primary_lb_private_IP secondary_lb_private_IP secondary_lb_private_IP secondary_lb_private_IP secondary_lb_private_IP primary_lb_private_IP primary_lb_private_IP primary_lb_private_IP

Server chính đã giành lại quyền kiểm soát địa chỉ IP nổi và đã tiếp tục công việc của nó với quyền là bộ cân bằng tải chính cho cơ sở hạ tầng.

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 để ghi lại địa chỉ IP của client root , 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 web server backend của bạn.

Trên cả hai web server , hãy mở file nginx.conf trong một editor :

  • sudo nano /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 gọi 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 web server , hãy mở cấu hình server default :

  • sudo nano /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 ở trên.

Trên cả hai web server , 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 web server 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.

IP và nổi keepalived cấu hình loại bỏ các điểm duy nhất của thất bại 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 cân bằng tải chính hoàn toàn thất bại. 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ăn xếp web bạn muốn đằng sau các server HAProxy.


Tags:

Các tin liên quan

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
Cách bảo vệ WordPress với Fail2Ban trên Ubuntu 14.04
2015-09-16
Cách cài đặt và sử dụng Composer trên Ubuntu 14.04
2015-09-11
Cách tối ưu hóa cài đặt Tomcat của bạn trên Ubuntu 14.04
2015-09-08