Продолжу серию: Импортозамещение и параллельный импорт без глянца и одновременно - Есть ли абсолютный ноль, который невозможно достичь?

Сначала разберу одну экспертную(ТМ) статью, потом пройдусь по некоторым особенностям, упущенным в первой статье про импортозамещение, но которые никак нельзя пропускать. И нет, это не про связку FreeBSD + ZFS + bhyve = импортозамещение.

(пометка для модераторов: текст отличается низким техническим качеством, не содержит рассказов про здоровье и эльбрус, НЕ НАДО ЕГО ПЕРЕМЕЩАТЬ ИЗ ЧУЛАНА)

Часть 1. Критические заметки к статье Обзор серверов Gooxi SL101. Опыт установки и первые впечатления.

Начало статьи хорошее:

Наш системный инженер Владимир Емельянов и его коллега – ведущий инженер по виртуализации рассказали мне о серверах Gooxi и поделились первыми впечатлениями.

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

Итак:

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

Но ?? у вас же в конфигурации заявлена Network card: 2x Intel 710 (10Gb) – карта, конечно, та еще для 2022 года, но ждать от нее какой-то серьезной не совместимости? Инженеры же проверили карту и версию микрокода (прошивки) на совместимость? ВЕДЬ ПРОВЕРИЛИ?

SSD: 2x 480GB SSD SATA 2.5"

– но зачем? Для Vmware (если вы не храните логи прямо на локальном диске) это избыточно. И у дисков еще есть модель .. и да, это иногда критично.

В комплектацию входят удобные рельсы с защелками без болтов

Судя по описанию, «руки» (Cable Management Arm  - CMA) нет, поэтому перед выдвижением сервер все равно придется полностью отключить. Ниже в комментариях есть ссылка на статью Джета, где так и написано – ни руки, ни кабель менеджмента нет.

поэтому подключение здесь не такое удобное, как с Blade-серверами, которые просто подключаются в слоты, а кабели соединяются напрямую с корзиной.

У блейд-корзины коммутаторы (или просто платы проброса портов, в зависимости от конфигурации) минимум на то же число портов, сколько слотов под сами лезвия на корзине. Другое дело, что при установке в блейд корзину – коммутаторов, иногда можно обойтись меньшим числом аплинков. Какие кабели используются между блейдом и его backplane – я не знаю, ни разу не видел чтобы были «кабели».

Совместимость с платформой VMware отличная. Специалисты тестировали стандартный ISO-образ ESXI 7.02, и установка кастомных драйверов не потребовалась.

Это точно статья от инженеров виртуализации?

Статья вышла 15 сентября 2022, а ESXi 7.0 Update 2 Build Number 17630552 вышел полтора года назад – 9 марта 2021 года. На момент написания статьи для исходной 7.0 u2 вышло 9 (12) патчей и актуальной  версией была ESXi 7.0 Update 3g Build Number 20328353

Понять, что же имелось ввиду под «установкой кастомных драйверов» тоже сложно – начиная с версии 7 (вышедшей 2.5 года назад, в апреле 2020), никаких Linux custom driver больше нет, а Community Networking Driver for ESXi- не такой уж и большой. Вендорские VIB ? Так их есть не так много у каких вендоров. Список тут, без регистрации и смс.

Еще до установки можно НУЖНО было посмотреть в VMware Compatibility Guide и увидеть там Ethernet Controller X710 for 10 Gigabit backplane, и заодно почитать предупреждения, включая, но не ограничиваясь статьей Hosts May Disconnect from vCenter when using a X710 or XL710 or X722 family card when LLDP is enabled. (53749)

Минусом еще стало и отсутствие уникальных UUID идентификаторов BIOS. Все оборудование имеет одинаковый идентификатор, что вызывает неудобства при мониторинге и работе с сервером через vCenter.

Всего лишь неудобства? А какие?

Vmware пишет немного иначе:

our ESXi’s operating system expects that each server will have a unique System Universally Unique Identifier (UUID).. which can lead to VMFS corruption if multiple hosts with the same System UUID share the same VMFS volumes, as there are dependencies in the storage stack that uses the System UUID for operations like VMFS journaling and VMFS Heartbeat operations.

Статья  84280 , статья 2000476

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

Это вроде не наддутый Ваз, чтобы поршни отлетали, да и других оснований для тук тук тук нет, это ж не сервер на все 4 сокета. Нагрузка вообще не нужна – иногда нужно просто время – от недели до пары тройки лет.  Опять же, КАКАЯ нагрузка? CPU + RAM ? Инженеры никогда не слышали о проблемах при работе сетевого стека или работе с СХД?

 внутри каждого сервера запущен процесс нагрузки процессора и оперативной памяти на 100%.

Неужели жалко написать, какой именно ?

Однако админы, как цифровые творцы, могут использовать кастомные разработки и исправить это, например, используя утилиту IPMI tool.

То есть никаких HPE Smart Update Manager (SUM) / Lenovo UpdateXpress / Supermicro Update Manager (SUM) / Huawei Smartkit / HPE SPP / Dell Update Package / Dell Server Update Utility (SUU) / Dell OpenManage Enterprise нет.

Но тут авторы опять пропускают интересный момент – авторизацию. Я про это напишу чуть ниже, и это очень неприятно. Причем, неприятно вдвойне – и сама проблема, и что авторы это упускают.

Обеспечивается сбалансированная нагрузка, что позволяет уменьшить износ серверов.

Износ чего именно? На серверах 2 SSD диска (правда, опять отмечу жадность автора статьи – модель диска не указана), нагрузка «меньше 50%», значит про VFFS речь не идет, а раз используется 7.0 ,то и про vFlash Read Cache тоже не стоит вспоминать.

Вентиляторы изнашиваются ? Память?

Главный плюс от статьи – наличие в комментариях ссылки на статью Тестируем китайские rack-серверы Gooxi. Правда, обещанного:

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

Не нашлось.

Часть 2.  Мой опыт.

Еще раз: модели серверов все еще не будет, как и точных данных, но кто сталкивался – догадается. Но это не точно.  ДАЛЬШЕ ПРО ДРУГИЕ СЕРВЕРА. НЕ Gooxi.

BIOS. Практика показала, что найти и скачать свежий BIOS к серверам можно, но дальше - все очень плохо. Руководство по проведению обновления доступно, но написано настолько криво, что пришлось читать 3 раза и уточнять у коллег. До SPP этому решению очень далеко. Документация на сам BIOS и настройки в нем тоже не поражает воображение.

IPMI. Он в системе есть, и он даже работает, и работает неплохо. Есть ряд нюансов, а именно:

  • Смена имени хоста в IPMI возможна, но выполняется слегка нетривиально, хотя и из GUI.

  • Основные настройки более-менее понятны, но часть настроек жестко зашита. Это, в частности: настройки порта для Syslog, служебные пользователи (Administrator может быть переименован, но не может быть удален), жестко зашитые роли, причем роли с правами Monitor / Read only отсутствует.

  • Списка прав предопределенных ролей в документации нет.

  • Документация по части настроек есть, по части настроек нет.

  • Часть настроек и в руководстве, и в встроенной справке выглядит примерно так: Snu snu. Вы можете выбрать для себя: включить Snu snu целиком, включить Snu snu не целиком, не включать Snu snu. Такие настройки включают в себя варианты с ipmitools, доступом из IPMI до BIOS, etc.

Иногда настройки IPMI слетают. Не знаю, почему так.

 Есть экспорт настроек BIOS в файл, но импорт из файла в BIOS - у меня не получился.

Какие-то данные можно получить через ipmitool (после того, как включите прием, см. выше про Snu snu).

IPMI умеет писать письма, отчитываться в Syslog и SNMP – но делает это по узкому списку событий. При этом событие «кто-то подбирает пароль» - в список просто так отправляемых событий не входит (блокировка есть). Сам шаблон извещения про события сложно читаем, и не настраивается. Есть еще DMTF Redfish , но эту рыбу пока не все едят. Можно вытаскивать System Event Log (SEL) в ELK, но это если у вас руки не только про статьи про пользу импортозамещения заточены.

Внутренний мониторинг (IPMI) очень беден. Можно получить сообщение «что-то не так», при всех зеленых индикаторах. Более серьезные сбои, типа CPU/RAM – система показывает с точностью до разъема, а больше и не надо. С NVME все странно. SFF-TA-1001 / OCuLink - MiniLink SFF-8611 работает, но определение NVME работает не со всеми накопителями.

Работа с обновлениями микрокода «всего». Проще обновить микрокоды карт в своем стендовом сервере, чем внутри.

Работа ОС. ПОКА сбоев не было, но все оборудование входит в Compatibility list, микрокоды обновлены.

PS Извините если кому не ответил в комментариях  в соседних статьях – оказывается, тема "Подорожник в 21 веке или немного про бинтики"  – политическая, и карается месяцем на киче, хотя описывает развитие службы крови и кровезаменители. Про говно и личностный рост можно писать, про сдачу крови - нет.

Комментарии (1)


  1. tvr
    07.11.2022 20:44
    +1

    Часть настроек и в руководстве, и в встроенной справке выглядит примерно так: Snu snu. Вы можете выбрать для себя: включить Snu snu целиком, включить Snu snu не целиком, не включать Snu snu.

    Ох уж эти импортозаместители — забыли таки главный пункт:
    Death By Snu Snu