中文 (中国)
English
Trong nhiều trường hợp, bạn có thể cần phải di chuyển dữ liệu và các yêu cầu vận hành từ một máy chủ này sang máy chủ khác. Lý do có thể là triển khai giải pháp mới tại một trung tâm dữ liệu khác, nâng cấp phần cứng lên một máy chủ mạnh hơn, hoặc chuyển sang nhà cung cấp VPS khác.
Tùy vào mục đích di chuyển, có rất nhiều yếu tố cần xem xét khi chuyển đổi giữa các hệ thống. Đảm bảo cấu hình và chức năng tương đương có thể trở nên khó khăn nếu không sử dụng các công cụ quản lý cấu hình như Chef, Puppet hoặc Ansible. Không chỉ cần chuyển dữ liệu, bạn còn phải cấu hình lại các dịch vụ sao cho hoạt động chính xác như trên máy chủ cũ.
Việc di chuyển máy chủ Linux đòi hỏi sự chính xác và chuyên môn. Nếu bạn đang tìm kiếm giải pháp tối ưu, mua VPS chất lượng cao tại DataOnline sẽ giúp bạn vận hành máy chủ ổn định, hiệu suất vượt trội. Khám phá ngay các gói VPS phù hợp để đảm bảo dự án của bạn thành công!
Trong bài viết trước của loạt bài này, bạn đã được hướng dẫn cách sử dụng rsync để di chuyển các gói cài đặt và dữ liệu. Trong bài hướng dẫn này, bạn sẽ tiếp tục quá trình chuyển đổi bằng cách di chuyển người dùng, nhóm, crontab và các thiết lập khác để hoàn tất quá trình chuyển đổi hệ thống.
Bước 1 – Di chuyển người dùng và nhóm
Trình quản lý gói của Linux rất mạnh mẽ và tái tạo được, và khi bạn đã chuyển các gói hệ thống trong hướng dẫn trước, hầu hết các thiết lập cấu hình cần thiết đã được chuyển qua. Tuy nhiên, điều này không bao gồm một số thiết lập mà bạn có thể đã chỉnh sửa thủ công trên máy chủ cũ, chẳng hạn như quyền của người dùng và nhóm. Những thiết lập này cũng cần được di chuyển hoặc tái tạo lại.
May mắn thay, tất cả các thiết lập người dùng và nhóm của Linux đều được chứa trong một vài tập tin, bao gồm:
-
/etc/passwd: Tập tin này định nghĩa người dùng và các thuộc tính của họ. Dù tên gọi như vậy, tập tin này không chứa thông tin mật khẩu. Nó bao gồm tên đăng nhập, số nhận dạng người dùng và nhóm chính, thư mục home và shell mặc định.
-
/etc/shadow: Tập tin này chứa thiết lập mật khẩu thực sự cho mỗi người dùng. Nó cần có một dòng cho mỗi người dùng được định nghĩa trong tập tin
passwd, kèm theo mã băm mật khẩu và một số thông tin về chính sách mật khẩu. -
/etc/group: Tập tin này định nghĩa từng nhóm có sẵn trên hệ thống của bạn. Nó bao gồm tên nhóm, số nhóm tương ứng cùng với các thành viên của nhóm.
-
/etc/gshadow: Tập tin này chứa một dòng cho mỗi nhóm trên hệ thống. Nó liệt kê tên nhóm, mật khẩu (để những người không phải thành viên có thể truy cập nhóm, nếu cần), danh sách quản trị viên và các thành viên khác.
Bạn không nên sao chép trực tiếp các tập tin này từ một hệ thống đang chạy sang hệ thống khác. Số nhận dạng người dùng và nhóm được tự động tăng khi được tạo trên mỗi hệ thống, và sẽ gây ra xung đột nếu không khớp. Thay vào đó, bạn có thể di chuyển chúng một cách có chọn lọc bằng cách sử dụng awk, như đã trình bày trong hướng dẫn trước.
Tạo các tập tin di chuyển
Bạn sẽ tạo một tập tin di chuyển mới cho mỗi tập tin nói trên. Việc này cho phép bạn di chuyển chúng một cách có hệ thống, bắt đầu với tập tin /etc/passwd.
Đầu tiên, bạn cần xác định xem các ID người dùng thông thường có bắt đầu từ 500 hay 1000 trên hệ thống nguồn của bạn. Hầu hết các môi trường Linux hiện đại bắt đầu đếm từ 1000 để dành chỗ cho người dùng hệ thống, nhưng nếu bạn đang di chuyển từ hệ thống rất cũ, có thể chúng bắt đầu từ 500. Để kiểm tra, bạn có thể in ra các dòng cuối của tập tin /etc/passwd để xem số tài khoản người dùng của bạn là bao nhiêu:
less /etc/passwd
Output … vault:x:997:997::/home/vault:/bin/bash stunnel4:x:112:119::/var/run/stunnel4:/usr/sbin/nologin sammy:x:1001:1002::/home/sammy:/bin/sh
Trong trường hợp này, nó sẽ là 1000, vì các ID người dùng thông thường (cột thứ ba của output) đều từ 1000 trở lên. Chúng ta sẽ không xuất các người dùng hoặc nhóm có ID nhỏ hơn giới hạn này. Bạn cũng sẽ loại trừ tài khoản nobody được gán ID 65534.
Sử dụng awk, bạn có thể tạo một tệp đồng bộ cho tệp /etc/passwd của mình. Các lệnh awk trong hướng dẫn này sẽ được cung cấp nguyên vẹn do cú pháp phức tạp của nó, nhưng hãy nhớ rằng bạn có thể tìm hiểu thêm về cách sử dụng awk trong một hướng dẫn khác.
awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > ~/passwd.sync
Tiếp theo, bạn có thể sử dụng cú pháp tương tự và cùng giới hạn ID người dùng để xuất tập tin /etc/group:
awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > ~/group.sync
Để phân tích tập tin /etc/shadow, bạn có thể sử dụng dữ liệu từ tập tin /etc/passwd làm đầu vào:
awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > ~/shadow.sync
Cùng cách tiếp cận cũng được áp dụng cho /etc/gshadow:
awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > ~/gshadow.sync
Sau khi bạn đã kiểm tra các lệnh trên và xác nhận rằng chúng tạo ra các tập tin xuất từ dữ liệu thực, bạn có thể thêm chúng vào tập tin sync.sh mà bạn đã duy trì từ hướng dẫn trước. Bạn có thể chạy từng lệnh này từ xa — tức là, như một phần của script chạy trên máy đích, bằng cách lấy đầu ra từ máy nguồn — bằng cách thêm tiền tố ssh source_server, và đặt lệnh awk trong dấu ngoặc kép.
`~/sync.sh
ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > ~/passwd.sync"
ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > ~/group.sync"
ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > ~/shadow.sync"
ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > ~/gshadow.sync"
rsync source_server:~/passwd.sync ~/
rsync source_server:~/group.sync ~/
rsync source_server:~/shadow.sync ~/
rsync source_server:~/gshadow.sync ~/
Sau khi xuất dữ liệu này về máy đích, bạn có thể tự động thêm người dùng và nhóm vào máy đích. Không giống như các lệnh khác, lệnh này sẽ tạo ra bản sao nếu được chạy lại trong cùng một môi trường, vì vậy bạn nên thực hiện thủ công thay vì thêm nó vào script di chuyển của bạn.
Có một lệnh gọi là newusers có thể thêm nhiều người dùng từ một tập tin đầu vào. Tuy nhiên, trước tiên bạn cần sử dụng một lệnh awk khác để loại bỏ các ID số khỏi tập tin đồng bộ của bạn:
awk 'BEGIN { OFS=FS=":"; } {$3=""; $4=""; } { print; }' ~/passwd.sync > ~/passwd.sync.mod
Sau đó, bạn có thể chuyển tập tin đó cho newusers:
newusers ~/passwd.sync.mod
Lệnh này sẽ thêm tất cả người dùng từ tập tin vào tập tin /etc/passwd của hệ thống mới, đồng thời tự động tạo các nhóm liên quan. Bạn sẽ phải thêm thủ công các nhóm bổ sung không liên quan đến người dùng vào tập tin /etc/group. Hãy sử dụng các tập tin đồng bộ của bạn làm tham chiếu để chỉnh sửa các tập tin đích tương ứng.
Đối với tập tin /etc/shadow, bạn có thể sao chép cột thứ hai từ tập tin shadow.sync vào cột thứ hai của tài khoản tương ứng trên hệ thống mới. Điều này sẽ chuyển mật khẩu của các tài khoản sang hệ thống mới. Bạn có thể viết script để thực hiện các thay đổi này, tùy theo số lượng tài khoản cần chuyển.
Bước 2 –Chuyển các công việc sang hệ thống mới
Sau khi bạn đã chuyển người dùng, gói cài đặt và các dữ liệu khác từ hệ thống cũ, còn một bước nữa — chuyển các công việc hệ thống và thư tín của từng người dùng.
Thư mục
/var/spooltrên Linux theo định nghĩa “chứa dữ liệu đang chờ xử lý” theo một cách nào đó. Trong thực tế, điều này thường bao gồm các cron job bạn đã cấu hình cũng như thư tín được xử lý bởi hệ thống. Dù bạn có thể không trực tiếp vận hành một máy chủ email cục bộ, khái niệm “mail” của Linux còn bao gồm cả log và thông báo từ một số phần mềm, vì vậy rất quan trọng để đảm bảo rằng những dữ liệu này cũng được chuyển giao.
Bạn có thể bắt đầu quá trình này bằng cách viết một lệnh rsync khác cho thư mục spool. Thư mục này thường chứa cron, mail và một số log khác:
ls /var/spool
Output anacron cron mail plymouth rsyslog
Để chuyển thư mục mail sang máy đích, bạn có thể thêm một lệnh rsync vào script di chuyển của mình:
~/sync.sh rsync -azvP --progress source_server:/var/spool/mail/* /var/spool/mail/
Một thư mục khác trong /var/spool mà bạn cần chú ý là thư mục cron. Thư mục này chứa các cron job, dùng để lập lịch chạy tác vụ. Thư mục con crontabs chứa cấu hình cron của từng người dùng.
Chuyển các crontab của bạn bằng rsync
~/sync.sh rsync -azvP --progress source_server:/var/spool/cron/crontabs/* /var/spool/cron/crontabs/*
Lệnh này sẽ xử lý cấu hình cron của từng người dùng. Tuy nhiên, nó không bao gồm các thiết lập cron hệ thống. Trong thư mục /etc, có một tập tin crontab hệ thống và một số thư mục khác chứa các thiết lập cron.
Khi liệt kê:
ls /etc/cron*
Output cron.d cron.daily cron.hourly cron.monthly crontab cron.weekly
Tập tin crontab chứa thông tin cron hệ thống, còn các mục khác là thư mục chứa các thiết lập cron khác. Hãy kiểm tra chúng và quyết định xem có chứa thông tin bạn cần chuyển hay không.
Một lần nữa, sử dụng rsync để chuyển các thiết lập cron có liên quan sang hệ thống mới:
rsync -azvP --progress source_server:/etc/crontab /etc/crontab
Trong khi kiểm tra các cấu hình cron trong /etc, hãy đảm bảo rằng bạn không bỏ sót bất kỳ tập tin cấu hình nào khác. Ví dụ, máy chủ web Nginx lưu cấu hình của nó trong /etc/nginx, và bạn nên đảm bảo rằng thư mục này cũng được chuyển giao qua script di chuyển của bạn.
Sau khi bạn đã chuyển các thông tin cron sang hệ thống mới, hãy kiểm tra chúng hoạt động chính xác. Cách duy nhất là đăng nhập với từng người dùng và chạy các lệnh trong crontab của họ thủ công để đảm bảo không có vấn đề về quyền hay đường dẫn tập tin khiến các lệnh thất bại im lặng khi chạy tự động.
Bước 3 – Kiểm tra các trang Web và dịch vụ
Tại thời điểm này, bạn nên đã hoàn tất việc thêm các lệnh vào script di chuyển và chuyển dữ liệu. Bước tiếp theo là bắt đầu khởi động lại tất cả các dịch vụ liên quan trên máy chủ mới. Ví dụ, bạn có thể khởi động lại máy chủ web Nginx bằng lệnh:sudo systemctl restart nginx
Lưu ý rằng việc này có thể đã được thực hiện tự động khi cài đặt gói Nginx trên máy mới. Đối với các dịch vụ khác, có thể là các unit file do bạn tự viết hoặc được triển khai qua Docker, bạn nên thử khởi động lại chúng thủ công. Bạn cũng nên khởi động lại máy chủ ít nhất một lần để đảm bảo rằng các dịch vụ này có thể khởi động lại đúng sau thời gian ngừng hoạt động.
Hãy chú ý đến các tập tin log trong quá trình kiểm tra để phát hiện bất kỳ vấn đề nào.
Bạn cũng có thể tiến hành một số kiểm tra ngẫu nhiên khác. Ví dụ, nếu bạn đã chuyển thư mục /data bằng rsync, bạn có thể chuyển đến thư mục đó trên cả máy nguồn và máy đích và chạy lệnh du để xác minh kích thước:
cd /data du -hs
Output 471M .
Nếu có sự chênh lệch giữa hai hệ thống, bạn cần kiểm tra kỹ lưỡng.
Tiếp theo, bạn có thể kiểm tra các tiến trình đang chạy trên mỗi máy. Sử dụng lệnh top để có cái nhìn tổng quan về các tiến trình hoạt động:
top
Output
top - 21:20:33 up 182 days, 22:04, 1 user, load average: 0.00, 0.01, 0.00
Tasks: 124 total, 3 running, 121 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.0 us, 1.0 sy, 0.0 ni, 98.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 981.3 total, 82.8 free, 517.8 used, 380.7 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 182.0 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11 root 20 0 0 0 0 I 0.3 0.0 29:45.20 rcu_sched
99465 root 20 0 685508 27396 5372 S 0.3 2.7 161:41.83 node /root/hell
104207 vault 20 0 837416 236528 128012 S 0.3 23.5 134:53.49 vault
175635 root 20 0 11000 3824 3176 R 0.3 0.4 0:00.03 top
1 root 20 0 170636 9116 4200 S 0.0 0.9 8:50.40 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:01.04 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
. . .
Bạn cũng có thể thực hiện một số kiểm tra như bạn đã làm trên máy nguồn để xem môi trường trên máy đích có được tái tạo đúng không. Bạn có thể chạy lại lệnh netstat với các tham số -nlp để có cái nhìn tổng quan:
netstat -nlp
Output Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:8200 0.0.0.0:* LISTEN 104207/vault tcp 0 0 0.0.0.0:1935 0.0.0.0:* LISTEN 3691671/nginx: mast tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 3691671/nginx: mast tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3691671/nginx: mast tcp 0 0 0.0.0.0:1936 0.0.0.0:* LISTEN 197885/stunnel4 tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 162540/systemd-reso tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 129518/sshd: /usr/s tcp 0 0 127.0.0.1:3000 0.0.0.0:* LISTEN 99465/node /root/he tcp 0 0 0.0.0.0:8088 0.0.0.0:* LISTEN 3691671/nginx: mast tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 3691671/nginx: mast tcp 0 0 0.0.0.0:56733 0.0.0.0:* LISTEN 170269/docker-proxy tcp6 0 0 :::80 :::* LISTEN 3691671/nginx: mast tcp6 0 0 :::22 :::* LISTEN 129518/sshd: /usr/s tcp6 0 0 :::443 :::* LISTEN 3691671/nginx: mast tcp6 0 0 :::56733 :::* LISTEN 170275/docker-proxy udp 0 0 127.0.0.53:53 0.0.0.0:* 162540/systemd-reso raw6 0 0 :::58 :::* 7 162524/systemd-netw raw6 0 0 :::58 :::* 7 162524/systemd-netw Active UNIX domain sockets (only servers) Proto RefCnt Flags Type State I-Node PID/Program name Path unix 2 [ ACC ] STREAM LISTENING 5313074 1/systemd /run/systemd/userdb/io.systemd.DynamicUser unix 2 [ ACC ] SEQPACKET LISTENING 12985 1/systemd /run/udev/control unix 2 [ ACC ] STREAM LISTENING 12967 1/systemd /run/lvm/lvmpolld.socket unix 2 [ ACC ] STREAM LISTENING 12980 1/systemd /run/systemd/journal/stdout unix 2 [ ACC ] STREAM LISTENING 16037236 95187/systemd /run/user/0/systemd/private
Ngoài ra, bạn có thể chạy lại lsof:
lsof
Output COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME node\x20/ 99465 root 20u IPv4 16046039 0t0 TCP 127.0.0.1:3000 (LISTEN) vault 104207 vault 8u IPv4 1134285 0t0 TCP *:8200 (LISTEN) sshd 129518 root 3u IPv4 1397496 0t0 TCP *:22 (LISTEN) sshd 129518 root 4u IPv6 1397507 0t0 TCP *:22 (LISTEN) systemd-r 162540 systemd-resolve 12u IPv4 5313507 0t0 UDP 127.0.0.53:53 systemd-r 162540 systemd-resolve 13u IPv4 5313508 0t0 TCP 127.0.0.53:53 (LISTEN) docker-pr 170269 root 4u IPv4 1700561 0t0 TCP *:56733 (LISTEN) docker-pr 170275 root 4u IPv6 1700573 0t0 TCP *:56733 (LISTEN) stunnel4 197885 stunnel4 9u IPv4 1917328 0t0 TCP *:1936 (LISTEN) sshd 3469804 root 4u IPv4 22246413 0t0 TCP 159.203.102.125:22->154.5.29.188:36756 (ESTABLISHED) nginx 3691671 root 7u IPv4 2579911 0t0 TCP *:8080 (LISTEN) nginx 3691671 root 8u IPv4 1921506 0t0 TCP *:80 (LISTEN) nginx 3691671 root 9u IPv6 1921507 0t0 TCP *:80 (LISTEN) nginx 3691671 root 10u IPv6 1921508 0t0 TCP *:443 (LISTEN) nginx 3691671 root 11u IPv4 1921509 0t0 TCP *:443 (LISTEN) nginx 3691671 root 12u IPv4 2579912 0t0 TCP *:8088 (LISTEN) nginx 3691671 root 13u IPv4 2579913 0t0 TCP *:1935 (LISTEN) nginx 3691674 www-data 7u IPv4 2579911 0t0 TCP *:8080 (LISTEN) nginx 3691674 www-data 8u IPv4 1921506 0t0 TCP *:80 (LISTEN) nginx 3691674 www-data 9u IPv6 1921507 0t0 TCP *:80 (LISTEN) nginx 3691674 www-data 10u IPv6 1921508 0t0 TCP *:443 (LISTEN) nginx 3691674 www-data 11u IPv4 1921509 0t0 TCP *:443 (LISTEN) nginx 3691674 www-data 12u IPv4 2579912 0t0 TCP *:8088 (LISTEN) nginx 3691674 www-data 13u IPv4 2579913 0t0 TCP *:1935 (LISTEN)
Nếu bạn đã chuyển giao một máy chủ web hoặc các ứng dụng hướng ra ngoài, bạn cũng nên kiểm tra trang web trên máy mới. Tùy thuộc vào cấu hình, có thể bạn cần di chuyển tên miền và đăng ký lại chứng chỉ HTTPS trước khi có thể kiểm tra. Nếu máy mới của bạn nằm sau VPN hoặc lớp nhập khác, bạn có thể thử nghiệm qua một URL khác trước khi chuyển giao hoàn toàn.
Bạn cũng cần chuyển các quy tắc firewall, thường được chứa trong /etc/sysconfig/iptables và /etc/sysconfig/ip6tables.
Trước khi nạp các quy tắc này vào máy mới, hãy xem lại chúng để cập nhật các địa chỉ IP hoặc phạm vi thay đổi nếu cần.
Bước 4 – Thay đổi cài đặt DNS
Khi bạn đã chuyển giao tất cả dữ liệu mới nhất sang máy đích và đã kiểm tra các điểm cuối web, bạn có thể chỉnh sửa máy chủ DNS của tên miền để trỏ đến máy mới. Hãy đảm bảo rằng mọi tham chiếu đến địa chỉ IP của máy cũ đều được thay thế bằng thông tin của máy mới.
Thay đổi DNS thường mất từ vài phút đến một giờ để cập nhật tại hầu hết các ISP ở nhà. Sau khi DNS đã được cập nhật, có thể bạn cần chạy lại script di chuyển một lần cuối để đảm bảo rằng mọi yêu cầu tồn đọng đến máy chủ cũ đều được chuyển sang máy mới.
Kết luận
Máy chủ mới của bạn hiện đã được cài đặt và sẵn sàng tiếp nhận các yêu cầu, đồng thời xử lý toàn bộ dữ liệu từ máy chủ cũ. Tuy nhiên, bạn vẫn cần tiếp tục theo dõi chặt chẽ máy chủ mới để phát hiện và xử lý kịp thời bất kỳ sự cố hoặc bất thường nào có thể xảy ra.
Sau khi hoàn tất các bước di chuyển, việc duy trì máy chủ ổn định là yếu tố then chốt. Với dịch vụ thuê VPS giá rẻ từ DataOnline, bạn nhận được hiệu năng cao, băng thông không giới hạn và hỗ trợ 24/7. Tìm hiểu thêm để tối ưu chi phí cho dự án của bạn
Việc di chuyển dữ liệu và cấu hình giữa các máy chủ không phải là một công việc đơn giản. Tỉ lệ thành công trong quá trình di chuyển sẽ cao nhất khi bạn hiểu rõ hệ thống của mình ngay từ đầu. Mỗi hệ thống đều có những đặc điểm riêng biệt, và mỗi lần chuyển đổi sẽ đi kèm với những thử thách và vấn đề cần giải quyết. Do đó, bạn không nên thực hiện di chuyển nếu không có đủ thời gian và tài nguyên để xử lý các sự cố phát sinh trong quá trình này.
