Как сделать рейд на сервере supermicro

Обновлено: 08.07.2024

Этот раздел адресуется тем, кто планирует систему со скоростным хранилищем большой емкости. Когда требуемый объем содержит группу NVMe SSD, объединенных в RAID массив.
Рассмотрим варианты объединения NVMe SSD в RAID и производительность каждого решения.
Доступны четыре варианта построения системы:
— программный средствами ОС;
— программно-аппаратный Intel VROC;
— аппаратный контроллер Broadcom MegaRAID;
— программно-определяемое хранилище (SDS).

Сценарии использования накопителя или массива NVMe SSD накопителей приведены в отдельной заметке.

Варианты строительства RAID массива из накопителей NVMe существенно различаются по стоимости реализации и производительности.

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

Максимальную скорость NVMe накопители показывают при непосредственном подключении к хост-контроллеру.

Однако, в реальной жизни организациям чаще требуется основное хранилище с защитой от потери данных. А это значит — RAID1, 5, 6, 50, 60.

Итак, смотрим плюсы-минусы вариантов, приняв во внимание предыдущие рассуждения об требуемом уровне RAID.

Показатели производительности подсистемы NVMe

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

В качестве показателей производительности для NVMe SSD и подсистемы NVMe в целом принят ряд метрик, показывающих скоростные характеристики для различных сценариев нагрузки (параметры и методики их измерения описаны в спецификации SNIA):
— IOPS (Input/Output Operations Per Second) — количество операций ввода/вывода в секунду. Это показатель скорости системы на случайных коротких запросах. Он зависит от размера блока, внутреннего устройства накопителя и настроек хост-контроллера;
— средняя и максимальная задержка передачи. Время, затраченное подсистемой хранения на получение запроса и подготовку ответа. Во многом определяется внутренним устройством контроллера накопителя. Средняя задержка замеряется на блоках трех размеров (8KiB, 4KiB, 0.5KiB) и в трех соотношениях чтение/запись (100/0, 65/35, 0/100) при глубине очереди =1;
— пропускная способность системы. Показатель скорости последовательного чтения/записи. Измеряется на операциях с блоками большого размера — 128k и 1m. Этот параметр больше относится к тестированию накопителей и показывает максимальную скорость выдачи последовательных данных без ограничений со стороны интерфейса. В тестах пропускная способность рассматривается с точки зрения влияния на нее программного обеспечения.

Отдельный NVMe SSD

Нам нужна отправная точка. Какая-то печка, от которой можно плясать.

В таблице измерение IOPS 800GB Intel DC D3700 Series накопителя.
Значения IOPS убывают почти пропорционально размеру блока передаваемых данных (391 000 — 1 700). Генерируемый при этом поток данных, который является произведением этих величин, остается, практически, постоянным.
Динамика кривой убывания IOPS при увеличении доли запросов на запись (391 000 — 84 000) менее крутая, но приводит к снижению показателя в 4,6 раза. Это объясняется внутренней логикой и процессами чтения/записи собственно накопителя SSD и к интерфейсу не имеет отношения.

Block size / R/W	0/100	5/95	35/65	50/50	65/35	95/5	100/0
4k	84 018	91 394	117 272	133 059	175 087	281 131	390 969
8k	42 603	45 736	58 980	67 321	101 357	171 317	216 551
16k	21 619	22 835	29 704	33 821	52 553	89 731	108 347
32k	10 929	11 322	14 787	16 811	26 578	47 185	50 671
64k	5 494	5 672	7 343	8 286	13 130	23 884	27 249
128k	2 748	2 805	3 618	4 295	6 507	11 998	13 631
1m	352	355	451	685	830	1 574	1 703

Для более наглядного представления, данные выведены в диаграмме:

IOPS одиночного NVMe накопителя

Задержка также зависит от размера блока и соотношения Чтение/Запись, но масштаб изменений значительно меньше.

Средняя задержка накопителя 800GB Intel DC D3700 Series в зависимости от размера блока и доли запросов на чтение в миллисекундах:

Block size/ R/W	100/0	65/35	0/100
4k	0,027	0,072	0,099
8k	0,030	0,093	0,122
16k	0,047	0,137	0,164

Средняя задержка одиночного NVMe накопителя

Максимальная задержка в миллисекундах:

Block size/ R/W	100/0	65/35	0/100
4k	1,510	4,715	6,985
8k	1,409	4,312	7,000
16k	1,106	4,644	7,007

Пропускная способность подсистемы с одним NVMe SSD:
1MB последовательная запись — 634 MBps.
1MB последовательное чтение — 1707 MBps.
128kB последовательная запись — 620 MBps.
128kB последовательное чтение — 1704 MBps.

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

Группа из 12 NVMe SSD (JBOD)

Еще одна отправная точка — несколько накопителей не объединенных ни в какой массив. Она нужна для сравнения производительности. JBOD — группа накопителей без чередования (в отличие от RAID0), в котором единое логическое пространство распределено по жёстким дискам последовательно.

Сравнительные результаты по показателю IOPS для одного NVMe SSD и группы из 12 приведены в таблице и показаны на диаграмме ниже:

Чтение/запись 4k	0/100	5/95	35/65	50/50	65/35	95/5	100/0
12xNVMe	1 363 079	1 562 345	1 944 105	2 047 612	2 176 476	3 441 311	4 202 364
1xNVMe	84 018	91 394	117 272	133 059	175 087	281 131	390 969

Производительность одного и двенадцати NVMe SSD, IOPS для операций блоками 4k

Пропускная способность NVMe подсистемы из 12 накопителей практически линейно увеличивается пропорционально их числу:
1MБ последовательная запись — 8612 MBps.
1MБ последовательное чтение — 20481 MBps.
128Kб последовательная запись — 7500 MBps.
128Kб последовательное чтение — 20400 MBps.

Программные RAID средствами ОС и файловой системы

Стоимость решения: низкая (бесплатно).
ОС: Linux.
Производительность: приемлемая (RAID0, преимущественное чтение), невысокая-низкая (RAID5, 6, высокая доля записи).
Применение: хранилище временной информации, кэш системы, основное хранилище небольшой емкости с защитой зеркалом (RAID1, RAID10).

Производительность программных реализаций RAID массива рассмотрена в заметке «Сравнение производительности программных RAID«.

Решения, построенные на утилите mdadm операционной системы Linux и на встроенных средствах файловой системы ZFX самые дешевые. По производительности только RAID0 mdadm можно рекомендовать для использования в качестве кэш или временного накопителя и RAID6 mdadm для основного хранилища с 90-100% долей операций чтения.

Решение на Intel VROC

Стоимость решения: низкая.
ОС: Linux, Windows.
Производительность: средняя (RAID0, 1, 10), невысокая (RAID5).
Применение: хранилище временной информации, кэш системы, основное хранилище.

Это не очень дорогое (15 — 30 тысяч рублей) программное решение на уровне драйвера. Позволяет формировать RAID0, 1, 10 (стандартная конфигурация) или в том числе RAID5 (премиум).

На диаграмме ниже представлены результаты тестов системы из 24 NVMe SSD Ultrastar DC SN620, объединенных в RAID5 при помощи Intel VROC.

IOPS для 24 NVMe SSD Ultrastar DC SN620, объединенных в RAID5 при помощи Intel VROC, 4k

Показатель IOPS очень резко (в восемь раз) падает при соотношении Чтение/Запись 90/10. Еще в три раза — при увеличении доли записи до 30%.

Еще одно исследование производительности NVMe системы представлено на StorageReview
Испытывалась система с восемью Intel DC P4510 NVMe SSD под управлением Intel VROC.

RAID массив на SAS/SATA/NVMe контроллере

Стоимость решения: невысокая.
ОС: Linux, Windows.
Производительность: сравнима с решением на VROC.
Применение: основное хранилище с защитой (RAID5, RAID6).

Контроллеры Broadcom описаны в разделе Оборудование. MegaRAID допускает прямое подключение до 4 накопителей или большее количество через коммутатор. Его имеет смысл ставить в систему в двух случаях: 1) сервер не поддерживает NVMe интерфейс; 2) не хочется забирать мощности центральных процессоров для непрофильной загрузки.

Для реализации решения помимо собственно контроллера (30 — 70 тыс. руб.) требуется корпус или корзина в корпус для установки SSD выбранного форм-фактора (как правило, U.2, но есть решения даже для M.2 накопителей — корзины ICY DOCK, например) и набор соответствующих кабелей.

Тестов производительности контроллера Broadcom в паре с NVMe накопителями практически не опубликовано. Мы представляем сравнительные тесты с VROC: Сравнение производительности Tri-Mode Broadcom MegaRAID 9460-16i и Intel VROC.

Программно-определяемое хранилище (SDS).

Стоимость решения: высокая.
ОС: Linux, Windows.
Производительность: высокая.
Применение: Масштабируемое основное хранилище большой емкости с защитой данных от потери. Высокоскоростное хранилище для группы серверов.

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

SDS использует мощности современных процессоров и распределение нагрузки между узлами. За счет этого SDS может показывать производительность, значительно превышающую возможности аппаратных дисковых контроллеров.
С учетом того, что аппаратных NVMe RAID контроллеров, мягко говоря, немного, приходится меряться с тем — что есть.

Есть сравнительные тесты RAIDIX ERA компании Рэйдикс с программными RAID на сервере с 12х Intel DC D3700 SSD (материалы Flash Memory Summit 2018)

IOPS для системы из 12шт Intel DC D3700
RAIDZ (аналог RAID6 в файловой системе ZFS)
RAID6 средствами mdadm Linux
RAID5 средствами mdadm Linux
RAID6 средствами RAIDIX ERA
Суммарная предельная скорость 12 накопителей — аппаратный предел

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

На следующей диаграмме — сравнение того же RAIDIX ERA с Intel VROC на сервере с 24х Ultrastar DC SN620 3.2TB объединенных в RAID5.

IOPS для 24х Ultrastar DC SN620 в RAID5
RAIDIX ERA RAID5, 4k
Intel VROC RAID5, 4k

Некоторые тесты производительности различных решений на NVMe SSD приводятся в NVMe хранилище. Тесты производительности.

30.08.2019

VyacheslavK

Linux, Железо

комментариев 19

Не так давно, мне удалось поработать с новыми для меня серверами Supermicro удаленное управление которыми осуществляется с помощью интерфейса IPMI. В данной статье я постараюсь раскрыть основные моменты в настройки IPMI на серверах Supermciro, покажу основные пункты меню интерфейса IPMI, а также расскажу о дополнительных утилитах, командах и способах мониторинга сервера с помощью ipmi.

IPMI (Intelligent Platform Management Interface) — интеллектуальный интерфейс управления платформой, предназначенный для автономного мониторинга и управления функциями, встроенными непосредственно в аппаратное и микропрограммное обеспечения серверных платформ. (информация взята с официального источника). IPMI реализуется в виде отдельного контроллера сервера, который не зависит от операционной системы, BIOS, CPU севера и позволяет удаленно управлять физическим оборудованием.

Первичная настройка IPMI консоли и знакомство с интерфейсом

Настройка IPMI начинается с настройки IP адреса интерфейса, который нужно указать в BIOS. Если сервер установлен в офисе, это может быть серый IP-адрес, если же ваше оборудование размещается в ДатаЦентре, то наверняка вы используете белый статический IP-адрес.

На серверах Supermicro в BIOS можно попасть, нажав кнопку “Del” при загрузке сервера, я не буду заострять на этом внимание и сразу перейду к интерфейсу самого BIOS.

Как видите на скриншоте, я вошел в пункт меню IPMI и активировал возможность конфигурации Lan для интерфейса (Update IPMI Lan Configuration=Yes, Configuration Address Source = Static), указал IP-адрес, маску подсети и основной шлюз.

Применить настройки можно нажав кнопку F4, после чего произойдет перезагрузка сервера.

Если вы все сделали правильно, то введя в браузере, указанный для интерфейса IPMI IP, у вас откроется авторизация:

Теперь пройдем по основным моментам.

При покупке нового сервера, в IPMI уже создан пользователь ADMIN с паролем ADMIN, именно с этими данными мы и авторизуемся. Я всегда рекомендую создавать нового пользователя, а стандартного удалять или менять у него пароль, так оставлять такой логин и пароль, крайне небезопасно. Создать нового пользователя или поменять пароли/привилегии у текущих, можно в меню Configuration -> Users.

Рестарт интерфейса IPMI можно сделать из меню Maintenance -> Unit Reset.

Монтирование iso образа ОС для установки на сервер выполняется в меню Virtual Media -> CD-ROM Image.

У меня iso образы ОС хранятся на сервере Samba в той же подсети что и интерфейсы IPMI серверов. Я указываю адрес сервера Samba, путь к образу установочному ISO с ОС, после чего монтирую ISO образ и приступаю к установке операционной системы.

Удаленную графическую Java консоль сервера (KVM-over-IP) можно открыть через Remote Control -> Console Redirection.

Консоль в целом удобная, но после установки ОС, для работы с сервером я обычно использую ssh клиенты. Иногда есть моменты когда, это невозможно, например если у вас не работает или еще не настроена сеть на сервере или же имеются какие-то проблемы с доступом. Именно тогда на помощь и приходит Remote Console.

Никаких отдельных настроек в самой консоли делать не нужно, хочу лишь добавить, что она имеет встроенную клавиатуру, которую можно вызывать из меню Virtual Media -> Virtual Keyboard.

Совет. После продолжительной работы с серверами SUpermicro, я обнаружил один неприятный баг. После установки операционной системы Centos 7 и установки KVM на нее, пропадает возможность использовать Remote Console. Пока сервер в процессе загрузки, консоль отвечает и можно пройти в Bios или увидеть загрузку ядра ОС. Но как только операционная система загрузилась, видео в консоли пропадает. Путем экспериментов мне удалось победить этот баг. Нужно в загрузки ядра добавить параметр загрузки nomodeset. Для этого после установки ОС нужно выполнить команду:

grubby --args "nomodeset" --update-kernel /boot/vmlinuz-`uname -r`

После этого, Remote Console работает исправно.

Управление сервером через утилиту IPMICFG от SuperMicro

Для управления серверами через IPMI компания SuperMicro разрабатывает собственную утилиту IPMICFG.

Распакуем скачанный файл в директорию которой находимся:

Далее создаем символическую ссылку для удобства запуска утилиты:

ln -s /root/IPMI*/Linux/64bit/IPMICFG-Linux.x86_64 /usr/local/sbin/ipmicfg

Теперь мы можем запускать утилиту с помощью команды ipmicfg (символической ссылки). Рассмотрим базовые возможности утилиты ipmicfg.

Если выполнить команду ipmicfg -help мы получим список всех возможных параметров утилиты.

Разберем основные команды:

• ipmicfg -help – полная справка по утилите;
• ipmicfg -m – просмотр текущего IP и mac-адреса для IPMI;
• ipmicfg -k — просмотр маски подсети;
• ipmicfg -g – просмотр заданного шлюза;
• ipmicfg -fd — сброс IPMI к заводским настройкам;
• ipmicfg -user list – просмотр созданных пользователей и их привилегий.

Вы можете изменить IP адрес, маску и шлюз интерфейса IPMI:

• ipmicfg -m 192.168.1.200
• ipmicfg -k 255.255.255.0
• ipmicfg -g 192.168.1.1

Создать нового пользователя IPMI и его пароль:

ipmicfg -user add

С помощью утилиты делаем следующее:

ipmicfg -user add 6 test 123456 4

Тем самым мы создали пользователя test с паролем 123456 и привилегиями администратора.

Список пользователей IPMI и их привилегии в системе можно вывести командами:

• ipmicfg -user list
• ipmicfg -user help

Как уже видите на скриншоте, пользователь test создан.

Чтобы изменит (сбросить) пароль пользователя IPMI, исползайте команду:

ipmicfg -user setpwd

И приведу еще пару примеров использование данной утилиты:

• ipmicfg -hostname [value] — задать hostname для ipmi интерфейса;
• ipmicfg -r — перезагрузка IPMI.

Мониторинг железа на сервере SuperMicro через IPMI и утилиту IPMICFG

Мониторинг сервера SuperMicro через IPMI

Через IPMI мониторить температуру и работу железа сервера SuperMicro довольно просто. Полная информация о железе сервера содержится в пункте System -> Hardware Information.

Информацию по состоянию процессора, оперативной памяти и вентиляторах, можно посмотреть перейдя во вкладку Server Health -> Sensor Readings.

Для удобства просмотра, можно менять категории отображения датчиков, например, температуры:

Или датчики напряжения:

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

Мониторинг с помощью утилиты ipmicfg

Проверка состояния блоков питания:

Посмотреть температуру процессора можно командой:

ipmicfg -nm oemgettemp

Так же можно проверить в каком режиме работают вентиляторы и изменить режим, если это необходимо.

Проверка состояния и конфигурации вентилятора

Изменение режима работы кулера: ipmicfg -fan Например, ipmicfg -fan 3

Информация о версии и прошивке IPMI:

И посмотреть все сенсоры можно командой ipmicfg -sdr

При выводе мы видим, что есть дополнительные столбцы, в которых отображена информация о лимитах нижнего и верхнего пределов.

Так же существует еще не малое количество утилит, которые можно использовать для мониторинга и автоматизировать этот процесс, например, с nagios. В данный момент заострять на этом внимание мы не будем, так как цель статьи рассказать основные моменты в работе с IPMI. Если вас заинтересует тема мониторинга, вы можете оставить свои пожелания и возможно в дальнейшем мы осветим и эту тему. Надеюсь, данная статья окажется для вас полезной!

Растущая потребность в мерах без­о­пас­нос­ти де­кла­ри­ру­ет вы­со­кие тре­бо­ва­ния к тех­но­ло­гии до­с­ту­па по IPMI. В пред­ы­ду­щем ма­те­ри­а­ле бы­ли рас­смот­ре­ны ап­па­рат­ные ре­ше­ния, ре­а­ли­зу­ю­щие ин­тел­лек­ту­аль­ный ин­тер­фейс уда­лен­но­го уп­рав­ле­ния плат­фор­ма­ми. Ком­па­ния Su­per­mic­ro пред­ла­га­ет также ряд про­грам­мных про­дук­тов, ко­то­рые гар­мо­нич­но до­пол­ня­ют эти ре­ше­ния.

Главный среди них — утилита IPMIView. Фак­ти­че­ски — это про­г­рам­мный про­дукт из не­сколь­ких свя­зан­ных при­ло­же­ний, фор­ми­ру­ю­щих се­те­вое под­клю­че­ние и гра­фи­че­ский ин­тер­фейс для до­сту­па к ин­фра­ст­рук­ту­ре на ба­зе обо­ру­до­ва­ния от Super Micro Com­puter. Дру­ги­ми сло­ва­ми, IPMIView — это за­щи­щен­ный веб-ин­тер­фейс по уп­рав­ле­нию сер­вер­ным хо­зяй­ст­вом без ис­поль­зо­ва­ния сто­рон­не­го бра­у­зе­ра. Оце­ним его пре­и­му­ще­с­т­ва в срав­не­нии с тра­ди­ци­он­ным под­хо­дом.

Несколько слов про IPMI

Принцип работы ин­тел­лек­ту­аль­ного ин­тер­фейса уда­лен­но­го уп­рав­ле­ния плат­фор­мой, или In­tel­li­gent Plat­form Ma­na­ge­ment In­ter­face (IPMI) основан на захвате со­дер­жи­мо­го ви­де­о­бу­фе­ра про­цес­со­ром Base­board Man­a­ge­ment Con­t­rol­ler (BMC). На плат­фор­мах Super­micro для этого ис­поль­зу­ет­ся про­цес­сор AST2500 от Aspeed Technology, раз­ра­бо­тан­ный на базе ар­хи­тек­ту­ры ARM11 или его более ран­ние ре­а­ли­за­ции.

Па­рал­лель­но, BMC-контроллер собирает данные сис­тем­но­го мо­ни­то­рин­га и фор­ми­ру­ет до­ступ к шинам уп­рав­ля­е­мой плат­фор­мы. Сервис, который он пред­ос­тав­ля­ет, кар­ди­наль­но отличен от простого доступа к консоли: ре­а­ли­зация KVM-over-LAN ста­но­вит­ся не­за­ви­си­мой от про­г­рам­мной среды уда­лен­ного сер­ве­ра и обес­пе­чи­ва­ет уп­рав­ле­ние, начиная с ранних этапов POST (доступ к на­с­т­рой­кам UEFI, ра­бо­та с за­гру­зоч­ны­ми уст­ро­й­ст­ва­ми etc.). Это до­сти­га­ет­ся за счет ис­поль­зо­ва­ния ши­ны USB для под­клю­че­ния вир­ту­аль­ных кла­ви­а­ту­ры, мы­ши и на­ко­пи­те­лей.

IPMI-интерфейс взаимодействия с BMC обеспечивает доступ к системам управления по сети либо через вы­де­лен­ный порт Dedicated LAN, ли­бо в со­вмест­ном доступе к одному из общих се­те­вых ре­сур­сов — Shared LAN. Это от­кры­ва­ет не­пло­хие пер­с­пек­ти­вы для бес­про­вод­но­го уп­рав­ления уда­лен­ным сервером — мо­биль­ное при­ло­же­ние Super­micro IPMI­View по удоб­ст­ву и эр­го­но­мике не оставляет шансов клас­си­че­ским бра­у­зер­ным тех­но­ло­гиям. Доступна и ве­р­сия для iOS-устройств, равная по фун­к­ци­о­наль­но­с­ти.

С чего начать?

Инсталляция IPMIView, если дело касается настольных систем, проста. Для ее выполнения не­об­хо­ди­мо на­ли­чие пред­ус­та­нов­лен­ной Java и за­пус­к приложения IPMIView20.exe от имени ад­ми­ни­ст­ра­то­ра. Дру­гих слож­но­с­тей нет. В частности, и потому что (в отличие от бра­у­зер­ной версии) нет необходимости заранее знать IP-адрес уда­лен­ной плат­фор­мы. Ути­ли­та IPMIView сделает все сама, нужно только сформировать запрос, пред­ва­ри­те­ль­но ука­зав сег­мент ис­ко­мой сети:

Утилита IPMIView корректно рас­по­з­на­ет тип BMC-контроллера. В данном слу­чае это про­цес­сор из выше упомянутого семейства AST2500, принадлежащий нашему стен­до­во­му серверу Supermicro X11SSL-F.

Управление и мониторинг

Опция IPMI Device Discovering дает возможность ин­с­т­ру­мен­таль­ной плат­фор­ме об­на­ру­жить все подлежащие над­зо­ру сер­ве­ры. Это удобно в тех случаях, когда тре­бу­ет­ся па­кет­ное уп­рав­ле­ние ком­пью­те­ра­ми. IPMIView пред­ла­га­ет груп­по­вые сце­на­рии мо­ни­то­рин­га серверных платформ с помощью Group Management:

Прелесть управления по IPMI — в доступе к ресурсам удаленного сервера на этапе, пре­д­ва­ря­ю­щем даже установки CMOS Setup системного UEFI BIOS. Мы спе­ци­аль­но ос­нас­ти­ли тестовую платформу Supermicro X11SSL-F RAID-кон­т­рол­ле­ром Avago 3108, чтобы про­де­мон­с­т­ри­ро­вать возможности по удаленной настройке его PCI BIOS.

BMC: перезагрузка

Сегодня никого не удивить удаленной пе­ре­за­груз­кой сервера, его вклю­че­ни­ем или от­клю­че­ни­ем. У не­по­свя­щен­ных, прав­да, возникают за­ко­но­мер­ные опасения — как кор­рект­но закрыть приложения (особенно, если речь идет о вир­ту­аль­ных ма­ши­нах), не потеряв данные? На этот случай в IPMIView есть изящный сце­на­рий — Graceful Shutdown.

Специалисты по безопасности в один голос твердят о том, что IPMI не стоит выставлять в открытую сеть не­смо­т­ря на все меры предосторожности: шифрование, парольный доступ и т.п. Но даже при доступе через VPN поль­зо­ва­тель мо­жет столк­нуть­ся с ситуацией, когда требуется перегрузить не сам сервер, а только его IPMI-подсистему. Функ­ция BMC Cold Reset — еще од­на силь­ная сто­ро­на про­грам­мно­го обес­пе­че­ния IPMI­View, ана­ло­гич­ная опции Unit Reset в уп­рав­ле­нии сер­ве­ром че­рез бра­у­зер (меню Maintenance).

Температурный режим и питание

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

А вот данные от основного и запасного блоков питания требуют пояснений. Меню PSU состоит из трех за­кла­док:

• информация, полученная по Power Management Bus (PMBus);
• информация о состоянии внутри блока питания (Field Replaceable Unit или FRU);
• информация о состоянии аккумуляторов в источнике бесперебойного питания (Battery Backup Power).

Если кому-то адреса сенсоров PSU покажутся занудным излишеством, их все же стоит взять на за­мет­ку для ис­поль­зо­ва­ния в мо­биль­ном при­ло­же­нии IPMIView.

Обновление ПО

В отличие от браузерной версии iKVM, утилита IPMIView ограничивает пользователя только обновлением ми­к­ро­ко­да BMC. Об­нов­ле­ние или восстановление поврежденного UEFI BIOS не входит в обязанности дан­но­го про­грам­мно­го про­дук­та.

Объяснение очень простое — прошивка BIOS возможна для владельцев OOB-ли­цен­зии, а утилита IPMIView рас­про­с­т­ра­ня­ет­ся бес­плат­но и не предполагает лицензирования.

И в заключение — о мобильном приложении

Самое время вспомнить о мобильном приложении. Ведь концепция удаленного доступа к управляемой плат­фор­ме ста­но­вит­ся куда более убедительной, если его можно осуществить с любого места и в любое время. Се­го­дня у смарт­фо­нов на этом поприще конкурентов нет. В силу того, что функциональность мобильного при­ло­же­ния богаче воз­мож­но­с­тей веб-интерфейса, который в узких рамках встроенного решения пока не го­тов пред­ло­жить даже адап­тив­ную вер­с­т­ку, преимущество anytime & anywhere подпитывается еще и опе­ра­ци­он­ным удоб­ст­вом. Но об этом в сле­ду­ю­щих пуб­ли­ка­ци­ях…

Серверная платформа Supermicro X11SSL-F
предоставлена компанией Onix

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

Затем появились SSD, или твердотельные накопители ( сокращённо они до сих пор называются “диски”, хотя там уже круглого ничего не осталось 🙂 ), скорость которых поначалу той же была хоть и выше, чем у механики, но всё равно “не радующей”, а надёжность вызывала сомнения (до сих пор большое количество айтишников уверены, что “SSD ненадёжные”), и эти SSD тоже по привычке запихивались в RAID-массивы. Однако “внезапно” стало проявляться, что далеко не всегда скорость итогового массива из SSD так же хорошо масштабируется, как если бы это был массив механических дисков, и тому есть ряд причин. Наиболее важные для нас минусы:

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

На снимке ниже: пример такого массива, собранного “неправильно”, формата RAID50, в котором 10 (десять) SSD. Причём в этом массиве “хорошо” себя показывает только чтение, и только крупными порциями (верхняя строчка Seq в колонке Read каждого из двух результатов). Запись даже крупными порциями (верхняя строчка Seq в колонке Write) показывает нам всего 142 мегабайта в секунду, а многопоточная запись пакетами по 4 килобайта (нижняя строчка 4K QD32 в колонке Write) даёт нам всего около 16 мегабайт в секунду.

Исключительно для понимания: одиночный диск из состава этого массива имеет показатели записи минимум вдвое выше тех, что показал массив из десяти таких дисков. А поскольку этот массив был предназначен для высокопроизводительной смешанной (чтение+запись) нагрузки сервера 1С/СУБД — очевидно, данный массив для этих целей можно считать непригодным.

Для базы данных 1С или данных кластера 1С “страйп” в отдельных случаях когда очередей к диску больше порога возможностей. Тут есть одно очень важное уточнение. Порог определяется не чьим-то мнением, а фактическими числовыми показателями времени отклика диска и числа очередей к диску, записанными за длительный период, который можно считать показательным для оценки. Т.е. решение принимается не потому, что вы заранее думаете “надо сделать рейд потому, что это так кажется правильным”, а потому что обладаете собранными с тестового стенда или даже лучше с продуктива данными, подтверждающими что с текущей нагрузкой диск не справляется именно из-за слишком большого числа одновременных операций чтения/записи. Если вы видите, что ваш диск выдерживает условно 128 одновременных активных транзакций (ну или пропорциональное им количество очередей) без потерь по времени отклика, а далее начинает выходить за рамки (ну пусть условно для примера порог будет 30 мс), то при росте числа активных транзакций ну скажем до 180, можно говорить об обоснованности наращивания дисковой подсистемы (например, добавления в RAID 0 второго диска). Ну и так далее. Также надо помнить, что в случае MS SQL Server и наличия квалифицированного админа — есть смысл не RAID 0 собирать под базу данных, а подключить те же два диска из примера отдельно, поместив на каждый по файлу базы данных (поровну распределив размер базы данных на каждый файл). В этом случае MS SQL Server на отдельных операциях может выдавать большую производительность, чем RAID 0.
Большинству админов лень что-либо замерять, и оборудование заказывается “на глаз”. Разумней в этом случае брать минимум дисков, и только по фактической нехватки мощности докупать диски. Если админ “отмазывается” тем, что у него бюджет на год и надо покупать сразу всё, тогда гораздо полезней всё равно сначала закупить один “нужный” диск, замерить практическим экспериментом “сколько он выдержит”, и только после этого составлять калькуляцию на год.

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

Временные данные 1С или СУБД, а также вторичные данные, потеря которых не остановит работу компании.

Сюда могут включаются например:
— папка кластера 1С, где лежат логи журналов регистрации и файлы полнотекстового поиска 1С (если он используется);
— папка temp профиля пользователя, под которым запущена служба сервера 1С;
— файлы и логи служебной базы tempdb сервера MS SQL (а если у вас PostgreSQL — то это например папки логов pg_clog/pg_xlog/pg_wal/pg_xact, в зависимости от версии постгреса).

Вышедшие NVMe PCIe 4.0 диски типа intel D7-P5600 настолько быстры, что современные сервера на RAM-дисках не дадут сколько-то значимого преимущества, но при этом обладают недостатками надежности при отключении питания. Для малого бизнеса есть бюджетные диски типа Samsung 980 Pro.

Основные данные и файлы лицензирования ключей 1С.
Надежность дисков серии intel p3700, p4800 проверена временем. На таких дисках можно смело размещать основные данные. Вероятность выхода из строя таких дисков меньше чем блока питания к примеру. На некоторых проектах такие диски успешно работают более 5 лет.

Что же касается надёжности — тут наша позиция такая: массив RAID даёт шанс пережить выход из строя условно 1-2 носителей из его состава. Это конечно замечательно, но если мы начинаем изучать, что же на самом деле может “сломаться” (не в порядке параноидального бреда, а по наблюдениям нас и наших клиентов) — выясняется, что это лишь малая часть айсберга! Выходят из строя разные комплектующие внутри сервера, выходят из строя компоненты сети, может “приехать” неудачное обновление Windows или 1С, может “упасть” сервер 1С, может “сломаться” база 1С, может “прилететь шифровальщик”. Будет ли откровением то, что ни от какого из этих факторов риска RAID-массив нас не спасёт? Здесь уже надо говорить о сценариях резервирования, отказоустойчивости и катастрофоустойчивости (но об этом в другой раз).

Почему SSD не “настолько же ненадёжны, как механические диски”: в механическом диске были вращающиеся с бешеной скоростью пластины, были яростно летающие над ними на микронной высоте головки, всё это жужжало, вибрировало, грелось, сильно боялось тряски или сторонних вибраций, внезапных отключений электричества и вообще было нежным и хрупким даже в довольно крепком серверном исполнении. Современные серверные SSD — скучная плата без движущихся деталей, возможно (и даже крайне желательно) с увесистым радиатором (а кто-нибудь может и вентилятор сверху “приколхозить”), по сути там внутри есть флэш-память и контроллер. Внутри SSD есть расходуемый ресурс, а именно флэш-память, которая при записи неизбежно изнашивается, и этот параметр крайне желательно контролировать хотя бы раз в месяц, но если к подбору SSD подошли правильно и вдумчиво — SSD как минимум переживёт период продуктивной эксплуатации, а с очень большой вероятностью доживёт и до полного морального устаревания сервера. Вся остальная электроника внутри — условно такая же, в остальном сервере, и выход из строя хоть и может произойти, но примерно с такой же вероятностью, как у любой другой компоненты серверного оборудования.

В итоге: для сервера 1С/СУБД RAID-массив из NVMe SSD в большинстве случаев не является необходимым ни для ускорения, ни для повышения надёжности.

Читайте также:

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