Ползут три черепашки.
Первая говорит, что перед ней никого нет, а сзади неё — две черепашки.
Вторая говорит, что впереди неё — одна черепашка, и сзади ещё одна.
И третья тоже говорит, что впереди неё одна, и сзади одна.
Как такое может быть? И при чем тут архаизация и импортозамещение ?
Для лиги лени: у автора наблюдается локальное повышение температуры, вплоть до точки обугливания стула.
Продолжу обзор «что не так с импортозамещением и ИТ сообществом».
Часть 1 15 лет развитию СПО в России
Часть 2 Дороги Анны Фирлинг, и куда они ведут
Часть 3 The СПО Strikes Back
Часть 4 Принесите, пожалуйста, кота
И не мои тексты: обзор на Хабре - vStack аналог VMware! Серьезно? с тестами производительности
(к сожалению, Хабр как ИТ сайт настолько опередил Пикабу, что кнопки «цикл статей» – нет, и экспорт копи-паст из ворда вносит пробел перед началом абзаца)
Продолжу рассмотрение «что же не так с продуктом ИТ содержащим» без примеров.
Вместо предисловия
Особенность vStack в том, что для администрирования платформы не требуется огромный штат специалистов, управлять ей может один инженер.
Демонстрация установки одного из узлов кластера vStack версии 2.1.3 (ч. 1)
Хотелось бы уточнить, а где надо обязательно два инженера, в каком решении? Это ж не rocket science silo с двумя ключами.
или же, внезапно для меня:
Теперь виртуальные машины (ВМ) можно запускать на любом узле кластера, независимо от расположения пула хранения. (27.12.2023 - Выпущена новая версия 2.2 платформы виртуализации vStack )
Раньше нельзя было? У вас там что под капотом, Pacemaker + DRBD или все в контейнерах и LINSTOR и ZFS-датасет ? Corosync? Самописные скрипты ? (статьи по теме: LINSTOR — это как Kubernetes, но для блочных устройств (обзор и видео доклада) , Надежное хранилище с DRBD9 и Proxmox (Часть 1: NFS) )
Попытка систематизации
Подходя к длинному обзору «что же могло пойти не так», надо составить план и попытаться ему следовать. Я попробую пойти следующим путем:
Минимальное число хостов для решения, ограничения.
Единичный хост
Требования к отдельному хосту. Ограничения методов загрузки хоста и авто конфигурации. (Это про файлы ответов, загрузку с SD \ USB \ M2 \ SAN \ и прочие Ansible \ ironic \ иной bifrost
Типовые операции отдельного хоста и групп независимых хостов (аналоги esxcli, vim-cmd, localcli , VMkernel Sys Info Shel – vsish и Get\set VMHostFirmware )
Безопасность и уровень атомизации \ гранулярности прав на управления операциями
Подключаемое оборудование (СХД, коммутаторы) и сетевая связность для единичных хостов
Вложенная виртуализация
Виртуализированные устройства (что с сетями и драйверами SAS \ NVME, ограничения USB арбитратора)
Проброс устройств и ограничения (pci passthrough)
Устойчивость к физическим сбоям отдельного хоста вне центра управления (например, отказ дисков ОС или отказ или переполнение диска \ раздела с логами)
Предоставляемые методы для операций резервного копирования сервисов на системе из одного хоста и их ограничения
Сетевая связность отдельного хоста (LACP, RDMA, etc)
Варианты балансировки сетевой нагрузки хоста
Внутренний мониторинг отдельного хоста в части состояния предоставляемых сервисов и скорости (аналог esxtop, в том числе для дисковых операций)
Внутренний мониторинг отдельного хоста в части состояния хоста – дисков, памяти, температуры, кручения вентиляторов
Внешний мониторинг отдельного хоста для всего перечисленного, связь с Zabbix \ Prometheus \ etc
Логирование операций отдельного хоста (внутреннее и внешнее – syslog, log redirect, etc)
Организация работы снапшотов, скорость консолидации, и возможность отката состояния виртуальной машины к дереву снапшотов, возможность консолидации всего дерева.
Мониторинг осиротевших панцу снапшотов
Работа переподписки и планировщика в условиях больших (больше половины физических ядер) и «шумных» виртуальных маши.
Работа при переподписке по RAM, технологии гарантированного резервирования памяти, приоритетов, баллона и свопа
Расширение и балансировка дисковых групп
Центр управления
Центр управления и его типовые операции
Устойчивость к сбоям модулей (демонов, сервисов, сервисных VM) управления на отдельном хосте по отношению к доступности отдельных операций и состоянию кластера
Устойчивость сервисов к сбою на отдельном хосте в части дисковой подсистемы и последствия для виртуальных машин (lock файлы, блокировка на уровне метаданных, иные методы)
Устойчивость сервисов к сбою на отдельном хосте в части сети и последствия для виртуальных машин (ситуация: сетевики опять положили сеть, или энтерпрайзный Eltex при прошивке запаниковал, перепутал где у него bpdu guard и положил LAG со словами в логе – ваши криворукие авторы LAG дали ему возможность пересылки bpdu и сборки петель)
Устойчивость сервисов к split-brain при нахождении в одном ЦОД (см. сетевики)
Устойчивость сервисов к split-brain при работе в метрокластере (см. сетевики)
Устойчивость сервисов к потери части путей и маршрутов при работе в метрокластере (см. пожар в коллекторе, см. экскаватор, см. высокоценный иностранный специалист Дилдожон Мастурбекович на тракторе украл кабель, запасная ссылка)
Устойчивость сервисов к потере управляемости (потере сервисов управления) отдельного хоста в кластере, без выхода из строя хоста (это про аналог отказа vpxa\vpxd и что будет при попытке их перезагрузки)
Предоставляемые методы для операций резервного копирования сервисов на уровне центра управления и их ограничения
Устойчивость кластера к сбоям сервера управления, ограничения и методы
Дополнительные сведения про типовые операции с RDM дисками
Внутренний мониторинг центра управления
Внешний мониторинг центра управления
Логирование внутренних операций центра управления (предоставление прав на сам центр управления, перезапуск сервисов, резервное копирование и восстановление, состояние внутренних сервисов) и их внешняя обработка
Логирований операций над предоставляемыми сервисами (предоставление прав на виртуальные машины, состояние внешних сервисов и виртуальных машин) и их внешняя обработка
Ограничения по скорости типовых операций, пути ускорения и тонкая настройка
Прочие известные ограничения, например Cross-cluster VM migration limits – причем, в том числе и те, которые надо искать по рассылкам вида:
Somehow this has been lurking for a while; we remove our subregions from the base BAR and VGA region mappings, but we don't destroy them, creating a leak and more serious problems when we try to migrate after removing these devices. Add the trivial bit of final cleanup to remove these entirely. (отсюда)
Гиперконвергентность
Требования к дискам и дисковым группам
Устойчивость к полным сбоям (гарантированной потере) отдельного диска
Устойчивость к частичным сбоям (потеря скорости) отдельного диска и методы диагностики указанной проблемы
Устойчивость к сбоям отдельного хоста
Устойчивость к частичному нарушению сетевой связности
Операции обслуживания и расширения дисковых групп
Калькулятор и оценка скорости дисковых операций, их зависимость от сетевой инфраструктуры
Документация и багтрекер
Где искать что-то аналогичное свежим сбоям в якобы давно протестированной на живых пользователях проприетарщине, вроде последнего QueryChangedDiskAreas API returns incorrect sectors after extending virtual machine VMDK file with Changed Block Tracking (CBT) enabled in ESXi 8.0u2 (95940)
Изобретая велосипед
Когда я дописал этот список, то подумал – где-то я это видел. И точно – это
- 10% от оглавления книги АДМИНИСТРИРОВАНИЕ VMWARE VSPHERE 5 - всего-то 500 страниц.
- немного от руководства vSAN Planning and Deployment 7 или 8
- чуть чуть от руководства vSAN Network Design Update 3 VMware vSphere 7.0 VMware vSAN 7.0 или vSAN Network Design Update 1 VMware vSphere 8.0 VMware vSAN 8.0
- 0.1% от VMware vSAN 7.0 U3 Deep Dive
Совокупный объем в книжных страницах вышеперечисленнго – около 800 страниц по нижней границе, и страниц хотя бы 1000 – для появления предмета обсуждения. При написании 5 страниц в день, 22 рабочих дня, примерно человеко-год работы, если писать одному, и 2-3 года, если будет писать коллектив
Это не включая методологию тестирования аппаратной совместимости и ее итоги.
Состояние
Можно сказать, что на текущий момент открытая документация по любому продукту импортозаместительному содержит страниц 10-20 из минимум 1000. В итоге, может оказаться, что все гораздо, гораздо сложнее.
Например: в списке выше есть пункт «Виртуализированные устройства». Про что это? Это, в том числе, про работу ленточных библиотек в среде виртуализации (SAS \ FC) и про работу графических ускорителей для работы в чем-то сложнее косынки. Немного цитаты про то, что может пойти не так на одном примере из группы в телеграме:
У нас ситуация с GPU/vGPU следующая:
1. В одном из облаков у нас порядка 80 карт Nvidia Tesla в разных комбинациях и 4 карты AMD MI100
2. Все комбинации рабочие, никаких "секретных" карт нам к счастью ни разу не доставалось:
a. Dell R740/ Xeon Gold 6226R + Tesla V100S PCIe 32GB
b. Supermicro AS-4124GS-TNR/AMD EPYC 7513 + Tesla T4 PCIe 16GB
c. Dell R750xa/Xeon Platinum 8358 + NVIDIA A100 PCIe 40GB
d. Niagara R2206SG (supermicro)/AMD EPYC 7513 + NVIDIA A100 PCIe 40GB
e. Lenovo SR670 V2/Xeon Gold 6338 + NVIDIA A100 PCIe 80GB
f. Dell R750XA/Xeon Gold 6338 + NVIDIA A100 PCIe 80GB
g. Dell R750xa/Xeon Gold 6338 + AMD Instinct MI100 32GB
h. есть ещё где-то SXM4 версии карт A100, но сходу не могу найти
3. Для карт Ampere vGPU нормально работают с парой не очень приятных особенностей:
a. Нужно в скрипт автозагрузки добавлять команды разбиения на карты и создания mdev девайсов, чтобы при ребуте не терялись идентификаторы. В противном случае nova-compute не запускается, поскольку помнит, что у виртуалок были девайсы с определёнными идентификаторами.
b. Разумеется, жадная Nvidia хочет лицензию внутри виртуальной машины на требуемые типы vGPU. Про деление через sriov без лицензии верится слабо (кто-то выше писал) -- я читал исходники драйверов из утечки, там довольно жестко определяется тип нарезанной карты прямо в драйвере. Если нарезать нештатным способом, драйвер все равно понимает, что это vgpu и требует лицензию
c. В зависимости от конкретной карты нужно внимательно смотреть в документации, какой версии драйвер она хочет в хост- и гостевой системе (525 или 535) чтобы расслоение через MIG срабатывало правильно и работало внутри виртуалки. Драйвера как ни странно было проще качать не с сайта Нвидии, а у какого-то заботливого чувака с гитхаба, его репозиторий прихлопнули, к сожалению (был тут: https://github.com/justin-himself/NVIDIA-VGPU-Driver-Archive)
4. С точки зрения использования самих видеокарт через pci-passthrough целиком проблем у Nvidia вообще никаких. Единственное что, нужно выключать у видеокарт GSP, он приводит к сбоям внутри ВМ (https://github.com/NVIDIA/open-gpu-kernel-modules/issues/446)
5. Проблемы с прокидыванием внутрь виртуалок были только у AMD MI100 из-за того что при перезагрузке ВМ посылается неправильная последовательность команд для освобождения PCIe устройств. Коллеги починили это модулем к ядру, но полноценно протестировать пока не успеваем. Если кто-то заинтересованный есть, могу забрать код у автора и дать под честное слово рассказать результат (мы его собираемся заопенсорсить, но только после того как кто-то его проверит — мы или не мы)
Архаизация ИТ сообщества
Вместо предисловия к абзацу процитирую старую, забытую книгу
Сталь и свечи
.. Настоящие трудности мы встретили тогда, когда приступили к изготовлению больших корабельных броневых плит весом до ста тонн. Практики отливки таких крупных слитков у нас в то время не было. Да и мировой опыт в этой области металлургии был невелик. Слитки такого веса отливали во всем мире всего несколько заводов. Когда на заводе Круппа производилась отливка крупных слитков, в цехе собиралось все заводское начальство – это было большим событием..
И вдруг кто-то из мастеров проговорил:
– А ведь в старое время на заводе броневую сталь отливали. Конечно, таких больших слитков не делали, но, может быть, посоветоваться со старыми мастерами?
Из рассказов рабочих завода я уже знал, что каждый мастер, сумевший изготовить доброкачественную броневую плиту, получал премию и особое удостоверение, в котором указывалось, для какого военного корабля и какой номер плиты был мастером изготовлен. Эти удостоверения были для мастеров своеобразным аттестатом. Чем больше мастер имел таких удостоверений, тем выше считалась его квалификация. ..
Не верилось, что этот маленький щуплый старичок способен сделать то, с чем не справились опытные специалисты завода, получившие высшее образование. Мы поздоровались. На мой вопрос, отливал ли он когда-нибудь броневые плиты, старичок ответил утвердительно и показал несколько удостоверений, подтверждающих изготовление им ряда плит для одного из военных кораблей.
– Поможете нам организовать отливку крупных слитков броневой стали? – спросил я.
– Помочь можно, конечно, но дело это особое, трудное, и не всякому оно дается. Святое это дело. А ведь вы, наверное, все безбожники?Старичок вдруг на какой-то момент преобразился, вся его степенность исчезла, а на лице появилось выражение ехидства. Ясно, он уже знал о неудаче с отливкой. Медленно опустившись на стул, он повторил:
– Помочь-то, конечно, можно, но дело это сурьезное. Без молитвы здесь никак нельзя. Много я плит изготовил, а плохих не было. За каждую плиту я особую награду получал. Если плиты такие изготовлять будем – свечи мне потребуются, восковые, церковные. Без свечей и пробовать нечего – все равно проку не будет. (В.С. Емельянов На пороге войны)
Где связь-то? Когда про связь?
Связь вот. Открываю я сайт по виртуализации в Перди-Закаменной и вижу :
всё взаимодействие с интреграторами и производителями идёт в рамках соглашений о неразглашении, поэтому возможности вываливать результатты тестов в бложик у меня нет
цитата авторская, я не виноват что у автора вместо Word – некий продукт импортозамещенный, который не может подчеркнуть грамматические ошибки
Результаты ладно, но нет даже методологии тестов, хотя бы в общих чертах. Интригаторы (нет, это не опечатка, от слова интрига, а не интеграция) пишут свои worth a street value of ten million dollars dollars or 20 million dollars or half a billion dollars 99.95% совместимости. Не знаю, откуда они эти цифры берут, потому что я свои цифры точно на другой улице покупаю считаю.
В остальном – все то же самое, только вместо удостоверений – красивые грамоты и результаты экзаменов, и далее ехал NDA через NDA, видит NDA NDA.
Так везде, куда ни посмотри – тут NDA, тут занимайтесь сами.
Почему так
Чтобы понимать, почему так, можно посмотреть что вообще с русской, не переводной технической литературой. А с ней.. А с ней все просто. По VMware – точнее, по одному продукту из линейки – вышло 2 издания по 2 версиям продукта, от Михеева, причем последняя по версии 5 (12 лет назад, 2012 год ) и есть заметки на манжетах от Мошкова. По Microsoft – есть Чекмарев «Windows Server 2008. Настольная книга администратора», и еще десяток авторов тут.
Много ли русских авторов в статьях Библиотека системного администратора: подборка книг на русском (2023) и Книги для системного администратора. Моя книжная полка (2015) ? Это не говоря о качестве Олиферов против Одома (Wendell Odom). Хотя о чем я вообще, люди на Хабр в 2024 году пишут статьи «я сделал conf te» при наличии цикла СДСМ на том же Хабре.
Авторов было мало, стало еще меньше, писать книги не очень выгодно – 300кк\наносек не видно даже в микроскоп. Возможно, поэтому часть авторов переключилась на рассказы про то, что импортозамещение уже вот вот. Порвет.
При таком подходе даже остаточные, не систематизированные знания сначала остаются у немногих, а затем подменяются догмами - что надо делать только так. Потом догмы тиражируются и.. и все, на Хабре получаются статьи «допустим, у нас контур разработки, тестирования и продуктивный в одной сети, и разработчики имеют root на прод».
Необходимое примечание
Если вы живете в ИТ пузыре, и думаете, что процесс архаизации и перехода знаний из состояния «вот так делаем, вот так не делаем потому что» в «делаем вот так потому что деды так делали и я сказал» идет только в ИТ – так это не так. Во всем ранее-хайтеке, от космоса до методов Чохральского – идет, хотя скорее уже завершен, процесс вымывания (по смерти) дедов, которые знали и как работает вон та установка наносварки, и графики режимов закалки и отпуска. На это состояние равномерно распределен (скорее-намазан) новый продукт – который, все чаще, на хлеб легко мажется, но на вкус пока не очень. Так везде в чем-то сложнее обработки напильником – хоть в расчете радиотрактов, хоть в производстве аналоговнетных устройств из китайской рассыпухи, где авторы мега-устройства не способны даже рассчитать мощность и прочитать даташит на тепловой режим. В медицине уже давно так, начиная от продаж в аптеках сахара и гомеопатии, заканчивая выписыванием врачами лекарств, не имеющих в составе веществ с доказанной эффективностью или вообще действующего вещества. О чем говорить, если утрачено исскуство массового (серийного) производства подшипников выше 4 класса. Дальше только переход на буксы вместо кассетного подшипника и возврат к герметичным корпусам для спутникового оборудования. Хотя, может оказаться, что проще вернуться сразу к тропосферной связи, к тому же она красивая. Кстати, вот и она - Тропосферные станции как еще одна возможность обеспечить интернетом удаленные регионы.