Уязвимости ядра Linux, влияющие на компонент выборочного ACK

18 июня 2019 года в 19:00 по центральноевропейскому летнему времени были обнаружены 4 уязвимости, влияющие на стек TCP ядра Linux. Эти уязвимости связаны с целочисленным переполнением в ядре Linux, которое может привести к панике ядра, с одной стороны, и с алгоритмической сложностью реализации SACK, приводящей к исчерпанию ресурсов ЦП, с другой стороны. В обоих случаях влияние ограничивается доступностью сервиса.



Кто уязвим?

  • Все Linux Oses с ядром 2.6.29 и выше (с марта 2009 г.)
  • FreeBSD 12 использует стек RACK TCP. Обратите внимание, что, к счастью, это не стек по умолчанию, вы можете запустить следующую команду, чтобы указать, использует ли ваша система реализацию «RACK» или нет:
    # sysctl net.inet.tcp.cc.algorithm
  • Если вы открываете службу TCP в Интернете (веб-службу, ssh, rcp,…), ваша система потенциально может быть затронута, поскольку для успешной атаки требуется только установить TCP-канал.
  • Если ваша служба находится за брандмауэром или iptables / pfsense настроен так, чтобы открывать службу только для доверенных IP-адресов, вы в безопасности.

Как исправить?
Есть 3 разных способа, вам нужно выбрать только ОДИН из них.

1. Обновите ядро

Основные дистрибутивы Linux уже выпустили исправление:
  • Linux версии 4.4.182 или выше
  • Linux версии 4.9.182 или выше
  • Linux версии 4.14.127 или выше
  • Linux версии 4.19.52 или выше
  • Linux версии 5.1.11 или выше.
  • Обратите внимание, что ветка Linux версии 3.16 еще не была объявлена ​​исправляемой. (2019-06-18)
Кстати, загляните на веб-сайт вашего дистрибутива (Ubuntu, RedHat, SuSE,…) для получения более подробной информации, поскольку ваш поставщик мог бы перенести патч на собственную версию ядра.

2. Снижение риска брандмауэра

Атака основана на небольшом варианте MSS, который очень необычен для стандартного сетевого взаимодействия. Следовательно, вы можете отбросить все пакеты с помощью небольшой опции MSS, чтобы предотвратить атаку вашей системы. Например, правила iptables могут выглядеть так:

3. Отключить SACK (не рекомендуется)

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

Является ли эксплойт общедоступным?

Насколько нам известно (18.06.2019), публичных эксплойтов пока нет, но это, вероятно, вопрос часов / дней.

Краткие технические пояснения


CVE-2019-11477


Целочисленное переполнение 16-битного счетчика (tcp_skb_pcount) может произойти в ядре, которое приведет к ошибке BUG_ON (не совсем паника, но оставит вашу систему в нестабильном — потенциально непригодном для использования — состоянии).

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

Ваше ядро ​​будет хранить список неподтвержденных пакетов, который увеличивает 16-разрядный счетчик (tcp_skb_pcount), который в какой-то момент переполняется и вызывает ошибку сравнения, приводящую к BUG_ON.


CVE-2019-11478


Используя тот же предыдущий сценарий, злоумышленник может фрагментировать буфер сокета (SKB) ядра Linux, подтвердив только несколько пакетов. Затем структура данных фрагментируется, что снижает производительность и может заставить ядро ​​потреблять больше ЦП.


CVE-2019-11479


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



Идентификационные номера


Эти уязвимости упоминаются в общих уязвимостях и уязвимостях следующим образом:
  • CVE-2019-11477: SACK Panic (Linux> = 2.6.29) | CVSS: 8,2
  • CVE-2019-11478: медленная работа SACK (Linux <4.15) или чрезмерное использование ресурсов (все версии Linux) | CVSS: 5,3
  • CVE-2019-11479: чрезмерное потребление ресурсов из-за низких значений MSS (все версии Linux) | CVSS: 7,5
  • CVE-2019-5599: Медлительность SACK (FreeBSD 12 с использованием стека TCP RACK) | Низкая степень серьезности



Внешние ссылки

RAMBleed DRAM

В июне 11 — го, исследователи безопасности опубликовал статью под названием « RAMBleed Чтение Биты в памяти без доступа к ним ». В этой статье описывается вектор противодействия модулям динамической оперативной памяти (DRAM), которые уже уязвимы для атак типа Роухаммера.

Системы, использующие модули DRAM, защищенные от атак в стиле Rowhammer, остаются защищенными от RAMBleed.

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



Эта уязвимость упоминается как:

· CVE-2019-0174 cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0174

По словам исследователей, « RAMBleed имеет невысокую скорость чтения памяти — около 3–4 бит в секунду. Это дает достаточно времени для контрмер по очистке памяти, чтобы удалить кратковременные секретные данные из памяти цели ».

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

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

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

Веб-хостинг: как разместить 3 миллиона веб-сайтов?

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

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

Как выполнять массовые операции с данными быстрее, чем когда-либо, на основе Apache Spark и OVH Analytics Data Compute

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

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

90% всех данных в мире было создано за последние два года. Согласно IDC, объем данных в мире должен вырасти с 33 зеттабайт в 2018 году до 175 зеттабайт в 2025 году. Когда мы делаем базовое деление, это составляет примерно 34 ТБ данных на человека, включая все страны и топологии.



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

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

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

  1. Во-первых, нам нужны данные. Иногда эти источники данных могут быть разнородными (текст, аудио, видео, изображения и т. Д.), И нам может потребоваться «очистить» их, прежде чем они смогут эффективно использоваться.
  2. Далее нам потребуется вычислительная мощность. Подумайте еще раз о себе: наш мозг может выполнять множество вычислений и операций, но невозможно разделить одну задачу между несколькими мозгами. Попросите друга сделать с вами умножение, и вы убедитесь в этом сами. Но с компьютерами все возможно! Теперь мы можем распараллеливать вычисления на нескольких компьютерах (например, в кластере), что позволяет нам получать желаемые результаты быстрее, чем когда-либо.
  3. Наконец, нам нужна структура, представляющая собой набор инструментов, которые позволят вам использовать эту базу данных и эффективно вычислять мощность.



Шаг 1. Найдите подходящую структуру


Как вы увидите из названия этого поста, не секрет, что Apache Spark  — наш предпочтительный инструмент в OVH.

Мы выбрали Apache Spark, потому что это распределенная универсальная среда кластерных вычислений с открытым исходным кодом, которая имеет самое большое сообщество разработчиков открытого исходного кода в мире больших данных и работает до 100 раз быстрее, чем предыдущая среда кластерных вычислений. Hadoop MapReduce благодаря приятным функциям, таким как обработка в памяти и отложенная оценка. Apache Spark — это ведущая платформа для крупномасштабного SQL, пакетной обработки, потоковой обработки и машинного обучения с простым в использовании API, а для кодирования в Spark у вас есть возможность использовать разные языки программирования, включая Java, Scala., Python, R и SQL .

Другие инструменты, такие как Apache Flink и Beam, также выглядят очень многообещающими и будут частью наших будущих услуг.

Различные компоненты Apache Spark:

  • Apache Spark Core , который обеспечивает вычисления в памяти и составляет основу других компонентов
  • Spark SQL , который обеспечивает абстракцию структурированных и полуструктурированных данных.
  • Spark Streaming , который выполняет потоковый анализ с использованием преобразования RDD (Resilient Distributed Datasets).
  • MLib (библиотека машинного обучения) , которая представляет собой распределенную платформу машинного обучения над Spark.
  • GraphX , который представляет собой среду обработки распределенных графов поверх Spark.

Принцип архитектуры Apache Spark

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

Вот пример кода на Python, где мы будем читать файл и подсчитывать количество строк с буквой «a» и количество строк с буквой «b».

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

Вот пример кода на Python, где мы будем читать файл и подсчитывать количество строк с буквой «a» и количество строк с буквой «b».


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

Каждое действие ( count()в нашем примере) запускает задания. Затем Apache Spark разделит вашу работу на несколько задач, которые можно вычислить отдельно.

Apache Spark хранит данные в RDD (устойчивые распределенные наборы данных), которые представляют собой неизменяемую распределенную коллекцию объектов, а затем делит их на разные логические разделы, чтобы можно было обрабатывать каждую часть параллельно на разных узлах кластера.



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

Шаг 2. Найдите необходимую вычислительную мощность

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

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

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

Лучшим способом создания кластера является использование поставщика публичного облака. Таким образом, ваши серверы будут развернуты очень быстро, вы будете платить только за то, что потребляете, и сможете удалить кластер после завершения задачи обработки. Вы также сможете получить доступ к своим данным намного проще, чем при использовании локального решения. Не случайно, согласно IDC, к 2025 году половина всех данных в мире будет храниться в публичном облаке [3].



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

Шаг 3. Отдохните и откройте для себя OVH Analytics Data Compute

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

В OVH мы решили эту проблему, представив службу кластерных вычислений под названием Analytics Data Compute, которая на лету создаст готовый, полностью установленный и настроенный кластер Apache Spark. Используя эту услугу, вам не нужно тратить время на создание сервера, сети, брандмауэры и настройки безопасности на каждом узле вашего кластера. Вы просто сосредотачиваетесь на своих задачах, и нужный вам вычислительный кластер появится как по волшебству!

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

Идея довольно проста: вы запускаете задание Apache Spark как обычно через командную строку или API, и полный кластер Apache Spark будет построен на лету, специально для вашей работы. После завершения обработки мы удаляем кластер, и вам выставляется счет за использованные ресурсы (на данный момент на почасовой основе).

Таким образом, мы можем быстро масштабироваться от одной до тысяч виртуальных машин, позволяя использовать тысячи ядер ЦП и тысячи ГБ оперативной памяти.



Чтобы использовать Analytics Data Compute, вам необходимо загрузить небольшой пакет клиентского программного обеспечения с открытым исходным кодом из репозитория OVH, который называется ovh-spark-submit.

Этот клиент был создан с целью сохранения официального синтаксиса командной строки Spark-submit Apache Spark. Большинство параметров и синтаксиса одинаковы, хотя в версии OVH есть еще несколько параметров, связанных с управлением инфраструктурой и кластером. Таким образом, вы просто запрашиваете запуск своего кода над своими данными в кластере определенных узлов, и инструмент создаст кластер с указанным количеством узлов, установит все пакеты и программное обеспечение (включая Spark и его систему управления кластером)., а затем настройте сеть и брандмауэр. После создания кластера OVH Analytics Data Compute запустит ваш код Spark, вернет результат пользователю, а затем удалит все, как только это будет сделано. Намного эффективнее!

Приступим… Почувствуй силу!

Хорошая новость заключается в том, что если вы уже знакомы с командной строкой Spark-submit Apache Spark, вам не нужно изучать какие-либо новые инструменты командной строки, поскольку ovh-spark-submit использует почти те же параметры и команды.

Давайте посмотрим на пример, в котором мы вычислим десятичные дроби знаменитого числа Пи, сначала с использованием исходного синтаксиса Apache Spark, а затем с помощью клиента ovh-spark-submit:

./spark-submit \
	--class org.apache.spark.examples.SparkPi \
	--total-executor-cores 20 \
	SparkPI.jar 100

./ovh-spark-submit \
	--class org.apache.spark.examples.SparkPi \
	--total-executor-cores 20 \
	SparkPI.jar 100


Вы можете видеть, что единственная разница — это «ovh-» в начале командной строки, а все остальное такое же. И, запустив ovh-spark-submitкоманду, вы запустите задание на кластере компьютеров с 20 ядрами, а не только на своем локальном компьютере. Этот кластер полностью посвящен этому заданию, так как он будет создан после выполнения команды, а затем удален по завершении.

Другой пример — популярный вариант использования подсчета слов. Предположим, вы хотите подсчитать количество слов в большом текстовом файле, используя кластер из 100 ядер. Большой текстовый файл хранится в хранилище OpenStack Swift (хотя это может быть любая онлайн-система или облачная система хранения). Код Spark для этого вычисления в Java выглядит так:

JavaRDD<String> lines = spark.read().textFile("swift://textfile.abc/novel.txt").javaRDD();

JavaRDD<String> words = lines.flatMap(s -> Arrays.asList(SPACE.split(s)).iterator());
JavaPairRDD<String, Integer> ones = words.mapToPair(s -> new Tuple2<>(s, 1));
JavaPairRDD<String, Integer> counts = ones.reduceByKey((i1, i2) -> i1 + i2);
List<Tuple2<String, Integer>> output = counts.collect();


Мы также можем выбрать желаемую версию Spark. В этом примере мы выбрали Spark версии 2.4.0, и командная строка для запуска этого задания Spark выглядит так:

./ovh-spark-submit \
	--class JavaWordCount \
	--total-executor-cores 100 \
	--name wordcount1 \
	--version 2.4.0 \
	SparkWordCount-fat.jar 


Для создания кластера Spark мы используем узлы с четырьмя виртуальными ядрами и 15 ГБ ОЗУ. Следовательно, при выполнении этой команды будет создан кластер из 26 серверов (один для главного узла и 25 для рабочих), поэтому у нас будет 25 × 4 = 100 виртуальных ядер и 25 × 15 = 375 ГБ ОЗУ.

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

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



Кроме того, если вы перейдете на панель управления OpenStack Horizon в своей облачной учетной записи OVH, вы увидите все 26 серверов:



Задание Apache Spark будет выполнено в соответствии с файлом java-кода в jar, который мы отправили в кластер Spark, и результаты будут показаны на экране. Кроме того, результаты и полные файлы журнала будут сохранены как на локальном компьютере, так и в хранилище Swift пользователя.



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



Еще немного о вычислении данных OVH Analytics

Если вам интересно, вот некоторые дополнительные сведения о вычислении данных Analytics:

  • Все построено на публичном облаке OVH, а это значит, что все работает на OpenStack.
  • Вы можете выбрать версию Apache Spark, которую хотите запустить, прямо в командной строке. Вы также, конечно, можете запускать несколько кластеров с разными версиями.
  • Для каждого запроса будет создан новый выделенный кластер, который будет удален после завершения задания. Это означает, что нет проблем с безопасностью или конфиденциальностью, вызванных наличием нескольких пользователей в одном кластере.
  • У вас есть возможность оставить кластер после завершения работы. Если вы добавите параметр keep-infra в командную строку, кластер не будет удален, когда вы закончите. Затем вы можете отправить больше заданий в этот кластер или просмотреть более подробную информацию в журналах.
  • Компьютеры кластера создаются в вашем собственном проекте OVH Public Cloud, поэтому вы имеете полный контроль над компьютерами кластера.
  • Результаты и журналы вывода будут сохранены в Swift в вашем проекте OVH Public Cloud. Только у вас будет доступ к ним, и у вас также будет полная история всех ваших заданий Spark, сохраненных в папке, с сортировкой по дате и времени выполнения.
  • Ввод и вывод данных могут быть любого источника или формата. Когда дело доходит до хранилища, нет привязки к поставщику, поэтому вы не обязаны использовать только облачное хранилище OVH для хранения ваших данных и можете использовать любую онлайн-платформу или платформу облачного хранилища в общедоступном Интернете.
  • Вы можете получить доступ к панелям мониторинга Cluster и Spark и веб-интерфейсу через HTTPS.

Сосредоточимся на системах управления кластером

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

Когда дело доходит до систем управления кластером, есть несколько вариантов, но, чтобы все было быстро и просто, мы выбрали автономную систему управления кластером Spark. Это дает нашим пользователям свободу выбора любой версии Spark, а также ускоряет установку кластера по сравнению с другими вариантами. Если, например, мы выбрали Kubernetes в качестве нашей системы управления кластером, наши пользователи были бы ограничены Spark версии 2.3 или выше, а установка кластера потребовала бы больше времени. В качестве альтернативы, если бы мы хотели развернуть готовый к использованию кластер Kubernetes (например, OVH Managed Kubernetes), мы бы потеряли масштабируемость, потому что инфраструктура нашего кластера Apache Spark была бы по своей сути ограничена инфраструктурой кластера Kubernetes.. Но с нашим текущим дизайном,

Попробуй сам!

Чтобы начать работу с Analytics Data Compute, вам просто нужно создать облачную учетную запись на www.ovh.com, затем загрузить программное обеспечение ovh-spark-submit и запустить его, как описано на странице документации OVH . Кроме того, если вы примете участие в небольшом опросе на нашей странице OVH Labs , вы получите ваучер, который позволит вам протестировать Analytics Data Compute из первых рук с 20 евро на бесплатный кредит.
Если у вас есть какие-либо вопросы или вы хотите получить дополнительные объяснения, с нашей командой можно связаться через наш канал Gitter.

Развертывание платформы FaaS на OVH Managed Kubernetes с использованием OpenFaaS

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

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

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

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

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

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

Для этого есть таблица Helm!

Сказать: «Вы можете сделать это с Kubernetes!» почти новый " Для этого есть приложение!", но это не помогает многим людям, которые ищут решения. Поскольку этот вопрос возникал несколько раз, мы решили подготовить небольшой учебник о том, как развернуть и использовать платформу FaaS на OVH Managed Kubernetes.

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

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

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

OpenFaaS — платформа FaaS для Kubernetes



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

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

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

  • Функция Watchdog.  Крошечный HTTP-сервер golang, который преобразует любой образ Docker в бессерверную функцию
  • API шлюз , который обеспечивает внешний маршрут в функции и собирает метрику
  • UI портал , который создает и вызывает функцию
  • Интерфейс командной строки (по сути, клиент REST для шлюза API ), который может развернуть любой контейнер как функцию

Функции можно писать на многих языках (хотя я в основном использовал для тестирования JavaScript, Go и Python), используя удобные шаблоны или простой файл Dockerfile.



Развертывание OpenFaaS на управляемом OVH Kubernetes

Есть несколько способов установить OpenFaaS в кластере Kubernetes. В этом посте мы рассмотрим самый простой: установка с помощью Helm.

Если вам нужна информация о том, как установить и использовать Helm в кластере OVH Managed Kubernetes, вы можете следовать нашему руководству .

Официальная диаграмма Helm для OpenFaas доступна в репозитории faas-netes.

Добавление диаграммы OpenFaaS Helm

Диаграмма OpenFaaS Helm недоступна в стандартном stableрепозитории Helm, поэтому вам нужно добавить их репозиторий в вашу установку Helm:

helm repo add openfaas https://openfaas.github.io/faas-netes/
helm repo update


Создание пространств имен

Руководства OpenFaaS рекомендуют создать два пространства имен: одно для основных служб OpenFaaS, а другое — для функций:

kubectl apply -f https://raw.githubusercontent.com/openfaas/faas-netes/master/namespaces.yml


Создание секретов

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

# generate a random password
PASSWORD=$(head -c 12 /dev/urandom | shasum| cut -d' ' -f1)

kubectl -n openfaas create secret generic basic-auth \
    --from-literal=basic-auth-user=admin \
    --from-literal=basic-auth-password="$PASSWORD"


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

Развертывание диаграммы Helm

Helm диаграмма может быть развернута в трех режимах: LoadBalancer, NodePortи Ingress. Для наших целей самый простой способ — просто использовать наш внешний балансировщик нагрузки, поэтому мы развернем его LoadBalancerс --set serviceType=LoadBalancer опцией

Если вы хотите лучше понять разницу между этими тремя режимами, вы можете прочитать нашу статью в блоге «Получение внешнего трафика в Kubernetes — ClusterIp, NodePort, LoadBalancer и Ingress» .

Разверните диаграмму Helm следующим образом:

helm upgrade openfaas --install openfaas/openfaas \
    --namespace openfaas  \
    --set basic_auth=true \
    --set functionNamespace=openfaas-fn \
    --set serviceType=LoadBalancer


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

kubectl --namespace=openfaas get deployments -l "release=openfaas, app=openfaas"


Если он работает, вы должны увидеть список доступных deploymentобъектов OpenFaaS:

$ kubectl --namespace=openfaas get deployments -l "release=openfaas, app=openfaas"
NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
alertmanager   1         1         1            1           33s
faas-idler     1         1         1            1           33s
gateway        1         1         1            1           33s
nats           1         1         1            1           33s
prometheus     1         1         1            1           33s
queue-worker   1         1         1            1           33s


Установите интерфейс командной строки FaaS и войдите в API-шлюз

Самый простой способ взаимодействия с вашей новой платформой OpenFaaS — это установка faas-cliклиента командной строки для OpenFaaS на Linux или Mac (или в терминале WSL linux в Windows):

curl -sL https://cli.openfaas.com | sh


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

kubectl get svc -n openfaas gateway-external -o wide


Экспортируйте URL-адрес в OPENFAAS_URL переменную:

export OPENFAAS_URL=[THE_URL_OF_YOUR_LOADBALANCER]:[THE_EXTERNAL_PORT]


Примечание. Этот URL-адрес понадобится вам позже в руководстве, например, для доступа к порталу пользовательского интерфейса. Вы можете увидеть это в любой момент в терминальной сессии, выполнив echo $OPENFAAS_URL.

И подключаемся к шлюзу:

echo -n $PASSWORD | ./faas-cli login -g $OPENFAAS_URL -u admin --password-stdin


Теперь вы подключены к шлюзу и можете отправлять команды на платформу OpenFaaS.

По умолчанию на вашей платформе OpenFaaS не установлено никаких функций, что вы можете проверить с помощью faas-cli listкоманды.

В моем собственном развертывании (URL-адреса и IP-адреса изменены для этого примера) предыдущие операции дали:

$ kubectl get svc -n openfaas gateway-external -o wide
 NAME               TYPE           CLUSTER-IP    EXTERNAL-IP                        PORT(S)          AGE     SELECTOR
 gateway-external   LoadBalancer   10.3.xxx.yyy   xxxrt657xx.lb.c1.gra.k8s.ovh.net   8080:30012/TCP   9m10s   app=gateway

 $ export OPENFAAS_URL=xxxrt657xx.lb.c1.gra.k8s.ovh.net:8080

 $ echo -n $PASSWORD | ./faas-cli login -g $OPENFAAS_URL -u admin --password-stdin
 Calling the OpenFaaS server to validate the credentials...
 WARNING! Communication is not secure, please consider using HTTPS. Letsencrypt.org offers free SSL/TLS certificates.
 credentials saved for admin http://xxxrt657xx.lb.c1.gra.k8s.ovh.net:8080

$ ./faas-cli version
  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|
CLI:
 commit:  b42d0703b6136cac7b0d06fa2b212c468b0cff92
 version: 0.8.11
Gateway
 uri:     http://xxxrt657xx.lb.c1.gra.k8s.ovh.net:8080
 version: 0.13.0
 sha:     fa93655d90d1518b04e7cfca7d7548d7d133a34e
 commit:  Update test for metrics server
Provider
 name:          faas-netes
 orchestration: kubernetes
 version:       0.7.5 
 sha:           4d3671bae8993cf3fde2da9845818a668a009617

$ ./faas-cli list Function Invocations Replicas 


Развертывание и вызов функций

Вы можете легко развернуть функции на вашей платформе OpenFaaS с помощью интерфейса командной строки, с помощью этой команды: faas-cli up.

Давайте попробуем несколько примеров функций из репозитория OpenFaaS:

./faas-cli deploy -f https://raw.githubusercontent.com/openfaas/faas/master/stack.yml


Выполнение faas-cli listкоманды сейчас покажет развернутые функции:

$ ./faas-cli list
Function                          Invocations     Replicas
base64                            0               1    
echoit                            0               1    
hubstats                          0               1    
markdown                          0               1    
nodeinfo                          0               1    
wordcount                         0               1    


В качестве примера вызовем wordcount(функцию, которая принимает синтаксис команды unix wcи дает нам количество строк, слов и символов входных данных):

echo 'I love when a plan comes together' | ./faas-cli invoke wordcount


$ echo 'I love when a plan comes together' | ./faas-cli invoke wordcount
       1         7        34


Вызов функции без CLI

Вы можете использовать faas-cli describeкоманду, чтобы получить общедоступный URL-адрес вашей функции, а затем вызвать его напрямую из вашей любимой HTTP-библиотеки (или старой доброй curl):

$ ./faas-cli describe wordcount
Name:                wordcount
Status:              Ready
Replicas:            1
Available replicas:  1
Invocations:         1
Image:               functions/alpine:latest
Function process:    
URL:                 http://xxxxx657xx.lb.c1.gra.k8s.ovh.net:8080/function/wordcount
Async URL:           http://xxxxx657xx.lb.c1.gra.k8s.ovh.net:8080/async-function/wordcount
Labels:              faas_function : wordcount
Annotations:         prometheus.io.scrape : false

$ curl -X POST --data-binary "I love when a plan comes together" "http://xxxxx657xx.lb.c1.gra.k8s.ovh.net:8080/function/wordcount"
       0         7        33


Везде контейнеры ...

Самая привлекательная часть платформы FaaS — это возможность развертывать свои собственные функции.

В OpenFaaS вы можете написать эти функции на многих языках, а не только на обычных подозреваемых (JavaScript, Python, Go и т. Д.). Это связано с тем, что в OpenFaaS вы можете развернуть практически любой контейнер как функцию, хотя это означает, что вам нужно упаковать свои функции как контейнеры, чтобы развернуть их.

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

Если вам нужен частный реестр, вы можете установить его в кластере OVH Managed Kubernetes. В этом руководстве мы решили развернуть наш образ в официальном реестре Docker.

Написание нашей первой функции

В нашем первом примере мы собираемся создать и развернуть функцию приветственного слова в JavaScript, используя NodeJS. Начнем с создания и формирования папки функции:

mkdir hello-js-project
cd hello-js-project
../faas-cli new hello-js --lang node


Интерфейс командной строки загрузит шаблон функции JS из репозитория OpenFaaS, сгенерирует файл описания функции ( hello-js.ymlв данном случае) и папку для исходного кода функции ( hello-js). Для NodeJS вы найдете в этой папке package.json(например, для объявления возможных зависимостей вашей функции) и handler.js(основной код функции).

Отредактируйте, hello-js.yml чтобы задать имя изображения, которое вы хотите загрузить в реестр Docker:

version: 1.0
provider:
  name: openfaas
  gateway: http://6d6rt657vc.lb.c1.gra.k8s.ovh.net:8080
functions:
  hello-js:
    lang: node
    handler: ./hello-js
    image: ovhplatform/openfaas-hello-js:latest


Функция, описанная в handler.jsфайле, действительно проста. Он экспортирует функцию с двумя параметрами: a, contextкуда вы получите данные запроса, и a, callbackкоторый вы вызовете в конце своей функции, и куда вы передадите данные ответа.

handler.js
"use strict"

module.exports = (context, callback) => {
    callback(undefined, {status: "done"});
}


Давайте отредактируем его, чтобы отправить обратно наше приветственное сообщение:

"use strict"

module.exports = (context, callback) => {
    callback(undefined, {message: 'Hello world'});
}


Теперь вы можете создать образ Docker и отправить его в общедоступный реестр Docker:

# Build the image
../faas-cli build -f hello-js.yml
# Login at Docker Registry, needed to push the image
docker login     
# Push the image to the registry
../faas-cli push -f hello-js.yml


Поздравляю! Вы только что написали и развернули свою первую функцию OpenFaaS.

Использование портала пользовательского интерфейса OpenFaaS

Вы можете протестировать портал пользовательского интерфейса, указав в браузере URL-адрес шлюза OpenFaaS (тот, который вы указали для $OPENFAAS_URLпеременной) и при появлении запроса введите admin пользователя и пароль, который вы установили для $PASSWORD переменной.



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







Куда мы отправимся отсюда?

Итак, теперь у вас есть рабочая платформа OpenFaaS в кластере OVH Managed Kubernetes.

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

Уязвимости Intel

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

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



Исследователи представили доказательства концептуальных атак под названиями RIDL, Fallout и ZombieLoad, которые используют следующие векторы атак:


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


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

Оповещение на основе сбора данных IPMI

Проблема, которую нужно решить…

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

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

    • Сбор информации
    • Хранилище данных

    • Аналитика данных
    • Визуализация / действия

Сбор информации

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



Какие данные собирать?

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

Что такое IPMI?

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

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

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



Сбор данных из нескольких источников

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



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

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

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

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

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

  • Отправить конфигурации
  • Для получения информации об отслеживаемых серверах

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



Хранилище данных



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

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

Аналитика данных



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

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

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

Визуализация / действия

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





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

Частное облако OVH и HashiCorp Terraform - Часть 1

При обсуждении концепций DevOps и Infrastructure-as-a-Code быстро всплывают инструменты, разработанные HashiCorp. С Terraform HashiCorp предлагает простой способ автоматизации подготовки инфраструктуры как в общедоступных облаках, так и в локальной среде. Terraform имеет долгую историю развертывания и управления ресурсами публичного облака OVH. Например, вы можете найти полное руководство на GitHub. В этой статье мы сосредоточимся на использовании Terraform для взаимодействия с другим решением OVH: частным облаком.



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

Установка

Terraform доступен на веб-сайте HashiCorp практически для всех ОС в виде простого двоичного файла. Просто загрузите его и скопируйте в каталог в PATH вашей операционной системы. Чтобы проверить, что все работает правильно, запустите команду terraform.

$ terraform
Usage: terraform [-version] [-help] <command> [args]

The available commands for execution are listed below.
The most common, useful commands are shown first, followed by
less common or more advanced commands. If you're just getting
started with Terraform, stick with the common commands. For the
other commands, please read the help and docs before usage.

Common commands:
    apply              Builds or changes infrastructure
    console            Interactive console for Terraform interpolations
    destroy            Destroy Terraform-managed infrastructure


Папки и файлы

Как и другие инструменты «Инфраструктура как код», Terraform использует простые файлы для определения целевой конфигурации. Для начала мы создадим каталог и поместим файл с именем main.tf. По умолчанию Terraform будет читать все файлы в рабочем каталоге с .tfрасширением, но для упрощения мы начнем с одного файла. В следующей статье мы увидим, как организовать данные в несколько файлов.

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

Провайдеры

Провайдеры позволяют указать, как Terraform будет взаимодействовать с внешним миром. В нашем примере провайдер vSphere будет отвечать за подключение к vCenter вашего частного облака. Мы декларируем поставщика следующим образом:

provider "vsphere" {
    user = "admin"
    password = "MyAwesomePassword"
    vsphere_server = "pcc-XXX-XXX-XXX-XXX.ovh.com"
}


Здесь мы видим, что Terraform использует свой собственный способ структурирования данных (также можно записать все в JSON, чтобы облегчить автоматическое создание файлов! ). Данные сгруппированы в блоки (здесь блок с именем vsphere, который относится к типу провайдера ), а данные, относящиеся к блоку, представлены в форме ключей / значений.

Данные

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

data "vsphere_datacenter" "dc" {
  name = "pcc-XXX-XXX-XXX-XXX_datacenter3113"
}

data "vsphere_datastore" "datastore" {
  name          = "pcc-001234"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_virtual_machine" "template" {
  name          = "UBUNTU"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}


В приведенном выше примере, мы пытаемся получить информацию о центре обработки данных с именем pcc-XXX-XXX-XXX-XXX_datacenter3113и получить информацию из хранилища данных с именем pcc-001234и шаблона, имя которого является UBUNTU. Здесь мы видим, что мы используем идентификатор центра обработки данных, чтобы получить информацию об объекте, связанном с ним.

Ресурсы

Ресурсы будут использоваться для создания и / или управления элементами инфраструктуры. В нашем примере мы будем использовать ресурс типа virtual_machine, который, как следует из названия, поможет нам создать виртуальную машину.

resource "vsphere_virtual_machine" "vm" {
  name             = "vm01"
  resource_pool_id = "${data.vsphere_compute_cluster.cluster.resource_pool_id}"
  datastore_id     = "${data.vsphere_datastore.datastore.id}"
  guest_id         = "${data.vsphere_virtual_machine.template.guest_id}"
  scsi_type        = "${data.vsphere_virtual_machine.template.scsi_type}"

  network_interface {
    network_id = "${data.vsphere_network.network.id}"
  }

  disk {
    label = "disk0"
    size  = "${data.vsphere_virtual_machine.template.disks.0.size}"
  }

  clone {
    template_uuid = "${data.vsphere_virtual_machine.template.id}"

    customize {
      linux_options {
        host_name = "vm01"
        domain     = "example.com"
      }

      network_interface {
        ipv4_address = "192.168.1.2"
        ipv4_netmask = 24
      }

      ipv4_gateway    = "192.168.1.254"
      dns_suffix_list = ["example.com"]
      dns_server_list = ["192.168.1.1"]
    }
  }
}


Структура этого ресурса немного сложнее, потому что она состоит из нескольких подблоков. Мы видим, что сначала мы определим имя виртуальной машины. Затем мы предоставляем информацию о его конфигурации (пул ресурсов, хранилище данных и т. Д.). И блоки используются, чтобы определить конфигурацию своих виртуальных устройств. Субблок позволит вам указать, какой шаблон вы хотите использовать для создания виртуальной машины, а также указать информацию о конфигурации операционной системы, установленной на виртуальной машине. Субблок является специфическим для типа ОС, которую вы хотите клонировать. На всех уровнях мы используем информацию, полученную ранее в блоках.network_interfacedisk clone customize data

Полный пример

provider "vsphere" {
    user = "admin"
    password = "MyAwesomePassword"
    vsphere_server = "pcc-XXX-XXX-XXX-XXX.ovh.com"
}

data "vsphere_datacenter" "dc" {
  name = "pcc-XXX-XXX-XXX-XXX_datacenter3113"
}

data "vsphere_datastore" "datastore" {
  name          = "pcc-001234"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_compute_cluster" "cluster" {
  name          = "Cluster1"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_network" "network" {
  name          = "vxw-dvs-57-virtualwire-2-sid-5001-Dc3113_5001"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_virtual_machine" "template" {
  name          = "UBUNTU"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

resource "vsphere_virtual_machine" "vm" {
  name             = "vm01"
  resource_pool_id = "${data.vsphere_compute_cluster.cluster.resource_pool_id}"
  datastore_id     = "${data.vsphere_datastore.datastore.id}"
  guest_id         = "${data.vsphere_virtual_machine.template.guest_id}"
  scsi_type        = "${data.vsphere_virtual_machine.template.scsi_type}"

  network_interface {
    network_id = "${data.vsphere_network.network.id}"
  }

  disk {
    label = "disk0"
    size  = "${data.vsphere_virtual_machine.template.disks.0.size}"
  }

  clone {
    template_uuid = "${data.vsphere_virtual_machine.template.id}"

    customize {
      linux_options {
        host_name = "vm01"
        domain     = "example.com"
      }

      network_interface {
        ipv4_address = "192.168.1.2"
        ipv4_netmask = 24
      }

      ipv4_gateway    = "192.168.1.254"
      dns_suffix_list = ["example.com"]
      dns_server_list = ["192.168.1.1"]
    }
  }
}


3… 2… 1… Зажигание

Давайте посмотрим, как использовать наш новый файл конфигурации с Terraform…



Инициализация

Теперь, когда наш файл конфигурации готов, мы сможем использовать его для создания нашей виртуальной машины. Начнем с инициализации рабочей среды с помощью terraform initкоманды. Это позаботится о загрузке поставщика vSphere и создании различных файлов, необходимых Terraform для работы.

$ terraform init

Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "vsphere" (1.10.0)...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

...

* provider.vsphere: version = "~> 1.10"

Terraform has been successfully initialized!
...


Строить планы

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

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.vsphere_datacenter.dc: Refreshing state...
data.vsphere_compute_cluster.cluster: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  + vsphere_virtual_machine.vm
      id:                                                   <computed>
      boot_retry_delay:                                     "10000"
      change_version:                                       <computed>
      clone.#:                                              "1"
      clone.0.customize.#:                                  "1"
      clone.0.customize.0.dns_server_list.#:                "1"
      clone.0.customize.0.dns_server_list.0:                "192.168.1.1"
      clone.0.customize.0.dns_suffix_list.#:                "1"
      clone.0.customize.0.dns_suffix_list.0:                "example.com"
      clone.0.customize.0.ipv4_gateway:                     "172.16.0.1"
      clone.0.customize.0.linux_options.#:                  "1"
      clone.0.customize.0.linux_options.0.domain:           "example.com"
      clone.0.customize.0.linux_options.0.host_name:        "vm01"
      clone.0.customize.0.linux_options.0.hw_clock_utc:     "true"
      clone.0.customize.0.network_interface.#:              "1"
      clone.0.customize.0.network_interface.0.ipv4_address: "192.168.1.2"
      clone.0.customize.0.network_interface.0.ipv4_netmask: "16"
      clone.0.customize.0.timeout:                          "10"
      clone.0.template_uuid:                                "42061bc5-fdec-03f3-67fd-b709ec06c7f2"
      clone.0.timeout:                                      "30"
      cpu_limit:                                            "-1"
      cpu_share_count:                                      <computed>
      cpu_share_level:                                      "normal"
      datastore_id:                                         "datastore-93"
      default_ip_address:                                   <computed>
      disk.#:                                               "1"
      disk.0.attach:                                        "false"
      disk.0.datastore_id:                                  "<computed>"
      disk.0.device_address:                                <computed>
      ...

Plan: 1 to add, 0 to change, 0 to destroy.


Перед продолжением важно уделить время проверке всей информации, возвращаемой командой. Было бы беспорядком удалять виртуальные машины в производственной среде из-за ошибки в файле конфигурации… В приведенном ниже примере мы видим, что Terraform создаст новый ресурс (здесь виртуальная машина), а не изменит и не удалит ничего, что в точности Цель!

Применять

На последнем этапе terraform applyкоманда фактически настроит инфраструктуру в соответствии с информацией, содержащейся в файле конфигурации. В качестве первого шага planкоманда будет выполнена, и Terraform попросит вас подтвердить ее, набрав yes.

$ terraform apply
...

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

vsphere_virtual_machine.vm: Creating...
  boot_retry_delay:                                     "" => "10000"
  change_version:                                       "" => "<computed>"
  clone.#:                                              "" => "1"
  clone.0.customize.#:                                  "" => "1"
  clone.0.customize.0.dns_server_list.#:                "" => "1"
  clone.0.customize.0.dns_server_list.0:                "" => "192.168.1.1"
  clone.0.customize.0.dns_suffix_list.#:                "" => "1"
  clone.0.customize.0.dns_suffix_list.0:                "" => "example.com"
  clone.0.customize.0.ipv4_gateway:                     "" => "192.168.1.254"
  clone.0.customize.0.linux_options.#:                  "" => "1"
  clone.0.customize.0.linux_options.0.domain:           "" => "example.com"
  clone.0.customize.0.linux_options.0.host_name:        "" => "terraform-test"
  clone.0.customize.0.linux_options.0.hw_clock_utc:     "" => "true"
  clone.0.customize.0.network_interface.#:              "" => "1"
  clone.0.customize.0.network_interface.0.ipv4_address: "" => "192.168.1.2"
  clone.0.customize.0.network_interface.0.ipv4_netmask: "" => "16"
  clone.0.customize.0.timeout:                          "" => "10"
  clone.0.template_uuid:                                "" => "42061bc5-fdec-03f3-67fd-b709ec06c7f2"
  clone.0.timeout:                                      "" => "30"
  cpu_limit:                                            "" => "-1"
  cpu_share_count:                                      "" => "<computed>"
  cpu_share_level:                                      "" => "normal"
  datastore_id:                                         "" => "datastore-93"
  default_ip_address:                                   "" => "<computed>"
  disk.#:                                               "" => "1"
...
vsphere_virtual_machine.vm: Still creating... (10s elapsed)
vsphere_virtual_machine.vm: Still creating... (20s elapsed)
vsphere_virtual_machine.vm: Still creating... (30s elapsed)
...
vsphere_virtual_machine.vm: Still creating... (1m50s elapsed)
vsphere_virtual_machine.vm: Creation complete after 1m55s (ID: 42068313-d169-03ff-9c55-a23e66a44b48)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.


Когда вы подключаетесь к vCenter вашего частного облака, вы должны увидеть новую виртуальную машину в инвентаре!

Следующие шаги

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

disk {
  label = "disk0"
  size  = "${data.vsphere_virtual_machine.template.disks.0.size}"
}

disk {
  label = "disk1"
  size  = "${data.vsphere_virtual_machine.template.disks.0.size}"
  unit_number = 1
}


Затем запустите, terraform planчтобы увидеть, что Terraform собирается сделать, чтобы согласовать состояние инфраструктуры с вашим файлом конфигурации.

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.vsphere_datacenter.dc: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_compute_cluster.cluster: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...
vsphere_virtual_machine.vm: Refreshing state... (ID: 4206be6f-f462-c424-d386-7bd0a0d2cfae)

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ vsphere_virtual_machine.vm
      disk.#:                  "1" => "2"
      disk.1.attach:           "" => "false"
      disk.1.datastore_id:     "" => "<computed>"
      ...


Plan: 0 to add, 1 to change, 0 to destroy.


Если вы согласны с предложением действия terraform, вы можете запустить его повторно terraform apply, чтобы добавить новый виртуальный диск к вашей виртуальной машине.

Приберись

Когда вы закончили свои тесты, и вы больше не требуется полезность инфраструктуры, у НУ можете просто запустить terraform destroyкоманду, чтобы удалить все ранее созданные ресурсы. Будьте осторожны с этой командой, так как после этого нет возможности вернуть ваши данные!

$ terraform destroy

data.vsphere_datacenter.dc: Refreshing state...
data.vsphere_compute_cluster.cluster: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...
vsphere_virtual_machine.vm: Refreshing state... (ID: 42068313-d169-03ff-9c55-a23e66a44b48)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  - vsphere_virtual_machine.vm


Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

vsphere_virtual_machine.vm: Destroying... (ID: 42068313-d169-03ff-9c55-a23e66a44b48)
vsphere_virtual_machine.vm: Destruction complete after 3s

Destroy complete! Resources: 1 destroyed.


В этой статье мы увидели, как развернуть виртуальную машину с файлом конфигурации Terraform. Это позволило нам узнать основные команды plan, applyи destroy, а также понятия provider, dataи resource. В следующей статье мы разработаем этот пример, изменив его, чтобы сделать его более адаптируемым и универсальным.

Prescience: знакомство с платформой машинного обучения OVH

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



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

В настоящее время Prescience используется в производственных масштабах для решения различных задач, с которыми сталкивается OVH, а его альфа-версия доступна для бесплатного изучения в OVH Labs. В этом сообщении блога мы познакомим вас с 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. Единственная задача парсера — обнаруживать типы и имена столбцов в случае текстовых форматов, таких как CSV, хотя исходники Parquet и Warp10 включают схему, что делает этот шаг спорным. После ввода данных парсер извлекает статистику, чтобы точно охарактеризовать ее. Полученные данные вместе со статистикой хранятся в нашем серверном хранилище объектов — публичном облачном хранилище на базе OpenStack Swift.

Преобразование данных

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

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

Выбор модели

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

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



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

  1. Модель находится в холодном состоянии. Оптимизатор возвращает контроллеру набор начальных конфигураций по умолчанию.
  2. Контроллер распределяет начальные конфигурации по кластеру учащихся.
  3. По завершении начальных настроек контроллер сохраняет результаты
  4. Оптимизатор запускает вторую итерацию и обучает модель доступным данным.
  5. На основе полученной модели оптимизатор выводит лучших претендентов, которые можно попробовать. Учитываются как их потенциальная эффективность, так и объем информации, которую они предоставят для улучшения модели выбора.
  6. Контроллер распределяет новый набор конфигураций по кластеру и ожидает новой информации, также известной как недавно оцененные конфигурации. Конфигурации оцениваются с использованием перекрестной проверки в K-кратном порядке, чтобы избежать переобучения.
  7. Когда становится доступной новая информация, запускается новая итерация оптимизации, и процесс начинается снова с шага 4.
  8. После заданного количества итераций оптимизация останавливается.

Проверка модели

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

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

Модель сервировки

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

Мониторинг модели

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

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

Переход к компании, управляемой искусственным интеллектом

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

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

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

Веб-хостинг - почему мы решили перенести три миллиона веб-сайтов

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

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

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

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

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

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