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

Контекст

Вы когда-нибудь задумывались, как:

• мы генерируем графики для вашего сервера OVHcloud или пакета веб-хостинга?
• наши внутренние команды контролируют свои собственные серверы и приложения?

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

Мы перепробовали множество различных баз данных временных рядов и в итоге выбрали Warp10 для обработки наших рабочих нагрузок. Warp10 может быть интегрирован с различными решениями для работы с большими данными, предоставляемыми Apache Foundation. В нашем случае мы используем Apache HBase в качестве хранилища данных долгосрочного хранения для наших показателей.

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

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

• от 1,6 до 2 миллионов операций записи в секунду, 24/7
• от 4 до 6 миллионов чтений в секунду
• около 300 ТБ телеметрии, хранящейся в Apache HBase

Как вы, вероятно, можете себе представить, хранение 300 ТБ данных на 270 узлах сопряжено с некоторыми проблемами, связанными с перераспределением, поскольку каждый бит является горячими данными и должен быть доступен в любое время. Давайте нырнем!

Как работает балансировка в Apache HBase?

Прежде чем погрузиться в балансировщик, давайте посмотрим, как он работает. В Apache HBase данные разделяются на сегменты, вызываемые Regionsи распределяемые по ним RegionServers. Количество регионов будет увеличиваться по мере поступления данных, и в результате регионы будут разделены. Вот тут-то и пригодится Balancer. Он будет перемещать регионы, чтобы избежать появления горячих точек, RegionServerи эффективно распределяет нагрузку.



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

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

   cost functions

   . Каждая функция стоимости возвращает число от 0 до 1 включительно , где 0 — это решение с наименьшей стоимостью и лучшим решением, а 1 — с максимально возможной стоимостью и наихудшим решением. Apache Hbase поставляется с несколькими функциями стоимости, которые измеряют такие вещи, как загрузка региона, загрузка таблицы, локальность данных, количество регионов на сервер RegionServer… Вычисленные затраты масштабируются с помощью соответствующих коэффициентов, определенных в конфигурации .
2. Теперь, когда начальная стоимость вычислена, мы можем попробовать 

   Mutate

   наш кластер. Для этого Balancer создает случайный случай 

   nextAction

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

   thousands of times

   , поэтому файл 

   Stochastic

   .
3. В конце список допустимых действий применяется к фактическому кластеру.

Что у нас не работало?

Мы выяснили это для нашего конкретного варианта использования , который включает:

• Один стол
• Выделенные Apache HBase и Apache Hadoop, адаптированные к нашим требованиям
• Хорошее распределение ключей

… Количество регионов на RegionServer было для нас настоящим пределом

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

В итоге мы получили разные группы оборудования: некоторые серверы могут обрабатывать только 180 регионов, тогда как самые большие могут обрабатывать более 900 . Из-за этого несоответствия нам пришлось отключить балансировщик нагрузки, чтобы избежать использования RegionCountSkewCostFunction , которая попыталась бы перенести все RegionServers в одно и то же количество регионов.



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

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

Наш вклад

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

Второй вклад касался добавления дополнительной функции costFunction для балансировки регионов в соответствии с правилом емкости.

Как это работает?

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

rs[0-9] 200
rs1[0-9] 50

RegionServers с именами хостов, соответствующими первым правилам, будут иметь ограничение 200 , а остальные 50 . Если совпадений нет, устанавливается значение по умолчанию.

Благодаря этому правилу у нас есть две ключевые части информации:

• максимальное число областей для этого кластера
• то правила для каждого сервера

Они 

HeterogeneousRegionCountCostFunction 

постараются сбалансировать регионы по своим возможностям.

Возьмем пример… Представьте, что у нас есть 20 RS:

• 10 RS, названный 

  rs0

  в 

  rs9

  , нагруженные 60 регионов каждый, каждый из которых может рукоятку 200 регионов.
• 10 RS, названные 

  rs10

  в 

  rs19

  , нагруженные 60 регионов каждый, каждый из которых может обрабатывать 50 областей.

Итак, исходя из следующих правил

rs[0-9] 200
rs1[0-9] 50

… Мы видим, что вторая группа перегружена, тогда как в первой группе много места.

Мы знаем, что можем обрабатывать максимум 2500 регионов (200 × 10 + 50 × 10), и в настоящее время у нас есть 1200 регионов (60 × 20). Таким образом, система 

HeterogeneousRegionCountCostFunction

поймет, что кластер заполнен на 48,0% (1200/2500). Основываясь на этой информации, мы попытаемся поставить все серверы RegionServers на ~ 48% нагрузки в соответствии с правилами.

Куда дальше?

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

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

« У тебя нет шансов». «Ты уже мертв». «Тебя сожрут заживо». За последние 21 год я слышал, как люди говорят эти вещи несколько раз в неделю. Их часто говорят люди, которые не понимают, что делает OVHcloud. Никогда не людьми в поле. Я их не виню. Они ясно думают: «Нельзя легко иметь конкурентов Amazon, Microsoft и Google»… Прежде всего, я всегда стремился стать участником соревнований и каждое утро говорю себе, что мы соревнуемся с лучшими в мире. Затем попробуйте назвать хоть одну компанию в мире, которая не будет конкурировать с этими гигантами, если они еще не являются конкурентами. Когда люди говорят мне, что у OVHcloud нет шансов, первое впечатление, которое я получаю, заключается в том, что они понятия не имеют, что они будут делать в своей области знаний. И то, что они не знают, как конкурировать с этими гигантами, не означает, что мы не нашли способа. Наоборот.

OVHcloud только что завершил свой четвертый стратегический план. В период с 2015 по 2019 год мы увеличились как минимум вдвое по всем нашим ключевым показателям эффективности. В этом году мы приступаем к реализации пятого стратегического плана, который завершится в 2024 году. Наша стратегия основана на пяти составляющих: культура, клиенты, облако, завоевание, затраты. В течение следующих нескольких месяцев мы сможем еще раз взглянуть на эту стратегию и поделиться подробностями нашего выполнения в 2020 году. В этом посте я хотел бы поделиться своим долгосрочным глобальным видением OVHcloud, основанным на европейских ценностях. С 1999 года я думал о том, где бы я хотел быть через 20 лет — и даже сегодня я думаю о том, где будет OVHcloud в 2040 году.



Есть ряд косвенных факторов:

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

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

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

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

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



Я могу думать так из-за моего личного прошлого, но, без сомнения, это еще и потому, что я мыслю как европеец. Свобода особенно важна для OVHcloud. Наш девиз: «Инновации во имя свободы», является символом этого видения. Если бы я был американцем, я бы, вероятно, владел всего 15% компании стоимостью несколько десятков миллиардов долларов, в отличие от 80% компании стоимостью несколько миллионов долларов. Если бы я был американцем, я бы подумал, что меньший кусок большего торта был бы для меня лучше, чем больший кусок меньшего торта. Но поскольку я европеец, я не думаю о кусках торта. Я думаю о долгосрочной перспективе, я думаю о Европе, я думаю об экосистеме и я думаю о «нас». Сегодня OVHcloud — единственное европейское облачное предприятие, которое достигло критического размера для работы во всем мире. Для меня было ответственностью укрепить это видение для европейцев в течение последних 20 лет, не подвергая OVHcloud тендерным предложениям, стратегическим изменениям, кризисам управления и финансовым кризисам.

OVHcloud — это инструмент, который я предлагаю европейцам, чтобы помочь им войти в этот новый, цифровой мир, сохраняя при этом свои ценности и мечты. Это инструмент 21-го века из-за его экосистемной ДНК и возможностей для сотрудничества. Даже если OVHcloud приобретет другие компании, мое главное стремление — не стать капиталистическим конгломератом, похожим на облачную версию Airbus. OVHcloud стремится способствовать созданию экосистемы, в которой компании могут раскрывать свой талант, сотрудничать вместе, оставаться независимыми и контролировать свою судьбу. OVHcloud стремится поддержать появление цифровых предприятий, которые будут приносить от 100 до 200 миллионов долларов годового дохода. Чтобы быть сильными, организации постоянно влияют на идентичность и основные ценности друг друга, чтобы они не исчезли. Быть сильным, Европейское облако должно работать как живая организация, состоящая из нескольких тысяч компаний, которые развиваются или исчезают. Таким образом, он может постоянно адаптироваться к текущей реальности. Он отличается от американских и китайских моделей, и я думаю, что он действительно наш. Это европейская модель.

Что такое снимок в публичном облаке OpenStack / OVHcloud?

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

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

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

Как создать снимок

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

Чтобы создать моментальный снимок экземпляра с помощью интерфейса командной строки, используйте следующую команду:

# Load your OpenStack credentials
$ source openrc

# Using the openstack client
$ openstack server image create --name <name of the new image> <instance name or uuid>

# Or using the nova client (deprecated)
$ nova image-create <instance name or uuid> <name of the new image>

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

После входа в Horizon вы можете создать моментальный снимок на странице « Вычислить» → «Экземпляры », щелкнув действие «Создать моментальный снимок».



Статус снимка и информацию о нем можно найти на странице Compute → Images.



Затем вы можете выбрать снимок при создании нового экземпляра.

Снимки в реальном времени и согласованность данных

Мы называем моментальный снимок, сделанный для работающего экземпляра без простоя, «живым моментальным снимком».

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

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

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

Обеспечение согласованности снимков

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

Эта связь происходит через виртуальное устройство, добавленное к экземпляру, когда OpenStack Nova обнаруживает, что используемое изображение имеет следующее свойство: hw_qemu_guest_agent set to yes.

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

# Using the openstack client
$ openstack image set --property hw_qemu_guest_agent=yes <image name or uuid>

# Or using the glance client (deprecated)
$ glance image-update --property hw_qemu_guest_agent=yes <image name or uuid>

Чтобы проверить, что свойства действительно установлены, используйте следующую команду:

$ openstack image show -f value -c properties <image name or uuid>

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



Конкретный шаг, который предотвращает любые несоответствия, — это №6: QEMU-agent замораживает файловую систему.

Настройка агента QEMU

Linux
Qemu-guest-agent не установлен по умолчанию, но после его установки и запуска механизм замораживания / размораживания файловой системы будет работать сразу после установки.

Вы можете проверить, настроен ли ваш экземпляр для связи с гипервизором, проверив конкретное устройство:

$ file /dev/virtio-ports/org.qemu.guest_agent.0
/dev/virtio-ports/org.qemu.guest_agent.0: symbolic link to `../vport2p1'

Если этого файла нет, гостевой агент qemu не будет работать, а это значит, что для вашего образа не установлено hw_qemu_guest_agentсвойство yes.

Дистрибутивы на основе Debian (Debian, Ubuntu)

# Install the agent
user@agent:~$ sudo apt-get update
user@agent:~$ sudo apt-get install qemu-guest-agent

# Check the agent is started (it should be automatically started and enabled)
user@agent:~$ sudo service qemu-guest-agent status

Распределения на основе Redhat (Centos, Fedora)

# Install the agent
user@agent:~$ sudo yum install qemu-guest-agent

# Enable the agent
user@agent:~$ sudo chkconfig qemu-guest-agent on

# Start the agent
user@agent:~$ sudo service qemu-guest-agent start

# Check the agent is started
user@agent:~$ sudo service qemu-guest-agent status

Windows

Загрузите и установите MSI, связанный с вашей архитектурой (32- или 64-разрядные версии, хотя мы рекомендуем 64-разрядные версии для публичного облака) из проекта Fedora: fedorapeople.org/groups/virt/virtio-win/direct-downloads/ последний-qemu-ga /

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

PS C:\Users\Administrator> Get-Service QEMU-GA

Status   Name               DisplayName
------   ----               -----------
Running  QEMU-GA            QEMU Guest Agent

Документацию Fedora по созданию образов Windows с драйверами virtIO можно найти здесь. [2]

Расширенное использование: перехватчики агента QEMU

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

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

Кроме того, в некоторых дистрибутивах уже есть ловушка fsfreeze.

Добавьте скрипт fsfreeze-hook

Во-первых, нам нужно добавить и активировать механизм fsfreeze-hook:

# Create the folders to receive the hooks
debian@agent:~$ sudo mkdir -p /etc/qemu/fsfreeze-hook.d

# Download the fsfreeze-hook from the QEMU repository
debian@agent:~$ sudo wget -O /etc/qemu/fsfreeze-hook https://raw.githubusercontent.com/qemu/qemu/master/scripts/qemu-guest-agent/fsfreeze-hook
debian@agent:~$ sudo chmod +x /etc/qemu/fsfreeze-hook

# Add the configuration of the qemu-guest-agent daemon to use this script
debian@agent:~$ sudo tee /etc/default/qemu-guest-agent > /dev/null <<EOF
DAEMON_ARGS="-F/etc/qemu/fsfreeze-hook"
EOF

# Restart the service to take the modifications into account
debian@agent:~$ sudo service qemu-guest-agent restart

Пример скрипта перехвата

/etc/qemu/fsfreeze-hook cкрипт позволяет пользователям добавлять пользовательские скрипты, которые будут выполняться до и после замораживания файловой системы.

Добавим тест, который записывает в файл при замораживании и оттаивании экземпляра:

debian@agent:~$ sudo tee /etc/qemu/fsfreeze-hook.d/test_hook.sh > /dev/null <<EOF
#!/bin/bash

case \$1 in
 freeze)
   echo "I'm frozen" > /tmp/freeze
   ;;
 thaw)
   echo "I'm thawed" >> /tmp/freeze
   ;;
 *)
   exit 1
   ;;
esac
EOF

debian@agent:~$ sudo chmod +x /etc/qemu/fsfreeze-hook.d/test_hook.sh

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

Сделайте снимок своего экземпляра:

$ openstack server image create --name test_snapshot <instance name or uuid>

Убедитесь, что тестовый хук запущен:

# It works!
debian@agent:~$ sudo cat /tmp/freeze
I'm frozen
I'm thawed

Очистите тест:

debian@agent:~$ sudo rm /etc/qemu/fsfreeze-hook.d/test_hook.sh /tmp/freeze

Почему это не включено по умолчанию?

Qemu-guest-agent не установлен по умолчанию в большинстве дистрибутивов. Так почему бы нам не добавить его по умолчанию в предоставляемые нами базовые изображения?

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

Источники:

• Запись в блоге Себастьяна Хана «OpenStack: выполнение согласованных снимков» [1]
• Вики-статья proxmox о гостевом агенте QEMU [2]
• Документация Fedora по созданию образов Windows с драйверами virtIO [3]

В октябре 2018 года, незадолго до саммита OVHcloud, я присоединился к платформе Product Unit Platform в качестве менеджера программы. С этой новой ролью возникла новая задача… поддержать команду, работающую над новым продуктом: OVHcloud Managed Kubernetes. Крайний срок был коротким, у нас было много дел, и нам нужно было обеспечить видимость как для менеджеров, так и для команд разработчиков. Но как программный менеджер у меня в сумке были нужные инструменты: SCRUM и agility.



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

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

• Организация нескольких презентаций и методических занятий
• Проведение личных встреч с командами в Париже и Лионе 
• Объяснение того, как метод будет работать во время реального спринта
• C ollectively разрабатывает руководство для нашей реализации метода SCRUM 

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

Ценность нашей маневренности

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

Чтобы быстро (пере) определить это, скорость — это количество «очков усилий», которые команда может выполнить во время спринта. Этот ключевой показатель позволил нам оценить, сколько работы наша команда могла бы выполнить за определенный период времени.

Скорость и усилия в нашем проекте Managed Kubernetes

Давайте посмотрим на упрощенную схему того, как этот метод работал в нашем проекте Managed Kubernetes:



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



Пример:



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

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

В прошлом году мы выпустили TSL как инструмент с открытым исходным кодом для выполнения запросов к Деформация 10 платформы, и выдвижением, OVHcloud Метрики Платформа данных .



Но как она развивалась с тех пор? Готов ли TSL запрашивать другие базы данных временных рядов ? Что насчет состояний TSL в экосистеме Warp10 ?

TSL для запроса многих баз данных временных рядов

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

Год спустя мы теперь знаем, что это был не лучший путь. Исходя из того, что мы узнали, тот TSL-адаптер проект был открытым исходным кодом, как доказательство концепции , как TSL может быть использован для запроса не-Деформация 10 базы данных. Проще говоря, TSL-адаптер позволяет TSL запрашивать InfluxDB .

Что такое TSL-адаптер?

TSL-адаптер — это API Quarkus JAVA REST, который можно использовать для запроса серверной части. TSL-адаптер анализирует запрос TSL, идентифицирует операцию выборки и загружает исходные необработанные данные из серверной части. Затем он вычисляет операции TSL с данными, прежде чем вернуть результат пользователю. Основная цель TSL-Adapter - сделать TSL доступным поверх других TSDB .



Говоря конкретно, мы запускаем JAVA REST API, который интегрирует библиотеку WarpScript в среду выполнения. Затем TSL используется для компиляции запроса в действительный запрос WarpScript. Это полностью прозрачно и касается только запросов TSL на стороне пользователя.


Чтобы загрузить необработанные данные из InfluxDB, мы создали расширение WarpScript. Это расширение объединяет абстрактный класс, 

LOADSOURCERAW

который необходимо реализовать для создания источника данных TSL-Adapter. Для этого требуется всего два метода: 

find

и 

fetch

. 

Find

собирает все селекторы серий, соответствующие запросу (имена классов, теги или метки), при этом 

fetch

фактически извлекает необработанные данные за определенный промежуток времени.

Приток запросов с TSL-адаптером

Для начала просто запустите InfluxDB локально на порту 8086. Затем давайте запустим агент Telegraf притока и запишем данные Telegraf на локальном экземпляре притока.

Затем убедитесь, что вы локально установили TSL-адаптер и обновили его конфигурацию, указав путь к tsl.soбиблиотеке.

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

Вы можете запустить TSL-адаптер с помощью следующего примера команды:

java -XX:TieredStopAtLevel=1 -Xverify:none -Djava.util.logging.manager=org.jboss.logmanager.LogManager -jar build/tsl-adaptor-0.0.1-SNAPSHOT-runner.jar

И это все! Теперь вы можете запрашивать свою базу данных притока с помощью TSL и TSL-адаптера.

Начнем с восстановления временного ряда, относящегося к измерениям диска.

curl --request POST \
  --url http://u:p@0.0.0.0:8080/api/v0/tsl \
  --data 'select("disk")'

Теперь давайте воспользуемся возможностями аналитики TSL!

Во-первых, мы хотели бы получить только данные, содержащие установленный режим rw.

curl --request POST \
  --url http://u:p@0.0.0.0:8080/api/v0/tsl \
  --data 'select("disk").where("mode=rw")'

Мы хотели бы получать максимальное значение через каждые пятиминутные интервалы за последние 20 минут. Таким образом, запрос TSL будет:

curl --request POST \
  --url http://u:p@0.0.0.0:8080/api/v0/tsl \
  --data 'select("disk").where("mode=rw").last(20m).sampleBy(5m,max)'

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

Что нового в TSL с Warp10?

Изначально мы создавали TSL как прокси GO перед Warp10. TSL теперь интегрировал экосистему Warp 10 как расширение Warp10 или как библиотеку WASM ! Мы также добавили несколько новых собственных функций TSL, чтобы сделать язык еще богаче!

TSL как функция WarpScript

Чтобы TSL работал как функция Warp10, вам необходимо, чтобы tsl.soбиблиотека была доступна локально. Эту библиотеку можно найти в репозитории TSL на github. Мы также сделали расширение TSL WarpScript доступным в WarpFleet, репозитории расширений сообщества Warp 10.

Чтобы настроить расширение TSL на Warp 10, просто загрузите JAR, указанный в WarpFleet. Затем вы можете настроить расширение в файле конфигурации Warp 10:

warpscript.extensions = io.ovh.metrics.warp10.script.ext.tsl.TSLWarpScriptExtension
warpscript.tsl.libso.path = <PATH_TO_THE_tsl.so_FILE>

После перезагрузки Warp 10 все готово. Вы можете проверить, работает ли он, выполнив следующий запрос:

// You will need to put here a valid Warp10 token when computing a TSL select statement
// '<A_VALID_WARP_10_TOKEN>' 

// A valid TOKEN isn't needed on the create series statement in this example
// You can simply put an empty string
''

// Native TSL create series statement
 <'
    create(series('test').setValues("now", [-5m, 2], [0, 1])) 
'>
TSL

С помощью функции WarpScript TSL вы можете использовать собственные переменные WarpScript в своем скрипте, как показано в примере ниже:

// Set a Warp10 variable

NOW 'test' STORE

'' 

// A Warp10 variable can be reused in TSL script as a native TSL variable
 <'
    create(series('test').setValues("now", [-5m, 2], [0, 1])).add(test)
'>
TSL

TSL WASM

Чтобы расширить возможности использования TSL, мы также экспортировали его как библиотеку Wasm, так что вы можете использовать ее прямо в браузере! Версия библиотеки Wasm анализирует запросы TSL локально и генерирует WarpScript. Затем результат можно использовать для запроса к бэкэнду Warp 10. Более подробную информацию вы найдете на github TSL.

Новые возможности TSL

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

Мы добавили setLabelFromNameметод, чтобы установить новую метку для серии на основе ее имени. Эта метка может быть точным названием серии или результатом регулярного выражения.

Мы также доработали sortметод, позволяющий пользователям сортировать набор серий на основе метаданных серии (т. Е. Селектора, имени или меток).

Наконец, мы добавили filterWithoutLabels, чтобы отфильтровать набор серий и удалить все серии, не содержащие конкретных меток.

Спасибо за прочтение! Я надеюсь, что вы попробуете TSL, так как я хотел бы услышать ваши отзывы.

Встреча в Париже Time Series

Мы рады провести в парижском офисе OVHcloud третью встречу Paris Time Series, организованную Николасом Штайнметцем. Во время этой встречи мы поговорим о TSL, а также познакомимся с платформой Redis Times Series.

Если вы свободны, мы будем рады встретить вас там!

В наших предыдущих статьях мы объяснили, почему нам пришлось перенести 800 000 баз данных из одного центра обработки данных в другой, на расстоянии 300 километров. Итак, мы… Мы сделали это! Теперь мы сосредоточимся на очень важной цели любой миграции. С вашей точки зрения, как покупатель, вы должны видеть… Ничего! Я полностью это понимаю, так как я также являюсь клиентом OVH. И как клиент, оплачивающий услугу, я хочу, чтобы она работала, независимо от того, что делают люди за кулисами.



В этом посте мы увидим, как нам удалось (почти) легко переместить их всех…

Основы

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

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

$database_server = 'mydatabase.mysql.db';
$database_name = 'mydatabase';
$database_user = 'mydatabase';
$database_password = 'correct horse battery staple';
# ref: https://www.xkcd.com/936/

Затем он начинает диалог с сервером доменных имен (DNS), чтобы получить IP-адрес mydatabase.mysql.db. Как только IP известен, веб-сервер может взаимодействовать с сервером базы данных.



Но наличие одного сетевого имени для каждой базы данных — это что-то относительно новое в истории OVH. Впервые он был представлен пять лет назад, а здесь описана архитектура Gravelines.

20-летнее наследие

Вначале мы давали нашим клиентам IP-адрес сервера базы данных.

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

$database_server = '10.0.59.42';
$database_name = 'mydatabase';
$database_user = 'mydatabase';
$database_password = 'correct horse battery staple';
# ref: https://www.xkcd.com/936/

Поскольку у нас есть постоянные клиенты (включая многих из вас, в данном случае!), Это была неплохая идея, но не очень масштабируемая.



Итак, чтобы упростить управление сервером, окончание срока службы оборудования и т. Д., OVHcloud перешла на предоставление нашим клиентам имени сервера вместо IP-адреса сервера.

$database_server = 'mysql55-59.pro';
$database_name = 'mydatabase';
$database_user = 'mydatabase';
$database_password = 'Brussels Sprouts Mandela Effect';
# ref: https://www.xkcd.com/2241/

Подводя итог, у нас есть три способа подключения к базе данных в P19:

• Использование IP сервера
• Использование имени сервера
• Использование имени базы данных

Блокиратор

Следуя правилам, описанным здесь, поскольку мы перемещали ваши базы данных по отдельности, а не весь сервер за раз, а базы данных перетасовывались во все наши новые экземпляры, а не оставались с их соседом, мы не могли повторно использовать IP-адрес сервера. Кроме того, мы не могли повторно использовать имя сервера.

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

Значит, нам пришлось бы:

• Разбирайте сотни терабайт. Выполнимо, но требует много времени.
• Разберитесь в организации вашего сайта. Это можно автоматизировать для 99% всех различных случаев использования, но 1% из 1,5 млн веб-сайтов по-прежнему представляют собой 15 000 потенциально поврежденных веб-сайтов после замены.
• Замените IP или имя сервера именем базы данных. Возможно, но не на 100% надежно.

Что, если заказчик:

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

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

Если конфигурация была:

• mydatabase.mysql.db: Нет проблем. DNS был обновлен.
• имя_сервера: запрос достигнет сервера и его нужно будет перенаправить.
• IP-адрес сервера: запрос достигнет сервера и его необходимо будет перенаправить.

Решение

Может быть, некоторые из вас уже начали искать решение…

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

Мы решили использовать proxySQL Рене Канна.

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

Сторона Парижа

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

Наша архитектура позволяла нам устанавливать по одному ProxySQL на каждый хост базы данных. Это было сделано в период с 27 ноября по 6 декабря 2019 года (http://travaux.ovh.net/?do=details&id=35499).



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



Легко, не правда ли? Поскольку ProxySQL работает на том же хосте, нам не нужно было ничего подделывать, и это работало как шарм. Но что произойдет, если веб-сервер в Gravelines вызовет базу данных, которая все еще находится в Париже?

Сторона Гравелина

На этот раз у нас не было выбора, кроме как подделать имя сервера в Gravelines. Что мы могли использовать? Конечно же, ProxySQL! Но в нашей новой архитектуре мы просто не могли установить их на всех хостах, потому что, как было замечено ранее, у нас в Gravelines в 10 раз меньше клиентов на каждый экземпляр, чем в Париже.

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



Но как насчет конфигураций с IP-адресами в них? Поскольку у нас был ProxySQL, загруженный пользователями для группы серверов P19, мы могли — благодаря уловке с маршрутизацией — заставить веб-серверы думать, что IP-адреса P19 были настроены на ProxySQL!

Обратная сторона

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

Если вы хотите сохранить наш современный способ решения задач (а также помочь нам обеспечить плавность изменений!), Вы можете проверить, что ваш веб-сайт уже использует .mysql.db в ваших файлах конфигурации.

Вывод

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

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

Вы, возможно, помните ненормальное количество «max_user_connections» ( travaux.ovh.net/?do=details&id=35689 ).
Нам пришлось поиграться с исходным кодом ProxySQL, чтобы разрешить его использование против mysql 5.1 в сочетании с алгоритмом хеширования паролей до mysql 4.0. Мы обнаружили забавные вещи о кодировании в исходном коде, который мы исправили в апстриме.Мы смогли заполнить таблицу ARP нашего хоста несколько раз в час. Вы узнаете больше об этих проблемах в наших следующих публикациях!

OVHcloud недавно получил новое имя, чтобы подчеркнуть свою направленность: облако, чтобы дать вам возможность легко запускать свои рабочие нагрузки, не слишком заботясь о базовом оборудовании. Так зачем говорить о ПЛИС?

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



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

Зачем использовать ПЛИС?

ПЛИС — чрезвычайно универсальные микросхемы, их можно использовать для построения схем для очень широкого круга приложений:

• обработка сигнала
• финансы
• машинное обучение (классификация)
• сеть

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

Для сетевых приложений преимущества:

• прямое подключение к каналам 100GbE: нет сетевой карты, нет канала PCIe, пакеты принимаются непосредственно на чип
• доступ к памяти с чрезвычайно низкой задержкой и очень быстрым произвольным доступом (QDR SRAM: каждый банк позволяет около 250 миллионов операций чтения и записи в секунду)
• возможность создавать собственные конвейеры обработки пакетов для максимального использования ресурсов чипа.

Это позволяет нам обрабатывать 300 миллионов пакетов в секунду и 400 Гбит / с на одной плате FPGA с потребляемой мощностью менее 70 Вт.

Чтобы узнать больше о ПЛИС, хорошим ресурсом является электронная книга ПЛИС для чайников.

Традиционный рабочий процесс разработки FPGA

Языки, используемые для разработки на ПЛИС, имеют сильную специфику: в отличие от стандартных последовательных языков все происходит параллельно, чтобы моделировать поведение миллионов транзисторов, работающих параллельно на кристалле. Используются два основных языка: VHDL и SystemVerilog. Мы используем SystemVerilog. Вот пример модуля SystemVerilog:

// Simple example module: a counter
// Will clear if clear is 1 during one clock cycle.
// Will increment at each clock cycle when enable is 1.
 
`timescale 1ns / 1ps
 
module counter
    #(
        // Number of bits of counter result
        parameter WIDTH = 5
    )
    (
        input                    clk,
 
        // Control
        input                    enable,
        input                    clear,
         
        // Result
        output reg [WIDTH-1:0]   count = '0
    );
 
    always_ff @(posedge clk) begin
        if (clear) begin
            count <= '0;
        end else if (enable) begin
            count <= count + 1;
        end
    end
 
endmodule

Модули можно объединять вместе, соединяя их входы и выходы для создания сложных систем.

Тестирование на тренажере

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



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

Базовый симулятор предоставляется Xilinx, производителем FPGA. Более продвинутые симуляторы предоставляются Mentor или Synopsys. Эти тренажеры являются коммерческими и требуют дорогих лицензий.

Создание двоичного файла

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

Наш текущий рабочий процесс разработки FPGA

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



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

Использование нашего публичного облака

Настройка всех машин выполняется Ansible. Есть несколько важных ролей для установки различных важных компонентов:

• симулятор
• компилятор Xilinx, Vivado
• компилятор Intel, Quartus
• сервер лицензий для симулятора и компиляторов

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

Экземпляры, используемые для моделирования тестов и для компиляции, при необходимости запускаются с использованием OpenStack API. Это очень важно, поскольку позволяет запускать несколько наборов тестов параллельно для разных разработчиков. Это также очень важно для составления. Мы компилируем наши проекты для нескольких целей (ПЛИС Stratix V для 10 Гбайт и ПЛИС Ultrascale + для 100 Гбайт), поэтому нам необходимо выполнять несколько заданий компиляции параллельно. Кроме того, мы запускаем задания параллельно с несколькими начальными числами, чтобы повысить наши шансы получить правильный двоичный файл. Поскольку сборка наших проектов может длиться 12 часов, очень важно начать достаточно параллельно, чтобы быть уверенным, что мы получим хотя бы один рабочий двоичный файл.

Запуск тестов

Функциональные тесты очень важны, потому что они проверяют каждую функцию, предоставляемую нашими проектами. Тесты разработаны на Python с использованием scapy для отправки трафика и анализа результатов. Они могут работать как с имитацией проекта, так и с реальным дизайном на реальных платах FPGA. CDS может автоматически запускать тесты на реальных платах, зарезервировав лабораторные серверы и подключившись к ним через SSH. Тот же процесс используется для тестов производительности.

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

Идти дальше

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

HLS

Очень распространенный подход — использовать синтез высокого уровня (HLS). Он заключается в использовании языка высокого уровня для разработки модулей вместо SystemVerilog. С Vivado HLS можно разрабатывать на C ++. Также возможно использование OpenCL, который мы протестировали на платах Intel. Принцип HLS состоит в том, чтобы извлечь алгоритм из кода высокого уровня, а затем автоматически построить лучшую конвейерную архитектуру на FPGA. Но мы занимаемся обработкой пакетов, наши алгоритмы очень простые. Сложность нашего кода заключается в самой архитектуре, позволяющей поддерживать очень высокие скорости передачи данных. Таким образом, мы не смогли эффективно использовать HLS, код, который мы получили, был на самом деле более сложным, чем та же функция в SystemVerilog.

Долото

SystemVerilog является чрезвычайно низкоуровневым и не позволяет использовать высокий уровень абстракций (по крайней мере, если вы хотите, чтобы код можно было использовать компиляторами Intel и Xilinx). Что нам действительно нужно для упрощения разработки, так это возможность использовать более высокие уровни абстракции. Нам не нужен сложный компилятор, чтобы попытаться угадать лучшую архитектуру. Для этого у нас есть аспирант, который в настоящее время участвует в проекте с открытым исходным кодом: Chisel.

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

В настоящее время нет инструментов с открытым исходным кодом для фазы размещения и маршрута, по крайней мере, на самых последних ПЛИС Xilinx и Intel. Но Chisel может генерировать Verilog, который может использоваться проприетарными компиляторами.

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

Смена парадигмы

Сообщество с открытым исходным кодом чрезвычайно важно для того, чтобы сделать разработку FPGA все ближе и ближе к разработке программного обеспечения. Признаком улучшения является постепенное появление ПЛИС начального уровня в FabLabs и проектах электроники для хобби. Мы надеемся, что Xilinx и Intel FPGA последуют за ними, и что однажды они перейдут на открытый исходный код для своих компиляторов, что может сделать их более эффективными и совместимыми. ПЛИС — это ускорители, которые предлагают невероятную гибкость и могут быть мощной альтернативой центральным и графическим процессорам, но для демократизации их использования в облачных средах сообществу открытого исходного кода необходимо стать намного сильнее.

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

На чем основана эта стратегия?

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

Приоритетом является реагирование на потребность наших клиентов в автономии, предоставляя им поддержку, необходимую для эффективного управления своими решениями в режиме 24/7 с использованием цифровых инструментов.

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

Как мы начали трансформироваться?

Набор цифровых инструментов для наших клиентов

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

Справочный центр. С начала 2019 года OVHcloud предоставляет клиентам набор инструментов и решений, особенно в новом пространстве, первоначально для наших французских клиентов, которое называется Справочный центр. Справочный центр пользуется большим успехом: его посещают более 70 000 человек в месяц, а количество пользователей растет более чем на 20% месяц за месяцем. Этот справочный центр будет по-прежнему доработан и развернут на международном уровне в конце января 2020 г.



В этом пространстве клиенты могут легко найти ответы на наиболее часто задаваемые вопросы (например, «Как я могу отслеживать свой заказ?» «Как мне просмотреть свой счет?» И т. Д.), А также широкий спектр руководств, которые помогут им настроить и используйте решения OVHcloud. Наши руководства постоянно обновляются нашими консультантами и техническими обозревателями в соответствии с обширными отзывами клиентов, которые они получают. Каждый месяц наши гиды просматривают около 300 000 раз.

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

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

• Community.ovh.com : платформа сообщества, где клиенты могут помогать друг другу, задавать вопросы и получать ответы (от других клиентов и сотрудников OVHcloud).
• С помощью инструмента для измерения удовлетворенности клиентов содержанием наших руководств мы можем постоянно улучшать их качество. По нашим оценкам, уровень удовлетворенности пользователей нашего гида составляет 80%.

Живой чат

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

Более удобная панель управления OVHcloud

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

В целом, мы радикально меняем способ взаимодействия с клиентами. Взаимодействие через тикеты через панель управления OVHcloud составляет 50% запросов на поддержку, которые мы получаем.

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

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

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

Заказчики Интернета и телекоммуникаций — Market

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

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

Облачные клиенты

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

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

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

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

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

Корпоративные клиенты

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



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

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

Обязательства команд OVHcloud на этих уровнях должны обеспечивать согласованность между предоставляемым уровнем обслуживания и бизнес-задачами клиентов.

Уровень Business — это первый уровень профессиональных услуг. Он соединяет технические группы наших клиентов с командами OVHcloud, которые имеют опыт в соблюдении очень сжатых сроков в режиме 24/7 и быстро группируют вместе нужных экспертов для решения основных вопросов, связанных с производством и непрерывностью бизнеса. Знание наших клиентов — вот что помогает нам адаптироваться к конкретным ситуациям. Наша приверженность предоставлению объяснений по поводу происходящих инцидентов также должна помочь нашим клиентам повысить безопасность своих сред.

Уровень Enterprise — это контракт самого высокого уровня с самыми большими обязательствами.

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

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

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

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

Мы опубликуем больше сообщений по этой теме в будущем.

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

Всех с Новым годом!



В этом первом посте 2020 года я хотел бы побаловать себя обзором прошлого года для блога OVHcloud.

Первый год напряженного нового блога OVHcloud

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

Год закончился для нас отличными новостями, потому что блог OVHcloud был назван одним из 5 самых активных французских технических блогов в 2019 году вместе с нашими друзьями Criteo, Algolia, Sqreen и Dailymotion. Неплохо для нашего первого года!



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

О чем мы говорили?

Наиболее часто изучаемыми предметами были:

• Kubernetes
• Инфраструктура
• Метрики и наблюдаемость
• DevOps и автоматизация
• Машинное обучение
• Специальные серверы
• Место хранения

Некоторые основные моменты

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

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

Отказ от ответственности: это не строгий рейтинг, так как я помещаю в него только одно сообщение на категорию

Получение внешнего трафика в Kubernetes — ClusterIp, NodePort, Load Balancer и Ingress



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

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

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

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

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

Как мы обновили 850 vCenter за 4 недели

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

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

Глубокое обучение объяснили моей 8-летней дочери

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

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

Выделенные серверы: новые линейки уже в пути!

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

TSL: удобный для разработчиков язык запросов временных рядов для всех наших показателей

В процессе создания и эксплуатации платформы данных метрик OVHcloud наши команды накопили большой опыт работы с системами баз данных временных рядов (TSDB) и их возможностями анализа данных .

В этом посте Орелиен рассказал историю протокола OVHcloud Metrics , от OpenTSDB и PromQL до нашего внутреннего принятия WarpScript , и почему мы решили создать TSL с открытым исходным кодом, язык временных рядов, нацеленный на создание потока данных временных рядов как код.

Водяное охлаждение: от инноваций к революционным изменениям — Часть I

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

Одним из наиболее очевидных примеров является идея  использования воды для охлаждения наших серверов . Эта технология позволила нам постоянно  повышать производительность серверов  при одновременном  снижении энергопотребления  в наших центрах обработки данных.

В этом посте и его продолжении, которые были первыми в области промышленного применения OVHcloud,  Али  рассказал нам историю водяного охлаждения в OVHcloud — от первого поколения в 2003 году до последних прототипов. Готов поспорить, вы не ожидали, что облачная компания выпустит такой пост!

А на 2020 год?

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

Наши цели всегда одинаковы: отдать общину, демонстрация OVHcloud — й разнообразие и ноу-Faire, и дать нашим командам платформу для обмена проблем, с которыми они сталкиваются, и решением они реализуют.

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

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

Добро пожаловать в 2020 год. Это будет взрыв!

Что такое объектное хранилище?

Знаете ли вы, что большой объем данных в Интернете хранится в объектном хранилище?

Объектное хранилище — это решение для хранения статических данных, которое позволяет просто расширять хранилище без добавления дополнительного оборудования. Преимущества этого до сих пор неправильно понятого облачного сервиса многочисленны, и они включают высокую устойчивость и доступность. Однако, если бы мне пришлось выбрать один, я бы сказал, что хранилище объектов делает следующее сообщение об ошибке устаревшим: «На устройстве не осталось места».

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

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

Стандартный и двусторонний

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

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

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

API S3

Интерфейс программирования приложений Amazon S3 (S3 API) — наиболее распространенный способ хранения, управления и извлечения данных из хранилищ объектов. S3 API — это интерфейсный API поверх OpenStack Swift. Чтобы использовать S3 API в OVHcloud, вам необходимо получить учетные данные S3 в форме Keystone (1), которая является модулем аутентификации в OpenStack. Это предоставит вам идентификатор ключа доступа и секретный ключ, которые вы можете использовать в своем инструменте S3 (2). Получив эти учетные данные, вы сможете общаться с OVHcloud, используя «язык» S3, и использовать наши решения для объектного хранилища. S3 API проверит ваши учетные данные (4) и переведет ваши вызовы в Swift API (5) для выполнения ваших запросов (6).

Пример использования: API S3 в действии

Рассмотрим типичный пример: использование S3 API для хранения мультимедийных и статических файлов для веб-сайта WordPress в OVHcloud Object Storage.

Мы будем использовать плагин WordPress под названием Media Cloud, который хранит мультимедиа (изображения, видео) в облачных сервисах. После его установки нам потребуются учетные данные S3 для настройки плагина, сгенерированные с помощью OpenStack CLI.

$ openstack ec2 credentials create
+------------+-----------------------------------------------------------+
| Field:     | Value                                                     |       
+------------+-----------------------------------------------------------+
| access     | 5a4d8b8d88104123a862c527ede5a3d3                          |
| links      | {u'self': u'https://auth.cloud.ovh.net/...                |
| project_id | 20e124b71be141299e111ec26b1892fa                          |
| secret     | 925d5fcfcd9f436d8ffcb20548cc53a2                          |
| trust_id   | None                                                      |
| user_id    | d74d05ff121b44bea9216495e7f0df61                          |
+------------+-----------------------------------------------------------+

Теперь мы можем настроить плагин, выбрав в мастере запись «Совместимость с S3» и предоставив учетные данные при появлении запроса. Обязательно укажите правильную конечную точку, например storage.gra.cloud.ovh.net для региона Graveline во Франции или storage.us-east-va.cloud.ovh.us для региона Vint Hill. в США.



Наконец, просто загрузите изображения в раздел «Медиа» и дважды проверьте, что они размещены в OVHcloud Object Storage.



Из всех доступных вариантов объектное хранилище — это простое, чрезвычайно надежное, высокодоступное и бесконечно масштабируемое решение для хранения данных. Кроме того, OVHcloud установил стандарт, обеспечив совместимость своего предложения Object Storage с де-факто сервисом Amazon S3.