Міграція сервера: найефективніший спосіб


10

Мені доручено перенести один з наших сайтів між серверами (два різні хости). Обидва середовища є Linux.

Сайт передає відео, тому сервер наразі заповнений медіа-файлами (зображеннями та відео). Моя перша думка полягала в тому, що ми будемо використовувати rsycnc для передачі всього, але я хочу бути максимально ефективним і робити все якнайшвидше. Я подумав, що у когось із вас можуть бути поради щодо прискорення процесу, або якщо rsync - це навіть правильний вибір.

Заздалегідь спасибі. Вибачте за мої обмежені знання з питань сисдаміна ...

EDIT: Ми працюємо на базовому стеку LAMP (центсоси) і переходимо до червоного капелюха на стійці).


1
Визначте "ефективний" у цьому контексті. Швидкий, надійний, надійний чи що? І ні, ви не можете їх мати.
Джон Гарденєр

1
rsync майже напевно найкращий вибір для міграції даних; Є ще конфігурація та можливі бази даних тощо, про які згадували інші, які мають інші кращі варіанти.
fukawi2

Відповіді:


12

Багато хто бере участь у "перенесенні програми з одного сервера на інший" - насправді немає можливості відповісти на це всебічно для всіх випадків використання. ВИ можете відповісти на це досить вичерпно, якщо ви підходите до цього систематично:

  1. Складіть список всього необхідного вашій програмі.
    • Веб-сервер?
    • Сервер баз даних?
    • Поштовий сервер?
    • Мова сценаріїв (PHP, Ruby / Rails, Perl, щось інше)?
    • Допоміжні програми (ImageMagick тощо)?
  2. Складіть список важливих елементів конфігурації.
    • IP-адреса, мережева маска, шлюз тощо.
    • DNS-сервери
    • Елементи, що залежать від програми (тимчасові каталоги тощо)
  3. Візьміть списки (1) та (2) та напишіть контур міграції.
    Сюди слід включити такі речі, як встановлення та налаштування будь-якого потрібного програмного забезпечення / пакунків, скидання та завантаження бази даних тощо.
  4. ТЕСТУВАННЯ МІГРАЦІЇ
    Скопіюйте все так, як ви хотіли б, якщо сервер збирається жити, але не використовуйте його. Закінчіть його в ізольованій мережі, коли все закінчите і протестуйте все.
    Якщо у вас є стандартна процедура тестування для вашої програми, слід запустити її на перенесеному сервері.
  5. Якщо все не пішло ідеально, перейдіть (3), оновіть (1) та (2), а потім перегляньте свій план.
  6. Коли тестові міграції проходять ідеально, виконайте фактичну міграцію.
    Залежно від того, наскільки складний процес міграції, це може просто означати скидання та перезавантаження бази даних, або ви можете витерти машину та зробити все з нуля.

Коли ви закінчите, у вашому конкретному середовищі з’явиться контрольний список для вашої конкретної програми. Цей контрольний список, ймовірно, розвиватиметься під час розробки програми, але він може послужити відправною точкою через 3-5 років, коли вам доведеться знову мігрувати.

Інші речі, які слід враховувати, включають в себе управління конфігурацією ala Puppet або Chef.
(Якщо ви збираєтесь бути "систематичним адміністратором", вам слід розглянути їх, інакше передайте їх відповідальній особі / команді.)


5

Ну, у вас є конфігурація сервера та вміст сервера, з яким ви можете мати справу, і навряд чи однакова техніка буде працювати для обох.

У вас є база даних? Якщо це так, це потрібно буде також перемістити. Rsync відмінно підходить для статичного вмісту. Просто запустіть її один раз, щоб перенести список своїх даних, а потім кажіть кожні кілька годин, щоб синхронізувати речі до розрізування. Переконайтеся, що вимкніть крон rsync перед міграцією!

Що стосується конфігурації, ми не маємо уявлення про те, що ти працюєш, тому не можемо реально давати рекомендації.


Дякую! Зараз ми працюємо на CentOS зі стеком Apache / PHP / MySQL (досить стандартний) з WHM. Ми переносимо все, щоб переробити Linux на Rackspace.
Ghost Code
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.