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

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

Это был не первый раз, когда я получил этот вопрос.

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

Ну, вы также можете сделать это с Kubernetes!

В этом прелесть богатой экосистемы Kubernetes: вы можете найти проекты, предназначенные для самых разных вариантов использования, от игровых серверов с Agones до платформ FaaS.

Для этого есть карта Хелма!
Говоря «Вы можете сделать это с Kubernetes! »Это почти новое« Для этого есть приложение! », Но это не помогает многим людям, которые ищут решения. Поскольку этот вопрос поднимался несколько раз, мы решили подготовить небольшое руководство по развертыванию и использованию платформы FaaS на управляемых OVH Kubernetes.

Мы начали с тестирования нескольких платформ FaaS на наших Kubernetes. Нашей целью было найти следующее решение:

• Простота развертывания (в идеале с простой диаграммой Хелма)
• Управляется как пользовательским интерфейсом, так и интерфейсом командной строки, потому что разные клиенты имеют разные потребности
• Авто-масштабируемый, как в увеличенном, так и в уменьшенном смысле
• Поддерживается всеобъемлющей документацией

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

OpenFaaS — платформа FaaS, родная из Кубернетеса


OpenFaaS
OpenFaaS — это платформа с открытым исходным кодом для создания бессерверных функций с помощью Docker и Kubernetes. Проект уже зрелый, популярный и активный, с более чем 14 тысячами звезд на GitHub, сотнями участников и множеством пользователей (как корпоративных, так и частных).

OpenFaaS очень прост в развертывании, используя диаграмму Хелма (включая оператор для CRD, т.е. функции get kubectl). Он имеет как CLI, так и пользовательский интерфейс, эффективно управляет автоматическим масштабированием, и его документация действительно всеобъемлющая (с каналом Slack для обсуждения, как приятный бонус!).

Технически OpenFaaS состоит из нескольких функциональных блоков:

• Функция Watchdog. Крошечный HTTP-сервер golang, который превращает любой образ Docker в функцию без сервера
• Шлюз API, который обеспечивает внешний маршрут к функциям и собирает метрики
• Портал пользовательского интерфейса, который создает и вызывает функции
• CLI (по сути, клиент REST для шлюза API), который может развернуть любой контейнер как функцию
• Функции могут быть написаны на многих языках (хотя я в основном использовал JavaScript, Go и Python для целей тестирования), используя удобные шаблоны или простой Dockerfile.

Подробности настройки
www.ovh.com/fr/blog/deploying-a-faas-platform-on-ovh-managed-kubernetes-using-openfaas/

Европейский лидер по облачным вычислениям, OVH защищает альтернативное предложение для гигантов, в частности американских, и намерен извлечь выгоду из своих ценностей, чтобы завоевать доли рынка на рынке с очень сильным ростом. Международная стратегия, влияние Закона об облачности США, финансирование роста, роль крупных компаний и французской администрации в появлении французских технических игроков. Генеральный директор OVH Мишель Полен Бордо, отвечает на вопросы La Tribune.

The Tribune — OVH вошли в 4-й квартал 2018 года как один из 10 лучших игроков в мире в облаке. Но в октябре прошлого года вы объявили о закрытии офисов в Европе и Западной Африке. Каковы будут основные факторы в вашей стратегии завоевания на международном уровне в ближайшие месяцы? И каковы будут ваши отличительные черты от гигантов мира, которые намного сильнее в финансовом отношении?

Мишель Полен: «OVH позиционируется как европейский альтернативный глобальный облачный оператор, и все эти слова важны». «Облачный оператор», потому что предыдущие 9 в этом рейтинге занимались другими видами деятельности. в том, что мы являемся чистым игроком, мы думаем только об облаке, мы инвестируем только в облако, недостатком является то, что мы не можем извлечь выгоду из прибыльности этих инвестиций как части деятельность или связанные с ней виды деятельности для финансирования облака. Второй момент заключается в том, что мы являемся европейским игроком, и мы защищаем этот аспект, мы уважаем европейское регулирование и наша экосистема очень близка к европейским ценностям: сообщество, Хотя во многих странах существуют правила, разрешающие доступ к данным за пределами их собственной географии, у европейского общества есть шанс, что мы Давайте предупредим наших клиентов, что их данные защищены местным законодательством. Наконец, мы являемся альтернативным игроком, потому что наша бизнес-модель, тот факт, что мы основаны на открытых стандартах, тот факт, что мы создаем наши собственные серверы и центры обработки данных, а также тот факт, что наши цены прозрачны и предсказуемы, отличает нас от других глобальных игроков, которые гораздо более влиятельны, в том числе в финансовом отношении.

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

Могут ли европейские ценности, особенно открытость, которые использует OVH, действительно привлекать в широком масштабе на ключевом американском рынке, которым вы занимались в течение следующих нескольких лет, или в Азии?

Если мы работаем на других континентах, кроме Европы, то это уже потому, что некоторые наши европейские клиенты работают там и просят нас следовать за ними». И мы также находим американских клиентов, которые хотят хранить свои данные в другом месте. что Соединенные Штаты Америки! Реальным предметом является обратимость (иными словами, факт возможности переноса или репатриации своих данных в стандартном формате, Эд), открытость и совместимость, возможность хранения своих данных. данные от нескольких игроков в облаке Многие клиенты не хотят одного облака, им нужно больше одного, и я всегда говорил, что если облако станет тюрьмой, даже золоченой, оно останется тюрьмой, которая не будет ничего хорошего, клиенты должны контролировать свои данные, и это актуальная глобальная тема в Европе, а также в США или Сингапуре.

Закон об облаке, обнародованный в 2018 году, позволяет администрации США получать информацию, хранящуюся в облачных игроках США, независимо от того, где находятся их серверы. Этот текст волнует. Получила ли OVH выгоду от «эффекта облачного действия», реализованного новыми клиентами? И, в более широком смысле, крупные французские компании и администрация играют в игру достаточно по сравнению с французскими техническими игроками? Инициативы, такие как установка поисковой системы Qwant по умолчанию вместо Google, все еще редки...

Мы выиграли клиентов, но если бы Закон об облачности был, возможно, одной из причин, они не сказали бы нам об этом, и когда они говорят это, они также говорят нам, что им нет дела до того, что это будет раскрыто» информация (улыбается)! Закон об облачности, а также создание в прошлом году RGPD, Европейского регламента о защите данных, тот факт, что Калифорния привержена этой теме… Все эти факты привели к субъекты владения и защиты данных постепенно, многие понимают, что данные имеют экономическую ценность, но также и то, что они должны рассматриваться с юридической точки зрения. Этот аспект начинает покидать технические центры от крупных компаний до комитетов по управлению, это становится частью промышленной стратегии, поэтому она носит постепенный, но очень позитивный характер, и я не удивляюсь, если завтра вопросы собственности и защиты данных будут встроен в оценочные сетки.

«Мы, европейцы, часто немного стесняемся»

В этом контексте министр экономики Бруно Ле Мэр несколько недель назад выдвинул из своего шкафа гипотезу о суверенном национальном облаке. Это относится к провалам предыдущих проектов Cloudwatt и Numergy. Основатель OVH Октава Клаба отреагировал в социальных сетях лапидарным «я не понимаю». Как вы живете такого рода правительственное заявление?

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

Как лидер европейского облака, вы думаете, что вы должны сыграть свою роль в развитии экосистемы? И особенно французские стартапы?

Мы, европейцы, иногда немного стесняемся, нам не должно быть стыдно за то, что происходит в Европе, у нас хорошие стартапы, но они либо пытаются достичь критических размеров, либо их выкупают люди». иностранные компании, у нас также есть высокие навыки во многих областях, которые вытаскивает весь мир. Но факт в том, что у нас нет такого технологического гиганта, каким может быть Gafam (Google, Apple, Facebook, Amazon От чего идея Октавы Клабы сосредоточиться на сотрудничестве, взаимопомощи без капитальных связей, чтобы создать своего рода «виртуальный Гафам», европейские актеры работают вместе, чтобы иметь возможность дать отпор В то же время, мы также работаем в экосистеме как часть нашей программы Digital Launch Pad, чтобы помочь стартапам иметь выбор своей инфраструктуры. У каждого должен быть выбор, и он не должен зависеть от одного или двух монополистические компании.

Проект по созданию альянса французских единорогов, включая OVH, Le Bon Coin, Critéo… для влияния на техническую политику Франции, актуален ли он?

Как вы знаете, в этом году Октава Клаба переехал в Соединенные Штаты, где он открыл для себя настоящую экосистему предпринимателей, способную быстро разрабатывать проекты, финансировать их и размещать на территории. Американец, который дает им пространство для борьбы с мировым рынком. Это, прежде всего, экосистемная работа между европейскими предпринимателями, как считает Октав. Так что французский — да, но не только французский, иначе Одно можно сказать наверняка: мы не сможем сделать что-то в одиночку: нам понадобится союз многих игроков всех размеров, чтобы каждый мог извлечь пользу из опыта других, расти и двигаться дальше.

Фондовый рынок, вариант среди других

Каковы возможности OVH в ближайшие годы для финансирования своего роста? IPO кажется все меньше и меньше табу ...

Сегодня OVH уже хорошо финансируется, мы уже неплохо собрали (250 млн. Евро в 2016 году в последнем раунде финансирования, Эд), и у нас есть хороший долговой потенциал, если это необходимо. 1,5 миллиарда евро до конца 2020 года. В будущем все средства будут внимательно отслеживаться. IPO является одним из вариантов, который будет рассмотрен. не выбирается и не исключается автоматически

В конце 2017 года OVH объявила о создании офиса в Бордо и ста рабочих мест за 18 месяцев. Мы приближаемся к этим 18 месяцам, где ты?

Решение о создании офиса в Бордо отвечает как необходимости диверсификации нашего географического местоположения, так и расширению наших возможностей по набору персонала в связи с историей бизнеса, сосредоточенного на севере Франции (OVH базируется в Рубе, Эд) и немного в Париже, я думаю не с точки зрения городов, а с точки зрения рекрутинговых пулов. Сегодня у нас есть рекрутинговый бассейн, который является Атлантическим побережьем. Нант, Бордо, Тулуза, мы пытаемся завербовать на этих трех площадках. В Бордо сейчас 21 человек, и мы собираемся переехать на 30. Очень скоро во Франции мы собираемся открыть почти 160 позиций, большая часть которых находится на этом атлантическом побережье. Будет ли это в Бордо, Тулузе или Нантсе, на что я не могу ответить, потому что подбор персонала — это настоящая проблема в нашем секторе сегодня, это кандидаты, которые скажут нам!
В Бордо мы пытаемся построить полюс, который включает в себя два вида деятельности: веб-поддержка с усиленной командой поддержки и поддержка в области веб-хостинга и разработка контейнеров Kubernetes. Будет ли в Бордо офис на 100 человек, я не знаю, это будет зависеть от нашей привлекательности и объема профилей, соответствующих нашим потребностям, присутствующим на месте.

Вы изо всех сил пытаетесь найти эти профили или вы выбираете постепенный рост власти?

И я не рекламирую, что OVH собирается набрать 500 или 1000 человек в ближайшие несколько месяцев, я предпочитаю постоянный поток прибывающих на наши разные сайты, а не наем 200 человек Внезапно, что крайне сложно для управления, в настоящее время мы нанимаем десятки людей, потому что мы знаем, что в периоды роста мы должны приветствовать новые команды, обучать их, помогать им понять стратегию. Необходимо сохранять наши ценности и удовлетворять новичков, потому что это важный вопрос, рекрутинг является инвестицией, а конкуренция сильна. Следует также понимать, что OVH сегодня является глобальным игроком и, следовательно, имеет много международный набор — даже большинство, все эти вакансии доступны на нашем сайте OVH.

OVH (для On Host hosts) работает в почти 140 странах и имеет 28 центров обработки данных, в 19 странах, где работают 1,3 миллиона клиентов, и является специалистом в области размещения инфраструктуры в облаке. Компания, основанная Октавой Клабой, ее знаковым руководителем, обращается к рынку компаний и разработчиков и достигла оборота в 500 млн. Евро в последний закрытый финансовый год в августе 2018 года. В настоящее время в ней работают 2200 человек. и установить отметку в миллиард долларов к 2021 году.

Это немного яснее, и это дает представление о том, что уже предложено и то, что происходит в качестве нового продукта в течение 3 месяцев.

Как и все участники ИТ-сектора, 14 мая 2019 года компания OVH была проинформирована об уязвимостях системы безопасности после обнаружения аппаратных уязвимостей на процессорах Intel.

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


Эти сбои обозначаются как RIDL, Fallout или ZombieLoad и включают в себя следующие векторы атаки:

• CVE-2018-12126 [выборка данных буфера микроархитектурного хранилища (MSBDS)]
• CVE-2018-12130 [выборка данных микроархитектурного буфера заполнения (MFBDS)]
• CVE-2018-12127 [микроархитектурная выборка данных порта нагрузки (MLPDS)]
• CVE-2019-11091 [микроархитектурная выборка данных без кэшируемой памяти (MDSUM)]

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

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

Создание надежного облака сопряжено с большой ответственностью, а безопасность данных его клиентов всегда была для OVH первостепенной.

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

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

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

• Windows: support.microsoft.com/en-us/help/4072698/windows-server-speculative-execution-side-channel-vulnerabilities-prot
• Linux Red Hat: access.redhat.com/security/vulnerabilities/mds
• Ubuntu: blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigate-new-microarchitectural-data-sampling-mds-vulnerabilities

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

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

Мы начали с разделения проблемы на четыре основных этапа:

• Сбор информации
• Хранилище данных
• Аналитика данных
• Визуализация / действия
• Сбор информации

Как мы собирали огромные объемы данных о работоспособности сервера ненавязчивым образом за короткие промежутки времени?


Какие данные собирать?
На современных серверах BMC (Board Management Controller) позволяет нам контролировать обновления прошивки, перезагрузки и т. Д. Этот контроллер не зависит от системы, работающей на сервере. Кроме того, BMC дает нам доступ к датчикам для всех компонентов материнской платы через шину I2C. Протокол, используемый для связи с BMC, является протоколом IPMI, доступным через LAN (RMCP).

Что такое IPMI?

• Интеллектуальный интерфейс управления платформой.
• Возможности управления и мониторинга независимо от операционной системы хоста.
• Под руководством INTEL, впервые опубликована в 1998 году.
• Поддерживается более чем 200 поставщиками компьютерных систем, такими как Cisco, DELL, HP, Intel, SuperMicro

Зачем использовать IPMI?

• Доступ к аппаратным датчикам (температура процессора, температура памяти, состояние шасси, питание и тд.)
• Нет зависимости от ОС (то есть решение без агента)
• Функции IPMI, доступные после сбоя ОС / системы
• Ограниченный доступ к функциям IPMI через пользовательские привилегии

Сбор данных из нескольких источников
Нам требовался масштабируемый и быстро реагирующий инструмент для сбора данных из нескольких источников, который собирал данные IPMI около 400 тыс. Серверов через фиксированные интервалы.


Akka Мы решили построить наш сборщик данных IPMI на платформе Akka. Akka — это инструментарий с открытым исходным кодом и среда выполнения, упрощающая создание параллельных и распределенных приложений на JVM.

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

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

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

API REST определен для связи со сборщиком данных двумя способами:

• Чтобы отправить конфигурации
• Получить информацию о контролируемых серверах

Узел кластера работает на одной JVM, и мы можем запустить один или несколько узлов на выделенном сервере. Каждый выделенный сервер, используемый в кластере, помещается в VRAC OVH. Пул шлюза IPMI используется для доступа к BMC каждого сервера, а связь между шлюзом и сборщиком данных IPMI защищена соединениями IPSEC.



Хранилище данных
Метрики OVH Конечно, мы используем сервис метрик OVH для хранения данных! Перед сохранением данных сборщик данных IPMI объединяет метрики, квалифицируя каждый датчик. Окончательное имя метрики определяется объектом, которому принадлежит датчик, и базовой единицей значения. Это облегчит процессы последующей обработки и визуализации / сравнения данных.

Каждый коллектор IPMI центра обработки данных передает свои данные на сервер оперативного кэша Metrics с ограниченным временем хранения. Вся важная информация сохраняется на сервере OVH Metrics.


Аналитика данных
Мы храним наши метрики в warp10. Warp 10 поставляется с языком сценариев временного ряда: WarpScript, который делает аналитику мощной, чтобы легко манипулировать и обрабатывать (на стороне сервера) наши собранные данные.

Мы определили три уровня анализа для мониторинга работоспособности серверов:

• Простая пороговая метрика на сервер.
• Используя службу метрических циклов OVH, мы объединяем данные по стойке и по комнате и вычисляем среднее значение. Мы устанавливаем порог для этого среднего значения, это позволяет обнаруживать стойки или общий отказ помещения в системе охлаждения или системы электропитания.
• Служба MLS OVH выполняет обнаружение аномалий в стойках и помещениях, прогнозируя возможное развитие метрик в зависимости от прошлых значений. Если значение метрики находится за пределами этого шаблона, возникает аномалия.

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


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

После того, как Advance, встань!
Диапазон Rise предлагает наши самые доступные по цене неокрашенные серверов. На основе Xeon платформа Intel, они гарантируют эффективные машины. Эти выделенные серверы также имеют пропускную способность 500 Мбит / с, и наши анти-DDoS, чтобы обеспечить оптимальную защиту. Они идеально подходят для размещения своих веб — сайтов для ваших потребностей в области виртуализации или для профессиональных приложений.
www.ovh.com/fr/serveurs_dedies/rise/


приглашение вебинар
Вторника, 30 Апрель 2019
Узнайте, как удовлетворить потребности вашего бизнеса
Наш эксперт представит преимущества принять выделенные серверы, наши голые новости металла, наш тренерский и как выбрать серверы, чтобы убедиться, что вы «облако готово!»
www.ovh.com/fr/events/el1164-ovh-webinar-nouvelle-gamme-serveurs-dedies-au-service-vos-besoins-metier


новая архитектура
Облако Базы данных
Воспользуйтесь сверхбыстрым хранение
Мы предлагаем новый способ хранения высокой скорости, на основе технологии NVMe SSD для костей v управляемых баз данных. Получите производительность до 10 раз на операции чтения и записи, по сравнению с предыдущими предложениями, и по той же цене!
www.ovh.com/fr/cloud/cloud-databases/


решение Здоровье
Найти нас на выставке HIT
Давайте поговорим о вашей информационной системе здравоохранения (HIS)
С 21 по 23 мая 2019 года, мы даем вам встречу в Paris Expo на стенде Q79. Вместе с нашим партнером VMware, мы сообщим Вам о решениях принять для размещения SIS в совершенно безопасной инфраструктуре.
www.ovh.com/fr/events/el1190-hit-salon-professionnel-leader-lit-sante

Служба OVH Managed Kubernetes предлагает вам полностью управляемый кластер, в котором вы выбираете выбранные рабочие узлы в каталоге постоянной производительности виртуальной машины OVH Public Cloud. В настоящее время мы изучаем лучший способ добавить поддержку для работников графических процессоров и «голого металла» (без виртуализации), чтобы вы могли смешивать и подбирать виртуальные машины для еще более специализированных и мощных конфигураций. Помогите нам сформировать новые функции нашего предложения Kubernetes, ответив на короткий опрос (рассказывающий о ваших потребностях в оборудовании и программном обеспечении, ваших конкретных случаях использования ...), и у вас будет возможность получить доступ к закрытой бета-версии в течение лета.
labs.ovh.com/gpu-baremetal-kubernetes-nodes

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



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

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

Начало Prescience
В какой-то момент все проекты машинного обучения сталкиваются с одной и той же проблемой: как преодолеть разрыв между прототипом системы машинного обучения и ее использованием в производственном контексте. Это было краеугольным камнем развития платформы машинного обучения в OVH.

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

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

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

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

Расширяя возможности
В такой компании, как OVH, много проблем можно решить с помощью методов машинного обучения. К сожалению, по каждому из этих вопросов невозможно назначить ученого, особенно если не установлено, стоит ли инвестировать. Несмотря на то, что наши специалисты по бизнесу не освоили все методы машинного обучения, они обладают обширными знаниями о данных. Опираясь на эти знания, они могут дать нам минимальное определение проблемы под рукой. Автоматизация предыдущих этапов (подготовка данных и выбор модели) позволяет специалистам быстро оценить возможные преимущества подхода машинного обучения. Тогда можно принять процесс быстрого выигрыша / быстрого отказа для потенциальных проектов. Если это удастся, мы можем, если необходимо, ввести в цикл исследователя данных.

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

Архитектура Prescience и рабочие процессы машинного обучения


По сути, платформа Prescience основана на технологиях с открытым исходным кодом, таких как Kubernetes для операций, Spark для обработки данных и Scikit-learn, XGBoost, Spark MLlib и Tensorflow для машинного обучения. Большая часть разработок Prescience заключалась в объединении этих технологий. Кроме того, все промежуточные выходы системы, такие как предварительно обработанные данные, этапы преобразования или модели, сериализуются с использованием технологий и стандартов с открытым исходным кодом. Это предотвращает привязку пользователей к Prescience в случае необходимости использования другой системы.

Взаимодействие пользователей с платформой Prescience стало возможным благодаря следующим элементам:

• пользовательский интерфейс
• клиент Python
• REST API

Давайте рассмотрим типичный рабочий процесс и дадим краткое описание различных компонентов…

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

CSV, отраслевой стандарт
Паркет, который довольно крутой (плюс автоматически документированный и сжатый)
Временной ряд, благодаря OVH Observability, работает на Warp10
Необработанные данные, предоставляемые каждым из этих источников, редко используются как есть в алгоритмах машинного обучения. Алгоритмы обычно ожидают, что числа будут работать. Поэтому первый шаг рабочего процесса выполняется компонентом Parser. Единственная задача Parser — обнаруживать типы и имена столбцов, в случае простых текстовых форматов, таких как CSV, хотя источники Parquet и Warp10 содержат схему, что делает этот шаг спорным. После ввода данных анализатор извлекает статистику, чтобы точно ее охарактеризовать. Полученные данные вместе со статистикой хранятся в нашей серверной памяти хранилища — Public Cloud Storage, работающей на OpenStack Swift.

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

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

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

Байесовская оптимизация


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

• Модель в холодном состоянии. Оптимизатор возвращает набор настроек по умолчанию для контроллера
• Контроллер распределяет начальные конфигурации по кластеру учащихся
• По завершении начальных конфигураций контроллер сохраняет результаты
• Оптимизатор запускает вторую итерацию и обучает модель на основе доступных данных.
• На основе полученной модели оптимизатор выводит лучших претендентов, которые можно попробовать. Рассматривается как их потенциальная эффективность, так и объем информации, который она предоставит для улучшения модели выбора.
• Контроллер распределяет новый набор конфигураций по кластеру и ждет новой информации, a.k.a вновь оцененных конфигураций. Конфигурации оцениваются с использованием K-кратной перекрестной проверки, чтобы избежать переоснащения.
• Когда доступна новая информация, запускается новая итерация оптимизации, и процесс начинается снова на шаге 4
• После предварительно определенного числа итераций оптимизация останавливается

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

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

Модель сервировки
На этом этапе модель обучается и экспортируется и готова к обслуживанию. Последний компонент платформы Prescience — это обслуживание Prescience. Это веб-сервис, который использует PMML и сохраненные модели и предоставляет REST API поверх. Поскольку преобразования экспортируются вместе с моделью, пользователь может запросить вновь развернутую модель, используя необработанные данные. Прогнозы теперь готовы к использованию в любом приложении.

Модельный мониторинг
Кроме того, одной из характерных особенностей машинного обучения является его способность адаптироваться к новым данным. В отличие от традиционных жестко заданных бизнес-правил, модель машинного обучения способна адаптироваться к базовым шаблонам. Для этого платформа Prescience позволяет пользователям легко обновлять источники, обновлять наборы данных и переучивать модели. Эти шаги жизненного цикла помогают поддерживать актуальность модели в отношении проблемы, которую необходимо решить. Затем пользователь может сопоставить частоту переподготовки с новой квалификацией данных. Они могут даже прервать процесс обучения в случае аномалии в конвейере генерации данных. Каждый раз, когда модель переобучается, вычисляется новый набор баллов и сохраняется в OVH Observability для мониторинга.

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

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

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

Разработка Prescience проводится командой служб машинного обучения. MLS состоит из четырех инженеров машинного обучения: Маэль, Адриен, Рафаэль и я. Командой руководит Гийом, который помог мне спроектировать платформу. Кроме того, в команду входят два исследователя данных, Оливье и Клемент, которые занимались внутренними случаями использования и предоставили нам обратную связь, и, наконец, Лоран: студент CIFRE, работающий над многоцелевой оптикой.

www.ovh.ie/dedicated_servers/rise/
www.ovh.ie/dedicated_servers/rise/prices/

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

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

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



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

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

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

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, управлять 7 000 серверов и поддерживать их работоспособность на основе самых ранних технологий 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 и многое другое.

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

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

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