Федерация  — это бета-функция, предлагаемая всем клиентам OVH Private Cloud с vCenter 6.5 . Если вы хотите принять участие в бета-тестировании, обратитесь в нашу службу поддержки. Это позволяет использовать внешний Microsoft Active Directory в качестве источника аутентификации для доступа к серверу VMware vCenter . Реализация этой функции стало возможным благодаря OvH в команде DevOps , которые разработали инновационный и уникальный API , который добавляет дополнительные возможности для тех , предлагаемых VMware. Действительно, в настоящий момент невозможно настроить источники идентификаторов через собственный API vCenter.



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

Зачем?

По умолчанию права доступа к vCenter в частном облаке управляются непосредственно этим vCenter. Пользователи создаются локально (localos или домен SSO), и все механизмы управления доступом ( RBAC ) управляются службой SSO . Включение федерации делегирует управление пользователями Microsoft Active Directory (AD). В результате сервер vCenter будет взаимодействовать с контроллером домена, чтобы гарантировать, что пользователь, пытающийся подключиться, является тем, кем он себя называет. VCenter сохраняет управление ролями и привилегиями для объектов, которыми он управляет. После настройки федерации можно связать пользователей AD с ролями vCenter, чтобы они могли получать доступ и / или управлять определенными объектами в инфраструктуре (виртуальными машинами, сетями, папками и т. Д.).


Одним из основных применений этого будет облегчение доступа к vCenter для администраторов за счет уменьшения количества учетных записей, необходимых для обслуживания различных элементов инфраструктуры. Кроме того, появится возможность расширить и унифицировать политику управления паролями между Active Directory и vCenter Private Cloud.

Тот факт, что федерацией можно управлять через API OVH, позволяет автоматизировать настройку, а также поддерживать ее в рабочем состоянии. Наконец, очень просто добавить проверки в любой инструмент мониторинга (Nagios, Zabbix, Sensu и т. Д.) Для мониторинга состояния Федерации и прав, назначенных пользователям.

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

Архитектура и предпосылки

Поскольку vCenter должен будет взаимодействовать с контроллерами домена, первым шагом будет разрешение потоков между этими элементами. Есть несколько способов достичь этой цели, например, объединить OVHCloud Connectс частным шлюзом . Для изучения всех различных возможностей потребуется целая статья, поэтому мы советуем вам связаться с OVH или одним из наших партнеров, чтобы помочь вам в выборе наиболее подходящей архитектуры. Следующая диаграмма дает вам упрощенный обзор того, как это может выглядеть:



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

• Ваши учетные данные OVH (ник и пароль)
• Имя вашего частного облака (в форме 

  pcc-X-X-X-X

  )
• Необходимая информация об инфраструктуре Active Directory, а именно:
  
  • Краткое и длинное имя домена Active Directory (например,

    contoso

    и 

    contoso.com

    )
  • IP-адрес контроллера домена
  • Имя пользователя и пароль учетной записи AD с достаточными правами для просмотра каталога
  • Расположение групп и пользователей в иерархии AD как «базовое DN» (пример:) 

    OU = Users, DC = contoso, DC = com

    . Следует отметить, что хотя информация о группе является обязательной, в настоящее время ее невозможно использовать для управления аутентификацией.
  • Список пользователей Active Directory, которых вы хотите привязать к vCenter. Необходимо будет указать имена пользователей в виде username@FQDN.domain (например,

    federation@contoso.com

    )

Обратите внимание, что в настоящее время невозможно иметь несколько пользователей с одним и тем же коротким именем, независимо от того, управляются ли они локально или с помощью Active Directory.

Активация и настройка

После того, как вы соберете всю необходимую информацию, можно будет активировать и настроить Федерацию. Операция будет проходить в три этапа:

1. Активация связи между Active Directory и частным облаком
2. Привязка одного или нескольких пользователей AD к частному облаку
3. Назначение прав пользователям

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

Включение соединения между AD и частным облаком

Перейдите на сайт проводника API и выполните аутентификацию, используя свои учетные данные OVH. Если у вас его еще нет, получите имя (также называемое serviceName в API) своего частного облака, так как оно будет обязательным для всех остальных шагов настройки. Вы можете получить доступ к этой информации, выполнив GET для URI / SpecialCloud:



Включите федерацию, предоставив всю информацию об Active Directory с помощью POST в URI- адресе / SpecialCloud / {serviceName} / federation / activeDirectory . Вся запрашиваемая информация обязательна:



Активация Федерации займет некоторое время и будет происходить в фоновом режиме. Вы можете следить за ходом операции через панель управления OVH:



После завершения вы можете получить идентификатор федерации, отправив запрос GET на URI- адрес / SpecialCloud / {serviceName} / federation / activeDirectory :

Привязка одного или нескольких пользователей AD

Теперь, когда ваш AD объявлен в vCenter Private Cloud, мы сможем привязать к нему пользователей Active Directory. Обратите внимание, что даже если ваши пользователи связаны, с ними не будет связанных ролей vCenter, поэтому они не смогут войти в систему.

Чтобы привязать пользователя, вам нужно будет отправить запрос POST на /dedicatedCloud/{serviceName}/federation/activeDirectory/{activeDirectory}/grantActiveDirectoryUser URI, указав полное имя пользователя:



Убедитесь, что пользователь присутствует в поисковом подразделении, которое вы указали при связывании AD с vCenter. Еще раз, вы можете проверить, что задача импорта выполнена через API или через панель управления:



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

Назначение прав доступа

Последним шагом будет предоставление пользователям прав доступа к различным объектам виртуальной инфраструктуры. Этот шаг не отличается от обычного способа управления правами пользователей частного облака. Это можно сделать через API или панель управления OVH.



Теперь вы должны иметь возможность войти в свой vCenter с пользователями вашего AD и начать управлять своим частным облаком!

В этом посте мы увидели, как активировать опцию «Федерация» и какие преимущества она дает пользователям частного облака OVH. В следующей публикации мы поговорим о еще одной новой функции: Granular Rights. Так что следите за новостями в блоге OVH!

Бизнес-аналитика (BI) — это способность собирать существенные данные из информационной системы для подачи в хранилище данных (DWH) или озеро данных. Обычно они предоставляют копию данных, которые будут использоваться для приложений бизнес-аналитики. Для подпитки DWH могут применяться разные стратегии. Одна из таких стратегий - Change Data Capture (CDC), которая представляет собой способность фиксировать изменяющиеся состояния из базы данных и преобразовывать их в события, которые можно использовать для других целей. Большинство баз данных предназначены для целей OLTP и хорошо для этого разработаны. Тем не менее, разные варианты использования потребуют одних и тех же данных с разными шаблонами доступа. Эти варианты использования (большие данные, ETL и потоковая обработка и др.) В основном подпадают под Баннер OLAP . Их смешение поставит под угрозу OLTP и производственную среду, поэтому нам нужно включить OLAP ненавязчивым образом.

OVH, как облачный провайдер, управляет многочисленными базами данных как для своих клиентов, так и для собственных нужд. Управление жизненным циклом базы данных всегда включает в себя как поддержание инфраструктуры в актуальном состоянии, так и синхронизацию с циклом разработки, чтобы согласовать программное обеспечение с его зависимостью от базы данных. Например, приложению может потребоваться MySQL 5.0, который затем может быть объявлен как EOL (End Of Life). В этом случае приложение необходимо изменить для поддержки (скажем) MySQL 5.5. Мы не изобретаем велосипед здесь — этим процессом уже несколько десятилетий управляют операторы и команды разработчиков.

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

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

Разработка ненавязчивого процесса сбора измененных данных

Обычно перед тем, как приступить к разработке, рекомендуется определить состояние технологии, поскольку это сэкономит время и укрепит сообщества. Еще в начале 2015 года, когда впервые появился ландшафт CDC ( Debezium , аналогичное решение с открытым исходным кодом, появилось только в конце того же года), единственное существующее решение — Databus — появилось от LinkedIn. Архитектура Databus была довольно сложной, и проект не был очень активным. Кроме того, это не решало наших требований к безопасности, и мы пришли из сильной культуры эксплуатации, поэтому запуск JVM на сервере базы данных был явно непозволительным для наших рабочих групп.

Хотя не существовало программного обеспечения CDC, соответствующего нашим требованиям, в конце концов мы нашли библиотеку репликации binlog, которую можно было бы интегрировать с некоторыми из них в Go. Binlog — это имя MySQL для базы данных WAL.

Наши требования были довольно простыми:

• Избегайте решений на основе JVM (JVM и контейнеры в то время не работали должным образом, и было бы трудно получить поддержку от Ops)
• Агент CDC, необходимый для подключения к шлюзу CDC для высокозащищенных сред (а не шлюзу для агентов)
• Шлюз CDC может контролировать флот своих агентов
• Агент CDC может фильтровать и сериализовать события, чтобы протолкнуть их с помощью контроля обратного давления.
• Агент CDC может сбросить БД, чтобы получить первый снимок, поскольку бинлоги не всегда доступны с самого начала.

Вот глобальный дизайн проекта Menura:



Менура — это род лирохвостов : птицы, способные воспроизводить любой звук. Большинство BI связанных компонентов являются «птицы», так как они часть B usiness I ntelligence R & D проекта!

Автоматизация плоскости управления BI

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

• Добавить и настроить источник базы данных
• Управление удаленной конфигурацией
• Картографический агент / картография таблиц
• Дамп таблиц базы данных
• Управление CDC (запуск / остановка синхронизации, фиксация смещений бинлогов…)

В то время gRPC только зарождался, но мы увидели в этом проекте, с его прочной основой, возможность примирить Protobuf, экономичность и языковое разнообразие. Кроме того, возможность настройки RPC с двунаправленной потоковой передачей была интересна с точки зрения реализации соединений клиент-сервер с RPC-серверами, поэтому мы сделали ее основой протокола управления.

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

enum RequestType {
 Control_Config       = 0;
 Control_Hearbeat     = 1;
 Control_MySQLClient  = 10;
 Control_MySQLBinlog  = 11;
 Control_Syslog       = 12;
 Control_PgSQLClient  = 13;
 Control_PgSQLWal     = 14;
 Control_PgSQLLogDec  = 15;
 Control_Kafka        = 16; 
 Control_MSSQLClient  = 17;
}

Этот RequestType позволил нам получить исходные плагины со специализированными структурами, которые они ожидают. Обратите внимание, что мы отделили клиентов БД от репликации БД (binlog, WAL…). Основная причина в том, что они не имеют одной и той же области видимости, поэтому библиотеки не совпадают. Поэтому имело смысл держать их отдельно.

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

Эти опасения подтолкнули нас к модульной конструкции агента Menura:

Фильтрация данных

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

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

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

filter_policy: accept/drop
filter:
 table_a:
 table_b:
   ignored_columns:
     — sensibleColumn

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

Валидации в гетерогенных системах

В некоторых случаях вы можете подтвердить, что обрабатываете аналитическое задание на тех же данных, из которых состоит настоящая база данных. Например, для расчета выручки за определенный период требуются достоверные данные от даты до даты. Проверка состояния репликации между базой данных и озером данных была сложной задачей. На самом деле проверки целостности не реализуются с той же логикой в ​​базах данных или хранилищах, поэтому нам нужен был способ абстрагировать их от собственной реализации. Мы подумали об использовании структуры данных Merkle Tree , чтобы мы могли поддерживать дерево целостности с блоками или строками. Если ключ / значение отличается от базы данных, то это будет отражать глобальный или промежуточный хэш целостности, и нам нужно будет сканировать только листовой блок, который имеет несогласованный хэш между обеими системами.

Соберем все вместе

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

Соединения между базами данных в реальном времени

Пока мы строили озеро данных из реплицированных таблиц, и поскольку этот проект был в основном для целей бизнес-аналитики, мы рассмотрели возможность добавления некоторых аналитических данных в реальном времени на основе той же логики, которую мы используем с пакетными заданиями и заданиями Apache Pig . С 2015 года самой продвинутой структурой обработки потоков является Apache Flink , которую мы использовали для обработки соединений в реальном времени между различными базами данных и таблицами.

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



Мы выбрали Apache Flink по нескольким причинам:

• Его документация была восхитительной
• Его основной движок был великолепен и намного превосходил Apache Spark (проекта Tungsten там даже не было).
• Это был европейский проект , поэтому мы были близки к редактору и его сообществу.

Индексирование в реальном времени

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

Здесь Гийом сотворил чудо! Повторно используя Lily , индексатор HBase, предоставляющий концепцию SEP (обработчик побочных эффектов), ему удалось повторно внедрить схему агрегированной таблицы в Lily, чтобы построить отображение типов данных, необходимое для чтения значений байтовых массивов HBase, перед их индексированием в Solr. Теперь у нас была панель мониторинга в реальном времени, представляющая собой агрегированную объединенную таблицу в реальном времени, обработанную на основе сбора данных об изменении в реальном времени. Бум!



Именно тогда мы начали привлекать реальных клиентов к нашему новому решению.

Жить!

Если по-прежнему существует необходимость продемонстрировать, что тестирование в среде моделирования — это не то же самое, что тестирование в производственной среде, эта следующая часть, вероятно, разрешит спор…

После настройки конвейера данных мы обнаружили несколько ошибок в производственной среде. Вот два из них:

Чередующиеся события

Согласно определению MySQL, структура события состоит из заголовка и поля данных.

В репликации на основе строк (RBR), в отличие от репликации на основе операторов (SBR), событие каждой строки реплицируется с соответствующими данными. Операторы DML разделены на две части:

• А TABLE_MAP_EVENT
• A ROWS_EVENT(может быть WRITE, UPDATEили DELETE)

Первое событие, TABLE_MAP_EVENTописывает метаданные содержимого второго события. Эти метаданные содержат:

• Включенные поля
• Растровые изображения с нулевыми значениями
• Схема предстоящих данных
• Метаданные для предоставленной схемы

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

Иногда некоторые события не обрабатывались должным образом, поскольку несогласованность между метаданными и данными приводила к VARCHARдекодированию DATETIMEзначений как значений и т. Д.

После некоторой отладки выяснилось, что команда DBA добавила триггеры в некоторые таблицы MySQL. Когда несколько дней спустя реплики были перестроены, они унаследовали эти функции и начали регистрировать события, производимые этими триггерами.

Дело в том, что в MySQL триггеры являются внутренними. В binlog каждое событие, исходящее от мастера, отправляется следующим образом:

TableMapEvent_a

TableMapEvent_a
WriteEvent_a
TableMapEvent_b
WriteEvent_b
TableMapEvent_c
WriteEvent_c

a, bи cпредставляет события для разных таблиц schema.tables.


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


Когда MySQL запускает событие, он отправляет его в двоичный журнал, поэтому вы закончите мультиплексированием двух TableMapEvents, а затем двух RowsEvents, как показано ниже:

TableMapEvent_a
TableMapEvent_a_event
WriteEvent_a
WriteEvent_a_event

Понял! Когда мы пытались декодировать WriteEvent_a, предыдущее TableMapEvent предназначалось для TableMapEvent_a_event, а не для TableMapEvent_a, поэтому он пытался декодировать событие с неправильной схемой.

Нам нужно было найти способ сопоставить WriteEvent с соответствующим TableMapEvent. В идеале в структуре должен был быть TableID, который мы могли бы использовать для этого. В конце концов, нам просто нужно было буферизовать все TableMapEvents, сделав их доступными для всех RowsEvent, начать чтение RowsEvent, выбрать TableID, а затем получить метаданные Columns из соответствующего TableMapEvent. Исправлена!

Неуловимая десятичная дробь ...

Мы также столкнулись с произвольной ошибкой в ​​библиотеке, из-за которой Menura взорвалась. И снова мы углубились в библиотеку binlog, чтобы шаг за шагом отладить процесс декодирования. Мы определили кортежи таблицы / столбца, чтобы ограничить вывод журнала до более разумной скорости. А RowEventвыглядело так:

DEBUG MR: TableMapEvent.read() : event.TableName = myTable
DEBUG MR: TableMapEvent.read() : columnCount= 16
DEBUG MR: TableMapEvent.read() : Read Next columnTypeDef= [3 3 15 246 0 0 12 0 15 12 12 15 3 3 15 15]
DEBUG MR: readStringLength() : r.Next(int(12))
DEBUG MR: TableMapEvent.read() : ReadStringLength columnMetaDef= [255 0 10 2 40 0 10 0 255 0 255 3]
DEBUG MR: TableMapEvent.read() : columnNullBitMap= [10 198]
DEBUG MR: TableMapEvent.read() : switch columnTypeDef[3]=f6
DEBUG MR: TableMapEvent.read() : switch : case metaOffset+=2
DEBUG MR: TableMapEvent.read() : column.MetaInfo
DEBUG MR: TableMapEvent.read() : column.MetaInfo = [10 2]

В этом журнале есть довольно интересные части процесса декодирования, на которые стоит обратить внимание. В первом столбце представлена ​​следующая схема:

TableMapEvent.read() : Read Next columnTypeDef= [3 3 15 246 0 0 12 0 15 12 12 15 3 3 15 15]

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

TableMapEvent.read() : ReadStringLength columnMetaDef= [255 0 10 2 40 0 10 0 255 0 255 3]

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

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

DEBUG MR: rowsEvent.read(): pack.Len() BEFORE : 59
DEBUG MR: rowsEvent.read(): Column.MetaInfo: &{246 [10 2] true}
DEBUG MR: rowsEvent.read(): switch column.Type= 246
DEBUG MR: case MYSQL_TYPE_NEWDECIMAL
DEBUG MR: readNewDecimal() precision= 10 scale= 2
DEBUG MR: readNewDecimal() size= 5
DEBUG MR: readNewDecimal() buff=8000000000
DEBUG MR: readNewDecimal() decimalpack=0000000000
DEBUG MR: rowsEvent.read(): pack.Len() AFTER : 54
DEBUG MR: rowsEvent.read(): value : 0
DEBUG MR: rowsEvent.read(): pack.Len() BEFORE : 54
DEBUG MR: rowsEvent.read(): Column.MetaInfo: &{0 [] false}
DEBUG MR: rowsEvent.read(): switch column.Type= 0

Что касается предыдущей схемы, у нас есть 16 столбцов, и согласно документации MySQL наши типы данных предоставляют метаданные, как в следующей таблице:Это дает нам 18 байтов метаданных для схемы этого примера, в отличие от 10 байтов в пакете.Мы также обнаружили, что MySQL явно не отправлял метаданные, необходимые для чтения DECIMALзначений в пакете. Было ли это нормальным поведением?Документация MySQL ясна: чтобы прочитать DECIMALзначение, вам нужны метаданные (точность, масштаб и т. Д.). Период.Однако мы обнаружили, что с этим MYSQL_TYPE_DECIMALобращались как MYSQL_TYPE_NEWDECIMAL.

case MYSQL_TYPE_DECIMAL, MYSQL_TYPE_NEWDECIMAL:
value.value = pack.readNewDecimal(int(column.MetaInfo[0]), int(column.MetaInfo[1]))

Мы отступили и стали искать, как это MYSQL_TYPE_DECIMALреализовано в других библиотеках binlog. Я не был администратором баз данных, но мне показалось странным, что в схеме, использующей DECIMALзначения, на самом деле используются два разных типа данных MySQL.

Хорошо… «Хьюстон, у нас проблема».

Во-первых, никто не внедрял его MYSQL_TYPE_DECIMAL, и по очень веской причине: мы не должны его получать, поскольку он устарел из MySQL, начиная с версии 5.0. Это означало, что в базе данных, лежащей в основе, работала таблица, созданная (в лучшем случае) из MySQL 4.9, в то время как база данных была обновлена ​​без надлежащего ALTER для автоматического преобразования типов данных в MYSQL_TYPE_NEWDECIMAL.

Во-вторых, поскольку у нас нет никакого контроля над базой данных, как нам декодировать MYSQL_TYPE_DECIMAL…

Первая попытка: игнорировать

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

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

Вторая попытка: наивный подход (т.е. догадки!)

Десятичное значение — это дробное число, обычно кодируемое как число с плавающей запятой. Например, в DECIMAL(10,2)столбце восемь разрядов целого числа и две цифры дробной части. Целые цифры определяют количество байтов, которые необходимо прочитать. Например, мы читаем четыре байта для целой части и один байт для дробной части. Это было бы так просто… если бы у нас были метаданные.

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

Кто-то может возразить, что если MySQL не предоставляет никаких метаданных, это потому, что он хранит их внутри, в фиксированном размере. Ну нет!

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

DEBUG MR: case MYSQL_TYPE_DECIMAL
DEBUG MR: readOldDecimalV2: byte = 32
DEBUG MR: readOldDecimalV2: continue
DEBUG MR: readOldDecimalV2: byte = 32
DEBUG MR: readOldDecimalV2: continue
DEBUG MR: readOldDecimalV2: byte = 32
DEBUG MR: readOldDecimalV2: continue
DEBUG MR: readOldDecimalV2: byte = 32
DEBUG MR: readOldDecimalV2: continue
DEBUG MR: readOldDecimalV2: byte = 32
DEBUG MR: readOldDecimalV2: continue
DEBUG MR: readOldDecimalV2: byte = 32
DEBUG MR: readOldDecimalV2: continue
DEBUG MR: readOldDecimalV2: byte = 32
DEBUG MR: readOldDecimalV2: continue
DEBUG MR: readOldDecimalV2: byte = 48
DEBUG MR: readOldDecimalV2: start writing
DEBUG MR: readOldDecimalV2: byte = 46
DEBUG MR: readOldDecimalV2: dot found
DEBUG MR: readOldDecimalV2: writing
DEBUG MR: readOldDecimalV2: byte = 48
DEBUG MR: readOldDecimalV2: writing
DEBUG MR: readOldDecimalV2: byte = 48
DEBUG MR: readOldDecimalV2: writing
DEBUG MR: readOldDecimalV2: byte = 32
DEBUG MR: readOldDecimalV2: unread, break
DEBUG MR: readOldDecimalV2: converting to float : 0.00
DEBUG MR: rowsEvent.read(): pack.Len() AFTER : 43
DEBUG MR: rowsEvent.read(): value : 0

Мы надеемся, что мы не встретим следующий тип VARCHAR с длиной, которую можно было бы проанализировать как значение DIGIT, но динамический размер значения DECIMAL означает, что должны быть доступны метаданные для правильного чтения. Другого пути нет.

Третья попытка: когда дело доходит до хорошего раба, компромиссов нет!

Мы спросили себя, что отличает mysqlbinlog от MySQL Slave, когда дело доходит до чтения двоичных журналов. Мы обнаружили, что единственная разница заключалась в том, что истинное ведомое устройство знало DECIMALсхему и связанные с ней метаданные при получении этих данных. Таким образом, ему не пришлось бы ничего гадать — просто прочтите нужное количество байтов в соответствии с известной схемой.

В итоге мы реализовали клиент MySQL в нашем источнике mysqlbinlog, который изначально сбрасывал схемы таблиц для передачи значения NumericScale в библиотеку декодирования. Проблема здесь в том, что строки не идентифицируются в схемах по их ColumnName. MySQL поддерживает OrdinalPositionстолбцы в таблице, но это не идентификатор, указанный в протоколе binlog (это было бы слишком просто!). Вы должны поддерживать свой собственный индекс столбца из схемы, чтобы он соответствовал тому, который вы получите в протоколе binlog. Как только он у вас есть, просто найдите значение десятичной шкалы, чтобы узнать, сколько байтов вам еще нужно прочитать после точки.

Таким образом, библиотека декодирования теперь могла декодировать MYSQL_TYPE_DECIMALиз потока событий binlog. Ура!!!

TL; DR

В итоге создание стека бизнес-аналитики с нуля заняло примерно шесть месяцев. В команду входило 2,5 человека: Алексис Жендронно, Гийом Салоу (который присоединился к нам через три месяца) и я. Он продемонстрировал принцип сбора измененных данных, применяемый к реальным вариантам использования, позволяя в реальном времени получать информацию о продажах, запасах и многом другом, без какого-либо влияния на производственную среду. Команда росла по мере расширения масштабов проекта за счет новых, более требовательных клиентов, таких как группы финансовых услуг и управленческого контроля. Спустя несколько недель нам удалось запустить его на Apache Flink на основе того же конвейера данных, который с тех пор стал надежным источником для расчета доходов и других бизнес-KPI.

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

Вся команда проделала отличную работу, и Димитри Капитан собирается открыть исходный код агента сбора данных, который использовался в предварительных лабораториях: сборщик данных OVH. Если вы заинтересованы в более подробном обсуждении системы отслеживания измененных данных в OVH, не стесняйтесь присоединиться к нам в Gitter команды или написать мне в Twitter.

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

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



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

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

LoadBalancer

ключевую функцию нашего первого коммерческого выпуска.

Чтобы попытаться лучше ответить на вопрос о внешнем трафике и упростить внедрение 

LoadBalancer

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

Это сообщение в блоге представляет собой расширенную версию этого руководства. Надеемся, оно вам пригодится!

Некоторые понятия: ClusterIP, NodePort, Ingress и LoadBalancer

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

Есть несколько способов перенаправить внешний трафик в ваш кластер:

1. Использование Kubernetes прокси и ClusterIP: По умолчанию значения Kubernetes ServiceType является ClusterIp, что выставляет Service на кластерной внутренний IP. Чтобы получить доступ к ClusterIp из внешнего источника, вы можете открыть прокси Kubernetes между внешним источником и кластером. Обычно это используется только для разработки.

2. Предоставление сервисов как NodePort: объявление Service as открывает NodePortего на IP-адресе каждого узла на статическом порте (называемом NodePort). Затем вы можете получить доступ к Service извне кластера, запросив :. Это также можно использовать для производства, хотя и с некоторыми ограничениями.

3. Предоставление услуг как LoadBalancer: объявление Service as LoadBalancer предоставляет его внешнему виду с помощью решения балансировки нагрузки поставщика облачных услуг. Облачный провайдер предоставит балансировщик нагрузки для Serviceи сопоставит его с автоматически назначенным NodePort. Это наиболее широко используемый метод в производственной среде.

Использование прокси Kubernetes и ClusterIP

По умолчанию Kubernetes ServiceType это ClusterIp, что выставляет Service на кластерной внутренний IP. Чтобы получить доступ ClusterIp с внешнего компьютера, вы можете открыть прокси Kubernetes между внешним компьютером и кластером.

Вы можете использовать kubectl для создания такого прокси. Когда прокси включен, вы напрямую подключены к кластеру и можете использовать для этого внутренний IP-адрес (ClusterIp) Service.



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

Предоставление услуг как NodePort

Объявление службы как NodePort раскрывает Service IP-адрес каждого узла в NodePort (фиксированный порт для этого Serviceв диапазоне по умолчанию 30000-32767). Затем вы можете получить доступ к Service извне кластера, запросив :. Каждая служба, которую вы развертываете, NodePort будет отображаться в своем собственном порту на каждом узле.



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

Предоставление услуг как LoadBalancer

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



Это LoadBalancer лучший вариант для производственной среды, но с двумя оговорками:

• Все, Service что вы развернете LoadBalancer, получит собственный IP.
• LoadBalancer Обычно выставлен счет на основании количества выставляемых услуг, которые могут быть дорогими.

В настоящее время мы предлагаем услугу OVH Managed Kubernetes LoadBalancer в качестве бесплатной предварительной версии до конца лета 2019 года.

О чем Ingress?

Согласно официальной документации, Ingress это объект API, который управляет внешним доступом к службам в кластере (обычно HTTP). Так в чем разница между этим и LoadBalancer или NodePort?

Ingress это не тип Service, а объект, который действует как обратный прокси-сервер и единственная точка входа в ваш кластер, который направляет запрос различным службам. Самый простой из них Ingress — это NGINX Ingress Controller, где NGINX берет на себя роль обратного прокси, а также работает как SSL.



Ingress ClusterIP доступен за пределами кластера через прокси Kubernetes NodePort, или LoadBalancer, и направляет входящий трафик в соответствии с настроенными правилами.



Основное преимущество использования Ingress за одним LoadBalancer — это стоимость: вы можете иметь множество услуг за одним LoadBalancer.

Какой мне использовать?

Что ж, это вопрос на миллион долларов, и он, вероятно, вызовет разный ответ в зависимости от того, кого вы спросите!

Вы можете пойти на все 100% LoadBalancer, получив индивидуальную LoadBalancer услугу. Концептуально это просто: каждая служба независима и не требует дополнительной настройки. Обратной стороной является цена (вы будете платить за одну LoadBalancer услугу), а также сложность управления множеством разных IP-адресов.

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

Если вы хотите узнать мое личное мнение, я бы попытался использовать комбинацию из двух…

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

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

Что такое сервисная сетка?

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

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

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

Машинное обучение и особенно глубокое обучение — горячие темы, и вы наверняка встречали модное слово «искусственный интеллект» в СМИ.



Однако это не новые концепции. Первая искусственная нейронная сеть (ИНС) была представлена ​​в 40-х годах. Так почему же в последнее время такой интерес к нейронным сетям и глубокому обучению? 

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

YABAIR — еще один блог о распознавании изображений

Я помню, как в 80-е мой отец создавал распознавание символов для банковских чеков. Он использовал примитивы и производные для определения уровня темноты пикселей. Изучение стольких разных типов почерка было настоящей болью, потому что ему требовалось одно уравнение, применимое ко всем вариантам.

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

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

Факт 1: это так же просто, как подсчет

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



Теперь давайте попробуем распознать (вывести) новую рукописную цифру, подсчитав количество совпадений с одинаковыми красными формами. Затем мы сравним это с нашей предыдущей таблицей, чтобы определить, какое число имеет больше всего соответствий:



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

Факт 2: изображение — это просто матрица

Компьютер рассматривает изображение как матрицу . Черно-белое изображение — это 2D-матрица.

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

Каждая ячейка матрицы представляет интенсивность пикселя от 0 (который представляет черный цвет) до 255 (который представляет чистый белый пиксель).

Таким образом, изображение будет представлено в виде следующей матрицы 28 x 28 пикселей.

Факт 3: сверточные слои — это просто сигналы летучей мыши

Чтобы выяснить, какой узор отображается на картинке (в данном случае рукописная цифра 8), мы будем использовать своего рода сигнал летучей мыши / фонарик. В машинном обучении фонарик называется фильтром. Фильтр используется для выполнения классического вычисления матрицы свертки, используемого в обычном программном обеспечении для обработки изображений, таком как Gimp.



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

Факт 4: сопоставление фильтров — это досадно параллельная задача.

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

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

Факт 5: просто повторите операцию фильтрации (свертку матрицы) как можно больше раз.

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

Чтобы повысить точность распознавания изображений, просто возьмите отфильтрованное изображение из предыдущей операции и фильтруйте снова, снова и снова…

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

Это похоже на создание новых слоев абстракции, чтобы получить более четкое и ясное описание фильтра объекта, начиная с простых фильтров и заканчивая фильтрами, которые выглядят как края, колесо, квадраты, кубы,…

Факт 6: свертки матрицы — это просто x и +

Изображение стоит тысячи слов: следующее изображение представляет собой упрощенный вид исходного изображения (8 × 8), отфильтрованного с помощью фильтра свертки (3 × 3). Проекция фонарика (в этом примере фильтр Sobel Gx) дает одно значение.



Пример фильтра свертки (Sobel Gx), примененного к входной матрице (Источник: datascience.stackexchange.com/questions/23183/why-convolutions-always-use-odd-numbers-as-filter-size/23186)

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

Факт 7. Необходимо упростить и обобщить то, что было обнаружено? Просто используйте max ()

Нам нужно обобщить то, что было обнаружено фильтрами, чтобы обобщить знания .

Для этого мы возьмем образец вывода предыдущей операции фильтрации.

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

Вы можете использовать любую операцию уменьшения, такую ​​как: max, min, average, count, median, sum и т. Д.

Факт 8: сожмите все, чтобы встать на ноги

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

Если целью нейронной сети является обнаружение рукописных цифр, в конце будет 10 классов для сопоставления входного изображения с: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

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

Ниже приведен обзор оригинальной сверточной нейронной сети LeNet-5, разработанной Яном Лекуном, одним из немногих, кто начал использовать эту технологию для распознавания изображений.

Факт 9: Глубокое обучение — это просто Бережливое производство — постоянное улучшение на основе обратной связи

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

Давайте KISS (будьте проще): мы смотрим на выход сети, если предположение (выход 0,1,2,3,4,5,6,7,8 или 9) неверно, мы смотрим, какой фильтр (ы) «сделал ошибку», мы присваиваем этому фильтру или фильтрам небольшой вес, чтобы они не повторили ту же ошибку в следующий раз. И вуаля! Система учится и продолжает совершенствоваться.

Факт 10: все сводится к тому, что глубокое обучение до неловкости параллельно

Обработка тысяч изображений, запуск десятков фильтров, применение понижающей дискретизации, сглаживание вывода… все эти шаги могут выполняться параллельно, что делает систему невероятно параллельной . Как ни странно, на самом деле это совершенно параллельная  проблема, и это просто идеальный вариант использования GPGPU (General Purpose Graphic Processing Unit), которые идеально подходят для массовых параллельных вычислений.

Факт 11: нужно больше точности? Просто иди глубже

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

В заключение

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



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

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

Процесс доставки — это набор шагов — от 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