Процесс доставки — это набор шагов — от git commit до производства — которые выполняются для предоставления ваших услуг вашим клиентам. Опираясь на ценности Agile, непрерывная интеграция и непрерывная доставка (CI / CD) — это практики, которые нацелены на максимальную автоматизацию этого процесса.

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



Центром этой экосистемы является инструмент CDS, разработанный в OVH.
CDS — это программное решение с открытым исходным кодом, которое можно найти по адресу https://github.com/ovh/cds, с документацией по адресу https://ovh.github.io/cds .

CDS — это третье поколение инструментов CI / CD в OVH, следующее за двумя предыдущими решениями, основанными на Bash, Jenkins, Gitlab и Bamboo. Это результат 12-летнего опыта в области CI / CD. Ознакомившись с большинством стандартных инструментов отрасли, мы обнаружили, что ни один из них полностью не соответствовал нашим ожиданиям в отношении четырех выявленных нами ключевых аспектов. Вот что пытается решить CDS.

Вот эти четыре аспекта:

Эластичный

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

Расширяемый

В CDS любые действия (развертывание Kubernetes и OpenStack, отправка в Kafka, тестирование CVE…) могут быть записаны в подключаемых модулях высокого уровня , которые будут использоваться пользователями в качестве строительных блоков . Эти плагины просты в написании и использовании, поэтому легко и эффективно удовлетворить самые экзотические потребности..

Гибко, но легко

CDS может запускать сложные рабочие процессы со всевозможными промежуточными этапами, включая сборку, тестирование, развертывание 1/10/100, ручные или автоматические шлюзы, откат, условные переходы… Эти рабочие процессы могут храниться в виде кода в репозитории git. CDS предоставляет базовые шаблоны рабочих процессов для наиболее распространенных сценариев основной группы, чтобы упростить процесс внедрения. Таким образом, создание функциональной цепочки CI / CD из ничего может быть быстрым и легким.

Самообслуживание

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

CI / CD в 2018 году — пять миллионов сотрудников!

• Около 5,7 млн ​​работников запускались и удалялись по запросу.
• 3,7 млн ​​контейнеров
• 2M виртуальных машин

Как это возможно?

Одной из первоначальных задач CDS в OVH было создание и развертывание 150 приложений в виде контейнера менее чем за семь минут. Это стало реальностью с 2015 года. Так в чем же секрет? Автоматическое масштабирование по запросу!

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



Инкубаторий похож на инкубатор: он рождает рабочих CDS и поддерживает над ними власть жизни и смерти.



Каждый инкубаторий предназначен для оркестратора. Кроме того, один инстанс CDS может создавать рабочих на многих облачных платформах:
— Инкубаторий Kubernetes запускает рабочих в контейнерах
— Инкубаторий OpenStack запускает виртуальные машины
— Инкубаторий Swarm запускает докерные контейнеры
— Инкубаторий Marathon запускает докерные контейнеры
— Инкубаторий VSphere запускает виртуальные машины
— местный инкубатор запускает процесс на хосте

Что дальше?

Это всего лишь предварительный просмотр CDS … Нам есть о чем вам рассказать! Инструмент CI / CD предлагает широкий спектр функций, которые мы подробно рассмотрим в наших  следующих статьях . Мы обещаем, что до завершения 2019 года вы больше не будете смотреть на свой инструмент CI / CD таким же образом ...

На этой неделе команда OVH Integration and Continuous Deployment была приглашена на подкаст DataBuzzWord .



Вместе мы исследовали тему непрерывного развертывания в контексте машинного обучения и больших данных. Мы также обсудили непрерывное развертывание для таких сред , как Kubernetes , Docker, OpenStack и VMware VSphere .

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

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

Найдите CDS на GitHub:

• https://github.com/ovh/cds

…. и подписывайтесь на нас в Twitter:

• https://twitter.com/yesnault
• https://twitter.com/francoissamin

Обсудите эти темы с нами на нашем канале Gitter: https://gitter.im/ovh-cds/

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

TSL означает язык временных рядов . Проще говоря, TSL  — это абстрактный способ генерации запросов для различных бэкэндов TSDB в форме HTTP-прокси. В настоящее время он поддерживает языки запросов WarpScript 10 и Prometheus PromQL, но мы стремимся расширить поддержку и на другие основные TSDB.



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

Так почему мы решили потратить время на разработку такого прокси? Что ж, позвольте мне рассказать вам историю протокола OVH Metrics !

Из OpenTSDB…

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

sys.cpu.0

 метрики в 

test

центре обработки данных, суммируя их между 

start

 и 

end

датами:

{
    "start": 1356998400,
    "end": 1356998460,
    "queries": [
        {
            "aggregator": "sum",
            "metric": "sys.cpu.0",
            "tags": {
                "host": "*",
                "dc": "test"
            }
        }
    ]
}

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

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

Например, запрос с OpenTSDB для получения максимального значения 

usage_system

для диапазона от 

cpu

0 до 9, взятого за 2-минутный интервал по среднему их значению, выглядит следующим образом:

{
    "start": 1535797890,
    "end": 1535818770,
    "queries":  [{
        "metric":"cpu.usage_system",
        "aggregator":"max",
        "downsample":"2m-avg",
        "filters": [{
            "type":"regexp",
            "tagk":"cpu",
            "filter":"cpu[0–9]+",
            "groupBy":false
            }]
        }]
}

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

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

… В PromQL

Вторым протоколом, над которым мы работали, был PromQL , язык запросов к базе данных временных рядов Prometheus . Когда мы сделали этот выбор в 2015 году, Prometheus набирал обороты, и у него по-прежнему впечатляющие темпы внедрения. Но если Prometheus добился успеха, дело не в его языке запросов, PromQL. Этот язык так и не получил широкого распространения внутри компании, хотя в последнее время он начал получать некоторое распространение, в основном благодаря приходу людей, которые работали с Prometheus в своих предыдущих компаниях. На внутреннем уровне запросы PromQL составляют около 1-2%нашего ежедневного трафика. Основные причины заключаются в том, что многие простые варианты использования могут быть решены быстро и с большим контролем необработанных данных с помощью запросов OpenTSDB, в то время как многие более сложные варианты использования не могут быть решены с помощью PromQL. Запрос, аналогичный тому, что определен в OpenTSDB, будет выглядеть так:

api/v1/query_range?
query=max(cpu. usage_system{cpu=~"cpu[0–9]%2B"})
start=1535797890&
end=1535818770&
step=2m

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

В конце концов, многие люди предпочитают использовать гораздо более сложный метод: WarpScript, который работает на движке Warp10 Analytics Engine, который мы используем за кулисами.

Наше внутреннее принятие WarpScript

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

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

Вот почему он по-прежнему является основным запросом, используемым в OVH на платформе OVH Metrics, при этом почти 60% внутренних запросов используют его. Тот же запрос, который мы только что вычислили в OpenTSDB и PromQL, в WarpScript будет выглядеть следующим образом:

[ "token" "cpu.average" { "cpu" "~cpu[0–9]+" } NOW 2 h ] FETCH
[ SWAP bucketizer.mean 0 2 m 0 ] BUCKETIZE
[ SWAP [ "host" ] reducer.max ] REDUCE

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

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

WarpScript может включать в себя десятки (или даже сотни) строк, и успешное выполнение часто является достижением с особым чувством, которое возникает от использования в полной мере своих умственных способностей. Фактически, внутренняя шутка среди нашей команды — это способность написать WarpScript за один день или заработать значок WarpScript Pro Gamer! Вот почему мы раздали футболки Metrics пользователям, добившимся значительных успехов с платформой Metrics Data Platform.

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

• Предложите четкую семантику аналитики временных рядов
• Упростите написание и сделайте его удобным для разработчиков
• Поддержка запросов потока данных и простота отладки сложных запросов
• Не пытайтесь быть лучшим ящиком для инструментов. Будь проще.

Мы знаем, что пользователям, вероятно, придется время от времени возвращаться к WarpScript. Однако мы надеемся, что использование TSL упростит их обучение. TSL — это просто новый шаг в приключении временных рядов!

Путь к TSL

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

В TSL существуют собственные методы, такие как 

select

и 

where

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

from

и 

last

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

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

Numbers

, 

Strings

, 

Time durations

, 

Lists

и 

Time Series

(конечно же !).

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

select("cpu.usage_system")
.where("cpu~cpu[0–9]+")
.last(12h)
.sampleBy(2m,mean)
.groupBy(max)

Вы также можете писать более сложные запросы. Например, мы собрали наш практический опыт WarpScript, предназначенный для обнаружения экзопланет по необработанным данным НАСА, в один запрос TSL:

sample = select('sap.flux')
 .where('KEPLERID=6541920')
 .from("2009–05–02T00:56:10.000000Z", to="2013–05–11T12:02:06.000000Z")
 .timesplit(6h,100,"record")
 .filterByLabels('record~[2–5]')
 .sampleBy(2h, min, false, "none")

trend = sample.window(mean, 5, 5)

sub(sample,trend)
 .on('KEPLERID','record')
 .lessThan(-20.0)

Итак, что мы здесь сделали? Сначала мы создали образец переменной, в которую загрузили необработанные данные sap.flux одной звезды, 6541920. Затем мы очистили серию, используя функцию временного разделения (чтобы разделить серию звезд, когда в данных есть дыра с длина больше 6h), сохраняя только четыре записи. Наконец, мы сделали выборку результата, сохранив минимальное значение каждого двухчасового периода.

Затем мы использовали этот результат для вычисления тренда ряда, используя скользящее среднее за 10 часов.

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

TSL с открытым исходным кодом

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

В настоящее время мы проводим бета-тестирование TSL на нашей публичной платформе OVH Metrics. Кроме того, исходный код TSL на Github открыт , поэтому вы также можете протестировать его на своих собственных платформах.

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

Запуск Kubernetes поверх Kubernetes был хорошей идеей для компонентов уровня управления без сохранения состояния… но как насчет etcd?

В нашем предыдущем посте мы описали архитектуру Kubinception, как мы запускаем Kubernetes поверх Kubernetes для компонентов без сохранения состояния на плоскостях управления клиентских кластеров. Но как насчет компонента с отслеживанием состояния, etcd?

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

Самая простая идея не всегда бывает удачной

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



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

Использование оператора

Не только мы думали, что сложность развертывания и эксплуатации кластера etcd в Kubernetes была чрезмерной, разработчики CoreOS заметили это и в 2016 году выпустили элегантное решение проблемы: etcd оператор .

Оператор — это особый контроллер, который расширяет Kubernetes API, чтобы легко создавать, настраивать и управлять экземплярами сложных (часто распределенных) приложений с отслеживанием состояния в Kubernetes. Для справки, понятие оператора было введено в CoreOS оператором etcd .



Оператор etcd управляет кластерами etcd, развернутыми в Kubernetes, и автоматизирует рабочие задачи: создание, уничтожение, изменение размера, восстановление после сбоя, последовательное обновление, резервное копирование…

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

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

StatefulSet

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

Существует официальная диаграмма ETCD Helm, которая позволяет развертывать кластеры ETCD как StafefulSets, в которой некоторая гибкость оператора и удобство использования сводятся к более надежному управлению PV, которое гарантирует, что перенесенный модуль etcd получит свои данные.



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

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

Постоянные тома, задержка и простой расчет затрат

Etcd StatefulSet казался хорошим решением … пока мы не начали интенсивно его использовать. Etcd StatefulSet использует PV, то есть тома сетевого хранилища . И etcd довольно чувствителен к задержкам в сети , их производительность сильно падает, когда они сталкиваются с задержками.

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

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

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

Многопользовательский кластер etcd

Если мы не хотели развертывать etcd внутри Kubernetes, альтернативой было развертывание снаружи. Мы решили развернуть мультитенантный кластер etcd на выделенных серверах . Все клиентские кластеры будут использовать один и тот же ETCD, каждый сервер API получит свое собственное пространство в этом мультитенантном кластере etcd.



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

Что дальше?

В следующих статьях серии Kubernetes мы погрузимся в другие аспекты построения OVH Managed Kubernetes и дадим клавиатуру некоторым из наших бета-клиентов, чтобы они рассказали о своем опыте использования сервиса.

На следующей неделе давайте сосредоточимся на другой теме, мы займемся языком запросов TSL , и почему мы создали и открыли исходный код…

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

С OVH Private Cloud мы избавляем вас от этой сложности. Мы управляем этим трудоемким и стрессовым аспектом, чтобы вы могли сосредоточиться на своем бизнесе и производстве.

Но это не значит, что это не проблема для нас.

Обновление сотен vSphere 5.5 до 6.0

vSphere — это ведущий продукт предложения Private Cloud, он является частью пакета SDDC, предоставляемого VMware. vSphere — это программное обеспечение, позволяющее пользователю управлять своими хостами, хранилищем, сетью… Через клиента он может создавать кластеры с этими активами для надежного, стабильного и высокодоступного размещения производственной среды.

С сентября 2018 года поддержка vSphere (vCenter, ESXi…) версии 5.5 со стороны VMware прекращается. Обладая безопасностью и стабильностью инфраструктуры частного облака, мы начали процессы обновления для всех vCenter.



У нас было около 850 vCenter в версии 5.5 в производстве, что представляет собой значительную работу по обновлению всего, если она выполняется вручную. Но в OVH у нас есть общий лейтмотив: автоматизировать все человеческие действия  для повышения эффективности и избегать ошибок.

Так нам удалось обновить 850 vCenter с версии 5.5 до версии 6.0 за 4 недели. Другими словами, более 210 vCenter в неделю, 30 vCenter в день , с командой из 10 человек, выполняющих это обслуживание в фоновом режиме, без какого-либо влияния на производительность клиентов.

Наша команда разработчиков разработала и создала набор скриптов (которые мы внутри себя называем «роботом») для автоматизации обновлений vCenter несколько лет назад. Этот робот сильно изменился с момента появления продукта Private Cloud и следует за нами с версии 4.1 до 6.5, работа над которой еще продолжается.

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

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

Обновление апгрейдера: новая версия робота

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

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

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

Мы создали этого робота для обновления в роботе-оркестраторе, который, в соответствии с введенными параметрами, будет создавать задачи обновления для каждого частного облака, связанного с обслуживанием, и будет планировать его в автоматические даты в течение как минимум 72 часов с учетом рассмотрения клиента. но также количество запускаемых обновлений по часам и критическим периодам (например, Черная пятница или Зимние распродажи). Клиенты могут изменить расписание своих обновлений с помощью диспетчера в части «Операции», чтобы выполнить обслуживание в более удобное для их производства время.



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






Подводя итоги, мы перешли от необходимости автоматизировать операцию обновления vCenter, которая должна занимать не менее 12 часов на каждый vCenter, к первой версии автоматизации, которая позволяет выполнить эту операцию за 4 часа, но с слишком высокий уровень ошибок (20%) из-за повторяющихся ошибок, которые SRE приходилось исправлять вручную. Теперь вторая версия является прочной, надежной и стабильной , позволяющей избежать известных проблем и создавать только редкие и уникальные проблемы, которые будут исправлены в процессе автоматизации на тщательно подобранном этапе.

Что дальше?

В ближайшие месяцы последуют другие мероприятия по техническому обслуживанию, обновление хоста с версии 5.5 до версии 6.0, обновление нашей опции Veeam Backup с 8.0 до версии 9.5, обновление нашей опции Zerto с 5.0 до 5.5 и множество других обновлений наших внутренних машин. для обеспечения регулярного аудита PCI-DSS.

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

1 февраля в протоколе DNS ( Domain Name System [1] ) произойдут новые большие изменения ...

Немного контекста

Протокол DNS был ключевым компонентом функциональности Интернета в течение последних 30 лет и до сих пор остается. Он связывает доменные имена (например, www.ovh.com ) с числовыми IP-адресами (например, 198.27.92.1), необходимыми для поиска и идентификации веб-сайтов или других компьютерных служб. Этот протокол обычно называют веб-каталогом.

Поскольку Интернет и технологии, использующие его, быстро развиваются, конечно, протокол DNS уже много раз эволюционировал за 30 лет своего существования.
Сегодня мы особенно рассмотрим его первое расширение под названием EDNS [2] , которое лежит в основе так называемого Дня флага DNS .

EDNS, что это за штука?

Это расширение добавило новые функции к тем, которые предоставляет протокол DNS.

Десять лет назад это расширение было ключом к созданию DNSSEC [3], который решает некоторые проблемы безопасности, связанные с протоколом DNS, за счет защиты определенных видов информации, предоставляемой DNS посредством ответов с криптографической подписью.

К сожалению, многие DNS-серверы в мире не имеют этого расширения EDNS. Иногда расширение не соответствует стандартам или, что еще хуже, просто блокируется!

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

1 февраля 2019 года — День первый

На кого это повлияет?

Инфраструктуры OVH совместимы с EDNS , поэтому не следует ожидать никаких последствий, если вы используете службы DNS, управляемые OVH.

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

Если вы не можете быть готовы к 1 февраля, у вас все еще есть возможность перенести свою зону DNS в нашу инфраструктуру.

Наши гиды:

• Редактирование DNS-серверов для доменного имени OVH
• Редактирование зоны OVH DNS

На меня влияют?

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

Идти дальше

Файл. Реестр расширений cz разместил в сети инструмент для сканирования любого расширения и проверки его совместимости с разрешением с помощью EDNS:

AFNIC провела тест на .fr TLD. В их результатах, доступных здесь , мы видим, что это, вероятно , затронет 3,49% доменов .fr .

• [1] DNS, RFC1034 и RFC1035
• [2] EDNS, RFC2671 и RFC6891
• [3] DNSSEC, RFC4033

OVH в значительной степени полагается на метрики для эффективного мониторинга всего своего стека. Независимо от того, являются ли они низкоуровневыми или ориентированными на бизнес , они позволяют командам получить представление о том, как наши службы работают на повседневной основе. Необходимость хранить миллионы точек данных в секунду привела к необходимости создать специальную команду для создания продукта, способного справиться с этой нагрузкой: Metrics Data Platform .  Опираясь на Apache Hbase , Apache Kafka и Warp 10 , нам удалось создать полностью распределенную платформу, которая обрабатывает все наши показатели… и ваши!

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

Встречайте OMNI, наш уровень оповещения

OMNI наше кодовое название  полностью распределенной ,  как-код ,  предупреждая  систему , которую мы разработали на вершине Метрики. Он разделен на компоненты:

• Часть управления , которая берет определения ваших предупреждений, определенных в репозитории Git, и представляет их как непрерывные запросы,
• Исполнитель запросов, распределяющий ваши запросы по расписанию.

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

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

Чтобы справиться с этим, мы посмотрели на проекты с открытым исходным кодом, такие как Prometheus AlertManager,  LinkedIn Iris, и обнаружили скрытую правду:

Обработка предупреждений как потоков данных,
передача от оператора к другому.

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

Архитектура маяка

По сути, Beacon читает события от Кафки . Все представлено в виде сообщения , от предупреждений до правил агрегирования, отложенных заказов и так далее. Трубопровод разделен на две ветви:

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

Тогда все объединяется , чтобы произвести  на  уведомление , что собирается быть вперед к нужному человеку. Уведомляющее сообщение помещается в Kafka, которое будет использоваться другим компонентом, называемым beacon-notifier.


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



Все объединяется в поток данных, разделяется (с ключом в Flink API) пользователями. Вот пример:

final DataStream<Tuple4<PlanIdentifier, Alert, Plan, Operation>> alertStream =

  // Partitioning Stream per AlertIdentifier
  cleanedAlertsStream.keyBy(0)
  // Applying a Map Operation which is setting since when an alert is triggered
  .map(new SetSinceOnSelector())
  .name("setting-since-on-selector").uid("setting-since-on-selector")

  // Partitioning again Stream per AlertIdentifier
  .keyBy(0)
  // Applying another Map Operation which is setting State and Trend
  .map(new SetStateAndTrend())
  .name("setting-state").uid("setting-state");

• SetSinceOnSelector , который устанавливается с момента срабатывания предупреждения
• SetStateAndTrend , который устанавливает состояние  (ПРОДОЛЖЕНИЕ, ВОССТАНОВЛЕНИЕ или ОК) и тренд (есть ли у нас более или менее метрики в ошибках).

Каждый из этого класса содержит менее 120 строк кода, потому что Flink справляется со всеми трудностями . Большая часть конвейера состоит только из классических преобразований, таких как Map, FlatMap, Reduce , включая их версии Rich и Keyed . У нас есть несколько функций процессов , которые очень удобны для разработки, например, таймера эскалации.

Интеграционные тесты

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

Запрашиваемое состояние

Убийственная особенность Apache Flink — это возможность запрашивать внутреннее состояниеоператора . Даже если это бета-функция, она позволяет нам узнать текущее состояние различных частей работы:

• на каких этапах эскалации мы находимся
• это он прилег или извед -ed
• Какое оповещение продолжается
• и так далее.

Благодаря этому мы легко разработали API для состояния запроса, который поддерживает наше представление предупреждений в Metrics Studio, наше кодовое имя для веб-интерфейса платформы данных метрик.

Развертывание Apache Flink

Мы развернули последнюю версию Flink ( 1.7.1 на момент написания) непосредственно на голых металлических серверах с выделенным кластером Zookeeper с использованием Ansible. Работа с Flink стала для нас действительно приятным сюрпризом, с понятной документацией и настройкой , а также впечатляющей устойчивостью . Мы можем перезагрузить весь кластер Flink, и задание перезапускается в его последнем сохраненном состоянии , как будто ничего не произошло.

Мы используем RockDB в качестве государственного сервера, поддерживаемого хранилищем OpenStack Swift,  предоставляемым OVH Public Cloud.

Для мониторинга мы полагаемся на Prometheus Exporter с Beamium, чтобы получить возможность наблюдать за состоянием здоровья рабочих.

Одним словом, мы любим Apache Flink!

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




Таким образом, мы настоятельно рекомендуем всем разработчикам взглянуть на Apache Flink. Я рекомендую вам пройти обучение Apache Flink , написанное Data Artisans. Более того, сообщество приложило немало усилий, чтобы легко развернуть Apache Flink в Kubernetes, поэтому вы можете легко попробовать Flink с помощью нашего управляемого Kubernetes!

Что дальше?

На следующей неделе мы вернемся к Kubernetes, поскольку мы расскажем, как мы работаем с ETCD в нашей службе OVH Managed Kubernetes .

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

Одним из наиболее структурных решений, которые мы сделали при создании сервиса OVH Managed Kubernetes, было развертывание кластеров наших клиентов над нашими собственными. Kubinception действительно…

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

Как работает кластер Kubernetes?

Чтобы полностью понять, почему мы запускаем Kubernetes на Kubernetes, нам нужно хотя бы базовое понимание того, как работает кластер Kubernetes. Полное объяснение по этому вопросу находится вне контекста этого поста, но давайте сделаем краткий обзор:
Рабочий кластер Kubernetes состоит из:

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

Основные компоненты

В этой категории компонентов у нас есть:

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

Компоненты узла

В каждом узле у нас есть:

• Kubelet: агент, который следит за тем, чтобы контейнеры, описанные в PodSpecs, работали и работали. Это связь между узлом и плоскостью управления.
• Kube-proxy: сетевой прокси, работающий на каждом узле, позволяющий абстрагировать сервис Kubernetes, поддерживая сетевые правила и выполняя переадресацию соединений.

Наша цель: быстрое и безболезненное развертывание кластера

Как мы пришли от этой простой архитектуры Kubernetes к Kubernetes вместо Kubernetes? Ответ кроется в одной из наших основных целей при создании сервиса OVH Managed Kubernetes: иметь возможность развертывать кластеры самым простым и автоматизированным способом.

И мы хотели не только развертывать кластеры, мы хотели, чтобы развернутые кластеры были:

• Эластичный
• Изолированные
• Оптимизированный по стоимости

Kubinception: запуск Kubernetes поверх Kubernetes

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




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

А рабочие узлы клиентского кластера? Это обычные узлы Kubernetes: экземпляры общедоступного облака OVH, подключающиеся к серверу API клиентского кластера, работающему в модуле кластера администрирования.



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



С точки зрения административного кластера, мы просто развернули три новых модуля. Затем мы создаем несколько новых экземпляров узлов и подключаем ETCD, и кластер готов.

Если что-то может выйти из строя, оно сделает это

Теперь у нас есть архитектура, которая позволяет нам быстро развертывать новые кластеры, но если мы вернемся к нашей цели, быстрое развертывание было только половиной, мы хотели, чтобы кластер был устойчивым . Начнем с отказоустойчивости.
Узлы клиентского кластера уже устойчивы, так как они являются обычными узлами Kubernetes , а устойчивость ETCD будет подробно описана в отдельном сообщении в блоге, поэтому давайте посмотрим на устойчивость плоскости управления, поскольку это особая часть нашей архитектуры.
И в этом прелесть архитектуры Kubinception, мы развертываем плоскость управления клиентскими кластерами в виде простых стандартных модулей в нашем административном кластере. А это означает, что они столь же устойчивы, как и любой другой модуль Kubernetes: если один из основных компонентов клиентского кластера выйдет из строя, диспетчер-контроллер административного кластера обнаружит его, и модуль будет перепланирован и повторно развернут без каких-либо ручных действий в нашем сторона.

Какой лучший способ убедиться, что наши Kubernetes достаточно надежны ...

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

А как насчет масштабирования

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

Что дальше?

Поскольку этот пост уже достаточно длинный, я оставляю объяснение на ETCD для следующего поста в серии, через две недели. На следующей неделе давайте сосредоточимся на другой теме, мы займемся Apache Flink и тем, как его использовать для обработки предупреждений в масштабе OVH…

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

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



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

В сегодняшнем посте мы представим наш управляемый Kubernetes и объясним, зачем мы его создали. В следующих постах мы более подробно рассмотрим некоторые аспекты архитектуры, такие как масштабирование ETCD или то, как мы запускаем клиентов мастеров Kubernetes внутри наших основных рабочих узлов Kubernetes…

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

Путешествие Kubernetes

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

Затем, как новый сторонник, вы говорите себе, что вам следует попытаться построить настоящий кластер и развернуть на нем несколько более крупных приложений. Вы создаете виртуальную kubeadmмашину, учитесь ею пользоваться и через некоторое время создали новый кластер Kubernetes для развертывания ваших приложений. Магия все еще существует, но вы начинаете чувствовать, что, как и в большинстве сказок, за магию приходится платить…

Запускаете Kubernetes в производство?

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

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

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

Наш ответ на эту сложность эксплуатации

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

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

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

На плечах гигантов ...

Итак, мы хотели создать управляемое решение Kubernetes, но как это сделать? Первый шаг был прост: нам нужно было убедиться, что базовая инфраструктура надежна, поэтому мы решили основать ее на нашем собственном предложении Public Cloud на основе OpenStack.

Сертифицированный хостинг Kubernetes
Построение нашей платформы на основе зрелого, высокодоступного и основанного на стандартах продукта, такого как OVH Public Cloud, позволило нам сосредоточить наши усилия на решении реальной проблемы, с которой мы столкнулись: создании хорошо масштабируемой, простой в эксплуатации, сертифицированной CNCF управляемой службы Kubernetes.

Что дальше?

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

Мы начнем с одного из наших самых смелых решений: запустить Kubernetes поверх Kubernetes или, как мы любим его называть, Kubinception.