Вопрос: Как перенести веб-сайт с одного сервера на другой с минимальным временем простоя?


У меня есть сервер, на котором размещен веб-сайт и другие службы, которые необходимо переустановить. Я хотел бы временно переместить эти службы на другой сервер с минимальным временем простоя. Оба сервера находятся в одном центре обработки данных и могут находиться на одном сетевом коммутаторе.

Каков наилучший способ перемещения этих служб с минимальным временем простоя? Сайт управляется базой данных, поэтому в идеале я хочу событие «switchroad switch», где я могу гарантировать, что весь трафик будет перемещен на новый сервер за один раз. Я не хочу иметь ситуацию, когда старая база данных получает обновления после переноса данных в новую.

Две вещи, которые я рассмотрел:

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

Есть ли способ исправить эту проблему с перенаправлением Apache +? Я подозреваю, что нет, поскольку виртуальный хостинг на основе имен прерывается без имени домена, который я не могу использовать, потому что он устарел.

Связывание старого IP-адреса с новым сервером и (временно) назначить старый сервер другому IP во время переустановки. В этом случае я могу оставить только DNS.

Есть ли другие простые решения, которые я рассматриваю?


6
2018-06-01 19:44


Источник




Ответы:


Похоже, вам лучше всего обслуживать относительно простое решение ... потому что вы можете терпеть немного времени простоя. Я бы избегал обмана с DNS, потому что у вас мало контроля за задержками распространения / кэширования.

1- построить временный сервер
2-опускание сервисов на первичном сервере
3- перемещение / копирование данных ключа с первичного сервера на временный сервер
4- изменить первичный сервер на другой IP-адрес
5- изменить сервер temp на первичный IP-адрес, вызвать
6 - фиксировать первичный сервер (на разных IP-адресах)
7 - снижать уровень обслуживания на сервере temp
8 - перемещение / копирование данных ключа с временного сервера на основной сервер
9-выключить временный сервер
10 - изменить первичный сервер на первичный IP-адрес, вызвать

Единственное время простоя - это когда данные перемещаются между серверами и будут меняться в зависимости от того, как перемещаются данные.

Примечание. Если у вас есть межсетевой экран и выполняется NAT, изменение NAT между первичными и временными - хорошая альтернатива обмену IP-адресами и сокращение времени простоя.


4
2018-06-01 20:30





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

Просто будьте в курсе кэшей ARP соседних компьютеров. Хорошая практика использования arping -s  после изменения.


2
2018-06-01 20:01





Если у вас есть Lan-скорость соединения между двумя системами и полным доступом, использование drbd (drbd.org) может быть хорошим вариантом для синхронизации данных между системами до перехода и обратно.

Настройка DRBD и возможность синхронизации
Завершить работу db и веб-сервера
Переключить drbd на исходную машину на вторичную
Переключить drbd на вторую машину на первичный
Изменить исходный IP-адрес сервера
Добавить старый IP-адрес на новый сервер
Приобретите db и веб-сервер на вторичной системе

Переверните их вокруг, когда исходная система перестроена

Возможность использовать репликацию базы данных хороша также, если ваши «данные» в основном относятся к db

Ожидание распространения DNS даже при низком TTL обеспечит «непоследовательные» результаты


1
2018-06-01 19:59





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

http://mysqlbarbeque.blogspot.com/2009/03/how-to-move-your-web-server-with-no.html


1
2018-06-01 20:53





Миграция сервера .. Какая боль.

К счастью, у вас есть все в одном центре обработки данных.

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

Как правило, на моем рабочем месте мы не используем IP-адреса в конфигурациях, мы используем DNS-имена. Но эти имена DNS упоминаются только в / etc / hosts

Это означает, что если нам нужно изменить IP-адрес на что-то, мы просто изменим файл hosts, и все указывает на новое местоположение.

Опять же, это действительно зависит от того, как вы хотите сделать переход - постепенный или нет. Вам, по крайней мере, нужно убедиться, что источники данных и т. Д. И т. Д. На обеих машинах одинаковы, поэтому создайте реплицированное ведомое устройство для базы данных и т. Д. В принципе, когда вы вытаскиваете вилку на одной машине, другая машина должна быть способный взять на себя мгновенно и в том же состоянии. Это хорошая причина для сохранения серверов отдельно. Поэтому не нужно, чтобы на одном сервере выполнялась вся ваша почта, ваши базы данных, ваши веб-приложения и т. Д. Убедитесь, что у вас нет единой точки отказа.

Вот как мы сделали недавнее перемещение сервера (от одного центра обработки данных до другого)

  1. За недели до этого измените TTL на DNS для домена (ов)
  2. Установите новый сервер, убедитесь, что он точно такой же код
  3. Мастер настройки <-> Мастер реплицирован раб в новом датацентре
  4. Укажите все в старом датацентре во время тестирования (туннели SSH - это ваши друг!)
  5. «Переверните переключатель» - запустите скрипт что меняет все на всех серверы (старые и новые) указывают на новых серверах (убедитесь, что вы делаете это все одновременно, или вы можете получить проблемы с репликацией!)
  6. Миграция записей DNS - укажите DNS на новом сервере
  7. Монитор - смотреть старые серверы пока трафик не погаснет.
  8. Декомпозиция старых серверов

Хотя это не совсем полный «удар от удара» всего, что мы делали. Это дает хороший обзор.


1
2018-06-01 20:12





Если у вас есть домен, о котором идет речь, вы можете указать, что TTL для этой записи DNS изменился на более низкое значение вашим администратором DNS (скажем, 3-5 минут). Пусть эта новая настройка распространяется через Интернет в течение нескольких дней, прежде чем вы сделаете свое фактическое изменение IP-адреса DNS. Это должно гарантировать, что любые кэшированные записи DNS будут быстро обновляться после вашего изменения.


0
2018-06-01 19:49



Моя главная проблема здесь в том, что я слышал анекдотические истории о крупных провайдерах, игнорирующих TTL и кеширование в течение нескольких дней или даже недель, но, возможно, я не должен беспокоиться о пользователях в таких сетях. - Steve Madsen
Не обращайте внимания на AOL на свой страх и риск. - chaos


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

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


0
2018-06-01 19:55





Имеет ли ваш сервер публичный IP-адрес на самом сервере. Если есть NAT-привязка, вы можете просто изменить отображение NAT, чтобы иметь тот же самый общедоступный IP-адрес нового внутреннего IP-адреса нового сервера.

Я бы подумал, что часто лучше иметь короткую страницу обслуживания и тестировать, чем нулевое время простоя.


0
2018-06-01 19:58