Дата-центры OVH

20Tbps OVH

• 1 server with 1 CPU with 3x Nvidia GPU and the waterclick
• 850W per server
• 48 servers per rack
• 40KW per rack

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

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


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

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

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

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

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

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

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

Чтобы узнать больше о FPGA, электронные книги FPGA For Dummies — это хороший ресурс.

Традиционный рабочий процесс разработки 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, нашей системой непрерывной доставки с открытым исходным кодом. Все тесты, а также задания по компиляции выполняются в Public Cloud, кроме тестов на борту, которые проводятся в нашей лаборатории.

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

• симулятор
• компилятор Xilinx, Vivado
• компилятор Intel Quartus

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

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

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

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

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

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

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

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


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


Эти большие файлы, которые мы называем «томами», имеют три важных характеристики:

• Они посвящены разделу Swift
• Они только добавляются: никогда не перезаписывают данные
• Нет одновременных записей: у нас может быть несколько томов на раздел

Нам нужно отслеживать расположение этих фрагментов в объеме. Для этого мы разработали новый компонент: индекс-сервер. Это сохранит каждое местоположение фрагмента: том, в котором он хранится, и его смещение внутри тома.


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

Использование на LevelDB
Мы выбрали LevelDB для хранения местоположения фрагмента на индексном сервере:

• Он сортирует данные на диске, что означает, что он эффективен на обычных вращающихся дисках
• Это экономит место благодаря библиотеке сжатия Snappy

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

При записи объекта обычная быстрая серверная часть создаст файл для хранения данных. С LOSF вместо этого:

• Получить блокировку файловой системы на томе
• Добавьте данные объекта в конец тома и вызовите fdatasync ()
• Зарегистрировать местоположение объекта на индексном сервере (номер тома и смещение внутри тома)

Чтобы прочитать обратно объект:

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

Однако нам еще предстоит решить пару проблем!

Удаление объектов
Когда клиент удаляет объект, как мы можем на самом деле удалить данные из томов? Помните, что мы добавляем данные только в том, поэтому мы не можем просто пометить пространство как неиспользуемое в томе и попытаться использовать его позже. Мы используем XFS, и она предлагает интересное решение: возможность «пробить дыру» в файле.

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


Структура каталогов
Индекс-сервер будет хранить имена объектов в плоском пространстве имен, но Swift использует иерархию каталогов.

/mnt/objects/<partition>/<suffix>/<checksum>/<timestamp>.data

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

Если вы ранее не использовали Swift, «индекс раздела» объекта указывает, какое устройство в кластере должно хранить объект. Индекс раздела вычисляется путем взятия нескольких битов из пути объекта MD5. Вы можете узнать больше здесь.

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



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

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

Результаты
После завершения миграции активность диска в кластере была намного ниже: мы заметили, что данные сервера индексирования будут помещаться в память, поэтому перечисление объектов в кластере или получение местоположения объекта не потребует ввода-вывода физического диска. Задержка улучшилась как для операций PUT, так и для операций GET, и задачи «реконструкции» кластера могли выполняться намного быстрее. (Реконструктор — это процесс, который восстанавливает данные после сбоя диска в кластере)

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

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

careers.ovh.com/fr

Теперь у нас есть пропускная способность 200 Гбит/с между их сетью и нашей сетью.

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


HCibench (https://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

«Прикладные» рабочие нагрузки
Под «прикладными» рабочими нагрузками мы понимаем рабочие нагрузки, которые соответствуют распространенным производственным сценариям использования, таким как «DATABASE WORKLOAD», «VDI WORKLOAD», «BACKUP WORKLOAD» и т. Д. С помощью этих тестов мы можем эмулировать типичную рабочую нагрузку и проверять области, где данный тип хранилища первенствует.


Пример файла параметров рабочей нагрузки 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 (http://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>'
...

Bench “root job”

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

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

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




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

• Разбор вариантов работы
• SSH подключиться к HCIbench VM
• Заполните шаблон конфигурации с соответствующими параметрами работы
• Запустить HCIbench

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


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


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


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


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

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


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

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

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

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

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


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

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

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

API S3
Интерфейс прикладного программирования Amazon S3 (S3 API) — это наиболее распространенный способ хранения, управления и извлечения данных хранилищами объектов. S3 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



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


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