Из чего же, из чего же, из чего же сделана СХД? Продолжаем сатирическую экскурсию в новом выпуске рубрики – #это_СХД.

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

Теперь по существу. Пост является околохудожественным продолжением рубрики про внутренности СХД, которая хоть и широкими мазками, но отвечает на вопрос: «Почему нельзя просто взять и сделать нормальную СХД?». А также объясняет, как создание систем хранения данных влияет на сон разработчика.

‼️ И еще чуть-чуть важного. Если все-таки тянет подискутировать про синюю изоленту под капотом СХД, то для этого идеально подойдет ближайшая конференция – «Технократия», где мы специально будем делать акцент на технической составляющей наших продуктов. Сразу отметим: хочется сохранить камерность мероприятия, поэтому количество посетителей строго ограничено. Получить талончик можно попробовать тут.

А мы начинаем

Программная часть СХД, как и любой нормальный бутерброд, состоит из нескольких слоев и должна либо не падать совсем, либо падать управляемо и строго маслом вверх. Поэтому на низком уровне системы важна простота, и тут СХД мало чем отличается от обычного сервера. Стандартный набор: BIOS и какая-нибудь несложная система управления (BMC). Она нужна для того, чтобы на аппаратном уровне можно было удаленно подключиться к «железу» и выполнять с ним элементарные операции. BMC, как и BIOS, некоторые допиливают под себя. У нас, например, тоже используется своя переписанная система, но без фанатизма.

Дальше идет ОС. Ни для кого не секрет, что 99% всех СХД, как, впрочем, и любых более-менее серьезных систем, имеют в своей основе Linux. Иногда Unix. В целом суть не меняется, но есть нюансы.

Конечно, некоторые компании, причем с уважаемыми транснациональными лицами, предпочитали экзотику и использовали нечто подобное обрезанной Windows. Но все осталось в их темном прошлом. Сейчас в большинстве случаев фундамент – Linux. Как правило, разработчик СХД берет готовое ядро, которое подходит по ряду причин, и дорабатывает его до нужного состояния. Мы, например, выбрали Alt Linux, потому что они – крайне компетентные ребята.

Над операционной системой – функциональные Open Source блоки. И вот тут уже начинается уличная магия в двух актах. В первом – мы получаем некий набор стандартных компонентов Linux (файловые системы, менеджеры томов и др.), которые нужно дописать согласно правилам ее использования, не нарушив никаких обязательств. И здесь немного задержимся, ведь речь идет про наш любимый Open Source.

Всегда радостно наблюдать за разными «потомственными экспертами», когда речь заходит о применении OS в российском софте. «Фи. Т.е получается, отечественные разработчики воруют чужие наработки?». Ну да, японские, китайские и американские специалисты ничего не воруют, сидят себе спокойно, пишут продукты на базе открытого ПО. А вот российские разработчики – это другое, они непременно должны написать все с нуля и точка.

Тут есть один маленький нюанс: дело в том, что в основе СХД (как и в любых других сложных решениях) используются Open Source компоненты. Которые каждый производитель перерабатывает под себя, создавая абсолютно новый продукт, не забывая, конечно, соблюдать правила сообщества. Получается, вся мировая разработка стоит на воровстве? Или нужно просто внимательнее читать правила использования OS? Оставим это «на подумать» и двигаемся дальше.

Продолжение ⬇️⬇️

#это_СХД #СХД #разработка #софт

Начало в предыдущем посте⤴️

Во втором акте нам нужно создать с нуля все недостающее ПО. Например, нормальную графику, кластерный софт, свой API, инструменты мониторинга и сбора статистики и т.д.

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

«Ой, да ладно. В чем проблема написать необходимое ПО? Взял, собрал команду и написал!» – спросит недоверчивый читатель и, возможно, будет в чем-то прав. Но есть проблема, даже две.

Недостаточно просто написать, нужно еще как-то обеспечить совместимость создаваемого софта с исходными программными компонентами и «железом». СХД – это сложная и чувствительная структура, где все элементы должны бесшовно взаимодействовать между собой. И очень много времени и сил уходит на то, чтобы довести не только свой, но и открытый код до ума. Более того, некоторые готовые решения практически полностью переписываются и используются вообще по-другому. Это как с пнем: можно на нем сидеть, можно его сжечь, а можно – использовать для строительства, например. Какой из вариантов будет полезнее? Также и с софтом.

Далее надо не прогореть на этапе проектирования. Для упрощения, допустим, что с архитектурой вроде все понятно – сразу бросаемся в омут с головой и беремся за самые хардкорные задачи. Например, если кластерный модуль, то непременно для high-end.

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

Процесс стопорится, все расстроены. А ведь это закономерно, мы же не идем на Эльбрус без подготовки? Здесь такая же история. Нужно двигаться от простого к сложному, класть кирпичик за кирпичиком.

💬 Для иллюстрации: свой первый кластерный модуль для mid-range СХД мы создали еще семь лет назад. Он был простым, в том числе с точки зрения отказоустойчивости, но рабочим. Постепенно СХД усложнялась, требования к кластерному ПО увеличивались, навыки и знания команды – тоже. И вот за это время мы переделали компонент 4 или 5 раз, причем почти с нуля.

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

Продолжение ⬇️⬇️

#это_СХД #СХД #разработка #софт

​​Начало в предыдущем посте⤴️

А теперь немного программных лозунгов. Каким должен быть софт для СХД?

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

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

🛠 Масштабируемым. Система не должна «падать» при увеличении нагрузки, а вот уметь расширяться под более емкие задачи – обязана. И масштабы этого расширения должны быть заранее определены опытным путем и протестированы при разработке.

🛠 Безопасным. СХД содержат ценную информацию, поэтому число атак на них постоянно растет. Необходимо внедрять процессы безопасной разработки и желательно проходить сертификацию/аттестацию всех известных внутренних органов. Это дисциплинирует.

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

Если проще, то все программные лозунги выше можно переформулировать: надо сделать так, чтобы не сильно переживать за то, что где-нибудь на АЭС система ляжет, будет взломана, потеряет данные или кто-то (а, возможно, и вы) останется без электричества или еще без чего-нибудь. Поэтому иногда лучше просто взять и донести кольцо до Ородруина. 🙂

#это_СХД #СХД #разработка #софт

@aerodisk_official — трезво про импортозамещение в ИТ

5 миллионов за коробку с гвоздями или мы тут совсем ук…ли? 🙂 О том, почему нормальная СХД стоит как крыло самолета, уже писали ранее. Спойлер: действительно дорого, но не потому, что производителю так захотелось.

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

PS. Благодарим Сергея Геннадьевича за предоставленный контент.

#СХД

@aerodisk_official — трезво про импортозамещение в ИТ

У нас не упадет. Что общего у делового партнера, автомобиля и СХД? Все они должны быть надежными. И во второй серии мини-сериала «Технократия» речь пойдет об основе основ СХД – отказоустойчивости.

Сценарий такой:

🎞 немного матчасти: вспоминаем структуру системы хранения данных;

🎞 обсуждаем, как должна реагировать СХД, если что-то не по плану;

🎞 изучаем, какие бывают отказы;

🎞 знакомим с нашими сервисами отказоустойчивости;

🎞 разбираем пограничные случаи отказов и их обработку;

🎞 а напоследок – затронем эмуляцию отказов или как мы вообще понимаем, что наши решения работают.

В главной роли – Алексей Меркулов, руководитель отдела разработки СХД.

Новая серия уже доступна здесь.

#Технократия #СХД

@aerodisk_official — трезво про импортозамещение в ИТ

«Бабушка прошла и все повыдергивала». Во второй серии нашего мини-сериала «Технократия» мы обсуждали отказоустойчивость СХД. Сегодня поговорим, как сохранять доступность критически важных приложений, даже если у вас несколько площадок и один сисадмин. Как уже, наверное, догадались, речь пойдет о метрокластере. 🙂 А детали расскажет наш руководитель отдела системной архитектуры Роман Козлов.

Запись тут.

#Технократия #СХД

@aerodisk_official — трезво про импортозамещение в ИТ

​​СХД и чародеи. Для отечественного рынка систем хранения данных последние пару лет выдались непростыми. Однако результаты, с которыми мы входим в 2024, в какой-то степени действительно волшебные. И если дело не в магии, то в чем? Подводим итоги года для рынка СХД и заглядываем в будущее.

Дела былые

Итак, конец 2021. «Российские системы хранения данных (да и в принципе любое «железо» или софт)? Пфф, вот еще» – все мы помним, как раньше относились к импортозамещению. Действительно, зачем напрягаться, когда есть глубокоуважаемые Dell, HPE и др.? Кто же мог подумать, что партнерство – штука относительная? А тут грянул шторм, и картина уже совсем иная.

Кто-то скажет: «Банальщина, сколько можно?». Да, банальщина, но нельзя забывать, как все начиналось и с чем пришлось стартовать.

Особенности параллельного импорта

После переформатирования санкциями, российский рынок СХД стал представлен двумя сегментами: отечественное оборудование и продукты западных «друзей», которые поставляются в основном по всем известной схеме на букву «п». Можно сказать, что мы конкурируем не с какими-то конкретными вендорами, а с неким «собирательным» образом в виде совокупности иностранных брендов.

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

⚙️ Компетенции и ресурсы. У интеграторов и конечных заказчиков имеется все необходимое, включая квалифицированные кадры и возможности покупки комплектующих.

⚙️ Экономическая выгода. Импортные решения оставались в среднем дешевле, чем российские СХД.

⚙️ Привычки. У нас целое поколение инженеров, которое выросло на западных продуктах.

⚙️ Функционал и качество. Мы все еще отстаем от зарубежных аналогов, чего греха таить. Преодолеть разрыв возможно, нужно лишь время.

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

Новые расклады

Отечественные производители, видя всю картину, не сидели сложа руки. В 2023 ключевые игроки, включая нас, любимых, укрепили свои позиции за счет поддержки с ИТ-холдингами. Yadro купили «Рэйдикс», F + tech приобрели 49% акций производителя СХД Baum. А мы, в свою очередь, запартнерились с «Аквариус».

Зачем, спросите? Все просто: наращивание объемов производства, инвестиции в разработку новых продуктов. Это позволит не только расширить ассортимент, но и значительно улучшить его качество и функционал. И результаты уже есть. На конец 2023 оборудования стало выпускаться больше, а цены в силу конкуренции в отдельных сегментах начали снижаться. Тенденция такова, что в течение 2024 года стоимость российских решений будет приближаться к параллельному импорту.

Запретят ли параллельный импорт? На то пока нет серьезных оснований. Тут как у классиков: утром деньги – вечером стулья. Пока российские производители СХД не достигнут нужных показателей по объему, цене и качеству, запрет параллельного импорта – выстрел себе в ногу.

Сейчас среди отечественных СХД формируются два направления: Enterprise – высокофункциональные и дорогие системы и сегмент начального уровня для широкого круга корпоративных заказчиков. И это станет основой для принципиально нового рынка СХД в России, самодостаточного и конкурентоспособного.

#мнение #СХД #импортозамещение

@aerodisk_official — трезво про импортозамещение в ИТ

«Вот бы хоть одну российскую СХД с файловой репликацией», – мечтательно протянул системный администратор одной компании, сидя в метро. Вместе с сисадмином вздохнул весь вагон. 😅 А пока кто-то вздыхал, мы взяли и сделали. Как это было – смотрите в пятой серии нашего мини-сериала «Технократия». 😉 В главной роли – Павел Сердечнов, руководитель отдела исследования и разработки «Аэродиск».

#Технократия #СХД

@aerodisk_official — трезво про импортозамещение в ИТ

​​Управлять СХД – это не rocket science. И даже не бином Ньютона. Но почему бы не упростить жизнь любимому сисадмину? 🙂 Вот мы и решили сделать тематический вебинар.

В программе:

🦾 работа с СХД АЭРОДИСК ENGINE: изучаем типовые операции для администратора, знакомимся с интерфейсом;

🦾 автоматизация REST API: разбираемся, кому и зачем она нужна, обсуждаем, какие операции лучше доверить скриптам;

🦾 демонстрация REST API в деле;

🦾 лайфхаки по использованию Curl и Python;

🦾 уличная магия: разворачиваем инфраструктуру для метрокластера «не из графического интерфейса».

🗓 Дата – 12 марта.

⌚️ Время – 15:00 (МСК).

Регистрация обязательна, количество мест ограничено.

#околоИТ #СХД #вебинар

@aerodisk_official — трезво про импортозамещение в ИТ

​​Engine AQ. «Аэродиск Engine AQ». 😎 Друзья, как вы, наверное, догадались, речь идет о нашем новом продукте. А точнее – целой линейке СХД на платформе «Аквариус». 🔥

Первый ее представитель – mid-range система «Аэродиск Engine AQ 440/450/460». Базируется на платформе Aquarius FS440/FS450/FS460, обеспечивает производительность до 1 млн IOPS, поддерживает работу с корпоративными приложениями. Предусмотрена репликация – не придется волноваться за надежность хранения информации. Есть возможность организовать метрокластер – он наладит бесперебойную работу и доступность данных в распределенных средах.

Конфигурацию рассчитываем, исходя из требований заказчика. С технической поддержкой тоже все обсуждаемо: есть программы «Стандарт+», «Бизнес» и «Премиум» на срок от 1 до 5 лет.

Отдельно отметим, что «Аэродиск Engine N4 AQ440» уже в заветных списках Минцифры и Минпромторга. Спасибо ведомствам!

Скажем откровенно: для нас Engine AQ – не просто новая СХД, а целая глава для компании. Мы стремились создать надежное, масштабируемое и гибкое решение – основу для развития ИТ-инфраструктур клиентов. И у нас получилось. 🙂

В планах – лайт-версия для малого и среднего бизнеса. Но это будущее. А пока – «Аэродиск Engine AQ» в вашем распоряжении.

#новости #СХД

@aerodisk_official — трезво про импортозамещение в ИТ