Этот пост — еще одна часть нашего списка коротких постов, в которых описываются конкретные случаи, с которыми сталкивался OVHcloud как при подготовке к миграции, так и во время нее. Здесь мы рассказываем историю о том, как иногда небольшое неожиданное поведение может привести к исправлению ошибки в программном обеспечении, используемом миллионами людей по всему миру.



В этом посте я объяснил, как нам пришлось продвинуть proxySQL за его пределы.

Жюльен объяснил здесь, насколько сложно перехватить часть программы и заставить ее работать для очень специфического случая использования. Один настолько специфический, что мы просто не могли продвинуть его вверх по течению, поскольку мы нарушали некоторые предположения в базовом коде (что-то вроде «смотри, мы не используем это, может быть, мы можем отклонить его, чтобы он соответствовал нашему использованию»).

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

Вот два реальных случая, когда у нас было неожиданное поведение ProxySQL, в результате чего появился патч для MariaDB / MySQL.

1. Важность цитирования

Неожиданное поведение

Когда мы впервые начали использовать ProxySQL, у нас было неожиданное поведение. ProxySQL раньше зависал. Ни предупреждения, ни предвестника. Зависание означает, что ProxySQL не может обрабатывать ваши запросы, в результате чего ваши веб-сайты становятся недоступными.

Копать

Системные администраторы знают, что в случае сомнений проверяйте журналы. Вот что мы сделали и заметили вот это:

[ОШИБКА] Обнаружено разорванное соединение во время SET NAMES на 192.168.59.272, 3306: 2019, Невозможно инициализировать набор символов (null) (путь: compiled_in)

ОШИБКА 1064 (42000): у вас есть ошибка в синтаксисе SQL; проверьте руководство, которое соответствует вашей версии сервера MySQL, чтобы найти правильный синтаксис для использования рядом с «двоичным» в строке 1

Это явно ошибка, возвращенная сервером MySQL. Поскольку эта строка журнала была создана на ProxySQL, это означает, что ошибка произошла между нашим ProxySQL и сервером MySQL.

В поисках золота

Жюльен много работал — он прочитал тонны журналов, отследил множество PID и отследил проблему вплоть до ИСПОЛЬЗОВАНИЯ триггерного случая, выполнив эту команду:

set names binary COLLATE binary;

Сопоставление — это своего рода набор правил для сравнения строк. Он может определять, например, при сортировке по алфавиту, если Aидет раньше a, éследует ли рассматривать как eили нет, или где œдолжно быть в алфавите.

Вы можете узнать больше об этом в Базе знаний MariaDB.

Исправление

Отправив сообщение об обнаруженной нами проблеме в системе отслеживания ошибок ProxySQL и предложив исправление, автор ProxySQL взглянул и подтвердил ошибку.

При написании ProxySQL Рене Канна делал то же, что и все разработчики, — следовал документации коннектора MariaDB. И ошибка была отсюда:

According to the documentation on SET NAMES syntax (https://dev.mysql.com/doc/refman/5.7/en/set-names.html) :

charset_name and collation_name may be quoted or unquoted

This doesn't seem true for "SET NAMES binary COLLATE binary" , that requires the collation name to be quoted.

(https://bugs.mysql.com/bug.php?172id=93692)

Эффект бабочки

Итак, из-за зависания нашей инфраструктуры мы сообщили об ошибке создателю проекта, который затем отследил ее до ошибки в коннекторе MariaDB, проследил ее до родительского MySQL и исправил в восходящем направлении. Ошибка была закрыта в начале 2020 года.

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

2. Когда провода перекрещиваются

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

Неожиданное поведение

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

MySQL_Session.cpp:2964:handler(): [WARNING] Error during query on (42,192.168.59.272,3306): 1267, Illegal mix of collations (utf8_general_ci,IMPLICIT) and (dec8_swedish_ci,COERCIBLE) for operation '='

Копать

Конечно, в первую очередь мы проверили, что мы используем настоящую и допустимую кодировку и соответствующее сопоставление. Мы дважды и трижды проверили, что нам разрешено использовать dec8_swedish_ci.

Мы решили взглянуть на исходный код коннектора.

В поисках золота

Если вам интересно, вы можете взглянуть на более старые версии кода libmariadb / my_charset.c, начиная со строки 541. Вы заметите, что dec8_swedish_ci нигде не найти. Но если вы присмотритесь, вы заметите dec8_swedisch_ci. Дорогие друзья из Швеции, опечатка была сделана не только вами.

Исправление

При устранении проблемы с экзотическими кодировками мы применили специальный патч к нашей собственной сборке ProxySQL. Сгоряча, мы отложили сообщение об ошибке.

Мы разделили репозиторий GitHub mariadb-corporation / mariadb-connector-c , исправили несколько опечаток и предложили запрос на перенос, который затем был объединен в середине февраля.

Эффект бабочки

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

Вывод

Как ведущий поставщик веб-хостинга в Европе, мы сталкиваемся с законом действительно больших чисел ( en.wikipedia.org/wiki/Law_of_truly_large_numbers ). TL; DR: произойдет каждое событие с ненулевой вероятностью.

У нас размещено более 1,3 миллиона веб-сайтов. Предположим, что 0,0001% наших клиентов могут вызвать одну конкретную ошибку — у нас есть по крайней мере 1 клиент, который ее вызовет. Вопрос не в том, если, а в том, когда нам придется с этим бороться и как это сделать.

Хотите знать, как мы заметили, что попали в Закон действительно больших чисел? Следите за обновлениями, ведь мы скоро напишем об этом.

Поделиться заботой

OVHCloud любит открытый исходный код и любит делиться. Это не первый раз, когда мы вносим свой вклад в мир открытого исходного кода, и определенно не последний.

Как подробно объяснялось в предыдущем посте, миграция P19 означала, что нам нужно было добавить новый элемент в нашу инфраструктуру… а именно ProxySQL.



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

Подключение баз данных 101

Вернемся к тому, как пользователь подключается к своей базе данных MySQL / MariaDB без ProxySQL…

Пользователь использует клиент MySQL и предоставляет хост / IP, имя пользователя и пароль.



С этой точки зрения все кажется довольно простым. Но в реальной жизни все не так просто…

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

Однако нам повезло, так как клиенты и серверы MySQL имеют хороший уровень обратной совместимости.

Так что же тогда?



Теперь мы ближе к реальности.

А теперь давайте добавим к этой картинке нашего маленького друга ProxySQL!

Первые часы жизни ProxySQL в OVHcloud

ProxySQL — очень хорошая и полезная программа. Его основная задача — установить соединение с вашей базой данных от вашего имени. Таким образом, устанавливается соединение, ProxySQL просматривает базу данных в своей конфигурации, проверяет учетные данные, предоставленные пользователем, и, если они действительно действительны, действует как клиент MySQL для подключения к фактическому серверу MySQL.



С этой точки зрения все кажется довольно простым. Но в реальной жизни все не так просто… Погодите, я уже это говорил?

Добавим в эту картину наше полное разнообразие, просто для удовольствия! Помните наши версии MySQL? Были упомянуты две конкретные версии…

MySQL5.6

Это последняя версия на OVHcloud. Что интересно в этой конкретной версии, так это то, что механизм аутентификации является последним и лучшим из MySQL. Он генерирует 41-байтовый хэш, изменение, которое было введено в MySQL 4.1.

Фактическая версия, которая была у нас в P19, была MySQL5.5, но эти две версии очень похожи с практической точки зрения.

MySQL5.1

Довольно старый материал, но у нас все еще есть экземпляры, которые его используют.

Некоторые клиенты, использующие эту версию, перешли с MySQL4.0 и сохранили пароли, сгенерированные этой версией. Для простоты мы будем называть их « MySQL5.1 со старыми паролями ». В этой версии используется 16-байтовый хэш, который является слабым и подверженным перехватам.

Так что же тогда?



Вот и мы! Путь нашего ProxySQL проходит не так гладко, поскольку он не может аутентифицироваться в MySQL 4.0. В этом есть смысл, поскольку он был написан спустя много времени после того, как была прекращена поддержка MySQL 4.0.

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

Под капотом: история подключения к MySQL

Как мы подчеркнули ранее, для подключения к серверу MySQL необходимо предоставить три параметра:

• Хозяин (скажем, 

  mysqlXXX.sqlXXX

  )
• Пользователь
• Пароль

Интересная часть здесь — это пароль, так как он изменился между двумя версиями.

Очевидно, что MySQL не хранит ваш пароль в виде обычного текста, а вместо этого хранит хэш. Чтобы позволить ProxySQL подключиться, хеш вставляется в его внутреннюю базу данных, после чего подключение становится возможным.

Существуют три типа паролей:

• Простой текст

• mysql_native_password

   (41-байтовый хеш)

• old_password

   (16-байтовый хеш)

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

Каковы наши пути решения?

Самым простым решением было бы, как вы понимаете, обновить пароли для использования нового алгоритма.

Однако мы не храним ваши пароли!

В некоторых случаях нам удавалось вычислить это, но с учетом значительного числа клиентов, столкнувшихся с этой проблемой (более 50 000… помните 1% из более чем одного миллиона?), Это было невозможно.

Первым шагом было научить наш ProxySQL обрабатывать соединение от клиента. Спустя несколько патчей наш ProxySQL гордился своей новой функцией и мог выполнять эту задачу.

Представим это на картинке:



Но мы определенно не хотели хранить эти старые пароли навсегда… поэтому нам пришлось вести себя гадко.

Помните, что единственная информация, которая у нас была, — это устаревший хешированный пароль, который был единственным источником информации, который мы могли передать ProxySQL. Чтобы упростить ситуацию, вот ситуация, в которой мы находимся:



Нам нужно было дать нашему клиенту ProxySQL пароль, но мы не смогли добавить старый пароль (да и не хотели!).

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



Поскольку клиент ProxySQL и сервер MySQL скрыты от пользователя, все было нормально, но мы не могли этого сделать на сервере ProxySQL (вы же хотите сохранить тот же пароль, верно?).

К счастью для нас, у нас было поле пароля в виде обычного текста, которое осталось неиспользованным, поэтому мы могли использовать его для хранения вашего OLD_HASH и завершения цепочки аутентификации.



Мы сделали это! Наконец-то вы можете получить доступ к своей базе данных!

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

Вывод

Трудно поддерживать широкий спектр программного обеспечения с несовместимыми версиями!

Чтобы убедиться, что миграция оказала минимальное влияние, нам пришлось исправить множество мелких деталей. В конкретном случае, подробно описанном в этой статье, у нас были проблемы со старыми паролями MySQL, и, учитывая временную шкалу, мы не могли попросить пользователей MySQL5.1 изменить свои пароли. Но после небольшого взлома мы смогли начать миграцию… даже для устаревшей аутентификации!

Опять же, это была лишь одна из проблем, с которыми мы столкнулись при настройке ProxySQL и адаптации его к нашим очень специфическим требованиям. Помните, что работа с устаревшим программным обеспечением — сложная и ответственная задача, но ее невозможно избежать! Это то, что мы сделали с переходом на P19, и что мы будем продолжать делать, чтобы постоянно улучшать предлагаемые вам услуги.

В наших предыдущих статьях мы объяснили, почему нам пришлось перенести 800 000 баз данных из одного центра обработки данных в другой, на расстоянии 300 километров. Итак, мы… Мы сделали это! Теперь мы сосредоточимся на очень важной цели любой миграции. С вашей точки зрения, как покупатель, вы должны видеть… Ничего! Я полностью это понимаю, так как я также являюсь клиентом OVH. И как клиент, оплачивающий услугу, я хочу, чтобы она работала, независимо от того, что делают люди за кулисами.



В этом посте мы увидим, как нам удалось (почти) легко переместить их всех…

Основы

Как веб-сайт подключается к базе данных, размещенной на другом сервере? Краткий ответ: по сети. Поскольку диаграмма всегда лучше, чем длинный ответ, вот упрощенное представление о том, как она работает…

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

$database_server = 'mydatabase.mysql.db';
$database_name = 'mydatabase';
$database_user = 'mydatabase';
$database_password = 'correct horse battery staple';
# ref: https://www.xkcd.com/936/

Затем он начинает диалог с сервером доменных имен (DNS), чтобы получить IP-адрес mydatabase.mysql.db. Как только IP известен, веб-сервер может взаимодействовать с сервером базы данных.



Но наличие одного сетевого имени для каждой базы данных — это что-то относительно новое в истории OVH. Впервые он был представлен пять лет назад, а здесь описана архитектура Gravelines.

20-летнее наследие

Вначале мы давали нашим клиентам IP-адрес сервера базы данных.

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

$database_server = '10.0.59.42';
$database_name = 'mydatabase';
$database_user = 'mydatabase';
$database_password = 'correct horse battery staple';
# ref: https://www.xkcd.com/936/

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



Итак, чтобы упростить управление сервером, окончание срока службы оборудования и т. Д., OVHcloud перешла на предоставление нашим клиентам имени сервера вместо IP-адреса сервера.

$database_server = 'mysql55-59.pro';
$database_name = 'mydatabase';
$database_user = 'mydatabase';
$database_password = 'Brussels Sprouts Mandela Effect';
# ref: https://www.xkcd.com/2241/

Подводя итог, у нас есть три способа подключения к базе данных в P19:

• Использование IP сервера
• Использование имени сервера
• Использование имени базы данных

Блокиратор

Следуя правилам, описанным здесь, поскольку мы перемещали ваши базы данных по отдельности, а не весь сервер за раз, а базы данных перетасовывались во все наши новые экземпляры, а не оставались с их соседом, мы не могли повторно использовать IP-адрес сервера. Кроме того, мы не могли повторно использовать имя сервера.

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

Значит, нам пришлось бы:

• Разбирайте сотни терабайт. Выполнимо, но требует много времени.
• Разберитесь в организации вашего сайта. Это можно автоматизировать для 99% всех различных случаев использования, но 1% из 1,5 млн веб-сайтов по-прежнему представляют собой 15 000 потенциально поврежденных веб-сайтов после замены.
• Замените IP или имя сервера именем базы данных. Возможно, но не на 100% надежно.

Что, если заказчик:

• Использует свою базу данных в двоичном файле, например, скомпилированный CGI, написанный на C? Не разбирается.
• Использует другую базу данных, чем та, на которую есть ссылка? Как мы узнаем, что нужно использовать?
• Не пользуется своей базой? Как мы узнаем, что это действительно правильный результат, если ничего не нашли?

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

Если конфигурация была:

• mydatabase.mysql.db: Нет проблем. DNS был обновлен.
• имя_сервера: запрос достигнет сервера и его нужно будет перенаправить.
• IP-адрес сервера: запрос достигнет сервера и его необходимо будет перенаправить.

Решение

Может быть, некоторые из вас уже начали искать решение…

Нам требовалось программное обеспечение, которое маскировалось бы под сервер, но фактически перенаправляло входящие соединения на реальный сервер, стоящий за ним. Другими словами, прокси!

Мы решили использовать proxySQL Рене Канна.

ProxySQL более или менее разработан для небольшого количества пользователей и небольшого количества баз данных, в основном для разделения доступа только для чтения и чтения-записи на разных серверных модулях, что может значительно помочь базе данных с небольшим количеством операций записи и поддержкой большого количества операций чтения. Загрузка. Это также может помочь в синтаксическом анализе и защите запросов. Но использование его для наших целей доводило его до предела. Надо сказать, этот продукт потрясающий!

Сторона Парижа

Прежде всего, нам пришлось развернуть его на сотнях серверов в P19.

Наша архитектура позволяла нам устанавливать по одному ProxySQL на каждый хост базы данных. Это было сделано в период с 27 ноября по 6 декабря 2019 года (http://travaux.ovh.net/?do=details&id=35499).



Как только все они будут запущены, мы сможем начать миграцию. Для каждой базы данных был обновлен ProxySQL, поэтому он отслеживал, где на самом деле находилась база данных, в Париже или в Gravelines.



Легко, не правда ли? Поскольку ProxySQL работает на том же хосте, нам не нужно было ничего подделывать, и это работало как шарм. Но что произойдет, если веб-сервер в Gravelines вызовет базу данных, которая все еще находится в Париже?

Сторона Гравелина

На этот раз у нас не было выбора, кроме как подделать имя сервера в Gravelines. Что мы могли использовать? Конечно же, ProxySQL! Но в нашей новой архитектуре мы просто не могли установить их на всех хостах, потому что, как было замечено ранее, у нас в Gravelines в 10 раз меньше клиентов на каждый экземпляр, чем в Париже.

Поэтому нам пришлось настроить ферму ProxySQL и ложный DNS, который разрешает члену фермы запросы о серверах в Париже. И, используя тот же механизм обновления конфигурации ProxySQL во время миграции, мы наконец получили такую ​​инфраструктуру:



Но как насчет конфигураций с IP-адресами в них? Поскольку у нас был ProxySQL, загруженный пользователями для группы серверов P19, мы могли — благодаря уловке с маршрутизацией — заставить веб-серверы думать, что IP-адреса P19 были настроены на ProxySQL!

Обратная сторона

Вы только что узнали, что для того, чтобы миграция произошла в требуемые сроки, нам пришлось внедрить ProxySQL. Даже если это отличное программное обеспечение, которое было почти спасением для нас, как системных администраторов, мы предпочитаем избегать обслуживания все большего и большего количества различных решений на ежедневной основе. Вот почему мы решили отказаться от поддержки способов подключения к вашей базе данных, кроме .mysql.db, в ближайшие месяцы. Подробности появятся в ближайшее время.

Если вы хотите сохранить наш современный способ решения задач (а также помочь нам обеспечить плавность изменений!), Вы можете проверить, что ваш веб-сайт уже использует .mysql.db в ваших файлах конфигурации.

Вывод

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

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

Вы, возможно, помните ненормальное количество «max_user_connections» ( travaux.ovh.net/?do=details&id=35689 ).
Нам пришлось поиграться с исходным кодом ProxySQL, чтобы разрешить его использование против mysql 5.1 в сочетании с алгоритмом хеширования паролей до mysql 4.0. Мы обнаружили забавные вещи о кодировании в исходном коде, который мы исправили в апстриме.Мы смогли заполнить таблицу ARP нашего хоста несколько раз в час. Вы узнаете больше об этих проблемах в наших следующих публикациях!

В наших предыдущих статьях мы объяснили, почему нам пришлось перенести 800 000 баз данных из одного центра обработки данных в другой, на расстоянии 300 километров. Итак, мы… Моя команда и я сделали это! Это было настоящей головной болью, поэтому я надеюсь, что наша история поможет вам обратиться к большему количеству крупных технических проектов, с которыми мы любим играть.

Правила

• Чтобы уменьшить задержку, базу данных необходимо переносить одновременно с веб-сайтом, который ее использует.
• Поскольку базы данных распределены по всем доступным серверам MySQL, детализацией миграции должна быть база данных, а не экземпляр MySQL. Другими словами, мы не можем перенести весь сервер MySQL. Мы должны переместить только его часть.
• Поскольку ссылка между веб-сайтом и его базой данных не обязательно указывается, веб-сайт в Gravelines должен иметь возможность связываться с базой данных в Париже (например), и наоборот.
• Чтобы связаться со своей базой данных, веб-сайт использует имя хоста, имя пользователя и пароль. Мы хотим, чтобы миграция была прозрачной, чтобы никому не пришлось изменять какие-либо из этих элементов, чтобы связаться с их новой базой данных.
• Платформы баз данных меняются между Paris и Gravelines, как показано ниже.

Подводя итог, вот что у нас было до миграции веб-кластера:



И это то, что мы хотим после миграции:

Еще несколько вещей…

• Очевидно, что при работе с базами данных мы должны помнить об одном из самых важных моментов: согласованности. Для каждой базы данных нам нужно было определить точку согласованности. До этого момента на временной шкале чтение и запись производились в Париже. После этого чтение / запись производились в Gravelines.
• Мы верим в прозрачность и обратимость. Это обе ключевые части нашего SMART-облака. Вот почему мы хотели предоставить вам доступ к этой точке согласованности в виде дампа на панели управления OVHcloud . Для каждой перенесенной базы данных мы решили предоставить вам доступ к дампу на один месяц.
• Перенос 800 КБ баз данных примерно за 60 ночей означал, что мы должны были быть очень быстрыми и масштабируемыми. Наш рекорд был 1 июля 2019 года, когда мы успешно перенесли 13 502 базы данных за 1 час 13 минут и 31 секунду.
• Если вы привыкли быть на работе, вы знаете, что ночью ваше внимание и работоспособность ниже. Повторение процесса миграции примерно 60 раз в год усилит это, поэтому мы хотели, чтобы все было максимально автоматизировано и как можно проще. Как мы увидим позже, для запуска миграции базы данных нам просто нужно было запустить одну команду на одном хосте:

migrate-p19

Теперь вы знаете правила, пора начинать игру!

1-й уровень

Первый уровень всегда легкий, где вы узнаете, как работает игра, с помощью своего рода учебника! Итак, начнем с небольшой миграции базы данных. Вот как мы это делаем:

1. У источника (Париж)

• Установите режим только для чтения. Нам абсолютно необходимо избегать записи во время миграции, чтобы избежать известного  разделения мозга . Самый простой способ сделать это — перевести базу данных в режим только для чтения. В большинстве случаев веб-сайтам нужно только читать базы данных, но в некоторых случаях им нужно читать и писать, и поэтому они будут сломаны. Это не проблема, потому что сайт сейчас перенесен и закрыт. Мы заблокируем доступ на запись, если база данных используется другим хостом, на который ночная миграция не влияет.
• Дамп базы данных и дамп куда-нибудь положить. Мы решили хранить дампы в публичном облачном хранилище (PCS) OVHcloud , так как мы уже используем это решение для хранения 36 миллионов дампов в месяц. Добавление 800 000 дампов за год — не проблема для этой потрясающей платформы!

2. В пункте назначения (Гравелин)

• Получите дамп и импортируйте его.
• Создайте пользователя и разрешения с правом записи.

3. Переключитесь на новую базу данных.

• На данный момент веб-сайт все еще обращается к базе данных в Париже. Чтобы веб-сайт (независимо от того, размещен ли он в Париже или Gravelines) мог связаться с новой базой данных, мы обновим DNS, чтобы имя указывало на экземпляр Gravelines MySQL, а не на Париж.
• Доступ для чтения к базе данных Paris также удален.
• Наконец, мы обновим нашу информационную систему, чтобы вы могли получить дамп с PCS через панель управления. Это обновление также позволяет нам перенаправить все действия, доступные из Панели управления (например, изменение пароля, создание дампа…), в новую базу данных на Gravelines.

Уровень 2: «Децентрализованный государственный автомат»

Чтобы подтвердить концепцию миграции, мы сначала выполнили все эти шаги вручную и последовательно. Естественный способ автоматизировать это — написать сценарий, который сделает то же самое, но быстрее. Это централизованный метод, но такие методы рано или поздно обнаруживают узкие места и подразумевают единую точку отказа.

Чтобы предотвратить это и выполнить наши требования к масштабируемости, мы должны быть децентрализованы. Мы должны представить себе миграцию единственной базы данных как конечный автомат. Вот упрощенная версия графа состояний миграции базы данных, как описано выше:



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

• Источник
• Назначение
• Тот, который обновляет DNS

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

Мозг миграции: CloudDB

Нам нравится концепция «ешьте свою собственную еду»! Это лучший контроль качества, который когда-либо был, и ваши отзывы — это наш первый источник запросов на добавление функций. Поэтому неудивительно, что мы использовали наш собственный продукт CloudDB для хранения графов состояний миграций баз данных.

Технически граф состояний — это строка в таблице. Упрощенная структура этой таблицы выглядит так:

- database_name VARCHAR(255) PRIMARY KEY,
- source VARCHAR(255),
- destination VARCHAR(255),
- status VARCHAR(255) NOT NULL DEFAULT 'Waiting',
- dump_url TEXT

За исключением dump_url, все поля заполняются до начала миграции. Другими словами, мы знаем, где находятся базы данных и где они будут.

Мы прошли все испытания этого уровня. Пришло время победить последнего монстра!

Уровень 3. Перенести 800 КБ баз данных.

Теперь, когда мы знаем, как перенести одну базу данных децентрализованно, давайте заполним CloudDB всеми базами данных, которые мы хотим перенести! Вот как теперь выглядит миграция:

В Париже

Примерно раз в минуту * каждый хост из 780 серверов баз данных спрашивает CloudDB, есть ли у них что-то для сброса. В sourceи statusстолбцах таблицы используются для получения этой информации:

SELECT … WHERE source = me AND status = 'To dump';

Если так, они выполняют свои задачи и обновляют CloudDB о том, что они делают. Когда они закончили, они передают эстафету перехода к Gravelines:

UPDATE … SET status = 'To import' WHERE database_name = '…';

В Gravelines

В то же время в 300 километрах сотни серверов баз данных также спрашивают CloudDB, есть ли у них что-то для импорта. Как и в Париже, они запрашивают CloudDB примерно раз в минуту *. В destinationи statusстолбцах таблицы используются для получения этой информации:

SELECT … WHERE destination = me AND status = 'To import';

Если да, они выполняют свои задачи и обновляют CloudDB о том, что они делают. По завершении они передают эстафету третьему роботу, который изменяет записи DNS для этой миграции базы данных:

UPDATE … SET status = 'DNS to update' WHERE database_name = '…';

(*) Чтобы избежать переполнения CloudDB, мы используем случайную частоту для запроса базы данных с графами состояний. Таким образом, соединения глобально распределяются во времени.

Обновление DNS

Робот, отвечающий за обновление DNS, является третьим игроком в процессе миграции и работает так же, как роботы дампа и импорта, описанные выше.

Не все так просто ...

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

• Предотвращение записи в исходную базу данных
• Обновление IS (среди прочего), чтобы вы могли видеть дамп в Панели управления
• Установка пароля в пункте назначения (такого же, как у источника), не зная этого
• И многие другие

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

Чит-код: Итерация!

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

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

Но есть чит-код, чтобы победить этого босса: повторять!

• Начать миграцию
• Столкнуться с проблемой
• Исправьте это окончательно (не только для конкретного случая, в котором произошел сбой, но и для всех похожих случаев на всей платформе)
• Тогда попробуйте еще раз, быстрее!

Этот способ возможен благодаря двум причинам:

• Волшебная команда
• Большая красная кнопка

Волшебная команда

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

migrate-p19

У этой волшебной команды есть один параметр: количество параллельных миграций, которые вы хотите сделать. Мы использовали 400для этого параметра.

migrate-p19 --max-procs 400

Это означает, что 400 баз данных выгружаются или импортируются одновременно — ни больше, ни меньше.

Команда migrate-p19- это планировщик. Он обновляет CloudDB каждые 10 секунд, поэтому эти 400 миграций всегда выполняются параллельно:

SELECT COUNT(database_name) … WHERE status in ('To dump', 'Dumping', 'Dump failed', 'To import', …);
42
UPDATE … SET status = 'To dump' WHERE status = 'Waiting' LIMIT (400 - 42);

Пауза в игре: большая красная кнопка

На каждой машине обязательно должна быть большая красная кнопка, которую нужно нажимать, когда что-то не так. Чтобы прервать миграцию по какой-либо причине, нам просто нужно убить migration-p19скрипт. Когда мы это делаем, текущие миграции завершаются сами собой, после чего новые не запускаются.

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

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

Продолжение следует…

В нашей серии статей о переносе инфраструктуры веб-хостинга из Парижа на Gravelines (первая из которых находится здесь ) мы не упомянули базы данных. Однако это очень важная часть, так как необходимо перенести 800 000 баз данных!

В этой новой серии публикаций мы расскажем вам о нашем опыте работы с базами данных веб-хостинга.

Как обрабатывать 800 тыс. Баз данных?

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

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

OVH предлагает два типа баз данных:

• Общие базы данных (которые мы называем SharedSQL )

• Частные базы данных (которые мы называем, как вы уже догадались, PrivateSQL)

Что такое SharedSQL?

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

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

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

Что такое PrivateSQL?

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

У каждого пользователя есть свой сервер? На самом деле, нет! Несколько лет назад мы использовали технологию Docker для контейнеризации наших баз данных, мы уже обсуждали это в этом посте: www.ovh.com/en/blog/docker-administration-databases-a-flying-ideas/. В PrivateSQL закрыто не только пространство базы данных, но и гарантировано выделенное службе ОЗУ. Это означает, что в любых обстоятельствах производительность остается неизменной.

Семь отличий!

При рассмотрении вопроса о миграции нам пришлось изучить разницу в архитектуре между Paris и Gravelines.

Что касается PrivateSQL, все было просто: нет никакой разницы, мы уже согласовали архитектуры, когда помещали их в контейнер. Перенести их было бы проще простого: нам просто нужно было переместить контейнер из точки А в точку Б.

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

Вот упрощенная схема PrivateSQL



Напротив, базы данных SharedSQL на самом деле не были согласованы. Когда мы настраивали центр обработки данных Gravelines в 2016 году, мы воспользовались гибкостью Docker, чтобы пересмотреть нашу технологию баз данных и, следовательно, адаптировать наше прежнее решение.

Небольшая сравнительная схема SharedSQL в Париже и Gravelines:

SharedSQL на Paris P19 и Gravelines:



С одной стороны (в Париже) у нас есть серверы с единой системой управления базами данных (MySQL), на которых размещено 2500 баз данных на одной машине.

С другой стороны (в Gravelines) мы добавили уровень: контейнеры Docker имеют одну и ту же систему баз данных (MySQL), на которой размещается до 250 баз данных. На каждой машине размещается по 10 контейнеров.

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

Вот что он дает:



Конечно, запуск базы данных в контейнере Docker казался безумной идеей. Но после многих лет производства эта технология упрощает повседневную жизнь в центре обработки данных Gravelines.

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

И вдруг у нас возникла еще одна проблема миграции.

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

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

Если вы не выполнили все наши технические ограничения, я предлагаю вам перечитать статью, в которой представлена инфраструктура нашего веб-хостинга. Мы построили наши сценарии миграции, серьезно отнеслись к этим ограничениям.

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

Сценарии

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

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

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

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

Самостоятельный перенос сайтов

Наша первая идея заключалась в том, чтобы переносить веб-сайты независимо друг от друга. Это также решение, которое мы рекомендуем клиентам, желающим быстро воспользоваться преимуществами Gravelines, прежде чем приступить к глобальной миграции.

Вот что обычно приходилось делать нашим клиентам:

• Определите все базы данных, используемые в их исходном коде
• Настройте целевую учетную запись
• Поместите сайт на обслуживание в центр обработки данных в Париже, чтобы избежать раздвоения мозгов
• Перенести все данные: файлы исходного кода, а также базы данных
• Настройте новые учетные данные базы данных в исходном коде сайта.
• Убедитесь, что сайт работает как задумано
• Измените свою зону DNS, чтобы перенаправить свой веб-сайт на новый IP-адрес нового кластера Gravelines.
• Повторно откройте сайт и дождитесь окончания задержки распространения DNS.

Мы рассмотрели возможность индустриализации этой техники, чтобы сделать это от имени клиента. Но мы столкнулись с несколькими техническими проблемами:

• Надежная идентификация всех используемых баз данных сложна. Можно искать все имена баз данных в исходном коде наших клиентов, но это очень долгая операция, надежная только в том случае, если исходный код не изменяется в течение этого времени. Это также требует работы со многими особыми случаями: двоичные файлы, выполняемые в CGI, обфускация исходного кода или даже хранение имени баз данных в… базе данных. Этот метод не позволяет нам рассчитывать на 100% надежность нашей миграции.
• Перенос файлов можно выполнить двумя способами:
  
  1. В файловом режиме сценарий миграции проходит по дереву файлов и копирует их по одному.
  
  
  2. В блочном режиме сценарий миграции берет данные с жесткого диска и побитно передает их на целевой жесткий диск без учета древовидной структуры.

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

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

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

• Изменение исходного кода — опасная операция, которую мы не позволяем делать, потому что это может сильно повлиять на веб-сайт. Кроме того, это требует исчерпывающего определения всех видов использования баз данных…
• Некоторые наши клиенты не размещают свою зону DNS дома. После этого мы не сможем изменить IP-адрес их веб-сайта без их вмешательства, что требует от нас сохранения этого IP-адреса, если мы хотим достичь хорошего уровня надежности для миграции.

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

IP через грузовые автомобили

Интернет основан на IP-протоколе для адресации машин в сети. Это не зависит от физического материала, на котором происходит обмен сообщениями, можно использовать многие: оптические каналы, электрические, беспроводные; даже странствующих голубей, как это описано в юмористическом стандарте, установленном 1 апреля 1990 года!

Эта первоапрельская шутка нас вдохновила, хотя мы не знатоки голубей. В самом деле, даже если задержка (продолжительность путешествия для сообщения из точки A в точку B) важна, пропускная способность (количество отправленной информации / время в пути) потенциально огромна: USB-ключ содержит много данных! При некоторых больших передачах физическое перемещение данных — разумный способ увеличить пропускную способность передачи.

Поэтому мы подумали о варианте просто перенести инфраструктуру из Парижа в Gravelines. У этого есть преимущества:

• Не влияет на веб-сайты. Нам просто нужно снова включить инфраструктуру в другом центре обработки данных и перенаправить туда трафик;
• Это позволяет очень быстро опустошить дата-центр.

Но это также создает некоторые проблемы:

• Как сократить время нарезки сайтов между остановкой машин в Париже, их загрузкой, транспортировкой, разгрузкой и повторным зажиганием? Время отключения будет порядка нескольких дней.
• Что делать в случае аварии в дороге? Падение сервера, ДТП…
• Как убедиться, что данные не изменятся во время транспортировки из-за вибрации грузовика?
• Как интегрировать эту инфраструктуру, не соблюдая стандарты индустриализации, действующие в Gravelines?

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

Масштабируемые миграции

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

Поэтому мы сделали шаг назад и посмотрели на уровни детализации нашей инфраструктуры, то есть на элементы, которые связывают веб-сайты друг с другом и предотвращают переход от сайта к сайту:

• IP-адреса: мы не контролировали все зоны DNS, мы считали, что IP-адреса сайтов наших клиентов не могут быть изменены. Это означает, что мы должны перенести сразу все веб-сайты, использующие один и тот же IP-адрес.
• Filerz : миграция в файл данных режима на filerz не является возможным из - за большое количество файлов, мы должны выполнить миграцию в блочной режиме и тем самым перенести все клиент в том же filerz одновременно.
• Базы данных: все базы данных на одном веб-сайте должны быть перенесены одновременно, чтобы сайт продолжал работать, а идентификаторы баз данных не должны изменяться. Эти базы данных потенциально могут использоваться двумя разными местоположениями, включая разные кластеры; эти приспособления должны быть перенесены одновременно.

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

Мы были в блокирующей позиции. Чтобы двигаться вперед, необходимо было пересмотреть каждый постулат и рассмотреть решения для преодоления этих проблем.

Устранение зависимостей от баз данных

Одно из самых сложных ограничений — это надежная миграция баз данных вместе с веб-сайтами.

Можем ли мы представить себе 95% надежную миграцию с учетом только баз данных, предоставленных с хостингом (то есть, не считая нетипичных случаев, которые обнаруживаются только путем анализа исходного кода веб-сайтов)?

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

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

Это технически возможно, если мы откроем сетевой туннель между нашим центром обработки данных в Gravelines и этим центром в Париже. С помощью этого туннеля веб-сайт, использующий базу данных, на которую нет ссылок на его хостинге, продолжит работу, получая данные в Париже.

Это не идеальное решение: добавление сетевого туннеля означает добавление задержки 10 мс. И на некоторых CMS, выполняющих десятки SQL-запросов последовательно, эта задержка быстро заметна. Но, ограничив этот эффект только базами данных без ссылок, мы могли бы упростить это сильное ограничение. Все сайты продолжат работу. Некоторые сайты могут работать медленно, но для наших обычных случаев веб-хостинга последствия минимальны.

Обход зависимости IP-адреса

За одним IP-адресом скрывается несколько сотен тысяч веб-сайтов. Поэтому миграция всех файлов и баз данных потребует очень важного времени завершения работы.

Однако вопрос можно задать по-другому: IP-адрес обслуживает несколько сайтов, как мы можем распределить входящий трафик с этого IP-адреса в правильный центр обработки данных, на котором размещен нужный веб-сайт? Это проблема балансировки нагрузки, и у нас уже есть балансировщик нагрузки, который адаптируется в соответствии с запрошенным веб-сайтом: предсказатель.

В предикторе можно определить, где веб-сайт действительно должен перенаправлять трафик. Самым простым решением было бы добавление нового предиктора перед нашей инфраструктурой, но объединение балансировок нагрузки в цепочку — не лучшая идея: это делает путь к веб-сайту более сложным и добавляет новый критический элемент в инфраструктуру.

И наконец, ничто не мешает нам использовать балансировку нагрузки Paris или Gravelines для выполнения этого перенаправления трафика.

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

Мы знали, как переносить IP-адрес между нашими центрами обработки данных. Таким образом, можно подготовить эти новые предикторы, а затем прозрачным образом перенести IP-адреса всего кластера, не вызывая прерывания работы клиента.

IP-адреса больше не были точкой блокировки. Снижая это ограничение, мы теперь можем переносить клиентов filerz by filerz. Можем ли мы сделать еще лучше?

Перенести filerz как блок

Чтобы добиться большего, нам потребуется декоррелировать клиентов каждого filerz. Как мы могли это сделать?

Перенос всего filerz требует времени. Нам нужно переместить несколько ТБ данных по нашей сети, это может занять десятки часов. Чтобы избежать расщепления мозгов, нам нужно избегать записи в источнике во время копирования.

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

В этот момент можно отключить службу на несколько часов ночью, чтобы выполнить миграцию ( filerz и связанные базы данных), не рискуя разделить мозг.

Теперь у нас есть все элементы для реализации нового сценария миграции!

Давай, сделаем это еще раз.

Наш финальный сценарий

После прочтения предыдущих разделов вы, вероятно, уже имеете хорошее представление о том, как мы переносим кластеры. Вот основные шаги:

1 / Строительство нового кластера в Gravelines, соответствующего стандартам этого нового центра обработки данных, но включающего столько же файлов и баз данных, сколько и предыдущий.


2 / Построение сетевого соединения между новым и старым центром обработки данных.


3 / Миграция IP-трафика на новый кластер с перенаправлением в Париж для немигрированных сайтов.


4 / Копирование данных без взлома сайтов.


5 / Ночью: отключение сайтов первого filerz, перенос его данных и связанных баз данных.


6 / Ночью: отключение сайтов, миграция второго filerz и связанных баз данных.


7 / Закрытие исходного кластера.


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

Этот сценарий был проверен в июле 2018 года. Чтобы он заработал, нам потребовалось 5 месяцев адаптации наших систем, а также несколько холостых повторений на тестовом кластере, специально развернутом для проверки того, что все работает должным образом. На бумаге сценарий выглядел красиво, но нам приходилось решать множество проблем на каждом этапе процесса (мы более подробно рассмотрим технические детали в будущих сообщениях в блоге).

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

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

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

До скорой встречи для дальнейших приключений!

В 2018 году мы запустили один из крупнейших проектов в истории OVH: миграцию 3 миллионов веб-сайтов, размещенных в нашем центре обработки данных в Париже. Если вы хотите узнать причины этого титанического проекта, мы рассмотрели их в этом посте.

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

Анатомия веб-хостинга

Для работы веб-сайтам и веб-приложениям обычно нужны две вещи :

• Исходный код, отвечающий за выполнение поведения веб-сайта
• T он данные , используемые в исходном коде , чтобы настроить опыт

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

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

Для владельца веб-сайта мониторинг инфраструктуры и ее операций может быть очень дорогостоящим: вам нужна достаточно большая команда, чтобы поддерживать присутствие 24 часа в сутки, 365 дней в году. С такой командой разработчики могут полагаться только на разовые запросы на обслуживание, когда владелец веб-сайта хочет внести изменения.

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

Таким образом, каждому веб-сайту не нужно использовать ресурсы всего сервера. С помощью наших решений мы объединяем ресурсы в нашей инфраструктуре, поэтому отдельные серверы могут использоваться для одновременного запуска нескольких веб-сайтов.

Все эти эффекты масштаба позволяют нам предлагать недорогие решения для веб-хостинга (от 1,49 евро в месяц), сохраняя при этом высокий уровень качества. Мы очень коротко объясним, как мы рассчитываем качество обслуживания, но если вы не хотите ждать, посмотрите конференцию, которую наши разработчики провели на FOSDEM 2019.

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

Техническая архитектура наших решений для веб-хостинга

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

Это очень эффективно, но у этого типа архитектуры есть некоторые недостатки :

• В случае поломки восстановление может быть долгим. Если у вас нет репликации системы в реальном времени, что очень дорого, вам нужно восстановить данные из резервной копии, а затем перенести их на новую машину, прежде чем повторно открывать службу для клиентов. Хотя вероятность аппаратного или программного сбоя невелика, это обычная операция в крупных инфраструктурах.
• Чтобы иметь дело с новыми технологиями, было бы предпочтительнее внедрять их на новых серверах только на первом этапе, а затем уделять время постепенному развертыванию их на существующих серверах на будущих этапах.
  Однако на таком быстро развивающемся рынке, как Интернет, становится трудно поддерживать разнородную инфраструктуру. Затем технические группы должны адаптироваться и работать с несколькими различными конфигурациями, что увеличивает риск регресса или поломки. А командам поддержки становится очень сложно запоминать все различные конфигурации и отслеживать текущие изменения.
• Каждый программный блок по своей сути сложен, поэтому для достижения максимальной производительности и качества обслуживания мы создали группы, специализирующиеся на каждой технологии: база данных, среда PHP, системы хранения, сеть… Может быть сложно заставить все эти группы взаимодействовать на одном сервере., и приводят к недопониманию относительно доступности веб-сайтов.
• Трудно выделить клиента, который потребляет больше ресурсов, чем в среднем. Если вам повезет, вы не будете на том же сервере, что и этот клиент, но если да, то производительность вашего веб-сайта может пострадать в результате потребления ресурсов.

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

N- уровневая архитектура

Участки с высоким уровнем нагрузки могут использовать п — уровень архитектуру, чтобы предоставить больше ресурсов для каждого программного кирпича, распределяя их между несколькими серверами. Если мы пойдем дальше с нашим разделением кода / данных, нам понадобится три сервера для запуска веб-сайта:

• Сервер, ответственный за выполнение исходного кода
• Два часто используемых сервера хранения : сервер базы данных и файловый сервер

Файловые серверы: Filerz

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

Ими управляет специальная группа хранения, которая также предоставляет услуги этого типа нескольким другим командам в OVH (веб-хостинг, электронная почта…). Если вас это интересует, они также предлагают NAS-HA, который вы найдете в общедоступном каталоге наших выделенных серверов.

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

Серверы баз данных

Серверы баз данных обычно используются веб-сайтами для динамического размещения данных сайта. Они используют систему управления базами данных (СУБД) (MySQL с нашими решениями), которая структурирует данные и делает их доступными через язык запросов (в нашем случае SQL).

Эти серверы также требуют специального оборудования для хранения данных, особенно большого объема оперативной памяти, чтобы использовать преимущества систем кэширования СУБД и быстрее отвечать на поисковые запросы.

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

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

Веб-серверы

Это серверы, которые получают запросы и выполняют исходный код веб-сайта. Они получают свои данные из файлов и баз данных, предоставленных ранее описанными Filerz и серверами баз данных. Основное требование к этим серверам — хорошие ресурсы ЦП, необходимые для выполнения исходного кода.

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

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

Балансировка нагрузки

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

В нашем центре обработки данных в Париже есть серверы, оборудование которых полностью предназначено для балансировки нагрузки. Однако в нашей новой инфраструктуре Gravelines мы используем публичный кирпич: IPLB.

Трафик веб-сайта поступает на несколько IP-адресов ( docs.ovh.com/en/hosting/list-addresses-ip-clusters-and-web-hostings/#cluster-025 ), которые мы выделяем для нашей службы веб-хостинга.. Эти IP-адреса управляются нашими балансировщиками нагрузки. Следовательно, они являются отправной точкой нашей инфраструктуры. Кроме того, мы реализовали самые лучшие анти DDoS технологии, чтобы защитить веб — сайтов наших клиентов.

Эти нагрузки балансиры работают отлично для больших объемов трафика веб — сайта, распространение на нескольких веб — серверов, так как запросы распределяются справедливо, с помощью алгоритмов балансировки нагрузки. Но наши требования другие. Мы хотим иметь несколько различных сайтов на в одном сервере, и изменить распределение на основе нескольких критериев: хостинг пакет клиента (как более премиальные предложения включают меньше веб — сайтов на одном сервере), и ресурсы, необходимые для непрерывного распределения нагрузки.

Мы также предлагаем решения с гарантированными ресурсами, такие как Performance Hosting, или даже полностью выделенные, например Cloud Web.

Фактически, распределение нагрузки очень сильно привязано к нашим клиентам. Мы изменили систему распространения, добавив блок, предназначенный для OVH, с именем predictor, который выбирает веб-сервер в соответствии с веб-сайтом запроса. В предикторы адаптации к метрикам нашей инфраструктуры, и информация, предоставленная нашей системой.



Все это делает нашу инфраструктуру немного сложнее, чем обычно, хотя ж е не будет идти гораздо дальше в детали того, чтобы держать вещи простым и в рамках этого блога. Это должно было дать достаточно обзора, чтобы объяснить возможные сценарии миграции.

Благодаря добавлению балансировки нагрузки, а также нескольких серверов баз данных и файлового хранилища эта архитектура позволяет нам размещать невероятно большое количество различных веб-сайтов. Но, как знают все администраторы инфраструктуры, «дерьмо случается!». Рано или поздно случится сбой. Поэтому необходимо знать, как реагировать в таких случаях, чтобы минимизировать воздействие.

Домены сбоя

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

В нашем бизнесе речь идет о разделении инфраструктуры на части и распределении клиентов по разным кластерам. Поэтому мы разделили инфраструктуру Парижа на 12 идентичных кластеров. В каждом кластере мы находим балансировщик нагрузки, веб-серверы и Filerz. Я е один из кластеров идет вниз, « только « 1/12 из клиентов с сайтов, размещенных на этом центре обработки данных затронуты.

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

Итак, в последний раз нам нужно обновить схему нашей инфраструктуры…

Управление инфраструктурой

Вся эта инфраструктура находится в ведении нашей информационной системы, с использованием конфигурации в режиме реального времени, которая формирует на связь между панелью управления OVH, в OVH API, и самой инфраструктурой.

Информационная система включает исчерпывающее представление инфраструктуры, что позволяет адаптировать доставку новых учетных записей, управлять изменениями в наших предложениях и выполнять технические действия с учетными записями.

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

Поздравляем… теперь вы знаете немного больше о нашей архитектуре! Чтобы узнать, где работает ваш собственный веб-сайт, вы можете найти имена серверов баз данных, Filerz и кластеров, связанных с вашим хостингом, в панели управления OVH.

Технические ограничения для миграции

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

• Все веб-сайты в одном кластере имеют один и тот же IP-адрес.
• Серверы баз данных и кластеры хостинга не коррелируют
• Чтобы перенести веб-сайт, вы должны синхронизировать его миграцию с миграцией всех связанных с ним элементов, то есть балансировщика нагрузки , Filerz и баз данных.
• Исходный код веб-сайта может использовать базу данных, на которую нет ссылок на его веб-хостинге.
• Исходный код может включать ссылки на инфраструктуру (абсолютная ссылка, включая номер файла , имя кластера, имя серверов баз данных ...)

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

Вы переносили веб-сайт раньше? Если у вас есть или потребуется регулярно переносить веб-сайты, вы будете знакомы с трудностями, связанными с такого рода операциями.

Проще говоря, эта операция обычно включает шесть шагов:

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

В зависимости от исходного кода веб-сайта и сложности инфраструктуры эти шаги могут различаться по сложности. На самом деле это зависит от доступа вашего веб-сайта к данным для записи. Следует ли хранить данные в базе данных? Есть ли на вашем сайте кеш на основе локальных файлов? Все это определено в исходном коде ваших веб-страниц.



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

Что касается веб-хостинга, то этот проект включает перенос трех миллионов различных веб-сайтов, размещенных на 7000 серверов в Париже. Некоторые из этих сайтов работают с 1999 года! Это одно из самых продолжительных направлений деятельности OVH. Так зачем же их мигрировать, если они прекрасно работают в Париже почти 20 лет? Чтобы понять все проблемы, с которыми мы сталкиваемся, нам нужно углубиться в историю этого сервиса.

Краткая история нашей платформы веб-хостинга

Когда Октав основал OVH в 1999 году, доступ в Интернет по-прежнему был ограничен. Первым направлением деятельности компании был хостинг сайтов. То, что сейчас кажется простым, в то время было не так просто. Вы должны были иметь хорошие сетевые соединения, поддерживать работу веб-серверов и правильно их настраивать. Было трудно найти людей, обладающих техническими знаниями или ресурсами для этого.

Строительство и расширение P19

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

В P19 OVH не просто предлагал веб-хостинг. В дата-центре также размещались выделенные серверы. Оба вида деятельности быстро завоевали популярность, и в конце 2000-х OVH начала строительство множества новых центров обработки данных в Рубе, затем в Страсбурге, Богарнуа (Канада), Гравелайн и других местах.

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

Как Интернет развивался с 1999 года по настоящее время

Интернет кардинально изменился с 1999 года. С нашей точки зрения, как хостинг-провайдер, мы наблюдали три изменения с течением времени…

• 1999 -> 2005: Рождение Интернета. Статические веб-сайты создавались в HTML. Именно тогда начали появляться блоги. Но эта технология была доступна только людям, которые знали, как использовать клиенты HTML и FTP, хотя FrontPage помог многим людям начать работу.
  Для работы эти веб-сайты включали данные прямо в код. Веб-хостинг был довольно простым: пользователю требовалось место для хранения и веб-сервер, единственной целью которого было отправить веб-страницу, которую он будет искать в пространстве для хранения.
• 2006 -> 2013: Web 2.0 — революция в социальных сетях и базах данных. Веб-сайты стали динамическими и могли отображать настраиваемые страницы в зависимости от пользователя. Именно тогда впервые начали появляться дискуссионные форумы, платформы для блогов и социальные сети, которые до сих пор так популярны.
  Динамические веб-сайты стали революцией для провайдеров веб-хостинга; код и данные теперь хранились в двух разных местах. Это означало, что страницу необходимо было создать до отправки конечному пользователю. Роль веб-сервера изменилась, и он будет генерировать эти страницы по запросу, в основном на языке PHP. Для этих веб-сайтов необходимо было добавить серверы баз данных, а также вычислительные мощности для веб-серверов.
• 2014 -> сегодня: JavaScript стал мощнее, помогая разработчикам создавать сложные веб-приложения в браузерах и значительно улучшая работу веб-пользователей. Это изменение стало возможным благодаря развертыванию Интернета на наших смартфонах. В результате может быть запущено большое количество сервисов, требующих доступа в Интернет.
  Технически это означает, что способы использования меняются, и пользователи чаще посещают веб-сайты, тем самым увеличивая объем создаваемых данных и сложность их обработки. Использование дискового пространства и ресурсов для создания веб-страниц постоянно увеличивается.

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

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

Развертывание веб-хостинга в Gravelines

Как только мы это заметили, было только одно решение: чтобы избежать нехватки планов веб-хостинга, нам нужно разместить наши веб-сайты в другом центре обработки данных. Мы индустриализировали наши услуги в Париже, чтобы предоставлять услуги хостинга в режиме 24/7, управлять 7000 серверов и поддерживать их в рабочем состоянии на основе самых ранних технологий OVH.

Мы могли бы сохранить эту индустриализацию и применить ее к Gravelines, но мы решили сделать что-то еще. Мы решили создать новую техническую архитектуру, которая будет поддерживать растущие потребности с точки зрения производительности и, прежде всего, позволит нам повторно использовать другие продукты OVH. Это знаменитый подход « ешьте свою собачью еду », примененный и расширенный в масштабах наших планов веб-хостинга.

Мы поставили перед нашими собственными командами задачу управлять выделенными серверами, vRack (частная сеть), IP-адресами и балансировщиками нагрузки (IPLB), чтобы они могли поддерживать инфраструктуры и трафик наших клиентов. Став одним из крупнейших клиентов нашей компании, мы смогли выявить и преодолеть множество ограничений — повысить скорость отклика наших API, оптимизировать наши базы данных и многое другое.

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

Чтобы выбрать наш новый центр обработки данных, мы проанализировали естественный рост, чтобы удовлетворить потребности нашей инфраструктуры. Фактически, наша инфраструктура растет каждую неделю за счет поставок нового оборудования, и мы рисковали настолько быстро заполнить наши центры обработки данных, что это помешало бы нашим клиентам арендовать выделенные серверы и другие услуги OVH. Согласно этим критериям, только два центра обработки данных соответствовали нашим потребностям с точки зрения инфраструктуры в 2016 году: Gravelines в Северной Франции и Beauharnois в Канаде. Поскольку наша платформа в настоящее время развернута только в Европе, мы начали работать над Gravelines.

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

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

Этот центр обработки данных для веб-хостинга был открыт в июле 2016 года. А с ноября того же года все наши новые планы хостинга были доставлены туда.

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

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

Почему мы решили перенести наш центр обработки данных?

Чтобы дать Парижу новую жизнь
Есть несколько причин, по которым мы начинаем это грандиозное предприятие. Но главная причина — это устаревание.

Наша инфраструктура основана на физических ресурсах, размещенных в этом центре обработки данных: выделенных и виртуализированных серверах (которые основаны на физических машинах), сетевых элементах и ​​контуре охлаждения (водяное охлаждение и кондиционирование воздуха). А для того, чтобы инфраструктура оставалась доступной 24/7, нам необходимо периодически обновлять это оборудование.

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

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

Выделенным серверам для работы также требуются питание, сеть и система охлаждения. Все эти элементы также управляются физическим оборудованием: кондиционирование воздуха и водяное охлаждение для охлаждения машин, маршрутизаторы и переключатели для сети, электрические трансформаторы, устройства ИБП и батареи для электричества.

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

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

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

Для увеличения производительности сайта
Благодаря новой инфраструктуре Gravelines мы можем повысить производительность веб-сайтов наших клиентов. Более того, эти новые технологии помогли нам развернуть некоторые дополнительные функции, которые мы не можем развернуть в Париже без обновления нашей инфраструктуры: HTTP / 2, MySQL 5.6 и другие.

Наши клиенты могут сами перенести свои проекты, но миграция плана веб-хостинга — сложная и деликатная процедура. Многие клиенты отказались от этого.

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

Как мы переносим так много сайтов?
Как провайдер веб-хостинга, мы в основном специализируемся в двух областях: размещение данных и выполнение кода.

Хостинг данных — сложная операция, если необходимо поддерживать ее целостность с течением времени, но это относительно стандартизированная отрасль. Данные хранятся в файловой системе (это стандарт) или в базе данных, использующей определенный язык запросов (MySQL 5.5 или MySQL 5.6). Поэтому нам просто нужно воспроизвести архитектуру, отвечающую тому же стандарту в целевой инфраструктуре, и перенести в нее данные.

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

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

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

Почти год мы разработали несколько сценариев миграции. Мы экстраполировали их по всем направлениям, преследуя две цели:

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

Мы реализовали и протестировали некоторые из этих сценариев в период с марта по июнь 2018 г. Эта первоначальная работа помогла нам выбрать лучший план миграции. Чтобы завершить эту миграцию, не затрагивая службы, нам нужно было адаптировать часть нашей инфраструктуры и информационной системы: создать сетевой туннель между центрами обработки данных, изменить балансировщики нагрузки, нашу платформу базы данных, добавить прокси-серверы SQL и многое другое.

Мы тщательно протестировали выбранный сценарий. Чтобы гарантировать, что эта процедура будет выполнена с минимальным воздействием, мы многократно повторили ее в реальных условиях на внутренних кластерах, используя наборы данных, основанные на производственных платформах.

Хотите узнать больше о нашем плане миграции? Мы не можем включить все в это сообщение в блоге, поэтому мы решили рассказать о нашей миграции в серии сообщений, поскольку тема очень обширна.

Следите за нашими предстоящими публикациями, которые дадут вам закулисное представление о самом крупномасштабном переносе веб-сайтов, осуществленном крупнейшим хостинг-провайдером Европы!