Задача: перенести работающий проект с одного сервера на другой.
У нас есть:
рабочий сервер, новый сервер настроен и настроен под проект. Я не буду углубляться в тонкости настройки сервера, так как это в принципе может быть любой сервер под любой ОС.Главное, чтобы у вас был полный доступ ко всей системе.
Те.
права администратора.
А также сервер должен быть готов принять посетителей в любое время.
Те.
должны быть настроены виртуалки, установлена СУБД, WEB-сервер и т.д.
Первый способ прост:
Вешаем на рабочий сервер страницу с надписью «Переезжаем, заходите завтра» и поехали! На самом деле, лучше всего начать со скриптов.Было бы идеально, если бы у вас был SVN или CVS. В этом случае скрипты можно загрузить в один клик.
В принципе, по FTP тоже можно легко загрузить, но если нужно что-то подправить и быстро перезалить, то загрузить все измененные файлы впопыхах может быть немного проблематично, особенно если они разбросаны по разным каталогам.
После загрузки скриптов зайдите в базу данных.
Если ваша база данных размером не гигабайт/терабайт, то можно попробовать сделать тестовую базу и загрузить туда весь дамп.
Если дамп все равно очень большой, то в тестовую базу можно загрузить только структуру и необходимые таблицы (чтобы система «запустилась») и протестировать на ней.
Это необходимо для промежуточного тестирования перед открытием сайта для посетителей.
Помимо тестовой базы создайте рабочую и залейте туда весь дамп, но использование тестовой базы оставьте в настройках.
Виртуальный хост. Его следует настроить так, чтобы он мог работать с двумя разными доменами.
За что? Опять же для тестирования.
Например, ваш сайт site.com сейчас закрыт, но вам нужно убедиться, что на новом сервере все будет хорошо? Вот почему вам нужен второй домен.
Где его взять – второй вопрос.
Если у вас нет поддоменов, вы можете временно добавить test.site.com и зарегистрировать его на новом сервере.
Ну или просто прописать любой домен в хостах (в вашей ОС) и все должно работать.
Также следует отметить, что ваши скрипты должны быть правильно настроены для этого домена (если, конечно, они не привязаны к доменам).
Переполнение контента.
Если на вашем сайте есть пользовательский контент, его также необходимо перенести на новый сервер.
Вы можете сделать это по-разному в зависимости от вашей ОС и ваших навыков.
Я не буду подробно останавливаться на этой, в общем-то, тривиальной задаче.
Если все прошло успешно, попробуйте войти в тестовый домен.
В этом случае при правильной настройке сайт должен работать корректно.
Сделайте полную проверку системы - зарегистрируйте пользователя, проверьте отправку почты, загрузку файлов, сервисы, cron, демоны и т.д. если все хорошо, переключите скрипты на реальную базу и можно менять DNS (IP реального домена) .
По мере обновления DNS-серверов на ваш новый сервер будет приходить все больше и больше новых посетителей.
Не забудьте удалить страницу с надписью о новом сервере.
Ей здесь вообще ничего не нужно :) Примерное время – от 30 минут до 3-4 часов (без учета времени обновления DNS) Дальше веселее.
Второй способ — перейти на лету, не закрывая сайт.
Более сложный и требует изменения скриптов, а также настройки репликации базы данных.И некоторые манипуляции с системой.
Это также требует больше времени и хороших навыков системного администрирования.
Лучше это делать вместе с системным администратором.
Начало то же, что и в первом случае – настройка виртуальных систем, СУБД, WEB-сервера и т.д. Просто сайт не закрываем! Пусть посетители гуляют. Далее, для большего удовольствия, редактируем скрипты.
Нам нужно добавить глобальную константу, которая будет содержать момент времени, с которого начнется наше перемещение.
Мы будем полагаться на эту константу во многих местах проекта, поэтому она должна быть видна везде.
Хочу отметить, что эта константа нужна только в том случае, если система использует пользовательский контент. Например, пользователи загружают картинки, аватарки, музыку и т. д. В этом случае нам нужно знать, в какой момент мы начинаем движение и новый контент должен быть загружен на новый сервер, а старый должен остаться там, где он есть.
Если мы просто начнем копировать текущий контент на новый сервер, то никто не даст нам гарантии, что пока мы все копируем, ничего нового не появится.
Возможно, кто-то уже догадался, что нужно сделать с константой.
Но объясню подробнее - например, мы должны начать движение в 00:00:00 01.03.2009. На этом этапе весь пользовательский контент должен храниться на старом сервере, после этого — на новом.
Для этого вам придется редактировать скрипты во всех местах загрузки контента.
Нам нужно добавить проверку времени и если время сервера меньше постоянного времени, оставить контент там, где он есть; если больше, загрузите на новый сервер.
Заполнение может осуществляться различными способами.
Вы можете смонтировать NFS или drbd (под *nix).
Вы можете загружать контент через FTP, SCP или другими способами.
Разумеется, вас должна волновать безопасность и стабильность системы, поэтому выбор средства доставки контента опять же зависит от конкретной ситуации.
Но как узнать, какой контент и где находится? И как отделить новый контент от старого? Хорошо, если у вас есть время на добавление контента, хранящегося в вашей базе данных - это значительно упрощает задачу, но если это не так.
то нужно исходить из текущей ситуации - если СУБД поддерживает глобальные идентификаторы объектов (OIDs ), то вы можете использовать их для получения первого идентификатора после указанной даты (опять же автоматически) или попытаться получить идентификатор для каждой таблицы, где содержимое хранится отдельно, и привязаться к ним.
Например, мы решили эту проблему.
Что дальше? Далее нам нужно настроить дополнительный домен для нового сервера.
Например, пусть вашим сайтом будет тот же site.com, а для доступа к контенту используйте поддомены: video.site.com, audio.site.com и т. д. Это тоже облегчит нам жизнь.
Добавляем поддомен: new.site.com и регистрируем в нем все наши поддомены: video.new.site.com, audio.new.site.com или наоборот — для каждого поддомена регистрируем еще один: new.video. site.com, new.audio.site.com и т.д. главное, чтобы они указывали на новый сервер и по этому адресу был новый контент. И осталось только заменить все ссылки на контент в зависимости от нашей константы — т.е.
даты Х, некоторые ссылки будут указывать на новый контент, а некоторые — на старый.
Если ваши пути прописаны в одном месте и доступны глобально, то заменить ссылки на лету не составит большого труда, а если все ссылки прибиты к шаблонам.
ну вы сами понимаете, кто вы сейчас :) Но не все так просто, как кажется.
Вам придется исправлять все места отображения контента.
Их, к сожалению, может быть много.
Хорошо, если у вас хорошая архитектура проекта и все сущности имеют классы с методами получения объектов из базы данных.
Можно примерно на некоторое время вписаться в эти методы и проверить там.
Например, вы получаете аудиообъект только в методе получения класса Audio. В этом случае вы можете добавить к этому методу собственную проверку и изменить базовый URL-адрес.
Но если ваша страница содержит список старого и нового контента, вам придется редактировать шаблон специально для этой страницы.
страница.
Чтобы избежать такой ситуации, добавьте в таблицы контента всего одно поле (об этом лучше подумать на этапе архитектуры), в котором будет указано, откуда брать этот контент. Например, поле Storage (smallint) содержит 1,2,3. и в шаблонах вы просто подставляете нужный URL исходя из этого - для 1 - vid1.site.com, для 2 - vid2.site.com, и т. д. Также рекомендуется сделать нечто подобное для распределения контента по нескольким серверам в высоконагруженном рабочем проекте.
Но это уже другая история.
УПД: В некоторых случаях этих танцев с благом можно избежать с помощью проксирования — все запросы на контент отправляются на новый сервер и там, если контент не найден, проксируются на старый.
Спасибо мгык за чаевые.
Итак, на данный момент мы решили проблему с раздачей контента и подстановкой правильных ссылок в зависимости от постоянной времени.
Дальше база.
Проблема та же — нужно иметь возможность использовать 2 базы данных параллельно.
Очень хорошо, если у вас уже есть кластер.
С его помощью мы решаем одну важную проблему — у нас есть сервер репликации.
Если этот сервер поддерживается мастер-мастером и еще можно добавлять сервера на лету, то это просто супер.
Все что нам нужно — это создать безопасный канал между серверами и настроить репликацию через него.
На живом сервере поднимаем мастер, настраиваем репликацию с нашим рабочим сервером и он скачивает (по крайней мере должен) сам всю базу + постоянно поддерживает ее в актуальном состоянии, что очень важно.
На данный момент он работает как «ведомый», т.е.
только синхронизируется с основной базой данных.
Если сервер репликации не установлен на основном сервере, вам придется его установить.
Во время установки, возможно, придется перезапустить СУБД, что может вызвать перебои в работе сайта.
Так что лучше потренироваться «на кошках», т. е.
где-нибудь еще.
Если репликация невозможна, то мы зашли в тупик.
Возможно, многие скажут, что репликация — не лучший способ.
Да, это может быть правдой.
Это немного замедлит работу и в реальном времени загрузит всю систему, но это действительно продлится недолго.
Всего на несколько часов, пока вы не загрузите основной контент и не обновятся все DNS. У меня это заняло не более 30 часов.
Итак, рассмотрим проблему с закрытой базой данных.
Настраивается и синхронизируется нормально.
Осталось совсем чуть-чуть, совсем чуть-чуть, потерпи.
Ваш сайт уже стоит на другом сервере :) Начнем плавный переход — добавим IP нового сервера в ваш основной домен.
По мере обновления зоны к вам на новый сайт будут приходить пользователи.
Начинать это делать нужно после того, как наступит заветная дата.
Также убедитесь, что весь новый контент со старого сервера загружен на новый и база данных работает как надо.
Теперь она может замедлиться.
Все зависит от канала, но если вы не храните в нем картинки, музыку, видео и т.д., то синхронизация не будет раздражать.
Как только вы убедитесь, что все идет как надо, начните загружать старый контент. Просто сделайте копию.
Не волнуйтесь, он не изменится.
Конечно, если все работает как надо.
Как только весь контент будет загружен, удалите старый IP из домена.
Должен остаться только новый.
По мере обновления зоны все пользователи перейдут на новый сервер.
Примерно через сутки на старом сервере в виртуальном домене на всякий случай зависнет страница с просьбой обновить кэш DNS. Это если у кого-то оно закешировано.
Остановите сервер репликации на новом сервере.
Загружайте старые скрипты без проверок.
Если все в порядке – поздравляем – вы на новом сервере.
Если что-то пошло не так, это не моя вина :) Не спешите останавливать старый сервер и отдавать его хостеру.
Подождите еще пару недель.
Если что-то не перенеслось, у вас останется старая копия и вы сможете восстановить данные.
Также будьте осторожны при внесении изменений в скрипты — они не должны пытаться загрузить контент на новый сервер.
Для этого необходимо провести дополнительную проверку относительно их местонахождения.
Например, добавить какой-нибудь файл, который будет только на новом сервере, и если он там есть, значит не отправлять контент. Собственно, это все.
Спасибо за внимание и приглашение, надеюсь, это кому-то поможет. Теги: #сервер #переезд #репликация #Распределенные системы #Чулан
-
Доход Фидонета На Android
19 Oct, 24 -
Куда Течет Ток Или Где Этот Проклятый Катод?
19 Oct, 24 -
История Датчиков Движения
19 Oct, 24 -
Встреча 25 Апреля. Гонка Rad
19 Oct, 24 -
Новый Шаг Яндекса В Борьбе С Продажей Ссылок
19 Oct, 24 -
Рисование Графиков Онлайн
19 Oct, 24
