Русский
Русский
English
Статистика
Реклама

Hpe

Обзор HPE Nimble или практический опыт использования. Все ли так хорошо, как заявляет производитель?

19.03.2021 16:09:40 | Автор: admin

Хотелось бы поделиться с вами практическим опытом тестирования и использования системы хранения данных HPE Nimble, в нашем случае впечатлениями будем делиться относительно модели All-Flash HPE Nimble AF40. Насколько эта статья будет актуальна и интересна решать только вам, но мы в свое время столкнулись с проблемой поиска реальных историй (не путайте с историями успеха), в которых по большей степени автор делился бы своими мыслями, опытом и впечатлениями, т.е. чистыми эмоциями от сердца, а не сухими фактами или вездесущим маркетингом. Поэтому решили потратить немного своего времени и попробовать написать что-то подобное, поэтому не судите строго, т.к. это первая проба пера. Итак, поехали.

Чтобы немного ввести вас в курс дела для начала дадим скупую информацию о нашем подопытном. Данную модель HPE позиционирует среди своего же семейства All-Flash массивов Nimble, как оптимальный выбор по соотношению цена/производительность. С точки зрения производительности система достаточно сильно отличается от младшей модели AF20 (превышает почти в 5 раз!), но при этом не столь сильно уступает более старшим моделям AF60 и AF80. Самой старшей модели наш экземпляр уступает по паспорту в среднем в 3 раза, по некоторым показателям и то меньше, а модели Nimble AF60 не более, чем в 2 раза. Массивы всей линейки HPE Nimble имеют весь необходимый функционал, согласно своему статусу массивам среднего ценового сегмента. Тут тебе и компрессия с дедупликацией, причем последняя с переменным блоком, и аппаратные снимки с согласованием на уровне приложения, и синхронная репликация, с возможностью реализации концепции Metro Storage Cluster, и поддержка технологии VVOL, QoS, возможность собирать Storage Pool из нескольких массивов некое подобие федерации, и еще парочка козырей в рукаве в виде искусственного интеллекта и продвинутой аналитики.

Ну а теперь о цифрах

По паспорту система позволяет получить до 130К IOPS на блоках 4К в смешанной нагрузке 50/50 на случайных операциях ввода-вывода, 150K IOPS на все тех же блоках 4К при 100% случайном чтении и 150К IOPS при 100% случайной записи все это без учета дедупликации. С ее же учетом итоговые показатели будут зависеть от ее общего коэффициента. К примеру, при общем коэффициенте дедупликации 10:1 немного просядут операции случайной записи до 130К на блоках 4К. При этом количество IOPS на операциях чтения возрастет до 170К, а в смешенном режиме 50/50 заявлено 96К IOPS. По нынешним меркам более чем скромно для All-Flash массива. Тем более, что массив является представителем Mid-Range сегмента, и от них ожидаешь действительно приличных цифр, так как сегмент представляет из себя подобие гоночного трека, где каждая доля секунды на счету и производители выставляют лучшее, лишь бы поразить искушенную публику и завоевать их сердца (а заодно и кошельки). Поражать тут с точки зрения цифр нечем, тем более что сейчас даже массивы Entry-Level (начального уровня) могут похвастаться и показателями 300+К IOPS, чему, к слову, могли бы и позавидовать приличное количество Hi-End систем хранения данных 8-10 летней давности. Да, прогресс не стоит на месте все так и есть. Другой вопрос, что критерии выбора у всех разные и не всем нужен самый быстрый автомобиль. Я так точно больше являюсь адептом комфорта. Да, динамика, несомненно, вещь важная и необходимая (в определенной степени) для формирования того самого комфорта: когда машина едет и позволяет без напряга, когда надо прибавить, совершить динамичный маневр и вообще приятно, когда под капотом мощный движок, который, возможно, никогда не будет использоваться в полную силу, но кого это волнует... Сразу вспоминаются спорт-кары, которые весело и задорно урчат в городе от светофора до светофора, знатно взбалтывая тушки своих удалых владельцев очень динамичный разгон и не менее динамичное торможение. На вкус и цвет фломастеры разные: кому-то нравится, кому-то нет. Я так всеми руками за практичность, т.е. можно есть суп вилкой, но зачем, когда есть ложка. Или зачем есть борщ черпаком из 10 литровой кастрюли, если есть тарелка и все та же ложка. Ну в общем, я думаю, вы меня поняли.

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

К слову, в нашей практике компания HPE не была замечена в каких-либо махинациях с цифрами, в неполноте или недостоверности ТТХ по продуктам. Чего не скажешь о документации по работе с оборудованием, уж простите наболело. Поэтому мы, конечно же, отнеслись к заявленным цифрам с доверием и сразу же решили их проверить (доверяй, но проверяй к этой простой жизненной мудрости мы пришли, проводя теплые летние деньки за очередной мисочкой лапши).

Плавно переходя к тестированию, естественно, нельзя не упомянуть состав нашего тестового стенда: здесь, как говорится, best practice не заглядывал. Если серьезно, то оборудование уже весьма подуставшее, процессоры на подключенных хостах не каноничные (те самые красные), гипервизоры End of General Support. Что действительно радует, так это наличие SAN-сети на коммутаторах SN6000 (8-гигабитный Qloqic SANbox 5800 привет из 2010-го года). В общем, не 4 Гбит, и уже хорошо. Но те самые 16 Гбит FC на HPE Nimble AF40 раскрыть, к сожалению, не удастся. Да и конфигурация самого массива, тоже, скажем так, не best practice, т.к. официально рекомендуется использовать минимум 4 порта ввод-вывода на каждом контроллере, а в нашем случае мы имеем только 2 порта 16 Гбит FC в режиме 8 Гбит.

сервер DL385 Gen7, AMD Opteron 6180 SE, VMware ESXi 6.0.0сервер DL385 Gen7, AMD Opteron 6180 SE, VMware ESXi 6.0.0

Из трех серверов DL385 Gen7 собран кластер виртуализации на VMware ESXi 6.0.0. Управление через VMware vCenter в формате appliance на Linux. На каждом хосте по два процессора AMD Opteron 6180 SE и 192 ГБ оперативной памяти DDR3 PC3-10600 ECC RDIMM (1300 МГц). Для подключения к SAN-сети используется две однопортовые FC HBA 8 Гбит (HPE 81Q) на каждом из хостов. Сам же HPE Nimble AF40 укомплектован 24 твердотельными накопителями объемом 480 ГБ, двумя контроллерами и по одной двухпортовой 16 Гбит FC HBA в каждом из них.

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

Пока это все было хождение вокруг да около и относительно самой системы хранения HPE Nimble AF40 не было сказано ничего, кроме заявленных ТТХ. Поэтому пора, так сказать, исправлять ситуацию, тем более что после затянувшегося аперитива, мы как раз подошли к этому весьма вкусному моменту. Делиться своими впечатлениями и результатами будем последовательно: начиная с настройки самой системы и далее переходя к тестам и кое-чему весьма интересному. Но обо всем по порядку.

Впечатление 1: распаковка, монтаж и первичная настройка

С вашего позволения тут я не стану сильно задерживаться, хотя есть любители посмаковать сей момент в полном объеме. Что тут сказать, упаковка внушает доверие, все очень добротно: плотная картонная коробка, притянутая болтами к деревянному паллету, внутри массив защищен плотным полиэтиленовым пакетом и черной разновидностью пенопласта (упругий и не крошится). Все на своих местах коробочки и пакетики с аксессуарами. В общем на упаковке точно не сэкономили. Сам массив представляет собой полку на 4U, очень увесист и габаритен, глубина полки этого мастодонта целых 89 см, а вес более 50 кг. Хотя, чему удивляться сама коробка огромна по меркам среднестатистического массива и как бы намекает на сидящего в ней монстра. Шутки шутками, а вес имеет значение, особенно при монтаже. Так и здесь металла много, пластика минимум, очень монолитно и добротно. Можно при желании хоть раз 10 монтировать и демонтировать ничего не погнется, не сломается, не треснет и не отлетит. На самом деле, это давно стало проблемой для современного оборудования, которое изобилует пластиком; детальки так и норовят треснуть или сломаться даже после монтажа.

Первоначальная настройка массива до безобразия проста и интуитивно понятна. А дополнительную веру в собственные силы поможет обрестиWelcome Center для Nimble. Производитель предлагает в помощь онлайн-портал с пошаговыми текстовыми и видео-инструкциями, что будет не только полезно и удобно, но и наглядно. Одним только Nimble там дело не ограничилось, доступны материалы и по другой системе хранения HPE Primera.

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

Ну и, конечно же, захватывающие видео сопровождения, а в качестве бонуса еще и ссылка на Installation Guide:

Суммарно подготовка массива к работе занимает 15-30 минут. За качество исполнения, упаковку, внешний вид и простоту первоначальной настройки 5 из 5. Вес и габариты, конечно, дают о себе знать, но можно и потерпеть.

Впечатление 2: подключение HPE Nimble AF40 к кластеру VMware

И здесь наc ждал первый приятный сюрприз и важное преимущество HPE Nimble простая и понятная интеграция с VMware с использованием технологией VVOL. Это особенно эффектно в связи с тем, что мы до этого не использовали технологию VVOL, но идеологически пытались ее воссоздать вручную использованием выделенных VMware VMFS Datastores под каждый виртуальный диск каждой виртуальной машины. Такой ручной подход был призван упростить использование аппаратных снимков, обезопасить от возможных проблем с очередями на уровне LUN (когда есть один жирный VMware VMFS Datastore и все виртуальные машины живут на нем, как в большой коммунальной квартире с общей кухней, на которой периодически могут устраивать поножовщину).

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

Но, несмотря на такое весомое количество плюсов, минусов было также предостаточно, особенно в части трудозатрат. Речь идет про ручное создание всех необходимых виртуальных томов на уровне массива, презентация их кластеру, создание каждого из дисков виртуальной машины на своем выделенном VMware VMFS Datastore, и так далее. Стоит отметить, что такой вариант явно подошел бы не всем, так как существуют ограничения по их количеству для ESXi 6.0.0 это значение равно 256. Но в нашем случае в лимит мы укладывались, а с неудобствами и трудозатратами мирились в угоду управляемости.

Технология VVOL вообще позволила уйти еще дальше. Помимо указанных плюсов и отсутствия явных минусов, она позволила перенести и полностью автоматизировать операции по созданию виртуальных томов на системе хранения данных для виртуальных машин на VMware vCenter. То есть, настроив интеграцию единожды, теперь вообще нет какой-либо необходимости заходить в интерфейс управления HPE Nimble AF40 или создавать новые презентации для новых томов. Даже не обязательно готовить тома заранее на системе хранения в случае использования специфических настроек (толстый или тонкий тип диска, включена ли компрессия и дедупликация, размер блока дедупликации). Теперь это все делается с помощью vCenter и VM Storage Policies.

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

  • Шаг 1. Выполнить интеграцию с vCenter

  • Шаг 2. Создать на HPE Nimble структурный каталог Folder с указанием типа управления VVOLs:

  • Шаг 3. Ознакомиться с Performance Policies на HPE Nimble для создания VM Storage Policies (можно так же создавать свои Performance Policies на HPE Nimble с указанием преднастроек это, по сути, профиль создания виртуального тома):

  • Шаг 4. Создать необходимый набор VM Storage Policies в vCenter на основе Performance Policies:

  • Шаг 5. Подключить Folder к кластеру в vCenter:

Для искушенных также есть возможность посмотреть разного рода информацию по VVOL через плагин HPE Nimble в vCenter, а также настроить график создания консистентных снапшотов на уровне VM Storage Policies:

Впечатление 3: нагрузочное тестирование синтетическими тестами

А теперь самое время проверить заявленные ТТХ массива. Самый простой паттерн нагрузки 100-процентное случайное чтение блоками 4К (без использования дедупликации). Используем встроенный в HCIbench нагрузочный инструмент со следующими настройками:

Общее количество виртуальных машин 12, каждая с 8 дисками объемом 10 ГБ, разогрев 6 минут, время теста 1 час, суммарное количество потоков 384. Важный момент перед тестом на диски записываются абсолютно случайные данные таким образом, что полностью отсутствуют блоки с 0, поэтому компрессия на данных дисках показывает коэффициент 1:1. Это важно, т.к. при наличии нулевых блоков операции чтения могут значительно ускоряться при включенной компрессии.

По результатам получаем следующее. Аналитика со стороны интерфейса управления HPE Nimble AF40:

Результаты со стороны HCIbench (для самых внимательных: время отчета указано с учетом временной зоны GMT -07:00, что составляет разницу в 10 часов по сравнению с GMT +03:00):

Задержки на чтение высоковаты хотелось бы уложиться в 2 мс, поэтому пробуем второй заход: настройки те же, но снижаем количество виртуальных машин до 6, тем самым снижая количество потоков до 192:

Уже значительно лучше.

Конечно, было интересно, как отработает QoS, поэтому выставили ограничение для тестируемых VVOL в 20К IOPS и еще раз запустили первый тест на 384 потока, но в целях экономии времени продолжительностью всего 10 минут.

Используя SSH-подключение к хостам ESXi и встроенную утилиту esxtop, видим, что с каждого хоста генерируется нагрузка в 125-128 потоков и при этом получаем очень высокие показатели задержки от FC HBA сервера до системы хранения. И тут ничего удивительного: система хранения отрабатывает политику QoS, понижая максимальное количество операций ввода-вывода в секунду до 20 000, что приводит к скапливанию очередей и задержкам в вводе-выводе.

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

А как дела обстоят с записью? Прогоняем тест 100% случайная запись, размер блока 4К, остальные параметры те же. Опять же для начала 384 потока.

По традиции прогоняем тест второй раз, но уже с 6 виртуальными машинами, а, следовательно, в 192 потока.

Тут тоже удалось уложиться в 2 мс. Результат весьма близок к аналогичным замерам по 100% случайному чтению. Это говорит о том, что соотношение показателей IOPS, заявленных вендором, являются релевантными. Напомню, по 150К IOPS для 100% случайного чтения блоками 4К и для 100% случайной записи блоками 4К. Хотя обычно на практике запись всегда проседает относительно чтения, вероятно, это чудесная магия запатентованной архитектуры HPE Nimble CASL с многоуровневым кэшированием как записи, так и чтения.

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

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

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

Впечатление 4: ИИ HPE Infosight в шахматы с ним не сыграешь, но вот проблемы найти и решить поможет

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

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

В том числе разнообразные дашборды. Например, Operational, который позволяет оценить общее состояние массива, или Recommendations, которые дают возможность подробно ознакомиться с рекомендациями на рисунке выше в правой части скриншота. Рекомендации, кстати, формируются на основании аналитики, которая производится искусственным интеллектом c использованием машинного обучения и телеметрии всей инсталляционной базы HPE Nimble по всему миру (в лабораториях HPE Nimble это Cross Stack Recommendations).

Ниже приведен пример рекомендаций по одной из проблем Physical CPU Saturation с указанием масштаба бедствия. Также доступны рекомендации и по оставшимся двум проблемам Elevated Latency, Virtual CPU Overprovisioning, и иногда щедрость тоже губит:

Также здесь присутствуют и отчеты для руководителей (Executive), которые показывают, есть ли открытые кейсы, по которым ведется работа, экономические показатели массива (сколько удалось сэкономить места благодаря технологиям компрессии и дедупликации), а также рекомендации в случае необходимости апгрейда массива. Wellness позволяет получить список по проблемам, если таковые имеются, а Capacity показывает разного рода тренды по динамике заполнения массива.

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

Тут и вышеупомянутая Cross Stack Recommendations, и Resource Planner, который позволит сэмулировать добавление на массив какой-либо нагрузки и изучить, как она повлияет в целом на производительность массива. При этом есть тонкая настройка выбранной нагрузки.

Раньше, кстати, для этого всего требовались отдельные продукты, например, HP Virtualization Performance Viewer, которые, естественно, стоили денег, и их необходимо было разворачивать и поддерживать.

Если вам кажется, что есть проблемы в производительности системы хранения данных, можно запустить AI Performance Recommendations и получить анализ за выбранный период. Соответственно, если будут проблемы будут и рекомендации, как их устранить.

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

Опытный заводчик виртуальных машин может подумать: вот еще бы тут была корреляция метрик производительности по виртуальной инфраструктуре с метриками системы хранения, а то как-то неудобно что-то искать в VMware vCenter, что-то в интерфейсе управления HPE Nimble в разделе Monitoring, а затем прикидывать одно к другому излюбленным эмпирическим методом. И, да, это тут тоже есть. В разделах Infrastructure -> Virtualization в зависимости от того, что вы используете (на текущий момент поддержка только для VMware и Hyper-V) можно получить информацию о своих дата-центрах, кластерах, хостах, дата-сторах и виртуальных машинах (их загрузка, производительность, метрики).

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

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

Резюме: с ИИ HPE Infosight все понятно, вещь полезная, удобная и нужная это бесспорно. В 86% случаев система будет предотвращать или предлагать рабочее решение ваших проблем автоматически. Но вот в остальных случаях что? А если возникла жизненная необходимость пообщаться с живым человеком, а в ответ только бездушный голос машины или робота, который готов всячески тебе помочь, но в своей извращенной манере. Сразу вспоминается ситуация с дозвоном в банк или оператору связи, когда нужно еще очень сильно постараться, чтобы попасть на живого человека. Но тут, к счастью, обошлось. Есть выделенный телефон поддержки HPE Nimble, по которому отвечают люди и даже больше инженеры (чувствуете разницу?) но сейчас будет вообще хорошо инженеры поддержки 3 уровня, в том числе и русскоязычные.

Впечатление 5: поддержка, которая помогает

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

В общем согласитесь, всегда приятно, когда кто-то ломает шаблоны. А еще приятнее, когда из этого действительно выходит толк. Так вот опишу нашу небольшую историю общения с L3 поддержкой HPE Nimble. Все началось с проблемы с одним из контроллеров во время тестирования их переключения (HA Failover). После переключения нагрузки, контроллер ушел за сигаретами в перезагрузку и после этого не вернулся. Странная, конечно, ситуация, но даже сброс по питанию не помог. Естественно, открылся кейс с помощью ИИ HPE Infosight и был автоматически передан инженерам L3 технической поддержки HPE Nimble, так как тут сбой контроллера на лицо и человекам виднее что там куда требовалась расширенная диагностика. Далее следовали в большинстве своем стандартные процедуры общения с поддержкой, исключая, разве что, прохождение кругов ада для того, чтобы попасть наконец к толковому инженеру (нашим кейсом, к слову, от начала и до конца занимался один и тот же инженер Павел Тимургалеев). Мы уже были морально готовы к замене контроллера, согласитесь, достаточно ожидаемый исход. Но все получилось немного интереснее.

Проблема оказалась в том, что контроллер был подключен по консольному кабелю к серверу, на котором был установлен СКУД (сервер использовался нами для доступа к консоли массива). Серверов стоечных у нас было всего два, поэтому раскидали один контроллер к одному, второй к другому, остальные же серверы были в форм-факторе блейд-сервер. СКУД каким-то образом держал на себе консольный порт контроллера HPE Nimble и не давал ему загрузиться. С заменой по итогу обошлось, проблема была решена. Каким образом поддержка дошла до причины проблемы тоже остается загадкой. Но сам факт, что проблему удалось решить в кратчайшие сроки и максимально эффективно, т.е. без 2-3 итерацией замены контроллера, после которых стало бы понятно, что дело не в контроллере, действительно внушает уважение. Павлу и команде поддержки HPE Nimble однозначно хотелось бы выразить благодарность за проявленный профессионализм (надеюсь, им икнулось).

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

На этой позитивной ноте я бы хотел уже откланяться, но вы же непременно скажете: а где же минусы, минусы-то где? Не бывает такого, чтобы без минусов. Да, соглашусь, без минусов, конечно же не обошлось. Один из основных минусов это избыточная мощность. Честно говоря, под наши нагрузки хватило бы и гибридной модели в соотношении 20% SSD/80% MDL 7,2K, например, тех же HPE Nimble HF20 или HPE Nimble HF40, но был бюджет, а поэтому почему бы и нет. Но теперь приходится придумывать самим себе работу и вводить новые сервисы, т.к. видя, как система простаивает, сердце кровью обливается и хочется непременно ее нагрузить. Поэтому каждый раз, когда залезаешь в ИИ HPE Infosight, то получаешь мощного пинка от системы, она заставляет постоянно что-то оптимизировать, что-то настраивать, заставляет работать, одним словом, смотреть только вперед и не оглядываться назад, ведь за спиной надежный соратник. А может быть VDI? А почему бы и нет, черт возьми! Поэтому сейчас начали разворачивать и тестировать VMware Horizon с использованием концепции Just-in-Time (linked clones уже не торт). А тем временем аппетиты растут и уже где-то там на горизонте маячат новые сервера с NVIDIA Tesla T4 или серии RTX6000. Было бы неплохо.


UPD: в рамках статьи упустил много чего интересного, а именно, первичную проблематику тестирования All-Flash массивов на гипервизорах VMware ESXi, с которой бились достаточно длительное время и грешили на HPE Nimble (мы и не говорили, что мы святые). Из коробки нагрузочное тестирование адекватно работать не будут: тут и проблемы с очередями на FC HBA (базовые значения драйвера) DQLEN и No of outstanding IOs with competing worlds, а также ограничения со стороны виртуальных контроллеров виртуальных машин. Этого материала вполне хватит на отдельную статью.

Подробнее..

Тестирование производительности и краткий обзор HPE Nimble Storage Adaptive Flash HF60

13.06.2021 08:21:39 | Автор: admin

Хочется пролить свет на интересную линейку систем хранения данных HPE Nimble Storage Adaptive Flash и попытаться раскрыть вопрос почему маркетологи решили его назвать Adaptive Flash, а не более традиционно - Hybrid Flash. Судя по поиску, существует не так много обзоров и статей, посвященных Nimble, поэтому надеюсь, что этот материал будет полезен интересующимся данной темой.

В мое распоряжение попал массив с флагманскими контроллерами - HF60. Это СХД 5-го поколения (Nimble Gen5), но уже по состоянию на 04.05.2021 компания HPE анонсировала (пока только AllFlash) 6-е поколение (Nimble Gen6), которое будет называться Allerta 6000. Adaptive Flash 6-го поколения - анонс ожидается летом 2021. Так что пока наш подопытный последнего (актуального) поколения.

Итак, чем же интересен HPE Nimble Adaptive Flash?

Давайте начнем издалека. Компания Nimble Storage берет свое начало в 2008 году и уже в 2014 наделала много шуму, объявив о революционном достижении (на тот момент) доступность систем хранения данных превысила 99,999%. В 2016 году этот показатель уже составлял 99,999928%. Традиционно, столь успешные стартапы поглощаются более крупными компаниями. Так и случилось с Nimble - в 2017 году компания влилась в ряды Hewlett Packard Enterprise. За счет чего им удалось получить такие цифры доступности (причем это не лабораторные, а реальные данные)? Если совсем коротко: архитектура и надстройка в виде аналитической платформы InfoSight. Давайте остановимся на каждом пункте чуть подробнее.

Архитектура

Если Вам лень читать, можете посмотреть видео (на англ.):

СХД Nimble в своей основе использует архитектуру CASL (Cache Accelerated Sequential Layout). В основу архитектуры заложено:

  1. Active/Standby контроллеры. Большинство других систем с двумя контроллерами Active/Active демонстрируют производительность с нулевым запасом мощности, поэтому, если один из контроллеров недоступен - вы уведёте половину скорости...

  2. Функционал редупликации/компрессии/шифрования в режиме онлайн (на лету). Подробнее как это работает ниже в описании операций чтения и записи.

  3. RAID Tripple Parity+ с фиксированным стартовым набором дисков 21шт HDD + 6шт SSD. Массив выдерживает выход из строя 3 любых дисков из одной RAID группы. Но лучшее качество Triple+ RAID не в том, что он защищает от потери любых 3 дисков. Крутая часть это +. Это позволяет системе не иметь проблем с целостностью данных, даже если на каждом отдельном диске в системе возникают ошибки параллельного чтения секторов и три диска были потеряны. Это уровень устойчивости к коррелированным по времени ошибкам, который ни один другой массив в мире даже близко не может предложить.

  4. Защита данных через каскадные многоступенчатые контрольные суммы.

  5. Память с защитой по питанию NVRAM.

  6. SSD кэш на чтение (в случае с Adaptive Flash). Важно отметить, что RAID для SSD не используется, т. к. задача кэша дать максимальную скорость. Насчет надежности можно не беспокоиться, поскольку данные в кэш копируются с защищенных RAID-ом TripleParity+ HDD (об этом ниже).

Рассмотрим алгоритмы чтения и записи

Процесс записи на массивы Adaptive FlashПроцесс записи на массивы Adaptive Flash

Распишем процесс записи:

  1. Запись от разных приложений разными блоками;

  2. NimbleOS принимает запись на NVDIMM активного контроллера;

  3. NimbleOS зеркалирует NVDIMM активного контроллера в NVDIMM Standby контроллера;

  4. NimbleOS подтверждает запись хосту;

  5. Блоки копируются в DRAM, где и происходит магия архитектуры CASL, а именно:

    a. Дедупликация с переменным блоком;

    b. Сжатие с переменным блоком;

    c. Блоки собираются в страйпы размером 10 Мбайт;

    d. Страйпы последовательно пишутся на HDD;

  6. Достойные кэша блоки или блоки из Pinned томов копируются на SSD кэш + блоки индексируются (индекс пишется на SSD и HDD в фоне). Есть 3 настройки кеширования которые можно выставить на каждый том:

    Default данные кэшируются в автоматическом режиме по выбору NimbleOS;

    Pinned настройка, которая по умолчанию копирует все данные тома на SSD диски и мы получаем All Flash на чтение;

    OFF - выключенное кеширование, т. е. SSD диски не задействованы вообще. Полезно для томов, где нет необходимости ускорять чтение;

Какие преимущества имеет такая запись?

Во-первых: количество операций Random write в бэкенде системы минимизировано. По сути, большинство операций происходит в оперативной памяти кэша контроллеров, компрессия выполняется после дедупликации, таким образом число операций ввода-вывода на дисках SSD/HDD сведено к минимуму.

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

Процесс чтения в массивах Adaptive FlashПроцесс чтения в массивах Adaptive Flash

Рассмотрим, что происходит при чтении:

  1. Запрашиваем блок в NVDIMM. Если данные там отдаем хосту;

  2. Если блока нет, читаем из DRAM;

  3. Если блока нет, читаем с SSD:

    a. Если блок есть, проверяем контрольную сумму, разжимаем;

    b. Регидрируем и отдаем хосту;

  4. Если блока нет, читаем с HDD, блок ищем через индекс;

    a. Если блок есть, проверяем контрольную сумму, разжимаем;

    b. Регидрируем и отдаем хосту;

  5. Если блок достоин кэша, копируем на SSD;

Какие преимущества дает такой алгоритм чтения?

Во-первых: скорость ограничена не производительностью дисков, а скоростью памяти NVDIMM (которая существенно быстрее SSD дисков) т. е. контроллерами.

Во-вторых: согласно живой статистике, массив больше 95% попадает в кэш. Иными словами, имея в запасе всего 1020% SSD дисков, массив будет обеспечивать скорость All Flash больше 95% времени. Важно отметить, что это не означает что оставшиеся 5% времени данные будут читаться медленно с механических дисков. Дисков в стартовом наборе - 21 шт., при чтении их скорость суммируется. Будет иметь место то, что при чтении с HDD дисков задержка будет немного больше чем 1мс. Но не забываем, что этого легко избежать настройкой кэширования индивидуально для каждого тома.

Резюмируя по архитектуре:

  1. Данные защищены от выхода из строя 3-х любых накопителей;

  2. Данные дедуплицируются и сжимаются в памяти до записи на диски без существенного падения производительности;

  3. Данные пишутся быстро: благодаря алгоритму архитектуры CASL;

  4. Данные читаются быстро: кэшируются на SSD диски для ускорения чтения и здесь нет никакого тирринга данных как в традиционных гибридах;

  5. Данные можно дополнительно защищать шифрованием;

  6. Гибкие настройки. Можно вкл/выкл индивидуально для каждого тома: дедуп; компрессия; шифрование; кеширование; ограничение по IOPS или пропускной способности (или того и другого) и прочее;

  7. Гибкие возможности масштабирования емкости/производительности:

  • возможность масштабировать емкость (добавлять дисковые полки);

  • емкость и производительность (добавлять еще один массив в кластер, до 4 шт);

  • производительность (заменить контроллеры на более производительные).

InfoSight

Тезисы:

  • HPE InfoSight это передовая в отрасли платформа облачной аналитики InfoSight. Передовая - поскольку начала работать гораздо раньше, чем у других вендоров. А здесь важна наработка системы по времени. Чем дольше она работает, тем больше данных собирает, тем больше проблем может предотвратить. Об этом ниже.

  • Доступность СХД HPE Nimble 99,9999%, достигается благодаря применению InfoSight.

  • Миссия HPE InfoSight: сохранять маниакальный фокус на предоставлении заказчику такой поддержки, чтобы все завидовали!

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

Например, при обнаружении у одного из заказчиков проблемы в совместимости микропрограммы контроллеров СХД с приложениями гипервизора, система автоматически заблокирует возможность установки данной версии прошивки на СХД у других заказчиков, а тем у кого уже установлена схожая конфигурация - будет предложен апдейт системы. Такой подход помогает предотвращать сбои до их возникновения, причем во многих случаях без вмешательства человека.

По данным HPE, при использовании InfoSight 86% проблем разрешаются без участия ИТ-службы. Сюда входят инциденты как с самой СХД, так и с окружающей инфраструктурой.

InfoSight позволяет значительно сократить время на поиск проблемных узлов инфраструктуры в случае деградации производительности. Система в удобном графическом виде показывает текущее время отклика и статистику задержек за определенный период по проблемной ВМ не только относительно самой СХД, но и сети передачи данных SAN, а также приложений гипервизора. Отклонение каких-либо показателей в кратчайшие сроки позволит определить узкое место инфраструктуры. Не нужно переключаться между несколькими системами мониторинга, все показатели доступны в едином портале, так как InfoSight интегрируется с VMware VCenter. В процессе диагностики собирается только служебная информация, собственные данные заказчика не затрагиваются. Информация передается по защищенному SSL каналу.

Некоторые примеры передаваемых данных:

  • Серийный номер массива.

  • Базовая информация о работоспособности (health check).

  • Системные журналы событий.

  • Параметры настроек системы.

  • Статистика работы системы.

Самое вкусное на десерт - тестирование

Тестовая конфигурация:

  • СХД Nimble HPE Nimble Storage Adaptive Flash HF60 / 21x2TB HDD / 5.76TB (6x960GB) SSD Cache / 4x16GB FC на каждый контроллер;

  • Хост 1: Сервер HPE DL160 Gen10 / 1x Xeon 4210R / 6x16GB DDR4-R / 2xSN1100Q 16Gb 2p FC / 2x500W;

  • Хост 2: Сервер HPE DL325 Gen10 / 1x EPYC 7551P / 8x16GB DDR4-R / 2xSN1100Q 16Gb 2p FC / 2x500W;

  • Подключение серверов напрямую к СХД, т. к. под рукой не было коммутаторов Fibre Channel. Поэтому в серверах по 2шт двухпортовых карточки, чтоб загрузить все 4 порта на каждом контроллере СХД;

  • VMware vSphere 7;

  • Тестирование с помощью HCIbench 2.5.3;

Для начала нам было интересно сравнить наш Adaptive Flash HF60 с протестированным All Flash AF40:

Нагружаем наш массив аналогичными параметрами и в конце сводим результаты.

Первый тест: 384 потока/100%, получаем результаты:

Второй тест: 192 потока/100% чтение, получаем результаты:

Третий тест: 192 потока/100% запись, получаем результаты:

Сравниваем результаты Adaptive Flash HF60 vs All Flash AF40:

Пару слов о полученных результатах

Получаем то, что СХД с медленными 7,2k дисками дает большую производительность и меньшое время отклика чем All Flash массив. Как так? Все дело в контроллерах и архитектуре. В нашем случает стоят более производительные контроллеры и за счет магии архитектуры CASL гибриды Adaptive Flash показывают производительности сопоставимую с All Flash (контролеры используются одинаковые HF20=AF20, HF40=AF40, HF60=AF60, разница HF и AF только в конфигурации дисках). Причем скорость и задержки HF60 выигрывает при записи, где в Adaptive Flash никак не задействованы SSD.

За то время что у нас был массив мы смогли сравнить еще с одной конфигурацией All Flash XS5226D СХД QSAN. К нам попал такой результат тестирования:

Единственное, что мы не смогли повторить 464 потока при 32-х виртуалках. Поэтому сделали 448 и 480.

448/480 одновременных потоков серьезная нагрузка. Можно отметить, что здесь массив вполне играет наравне с дешевым All Flash. У QSAN очень много непонятных пиков и провалов по задержке. Поэтому Nimble существенно выигрывает по 95-му перцентилю.

Эксперименты с дудепликацией и компрессией

При 100% записи производительность проседает некритично ~ 20%. При 100% чтении почти ничего не меняется, что вполне логично. Гораздо интереснее 70/30. При наличии нулевых блоков операции чтения ускоряются при включенной компрессии.

Итого: почему его назвали Adaptive Flash а не Hybrid Flash?

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

Могу еще добавить, что наши инженеры скептически относились к данному массиву до тестирования. После первых предварительных результатов (~94k IOPS и задержки 5мс) на 100% чтение Возник спор, т. к. 94k полученных и 300k теоретических сильно отличались. Инженеры стояли на том, что невозможно получить больше на дисках 7200. После проверки конфигурации оказалось, что для тестовых машин было выключено кеширования и чтение не ускорялось вообще. После правильной настройки все взлетело. И как только они не пытались убить скорость массива не получалось (в рамках разумного естественно). В итоге лишь в условиях личного опыта у них поменялось мнение. К чему это? К тому что очень полезно брать железяку на тест, когда ее предлагают (да еще и бесплатно).

Подробнее..

CentOS 7 и контроллер HPE B320i

17.02.2021 18:10:52 | Автор: admin

Понадобилось на днях установить старенький CentOS 7 на старенький ProLiant 360e Gen8. Задача уже экзотическая, но мало ли - вдруг кому пригодится, Maintenance updates для 7-ки обещаны еще до июня 2024, и gen8 еще могут послужить. Сперва опишу проблему, далее будет пошаговое руководство.

Intro

Итак, имеем CentOS/RHEL 7 и ProLiant Gen8 с Dynamic Smart Array B120i/B320i SATA RAID Controller. B120i и B320i очень похожи, отличаются количеством поддерживаемых физических дисков (6 и 8 соответственно) и опциональной поддержкой SAS дисков с дополнительной лицензией в B320i. Контроллеры являются "облегченными" и без проприетарного драйвера не работают, в отличие от полноценных Smart Array (без Dynamic). Руководство применимо ко всем моделям с этим контроллером.

Проблема описана на в статье Is the HP Smart Array B320i, B140i, B120i, B110i controller supported by RHEL or RHELOSP сайте Red Hat.

Issue: Some of the HP Gen8 and Gen9 systems are shipping with either a Smart Array B320i, B140i, B120i, B110i, or other Bxxxi controller that requires a closed source driver to make RAID functionality available to the OS.

Выхода здесь два:

  • переключить контроллер в SATA режим и собрать массив программно средствами ОС;

  • предоставить драйвер программе установки ОС.

Подробности есть в документе HP Dynamic Smart Array B120i and B320i Controllers - Driver Support and Configuration на сайте HPE, здесь же есть о переключении режима контроллера. Документация - QuickSpecs и User Guide для Dynamic Smart Array Controllers.

Нам же интересен 2-й вариант. Контроллер есть, уже куплен - надо использовать! Из очевидных плюсов - простота, никаких дополнительных шагов для загрузчика, boot раздела и т.д.

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

Пошаговое руководство.

  1. Загрузить тот самый драйвер. HPE Dynamic Smart Array B120i/B320i SATA RAID Controller Driver for Red Hat Enterprise Linux 7 (64-bit).

  2. Перейти в папку с загруженным файлом, распаковать его и изменить расширение на iso:
    $ gunzip hpvsa-1.2.16-136.rhel7u8.x86_64.dd.gz && \
    mv hpvsa-1.2.16-136.rhel7u8.x86_64.dd hpvsa-1.2.16-136.rhel7u8.x86_64.iso

  3. Создать образ флоппи-диска (шаг можно пропустить при наличии физического доступа к машине, записав iso-файл на отформатированный в fat32 USB-накопитель):
    $ mkfs.msdos -C hpvsa.rhel7.floppy.img 1440
    $ mkdir /tmp/hpvsa.rhel7.floppy
    $ sudo mount -o loop hpvsa.rhel7.floppy.img /tmp/hpvsa.rhel7.floppy
    $ sudo cp hpvsa-1.2.16-136.rhel7u8.x86_64.iso /tmp/hpvsa.rhel7.floppy
    $ sudo umount /tmp/hpvsa.rhel7.floppy
    $ rm -r /tmp/hpvsa.rhel7.floppy

  4. Подключаем в iLO Remote Console образы дистрибутива и флоппи-диска с драйвером, загружаемся с загрузочного диска, F11 Boot Menu.

  5. В параметры загрузчика дописываем (по нажатию Tab):
    (Прим.: в 5 и 6 было linux dd blacklist=ahci с добавлением vmalloc=384M для 32-битных ядер)
    modprobe.blacklist=ahci inst.dd

    Добавление параметров ядраДобавление параметров ядра
  6. Выбираем драйвер:

    Выбор драйвераВыбор драйвера
  7. Продолжаем обычную установку.

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

Дополнение

Для работы с контроллером и массивом непосредственно из ОС можно установить программу Command Line Smart Storage Administrator - ssacli.

  1. Импортируем публичный ключ HPE:
    rpm --import https://downloads.linux.hpe.com/SDR/hpePublicKey2048_key1.pub

  2. Создаем репозиторий

    vim /etc/yum.repos.d/mcp.repo
    [mcp] name=Management Component Pack
    baseurl=http://downloads.linux.hpe.com/repo/mcp/centos/$releasever/$basearch/current/
    enabled=1
    gpgkey=file:///etc/pki/rpm-gpg/GPG-KEY-mcp

  3. Установка:
    yum install amsd ssacli

  4. Использование:
    ssacli help

    Пример получения списка физических дисковПример получения списка физических дисков
Подробнее..

Использование недорогих 1040 Гбитс сетевых адаптеров с интерфейсом HP FlexibleLOM

25.11.2020 10:14:05 | Автор: admin

Для соединения пары домашних серверов мне захотелось выйти за пределы привычных 1Гбит/с и при этом сильно не переплачивать за сетевое оборудование. На известном сайте были приобретены недорогие серверные адаптеры HP 764285-B21, по сути являющиеся ОЕМ аналогами Mellanox ConnectX-3 Pro, и QFSP+ медный кабель (DAC). Эти двухпортовые адаптеры могут работать на скоростях 10 и 40 Гбит/с в режиме Ethernet портов и до 56 Гбит/с в режиме InfiniBand. Низкая цена на вторичном рынке обусловлена нестандартным интерфейсом HP FlexibleLOM, разъем которого хотя и похож на стандартный PCIe x8, но имеет иное расположение линий PCIe и поэтому может использоваться только в совместимых серверах HP. Тем не менее выход есть - Tobias Schramm спроектировал специальный адаптер для установки карт HP FlexibleLOM в обычный слот PCIe. Я заказал платы адаптера на jlcpcb.com и 8х коннекторы на алиэкспресс. После монтажа коннектора на плату адаптера и установки всей конструкции в слот она успешно определилась как устройство на шине PCIe:

lspci | grep Mellanox23:00.0 Ethernet controller: Mellanox Technologies MT27520 Family [ConnectX-3 Pro]

Однако после установки Ethernet драйвера Mellanox (я использовал Ubuntu 16.04 и 20.04, предполагаю для других версий и для Windows порядок действий будет аналогичен) Ethernet интерфейсы не появились в системе. Это означало, что драйвер по какой-либо причине не смог распознать адаптер и скорее всего потребуется перешивка. Изучая вывод dmesg можно примерно установить причину ошибки, в моём случае в прошивке адаптеров была включена опция SR-IOV, несовместимая с используемой материнской платой.

Для перешивки адаптера скачиваем и распаковываем Mellanox firmware tools для вашей ОС. Установку производим с ключом --oem (sudo ./install --oem), это позволит сразу установить дополнительные утилиты для сборки новой прошивки.

После установки MFT определяем текущую версию прошивки:

mlxfwmanager -d 23:00.0Querying Mellanox devices firmware ...Device #1:----------  Device Type:      ConnectX3Pro  Part Number:      764285-B21_Ax  Description:      HP InfiniBand FDR/Ethernet 10Gb/40Gb 2-port 544+FLR-QSFP Adapter  PSID:             HP_1380110017  PCI Device Name:  23:00.0  Port1 MAC:        24be05c557c1  Port2 MAC:        24be05c557c2  Versions:         Current        Available          FW             2.42.5700      N/A             Status:           No matching image found

...и делаем бэкап текущей прошивки и конфигурации адаптера:

flint -d 23:00.0 ri original_firmware.binflint -d 23:00.0 dc original_config.ini

Изучив раздел [HCA] файла конфигурации находим требуемый параметр sriov_en и, предварительно скопировав конфигурацию в новый файл new_config.ini, выставляем ему нулевое значение. Также проверяем, что eth_xfi_en равен единице - это позволит активировать Ethernet режим портов:

[HCA]...eth_xfi_en = 1sriov_en = 0...

Далее нам потребуется исходный файл прошивки .mlx для нашего чипсета (в моём случае это ConnectX-3 Pro), как выяснилось раньше их можно было свободно скачать с сайта Mellanox, однако сейчас лавочку прикрыли, оставив только готовые бинарные прошивки, которые, к сожалению, нам не подходят. В результате поисков мне удалось найти прямую ссылку на скачивание исходной прошивки предыдущей версии 2.36:

wget http://www.mellanox.com/downloads/firmware/ConnectX3Pro-rel-2_36_5000-web.tgz

Распаковываем архив и извлекаем искомый fw-ConnectX3Pro-rel.mlx, затем собираем новую прошивку с помощью mlxburn:

mlxburn -fw fw-ConnectX3Pro-rel.mlx -conf new_config.ini -wrimage new_firmware.bin

На всякий случай проверяем новую прошивку:

flint -i new_firmware.bin verify     FS2 failsafe image. Start address: 0x0. Chunk size 0x80000:     NOTE: The addresses below are contiguous logical addresses. Physical addresses on           flash may be different, based on the image start address and chunk size     /0x00000038-0x0000065b (0x000624)/ (BOOT2) - OK     /0x0000065c-0x00002b9b (0x002540)/ (BOOT2) - OK     /0x00002b9c-0x00003b27 (0x000f8c)/ (Configuration) - OK     /0x00003b28-0x00003b6b (0x000044)/ (GUID) - OK     /0x00003b6c-0x00003cc3 (0x000158)/ (Image Info) - OK     /0x00003cc4-0x00010fc3 (0x00d300)/ (DDR) - OK     /0x00010fc4-0x00012027 (0x001064)/ (DDR) - OK     /0x00012028-0x000123f7 (0x0003d0)/ (DDR) - OK     /0x000123f8-0x0005008b (0x03dc94)/ (DDR) - OK     /0x0005008c-0x00054f0f (0x004e84)/ (DDR) - OK     /0x00054f10-0x00059103 (0x0041f4)/ (DDR) - OK     /0x00059104-0x00059bfb (0x000af8)/ (DDR) - OK     /0x00059bfc-0x0008915f (0x02f564)/ (DDR) - OK     /0x00089160-0x0008cd0b (0x003bac)/ (DDR) - OK     /0x0008cd0c-0x000a1d7f (0x015074)/ (DDR) - OK     /0x000a1d80-0x000a1e87 (0x000108)/ (DDR) - OK     /0x000a1e88-0x000a6a8b (0x004c04)/ (DDR) - OK     /0x000a6a8c-0x000a827b (0x0017f0)/ (Configuration) - OK     /0x000a827c-0x000a82ef (0x000074)/ (Jump addresses) - OK     /0x000a82f0-0x000a8e03 (0x000b14)/ (FW Configuration) - OK     /0x00000000-0x000a8e03 (0x0a8e04)/ (Full Image) - OK-I- FW image verification succeeded. Image is bootable.

...и затем прошиваем в адаптер:

flint -d 23:00.0 -i new_firmware.bin -allow_psid_change burn    Current FW version on flash:  2.42.5700    New FW version:               2.36.5000    Note: The new FW version is older than the current FW version on flash. Do you want to continue ? (y/n) [n] : yBurning FS2 FW image without signatures - OK  Restoring signature                     - OK

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

В моём случае после всех вышеперечисленных манипуляций драйвер mlx4_core успешно распознал адаптер и сетевые интерфейсы появились в системе. Для ускорения процесса загрузки я дополнительно отключил boot options:

mlxconfig -d 23:00.0 set BOOT_OPTION_ROM_EN_P1=falsemlxconfig -d 23:00.0 set BOOT_OPTION_ROM_EN_P2=falsemlxconfig -d 23:00.0 set LEGACY_BOOT_PROTOCOL_P1=0mlxconfig -d 23:00.0 set LEGACY_BOOT_PROTOCOL_P2=0

...и удалил BootROM:

flint -d 23:00.0 --allow_rom_change drom

Кроме того, если не планируется использование интерфейсов InfiniBand, можно принудительно перевести оба порта в режим Ethernet:

mlxconfig -d 23:00.0 set LINK_TYPE_P1=2mlxconfig -d 23:00.0 set LINK_TYPE_P2=2
Подробнее..

Организация удалённой работы BIM-команды посредством HPE Edgeline, NVIDIA, VMware

11.04.2021 12:12:58 | Автор: admin

В РФ ведётся широкое внедрение цифрового строительства и использование цифровых моделей здания (BIM building information modelling) на законодательном уровне. Например, с 18 марта 2021г. вступило в действие Постановление Правительства РФ от 05.03.2021 331 "Об установлении случая, при котором застройщиком, техническим заказчиком, лицом, обеспечивающим или осуществляющим подготовку обоснования инвестиций, и (или) лицом, ответственным за эксплуатацию объекта капитального строительства, обеспечиваются формирование и ведение информационной модели объекта капитального строительства". Выбор технической базы для внедрения новой технологии должен быть оправдан технико-экономическим обоснованием. Подобными исследованиями занимаются зарубежные интеграторы. Данная заметка является вольным переводом исследования от независимого системного архитектора Томаса Поппельгаарда.

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

Новые предложения от компании HPE имеют расширенные возможности графического процессора с HPE Proliant m750 и предоставляют выделенный графический процессор от NVIDIA, адаптированный для видеокарт NVIDIA P1000 или NVIDIA T4. Это решение разработано для удовлетворения требований опытных дизайнеров, архитекторов и 3D-дженералистов.

Для организации удалённой работы с высокопроизводительными графическими приложениями HPE имеет 3 аппаратных решения в различных исполнениях по форм-фактору:

  • HP Moonshot 1500;

  • HPE Edgeline EL4000;

  • HPE Edgeline EL8000 / EL8000t.

VMware уже поддерживает установку на серверах без предустановленной операционной системы (bare-metal). Применительно к BIM, данный функционал требует внимательного рассмотрения. 4 недели назад HPEобъявило об официальной поддержке выпускаемого ПО VMware Horizon на bare-metal в HPE Moonshot.

Архитектура HPE Edgeline и VMware Horizon 8

HPE Edgeline и VMware Horizon показывают на рисунке ниже, что вы можете использовать VMware Horizon cloud, но он также полностью поддерживается инфраструктурой On-Premise VMware Horizon, если у вас есть для этого требования. Вы можете использовать тонкий клиент от HP 740, который является лучшим аппаратным тонким клиентом на рынке, который также может декодировать несколько мониторов 4K без каких-либо неудобств для пользователя. Самое замечательное в нижеприведенной архитектуре заключается в том, что вы можете иметь 4 физических рабочих станции в 1U, установленных в вашем центре обработки данных или ином расположении, без ущерба для пользовательской виртуализации. Сила bare-metal в том, что вы выжать максимум от возможностей оборудования. Функциональная схема такой системы показана ниже.

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

Коротко о HPE Proliant m750

В модели HPE m750 установлен 8-ядерный процессор AMD16-core с технологией Hyper-threading, что вдвое больше по сравнению с оборудованием, выпущенными за последние 7 лет. Это пригодится пользователям, которым требуется многопоточность, и тем, кто работает с HCI или виртуализацией. Платы также могут быть сконфигурированы с NVMe емкостью до 16 ТБ, что наводит на мысли о невероятно малом форм-факторе и о том, как мало энергии он потребляет (максимум 90 Вт). HP m750 также работает под управлением любой операционной системы и гипервизора. Также он использует iLO 5, используя который системный администратор имеет большее удобство в управлении сервером.

Коротко о NVIDIA T4

NVIDIA T4 - это однослотовый графический процессор от NVIDIA, использующий архитектуру Тьюринга от NVIDIA и являющийся частью серии Quadra. Этот графический процессор обладает возможностями RTX и адаптирован для трассировки лучей в реальном времени. Графический процессор имеет 16 ГБ выделенного кадрового буфера GDDR6, который требуется для высокопроизводительных САПР-приложений. Драйвера Nvidia Т4 могут быть использованы и в bare-metal, и на виртуальных машинах. В сочетании с NVIDIA vGPU буфер кадров может быть разделён на сегменты от 2 ГБ до 16 ГБ. Это означает, что вы можете запустить до 8 виртуальных пользователей. Идея в том, чтобы дать пользователю выделенную мощность m750 (5 ГГц CPU 8c/16c, до 16 ТБ NVMe, объём памяти 64 ГБ) и заставить его перейти в удалённый центр обработки данных. NVIDIA T4 требует лицензий vGPU как в установке bare-metal, так и в виртуализированной среде.

Тестирование HPE Edgeline m750 + GPU от Nvidia с VMware

Для тестирования были выбраны следующее оборудование: HPE m750 с процессором Intel Xeon и встроенным графическим процессором Intel P630, NVIDIA P1000. В качестве программного обеспечения, устанавливаемого на серверную платформу, использовались Windows 10 1909 и VMware Horizon 8.

Суммарный перечень программ, используемых в тестировании на быстродействие удалённого рабочего места:

  • Adobe Photoshop CC 2020 с дополнением Puget System;

  • Autodesk Inventor Professional 2020 с дополнением Inventor;

  • Furmark (OpenGL);

  • SPECworkstation 3;

  • SPECviewPerf3;

  • Basemark GPU;

  • Unigine Superposition.

Итог тестирования

Гибкость развертывания bare-metal (m750/P1000) или сборки с виртуализацией (m750/T4) измерялась в зависимости от требований приложения и по показателю изменения соотношения вычислений к загрузке графического процессора. Виртуализация на EL4000/m750/T4 оказалась экономически эффективным методом централизации и предоставления удаленного доступа для пользователей САПР малого и среднего бизнеса. Вы можете использовать либо 1-2 блока EL4000 настенного монтажа для небольшого числа пользователей (до 32), либо укладывать до 20 блоков в стойку для смешанного развертывания до 300 пользователей. Как оборудование будет располагаться в 19" стойке отражено на картинке ниже.

Для программ Autodesk Revit 2020, Autodesk Navisworks 2020, Autodesk Inventor 2020, Autodesk 3DSMax 2020 HP T740 обеспечивает лучшее отображение на 2-х 4K-мониторах при работе пользователя VMware Blast Extreme для m750 с NVIDIA P1000. У пользователя есть возможность работать с HP Thinpro с помощью клиента VMware Horizon. NVIDIA P1000 обеспечивает отличную работу с BIM-образцами средней детализации. Если клиентам требуются более крупные наборы данных, то NVIDIA T4 является предпочтительным выбором для использования с HPE m750. NVIDIA vGPU является предпочтительным выбором, если клиенты хотят масштабировать свой центр обработки данных и достичь высокой плотности пользователей виртуальных машин с максимальной производительностью.

В процессе тестирования наблюдалось изменение полосы пропускания с пиками до 30 Мбит/с на пользователя при изменении масштаба или вращении больших визуальных объектов в САПР-приложениях. Протокол VMware blast адаптируется и оптимизируется из коробки в последней версии с 2D/3D приложениями и не требует настройки оптимизации. При переходе от dual HD к dual 4K следует учитывать, что пропускная способность будет использоваться в 4 раза больше.

Рекомендации

Решение 1 предназначено для клиентов, которые хотели бы использовать процессор 5 ГГц для приложений с высокими требованиями производительности и для работы с 2D-графикой на отдельном процессоре. Например, AutoCAD, 4K video, Office365. Предлагаемый сервер вместе с VMware Horizon обеспечивает отличную производительность даже на мониторах 4K, где VMware обеспечивает аппаратную возможность декодирования как с процессором, так и с графическим процессором.

Решение 2 предназначено для клиентов, использующих базовые возможности САПР таких как AutoCAD, Revit, Navisworks, Inventor. Видеокарта NVIDIA P1000 обеспечивает отличную производительность с VMware Horizon и декодированием GPU из коробки на мониторах 4K.

Решение 3 предназначено для клиентов, которые использующих расширенные возможности работы с AutoCAD, Revit, Navisworks, Inventor. Виртуализация m750, сочетание технологии NVIDIA T4 с технологией vGPU, работающей на VMware vSphere - отличное решение, масштабируемое от 4 до 32 пользователей. Клиенты получают лучшую производительность за эти деньги, так как они могут эффективно использовать аппаратное обеспечение. Трассировка лучей в реальном времени также поддерживается NVIDIA vGPU но для более высоких рабочих нагрузок рекомендуется использовать большие фреймбуферы.

Решение 4 предназначено для клиентов, использующих высокопроизводительные приложения, такие как Autodesk VRED, Maya, Arnold, 3DSMax или Dassault Catia. Решение полностью поддерживает трассировку лучей в реальном времени, поскольку графический процессор NVIDIA T4 способен обеспечить эти возможности. Это решение также предпочтительно, если клиенты хотят использовать VR-решения, такие как NVIDIA CloudXR, где они могут объединить его с VMware Horizon.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru