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. 
 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:
Output10.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ó:
Output10.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 .
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 :
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:
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:
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à 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 :
Outputcurl: (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”:
# 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 :
. . .  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):
. . .  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”:
. . .  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:
Outputcurl: (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 ):
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:
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 :
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 :
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 :
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:
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:
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:
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”:
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”:
Trên trang API, mã thông báo mới của bạn sẽ được hiển thị:
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:
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:
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 :
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:
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 :
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:
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 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:
 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:
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:
        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.
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.042015-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
 

