Кажется, совсем не так давно, а для кого-то, может быть, еще в прошлую пятницу, золотым стандартом технологического стека сетей хранения данных был Fibre Channel: SCSI, FCP, FC. Неудивительно: Fibre Channel разрабатывался целенаправленно для хранения данных. Но уже к середине 2000-х на сцене появляется новый стандарт — протокол iSCSI, реализованный поверх TCP/IP и Ethernet. Почему? Fibre Channel был всем хорош, кроме своей цены и зависимости от нескольких производителей сетевого оборудования.

C появлением новых высокопроизводительных компонент хранения данных и исчерпания масштабирования производительности традиционных интерфейсов, в том числе SAS, рождается стандарт NVMe — протокол, который работает поверх PCIe. NVMe, повторяя путь SCSI на заре эры SAN, реализуют в сетях хранения как набор стандартов NVME-oF (Over Fabric) для различных транспортных протоколов: FC, RDMA, TCP. Начиная с версии 3.2 в TATLIN.UNIFIED реализована поддержка NVMe over TCP наравне с Fibre Channel и iSCSI.

Меня зовут Александр Пищулин, я инженер в отделе оптимизации быстродействия СХД в YADRO. В статье я постараюсь дать представление о реализации NVMe over TCP в системах, построенных на базе ядра Linux, c фокусом на производительность. Также поделюсь результатами тестирования протокола в TATLIN.UNIFIED GEN2.

Привет! Я Александр Пищулин, перфоманс-инженер в компании YADRO. Сегодня расскажу об одном интересном случае траблшутинга в работе с системой хранения данных — он касается выброса времени отклика. Поиск причин сбоев, наверное, одно из самых увлекательных занятий в моей работе. Зачастую у подобных задач минимальная формализация подхода к решению, каждый раз может быть своего рода открытием или, если угодно, челленджем.

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