Giá trị của session gửi và lưu tại server sau đó gửi lại browser có tên PHPSESSID

17th Oct 2022
Giá trị của session gửi và lưu tại server sau đó
Table of contents

Load Balancer (Cân bằng tải) là một tính năng có vai trò giúp phân phối đồng đều tài nguyên cho các server trong hệ thống cũng như cho phép mở rộng hệ thống khi lượng người dùng hệ thống tăng lên.

Nếu đã làm với các khách hàng là công ty Nhật thì tương ứng với việc làm trên có một thuật ngữ khá phổ biến gọi là 冗長化 (Zô Chô Ka). Khách hàng Nhật đang trong quá trình tiếp cận migration và sử dụng Cloud rộng rãi nên yêu cầu này thường xuyên xuất hiện.

Riêng với môi trường AWS Cloud, có hai loại Load Balancer hay dùng là ELB (Elastic Load Blancer) và ALB (Application Load Balancer). Ở thời điểm hiện tại khi Cloud Computing đã phát triển rộng rãi, trong quá trình phát triển và vận hành hệ thống bạn sẽ thường gặp hai trường hợp sau:

Chuyển hệ thống hiện tại có 1 Server On Premis (Ví dụ: Server máy ảo đặt ở DataCener) lên Cloud với 2 Server, access thông qua Load Balancer.

Chuyển từ 1 Server với môi trường phát triển DEV/ Staging/ Product đặt trên Cloud, sang triển khai môi trường Staging hoặc Product với 2 Server, access thông qua Load Balancer.

Các vấn đề phát sinh và hướng giải quyết sẽ được trao đổi chi tiết ngay dưới đây.

Mất Session

Nếu hệ thống của bạn không sử dụng Session hoặc lưu Session ở một nơi thứ 3 như DB hay Cache trung gian thì sẽ chẳng có gì để bàn ở đây. Tuy nhiên nếu có xử lý Session và lưu ở chính Server thì khi chuyển lên ALB hay ELB cần phải chú ý đến vấn đề mất Session đầu tiên. Lý do là vì Load Balancer sẽ điều hướng access đến các server dựa trên lưu lượng truy cập nên có thể có trường hợp đang làm việc với Session ở Server A nhưng lại điều hướng sang Server B, như vậy sẽ phát sinh việc mất Session và hiện tượng phổ biến là hệ thống sẽ Logout về màn hình Login.

Rất may AWS đã tính toán đến phần này giúp chúng ta. Ở ELB hay ALB của AWS có cơ chế Sticky Session.

Cơ chế Sticky Session thực hiện thiết lập một tracking ID cho mỗi truy cập của User cụ thể. , đảm bảo cho việc truy cập của User được liên tục, ví dụ như không bị tự động logout khỏi hệ thống.

Lỗi “ERR_TOO_MANY_REDIRECTS”

Đây là lỗi bạn sẽ thấy nếu hệ thống truy cập qua HTTPS hoặc hỗn hợp có trang HTTP/HTTPS khi dùng Load Balancer.

Lý do nằm ngay trong hình trên.

Để giải quyết vấn đề này, Load Balancer của AWS có add thêm vào Header của Request từ Load Balancer đến Server một request header có tên là X-Forwarded-Proto. Request header này giúp Server phân biệt được Request từ phía người dùng là HTTP hay HTTPS. Dựa trên Header này phía Server có thể xử lý để Redirect trong Source Code. Tuy nhiên, có một cách cách đơn giản hơn là thực hiện setting Rewrite URL trên Web Server.

Để tham khảo, với Web Server trên EC2 instance của AWS, cách setting như sau:

Bước 1: Vào file config /etc/httpd/conf.d/virtual.conf

sudo vi /etc/httpd/conf.d/virtual.conf

Bước 2: Add nội dung sau vào file:

<VirtualHost *:80>

ServerName Your_System_Domain_Name

RewriteEngine On

RewriteCond %{HTTPS} !=on

RewriteCond %{HTTP:X-Forwarded-Proto} !=https

RewriteRule .* https://%{HTTP:Host}%{REQUEST_URI} [L,NE,R=permanent]

</VirtualHost>

Bước 3: Save file và khởi động lại Web Server:

sudo systemctl stop httpd.service

sudo systemctl start httpd.service

Đồng bộ khi Upload File lên Server

Thông thường khi upload file lên Server, thì file được lưu trên Server đó, Server còn lại thì lại không tồn tại file đó, nên cần có việc đồng bộ file giữa hai Server với nhau. Thông thường khi dùng nhiều server cùng lúc, khi upload file hay xảy ra trường file chỉ xuất hiện ở 1 server, các server còn lại thì không có. Điều này xảy ra do chương có bước đồng bộ file giữa các Server với nhau.

Để giải quyết vấn đề này có hai cách:

Cách 1: Lưu file Upload vào một nơi khác. Phổ biến là dùng AWS S3 hoặc AWS EFS, hoặc nếu ít file và dung lượng bé thì có thể lưu trực tiếp vào DB. Sau đó thực hiện copy file đồng bộ giữa các Server mỗi khi thực hiện Upload.

Cách 2: Nếu bạn không thích tốn công mỗi lần upload file thì hãy dùng cách thứ 2.

Bước 1: Tạo một file Shell Script để thực hiện Copy file.

#!/bin/bash

##Copy file form local server to other server in the same Loadbalancer

##    $1: Server 1 IP

##    $2: Server 2 IP

##    $3: Server 2 Folder path

##    $4: Server 1 file path

LOCAL_IP=$(ifconfig | grep -Eo ‘inet (addr:)?([0-9]*\.){3}[0-9]*’ | grep -Eo ‘([0-9]*\.){3}[0-9]*’ | grep -v ‘127.0.0.1’)
if [ “$1” == “$LOCAL_IP” ]; then

if ssh server_login_user@$2 -p 10022 “test -e $4” ; then

scp -P 10022 $4 server_login_user@$2:$3

else

scp -P 10022 $4 server_login_user@$2:$3

ssh server_login_user@$2 -p 10022 “chmod 0777 $4”

fi

elif [ “$2” == “$LOCAL_IP” ]; then

if ssh server_login_user@$1 -p 10022 “test -e $4” ; then

scp -P 10022 $4 server_login_user@$1:$3

else

scp -P 10022 $4 server_login_user@$1:$3

ssh server_login_user@$1 -p 10022 “chmod 0777 $4”

fi

fi

Ở file Script trên sẽ dùng lệnh scp (copy thông qua SSH) để copy file giữa 2 server. Một vài lưu ý khi tạo Script:

Địa chỉ của các Server sẽ là dùng Private IP

Mở cổng SSH trên AWS cho 2 Server thông được với nhau. Đồng thời setting để thực hiện SSH giữa 2 Server mà không cần dung file PEM để authenticate.
“server_login_user” là user login vào thao tác được với Server.

Bước 2: Đặt file Script trên ở một thư mục giống nhau trên cả hai Server, Setting quyền có thể thực hiện cho file Shell Script này.

sudo chmod +x /home/path_to_file/scp_file_to_other_server.sh

Bước 3: Setting quyền để cho user apache của Server có thể thực hiện được Shell script.

Edit file setting quyền cho user:

sudo visudo

Thêm nội dung sau vào file:
Defaults!/home/path_to_file/scp_file_to_other_server.sh !requiretty

apache         ALL=(ALL)       NOPASSWD: /home/path_to_file/scp_file_to_other_server.sh *

Bước 4: Trong source code của Server, sau khi thực hiện upload file thì chạy file Shell Script để copy file đến Server còn lại. Source PHP có thể tham khảo như sau:

/**

* Secure copy file from [server 1] to [server 2]

*

* @param string $folderSave

* @param string $fileName

* @return type

*/

private function scpFileToOtherServer($privateIpSer1, $privateIpSer2, $folderSave, $fileName) {

$shellScript = Configure::read(‘path_of_script_copy_file’);

$pemFile = Configure::read(‘path_of_pem_file’);

$filePath = $folderSave . $fileName;


// remove char [/]

$folderSave = (mb_substr($folderSave, -1) == DS) ?

mb_substr($folderSave, 0, mb_strlen($folderSave) – 1) : $folderSave;

$command = “sudo -u server_login_user -S {$shellScript} {$privateIpSer1} {$privateIpSer2} {$folderSave} {$filePath} 2>&1”;

$output = shell_exec($command);

if (!empty($output)) {

$this->log(__FILE__ . ‘(‘ . __LINE__ . ‘): Copy fail, command: ‘ . $command);

$this->log($output);

}

return $output;

}

Khi đưa Server độc lập lên Load Balancer, có thể sẽ gặp một vài khó khăn khác. 

Setting Session timeout cho Load Balancer: Dựa trên Session Timeout của hệ thống của bạn để setting phù hợp cho Load Balancer. Session Timeout của Load Balancer phải lớn hơn hoặc bằng giá trị time out của hệ thống.

Session
Giá trị của session sẽ được lưu trong một file trên server. Sau đó gửi xuống Browser. Lưu vào Cookie đã mã rồi

Setting Timeout cho Load Balancer. Default timeout của Load Balancer (AWS) thường là 60 giây. Nếu hệ thống Performance không tốt, mất nhiều thời gian trả lời Request thì sẽ dễ phát sinh lỗi [504 Gateway Time-out]. Do đó cần tăng thời gian Timeout của Load Balancer lên để tránh lỗi này (Ví dụ sửa thành 180 giây).

Hệ thống của có sử dụng một số API của bên thứ ba và có trả phí, đồng thời bị giới hạn truy cập theo IP Global của Server. Do đó nếu đưa thêm Server vào thì sẽ phải cần đăng ký địa chỉ IP Global của Server được thêm để có thể sử dụng được các API đó. Cần xử lý việc này trước khi bạn chính thức chạy hệ thống với kiến trúc mới.

Các thuật toán Load Balancing là gì?

Tùy thuộc công nghệ Load Balancing mà các thuật toán khác nhau sẽ được sử dụng để định tình trạng của máy chủ có hoạt động hay không. Có các loại thuật toán thường thấy là:

  1. Round Robin
  2. Weighted Round Robin
  3. Dynamic Round Robin
  4. Fastest
  5. Least Connections

Thuật toán Load Balancing – Round Robin là gì?

Round Robin là thuật toán lựa chọn các máy chủ theo trình tự. Theo đó, Load Balancer sẽ bắt đầu đi từ máy chủ số 1 trong danh sách của nó ứng với yêu cầu đầu tiên. Tiếp đó, nó sẽ di chuyển dần xuống trong danh sách theo thứ tự và bắt đầu lại ở đầu trang khi đến máy chủ cuối cùng.

Nhược điểm thuật toán Load Balancing – Round Robin là gì?

Khi có 2 yêu cầu liên tục từ phía người dùng sẽ có thể được gửi vào 2 server khác nhau. Điều này làm tốn thời gian tạo thêm kết nối với server thứ 2 trong khi đó server thứ nhất cũng có thể trả lời được thông tin mà người dùng đang cần. Để giải quyết điều này, round robin thường được cài đặt cùng với các phương pháp duy trì session như sử dụng cookie.

Thuật toán Load Balancing – Weighted Round Robin là gì?

Tương tự như kỹ thuật Round Robin nhưng WRR còn có khả năng xử lý theo cấu hình của từng server đích. Mỗi máy chủ được đánh giá bằng một số nguyên (giá trị trọng số Weight – mặc định giá trị là 1). Một server có khả năng xử lý gấp đôi server khác sẽ được đánh số lớn hơn và nhận được số request gấp đôi từ bộ cân bằng tải.

Nhược điểm thuật toán Load Balancing – Weighted Round Robin là gì?

Weighted Round Robin gây mất cân bằng tải động nếu như tải của các request liên tục thay đổi trong một khoảng thời gian rộng.

Thuật toán Load Balancing – Dynamic Round Robin (DRR) là gì?

Thuật toán DRR hoạt động gần giống với thuật toán WRR. Điểm khác biệt là trọng số ở đây dựa trên sự kiểm tra server một cách liên tục. Do đó trọng số liên tục thay đổi.

Việc chọn server sẽ dựa trên rất nhiều khía cạnh trong việc phân tích hiệu năng của server trên thời gia thực. Ví dụ: số kết nối hiện đang có trên các server hoặc server trả lời nhanh nhất, …

Thuật toán này thường không được cài đặt trong các bộ cân bằng tài đơn giản. Nó thường được sử dụng trong các sản phẩm cân bằng tải của F5 Network.

Thuật toán Load Balancing – Fastest là gì?

Đây là thuật toán dựa trên tính toán thời gian đáp ứng của mỗi server (response time). Thuật toán này sẽ chọn server nào có thời gian đáp ứng nhanh nhất. Thời gian đáp ứng được xác định bởi khoảng thời gian giữa thời điểm gửi một gói tin đến server và thời điểm nhận được gói tin trả lời.

Việc gửi và nhận này sẽ được bộ cân bằng tải đảm nhiệm. Dựa trên thời gian đáp ứng, bộ cân bằng tải sẽ biết chuyển yêu cầu tiếp theo đến server nào.

Thuật toán Fastest thường được dùng khi các server ở các vị trí địa lý khác nhau. Như vậy người dùng ở gần server nào thì thời gian đáp ứng của server đó sẽ nhanh nhất. Cuối cùng server đó sẽ được chọn để phục vụ.

Thuật toán Load Balancing – Least Connections là gì?

Các request sẽ được chuyển vào server có ít kết nối nhất trong hệ thống. Thuật toán này được coi như thuật toán động, vì nó phải đếm số kết nối đang hoạt động của server.

Least Connections có khả năng hoạt động tốt. Ngay cả khi tải của các kết nối biến thiên trong một khoảng lớn. Do đó nếu sử dụng RC sẽ khắc phục được nhược điểm của Round Robin.

Bạn thấy bài viết này như thế nào?
0 reactions

Add new comment

Image CAPTCHA
Enter the characters shown in the image.

Related Articles

301 Redirect (Moved permanently) là một mã trạng thái HTTP ( response code HTTP) để thông báo rằng các trang web hoặc URL

Redirect 302 (MovedTemporarily) hay còn gọi là redirection 302, chuyển hướng tạm thời, gần giống với Redirection 301, di chuyển vĩnh viễn.

Ở các quốc gia trên Thế Giới hiện tại, để xây dựng một website áp dụng kiến trúc JAMstack Doanh Nghiêp phải bỏ ra ít nhất ~3.000$ hoặc hơn.