Hướng dẫn tạo Load Balancer trong Portal Cloud Gdata
Giới thiệu
Load Balancer trong Portal Cloud Gdata giúp phân phối lưu lượng truy cập đến nhiều Cloud Server nhằm tăng hiệu năng, tính sẵn sàng và khả năng chịu tải của hệ thống.
Hệ thống Load Balancer của Gdata hỗ trợ cân bằng tải cho Website, API, Application Server và nhiều dịch vụ khác.
Load Balancer trong Portal Cloud Gdata hỗ trợ:
• Load Balancer Internal
• Load Balancer External
• Health Check tự động
• Sticky Session
• Thuật toán cân bằng tải
• Listener HTTP/HTTPS
• Quản lý nhiều backend server
Điều kiện trước khi thực hiện
Trước khi tạo Load Balancer, người dùng cần chuẩn bị:
• Đã đăng nhập Portal Cloud Gdata
• Đã có Cloud Server hoạt động
• Các máy chủ nằm trong cùng Network
• Đã có Subnet và Router
• Security Group mở đúng port dịch vụ
• Các backend server hoạt động bình thường
Các mô hình sử dụng phổ biến
Load Balancer thường được sử dụng trong các trường hợp:
• Cân bằng tải Website
• Load balancing API Server
• Triển khai High Availability
• Hệ thống Web nhiều node
• Application Cluster
• Reverse Proxy cho dịch vụ nội bộ
• Scale horizontal nhiều máy chủ
Phân biệt Internal và External Load Balancer
Internal Load Balancer
Internal Load Balancer chỉ cho phép truy cập trong mạng LAN nội bộ.
Phù hợp cho:
• Backend API
• Database Proxy
• Microservices nội bộ
• Hệ thống private network
External Load Balancer
External Load Balancer cho phép truy cập từ Internet.
Phù hợp cho:
• Website public
• API public
• Application Internet-facing
• Dịch vụ truy cập bên ngoài
Hướng dẫn tạo Load Balancer trong Portal Cloud Gdata chi tiết
Bước 1: Truy cập chức năng Load Balancer
Tại menu Network, chọn mục Load Balancers.
Hệ thống sẽ hiển thị danh sách Load Balancer hiện có trong Project.
Thực hiện:
Mở menu:
Network → Load Balancers
Nếu chưa có Load Balancer, danh sách sẽ hiển thị trống.
Nhấn nút Thêm mới để tạo Load Balancer.
Kiểm tra:
• Tên Load Balancer
• Trạng thái
• Loại
• IP Address
• Region
Lưu ý:
• Mỗi Load Balancer sẽ được tạo riêng trong Project
• Load Balancer sử dụng tài nguyên mạng riêng
• Nên xác định rõ mô hình Internal hoặc External trước khi tạo
Bước 2: Khai báo thông tin Load Balancer
Tại màn hình tạo mới, cấu hình thông tin cơ bản cho Load Balancer.
Thực hiện:
Nhập các thông tin:
• Tên
• Mô tả
• Loại
• Chu kỳ thanh toán
Ví dụ:
• Tên: demo-lb
• Mô tả: Demo Load Balancer
• Loại: lb_basic
Portal Cloud Gdata hỗ trợ nhiều loại cấu hình Load Balancer:
• lb_basic
• lb-16c-16gb
• lb-32c-8gb
Ý nghĩa từng loại:
• lb_basic: Phù hợp Website nhỏ và hệ thống test
• lb-16c-16gb: Phù hợp hệ thống traffic trung bình
• lb-32c-8gb: Phù hợp hệ thống tải lớn hoặc nhiều kết nối đồng thời
Kiểm tra:
• Thông tin hiển thị đúng
• Chi phí được cập nhật theo loại Load Balancer
• Chu kỳ thanh toán chính xác
Lưu ý:
• Cấu hình càng cao thì chi phí càng lớn
• Nên chọn cấu hình phù hợp lưu lượng thực tế
• Có thể mở rộng hệ thống backend sau này
Bước 3: Chọn kiểu kết nối Load Balancer
Portal Cloud Gdata hỗ trợ 2 loại kết nối:
• External
• Internal
Thực hiện:
Chọn kiểu kết nối phù hợp.
Nếu chọn External:
• Load Balancer có thể truy cập từ Internet
• Chọn External Network
Ví dụ:
• Public-VLAN909
Nếu chọn Internal:
• Chỉ truy cập trong LAN nội bộ
• Chọn Internal Network và Subnet
Ví dụ:
• demo-network
• subnet-demo
Kiểm tra:
• Network đúng với hệ thống backend
• Subnet hiển thị chính xác
• Kiểu kết nối phù hợp nhu cầu sử dụng
Lưu ý:
• Internal LB không truy cập được từ Internet
• External LB cần Security Group phù hợp
• Backend server phải nằm cùng network
Bước 4: Cấu hình Listener
Listener là thành phần tiếp nhận kết nối từ client và chuyển tiếp đến Pool backend.
Portal Cloud Gdata hỗ trợ nhiều giao thức như:
• HTTP
• HTTPS
Thực hiện:
Bật mục Cấu hình nâng cao.
Tại phần Listener, cấu hình:
• Tên Listener
• Mô tả Listener
• Giao thức
• Cổng
• Cert SSL nếu dùng HTTPS
Ví dụ:
• Listener: web-http
• Protocol: HTTP
• Port: 80
Kiểm tra:
• Protocol đúng dịch vụ
• Port chính xác
• SSL Certificate đúng nếu dùng HTTPS
Lưu ý:
• HTTPS yêu cầu SSL Certificate
• Không nên mở port không cần thiết
• Listener nên trùng với service backend
Bước 5: Cấu hình Pool
Pool là nhóm backend server phía sau Load Balancer.
Thực hiện:
Tại phần Thông tin Pool, cấu hình:
• Tên Pool
• Mô tả
Ví dụ:
• Pool: Default
Sau đó thêm backend server vào danh sách Member.
Tại phần Danh sách Member:
• Nhập IP backend
• Nhập tên server
• Chọn port backend
• Cấu hình Weight
Ví dụ:
• IP: 10.10.10.11
• Port: 80
• Weight: 1
Có thể nhấn nút + Server để thêm nhiều backend server.
Ý nghĩa Weight:
Weight quyết định tỷ lệ traffic phân phối đến backend server.
Ví dụ:
• Server weight 2 sẽ nhận nhiều traffic hơn server weight 1
Kiểm tra:
• Backend IP đúng
• Port backend hoạt động
• Các server có thể ping được
Lưu ý:
• Backend server cần mở đúng port
• Không dùng IP public làm backend
• Weight nên cân đối theo cấu hình server
Bước 6: Chọn thuật toán cân bằng tải
Portal Cloud Gdata hỗ trợ các thuật toán:
• ROUND ROBIN
• SOURCE IP
• SOURCE IP PORT
• LEAST CONNECTIONS
Mỗi thuật toán sẽ có cách phân phối request khác nhau.
ROUND ROBIN
Thuật toán sẽ phân phối request lần lượt đến từng backend server theo vòng tròn.
Ví dụ:
Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Quay lại Server A
Phù hợp với:
• Website thông thường
• API server cơ bản
• Backend có cấu hình tương đương nhau
• Hệ thống tải đồng đều
Ưu điểm:
• Cấu hình đơn giản
• Phân phối traffic đồng đều
• Hoạt động ổn định
Lưu ý:
• Không tối ưu nếu backend server có cấu hình khác nhau
• Không giữ session người dùng
SOURCE IP
Thuật toán sẽ dựa trên địa chỉ IP client để xác định backend server.
Một IP client sẽ luôn được chuyển đến cùng một backend server.
Phù hợp với:
• Hệ thống cần session ổn định
• Website login session
• Ứng dụng cần cache local
• Hệ thống yêu cầu giữ trạng thái người dùng
Ưu điểm:
• Người dùng luôn truy cập cùng backend
• Giảm mất session
• Giảm đồng bộ cache giữa các node
Lưu ý:
• Có thể gây mất cân bằng tải nếu nhiều người dùng cùng NAT IP
• Một backend có thể nhận nhiều traffic hơn các backend khác
SOURCE IP PORT
Thuật toán sẽ sử dụng cả IP client và source port để phân phối traffic.
Khả năng phân phối tải sẽ đồng đều hơn SOURCE IP.
Phù hợp với:
• Hệ thống có nhiều kết nối đồng thời
• API Gateway
• Reverse Proxy
• TCP Load Balancing
Ưu điểm:
• Phân phối tải tốt hơn SOURCE IP
• Hạn chế tình trạng dồn traffic vào một node
• Vẫn giữ được tính ổn định kết nối
Lưu ý:
• Có thể thay đổi backend khi client reconnect
• Không phù hợp ứng dụng yêu cầu session cố định tuyệt đối
LEAST CONNECTIONS
Thuật toán sẽ gửi request đến backend server đang có ít kết nối nhất.
Server tải nhẹ hơn sẽ nhận thêm traffic.
Phù hợp với:
• Hệ thống traffic lớn
• Backend xử lý request không đồng đều
• Ứng dụng realtime
• Websocket hoặc long connection
Ưu điểm:
• Tối ưu tài nguyên backend
• Hạn chế quá tải trên một node
• Hoạt động tốt với hệ thống traffic biến động
Lưu ý:
• Backend cấu hình yếu vẫn có thể bị quá tải nếu xử lý chậm
• Cần Health Check hoạt động chính xác
Hướng dẫn lựa chọn thuật toán phù hợp
ROUND ROBIN
Khuyến nghị cho:
• Website cơ bản
• CMS
• Blog
• API nhỏ
SOURCE IP
Khuyến nghị cho:
• Website login session
• ERP
• CRM
• Session-based application
SOURCE IP PORT
Khuyến nghị cho:
• API Gateway
• TCP service
• Proxy server
• High concurrent connection
LEAST CONNECTIONS
Khuyến nghị cho:
• Traffic lớn
• Realtime service
• Streaming
• Websocket
• Hệ thống tải không đồng đều
Cấu hình Sticky Sessions
Sticky Session giúp giữ người dùng truy cập vào cùng backend server trong thời gian hoạt động.
Portal Cloud Gdata hỗ trợ bật hoặc tắt Sticky Session tùy nhu cầu.
Nên bật Sticky Session khi:
• Ứng dụng sử dụng session local
• Chưa triển khai Redis Session
• Hệ thống login stateful
Không nên bật khi:
• Backend stateless
• API microservices
• Hệ thống cần cân bằng tải tối đa
Khuyến nghị thực tế
• ROUND ROBIN phù hợp đa số hệ thống thông thường
• LEAST CONNECTIONS phù hợp traffic lớn
• SOURCE IP phù hợp hệ thống session-based
• Luôn bật Health Check để loại bỏ backend lỗi
• Theo dõi traffic thực tế để tối ưu thuật toán phù hợp hệ thống
Bước 7: Cấu hình Health Check
Health Check giúp kiểm tra trạng thái backend server tự động.
Nếu server lỗi hoặc không phản hồi, Load Balancer sẽ ngừng gửi traffic đến server đó.
Thực hiện:
Bật mục Health Check.
Cấu hình:
• Protocol
• Tên Health Check
• URL kiểm tra
Ví dụ:
• Protocol: HTTP
• URL: /
Kiểm tra:
• URL phản hồi HTTP 200
• Backend hoạt động bình thường
• Health Check không timeout
Lưu ý:
• URL Health Check nên nhẹ và phản hồi nhanh
• Không dùng URL tải nặng
• Health Check giúp tăng High Availability
Bước 8: Thanh toán và tạo Load Balancer
Sau khi hoàn tất cấu hình, hệ thống sẽ tạo đơn hàng Load Balancer.
Thực hiện:
Kiểm tra lại:
• Loại Load Balancer
• Chi phí
• VAT
• Tổng thanh toán
Sau đó nhấn nút Thanh toán.
Kiểm tra:
• Load Balancer xuất hiện trong danh sách
• Trạng thái ACTIVE
• IP Address được cấp phát
• Listener hoạt động
Kết quả:
Load Balancer được tạo thành công và sẵn sàng phục vụ traffic.
Kết quả sau khi thực hiện
Sau khi cấu hình thành công:
• Traffic được phân phối đến nhiều backend server
• Hệ thống tăng tính sẵn sàng
• Backend lỗi sẽ tự động bị loại khỏi hệ thống
• Có thể scale thêm backend server dễ dàng
• Hệ thống ổn định hơn khi traffic tăng cao
Các lỗi thường gặp
Lỗi: Backend server DOWN
Nguyên nhân:
• Server backend tắt
• Port backend không mở
• Security Group chặn traffic
Cách xử lý:
• Kiểm tra trạng thái server
• Mở đúng port backend
• Kiểm tra Security Group
Lỗi: Health Check thất bại
Nguyên nhân:
• URL Health Check sai
• Backend không phản hồi HTTP 200
• Firewall chặn request
Cách xử lý:
• Kiểm tra URL Health Check
• Kiểm tra service backend
• Kiểm tra firewall
Lỗi: Không truy cập được Load Balancer
Nguyên nhân:
• Listener sai port
• Security Group chưa mở
• Chọn sai loại Internal hoặc External
Cách xử lý:
• Kiểm tra Listener
• Kiểm tra Security Group
• Kiểm tra cấu hình network
Lỗi: Website truy cập chậm
Nguyên nhân:
• Backend quá tải
• Chọn cấu hình LB quá thấp
• Health Check cấu hình chưa hợp lý
Cách xử lý:
• Tăng cấu hình Load Balancer
• Scale thêm backend server
• Kiểm tra tài nguyên backend
Khuyến nghị và lưu ý bảo mật:
• Luôn bật Health Check
• Sử dụng HTTPS cho Website public
• Không public backend server trực tiếp ra Internet
• Chỉ mở các port cần thiết
• Theo dõi traffic và tài nguyên thường xuyên
• Sử dụng Sticky Session khi ứng dụng yêu cầu session state
• Scale backend server thay vì tăng tải trên một node
• Kết hợp Security Group để tăng cường bảo mật hệ thống