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

Давайте подумаем о себе… Теперь у нас есть смартфоны, которые делают снимки и отправляют текстовые сообщения, спортивные часы, собирающие данные о нашем здоровье, учетные записи 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.

Несколько недель назад я участвовал в митапе, посвященном 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, чтобы получить больше практических советов и советов.

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

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



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

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

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

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

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

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

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

При обсуждении концепций 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. В следующей статье мы разработаем этот пример, изменив его, чтобы сделать его более адаптируемым и универсальным.

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

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

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

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

Одним из ключевых преимуществ использования Kubernetes является огромная экосистема вокруг него. От Rancher к Istio , от Грача до ДЕЛЕНИЯ , от gVisor к KubeDB , экосистема Kubernetes богата, живая и постоянно растет. Мы подходим к тому моменту, когда для большинства потребностей развертывания мы можем сказать, что для этого существует проект с открытым исходным кодом на основе K8s .

Одним из latests дополнений в этой экосистеме является Agones проект с открытым исходным кодом, мультиплеер, посвященный игровой сервер хостинг построен на Kubernetes, разработанный Google в сотрудничестве с Ubisoft . О проекте было объявлено в марте , и он уже наделал много шума…

В OVH Platform Team мы фанаты как онлайн-игр, так и Kubernetes, поэтому мы сказали себе, что нам нужно протестировать Agones. И что может быть лучше для его тестирования, чем развертывание в нашей службе OVH Managed Kubernetes , установка кластера игровых серверов Xonotic и участие в некоторых олдскульных смертельных матчах с коллегами?



И, конечно же, нам нужно было написать об этом, чтобы поделиться опытом…

Почему Агоны?

Agones ( происходящее от греческого слова ag, n, соревнования, проводимые во время публичных фестивалей или, в более общем смысле, «соревнование» или «соревнование в играх») призвано заменить обычные проприетарные решения для развертывания, масштабирования и управления игровыми серверами.

Agones обогащает Kubernetes настраиваемым контроллером и настраиваемым определением ресурса. С их помощью вы можете стандартизировать инструменты и API Kubernetes для создания, масштабирования и управления кластерами игровых серверов.

Постой, о каких игровых серверах ты говоришь?

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

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

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

А как подключить игроков к нужному серверу?

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



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

Вишенка на торте

Использование Kubernetes для этих задач также дает приятный дополнительный бонус, например, возможность развернуть полную игровую инфраструктуру в среде разработчика (или даже в мини-кубе ) или легко клонировать ее для развертывания в новом центре обработки данных или облачном регионе, но также предлагая целую платформу для размещения всех дополнительных услуг, необходимых для создания игры: управление учетными записями, списки лидеров, инвентарь…

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

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

Есть несколько способов установить Agones в кластер Kubernetes. Для нашего теста мы выбрали самый простой: установку с помощью Helm.

Включение создания ресурсов RBAC

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

kubectl cre

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin --serviceaccount=kube-system:default

Теперь у нас есть привязка роли кластера, необходимая для установки.

Установка диаграммы Agones

Теперь продолжим, добавив репозиторий Agones в список репозиториев Helm.

helm repo add agones https://agones.dev/chart/stable

А затем установите стабильную диаграмму Agones:

helm install --name my-agones --namespace agones-system agones/agones

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

Подтверждение успешного запуска Agones

Чтобы убедиться, что Agones работает в нашем кластере Kubernetes, мы можем взглянуть на поды в agones-systemпространстве имен:

kubectl get --namespace agones-system pods

Если все в порядке, вы должны увидеть agones-controllerмодуль со статусом " Работает":

$ kubectl get --namespace agones-system pods
NAME                                 READY   STATUS    RESTARTS   AGE
agones-controller-5f766fc567-xf4vv   1/1     Running   0          5d15h
agones-ping-889c5954d-6kfj4          1/1     Running   0          5d15h
agones-ping-889c5954d-mtp4g          1/1     Running   0          5d15h

Вы также можете увидеть более подробную информацию, используя:

kubectl describe --namespace agones-system pods

Посмотрев на agones-controllerописание, вы должны увидеть что-то вроде:

$ kubectl describe --namespace agones-system pods
Name:               agones-controller-5f766fc567-xf4vv
Namespace:          agones-system
[...]
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 

Где все Conditionsдолжно иметь статус True.

Развертывание игрового сервера

Мир Agones Hello довольно скучный, простой эхо-сервер UDP, поэтому мы решили пропустить его и перейти непосредственно к чему-то более интересному: игровому серверу Xonotic.

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

Развернуть игровой сервер Xonotic поверх Agones довольно просто:

kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/agones/release-0.9.0/examples/xonotic/gameserver.yaml

Развертывание игрового сервера может занять некоторое время, поэтому нам нужно дождаться его статуса, Readyпрежде чем его использовать. Мы можем получить статус с помощью:

kubectl get gameserver

Мы ждем, пока выборка не выдаст Readyстатус на нашем игровом сервере:

$ kubectl get gameserver
NAME      STATE   ADDRESS         PORT   NODE       AGE
xonotic   Ready   51.83.xxx.yyy   7094   node-zzz   5d

Когда игровой сервер готов, мы также получаем адрес и порт, который мы должны использовать для подключения к нашей игре deathmatch (в моем примере 51.83.xxx.yyy:7094).

Время фрага

Итак, теперь, когда у нас есть сервер, давайте протестируем его!

Мы загрузили клиент Xonotic для наших компьютеров (он работает в Windows, Linux и MacOS, поэтому нет оправдания) и запустили его:



Затем заходим в меню многопользовательской игры и вводим адрес и порт нашего игрового сервера:



И мы готовы играть!

А на стороне сервера?

На стороне сервера мы можем следить за тем, как идут дела на нашем игровом сервере, используя kubectl logs. Начнем с поиска модуля, в котором запущена игра:

kubectl get pods

Мы видим, что наш игровой сервер работает в модуле под названием xonotic:

$ kubectl get pods 
NAME      READY   STATUS    RESTARTS   AGE
xonotic   2/2     Running   0          5d15h

Затем мы можем использовать kubectl logsего. В модуле есть два контейнера, основной xonoticи вспомогательный Agones, поэтому мы должны указать, что нам нужны журналы xonoticконтейнера:

$ kubectl logs xonotic
Error from server (BadRequest): a container name must be specified for pod xonotic, choose one of: [xonotic agones-gameserver-sidecar]
$ kubectl logs xonotic xonotic
>>> Connecting to Agones with the SDK
>>> Starting health checking
>>> Starting wrapper for Xonotic!
>>> Path to Xonotic server script: /home/xonotic/Xonotic/server_linux.sh 
Game is Xonotic using base gamedir data
gamename for server filtering: Xonotic
Xonotic Linux 22:03:50 Mar 31 2017 - release
Current nice level is below the soft limit - cannot use niceness
Skeletal animation uses SSE code path
execing quake.rc
[...]
Authenticated connection to 109.190.xxx.yyy:42475 has been established: client is v6xt9/GlzxBH+xViJCiSf4E/SCn3Kx47aY3EJ+HOmZo=@Xon//Ks, I am /EpGZ8F@~Xon//Ks
LostInBrittany is connecting...
url_fclose: failure in crypto_uri_postbuf
Receiving player stats failed: -1
LostInBrittany connected
LostInBrittany connected
LostInBrittany is now spectating
[BOT]Eureka connected
[BOT]Hellfire connected
[BOT]Lion connected
[BOT]Scorcher connected
unconnected changed name to [BOT]Eureka
unconnected changed name to [BOT]Hellfire
unconnected changed name to [BOT]Lion
unconnected changed name to [BOT]Scorcher
[BOT]Scorcher picked up Strength
[BOT]Scorcher drew first blood! 
[BOT]Hellfire was gunned down by [BOT]Scorcher's Shotgun
[BOT]Scorcher slapped [BOT]Lion around a bit with a large Shotgun
[BOT]Scorcher was gunned down by [BOT]Eureka's Shotgun, ending their 2 frag spree
[BOT]Scorcher slapped [BOT]Lion around a bit with a large Shotgun
[BOT]Scorcher was shot to death by [BOT]Eureka's Blaster
[BOT]Hellfire slapped [BOT]Eureka around a bit with a large Shotgun, ending their 2 frag spree
[BOT]Eureka slapped [BOT]Scorcher around a bit with a large Shotgun
[BOT]Eureka was gunned down by [BOT]Hellfire's Shotgun
[BOT]Hellfire was shot to death by [BOT]Lion's Blaster, ending their 2 frag spree
[BOT]Scorcher was cooked by [BOT]Lion
[BOT]Eureka turned into hot slag
[...]

Добавить друзей…

Следующий шаг в основном доставляет удовольствие: попросить коллег подключиться к серверу и провести настоящий смертельный бой, как в Quake 2 раза.

И сейчас?

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

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

В 2017 году многие факторы способствовали значительному росту OVH: найм в Европе; приобретение компании в США; строительство 14 новых дата-центров; и начало деятельности в Азиатско-Тихоокеанском регионе. Менее чем за 18 месяцев мы удвоили количество сотрудников с двенадцати сотен до двадцати пятисот. Я не рекомендую масштабировать так быстро!

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



Один из разработанных мною инструментов имеет аббревиатуру « BFLNT ». Название не очень сексуальное, но выполняет свою работу. Я предложил использовать этот инструмент для изучения всей организации OVH, чтобы ответить на несколько простых вопросов, которые необходимо задать при наборе персонала в цифровой компании. Вот некоторые из этих вопросов: 

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

Это не единственная основа для определения структуры цифрового предприятия. Если вам известны другие подобные инструменты, не стесняйтесь делиться ими в Twitter @olesovhcom. 

B: BAU = Бизнес как обычно

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

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

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



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

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

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

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

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

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

twitter.com/olesovhcom/status/1109533124336254981?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1109533336417042432%7Ctwgr%5Eshare_3&ref_url=https%3A%2F%2Fwww.ovh.com%2Fblog%2Fthe-role-of-humans-in-digital-businesses%2F

BAU основана на идеальной компании, но мы знаем, что идеального мира не существует. По этой причине я создал еще 4 функции BFLNT: 

• F: FIX 
• L: LEAN 
• N: НОВИНКА 
• Т: ПРЕОБРАЗОВАНИЕ  

F: FIX

Поскольку невозможно предоставить BAU без сбоев, проекты, процессы и команды FIX готовы решать непредвиденные проблемы.

В OVH наши команды RUN работают над 2 миссиями 24/7:  

• Отслеживайте заказанные клиентами, предоставляемые BAU услуги и ИСПРАВЛЕНИЯ программного обеспечения, которые автоматически исправляют ошибки в программном обеспечении BAU. Команды RUN также вмешиваются, когда программное обеспечение FIX не исправляет ошибки.
• Реагируйте на клиентов, сообщающих об инцидентах, пропущенных мониторингом. Даже самый лучший мониторинг не может представить все возможные проблемы.  

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

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

Американские компании, вероятно, понимают важность FIX больше, чем европейские. Значительные инвестиции в FIX в эти компании связаны с FIX в их ДНК. Из-за огромной стоимости FIX американские цифровые компании стремятся увеличить объемы и выйти на мировой рынок как один из способов уменьшить влияние расходов FIX на бизнес-модель.

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

L: LEAN

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

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

Обоснование таких небольших постепенных улучшений скорости не является защитным, потому что наши конкуренты будут делать это. Команды LEAN страстно и постоянно выходят за рамки собственных возможностей в том, что Саймон Синек называет «Бесконечной игрой». Это спорт, которому нет предела.

N: НОВИНКА

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

Но NEW — это не только написание кода. NEW должен учитывать потребности клиентов и бизнес-модель, которая включает цену, стоимость, объем и размер рынка. Как только мы рассмотрим эти факторы, мы сосредоточимся на программном обеспечении. НОВЫМ командам требуются маркетинговые, технические и финансовые ноу-хау при разработке новых продуктов.  

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

Компромисс и сбои также являются частью портфолио NEW Team. Клиент всегда хочет, чтобы 1 + 1 равнялось 3, и нам нужно выполнить поставку, что требует нестандартного мышления. Примером успеха OVH в этой области является охлаждение центров обработки данных, которое мы разработали в 2003 году. С самого начала мы были убеждены, что найдем способ охлаждать центры обработки данных водой, аналогично тому, как применялось жидкостное охлаждение. разработан для охлаждения автомобильных двигателей. Мы просто сказали себе, что это возможно, а затем сделали это возможным. Этот пример показывает, что цифровые компании нечасто создают действительно новые изобретения . На самом деле мы адаптируем существующие технологии в новых условиях. Это истинное значение слова взломать. 

Появление ИИ во многом разрушает индустрию программного обеспечения. НОВЫЕ и LEAN программного кода AI которые «Автоматы с »  на разработчиках .  Начало. Это отличная тема для будущего сообщения в блоге. 

Т: ПРЕОБРАЗОВАНИЕ

ТРАНСФОРМАЦИЯ бизнеса — это хорошо известный процесс. Иногда ТРАНСФОРМАЦИЯ необходима, потому что компания работает неэффективно и ее необходимо реструктурировать. Иногда ТРАНСФОРМАЦИЯ необходима, потому что компания очень успешна и растет, поэтому ей необходимо преобразовать процессы и организацию, чтобы эффективно работать в более широком масштабе.

В цифровых компаниях чаще встречается ПРЕОБРАЗОВАНИЕ к плоским трансверсальным моделям, в которых организации используют коллективный разум. У этих компаний нет роскоши платить за организационную разобщенность, борьбу с эгоизмом или медленное исполнение из-за недостатка информации. Цифровой гр ompanies га Ve  surviv ал  в их  ДНК. Представьте живое существо, созданное матерью-природой, органы которого автономны и взаимозависимы. При этом уделяется внимание вовлечению в компанию мужчин и женщин из разных стран, разных стран и способов мышления, что позволяет им эффективно работать вместе. Результат миллионов лет дарвиновской эволюции делает эти компании более органичными., Более гуманным, и более надежные , которые  помогают S им  выжить .  

Команды ТРАНСФОРМАЦИИ разделяют идеал никогда не сдаваться , но работают тихо и чутко. Они специализируются на преобразовании компании. Преобразование культуры — это первый шаг, который достигается путем слушания, объяснения и передачи смысла, тем самым помогая сотрудникам пройти через процесс ТРАНСФОРМАЦИИ. Они поощряют и успокаивают сотрудников, сохраняя при этом сосредоточенность. 

ПОДВЕДЕНИЕ

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

Cоздание команд BAU, FIX, LEAN, NEW и TRANSFORMATION требует понимания психологии, глубокой мотивации всех участников и поиска лучших талантов, которые могут работать вместе. В OVH около 50% команд работают над BAU, 10% над FIX, 25% над LEAN, 10% над NEW и 5% над TRANSFORMATION. Наша цель — перейти примерно к 40% на BAU, 10% на FIX, 30% на LEAN, 15% на NEW и 5% на TRANSFORMATION. 

LEAN и НОВЫЕ команды дороги. Компании должны нанимать сотрудников, которые разрабатывают программное обеспечение и которым необходимо преобразовать бизнес, его организацию и культуру. Это инвестиции в существующие производственные инструменты для лучшего будущего. Если мыслить на долгую перспективу, без этих инвестиций не обойтись. И есть много хороших новостей. Во-первых, создание групп LEAN и NEW позволяет компании переквалифицировать все эти прямые инвестиционные затраты. На уровне бюджета все эти OPEX могут быть инвестированы как CAPEX  и амортизированы в течение 5 лет. Это свидетельствует о том, что бизнес остался прибыльным, несмотря на глубокую внутреннюю трансформацию. Однако это не меняет ситуацию с денежными потоками; работникам по-прежнему нужно платить. Увеличение капитала может быть необходимо для того , чтобы иметь средствадля инвестирования  в LEAN и NEW и, таким образом, для снижения затрат на BAU. На рынке есть много игроков, которые помогают в этом. Увеличится доходность, и это хорошо в долгосрочной перспективе. 




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

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

Мы определенно живем в страстное время!  

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

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

Мы уже представили  TSL в предыдущем сообщении блога , в котором было продемонстрировано, как наши клиенты используют доступные протоколы OVH Metrics, такие как Graphite, OpenTSDB, PromQL и WarpScript ™, но когда дело доходит до манипулирования или даже создания новых данных , у вас нет много вариантов, хотя вы можете использовать WarpScript ™ или TSL в качестве языка сценариев вместо языка запросов.

В большинстве случаев эта бизнес-логика требует создания приложения, что требует больше времени, чем выражение логики в виде запроса, нацеленного на TSDB. Создание кода базового приложения — это первый шаг, за которым следует CI / CD (или любой процесс доставки) и настройка его мониторинга. Однако управление сотнями таких небольших приложений приведет к увеличению органических затрат из-за необходимости  поддерживать их вместе с базовой инфраструктурой.

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

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

Вы не должны FaaS!

Планирование работы — старая привычная рутина. Будь то задания bash cron, раннеры или специализированные планировщики, когда дело доходит до упаковки фрагмента кода и его периодического запуска, для этого есть название: FaaS.

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

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

#def <Циклы>

Именно тогда мы решили создать «Loops»: платформу приложений, на которой вы можете отправить код, который хотите запустить. Вот и все. Цель состоит в том, чтобы продвинуть функцию (буквально!), А не модуль, как это делают все текущие решения FaaS:

function dailyReport(event) {
    return Promise.resolve('Today, everything is fine !')
}

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

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

Когда мы начали создавать Loops, были некоторые необходимые ограничения:

• Эта платформа должна легко масштабироваться , чтобы поддерживать производственную нагрузку OVH.
• Он должен быть высокодоступным
• Он должен быть независимым от языка , потому что некоторые из нас предпочитают Python, а другие JavaScript.
• Это должно быть надежно
• Часть планирования не должна коррелировать с частью выполнения ( культура μService )
• Он должен быть безопасным и изолированным, чтобы любой мог размещать непонятный код на платформе.

Реализация петель

Мы решили построить нашу первую версию на V8 . Мы выбрали JavaScript в качестве первого языка, потому что его легко изучить, а асинхронными потоками данных легко управлять с помощью Promises. Кроме того, он очень хорошо сочетается с FaaS, поскольку функции Javascript очень выразительны. Мы построили его на основе нового модуля виртуальной машины NodeJS , который позволяет выполнять код в выделенном контексте V8 .

Контекст V8 похож на объект (JSON), изолированный от вашего исполнения. В контексте вы можете найти собственные функции и объекты. Однако, если вы создадите новый контекст V8, вы увидите, что некоторые переменные или функции изначально недоступны (например, setTimeout (), setInterval () или Buffer ). Если вы хотите их использовать, вам придется внедрить их в свой новый контекст. Последнее, что нужно помнить, это то, что когда у вас есть новый контекст, вы можете легко выполнить сценарий JavaScript в строковой форме.

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

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

Теперь мы знаем, как выполнять наши скрипты, давайте реализуем для них некоторое управление. Чтобы не иметь состояния , каждый экземпляр рабочего цикла Loops (то есть движок JavaScript, способный запускать код в контексте виртуальной машины) должен иметь последнюю версию каждого цикла (цикл — это сценарий, который нужно выполнить). Это означает, что когда пользователь отправляет новый цикл, мы должны синхронизировать его с каждым рабочим циклом. Эта модель хорошо согласуется с парадигмой pub / sub, и, поскольку мы уже используем Kafka в качестве инфраструктуры pub / sub, оставалось лишь создать специальную тему и использовать ее у рабочих. В этом случае публикация включает API, в который пользователь отправляет свои циклы, которые создают событие Kafka, содержащее тело функции. Поскольку у каждого воркера есть своя группа потребителей Kafka, все они получают одинаковые сообщения.

Рабочие подписываются на обновления Loops как потребители Kafka и поддерживают хранилище Loop, которое представляет собой встроенный ключ (хэш Loop) / значение (текущая версия функции). В части API хэши цикла используются в качестве параметров URL для определения того, какой цикл выполнять. После вызова цикл извлекается из карты, затем вводится в контекст V8 , выполняется и отбрасывается. Этот механизм перезагрузки горячего кода гарантирует, что каждый цикл может быть выполнен для каждого рабочего. Мы также можем использовать возможности наших балансировщиков нагрузки для распределения нагрузки на рабочих. Эта простая модель распределения позволяет избежать сложного планирования и упрощает обслуживание всей инфраструктуры.

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

Время выполнения циклов

Даже если базовый движок может запускать собственный Javascript, как указано выше, мы хотели, чтобы он выполнял более идиоматические запросы временных рядов, такие как TSL или WarpScript ™ . Для этого мы создали абстракцию Loops Runtime, которая оборачивает не только Javascript, но также запросы TSL и WarpScript ™ в код Javascript. Пользователи должны объявить цикл с его средой выполнения, после чего остается лишь вопрос работы оберток. Например, выполнение цикла WarpScript ™ включает в себя использование простого сценария WarpScript ™ и его отправку посредством HTTP-вызова запроса узла.

Обратная связь по петлям

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

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

Планирование циклов

При публикации Loops вы можете объявить несколько триггеров аналогично Cron. Каждый триггер будет выполнять HTTP-вызов вашего цикла с дополнительными параметрами.

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

functions:
  warp_apps_by_cells:
    handler: apps-by-cells.mc2
    runtime: ws
    timeout: 30
    environment:
    events:
      - agra:
          rate: R/2018-01-01T00:00:00Z/PT5M/ET1M
          params:
            cell: ovh-a-gra
      - abhs:
          rate: R/2018-01-01T00:00:00Z/PT5M/ET1M
          params:
            cell: ovh-a-bhs

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

Петли трубопроводов

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

Болевые точки: масштабирование приложения NodeJS

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

NodeJS также имеет доступный модуль кластера , который позволяет приложению использовать несколько потоков. Вот почему в воркере Loops мы начинаем с потока N-1 для обработки вызовов API, где N — общее количество доступных потоков, в результате чего один остается выделенным для главного потока.

Главный поток отвечает за использование тем Kafka и поддержание хранилища Loops , а рабочий поток запускает сервер API. Для каждого запрошенного выполнения цикла он запрашивает у мастера содержимое скрипта и выполняет его в выделенном потоке.

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

Вывод

В этом посте мы предварительно ознакомились с Loops, масштабируемой, ориентированной на метрики FaaS с встроенной поддержкой JavaScript и расширенной поддержкой WarpScript ™ и TSL .

У нас еще есть несколько вещей, которые нужно улучшить, например импорт зависимостей в стиле ES5 и предварительный просмотр показателей для проектов циклов наших клиентов. Мы также планируем добавить больше сред выполнения , особенно WASM , что позволит использовать многие другие языки, которые могут быть ориентированы на него, например Go, Rust или Python , в соответствии с предпочтениями большинства разработчиков.

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

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