Как перенести сервер Linux на новое оборудование
Независимо от того, переходите ли вы на более мощные серверы, перемещаетесь ли вы в новые регионы или добавляете новые экземпляры, миграцию сервера Linux можно упростить, применяя правильные стратегии и зная правильные команды. Мы обсудим, как перенести ваш сервер на новую машину с минимальными хлопотами.
Стратегии миграции
Простейшей и наиболее эффективной стратегией является сине-зеленое развертывание: запустите и запустите новый сервер, а затем, когда он будет готов к работе, перенаправьте на него трафик и удалите старый сервер, как только убедитесь, что проблем нет. При балансировке нагрузки этот процесс может происходить поэтапно, что еще больше снижает вероятность проблем с доступностью.
Сине-зеленое развертывание включает в себя копирование всех файлов, пакетов и кода со старого сервера на новый. Это может быть так же просто, как вручную установить необходимые пакеты, такие как веб-сервер NGINX, а затем скопировать конфигурацию с существующего сервера. Вы также можете сделать полную резервную копию диска и создать из нее новый сервер.
Конечно, сейчас самое подходящее время подумать, можете ли вы использовать контейнеры или автоматическое масштабирование. Контейнеры Docker можно легко остановить, запустить и перенести, скопировав базовые тома данных (или используя общее хранилище данных, такое как EFS). Автомасштабирование различается в зависимости от поставщиков, но если вы добавляете новую копию своего сервера для удовлетворения растущего спроса, это может быть правильным для вашего бизнеса. Вы также можете использовать автоматическое масштабирование с контейнерами Docker на многих платформах, таких как AWS ECS.
Настройка как для контейнеров, так и для автоматического масштабирования требует, чтобы вы проделали большую часть той же работы, что и для переноса сервера вручную, например, автоматизировали установку пакетов и собственного кода, поэтому, если вы планируете снова выполнить миграцию в будущем , вам следует подумать сейчас, что вам лучше переключиться на контейнеры или настроить автоматическое масштабирование.
Если вас интересуют контейнеры, вы можете прочитать наше руководство по началу работы с Docker, чтобы узнать больше, или прочитать наше руководство по использованию автоматического масштабирования в AWS или Google Cloud Platform.
Установка пакетов
Если вы не совсем уверены, что вы установили на старый сервер, лучший способ проверить это — получить список всех установленных служб. Это покажет большинство основных вещей, которые вам нужно установить:
Причина предпочтения служб листинга заключается в том, что список установленных пакетов может быть очень длинным, при этом также устанавливаются все второстепенные зависимости. На моем тестовом сервере Ubuntu было установлено более 72 000 пакетов, поэтому их список не очень полезен, учитывая, что все они будут установлены в любом случае при установке основных служб, необходимых новому серверу.
Если вы хотите, вы можете перечислить их все с помощью следующей команды:
Для поиска в списке пакетов определенного пакета вы можете использовать:
sudo apt -qq list program_name --installed
В любом случае вам нужно составить список пакетов, которые необходимо установить, и установить их на новый сервер.
Перенос диска сервера с помощью rsync
Вы можете заархивировать диск с помощью tar , но tar обычно предназначен для архивирования отдельных файлов или каталогов, а не всего диска. Если вы перемещаете много данных, у вас может не хватить места для локального резервного копирования (возможно, это даже причина для обновления!).
В этом случае вам нужно использовать команду rsync для загрузки данных непосредственно на целевой сервер. rsync подключится через SSH и синхронизирует два каталога; в этом случае мы хотим передать локальный каталог на удаленный сервер, например:
rsync -azAP /etc/nginx username@remote_host:/etc/nginx
Вот и вся команда — вы должны увидеть индикатор выполнения по мере ее передачи (используя сжатие с флагом -z ), а когда это будет сделано, вы увидите файлы в целевом каталоге на новом сервере. . Возможно, вам придется запустить это несколько раз, чтобы скопировать каждый каталог; вы можете использовать этот онлайн-генератор команд rsync для создания команды для каждого запуска.
Если хотите, можете попробовать скопировать всю корневую файловую систему на новый сервер, за исключением некоторых системных файлов:
sudo rsync -azAP / --exclude= username@remote_host:/
Если вы просто хотите сделать резервную копию нескольких каталогов, вы можете использовать простую команду tar для создания одного файлового архива:
tar -czvf nginxconfig.tar.gz /etc/nginx
В результате будет создан один файл, который можно передать на целевой сервер с помощью scp или по FTP. Затем извлеките файл в целевой каталог:
tar -xzvf nginxconfig.tar.gz -C /etc/nginx
Перенос базы данных
Если вам нужно перенести базу данных, вы захотите сделать резервную копию и создать дамп исходной базы данных. Для MySQL это будет:
mysqldump -uUser -pPass -hHost --single-transaction database > backup.bak
mongodump --host=mongodb.example.net --port=27017
Затем вам нужно восстановить базу данных на целевом сервере. Для MySQL это будет:
mysql -u [user] -p [database_name] < [filename].sql
Для других баз данных вы сможете найти соответствующие команды в Интернете.
Переключение IP-адресов на новую систему
Конечно, вы захотите убедиться, что все работает, как задумано, прежде чем продолжить, но как только это произойдет, вы захотите переключить трафик на новый сервер.
Самый простой способ сделать это — изменить записи DNS. После обновления клиенты и службы будут отправлены на новый сервер. Однако это происходит одновременно, поэтому, если у вас есть балансировщик нагрузки, было бы лучше медленно переводить трафик на новый экземпляр.
Если вы используете AWS или аналогичный провайдер с эластичными IP-адресами, вы можете поменять адрес, чтобы он указывал на новый сервер, который не потребует обновления DNS. На вкладке «Эластичные IP-адреса» в консоли EC2 выберите «Действие» > «Связать эластичный IP-адрес».
Это позволит вам изменить ассоциацию, которая мгновенно перенаправит трафик на новый экземпляр.
Как правильно перенести сервер Ubuntu с одной машины на другую?
Попытка сделать это уже три раза, но не увенчалась успехом, так что надеялся ли кто-нибудь здесь направить меня в правильном направлении?
Я пытаюсь переместить мой сервер Ubuntu 14.04 с одной физической машины на другую. Я использую следующую команду rsync для достижения этой цели:
rsync -aAXvP --exclude= root@iphere:/* / rsync правильно перемещает файлы, и без перезагрузки я могу запустить некоторые службы с исходного сервера, однако после перезагрузки (для запуска других служб) у меня теперь появляется бесконечный экран загрузки Ubuntu. Вы знаете тот, у которого точка движется вправо каждую секунду.
Первоначально проблема заключалась в том, что загрузочное устройство не было найдено, поэтому после rysnc я сменил UUID с предыдущего сервера. Это привело к тому, что Ubuntu не загружается; так что шаг вперед. Однако сейчас я немного растерялся, поскольку сообщений об ошибках нет, и я не могу ничего сделать физически с машиной, поскольку это VPS от Vultr.
И теперь, думая об этом, когда я, наконец, получу дело, Сеть будет совсем не в порядке.
Я очень плохо знаком с Linux и командной строкой, поэтому любая помощь будет чрезвычайно цениться.
Стоит также отметить, что я выбрал этот подход, потому что я хочу сохранить новый сервер точно таким же, как мой старый / текущий, о восстановлении сервера не может быть и речи. У меня просто нет времени.
2 ответа 2
Это не методология, которую вы использовали - и я считаю эту технику «наивной», но она надежно сработала для меня. Вы, возможно, должны настроить вещи с некоторым пониманием того, как работает Linux, конечно. Я адаптировал это из ответа SF с небольшими изменениями
Проблема этого метода в том, что некоторые конфигурационные файлы лучше не дублировать - нет практической причины для копирования через конфигурацию grub или /etc/networks .
То, что я считаю правильным способом сделать это, это использовать dpkg --get-selections, чтобы выгрузить список установленных пакетов, и установить их с помощью dpkg --set-selections. При необходимости создайте тех же пользователей, что и в исходной системе - cat /etc/passwd должен перечислить их, и вы можете проверить с помощью diff, чтобы увидеть, идентичны ли эти два списка. Затем используйте rsync для дублирования вашей папки /etc/ для настроек (хотя, если вы используете проверку статического IP-адреса или пропустите /etc /networks), различные папки /home/ для пользователей (и проверьте разрешения здесь) и другие папки, такие как /var/www/ .
Я рекомендую подготовить /etc /, а затем скопировать файлы конфигурации на место, тем более что это возможная точка поломки.
Проверьте, убедитесь, что все есть, и все готово. У меня уходит меньше времени, чем на настройку свежего сервера.
Здесь есть несколько «хороших» вещей. Вы гарантируете, что вещи, которые не должны быть выполнены вручную, не являются - управление пакетами, и такие вещи, как grub, остаются согласованными. Это позволяет вам перемещать минимум файлов - быть исключительным, не включая то, что вы перемещаете.
Изменение UUID - хороший план. Но дело в том, что хотя сейчас система может быть технически пригодна для использования, вам нужно убедиться в нескольких вещах. Все эти заметки основаны на моих заметках по настройке сервера с использованием Ubuntu 12.04:
Настройки сети: не уверены, что сетевые настройки старой установки сравнивались с тем, какими они должны быть на Vultr, но велики шансы, что их следует отрегулировать. Если вы можете войти на компьютер, я бы порекомендовал запустить ifconfig чтобы получить необработанные показания данных интерфейса. Что касается сетевых настроек, это может произойти в /etc/network/interfaces который можно просмотреть / отредактировать следующим образом:
sudo nano /etc/network/interfaces Тем не менее, если вы можете добраться до машины, есть вероятность, что есть настройка DHCP? В любом случае, я бы посмотрел туда, чтобы что-то изменить, и если вы не знаете, как это сделать, обратитесь в службу поддержки Vultr, расскажите им, что именно вы сделали и что вам нужно изменить. Я уверен, что они сразу же ответят вам небольшим списком сетевых настроек, которые вы должны изменить.
Обновить Grub: это может быть или не быть проблемой, но вы должны войти в систему и выполнить следующую команду:
Это заставит систему обновить настройки загрузчика Grub. Но если вы заметите задержку, это может быть тайм-аут в самой настройке загрузчика Grub. Иногда - и, честно говоря, мне было трудно определить, когда и как - Grub зависает, казалось бы, вечно, ожидая взаимодействия с пользователем при выборе загрузочного устройства. Если вы на 100% уверены, что вам не нужно загружаться ни на что, кроме имеющегося у вас ядра Ubuntu, я бы порекомендовал изменить настройки Grub по умолчанию в этом файле:
Теперь закомментируйте это - или удалите его - и затем замените его этим новым параметром, а также дополнительным параметром для GRUB_RECORDFAIL_TIMEOUT например так:
GRUB_TIMEOUT=0 GRUB_RECORDFAIL_TIMEOUT=$GRUB_TIMEOUT Теперь снова запустите команду обновления Grub:
И посмотрим, что происходит при перезагрузке. Если это было этой проблемой, перезагрузка должна быть довольно быстрой по сравнению с предыдущей.
И после всего этого вы заявляете:
Стоит также отметить, что я выбрал этот подход, потому что я хочу сохранить новый сервер точно таким же, как мой старый / текущий, о восстановлении сервера не может быть и речи. У меня просто нет времени.
Ну, сколько времени вы на самом деле сэкономили между миграцией, путаницей в настройках и теперь хэшированием здесь? Является ли это воспринимаемой проблемой экономии времени, которая на самом деле не составляет в целом экономию времени?
Не пойми меня неправильно; Я рад помочь. Но в целом способ, которым я настраиваю серверы Linux - и я в основном работаю в Ubuntu - это то, что у меня есть очень хорошо проверенная формула для создания надежного базового сервера с нуля. Теперь это занимает у меня около 1 часа; может занять больше времени в зависимости от скорости системы и тому подобное. Но после того, как я заложил эту прочную основу, конфигурация приложений и пользователей становится запоздалой мыслью.
Таким образом, восприятие сэкономленного времени может столкнуться с неизвестными реалиями чистого клонирования, например, так: установив из чистого дистрибутива Linux для начала, а затем заложив прочную основу, вы в основном делаете все свои системы Linux более переносимыми без непредвиденных «ошибок» такого процесса клонирования.