После того, как мне попались на глаза рассказы о переезде информационной инфраструктуры компании с места на место, я подумал, что переезд среднего контентного интернет-проекта с одной площадки на другую — тоже довольно интересная тема. Особенно интересно то, как сделать это с минимальными перебоями в работе.
Речь идёт, конечно, не о мегапортале с двумя самосвалами железа, а о средних размеров проекте, когда серверов немного, все они скорее арендуются, нежели находятся в вашей собственности, или же у вас есть достаточный запас ресурсов для того, чтобы перебросить часть серверов на новое место.
Наверняка, есть способы как сделать это лучше в тех или иных условиях, однако изложу свои соображения на эту тему. Уверен, что как обычно это происходит, кто-нибудь дополнит изложенное своим ценным опытом.
Рассказ рассчитан на подготовленную аудиторию и не является точным пошаговым руководством к действию.
Итак, имеется типичный «джентельменский набор»:
Весь проект может «жить» на одном сервере или на нескольких, пользовательские файлы могут хранится как на фронтенде, так и на отдельном сервере.
В случае переезда между арендуемыми серверами чаще всего удаётся договориться с новым хостером о тарификации только с начала нового месяца, так чтобы вы могли при этом ввести в строй оборудование и перенести данные.
Таким образом, простой сервиса при переносе можно сократить по крайней мере до времени создания дампа базы. Хорошо если сервер базы уже настроен для репликации, если нет, придётся сделать и это.
Весь процесс делится на две части: первая — создание актуальной копии ресурса на новой площадке, вторая — плавное перенаправление трафика, обусловленное постеменным обновлением кеширующих DNS-серверов.
Код, шаблоны и прочее в хорошем случае переносятся простым действием:svn co svn://my.repository.ru/myproject/trunk .
Итак, нужно открыть два соединения с рабочим сервером базы данных, в одной консоли написать flush tables with read lock, в другой запустить mysqldump c нужными параметрами. Этот момент и подразумевается моментом простоя, так как скорее всего в это время ваш проект может работать некорректно в силу read-блокировки(только чтение) всех таблиц, вероятно, на это время вам придётся повесить «заглушку» (bonnie создаёт полный дамп суперхабра примерно за 58 секунд). После того, как копия базы будет готова, в первой консоли пишем show master status и запоминаем полученные значения (текущее имя файла бинарного лога и позиция в нём) в какое-нибудь безопасное место. Затем просто закрываем консоль, что снимает блокировку таблиц или выполняем unlock tables.
Полученный файл архивируем и переносим на новую площадку. Там, на новом, ещё пахнущим заводом серверов, сервере, создаём базу и восстанавливаем в неё данные. Затем делаем из этого сервера клиента репликации базы со старой площадки и инициализируем репликацию с полученного ранее места: change master to master_log_file='server1-relay-bin.00025', master_log_pos=350384183; start slave;
Если вы знакомы с репликацией и всё сделали правильно, то через несколько минут у вас будет «живая» актуальная копия базы на новом месте. В большинстве случаев трафик между разными площадками передаётся с достаточной скоростью, чтобы все «пишушие» запросы успели попасть от сервера к серверу без очередей и задержек.
Примечание: этот пункт можно опустить чем полностью исключить перебой в работе, если у вас уже есть слейв-сервер, который вы можете перенести на новое место.
Пользовательские файлы очень удобно перемещаются с помощью rsync (man rsync). При начальной подготовке можно скопировать полный набор хранилища, а во время запуска запустить синхронизацию снова, для того, чтобы синхронизировать изменения: обновить изменившиеся файлы и перенести новые.
Теперь решающий и самый интересный момент. Когда у вас уже есть две работающие копии проекта, прежде чем вносить изменения в DNS, нужно «замкнуть» одну площадку на другую. Сделать это можно при помощи родных возможносней nginx, а именно: его проксирующего модуля. То есть попросту осуществить проксирование всех запросов на новый сервер через старый(снова дурацкая тавтология, когда же конец?): proxy_pass httр://new.server.ip:80/.
Если всё работает нормально, можно обновлять файл DNS-зоны (перенести DNS-сервера каждый, думаю, может на свой лад). С этого момента одна часть обращений будет прозрачно обрабатываться старыми серверами, другая часть новыми. Разумеется, вторая часть будет расти по мере обновления записей кеширующих серверов, а первая примерно через сутки сойдёт на нет.
Как только вы почувствуете, что старые сервера более не нужены, можно отключить или перенастроить репликацию так, как вам нужно и заявить старому хостеру о том, что более он от вас не получит ни рубля.
Речь идёт, конечно, не о мегапортале с двумя самосвалами железа, а о средних размеров проекте, когда серверов немного, все они скорее арендуются, нежели находятся в вашей собственности, или же у вас есть достаточный запас ресурсов для того, чтобы перебросить часть серверов на новое место.
Наверняка, есть способы как сделать это лучше в тех или иных условиях, однако изложу свои соображения на эту тему. Уверен, что как обычно это происходит, кто-нибудь дополнит изложенное своим ценным опытом.
Рассказ рассчитан на подготовленную аудиторию и не является точным пошаговым руководством к действию.
Вступление
Итак, имеется типичный «джентельменский набор»:
- Nginx — фронтенд сервер, за ним Apache или FastCGI
- Сервер базы данных — MySQL
- Сервера в новом датацентре — достойная замена серверам текущего хостера, который уже испытал ваше терпение до последне��о предела
Весь проект может «жить» на одном сервере или на нескольких, пользовательские файлы могут хранится как на фронтенде, так и на отдельном сервере.
В случае переезда между арендуемыми серверами чаще всего удаётся договориться с новым хостером о тарификации только с начала нового месяца, так чтобы вы могли при этом ввести в строй оборудование и перенести данные.
Таким образом, простой сервиса при переносе можно сократить по крайней мере до времени создания дампа базы. Хорошо если сервер базы уже настроен для репликации, если нет, придётся сделать и это.
Весь процесс делится на две части: первая — создание актуальной копии ресурса на новой площадке, вторая — плавное перенаправление трафика, обусловленное постеменным обновлением кеширующих DNS-серверов.
Код
Код, шаблоны и прочее в хорошем случае переносятся простым действием:
База
Итак, нужно открыть два соединения с рабочим сервером базы данных, в одной консоли написать flush tables with read lock, в другой запустить mysqldump c нужными параметрами. Этот момент и подразумевается моментом простоя, так как скорее всего в это время ваш проект может работать некорректно в силу read-блокировки(только чтение) всех таблиц, вероятно, на это время вам придётся повесить «заглушку» (bonnie создаёт полный дамп суперхабра примерно за 58 секунд). После того, как копия базы будет готова, в первой консоли пишем show master status и запоминаем полученные значения (текущее имя файла бинарного лога и позиция в нём) в какое-нибудь безопасное место. Затем просто закрываем консоль, что снимает блокировку таблиц или выполняем unlock tables.
Полученный файл архивируем и переносим на новую площадку. Там, на новом, ещё пахнущим заводом серверов, сервере, создаём базу и восстанавливаем в неё данные. Затем делаем из этого сервера клиента репликации базы со старой площадки и инициализируем репликацию с полученного ранее места: change master to master_log_file='server1-relay-bin.00025', master_log_pos=350384183; start slave;
Если вы знакомы с репликацией и всё сделали правильно, то через несколько минут у вас будет «живая» актуальная копия базы на новом месте. В большинстве случаев трафик между разными площадками передаётся с достаточной скоростью, чтобы все «пишушие» запросы успели попасть от сервера к серверу без очередей и задержек.
Примечание: этот пункт можно опустить чем полностью исключить перебой в работе, если у вас уже есть слейв-сервер, который вы можете перенести на новое место.
Пользовательские файлы
Пользовательские файлы очень удобно перемещаются с помощью rsync (man rsync). При начальной подготовке можно скопировать полный набор хранилища, а во время запуска запустить синхронизацию снова, для того, чтобы синхронизировать изменения: обновить изменившиеся файлы и перенести новые.
Перевод стрелок
Теперь решающий и самый интересный момент. Когда у вас уже есть две работающие копии проекта, прежде чем вносить изменения в DNS, нужно «замкнуть» одну площадку на другую. Сделать это можно при помощи родных возможносней nginx, а именно: его проксирующего модуля. То есть попросту осуществить проксирование всех запросов на новый сервер через старый(снова дурацкая тавтология, когда же конец?): proxy_pass httр://new.server.ip:80/.
Если всё работает нормально, можно обновлять файл DNS-зоны (перенести DNS-сервера каждый, думаю, может на свой лад). С этого момента одна часть обращений будет прозрачно обрабатываться старыми серверами, другая часть новыми. Разумеется, вторая часть будет расти по мере обновления записей кеширующих серверов, а первая примерно через сутки сойдёт на нет.
Как только вы почувствуете, что старые сервера более не нужены, можно отключить или перенастроить репликацию так, как вам нужно и заявить старому хостеру о том, что более он от вас не получит ни рубля.
