Linux 서버 마이그레이션 방법 1부 - 시스템 준비
소개
한 서버에서 다른 서버로 데이터 및 운영 요구 사항을 이동해야 할 수 있는 많은 시나리오가 있습니다. 새 데이터 센터에서 솔루션을 구현하거나 더 큰 시스템으로 업그레이드하거나 새 하드웨어 또는 새 VPS 공급자로 전환해야 할 수 있습니다.
이유가 무엇이든 한 시스템에서 다른 시스템으로 마이그레이션할 때 고려해야 할 여러 가지 사항이 있습니다. Chef, Puppet 또는 Ansible과 같은 구성 관리 솔루션으로 작업하지 않는 경우 기능적으로 동등한 구성을 얻는 것이 어려울 수 있습니다. 데이터를 전송할 뿐만 아니라 새 시스템에서 동일한 방식으로 작동하도록 서비스를 구성해야 합니다.
참고: 일반적으로 최신 배포는 일시적인 Kubernetes 노드로 설계되었는지 또는 시스템 서비스와 컨테이너화된 소프트웨어의 조합을 실행하는지 여부에 관계없이 가능하면 항상 구성 관리 시스템을 사용해야 합니다. 이 가이드는 그렇지 않고 서비스를 수동으로 카탈로그화하고 마이그레이션해야 하는 경우에 주로 유용합니다.
이 가이드에서는 마이그레이션을 위해 소스 및 대상 시스템을 준비하는 방법을 검토합니다. 여기에는 SSH 키와 통신하기 위한 두 대의 시스템 설정과 전송해야 하는 구성 요소에 대한 조사가 포함됩니다. 이 시리즈의 다음 문서에서 실제 마이그레이션을 시작합니다.
1단계 – 백업 만들기
잠재적으로 파괴적인 작업을 수행할 때 취해야 할 첫 번째 단계는 새로운 백업을 생성하는 것입니다. 교체가 시작되어 실행되기 전에 명령이 현재 생산 시스템에서 무언가를 중단시키는 상황에 처하고 싶지 않을 것입니다.
서버를 백업하는 방법에는 여러 가지가 있습니다. 선택은 시나리오에 적합한 옵션과 가장 편안한 옵션에 따라 달라집니다.
물리적 하드웨어와 백업할 공간(디스크 드라이브, USB 등)에 액세스할 수 있는 경우 사용 가능한 많은 이미지 백업 솔루션 중 하나를 사용하여 디스크를 복제할 수 있습니다. 클라우드 서버를 다룰 때 기능적으로 동등한 것은 제어판 인터페이스 내에서 스냅샷 또는 이미지를 찍는 것입니다.
백업을 완료하면 계속할 준비가 된 것입니다. 이 가이드의 나머지 부분에서는 많은 명령을 루트로 실행하거나 sudo를 사용하여 실행해야 합니다.
2단계 – 소스 시스템에 대한 정보 수집
마이그레이션을 시작하기 전에 소스 시스템과 일치하도록 대상 시스템을 구성해야 합니다.
현재 서버와 마이그레이션하려는 서버 간에 최대한 많이 일치시키고 싶을 것입니다. 최신 대상 시스템으로 마이그레이션하기 전에 현재 서버를 업그레이드하고 나중에 다른 백업 세트를 만들 수 있습니다. 중요한 것은 실제 마이그레이션을 시작할 때 가능한 한 가깝게 일치한다는 것입니다.
새 컴퓨터에 대해 생성할 서버 시스템을 결정하는 데 도움이 되는 대부분의 정보는 uname 명령으로 검색할 수 있습니다.
- uname -r
Output5.4.0-26-generic
이것은 현재 시스템이 실행 중인 커널의 버전입니다. 원활하게 진행하려면 대상 시스템에서 일치하도록 시도하는 것이 좋습니다.
또한 원본 서버의 배포판과 버전을 일치시켜야 합니다. 소스 시스템에 설치한 배포 버전을 모르는 경우 다음을 입력하여 확인할 수 있습니다.
- cat /etc/issue
OutputUbuntu 20.04.3 LTS \n \l
가능한 경우 이와 동일한 매개변수를 사용하여 새 서버를 만들어야 합니다. 이 경우 Ubuntu 20.04 시스템을 생성합니다. 또한 커널 버전과 최대한 일치하도록 노력해야 합니다. 일반적으로 이것은 Linux 배포판의 리포지토리에서 사용할 수 있는 최신 커널이어야 합니다.
3단계 – 원본 서버와 대상 서버 간의 SSH 키 액세스 설정
파일을 전송할 수 있도록 서버가 통신할 수 있어야 합니다. 이렇게 하려면 그들 사이에 SSH 키를 교환해야 합니다. Linux 서버에서 SSH 키를 구성하는 방법을 배울 수 있습니다.
기존 서버의 authorized_keys 파일에 추가할 수 있도록 대상 서버에 새 키를 생성해야 합니다. 이 방법은 마이그레이션이 완료될 때 새 서버의 authorized_keys 파일에 스트레이 키가 없기 때문에 다른 방법보다 더 깔끔합니다.
먼저 대상 머신에서 다음을 입력하여 루트 사용자에게 이미 SSH 키가 없는지 확인하십시오.
- ls ~/.ssh
Outputauthorized_keys
id_rsa.pub 및 id_rsa 파일이 보이면 이미 키가 있는 것이므로 이를 전송하기만 하면 됩니다.
해당 파일이 표시되지 않으면 ssh-keygen을 사용하여 새 키 쌍을 만듭니다.
- ssh-keygen -t rsa
모든 프롬프트에서 "Enter\를 눌러 기본값을 수락합니다.
이제 ssh를 통해 키를 파이핑하여 원본 서버로 키를 전송할 수 있습니다.
- cat ~/.ssh/id_rsa.pub | ssh other_server_ip "cat >> ~/.ssh/authorized_keys"
이제 암호를 제공하지 않고 대상 시스템에서 소스 서버로 SSH로 자유롭게 연결할 수 있습니다.
- ssh other_server_ip
이렇게 하면 추가 마이그레이션 단계가 훨씬 더 원활하게 진행됩니다.
4단계 – 요구 사항 목록 작성
이제 실제로 시스템에 대한 심층 분석을 수행하게 됩니다.
운영 과정에서 소프트웨어 요구 사항이 변경될 수 있습니다. 때때로 오래된 서버에는 한때 필요했지만 교체된 일부 서비스와 소프트웨어가 있습니다.
일반적으로 불필요한 서비스는 비활성화할 수 있으며 완전히 불필요한 경우 제거할 수 있지만 이러한 서비스를 살펴보는 데 시간이 많이 걸릴 수 있습니다. 원본 서버에서 어떤 서비스가 사용되고 있는지 확인한 다음 해당 서비스가 새 서버에 있어야 하는지 결정해야 합니다.
서비스와 실행 수준을 검색하는 방법은 서버가 사용하는 "init\ 시스템 유형에 따라 다릅니다. init 시스템은 사용자의 명령에 따라 또는 자동으로 서비스를 시작하고 중지하는 역할을 합니다. 약 2014년부터 거의 모든 주요 Linux 배포판은 Systemd라는 초기 시스템을 채택했으며 이 가이드는 Systemd를 반영합니다.
Systemd에 등록된 서비스를 나열하려면 systemctl 명령을 사용할 수 있습니다.
- systemctl list-units -t service
Output UNIT LOAD ACTIVE SUB DESCRIPTION >
accounts-daemon.service loaded active running Accounts Service >
apparmor.service loaded active exited Load AppArmor profiles >
apport.service loaded active exited LSB: automatic crash repor>
atd.service loaded active running Deferred execution schedul>
blk-availability.service loaded active exited Availability of block devi>
cloud-config.service loaded active exited Apply the settings specifi>
cloud-final.service loaded active exited Execute cloud user/final s>
cloud-init-local.service loaded active exited Initial cloud-init job (pr>
cloud-init.service loaded active exited Initial cloud-init job (me>
console-setup.service loaded active exited Set console font and keyma>
containerd.service loaded active running containerd container runti>
…
서비스 관리를 위해 Systemd는 "대상\ 개념을 구현합니다. 기존 초기화 시스템을 사용하는 시스템은 한 번에 하나의 "런레벨\에만 있을 수 있지만 Systemd를 사용하는 서버는 동시에 여러 대상에 도달할 수 있습니다. 이것은 실제로는 더 유연하지만 활성화된 서비스를 파악하는 것이 더 어려울 수 있습니다.
다음을 입력하여 현재 활성 상태인 대상을 확인할 수 있습니다.
- systemctl list-units -t target
Output UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
cloud-config.target loaded active active Cloud-config availability
cloud-init.target loaded active active Cloud-init target
cryptsetup.target loaded active active Local Encrypted Volumes
getty.target loaded active active Login Prompts
graphical.target loaded active active Graphical Interface
local-fs-pre.target loaded active active Local File Systems (Pre)
local-fs.target loaded active active Local File Systems
multi-user.target loaded active active Multi-User System
network-online.target loaded active active Network is Online
…
다음을 입력하여 사용 가능한 모든 대상을 나열할 수 있습니다.
- systemctl list-unit-files -t target
OutputUNIT FILE STATE VENDOR PRESET
basic.target static enabled
blockdev@.target static enabled
bluetooth.target static enabled
boot-complete.target static enabled
cloud-config.target static enabled
cloud-init.target enabled-runtime enabled
cryptsetup-pre.target static disabled
cryptsetup.target static enabled
ctrl-alt-del.target disabled enabled
…
여기에서 각 대상과 연결된 서비스를 확인할 수 있습니다. 대상은 서비스 또는 기타 대상을 종속성으로 가질 수 있으므로 다음을 입력하여 각 대상이 구현하는 정책을 확인할 수 있습니다.
- systemctl list-dependencies target_name.target
multi-user.target은 시작 프로세스에서 사용자가 로그인할 수 있는 시점에 도달하는 Systemd 서버에서 일반적으로 사용되는 대상입니다. 예를 들어 다음과 같이 입력할 수 있습니다.
- systemctl list-dependencies multi-user.target
Outputmulti-user.target
● ├─apport.service
● ├─atd.service
● ├─console-setup.service
● ├─containerd.service
● ├─cron.service
● ├─dbus.service
● ├─dmesg.service
● ├─docker.service
● ├─grub-common.service
● ├─grub-initrd-fallback.service
…
그러면 해당 대상의 종속성 트리가 나열되어 해당 대상에 도달했을 때 시작되는 서비스 및 기타 대상 목록을 제공합니다.
다른 방법을 통한 서비스 확인
패키지 관리자가 구성한 대부분의 서비스는 초기 시스템에 등록되지만 Docker 배포와 같은 일부 다른 소프트웨어는 등록되지 않을 수 있습니다.
이러한 서비스에서 사용 중인 네트워크 포트와 Unix 소켓을 살펴봄으로써 이러한 다른 서비스와 프로세스를 찾을 수 있습니다. 대부분의 경우 서비스는 어떤 방식으로든 서로 또는 외부 엔터티와 통신합니다. 서비스가 통신할 수 있는 특정 수의 서버 인터페이스만 있으며 이러한 인터페이스를 확인하는 것은 다른 서비스를 발견하는 좋은 방법입니다.
네트워크 포트와 사용 중인 Unix 소켓을 검색하는 데 사용할 수 있는 한 가지 도구는 netstat입니다. 개요를 보려면 -nlp 플래그와 함께 netstat를 실행할 수 있습니다.
- netstat -nlp
-n은 호스트 이름이나 사용자 이름이 아닌 숫자 IP 주소가 출력에 표시되도록 지정합니다. 로컬 서버를 확인할 때 일반적으로 더 많은 정보를 제공합니다.-l는netstat가 활성 수신 소켓만 표시하도록 지정합니다.-p는 프로세스 ID(PID)와 포트 또는 소켓을 사용하는 각 프로세스의 이름을 표시합니다.
OutputActive 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
…
netstat 출력에는 두 개의 개별 블록이 포함되어 있습니다. 하나는 네트워크 포트용이고 다른 하나는 소켓용입니다. 여기에 init 시스템을 통해 정보가 없는 서비스가 표시되면 그 이유와 해당 서비스도 마이그레이션할지 여부를 파악해야 합니다.
lsof 명령을 사용하여 서비스에서 사용 가능한 포트에 대한 유사한 정보를 얻을 수 있습니다.
- lsof
OutputCOMMAND 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)
netstat 및 lsof는 모두 다양한 기타 상황에서 유용한 핵심 Linux 프로세스 관리 도구입니다.
5단계 – 패키지 버전 수집
이 시점에서 대상 서버에서 구현해야 하는 소스 시스템에서 실행 중인 서비스에 대해 잘 알고 있어야 합니다.
구현해야 할 서비스 목록이 있어야 합니다. 전환이 순조롭게 진행되려면 가능한 한 버전을 맞추는 것이 중요합니다.
소스 시스템에 설치된 모든 단일 패키지를 검토하고 새 시스템에 복제하려고 시도할 필요는 없지만 필요에 따라 중요한 소프트웨어 구성 요소를 확인하고 해당 버전 번호를 찾아야 합니다.
때때로 각 명령에 -v 또는 --version 플래그를 전달하여 소프트웨어 자체에서 버전 번호를 얻을 수 있지만 패키지를 통해 수행하는 것이 더 간단합니다. 관리자. Ubuntu/Debian 기반 시스템을 사용 중인 경우 dpkg 명령을 사용하여 설치된 패키지 버전을 확인할 수 있습니다.
- dpkg -l | grep package_name
대신 Rocky Linux, RHEL 또는 Fedora 기반 시스템을 사용하는 경우 동일한 목적으로 rpm을 사용할 수 있습니다.
- rpm -qa | grep package_name
이렇게 하면 일치시키려는 패키지 버전에 대한 좋은 아이디어를 얻을 수 있습니다. 관련 소프트웨어의 버전 번호를 유지해야 합니다.
결론
이제 소스 서버의 어떤 프로세스와 서비스를 새 시스템으로 이전해야 하는지 잘 알고 있어야 합니다. 또한 두 서버가 서로 통신할 수 있도록 예비 단계를 완료해야 합니다.
이제 마이그레이션을 위한 기초 작업이 완료되었습니다. 이 시리즈의 다음 기사에서는 실제 마이그레이션 프로세스를 시작합니다.