В прошлом году мы выпустили 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.

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

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

Короткий рассказ

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

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

Инструменты и оркестровка

FIO, vdbench, I / O Meter, (dd!) — это лишь некоторые из широко используемых и проверенных инструментов для тестирования хранилища. Они дают вам обзор чистой производительности для данного типа хранилища. Но что, если вы хотите протестировать всю инфраструктуру от начала до конца? Это может включать 1, 10, 100, 1000 виртуальных машин или более, с несколькими настройками диска / рейда, несколькими размерами дисков, несколькими размерами блоков. И все это с различными типичными рабочими нагрузками, состоящими из определенного процента операций чтения / записи, последовательных или случайных, и выполняемых таким количеством потоков. Вам также нужно будет использовать рабочие нагрузки, соответствующие вашим производственным рабочим нагрузкам. На самом деле комбинации бесконечны.

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

Тест гиперконвергентной инфраструктуры

HCibench ( flings.vmware.com/hcibench ) — это бесплатный инструмент автоматизации тестов с открытым исходным кодом. Он определяет себя как «Тест гиперконвергентной инфраструктуры». По сути, это оболочка для автоматизации популярных и проверенных инструментов тестирования производительности с открытым исходным кодом: Vdbench и Fio, упрощающая автоматизацию тестирования в кластере HCI. HCIBench стремится упростить и ускорить тестирование производительности клиентских POC последовательным и контролируемым образом. Этот инструмент полностью автоматизирует сквозной процесс развертывания тестовых виртуальных машин, координации выполнения рабочих нагрузок, агрегирования результатов тестирования, анализа производительности и сбора необходимых данных для устранения неполадок.



HCIbench так же просто установить, как развернуть OVA (Open Virtual Appliance) в вашей инфраструктуре VMware:



После настройки HCIbench просто укажите в браузере адрес https: // IP: 8483, и вы готовы приступить к тестированию:





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

• Количество виртуальных машин для развертывания
• Количество дисков для каждой ВМ
• Размер диска
• Инструмент тестирования (FIO или vdbench)
• Файл параметров ввода-вывода (подробности см. Ниже)
• Продолжительность
• И более …

Затем HCIbench возьмет на себя все операции по развертыванию / утилизации виртуальных машин и выполнит ваш тест. Результаты доступны в различных формах, от интерфейсов Grafana до файлов Excel или просто текстовых файлов для дальнейшего внешнего анализа…

Файлы параметров рабочей нагрузки, моделирование операций ввода-вывода

Файлы параметров рабочей нагрузки (здесь используются vdbench) лежат в основе всех операций тестирования. Они описывают модель ввода-вывода, которую вы хотите использовать для данной конечной точки хранилища. Доступны проценты чтения / записи, случайные / последовательные, размер блока, потоки и многие другие параметры.

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

«Общие» рабочие нагрузки

Под «общими» рабочими нагрузками мы понимаем все рабочие нагрузки, которые выглядят как «ТОЛЬКО СЛУЧАЙНОЕ ЧТЕНИЕ» или «ТОЛЬКО ПОСЛЕДОВАТЕЛЬНЫЕ ЗАПИСИ». Они позволяют нам проверить, как тип хранилища реагирует на линейные случаи и как он работает с «крайними» случаями.



Пример «универсального» файла параметров рабочей нагрузки vdbench

root@photon-HCIBench [ /opt/automation/vdbench-param-files ]# cat 
GENERIC-ONLY-READS-RANDOM-16K-vdb-1vmdk-80ws-16k-100rdpct-100randompct-4threads
*SD:    Storage Definition
*WD:    Workload Definition
*RD:    Run Definitionsd=sd1,
        lun=/dev/sda,openflags=o_direct,
        hitarea=0,range=(0,80),
        threads=4,
        wd=wd1,
        sd=sd1,
        rd=run1,
        xfersize=16k,
        rdpct=100,
        seekpct=100,
        iorate=max,
        elapsed=120,
        interval=1

«Приложения»

Под «прикладными» рабочими нагрузками мы понимаем рабочие нагрузки, которые соответствуют типичным производственным сценариям использования, таким как «РАБОЧАЯ ЗАГРУЗКА БАЗЫ ДАННЫХ», «РАБОЧАЯ ЗАГРУЗКА VDI», «РЕЗЕРВНАЯ РАБОЧАЯ ЗАГРУЗКА» и т. Д. отлично.



Пример файла параметров рабочей нагрузки vdbench «Приложение»

root@photon-HCIBench [ /opt/automation/vdbench-param-files ]# cat 
OLTP-SQL-Oracle-Exchange-vdb-1vmdk-80ws-16k-100random-70rdpct-4threads
*SD:    Storage Definition
*WD:    Workload Definition
*RD:    Run Definitionsd=sd1,
        lun=/dev/sda,
        openflags=o_direct,
        hitarea=0,range=(0,80),
        threads=4wd=wd1,
        sd=(sd1),
        xfersize=16k,
        rdpct=70,
        seekpct=100,
        rd=run1,
        wd=wd1,
        iorate=max,
        elapsed=120,
        interval=1

«Производственные» нагрузки.

Наконец, еще один подход, над которым мы работаем, — это возможность «записывать» производственную рабочую нагрузку и «воспроизводить» ее на другой конечной точке хранилища, чтобы оценить, как целевое хранилище работает с вашей производственной рабочей нагрузкой,  без  необходимости запускать на нем реальное производство. Хитрость здесь в том, чтобы использовать сочетание 3 инструментов: blktrace, btrecord и btreplay, чтобы отслеживать и отслеживать вызовы ввода-вывода низкого уровня и иметь возможность воспроизвести эти следы на другой платформе хранения. 

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

Индустриализация HCIbench работает с планировщиком Rundeck

Как мы видели, за несколько щелчков мышью мы можем определить и запустить тестовый сценарий для конкретной рабочей нагрузки. Развертывание и повторное использование тестовых виртуальных машин полностью автоматизировано. Что, если в следующий раз мы захотим повторить несколько сценариев? Например, в рамках общей проверки новой платформы хранения? На этом этапе мы начали использовать Rundeck ( www.rundeck.com), бесплатный планировщик автоматизации Runbook с открытым исходным кодом, перед HCIbench. Идея состоит в том, чтобы иметь возможность создавать полные коллекции сценариев тестов.



Первым шагом было понять, как HCIbench работает под капотом, чтобы мы могли управлять им через планировщик Rundeck. HCIbench разработан для использования через веб-интерфейс, но все его механизмы выполняются с помощью чистых и отдельных скриптов, таких как start / stop / kill. Все настройки тестов хранятся в чистом плоском файле конфигурации, который легко преобразовать в шаблон…

Создание шаблона файла конфигурации HCIbench

root@photon-HCIBench [ /opt/automation/conf ]# cat template.yaml
vc: '<VCENTER_HOSTIP>'
vc_username: '<USERNAME>'
vc_password: '<PASSWORD>'
datacenter_name: '<DATACENTER>'
cluster_name: '<CLUSTER>'
number_vm: '<NUMBERVM>'
testing_duration: '<DURATION>'
datastore_name:- '<DATASTORE>'
output_path: '<OUTPUT_PATH>'
...

Скамья «корневая работа»

Задание rundeck состоит из последовательности шагов, которые будут выполняться для определенного списка узлов. В нашем контексте узлы — это виртуальные машины, на которых работает HCIbench.

То, что мы называем стендовым «корневым заданием», — это задание rundeck, которое является основной точкой входа в стенд. Его общая роль заключается в том, чтобы вызывать другие рабочие места и запускать один конкретный стенд.

Опции (параметры) этого задания — это все элементы из шаблона конфигурации HCIbench (см. Выше).





Рабочий процесс для этого задания следующий:
— Параметры задания синтаксического анализа
— Подключение SSH к виртуальной машине HCIbench
- Заполнение шаблона конфигурации соответствующими параметрами задания
— Запуск HCIbench 

Скамейка

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

«Супер» вакансии

Наконец-то у нас есть «Супер вакансии». Это коллекции заданий, их рабочие процессы — это серии вызовов стендовых заданий. Мы используем механизм каскадных опций для передачи опций через задания. В приведенном ниже примере мы тестируем кластер vSAN через полную панель моделей ввода-вывода.



Еще одна интересная особенность использования Rundeck в качестве планировщика HCIbench — это возможность хранить все журналы с виртуальных машин HCIbench и время каждого теста в одном месте. Таким образом, можно легко просматривать и искать по всем нашим тестам или ориентироваться на конкретное поведение, показанное на графике.

Результаты и варианты использования

vSAN
Интеграция vSAN в наш продукт Hosted Private Cloud была типичным эталонным проектом, в котором нам нужно было не только проверить, как вся платформа работает в каждой области, но и уточнить дизайн самой платформы. С одной стороны, мы оценили дизайн оборудования с несколькими ссылками на диски, а с другой стороны, мы улучшили дизайн программного обеспечения, оценив различные группы дисков vSAN и конфигурации кеша.

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

Еще один интересный случай использования — это оценка влияния нового ядра на массивы хранения на базе OmniOS ( www.omniosce.org). OmniOS — это бесплатная операционная система с открытым исходным кодом, основанная на OpenSolaris, которая объединяет некоторые замечательные технологии, такие как ZFS, DTrace, Crossbow, SMF, Bhyve, KVM и поддержку зон Linux. Этот случай показывает не только немного лучшие характеристики, но и значительное улучшение обработки операций ввода-вывода.

Действительно, среди множества различных тестов новое ядро ​​(r151022) показывает гораздо более стабильные и линейные операции ввода-вывода. Этот стенд также подтверждает несколько исправлений ZFS / NFS, которые были включены в это ядро, которые устраняют проблемы с задержкой во время отправки / получения снимка ZFS.



Индустриализация наших тестов позволила нам отслеживать производительность нашего хранилища. Прежде всего, поскольку мы создавали их для наших пользователей, мы согласны с тем, что получат наши клиенты. Кроме того, тесты дают нам представление об устранении проблем с хранением, которые очень специфичны и / или видны только с виртуальных машин. Мы планируем расширить это, чтобы мы могли проверить, как работает вычислительная сторона (CPU / RAM /…). Наконец, теперь мы сосредоточены на функции записи / воспроизведения рабочей нагрузки, позволяющей нашим пользователям прогнозировать, как их производственная рабочая нагрузка будет работать на платформах «XYZ», без необходимости фактически запускать на ней свою производственную среду. Мы подробно расскажем об этом в следующих статьях блога, следите за обновлениями!

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

2015 г.

В 2015 году приблизился, наша ключевой целью заключалась в разработке водных блоков с производительностью оптимального по 120W и температурой воды 30 ° С .



Чтобы упростить процесс и снизить затраты, мы заменили металлическую крышку на АБС-пластик.



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



Как и в предыдущих итерациях, мы также производили водоблоки меньшего форм-фактора. Например, вот вам водоблок GPU:

3D-печать водяных блоков

Использование пластиковых крышек для водоблоков также открыло двери для нового процесса прототипирования, включая 3D-печать. Мы начали экспериментировать с 3D-печатными водоблоками из АБС-пластика, тестируя различные типы крышек.

Варианты обложек, напечатанных на 3D-принтере:

CFD моделирование

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

Резервирование

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

2017 г.

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



К 2017 году мы были в состоянии использовать водные блоки с оптимальной производительностью от 200Вт и температурой воды 30 ° C , и все было полностью разработано и изготовлено внутри на OVHcloud .

После крышек из АБС-пластика пришло время протестировать другие пластики, включая полиамиды.

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





Водоблок для процессоров высокой плотности с черной крышкой из полиамидного пластика:



Эксперименты с полиамидным пластиком также позволили нам быстро спроектировать и протестировать различные прототипы для улучшения поддержки ЦП и снижения стоимости.

2018-2019

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

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



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



На этих водоблоках трубопроводы полностью выполнены из медных сварных труб.



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

2020-…

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



Мы работаем над водоблоками следующего поколения tier-4, используя нашу запатентованную технологию. Наши водоблоки 4-го уровня больше не являются прототипами, они готовы к производству, и мы активно работаем над моделированием и тестами для повышения производительности.



Мы стремимся к водоблокам мощностью 400 Вт с температурой воды 30 ° C и полностью резервным водоснабжением.

А кроме водоблоков?

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



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

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



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

libvirt

, которое имеет PCI транзитного особенность , которая оказалась именно то , что нам нужно для этой цели.

Архитектура NVMe для наших экземпляров Public Cloud

Чтобы обеспечить максимальную производительность хранилища, мы работали с рядом наших клиентов над PoC, в котором использовалась та же функция PCI Passthrough, чтобы включить самое быстрое устройство хранения в наши экземпляры Public Cloud: карты NVMe с 1,8 ТБ пространства .

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



Очистите устройство перед его перераспределением

Вы говорите быстро, но как быстро?

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

Сначала создайте экземпляр i1-180, используя OpenStack CLI.

$ openstack server create --flavor i1-180 --image "Ubuntu 19.04" \
  --net Ext-Net --key-name mykey db01

Проверьте устройства NVMe на экземпляре.

$ lsblk | grep nvme
nvme2n1 259:0    0  1.8T  0 disk
nvme1n1 259:1    0  1.8T  0 disk
nvme0n1 259:2    0  1.8T  0 disk
nvme3n1 259:3    0  1.8T  0 disk

У нас есть четыре устройства NVMe, поэтому давайте создадим с ними RAID 0.

$ mdadm --create /dev/md1 --level 0 --raid-devices 4 \
  /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started

Теперь отформатируем рейд-устройство.

$ mkfs.xfs /dev/md1
meta-data=/dev/md1               isize=512    agcount=32, agsize=58601344 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0, rmapbt=0, reflink=0
data     =                       bsize=4096   blocks=1875243008, imaxpct=5
         =                       sunit=128    swidth=512 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=8 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

После монтирования файловой системы на / mnt мы готовы запустить тест.

Прочитать тест

Мы начнем с теста чтения, используя блоки размером 4 КБ, и поскольку у нас 32 виртуальных ядра в этой модели, мы будем использовать 32 задания. Пошли!

$ fio --bs=4k --direct=1 --rw=randread --randrepeat=0 \
  --ioengine=libaio --iodepth=32 --runtime=120 --group_reporting \
  --time_based --filesize=64m --numjobs=32 --name=/mnt/test
/mnt/test: (g=0): rw=randread, bs=® 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
[...]
fio-3.12
Starting 32 processes
Jobs: 32 (f=32): [r(32)][100.0%][r=9238MiB/s][r=2365k IOPS][eta 00m:00s]
/mnt/test: (groupid=0, jobs=32): err= 0: pid=3207: Fri Nov 29 16:00:13 2019
  read: IOPS=2374k, BW=9275MiB/s (9725MB/s)(1087GiB/120002msec)
    slat (usec): min=2, max=16031, avg= 7.39, stdev= 4.90
    clat (usec): min=27, max=16923, avg=419.32, stdev=123.28
     lat (usec): min=31, max=16929, avg=427.64, stdev=124.04
    clat percentiles (usec):
     |  1.00th=[  184],  5.00th=[  233], 10.00th=[  269], 20.00th=[  326],
     | 30.00th=[  363], 40.00th=[  388], 50.00th=[  412], 60.00th=[  437],
     | 70.00th=[  465], 80.00th=[  506], 90.00th=[  570], 95.00th=[  635],
     | 99.00th=[  775], 99.50th=[  832], 99.90th=[  971], 99.95th=[ 1037],
     | 99.99th=[ 1205]
   bw (  KiB/s): min=144568, max=397648, per=3.12%, avg=296776.28, stdev=46580.32, samples=7660
   iops        : min=36142, max=99412, avg=74194.06, stdev=11645.08, samples=7660
  lat (usec)   : 50=0.01%, 100=0.02%, 250=7.41%, 500=71.69%, 750=19.59%
  lat (usec)   : 1000=1.22%
  lat (msec)   : 2=0.07%, 4=0.01%, 10=0.01%, 20=0.01%
  cpu          : usr=37.12%, sys=62.66%, ctx=207950, majf=0, minf=1300
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=284924843,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32
 
Run status group 0 (all jobs):
   READ: bw=9275MiB/s (9725MB/s), 9275MiB/s-9275MiB/s (9725MB/s-9725MB/s), io=1087GiB (1167GB), run=120002-120002msec
 
Disk stats (read/write):
    md1: ios=284595182/7, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=71231210/1, aggrmerge=0/0, aggrticks=14348879/0, aggrin_queue=120, aggrutil=99.95%
  nvme0n1: ios=71231303/2, merge=0/0, ticks=14260383/0, in_queue=144, util=99.95%
  nvme3n1: ios=71231349/0, merge=0/0, ticks=14361428/0, in_queue=76, util=99.89%
  nvme2n1: ios=71231095/0, merge=0/0, ticks=14504766/0, in_queue=152, util=99.95%
  nvme1n1: ios=71231096/4, merge=0/1, ticks=14268942/0, in_queue=108, util=99.93%

2370 тыс. Операций ввода-вывода в секунду. Потрясающие цифры, не правда ли?

Написать тест

Готовы к тесту записи?

$ fio --bs=4k --direct=1 --rw=randwrite --randrepeat=0 --ioengine=libaio --iodepth=32 --runtime=120 --group_reporting --time_based --filesize=64m --numjobs=32 --name=/mnt/test
/mnt/test: (g=0): rw=randwrite, bs=® 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
[...]
fio-3.12
Starting 32 processes
Jobs: 32 (f=32): [w(32)][100.0%][w=6702MiB/s][w=1716k IOPS][eta 00m:00s]
/mnt/test: (groupid=0, jobs=32): err= 0: pid=3135: Fri Nov 29 15:55:10 2019
  write: IOPS=1710k, BW=6680MiB/s (7004MB/s)(783GiB/120003msec); 0 zone resets
    slat (usec): min=2, max=14920, avg= 6.88, stdev= 6.20
    clat (nsec): min=1152, max=18920k, avg=587644.99, stdev=735945.00
     lat (usec): min=14, max=18955, avg=595.46, stdev=736.00
    clat percentiles (usec):
     |  1.00th=[   21],  5.00th=[   33], 10.00th=[   46], 20.00th=[   74],
     | 30.00th=[  113], 40.00th=[  172], 50.00th=[  255], 60.00th=[  375],
     | 70.00th=[  644], 80.00th=[ 1139], 90.00th=[ 1663], 95.00th=[ 1991],
     | 99.00th=[ 3490], 99.50th=[ 3949], 99.90th=[ 4686], 99.95th=[ 5276],
     | 99.99th=[ 6521]
   bw (  KiB/s): min=97248, max=252248, per=3.12%, avg=213714.71, stdev=32395.61, samples=7680
   iops        : min=24312, max=63062, avg=53428.65, stdev=8098.90, samples=7680
  lat (usec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.86%, 50=11.08%
  lat (usec)   : 100=15.35%, 250=22.16%, 500=16.34%, 750=6.69%, 1000=5.03%
  lat (msec)   : 2=17.66%, 4=4.38%, 10=0.44%, 20=0.01%
  cpu          : usr=20.40%, sys=41.05%, ctx=113183267, majf=0, minf=463
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,205207842,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32
 
Run status group 0 (all jobs):
  WRITE: bw=6680MiB/s (7004MB/s), 6680MiB/s-6680MiB/s (7004MB/s-7004MB/s), io=783GiB (841GB), run=120003-120003msec
 
Disk stats (read/write):
    md1: ios=0/204947351, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/51301962, aggrmerge=0/0, aggrticks=0/27227774, aggrin_queue=822252, aggrutil=100.00%
  nvme0n1: ios=0/51302106, merge=0/0, ticks=0/29636384, in_queue=865064, util=100.00%
  nvme3n1: ios=0/51301711, merge=0/0, ticks=0/25214532, in_queue=932708, util=100.00%
  nvme2n1: ios=0/51301636, merge=0/0, ticks=0/34347884, in_queue=1089896, util=100.00%
  nvme1n1: ios=0/51302396, merge=0/0, ticks=0/19712296, in_queue=401340, util=100.00%

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

Конечно, для этого примера мы представляем оптимальный сценарий. RAID 0 по своей природе опасен, поэтому любой сбой на одном из устройств NVMe может повредить ваши данные. Это означает, что вы обязательно должны создавать резервные копии критически важных данных, но это само по себе открывает множество новых возможностей. Так что мы на 100% уверены, что ваши базы данных полюбят эти экземпляры! Вы можете найти более подробную информацию о них на нашем  веб-сайте Public Cloud .

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

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



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

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

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

2003-2008 гг.

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



Наши первые поколения технологии водоблоков были разработаны нашими командами и изготовлены на стороне. Эти водоблоки имели оптимальную производительность 60 Вт при температуре воды 30 ° C.

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



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

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

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



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

2011 г.

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



В течение этого периода мы по-прежнему разрабатывали наши водоблоки внутри и производили их внешне. Оптимальная мощность для этого поколения водоблоков — 60 Вт при температуре воды 30 ° C.

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

2013-2014 гг.

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



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

Прочие факторы

На этом этапе мы начали делать вариации водоблока, например адаптировать их к меньшим форм-факторам GPU:



Здесь вы можете сравнить стандартный водоблок процессора и более компактный водоблок графического процессора:



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



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



Крышка и опорные пластины водяного блока, используемые в процессорах IBM Power8 высокой плотности

2015 и далее

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

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

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