Разрушая мифы о гиперконвергенции / Комментарии / Хабр

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

Современные HCI‑решения также включают функции проактивного мониторинга и автоматического перераспределения ресурсов. Это снижает потребность в ручной настройке и реагировании «по факту» — экономится и время, и деньги.

Как работает это "автоматического перераспределения ресурсов"? По мановению волшебной палочки? Другого в статье нет, увы.

Масштабирование происходит линейно: нужно больше ресурсов — добавляется узел в кластер. Новый сервер увеличивает вычислительную мощность, объем хранилища и сетевые возможности одновременно.

А если речь идет не о кластерной структуре? Невсегда кластер это универсальное решение для ИТ инфраструктуре. Более того это миф что добавление узла в кластер добавляет ресурсы линейно. Наоборот это никогда не происходит линейно и это доказано было много-много лет. Видимо сейчас про это забыли и можно снова использовают протухшую наживку для новых пользователей.

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

Не раскрыт фокус как из нескольких отдельных специалистов по "вычислению, хранению, сетям" рекламируемый подход превращает несколько отдельных специалистов в двух-трех инженеров (в ИТ нет инженеров) по кластерам, а сами кластера состоят все таки из вычислений, хранения и сетей.

Я больше 25 лет проработал и работаю в Канаде в большой канадской фирме использующей ИТ самым наиширочейшем способом. Это энергитическая компания с производством элетроэнергии в масштабах нескольких регионов России. Это так, небольшое введение.

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

Ладно я, я работаю с ИБМ мэйнфрэймами, но я вхожу в подразделение занимающееся именно инфраструктурой Ит этой большой канадской компании. На еженедельных митингах в составе более 20 членов нашей команды (я один среди них мэйнфрэймщик, больше мэйнфрэймщиков в компании нет, а МФ есть. Интересно?) я много слышу о разных современных чудесах в ИТ, но не только о чудесах, но и о проблемах. И вот что я давно заметил. Проблемы из раза в раз практически одни и те же. Их рещают, но они снова вылазят по другому.

Чудеса примерно об одном, о Кубернетесе и кластерах. Их любит наш манагер и продвигает всеми правдами и неправдами. А вот реальные программисты всячески от этого отмахиваются. У них других проблем до вала, им бы запустить в продакшн то что они клепали много лет под IIS.

А вот маленькая история об инфраструктуре на МФ за последние 25 лет в этой компании. Уходить с МФ компания начала более 30 лет назад. На момент моего прихода в 2000 году оставалось два критических приложения на МФ. Оба настолько критичские для бизнеса что уходить с МФ никто тогда даже не помышлял. Людей вокруг МФ было много, я слышал до 70 человек, но я в это и тогда не верил.

Сами МФ время от времени менялись и менялась их СХД (новый термин для меня), и сетевое обеспечение. Приложения (два, одно это ERP класса) тоже жили своей жизнью и развивались.

Сменя МФ происходила по разным причинам.причем почти никогда потому что они типа устарели физически или морально. У нас сейчас один из МФ возраста 10 лет, второй 5 лет. Оба под одной и той же версией ОС (далеко не версии сегодняшнего дня).

Менялись МФ главным образом потому что ИБМ снижал цены лицензий и собственно владения МФ (использовался лизинг). Менялись СХД тоже не раз. И вот что инересно, все эти изменения, апгрейды проходили легко и непринужденно.

Но время шло, пришли новые манагеры и они решили что таки надо избавиться от МФ несмотря на критичность приложений (атомная энергетика на минуточку). На наше "счастье" одно из приложений было разработкой внешней, мирового масштаба, фирмой. И эта фирма решила с новой версии переписать это приложение так что оно не могло бы, по их мнению, выполняться на МФ. Вот и так бывает, на Западе, у акул капитализма. К слову сказать не все их клиенты на МФ с этим согласились и решили остаться на последней версии для МФ. Это клиенты в США.

Наша же, канадская компания, решили скакнуть сразу на ту версию что для МФ не предполагалась. Говоря не предполагалась я имею в виду что с небольшими усилиями и их новая версия, не для МФ, могла таки и на МФ работать. И даже без усилий могла, но немножко иначе.

Это взяло годы. Люди поддерживающие Мф (очень специализированыые) уходили на пенсии, сокращались так или иначе. И наконец остался я один. Все свалилось на меня и я (не титан, простой человек) смог это все тянуть и тяну до сих пор. Это я к Вашим двум-трем инженерам по кластерам подвел. А мне, на минуточку, 70.

Три года назад приложение сняли с МФ в Azure. Но второе приложение так пока на МФ и выполнчяется. Но вот уже вот-вот снесут его с МФ. Успешно это будет или нет никто не знает. Увидем. Но, на оба сноса потрачены большие миллионы $$$$. Вместо одного, небольшого, прямо скажем маленького МФ, первое приложение сейчас выполняется на 36 х86 серверах и постоянно в проблемах, Людей вовлечено масса. Второе приложение выполняется на МФ с минимально возможной конфигурацией. 1(один) CPU на минимально возможной производительности. Две системы, Продакшн и Девелопмент каждый в своей партиции с 1 ГБ мемори. Кстати этот МФ может быть "масштабирован" в одном фрэйме от 1 до, хочется сказать бесконечности, но это конечно лишь в сравнении с масштабируемостью на х86 серверах и при условии приобретения Мф от ИБМ, что в России нынче невозможно насколько я знаю.