Posts Tagged ‘LoadBalancing’

Replication trong MongoDB 3

Posted: Tháng Năm 8, 2018 in Database, MongoDB
Thẻ:, , ,

Trong bài trước nói về begin MongoDB và triển khai MongoDB với 01 member. Do đó có thể tham khảo cài đặt và sử dụng các thao tác cơ bản trên MongoDB 3 tại:  Cài đặt và các thao tác cơ bản MongoDB 3

Trong bài này, mô hình triển khai replica set MongoDB sử dụng 02 member, và tận dụng 01 server trong hệ thống làm Arbiter cho việc vote

Replication MongoDB 3

Về lý thuyết mình thấy 2 nguồn này rõ ràng và dễ hiểu:

https://docs.mongodb.com/manual/replication/

https://kipalog.com/posts/Replica-set-trong-MongoDB

 

Trong phạm vi bài viết sẽ triển khai replication MongoDB 3 trên các member là CentOS 7

I. Cài đặt MongoDB 3 trên 03 servers

Step1:  Tạo mongodb3 repository

#vim /etc/yum.repos.d/mongo.repo

[mongodb-org-3.4]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.4/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.4.asc

Step2: Cài đặt MongoDB và các gói công cụ

yum install -y mongodb-org
systemctl start mongodb
systemctl enable mongodb

Step3: Cho phép truy cập mongodb từ một số IPAddress
Soạn tệp cấu hình /etc/mongod.conf trên các server

sed -i 's/127.0.0.1/0.0.0.0/' /etc/mongod.conf

Cho phép truy cập mongodb từ local network

firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.10.0/24" port port="27017" protocol="tcp" accept'
firewall-cmd --reload

2. Replication MongoDB

Trong điều kiện replication MongoDB với 2 server, khi primary unvailable, thì secondary cũng sẽ không tự động thành primary được, vì nó chỉ có 01 vote.
Thực tế trong môi trường product thì luôn cần ghi vào database, và tất nhiên chỉ có Primary là có thể write, secondary thì chỉ có thể read. Do đó chúng ta sẽ tận dụng một máy nào đó trong hệ thống để làm Arbiter (trọng tài) vào replica set, để vote cho secondary thành primary.
– Arbiter chỉ có chức năng vote, không giữ data của hệ thống replica set, cũng như không thể trở thành primary.
– Arbiter yêu cầu cấu hình tối thiểu để cài đặt mongodb, do đó chúng ta có thể tận dụng một server nào nó trong hệ thống như: monitor, application

Với replica set MongoDB, member nào có priority cao hơn sẽ là primary. Do đó khi cấu hình chúng ta sẽ để server01 có priority cao hơn để làm default primary.

2.1 Replica set mà không access control

Step1: Enable replication on MongoDB

Trên 03 server mà cài đặt MongoDB, thêm nội dung sau vào tệp tin cấu hình mongod.conf để enable replication với tên replica set id là: mongo_rep

cat >>/etc/mongod.conf <<EOF
replication:
    #replica set id
    replSetName: mongo_rep
EOF

#Restart mongod
systemctl restart mongod

Step2: Thiết lập hosts.conf trên 03 servers

cat >>/etc/hosts <<EOF
192.168.10.111    mongo01
192.168.10.112    mongo02
192.168.10.113    mongo03
EOF

Step3: Khởi tạo MongoDB replica set trên primary

Cấu hình replica set trên primary (mongo01)

[root@mongo01]# mongo
MongoDB shell version v3.4.13
connecting to: mongodb://127.0.0.1:27017
>rs.initiate( { _id: "mongo_rep", members: [ { _id: 0, host: "mongo01:27017", priority: 2 } ] } )
>rs.add( { _id:2,host:"mongo02:27017",priority:1 } )
>rs.addArb( { _id:3,host:"mongo03:27017",priority:0 })

Note: Để sửa thông tin cấu hình replica set thực hiện như sau:

 >cfg = rs.conf()
 >cfg.members = [cfg.members[1]]
 >rs.reconfig(cfg, {force : true})
 >rs.reconfig({_id:"mongo_rep",members:[{_id:1,host:"mongo01:27017",priority:3},{_id:2,host:"mongo02:27017",priority:2}]})

2.2 Replication set MongoDB with access control

MongoDB cho phép chứng thực giữa các members của replica set with 2 phương thức:
– KeyFile ( https://docs.mongodb.com/manual/core/security-internal-authentication/#keyfiles )
– x.509 (https://docs.mongodb.com/manual/core/security-internal-authentication/#x-509)

Chúng ta thực hiện chứng thực với keyFile
Nội dung của keyFile giống như chia sẻ mật khẩu chung giữa các member servers

Step1: Trên primary MongoDB server
Tạo keyFile

mkdir -p /mongodb/data #Thư mục chứ keyFile
echo "sharedpassword" >/mongodb/data/keyfile
chown -R mongod:mongod /mongodb
chmod 400 /mongodb/data/keyfile

Step2: Enable chứng thực trên all member replica set
Để enable chứng thực chúng ta thêm đoạn sau vào tệp cấu hình mongodb

cat >>/etc/mongod.conf <<EOF
security:
    authorization: enabled #Enable chứng thực password
    keyFile: /mongodb/data/keyfile #keyFile path
EOF

Step3: Tạo tài khoản chứng thực
Cách tạo tài khoản trong bài giới thiệu cũng có nói qua, hoặc tham khảo https://docs.mongodb.com/manual/tutorial/create-users/
#Ví dụ tạo tài khoản có quyền root (mức cao nhất)

mongo
>use admin
>db.createUser(
  {
    user: "keepwalking",
    pwd: "P@ssw0rd",
    roles: [
    "root"
    ]
  }
)

Step4: Copy keyfile đến các MongoDB server khác

Ở đây chúng ta sẽ copy keyFile sang secondary và Arbiter member, sử dụng rsync để không phải tạo lại đường dẫn và quyền cho keyFile.

rsync -avzhP /mongodb root@192.168.10.112:/
rsync -avzhP /mongodb root@192.168.10.113:/

Step5: Copy mongod.conf đến các MongoDB server khác

Để đồng bộ thông tin cấu hình MongoDB thì chúng ta cũng sử dụng rsync để copy mongod.conf đến các member của replica set

rsync -avzhP /etc/mongod.conf root@192.168.10.112:/etc/
rsync -avzhP /etc/mongod.conf root@192.168.10.113:/etc/

Step6: Restart mongod từ các replica set servers

systemctl restart mongod

Step7: Kiểm tra Replication MongoDB

[root@mongo01 ~]# mongo -u keepwalking -p P@ssw0rd admin
 mongo_rep:PRIMARY>

[root@mongo02 ~]# mongo -u keepwalking -p P@ssw0rd admin
 mongo_rep:SECONDARY>

#Do Arbiter chỉ chứa thông cấu hình nhân bản nên chỉ có db local

[root@server03 ~]# mongo
 mongo_rep:ARBITER>

Bài tiếp theo chúng ta sẽ ứng dụng Replication MongoDB cho PHP Laravel framework, với các “Read Preference” khác nhau, để thấy Replication MongoDB có thể vừa đảm nhận nhiệm vụ Hight Available và Load Sharing.

 

Chúng ta vẫn thường sử dụng tiện ích rsync cho đồng bộ cây thư mục trong cùng máy hoặc giữa 2 máy.

Rsync nhẹ, cho tốc độ đồng bộ nhanh, nhưng nó chưa tích hợp tính năng đồng bộ Live, tức là mọi thay đổi chưa được đồng bộ ngay tức thì như một số ứng dụng lưu trữ đám mây phổ biển hiện nay như: Dropbox, Owncloud, …). Rsync cũng chưa cấu hình được để đồng bộ 2 chiều trong trường hợp cần Load Balancing. Một điểm nữa là để đồng bộ tự động thì cần đặt lịch cho Rsync. Trên Linux, cronjob chỉ đặt lịch đồng bộ tối thiểu 1 phút (có thể hack để đặt lịch ở mức thấp hơn :D)

Để giải quyết cho bài toán đồng bộ Live và 2 chiều cho Load Balancing, chúng ta có thể sử dụng đến Lsyncd.

Lsyncd là một daemon, sử dụng tiện ích rsync, kết hợp với SSH để giải quyết những hạn chế nêu trên của rsync. Lsyncd nhẹ, cài đặt và cấu hình đơn giản.

Trong phạm vi bài viết tôi sẽ sử dụng Lsyncd để đồng bộ dữ liệu giữa 2 CentOS 7 servers

sync data with lsyncd

Yêu cầu: Cài đặt SSH Keys 2 chiều cho Server01 và Server02, tham khảo bài viết:  https://vnsys.wordpress.com/2016/12/10/ssh-keys-2-chieu-tren-servers/

1. Install lsyncd and required packages

Cài đặt lsyncd trên cả 2 servers

rpm -ivh http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install lsyncd rsync

2. Config lsync on both servers

2.1 Cấu hình Lsyncd trên server01

Sửa đổi nội dung tệp tin cấu hình “/etc/lsyncd.conf” với nội dung sau:

 ----
 -- User configuration file for lsyncd.
 --
 -- Simple example for default rsync, but executing moves through on the target.
 --
 -- For more examples, see /usr/share/doc/lsyncd*/examples/
 --
 -- sync{default.rsyncssh, source="/var/www/html", host="localhost", targetdir="/tmp/htmlcopy/"}

settings {
 logfile = "/var/log/lsyncd.log", -- Sets the log file
 statusFile = "/var/log/lsyncd-status.log" -- Sets the status log file
 }
 sync{
 default.rsyncssh, -- uses the rsyncssh defaults Take a look here: https://github.com/axkibe/lsyncd/blob/master/default-rsyncssh.lua
 delete = true, -- Doesn't delete files on the remote host eventho they're deleted at the source. This might be beneficial for some not for others
 source="/var/www/example/", -- Your source directory to watch
 host="192.168.1.51", -- The remote host (use hostname or IP)
 exclude={"/storage"}, -- To exclude file & folder (not sync)
 targetdir="/var/www/example/", -- the target dir on remote host, keep in mind this is absolute path
 rsync = {
 archive = true, -- use the archive flag in rsync
 perms = true, -- Keep the permissions
 owner = true, -- Keep the owner
 _extra = {"-a"}, -- Sometimes permissions and owners isn't copied correctly so the _extra can be used for any flag in rsync
 },
 delay = 5, -- We want to delay the syncing for 5 seconds so we queue up the events
 maxProcesses = 1, -- We only want to use a maximum of 4 rsync processes at same time
 ssh = {
 port = 1122 -- This section allows configuration for ssh specific stuff such as a different port
 }
 }

2.2 Cấu hình Lsyncd trên server02

Sửa đổi nội dung tệp tin cấu hình “/etc/lsyncd.conf” với nội dung sau:

----
 -- User configuration file for lsyncd.
 --
 -- Simple example for default rsync, but executing moves through on the target.
 --
 -- For more examples, see /usr/share/doc/lsyncd*/examples/
 --
 -- sync{default.rsyncssh, source="/var/www/html", host="localhost", targetdir="/tmp/htmlcopy/"}

settings {
 logfile = "/var/log/lsyncd.log", -- Sets the log file
 statusFile = "/var/log/lsyncd-status.log" -- Sets the status log file
 }
 sync{
 default.rsyncssh, -- uses the rsyncssh defaults Take a look here: https://github.com/axkibe/lsyncd/blob/master/default-rsyncssh.lua
 delete = true, -- Doesn't delete files on the remote host eventho they're deleted at the source. This might be beneficial for some not for others
 source="/var/www/example/", -- Your source directory to watch
 host="192.168.1.50", -- The remote host (use hostname or IP)
 exclude={"/storage"},
 targetdir="/var/www/example/", -- the target dir on remote host, keep in mind this is absolute path
 rsync = {
 archive = true, -- use the archive flag in rsync
 perms = true, -- Keep the permissions
 owner = true, -- Keep the owner
 _extra = {"-a"}, -- Sometimes permissions and owners isn't copied correctly so the _extra can be used for any flag in rsync
 },
 delay = 5, -- We want to delay the syncing for 5 seconds so we queue up the events
 maxProcesses = 1, -- We only want to use a maximum of 4 rsync processes at same time
 ssh = {
 port = 1122 -- This section allows configuration for ssh specific stuff such as a different port
 }
 }

3. Restart and check log lsyncd on both servers

Start lsyncd trên 2 servers và tạo hoặc xóa tệp tin, thư mục trong đường dẫn đồng bộ /var/www/example để kiểm tra

systemctl start lsyncd
tail -f /var/log/lsyncd.log

lsyncd for syncing data

Load balancing across multiple application instances is a commonly used technique for optimizing resource utilization, maximizing throughput, reducing latency, and ensuring fault-tolerant configurations.
Nginx is a very efficient HTTP load balancer to distribute traffic to several application servers and to improve performance, scalability and reliability of web applications.
Nginx Load balancing methods
The following load balancing mechanisms (or methods) are supported in nginx:
  • round-robin
  • least-connected
  • ip-hash
nginx load balancing

nginx load balancing

srv-lb01 (10.11.218.250) (Nginx load balancer)
srv-web01 (10.11.218.251) ( Web server)
srv-web02 (10.11.218.252) ( Web server)
srv-web03 (10.11.218.253) ( Web server)

Note: pointing nginx.vn to 10.11.218.250 (Replace nginx.vn with your real site name)


1.
Default load balancing configuration (round-robin)

When load balancing method is not specifically configured, it defaults to round-robin. All requests are proxied to the server group, and nginx applies HTTP load balancing to distribute the requests.

Install Nginx on srv-lb01, see at http://vietsystem.blogspot.com

Create a new configuration file called /etc/nginx/sites-available/nginx.vn with the following contents:

vim /etc/nginx/sites-available/nginx.vn

# Defines a group of servers and Load balancing methods

upstream nginx.vn {          
          server 10.11.218.251; 
          server 10.11.218.252;
          server 10.11.218.253;
}
server {
          listen 80;
          error_log /var/log/nginx/nginx.vn-error.log;
          location / {
               proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
               proxy_pass http://nginx.vn;
          }
}

Enable the site and restart Nginx

# cd /etc/nginx/sites-enabled
# ln -s ../sites-available/nginx.vn .
#systemctl restart nginx.service

Open web browser and go to http://nginx.vn

2. Least connected load balancing

Least-connected load balancing is activated when the least_conn directive is used as part of the server group configuration:
# Defines a group of servers and Load balancing methods
upstream nginx.vn {
           least_conn;
           server 10.11.218.251;
           server 10.11.218.252;
           server 10.11.218.253;
}

3. ip hash load balancing

 To configure ip-hash load balancing, just add the ip_hash directive to the server (upstream) group configuration
# Defines a group of servers and Load balancing methods
upstream nginx.vn {
          ip_hash;
          server 10.11.218.251;
          server 10.11.218.252;
          server 10.11.218.253;
}
4. Weighted load balancing
When the weight parameter is specified for a server, the weight is accounted as part of the load balancing decision.
# Defines a group of servers and Load balancing methods
upstream nginx.vn {
          server 10.11.218.251 weight=2;
          server 10.11.218.252;
          server 10.11.218.253;
}
With this configuration, every 4 new requests will be distributed across the application instances as the following: 3 requests will be directed to srv-web01, one request will go to srv-web02, and another one to srv-web03.