Гиперконвергенция

Мы продолжаем цикл статей о нашей новой линейке систем хранения данных PowerStore. Этот материал посвящен уникальному функционалу, позволяющему запускать на борту системы пользовательские приложения AppsON.

Для начала вкратце напомним основные особенности PowerStore. Система имеет микроконтейнерную архитектуру. Разные компоненты ОС выделяются в отдельные, изолированные функциональные элементы (контейнеры). Это обеспечивает простую переносимость функций, стандартизацию и быстрое внедрение нового функционала, а также максимальную гибкость развёртывания.



Как вы наверняка помните из предыдущей статьи, платформа PowerStore представлена двумя типами систем:

• PowerStore T традиционная внешняя СХД, которая подключается к серверам для обеспечения потребностей в хранении информации.
• PowerStore X гиперконвергентное решение на базе гипервизора VMware ESXi, который стал признанным фундаментом для большинства HCI решений. Забегая вперед, отметим, что гипервизор ESXi загружается на каждый из двух контроллеров, работающих в режиме active-active, а PowerStore OS работает как виртуальная машина на каждом узле.

Важно понимать, что после выбора типа системы PowerStore T или X, пользователи не cмогут переключаться между ними в силу архитектурных особенностей, которые мы и рассмотрим ниже.

Размещение гипервизора на борту PowerStore X позволяет одновременно запускать приложения пользователя и функционально организовать внешнюю дисковую систему хранения данных со всем привычным нам функционалом. Этот подход получил название AppsON.

Независимо от того, какую модель PowerStore выберет заказчик, он получает в части СХД одни и те же возможности, службы по работе с данными и полную отказоустойчивость.

Виртуализация функционала СХД обеспечивает не только дополнительную изоляцию и абстракцию операционной системы, но и предполагает в недалёком будущем новые варианты развёртывания платформы, в которых ПО хранения данных может быть развёрнуто на серверах заказчиков либо в облаке, причём без привязки к специально разработанным для этого аппаратным устройствам. С таким подходом мы уже сталкивались на примере Unity VSA (Unity Virtual Storage Appliance), когда заказчик на своем сервере мог развернуть полнофункциональную систему хранения данных.



В PowerStore X, как было отмечено выше, ОС запускается внутри виртуальной машины. Каждый физический узел содержит один экземпляр виртуальной машины с PowerStore OS Controller VM. Этот вариант ничем не отличается от PowerStore OS, работающей непосредственно на физических узлах PowerStore T, но в данном случае 50% аппаратных ресурсов зарезервированы для этой виртуальной машины. Остальные ресурсы доступны для клиентских виртуальных машин.

Для минимизации влияния на производительность СХД совместно с компанией VMware была разработана специальная технология проброса ключевых аппаратных ресурсов PowerStore (диски, чип сжатия и т.д.) напрямую в виртуальную машину PowerStore OS Controller VM. На выходе подобный механизм позволил получить сопоставимое время отклика от дисковой подсистемы с моделью PowerStore T.



Идеальным вариантом использования подобного решения являются рабочие нагрузки с интенсивным вводом-выводом (в отличие от нагрузок с интенсивным вычислением): например, базы данных. Ещё одним вариантом является консолидация, когда надо развернуть инфраструктуру, где фактически нет ЦОД или очень мало места. Кроме того, одновременно с запуском виртуальных машин, PowerStore X может выступать в роли внешней СХД и предоставлять ресурсы хранения серверам через FC или ISCSi.

Таким образом, мы получаем новый уровень унификации решения, а термин Unified Storage играет новыми красками.

Тезисно резюмируем вышесказанное перед тем, как идти дальше:

• ESXi устанавливается непосредственно на каждый из контроллеров PowerStore X.
• PowerStoreOS работает внутри виртуальной машины на каждом из контроллеров. Эта виртуальная машина называется Controller VM (контроллером виртуальной машины).
• PowerStore X может предоставлять традиционные ресурсы хранения (такие как SAN/NAS/vVOl) внешним серверам и вместе с тем выполнять приложения пользователя.
• Независимо от модели X или T, PowerStore разработан с использованием архитектуры Active/Active, оба узла имеют доступ ко всем дискам и ресурсам хранения.
• Как и многие наши продукты, PowerStoreOS основана на операционной системе Linux, которая обеспечивает весь необходимый программный стек: API функции и точки интеграции, размещает веб-браузер для управления системой.
• PowerStoreOS реализована в виде контейнеров Docker. Контейнерная реализация упрощает обслуживание и развитие платформы, поскольку новые сервисы (контейнеры) можно легко и быстро добавить, а затем и перевести в оперативный режим. Если контейнер необходимо перезагрузить или изменить, то для этого не нужно останавливать весь стек. Это также обеспечивает больший потенциал для интеграции в портфель продуктов Dell Technologies, поскольку новые функции могут быть легко развёрнуты в среде докеров для PowerStore для использования.
• В модели PowerStore T 100% системного ЦП и памяти используются PowerStoreOS.
• В модели PowerStore X 50% ЦП и памяти зарезервированы для PowerStoreOS, что гарантирует наличие ресурсов для служб хранения данных, а остальные 50% доступны для запуска виртуальных машин пользователей.

На рисунке представлено наглядное сравнение двух подходов:

• Отдельный физический сервер, на котором запущен ESXi, подключается через FC или iSCSI к внешнему массиву хранения (в данном примере Unity). На сервере работает приложение (внутри виртуальной машины), которое получает доступ к ресурсам хранения данных.
• PowerStore X содержит одновременно вычислительные компоненты и компоненты хранения данных. Два отдельных хоста ESXi (оба контроллера) образуют единый вычислительный кластер. Виртуальная машина Controller VM запускает PowerStoreOS, которая предоставляет доступ к внутреннему хранилищу для любых встроенных приложений или (при необходимости) предоставляет ресурсы хранения для внешних хостов.
• PowerStore X может предоставлять ресурсы хранения внешним потребителям так же, как это делает обычная СХД.
• PowerStore X может выполнять приложения пользователей и обеспечивать их потребности в ресурсах хранения через внутренний интерконнект.
• PowerStore X может быть легко интегрирована в вашу виртуальную ферму. Одно из преимуществ, которое вскоре станет доступно, vMotion для бесшовной миграции ВМ между вашими системами.

Сценарии использования

Консолидация рабочих нагрузок

Очевидным сценарием использования возможностей функционала AppsON является консолидация рабочих нагрузок в рамках одной PowerStore X. Практика внедрения и использования систем PowerStore показала востребованность такого подхода, что подтверждается статистикой продаж. Нашим заказчикам пришлась по вкусу возможность иметь одну систему взамен комплекса различных устройств сервер, SAN-коммутаторы, СХД. Для бизнеса малого и среднего размера, а также для задач не требовательных к большому объему оперативной памяти, такой подход оказался экономически и технически интересным.

Удалённые филиалы (ROBO)

Интересный сценарий применения PowerStore X размещение системы в удалённых филиалах, где не требуется мощная инфраструктура, используются типовые офисные приложения, а технический персонал состоит из одного или двух администраторов-многостаночников. В такой ситуации минимизация нагрузки на сотрудников и упрощение применяемых решений один из важнейших критериев при выборе решения.
При таком подходе компактный форм-фактор 2U, простота развёртывания, гибкая архитектура, способность поддерживать несколько типов данных, централизованное управление и расширенная репликация в основные центры обработки данных делают PowerStore идеальным решением для периферии. Филиалы компаний и магазины розничной торговли, распределительные центры и склады, поликлиники и больницы, где пространство и ресурсы ограничены и где нет узкоспециализированных специалистов, смогут воспользоваться преимуществами простой системы, способной заменить собой целый комплекс различного оборудования и программного обеспечения.

Гиперконвергенция

Безусловно PowerStore также можно развернуть и в основном центре обработки данных. Благодаря интеграции с VMware, IT-специалисты могут легко и эффективно балансировать рабочую нагрузку в наиболее эффективную для нее среду на основе потребностей приложений и доступности ресурсов.

Управление кластером PowerStore в сочетании с инструментами VMware, включая vMotion, обеспечивает беспрепятственную мобильность приложений между PowerStore и другими узлами VMware. Приложения можно развернуть, например, на серверах, гиперконвергентной инфраструктуре или на самом PowerStore, а затем прозрачно для приложения переносить его между этими системами.

Аналитика

Предприятия в различных отраслях активно внедряют широкий спектр сценариев использования интернета вещей. Им часто приходится анализировать большие объемы данных и информации в режиме реального времени. Широкое распространение также получают различные устройства вроде датчиков и видеокамер. Они создают непрерывный поток структурированных и неструктурированных данных: видео- и аудиоконтент, файлы с текстовыми записями или строчки в базах данных. Всё это необходимо анализировать в режиме реального времени с целью принятия оперативных решений или для передачи данных или команд в другие информационные системы. В подобных сценариях анализ данных непосредственно на источнике хранения данных является одним из самых эффективных подходов и, безусловно, для решения таких задач система PowerStore тоже подойдёт отлично.

Интеграция с vCenter

Многие наши заказчики используют VMware vSphere в качестве основной платформы виртуализации для всех своих IT-систем. Таким заказчикам важно понимать, что PowerStore X глубоко интегрирован с VMware vCenter, а следовательно создание виртуальных машин и управление ими ничем не отличается от управления простым внешним сервером ESXi.

Известно, что для взаимодействия VMware и систем хранения данных используется VSI провайдер (Virtual Storage Integrator), который обеспечивает возможности выделения ресурсов хранения, управления и мониторинга непосредственно из интерфейса клиента VMware vSphere.

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



PowerStore поддерживает простую настройку виртуальных машин с использованием vVol, а также отображает много полезной информации о них. Таким образом, заказчики, сделавшие выбор в пользу семейства PowerStore, получают систему с простым управлением и мониторингом, нативной интеграцией с продуктами VMware и возможностью размещения виртуальных машин на самом массиве. В статье мы привели несколько практических примеров использования данного функционала, основанных на реальном опыте эксплуатации AppsON у наших заказчиков. Уверены, что со временем их станет ещё больше, и нам будет о чём рассказать в следующих статьях, посвященных системам PowerStore.

Всем привет. Этой статьей мы начинаем знакомить вас с новой версией российской гиперконвергентной системы AERODISK vAIR v2, в частности, со встроенным гипервизором АИСТ, который сейчас получил возможность работать автономно от vAIR, используя внешние СХД.

Изначально мы хотели рассказать о функциональности новой версии vAIR в одной статье, но материала получилось очень много, и мы встали перед выбором: либо сократить материал, либо разбить его на три части. Мы выбрали второй вариант и разбили материал следующим образом:

• Управление кластером и гипервизор АИСТ
• Файловая система ARDFS
• Аппаратные платформы, лицензирование и поддержка

Соответственно, в первой части мы расскажем о функциях управления vAIR v2 и более подробно о подсистеме виртуализации. Но сначала хотелось бы сказать пару слов об архитектурных изменениях в версии vAIR v2.

Коротко об архитектуре. Основные отличия между первой и второй версией

С момента выхода первой версии в 2019 году архитектура vAIR претерпела ряд изменений. Связано это в первую очередь с борьбой за стабильность, ресурсоемкость и производительность. Однако обо всем по порядку.

Описывать полностью архитектуру с нуля мы рамках этой статьи не будем. Коснёмся лишь тех отличий, которые существуют в настоящий момент между первой и второй версией. Для более глубокого знакомства с изначальной архитектурой vAIR v1 рекомендуем ознакомиться с нашими предыдущими статьями на эту тему:

• Принцип работы файловой системы ARDFS
• Архитектура vAIR

На уровне большой картинки на данный момент архитектура vAIR v2 выглядит следующим образом:

Ну а теперь переходим к деталям.

Косметические изменения

Незаметное внешнему глазу, но при этом важное и трудоемкое событие произошло в распределенной базе конфигураций (ConfigDB), которая отвечает за одновременное хранение конфигураций всех компонентов решения на всех нодах кластера. Мы полностью её переработали и, соответственно, оптимизировали. В итоге ConfigDB стала значительно стабильнее и минимизировала пожирание бесценных аппаратных ресурсов. Если говорить о цифрах, то за счёт переработки полезную производительность решения удалось увеличить примерно на 30%, что, очевидно, хорошо.

Стандартный блок данных, которым оперирует ARDFS, изменился с 4МБ до 64 МБ. Сделано это было также с целью увеличения производительности ввода-вывода.

Ещё одним маленьким, но приятным бонусом, который получился в результате оптимизации ARDFS и ConfigDB, стало снижение минимальных системных требований по количеству нод в кластере. Первая версия vAIR требовала не менее четырех нод, во второй-же версии начинать можно с трёх нод. Мелочь, но тоже приятно.

АИСТ покинул гнездо

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

Для справки: и АИСТ, и vAIR как два отдельных продукта прошли всю необходимую экспертизу регуляторов и, соответственно, добавлены во всех необходимые гос. реестры Минцифры и Роспатента, чтобы по-честному считаться российским ПО.

Чтобы не было путаницы, поясним. По факту АИСТ и vAIR не являются разными продуктами. Гипервизор АИСТ это составная и обязательная часть гиперконвергентной системы vAIR, при этом АИСТ может использоваться в качестве самостоятельного решения, а также АИСТ может всегда быть обновлен до полноценного vAIR-а.

Данное архитектурное изменение не только позволяет импортозаместить зарубежную виртуализацию на российских предприятиях, но и открывает ряд крайне полезных сценариев использования vAIR. Разберем их:

Сценарий 1. Просто гиперконвергент

Тут все просто. АИСТ используется как составная часть vAIR и работает с хранилищем ARDFS. Это то, что было в первой версии, и остается сейчас.

Виртуальные машины, сеть и хранилище работают в рамках одной отказоустойчивой аппаратной платформы (3 ноды+).

Сценарий 2. Просто виртуализация

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

При этом в этой схеме всегда остается возможность добавить локальных дисков во все физические серверы, объединить их быстрым (от 10 Гбит/сек) интерконнектом и обновить лицензию АИСТа до vAIR, получив в итоге гибридный сценарий (см. ниже).

Сценарий 3. Гибридный сценарий

Самый интересный сценарий. Мы одновременно с гиперконвергентом используем в качестве хранилища виртуальных машин сторонние СХД (например ENGINE или ВОСТОК :-)). Полезным является то, что к любой виртуалке, которая хранится на ARDFS, мы можем легко прицепить дополнительные виртуальные диски с СХД. И наоборот, к любой виртуалке, которая лежит на СХД, мы можем прицепить виртуальные диски с ARDFS. Это открывает очень много возможностей, начиная с задач постепенной и бесшовной миграции инфраструктуры между разными хранилищами, заканчивая полезным использованием старых СХД и серверов хранения, которые и выкинуть жалко, и подарить некому.

В итоге, когда мы пишем vAIR, мы имеем ввиду большой продукт в целом гиперконвергентную систему, которая включает в себя гипервизор АИСТ и файловую систему ARDFS. А если мы пишем АИСТ, то имеем в виду только компонент, который отвечает за серверную виртуализацию и виртуальную сеть. Чтобы внести ещё больше ясности, приводим ниже таблицу с разбивкой функционала по компонентам.

Обзор функционала. Что нового и для чего

Функции управления

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

Предусмотрен сценарий развертывания управляющей виртуальной машины (УВМ), которая через RestfulAPI может осуществлять полноценное управление всем кластером.

Кстати RestfulAPI, как понятно выше, есть, он описан и работает (по нему будет отдельная статья). Его спокойно можно использовать для автоматизации операций и интеграции со смежными системами. К примеру, уже сейчас есть интеграция (и, кстати, есть внедрение в продуктив) с российским VDI-решением Термидеск, как раз реализованная на базе нашего API. Плюс ещё несколько продуктов вендоров-партнеров на подходе.

Для управления виртуальными машинами изнутри гостевой ОС используется на выбор два протокола: VNC (по умолчанию) или Spice. На уровне отдельных ВМ администратор может задавать разные варианты подключений.

Сам интерфейс разбит на несколько логических частей.

1) Основная область управления, в которой выполняются почти все операции

2) Основное меню, которое выдвигается наведением курсора

3) Панель действий, на которой отображаются доступные для выбранного объекта действия.

4) Панель задач, которая показывает, какие задачи выполняются или были выполнены над выбранным объектом, вызывается выбором объекта и последующим кликом по кнопке задачи.

5) Ну и, наконец, информационная панель, которая показывает количество актуальных ошибок (красные) и выполняемых в данный момент действий (синие).

В целом после оптимизации распределенной БД интерфейс стал работать очень плавно и шустро, кроме того мы делали интерфейс сразу адаптивным и без привязки действий к правому клику мышки, и поэтому с ним спокойно можно работать даже с мобильного телефона.

Лирическое отступление: когда я эту функцию показал моему старому товарищу, который является тру-админом (то есть он админил системы в те славные времена, когда систем ещё не существовало) он воскликнул:
Вы нормальные там??!!! Нельзя админить серьезные системы через мобилу!!!
Хочу отметить, что во втором своём высказывании он, безусловно прав, лазить по серьезным кластерам через мобилку опасно, можно ткнуть не туда и всё как обычно упадёт, но всегда есть НО
Я напомнил ему ситуацию, в которую он попал несколько лет назад, когда потратил примерно 40 минут времени и 10 тонн мата на то, чтобы перезагрузить пару зависших виртуалок на известном гипервизоре, используя свой смартфон. Ноутбука у него с собой не было, а его заказчик с паром из ушей требовал устранить проблему здесь и сейчас.
Вспомнив об этом случае, мой товарищ тру-админ перестал сомневаться в нашей нормальности :-).

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

Гипервизор АИСТ

Не секрет, что в основе АИСТа лежит старый добрый KVM с libvirt-овой обвязкой. При этом наша реализация очень сильно доработана. Про годный веб-интерфейс, который управляет не только виртуализацией, но и сетью с хранилищем и который доступен, как с любой ноды, так и с управляющей ВМ, мы писали выше. Но это далеко не все доработки. Вот ещё несколько крайне достойных функций, которых в штатном KVM-е нет.

Отказоустойчивость виртуальных машин (HAVM) реализована классическим и понятным образом. Она может быть активна или неактивна для каждой виртуалки, а включается на этапе создания ВМ или в процессе её редактирования.

Если параметр HAVM активен, то в случае отказа ноды кластера, ВМ автоматически перезапуститься на другой ноде.

Для отдельных ВМ или для групп ВМ предусмотрены приоритеты обслуживания (QOS) из libvirt-а, где в свою очередь предусмотрены шаблоны популярных конфигураций.

Для защиты данных на уровне ВМ, а также для большей гибкости администрирования предусмотрены мгновенные снимки и клоны (которые можно превратить в шаблоны ВМ соответственно). Важной доработкой и одновременно крайне большой радостью является то, что снэпшоты делаются на горячую (при работающей ВМ) и полностью поддерживают консистентность файловых систем гостевых ОС (Linux, Solaris, Windows, BSD) и ряда поддерживаемых СУБД (пока только PostgreSQL и MySQL). При этом с помощью RestfulAPI никто не мешает реализовать консистентные снимки для других систем внутри гостевой ОС самостоятельно.

Для внешнего хранения из коробки поддерживается NFS, то есть хранить виртуалки можно на распределенном хранилище ARDFS (доступно в vAIR) или на внешней СХД по протоколу NFS. Опционально предусмотрена поддержка блочных внешних СХД по протоколам iSCSI и FC.

Миграция виртуальных машин со сторонних гипервизоров

Миграция, причем неважно откуда и куда, всегда стоит особняком во всей ИТ-жизни. За время полутора лет эксплуатации нашими заказчиками первой версии vAIR они (и мы автоматически) регулярно сталкивались с проблемами миграции виртуальных машин со сторонних гипервизоров в АИСТ. Штатный конвертер KVM штука хорошая, но крайне капризная. Поэтому в vAIR v2 (и в АИСТе соответственно) мы предусмотрели человеческий конвертер ВМ из VMware/Hyper-V прямо в интерфейсе vAIR/АИСТ.

Для конвертации администратор выбирает шару NFS (пока только NFS), где лежат файлы виртуальных машин VMware или Hyper-V. Далее vAIR сам сканирует шару на наличие нужных ему файлов и формирует доступный список для миграции. Далее выбираем целевой пул ARDFS (или внешнюю СХД), то есть куда будем конвертировать, выбираем нужные файлы ВМ (можно несколько, они будут конвертироваться по очереди) запускаем и идём пить пиво.

Когда пиво выпито, новые, уже сконвертированные, виртуалки ждут нас уже внутри vAIR-а в выключенном состоянии.

Мониторинг и логирование

Функции мониторинга реализованы как локально, так и удаленно. Администратор может работать со счетчиками утилизации ресурсов CPU, RAM, сетевых интерфейсов и подсистемой ввода-вывода (IOPS, MB/s, latency), как на уровне отдельных нод, так и на уровне кластера в целом.

Всё то же самое доступно и для удаленной системы мониторинга на базе Grafana.

Для логирования и алертинга предусмотрен журнал событий (ноды, порты, физические диски (SMARTCTL), сенсоры, температура и т.п.) с разбивкой по категориям и возможностью оповещения по электронной почте. Опционально поддерживается SNMP.

Кроме описанных выше возможностей гипервизор АИСТ позволяет выполнять функционал, который мы считаем must have, поэтому сильно его разрисовывать не будем, а просто перечислим:

• Обновление ПО без остановки и миграции виртуальных машин
• Живая миграция ВМ, а в ближайшем будущем с возможностью динамичного распределения ресурсов (а-ля DRS)
• Распределённые виртуальные коммутаторы с поддержкой VLAN-ов
• Расширение кластера без остановки виртуальных машин
• Автоподдержка (автоматическое оповещение производителя и заведение тикетов в тех. поддержку, при согласии заказчика, само собой)
• Метрокластер (отдельная большая функция, которой мы посветим позже отдельную статью)

Детально ознакомиться с особенностями функционала можно в технической документации, которая есть у нас на сайте:

https://aerodisk.ru/upload/Datasheet_AIST_final_11042021.pdf

В завершение первой части

В процессе разработки vAIR и АИСТ собственных решений в области виртуализации многие наши доверенные партнеры (которые допущены к раннему доступу), глядя на это, утверждали, что это плохая идея, потому что ВМварь и Нутаникс не догнать, они слишком крутые и великие, у них тысячи программистов по всей планете, бороды длиннее и свитера в два раза толще.

На подобные утверждения мы всегда задавали вопрос.

А эти компании сразу появились на свет с тысячей бородатых разрабов в толстых свитерах?

ИЛИ другой вариант

А вы когда родились вам сразу было 35 лет, у вас была машина, семья, дача, работа и образование? Это в комплекте вам врачи в роддоме выдавали?

В продолжении этой мысли позволим себе процитировать нашу же старую статью:

притча на эту тему.

Однажды странник попал в город, где шло грандиозное строительство. Мужчины ворочали большие камни под палящим солнцем. Что ты делаешь? спросил наш герой у одного из рабочих, который медленно тащил булыжник. Ты что, не видишь камни таскаю! зло ответил тот. Тут странник заметил другого рабочего, который волок телегу с большими камнями, и спросил: Что ты делаешь? Я зарабатываю на еду для своей семьи, получил он ответ. Странник подошел к третьему рабочему, который занимался тем же, но работал энергичнее и быстрее. Что делаешь ты? Я строю храм, улыбнулся тот.

О чем эта притча? О том, что если веришь в большую идею, видишь большую цель, то для тебя нет ничего невозможного, все достижимо. И каждый шаг, который приближает тебя к большой цели, удваивает твои силы. Существует устоявшийся миф о том, что разработка любого серьезного продукта, по силам только транснациональной корпорации, у которой обязательно сотни или тысячи программистов по всему миру.

В жизни это совсем не так. Практически всегда (за редким исключением), новый серьезный продукт создается небольшим коллективом до 10 человек (а обычно 2-3). При этом на этапе создания закладывается 80% всего функционала продукта. Далее продукт силами этого маленького коллектива выходит на рынок (или как-то еще громко заявляет о себе), и там его уже подхватывают инвесторы (фонды, холдинги или крупные производители).

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

На этом мы завершаем первую часть цикла статей про vAIR v2. В следующей статье подробно расскажем о функционале файловой системы ARDFS.

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

Голосование доступно тут, на Хабре, а также в нашем телеграм-чате https://t.me/aerodisk

Всем спасибо за внимание, как обычно ждем конструктивной критики и интересных вопросов.