Самарский портал "Технологии, компьютеры"

Галопом по вычислительным Европам. Часть 6. Спецпроцессоры.

Собственно, посмотрите на наиболее показательный пример из истории: двухканальный ultrawide SCSI RAID контроллер для серверов эпохи i486 и Pentium. Что у нас тут? Да DPU в самом полном виде.

Контроллер, с помощью довольно сложного ПО, исполняемого на «нормальном процессоре»[1], преобразует всю реальную адресацию нескольких накопителей в представление единого «большого диска», реализует все варианты RAID, детектирование сбойных накопителей, режим горячей замены и восстановления отказоустойчивости массива после замены сбойного накопителя. Для ускорения работы контроллер может оснащаться большим кэшем из стандартного модуля памяти, который в режиме отложенной записи сильно повышает производительность записи, ну а чтение из кэша оно чтение и есть — умный контроллер реализует упреждающее чтение секторов, так что когда CPU запрашивает следующую порцию данных, то она уже в оперативной памяти контроллера и моментально (со скоростью шины PCI 32) передается на обработку.

Зачем нужна батарейка? Для безопасности[2] при включении режима отложенной записи. Представьте себе, что у вас сгорел блок питания в сервере или сломалась материнская плата, а в кэше контроллера еще не записанные мегабайты (а в более новых контроллерах и сотни мегабайт) еще не записанных на диски данных? В этом случае батарейка позволяет сохранить данные в DRAM (вы помните, что там надо постоянно подпитывать ячейки?). У вас есть от двух-трех дней до пары недель, чтобы починить сервер, и тогда после включения контроллер сам завершит прерванные операции.

С одной стороны, учитывая пропускную способность шины PCI 32 в 132 MB/s и два[3] канала UW SCSI по 40 MB/s (итого 80) необходимость кэша кажется неочевидной, но кроме пропускной способности у нас ведь есть еще и латентность. А она у дисковых накопителей тех времен была очень даже большой, оперативная память тут вне конкуренции. Ну и при записи надо куда-то сбросить данные, чтобы их потом уже без участия CPU поделили на N-1 элементов, вычислили контрольный блок и аккуратно перемешали по накопителям. Так что без модуля памяти — никуда. В общем, DPU как он есть, только древний.

Трехканальный UWSCSI контроллер на процессоре i960 с двумя модулями памяти.

Что интересно: чуть позже поддержка RAID появилась в операционных системах (с расчетами на CPU), благо производительность процессоров начиная с середины 90^-х начала расти очень быстро, а потом в гонку включились и многоядерные процессоры. Да, такие «программные RAID» вполне себе работают[4] — вот только надо понимать, что при более-менее серьезной нагрузке на дисковый ввод/вывод эта задача отнимает значительную часть ресурсов CPU, так что пользоваться этим имеет смысл только в малонагруженных серверах, которым все равно нужно иметь отказоустойчивый дисковый массив. И — да, это хороший способ сэкономить несколько сот (а иногда и пару тысяч) долларов. Для нагруженных же серверов альтернативы интеллектуальным контроллерам массивов, берущим на себя всю работу с дисками альтернативы, как вы понимаете, как не было, так и нет.

Стандартность решаемых накопителями задач (выборка данных «по заданию от CPU», расчет RAID и оперирование накопителями, сжатие и шифрование данных) не могла не напрашиваться на перенос этой нагрузки из серверов и их RAID-контроллеров тоже в сами накопители. И это, конечно, было сделано[5].

Сначала на уровень NAS/SAS, коль скоро там уже есть какие-никакие (и все более мощные) процессоры. С т.з. архитектуры это исходно представляло собой простой (без процессора) SCSI контроллер в сервере, который SCSI кабелем подключался к отдельному корпусу, в котором тоже был SCSI контроллер, но уже с полноценной процессорной частью, реализующий все необходимые функции для работы массива. С т.з. же серверного контроллера массив выглядел как один сверхскоростной диск огромной емкости. Затем, по мере развития сетевых технологий толстый и короткий кабель SCSI заменился на Fibre Channel (сначала на меди, потом на оптике, а потом снова на меди), а потом и на Ethernet[6]. Скорости связи с массивами накопителей, объединенными в целые сети хранения, достигли сотен гигабайт в секунду.

С другой от RAID-контроллеров стороны системы всё большую часть работы брали на себя сетевые адаптеры. Дешевые сетевые адаптеры (те, что по $10 за карточку) несли на борту простейшие микросхемы, реализующие только первые два уровня модели OSI, а все остальное исполнялось на CPU программой-драйвером. Это, конечно удобно, и для рабочего места, активность сети на котором ограничивается работой с документами на сетевом диске и иногда запросами СУБД вполне нормально, но на стороне сервера все гораздо хуже. Когда на сервер через несколько сетевых интерфейсов наваливаются десятки и сотни клиентов, его центральный процессор становится узким местом, погребенным под потоком запросов. Хуже того: время обработки приходящих по сети пакетов ограничено, и если клиент не получит подтверждения (в рамках протокола TCP, например), то он повторит отправку пакета, создавая эффект лавины, погребающий под собой и сами сети и серверы. Поэтому что? Поэтому, уже лет 30 назад стали появляться сетевые платы, которые позиционировались в качестве серверных. Они получали все более и более производительные системы обработки данных (сначала ASIC, а потом и полноценные процессоры, берущие на себя все обработки все более и более высоких уровней модели OSI. Сами адаптеры постепенно брали на себя поддержку VLAN, шифрования данных, фильтрацию пакетов — и так далее, и тому подобное. На практике оснащение сервера интеллектуальным контроллером RAID и серверным сетевым адаптером ускоряло нагруженные серверы на десятки процентов и даже в разы.

Серверный сетевой адаптер 10/100Base-T с процессором i960

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

В настоящее время на сетевых адаптерах устанавливаются процессоры гораздо более мощные, чем старинные i960. Они берут на себя все большую и большую часть работы, самостоятельно поддерживая шифрование[7] и сжатие трафика, VLAN и такие вещи, как виртуализацию NVMe накопителей (это отдельная красивая штука) и много что ещё.

Когда уже будет про настоящие DPU? Прямо сейчас и будет: Фактически, современные DPU являются продуктом постепенной конвергенции интеллектуальных контроллеров дисковых массивов и «серверных» сетевых адаптеров. Процесс дезагрегации вычислений постепенно привел к ситуации, когда между его величеством CPU и данными расположился один сетевой контроллер, соединенный с хранилищами с одной стороны, и с клиентскими компьютерами — с другой. На противоположном конце провода примерно такая же ситуация, только контроллер находится между накопителями и сетью Ethernet. На какой из DPU (где именно расположенный) и какие именно возложить задачи по пред- и постобработке информации — вопрос уже чисто архитектурно-технологический.

Давайте заглянем в какой-нибудь современный серверный DPU, обеспечивающий связь сервера с клиентскими компьютерами и системами хранения (и наоборот, систем хранения с серверами), например в Kalray MPPA Coolidge (выбор не совсем случайный, конечно). Итак, что мы видим?

Архитектура DPU Kalray MPPA Coolidge

Первое, что обращает на себя внимание: 16(!) ядер для прикладных задач. Кроме того, обратите внимание — тут применена та самая архитектура VLIW, которую я критиковал выше (поэтому и выбрал этот ускоритель для иллюстрации, собственно). Но именно в данном применении VLIW есть нюанс: эти задачи — низкоуровневая обработка данных — как раз относятся к категории идеально распараллеливаемых как по данным, так и по алгоритмам (тот редкий случай, когда в кремнии реализуется полноценная MIMD обработка[8]), так что упрощение архитектуры ядер за счет статической оптимизации кода в данном случае вполне оправдано. Но обратите внимание: ширина VLIW слова — шесть команд. Не 25, как в не к ночи будь помянутом, «Эльбрусе», а вполне рациональные шесть[9], которые можно реально заполнить в каждом слове, получив хорошую суммарную производительность[10] при сравнительно невысоких частотах. В транзисторах это получается настолько дешево, что в рамках одного DPU Kalray MPPA Coolidge может быть упаковано до пяти многоядерных сборок, т. е., 80(!) ядер с частотой от 600 до 1200 MHz для обработки данных (+5 сервисных ядер, решающих внутренние задачи) Что тут еще есть? Два канала DDR4-3200, для всех ядер и задач. А обмен с внешним миром осуществляется через два канала Ethernet до 100 Gbit/s каждый (200 Gbit /s или 25 GB/s суммарно), а «внутрь» системы обращена 16-канальная шина PCIe 4 (32 GB/s). Все это обеспечивает производительность до 12000000[11] (12 миллионов) IOPS.

В общем, то же самое, что у мамонта древнего контроллера на TI486, только примерно в 10-15 тысяч раз быстрее, и для связи с хранилищами используются два канала по 100 GBE (2 TB/s) вместо 2xUWSCSI.

Продолжение следует…

[1]Собственно, использование обычного 486^-го процессора на RAID контроллере дело довольно нетипичное. Обычно использовались более простые и эффективные в данном случае RISC-процессоры и специализированные ASIC. Этот контроллер (я даже не знаю, кто его производитель) я взял для примера, потому, что на нем процессор уж очень хорошо виден и узнаваем. И — да, это не i486, а TI486. Он был ощутимо медленнее, особенно, в FP – но зато, даже на частоте 66 MHz, мог работать без кулера и даже без радиатора.

[2]Большинство кэш-контроллеров даже не разрешают включать отложенную запись без установки батарейного модуля.

[3]Контроллеров шины SCSI тут всего два, так что внешний разъем мог использоваться (скажем, для подключения ленточной библиотеки или дисковой полки) только вместо одного из внутренних каналов. «Сквозное» подключение (возможное теоретически) на практике не применялось из-за проблем с сигналом.

[4]Если мы заглянем в современные NAS, то увидим там снова тот же самый «программный RAID», реализуемый на единственном в изделии CPU, который занимается и обслуживанием RAID, и сетевыми интерфейсами, и контролем доступа и еще крутит несколько сервисов. При этом RAID-массив снаружи воспринимается уже практически как специализированный аппаратный. Граница между программными и аппаратными реализациями постепенно размывается, ничего не поделать.

[5]Кроме просто хранения данных и передачи их в компьютеры NAS уже давным-давно научились поддерживать такие операции с данными, как шифрование и сжатие, а затем начали уже позволять запускать на своих мощностях и более сложные сервисы, такие как MySQL, торрент-клиенты, web-серверы и всякое разное. Не редкость уже и реализация в таких NAS иерархических систем хранения из SSD и HDD с автоматическим управлением размещением данных.

[6]Собственно, протокол iSCSI и есть передача команд протокола SCSI по IP сетям. Удаленный NAS с т.з. системы виден и управляется как локальный накопитель. Ну а дальше все зависит от скоростей сети.

[7]Кто сказал: «так это же криптоускоритель из сноски №12!»? Молодцы, правильно. История идет по спирали!

[8]Собственно, иллюстрация к понятию MIMD из Википедии прямо изображает VLIW-процессор. Они совпадают идеально.

[9]Все успешные реализации VLIW имеют от 4 до 8 команд в слове. Меньше нет смысла, а больше — невозможно надежно обеспечить заполнение слова. Появляются «пробелы», простаивающие исполнительные устройства — и «на транзистор» у такой реализации КПД падает. Впрочем, я об этом писал выше, и не один раз. Больная тема.

[10]1,15 TFlops на операциях FP32 и 25 TOps для INT8. Вполне годно не только для дисковых массивов, но и для систем технического зрения и машинного обучения ИИ. Собственно, из таких DPU можно собирать даже и чисто счетные массивы.

[11]Для сравнения: i7-3216QM на SATA III SSD при всех возможных кэшированиях в памяти и в режиме «выделенного DPU» (чистый тест без других нагрузок в системе) дает ~97 тыс. IOPS на чтение и ~68 тыс. IOPS на запись.

Ссылки на все 10 статей цикла «Галопом по вычислительным Европам»:

Галопом по вычислительным Европам. Часть 1. Что такое процессор.

Галопом по вычислительным Европам. Часть 2. Пути повышения IPC.

Галопом по вычислительным Европам. Часть 3. Оптимизация.

Галопом по вычислительным Европам. Часть 4. Как накормить процессор.

Галопом по вычислительным Европам. Часть 5. Память.

Галопом по вычислительным Европам. Часть 6. Спецпроцессоры.

Галопом по вычислительным Европам. Часть 7. Ввод-вывод.

Галопом по вычислительным Европам. Часть 8. Хранение данных.

Галопом по вычислительным Европам. Часть 9. Параллельные миры и техпроцессы.

Галопом по вычислительным Европам. Часть 10. Китайский путь и персональная безопасность.