Назад | Перейти на главную страницу

Какие основные проблемы необходимо решать при переходе между разными хостинг-провайдерами?

У нас есть от 100 до 200 серверов на двух сайтах, расположенных у стороннего хостинг-провайдера.
(Компания, которую никто бы не узнал.)

Различный технический персонал предлагает перейти к другому поставщику хостинга (например, Amazon).

Основными причинами этого являются:

Какие ключевые проблемы необходимо решить при переносе всех серверов от одного провайдера к другому.

Серверы бывают всех видов, с несколькими ОС, сложной зонированной сетью и несколькими типами программного обеспечения для виртуализации.

Обновления:

Все это выделенные хосты, которые арендуются у провайдера на определенный период. (Это одна из проблем - негибкость нынешнего устройства.)

Во время переезда можно ограниченное время простоя. (Выходные, поздно вечером и т. Д.)

Во многом это действительно зависит от того, для чего вы используете серверы. Это общий ответ, предполагающий SLA с высоким целевым временем работы.

Если вам нужно поддерживать работоспособность во время перемещения, вам нужно будет настроить новые серверы с новым хостом, а затем настроить репликацию между двумя серверами. Если у вас есть репликация, вы можете подумать об использовании балансировки нагрузки для медленного ввода новых серверов в работу. Таким образом, в случае сбоя он будет изолирован только для нескольких пользователей (возможно, даже сначала перенесет бета-группу).

Если постепенное продление продолжит работать, в конечном итоге вы можете просто переключить его на 100% использование новых серверов. Как только вы это сделаете, вы можете выключить репликацию и списать старые серверы.

Конечно, если ваша цель по времени безотказной работы высока, вы можете рассмотреть возможность сохранения некоторых старых серверов на репликации и балансировки нагрузки в качестве резервных копий.

Первое, о чем вам следует подумать и внимательно изучить, - действительно ли новый провайдер может предоставить вам необходимые настройки и услуги (время безотказной работы, доступ, поддержка и т. Д.). Предполагая, что они могут, следующим шагом будет тщательно задокументировать любые изменения, которые необходимо будет внести в существующую настройку после перемещения. Маловероятно, что в двух разных средах все будет работать одинаково, необходимо будет внести некоторые изменения.

После этого следует постепенное продление, как описал Джим МакКит, с таким количеством тестов, которое вы можете провести на начальной небольшой системе, чтобы убедиться, что вы ничего не пропустили.

Я думаю, что, основываясь на появившейся новой информации, я бы рекомендовал использовать Инструменты VMWare для миграции в виртуальную инфраструктуру. затем перенести эту инфраструктуру. Вам все равно придется иметь дело с любыми жестко закодированными IP-адресами, которые необходимо изменить, и с неизбежными проблемами кэширования DNS при фактическом переключении.

Одним из огромных преимуществ этого является то, что VMWare имеет большой опыт выполнения этих двух шагов и сможет помочь вам в этом. Кроме того, когда вы закончите, у вас будет виртуализированная инфраструктура, которая станет намного более гибкой и устойчивой.

Какие ключевые проблемы необходимо решить при переносе всех серверов от одного провайдера к другому.

Несколько заметок ...

  • Время переезда (100 серверов - это много для переезда за несколько часов)
  • Перекрытие
    • Возможно, стоит подумать о том, чтобы обе они работали при обновлении DNS.
    • Остановить обновление или передать обновления в реальном времени или позже
  • Выделение IP
  • Конфигурация сети
  • Управление сетью
    • Каждый провайдер предоставляет разный уровень и тип обслуживания.
    • То, как вы работаете с текущим поставщиком, может негативно повлиять на отношения с новым поставщиком, поэтому не берите с собой свои предположения и процессы, не зная об этом.
  • Время безотказной работы, SLA, TOS, другие вопросы контрактов
  • Версии программного обеспечения, особенно если они управляют за вас
  • Конфигурация машины
    • Какую часть машины вы контролируете?
  • Действия в чрезвычайных ситуациях
    • Они доступны 24/7?
    • Резервное копирование на месте, восстановление?
    • Время отклика
  • Конфигурация межсетевого экрана
  • Кто их поставщики услуг (и коллеги, если применимо)
  • Каков ваш процесс
    • Для резервного копирования всего
    • Восстановление на новых машинах
    • Тестируем это
    • Перенос новых данных после резервного копирования (синхронизация баз данных)
    • Вывод в онлайн
  • Каков план резервного копирования, когда (а не если) что-то пойдет не так
    • Установить вехи
    • Если определенная веха не соответствует крайнему сроку, каков процесс - пропустить, откатиться или остаться на месте, пока он не будет решен (особенно для фактического переключения сервера)
  • Предварительная настройка кешей (HTTP-заголовки, метаинформация и т. Д.), Чтобы они не кешировали вещи, которые могут измениться с переключателем.

-Адам

Вы можете разместить несколько серверов в том же помещении, что и существующие, а затем каждые выходные отключать несколько серверов для резервного копирования старого сервера и восстановления его на новом размещенном сервере, которым вы действительно владеете. После того, как вы перешли с выделенных серверов на свои собственные, вы можете физически загрузить все серверы на грузовик и переместить их в новое место. Я работал в компании, которая делала что-то очень похожее (они начали с размещенных серверов).

Если вы можете разделить его на несколько меньших ходов, это будет лучше, но это зависит от взаимозависимостей между серверами.

Очевидным недостатком является то, что вам потребуется перейти с выделенного хостинга на совместный хостинг, что может не вписаться в ваш план.

Другой вариант - отключить некоторые серверы в пятницу вечером, создать для них резервную копию, а затем переместить резервную копию и переустановить ее на другой машине. Похоже на кошмар. Я все еще рекомендую Вариант VMWare.