У меня есть сервер, на котором размещен веб-сайт и другие службы, которые необходимо переустановить. Я хотел бы временно переместить эти службы на другой сервер с минимальным временем простоя. Оба сервера находятся в одном центре обработки данных и могут находиться на одном сетевом коммутаторе.
Как лучше всего переместить эти службы с минимальным временем простоя? Сайт управляется базой данных, поэтому в идеале мне нужно мероприятие «стрелка железной дороги», где я могу обеспечить одновременное перемещение всего трафика на новый сервер. Я не хочу, чтобы старая база данных обновлялась после того, как я перенес данные в новую.
Я рассмотрел две вещи:
Измените DNS, чтобы он указывал на временную службу. Основная проблема здесь в том, что я не контролирую время распространения для DNS, и другие серверы могут некоторое время хранить кешированные результаты, оставляя сайт «неработающим» для пользователей, которые получают старый адрес.
Есть ли способ решить эту проблему с перенаправлением Apache +? Я подозреваю, что нет, поскольку виртуальный хостинг на основе имен не работает без доменного имени, которое я не могу использовать, потому что оно устарело.
Привяжите старый IP-адрес к новому серверу и (временно) назначить старому серверу другой IP-адрес во время переустановки. В этом случае я могу оставить DNS в покое.
Есть ли другие простые решения, которые я упускаю из виду?
Похоже, вам лучше всего подойдет относительно простое решение ... потому что вы можете терпеть некоторое время простоя. Я бы не стал вводить в заблуждение DNS, потому что у вас мало контроля над задержками распространения / кеширования.
1- построить временный сервер
2- отключить службы на основном сервере
3- переместить / скопировать ключевые данные с первичного сервера на временный сервер
4- изменить основной сервер на другой IP-адрес
5- изменить временный сервер на основной IP-адрес, вызвать
6- исправить основной сервер (на другом IP)
7- отключить службы на временном сервере
8- переместить / скопировать ключевые данные с временного сервера на первичный сервер
9- выключить временный сервер
10- измените первичный сервер обратно на первичный IP-адрес, откройте
Единственное время простоя - это когда данные перемещаются между серверами, и будет варьироваться в зависимости от того, как данные перемещаются.
Примечание: если у вас есть брандмауэр и вы используете NAT, изменение NAT между основным и временным является хорошей альтернативой замене IP-адресов и сократит время простоя.
Если к IP-адресу не привязаны другие службы, переключите его. Это не займет много времени, и вы можете быть абсолютно уверены, что трафик идет в нужное место.
Просто помните об ARP-кэшах соседней машины. Хорошая практика - использовать arping -s после изменения.
Если у вас есть соединение со скоростью LAN между двумя системами и полный доступ, использование drbd (drbd.org) может быть хорошим вариантом для синхронизации данных между системами перед переключением и обратно.
Настройте DRBD и дайте ему синхронизироваться
Выключите БД и веб-сервер
Переключите drbd на исходном компьютере на вторичный
Переключите drbd на втором компьютере на основной
Изменить исходный IP-адрес сервера
Добавить старый IP на новый сервер
Поднять БД и веб-сервер во вторичной системе
Переверните их, когда исходная система будет восстановлена
Возможность использовать репликацию базы данных хороша также, если ваши "данные" в основном находятся в db
Ожидание распространения DNS даже с низким TTL приведет к «противоречивым» результатам.
О том, как перенести веб-сервер на другой, я писал в своем блоге. Включает много, в том числе проблемы с базой данных.
http://mysqlbarbeque.blogspot.com/2009/03/how-to-move-your-web-server-with-no.html
Перенос сервера .. Какая боль.
К счастью, у вас все в одном центре обработки данных.
Однако на самом деле это зависит от того, какие у вас есть приложения и т. Д., И убедитесь, что вы настроили их все на новом устройстве.
Обычно на моем рабочем месте мы не используем IP-адреса в конфигурациях, мы используем DNS-имена. Но эти DNS-имена всегда упоминаются только в / etc / hosts.
Это означает, что если нам нужно изменить IP-адрес для чего-то, мы просто меняем файл hosts, и все указывает на новое местоположение.
Опять же, это действительно зависит от того, как вы хотите переключиться - постепенно или нет. Вам, по крайней мере, необходимо убедиться, что источники данных и т. Д. Точно такие же на обеих машинах, поэтому создайте реплицированный подчиненный сервер для базы данных и т. Д. И т. Д. В принципе, когда вы отключаете одну машину, другая машина должна возможность взять на себя управление мгновенно и в том же состоянии. Это хороший повод держать серверы отдельно. Поэтому не создавайте на одном сервере всю вашу почту, базы данных, веб-приложения и т. Д. Убедитесь, что у вас нет единой точки отказа.
Вот как мы недавно перенесли сервер (из одного центра обработки данных в другой)
Хотя это не совсем «удар за ударом» всего, что мы сделали. Это дает хороший обзор.
Если вы являетесь владельцем рассматриваемого домена, вы можете изменить TTL для этой записи DNS на более низкое значение администратором DNS (скажем, 3-5 минут). Дайте этой новой настройке распространиться по Интернету в течение нескольких дней, прежде чем вы действительно измените IP-адрес DNS. Это должно гарантировать, что любые кэшированные записи DNS будут быстро обновляться после вашего изменения.
Вы правы, что переключение DNS совершенно ненадежно. Я предпочитаю одновременно с изменением DNS переключить конфигурацию базы данных старого сайта, чтобы он подключался к базе данных нового сервера. Тада, все твои обновления собираются в одном месте.
Сайт, вероятно, будет работать медленнее для людей, которые подключаются к старому серверу, конечно, но это будет длиться только до тех пор, пока они не синхронизируются.
Есть ли у вашего сервера общедоступный IP-адрес на самом сервере. Если есть сопоставление NAT, вы можете просто изменить сопоставление NAT, чтобы та же общедоступная IP-точка была связана с новым внутренним IP-адресом нового сервера.
Я думаю, что лучше иметь короткую страницу обслуживания и тестирование, чем нулевое время простоя самому.
Используйте репликацию на своих серверах баз данных. Это решит вашу проблему с обновлением баз данных на обоих серверах в промежуточное время.
В идеале вы устанавливаете TTL записи хоста DNS на пару дней раньше запланированного времени, но если у вас нет контроля над этим (или вы не можете работать с кем-то в этом направлении), тогда все готово.
Если нет, то единственное, что действительно нужно сделать - это построить новый сервер до тех пор, пока он не будет готов к производству, а затем запланировать несколько минут простоя, пока вы отключаете коробки ...