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

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

• покупка и настройка инфраструктуры назначения
• тестирование новой инфраструктуры путем импорта данных и кода веб-сайта
• закрытие веб-сайта или перевод его в режим только для чтения, чтобы данные не сохранялись в старой инфраструктуре во время процесса миграции
• развертывание кода в новой инфраструктуре и импорт данных в новые базы данных
• изменение исходного кода для адаптации его к новой инфраструктуре (идентификаторы базы данных, подключение к внешним 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 и многое другое.

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

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

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