Как выполнить миграцию серверов Linux. Часть 1. Подготовка системы
Введение
Существует множество сценариев, в которых вам, возможно, придется переместить данные и рабочие требования с одного сервера на другой. Возможно, вам потребуется реализовать свои решения в новом центре обработки данных, перейти на более крупную машину или перейти на новое оборудование или нового поставщика VPS.
Какими бы ни были ваши причины, при переходе с одной системы на другую следует учитывать множество различных соображений. Получение функционально эквивалентных конфигураций может быть затруднено, если вы не работаете с решением для управления конфигурацией, таким как Chef, Puppet или Ansible. Вам нужно не только перенести данные, но и настроить свои сервисы, чтобы они работали так же на новой машине.
Примечание. Как правило, современные развертывания всегда должны использовать систему управления конфигурацией, где это возможно, независимо от того, предназначены ли они для временных узлов Kubernetes или они используют комбинацию системных служб и контейнерного программного обеспечения. Это руководство будет в первую очередь полезно, когда это не так, и сервисы необходимо каталогизировать и перенести вручную.
В этом руководстве вы узнаете, как подготовить исходную и целевую системы к миграции. Это будет включать в себя настройку связи ваших двух машин с ключами SSH и исследование того, какие компоненты необходимо перенести. Вы начнете фактическую миграцию в следующей статье этой серии.
Шаг 1 – Делайте резервные копии
Первым шагом при выполнении любого потенциально разрушительного действия является создание свежих резервных копий. Вы же не хотите оказаться в ситуации, когда какая-то команда сломает что-то на вашей текущей производственной машине до того, как замена будет запущена и запущена.
Существует несколько различных способов резервного копирования вашего сервера. Ваш выбор будет зависеть от того, какие варианты имеют смысл для вашего сценария и что вам наиболее удобно.
Если у вас есть доступ к физическому оборудованию и место для резервного копирования (диск, USB и т. д.), вы можете клонировать диск, используя любое из множества доступных решений для резервного копирования образа. Функциональным эквивалентом при работе с облачными серверами является создание моментального снимка или изображения из интерфейса панели управления.
После того, как вы завершили резервное копирование, вы готовы продолжить. В оставшейся части этого руководства вам нужно будет запускать многие команды от имени пользователя root или с помощью 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. Вы можете узнать, как настроить ключи SSH на сервере Linux.
Вам нужно будет создать новый ключ на целевом сервере, чтобы вы могли добавить его в файл authorized_keys вашего существующего сервера. Это чище, чем наоборот, потому что таким образом новый сервер не будет иметь ложного ключа в своем файле authorized_keys после завершения миграции.
Во-первых, на целевом компьютере убедитесь, что у вашего пользователя root еще нет ключа 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 – Создайте список требований
Теперь вы действительно проведете глубокий анализ вашей системы.
В ходе работы требования к программному обеспечению могут измениться. Иногда на старых серверах есть некоторые службы и программное обеспечение, которые когда-то были нужны, но были заменены.
Как правило, ненужные службы можно отключить, а если они совершенно не нужны, удалить их, но их инвентаризация может занять много времени. Вам нужно выяснить, какие сервисы используются на вашем исходном сервере, а затем решить, должны ли эти сервисы существовать на вашем новом сервере.
То, как вы обнаруживаете службы и уровни выполнения, зависит от типа системы инициализации, используемой вашим сервером. Система инициализации отвечает за запуск и остановку служб либо по команде пользователя, либо автоматически. Примерно с 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. Вы можете запустить netstat с флагами -nlp, чтобы получить обзор:
- netstat -nlp
-nуказывает, что в выходных данных должны отображаться числовые IP-адреса, а не имена хостов или имена пользователей. При проверке локального сервера это обычно более информативно.-lуказывает, чтоnetstatдолжен отображать только активно прослушиваемые сокеты.-pотображает идентификатор процесса (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 содержат два отдельных блока — один для сетевых портов и один для сокетов. Если вы видите здесь службы, о которых у вас нет информации через систему инициализации, вам придется выяснить, почему это так, и собираетесь ли вы также перенести эти службы.
Аналогичную информацию о портах, предоставляемых службами, можно получить с помощью команды 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
Это даст вам хорошее представление о версии пакета, которую вы хотите сопоставить. Обязательно сохраните номера версий любого соответствующего программного обеспечения.
Заключение
Теперь у вас должно быть хорошее представление о том, какие процессы и службы на исходном сервере необходимо перенести на новую машину. Вы также должны выполнить предварительные шаги, чтобы ваши два сервера могли общаться друг с другом.
Теперь основа для вашей миграции завершена. В следующей статье этой серии вы начнете фактический процесс миграции.