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

Объявляя полное обновление диапазонов продукции выделенного сервера OVHcloud США

OVHcloud объявляет полное обновление своих выделенных диапазонов серверных продуктов в своих центрах обработки данных США по приведению в соответствие описи с мировым каталог OVHcloud.

Обновления обновляет инфраструктуру и игры диапазоны и вводит заранее и Райз диапазоны. Серверы HG и Best Value продолжают быть частью каталога США. Для решения меняющихся потребностей бизнеса, новые диапазоны серверные расширенные функции, такие как:

• Процессоры AMD
• Улучшенная скорость сети
• Горящие цены на краткосрочные обязательства 12- и 24- месяц

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

Проверьте наши новые выделенные диапазоны сервера здесь. Пожалуйста, ответьте на это письмо, если у вас есть какие — либо вопросы.
us.ovhcloud.com/dedicated-servers/prices/

Спасибо,
Паскаль Жайон
SVP продукт и цифровой Accounts
OVHcloud

2 из 6 стоек, заказанных при доставке в GRA
следующие 4 прибывают на следующей неделе

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 Гбит/с между их сетью и нашей сетью.