Здравствуйте, благодарю за хорошую оценку (приятно) и за повод для дискуссии :-).
RDG ("интеллект, функциональность, большие объемы") - прямо на старте вынуждает выбирать уровень RAID для всего пула. Как так? Это "интеллект и функциональность"?
Интеллект и функциональность в RDG - это когда вы можете:
создавать большие двухслойные пулы с большим количеством дисков;
из коробки реализовать файловый и блочный доступ с одного пула
делать много разных вариантов снапшотов: стандартные ROW снэпшоты, снэпклоны, связанные клоны, группы консистентности, локальные реплики
создавать не только классические Рэйды 1/10/5/50/6/60, но и рэйд с тройной четностью
использовать глобальную автозамену дисков для любых типов пулов
ускорять производительность разными вариантами кэшей
назначать политики перестроения для разных типов данных в зависимости от задачи
экономить место за счет компрессии и дедупликации для больших архивов
ну и делать прочие полезные телодвижения с тонкими томами, VLAN-ами репликацией и метрокластером.
ну а если после всего вышеперечисленного по прежнему вас будет волновать, что вас "вынуждают выбирать уровень RAID для всего пула", то во-первых, никто не мешает создать несколько пулов, а во-вторых не только мы, но и также не менее прекрасные ребята из NetApp-а с вами категорически не согласятся и скажут, что это благо! :-)
DDP - здесь уровень RAID можно выбирать для тома, размещаемого в пуле. Но вот только диски для чанков этого тома, физические диски, нужно выбирать из пула вручную. И следить за тем, чтобы пространство на физических дисках в пуле при множестве RAID-групп (т.е. томов) распределялось равномерно. Особенно интересно это всё начинает выглядеть при количестве дисков в пуле большим 10, т.к. нужно теперь учитывать, что у тома с RAID-5 (например) физических дисков должно быть меньше 11, иначе производительность падает. Очень похоже на тетрис, только не так весело.
Про чанки вручную вы ошибаетесь, возможно перепутали что-то. Чанки у нас в DDP распределяются автоматически и равномерно. Для этого при создании пула надо выбрать количество дисков для него, дальше система сама все распределит в зависимости от свободного места. Специально следить за этим не надо. Возможно когда-было не так, но я если честно не помню такого, если напомните, буду признателен.
А ещё Куриман подсказывает, что набивать в DDP-тома много дисков не рекомендуется, о чем мы везде пишем и говорим, для этого есть RDG, там это разумно.
В обоих случаях это такой дремучий олдскул, что смотреть страшно
тогда отвернитесь, но помните, что в таком положении дремучий олдскул будет смотреть на вас, находясь у вас за спиной :-)
И в обоих случаях отсутствуют такие ставшие уже привычными вещи как распределенные spare диски и быстрое восстановление после сбоя
опять вы что-то перепутали. Hotspare диски у нас глобальные-универсальные. Т.е. один диск может подменить своего сбойного собрата в любом типе пула.
не очень понял, что вы имеете в виду под "быстрое восстановлением после сбоя"
если вы говорите о перестроении при выходе из строя диска , то тут у нас также два вполне годных инструмента для его ускорения: 1)частичное восстановление (только поврежденные данные) 2)политика перестроения. Разве этого мало?
если вы говорите о восстановлении после сбоя той или иной части СХД (ноды, порта, БП итп), то на аппаратном уровне все задублировано, а на программном работает целая связка кластерных служб и переключение выполняется за секунды и без прерывания доступа. На крайнем вебинаре мы подробно рассказали об этом, а также продемонстрировали выход из строя портов и дисков в прямом эфире. Вот запись пожалуйста
Не стоит забывать, что производительность с включенным дополнительным функционалом (дедупликация, компрессия) падает кратно.
Тут полностью с вами согласен, есть такая у нас боль. Именно поэтому мы везде рекомендуем эти функции не использовать для задач с высокой производительностью. Но это не значит, что мы не будем развивать это направление. Еще как будем.
А что внутри Аэродиска делает ZFS? Кто кого взял в заложники?
прочитав это замечание, другие опенсорс компоненты СХД Аэродиск обиделись и загрустили. Почему? Потому-что про них опять забыли, а они не менее важны! :-). Давайте не будем их обижать и вспомним их тоже: linux, net-tools, udev, smartctl, zfs, lvm, drbd, smb, chrony, ipmitool, prometheus, iperf, scst, iscsi_driver, fc_driver, multipath, snmp, snmptrap, python, javascript, flask, react, sqlite, postgresql, redis, gunicorn, nginx
а если серьезно, то мы всегда говорили, что опенсорса внутри у нас много и подробно рассказывали какого. Не вижу в этом ничего плохого. Наоборот, в прямых хороших руках, которые растут из плеч, и в которых есть хорошим напильник, опенсорсные поделки превращаются в инструменты уровня предприятия, а сообщество получает профит в виде новых разработок.
Более того, мы настолько любим тему опенсорса, что скоро один из наших продуктов реализуем в опенсорс версии со своим репозиторием, сообществом, блэкджеком и хохломой. Не переключайтесь!
Российские конкуренты (все) уступают нам в функциональности.
А вот это чистая правда
Ещё раз благодарю за теплые слова :-), для нас это ценно!
вы наверняка интересовались и в курсе жизни конкурентов, западных и Российских, есть ли у вас киллер-фичи технического плана, может, какие-то опции которых нет ни у кого или характеристики, по которым вы готовы обогнать ведущих зарубежных производителей ?
Интересовались, интересуемся и будем интересоваться!
По сравнению нашего и "ихнего" кунг-фу, не хочу тут устраивать прямой холивар, т.к. это неэтично, поэтому отвечу в общем виде.
Российские конкуренты (все) уступают нам в функциональности.
Зарубежные превосходят (логично), но есть у нас прекрасная особенность, которой у них нет. Это две принципиально разные схемы организации хранилищ в одной СХД - RDG (Raid Distributed Group) и DDP (Dinamic Disk Pool). Большинство СХД сильных зарубежных конкурентов - заложники своей схемы организации хранения. К примеру, есть массив с кучей функций и интеллектуальных фич, поддержкой больших объемов и много-много всего, но за интеллект приходится платить невысокой производительностью. Или наоборот, производительность - пушка, но функциональность слабая. Поэтому мы чтобы избавить заказчика от мук выбора "красивый или умный (тупой или страшный)", используем две схемы организации хранения RDG - интеллект, функциональность, большие объемы, DDP - производительность. Это то что выгодно нас отличает от известных нам сильных зарубежных конкурентов.
Насколько активна сейчас ветка Восток ? Расскажите что у него под капотом, много ли проблем ?
Лично мы пытались поднять простенькое СХД на 8СВ (mdadm + tgt), но упёрлись в то что не удаётся достичь производительности между двумя контроллерами (HBA и LAN) более чем 4ГБит, на 8С ситуация ещё хуже. Говорят, это решается тонким тюнингом ядра. Удалось ли вам с этим справиться ?
Проблем с разработкой на Эльбрусе хватает, но они решаемы любым взрослым коллективом разработчиков. И да, вы правы, решать их надо доработкой ядра, которой мы активно занимаемся не без поддержки коллег их АльтЛинукса (отдельное спасибо Михаилу Шигорину).
Есть ли вообще сравнительные тесты производительности Engine и Восток со схожими параметрами ?
Почему на random r/w не восстанавливается время отклика после возврата оптимального пути?
Это баг версии 5.0.0 (на ней тесты делали), исправлено в версии 5.0.1 (вышла на днях)
Почему на seq write производительность неоптимального пути выше?
В случае такой нагрузки активнее начинает работать процессор (это видно на схеме) именно за счет этого вытягивается производительность. Это, само собой, актуально когда есть свободные процессорные ресурсы, если бы процессор был бы нагружен на 80%+ была бы просадка
Восстановление ВМ происходит в другую ВМ. Если при возникновении ВМ уже существует, то она восстановливается рядом с другим именем (префикс добавляется)
Здравствуйте. Очень правильный вопрос, почему-то забыл об этом написать в статье. Рассказываю о принципах масштабирования по линиям.
Первая линия. Технический колл-центр, масштабируется также как и другие колл-центры, путем набора и быстрого обучения людей на местах, либо расширением услуг внешнего колл-центра (также с обучением сотрудников) и оплатой по объему обращений.
Вторая линия. Исходя из нашей практики, на 100 "условных СХД" на поддержке требуется один инженер второй линии (с нашим расширенным функционалом). Набор и обучение - процесс сложный, но оно того стоит. Также у инженера второй линии есть ресурс в виде внешних удаленных рук (как правило это несколько специально обученных подрядчиков с высокими компетенциями). Этот ресурс инженер привлекает сам когда требуется (у него есть специальный бюджет для этого). В случае необходимости этот ресурс наращивается с оплатой по запросам.
Третья линия. Разработка. Тут похожая математика, как и с инженерами. Только "200 условных СХД" = 1 разработчик на поддержке.
С виртуализацией математика отличается, но принцип тот же.
1. Эльбрусы сейчас в России в достаточном для наших задач (СХД) количестве.
2. Новые будут делаться на других заводах (детали, пожалуйста, не к нам, а к производителю).
3. Корпуса, материнские платы, бэкплейны итп давно уже в России делаются (во всяком случае для наших систем)
4. Другие комплектующие (втч процессоры ) мы уже давно завозим по своим специальным каналам
Резюмирую. Производство СХД у нас налажено давно, тк мы в наших прогнозах рассматривали в том числе и подобный поворот событий, то есть были к этому готовы. Поэтому и сейчас, и через несколько лет мы готовы производить и поддерживать наши системы хранения (и не наши кстати тоже если очень попросят))
А о каком функционале речь?
Ну мы в своей телеге (ИЗЧ) уже писали об этом)))
А на Хабре у нас чуть-чуть другой формат постов, мы обычно пишем тут над- и подкапотку про свои продукты. За редким исключением конечно.
Здравствуйте, благодарю за хорошую оценку (приятно) и за повод для дискуссии :-).
Интеллект и функциональность в RDG - это когда вы можете:
создавать большие двухслойные пулы с большим количеством дисков;
из коробки реализовать файловый и блочный доступ с одного пула
делать много разных вариантов снапшотов: стандартные ROW снэпшоты, снэпклоны, связанные клоны, группы консистентности, локальные реплики
создавать не только классические Рэйды 1/10/5/50/6/60, но и рэйд с тройной четностью
использовать глобальную автозамену дисков для любых типов пулов
ускорять производительность разными вариантами кэшей
назначать политики перестроения для разных типов данных в зависимости от задачи
экономить место за счет компрессии и дедупликации для больших архивов
ну и делать прочие полезные телодвижения с тонкими томами, VLAN-ами репликацией и метрокластером.
ну а если после всего вышеперечисленного по прежнему вас будет волновать, что вас "вынуждают выбирать уровень RAID для всего пула", то во-первых, никто не мешает создать несколько пулов, а во-вторых не только мы, но и также не менее прекрасные ребята из NetApp-а с вами категорически не согласятся и скажут, что это благо! :-)
Про чанки вручную вы ошибаетесь, возможно перепутали что-то. Чанки у нас в DDP распределяются автоматически и равномерно. Для этого при создании пула надо выбрать количество дисков для него, дальше система сама все распределит в зависимости от свободного места. Специально следить за этим не надо. Возможно когда-было не так, но я если честно не помню такого, если напомните, буду признателен.
А ещё Куриман подсказывает, что набивать в DDP-тома много дисков не рекомендуется, о чем мы везде пишем и говорим, для этого есть RDG, там это разумно.
тогда отвернитесь, но помните, что в таком положении дремучий олдскул будет смотреть на вас, находясь у вас за спиной :-)
опять вы что-то перепутали. Hotspare диски у нас глобальные-универсальные. Т.е. один диск может подменить своего сбойного собрата в любом типе пула.
не очень понял, что вы имеете в виду под "быстрое восстановлением после сбоя"
если вы говорите о перестроении при выходе из строя диска , то тут у нас также два вполне годных инструмента для его ускорения: 1)частичное восстановление (только поврежденные данные) 2)политика перестроения. Разве этого мало?
если вы говорите о восстановлении после сбоя той или иной части СХД (ноды, порта, БП итп), то на аппаратном уровне все задублировано, а на программном работает целая связка кластерных служб и переключение выполняется за секунды и без прерывания доступа. На крайнем вебинаре мы подробно рассказали об этом, а также продемонстрировали выход из строя портов и дисков в прямом эфире. Вот запись пожалуйста
Тут полностью с вами согласен, есть такая у нас боль. Именно поэтому мы везде рекомендуем эти функции не использовать для задач с высокой производительностью. Но это не значит, что мы не будем развивать это направление. Еще как будем.
прочитав это замечание, другие опенсорс компоненты СХД Аэродиск обиделись и загрустили. Почему? Потому-что про них опять забыли, а они не менее важны! :-). Давайте не будем их обижать и вспомним их тоже: linux, net-tools, udev, smartctl, zfs, lvm, drbd, smb, chrony, ipmitool, prometheus, iperf, scst, iscsi_driver, fc_driver, multipath, snmp, snmptrap, python, javascript, flask, react, sqlite, postgresql, redis, gunicorn, nginx
а если серьезно, то мы всегда говорили, что опенсорса внутри у нас много и подробно рассказывали какого. Не вижу в этом ничего плохого. Наоборот, в прямых хороших руках, которые растут из плеч, и в которых есть хорошим напильник, опенсорсные поделки превращаются в инструменты уровня предприятия, а сообщество получает профит в виде новых разработок.
Более того, мы настолько любим тему опенсорса, что скоро один из наших продуктов реализуем в опенсорс версии со своим репозиторием, сообществом, блэкджеком и хохломой. Не переключайтесь!
Ещё раз благодарю за теплые слова :-), для нас это ценно!
Спасибо, буду рад дискуссии.
Нет ничего лучше бесплатного хорошего софта. Пользуйтесь на здоровье!
Спасибо за много интересных вопросов :-) Отвечаю
Интересовались, интересуемся и будем интересоваться!
По сравнению нашего и "ихнего" кунг-фу, не хочу тут устраивать прямой холивар, т.к. это неэтично, поэтому отвечу в общем виде.
Российские конкуренты (все) уступают нам в функциональности.
Зарубежные превосходят (логично), но есть у нас прекрасная особенность, которой у них нет. Это две принципиально разные схемы организации хранилищ в одной СХД - RDG (Raid Distributed Group) и DDP (Dinamic Disk Pool). Большинство СХД сильных зарубежных конкурентов - заложники своей схемы организации хранения. К примеру, есть массив с кучей функций и интеллектуальных фич, поддержкой больших объемов и много-много всего, но за интеллект приходится платить невысокой производительностью. Или наоборот, производительность - пушка, но функциональность слабая. Поэтому мы чтобы избавить заказчика от мук выбора "красивый или умный (тупой или страшный)", используем две схемы организации хранения RDG - интеллект, функциональность, большие объемы, DDP - производительность. Это то что выгодно нас отличает от известных нам сильных зарубежных конкурентов.
СХД Восток активно развивается и продается. Что под капотом писали в одной из предыдущих статей: https://habr.com/ru/company/aerodisk/blog/656757/
Проблем с разработкой на Эльбрусе хватает, но они решаемы любым взрослым коллективом разработчиков. И да, вы правы, решать их надо доработкой ядра, которой мы активно занимаемся не без поддержки коллег их АльтЛинукса (отдельное спасибо Михаилу Шигорину).
Есть см. статья https://habr.com/ru/company/aerodisk/blog/520888/
Здравствуйте, очень правильные вопросы.
Отказ контроллера демонстрировали в одной из предыдущих статей, см ссылка https://habr.com/ru/company/aerodisk/blog/447070/ с того времени логика работы кластера не изменилась.
Это баг версии 5.0.0 (на ней тесты делали), исправлено в версии 5.0.1 (вышла на днях)
В случае такой нагрузки активнее начинает работать процессор (это видно на схеме) именно за счет этого вытягивается производительность. Это, само собой, актуально когда есть свободные процессорные ресурсы, если бы процессор был бы нагружен на 80%+ была бы просадка
А по поводу цены на СХД, ранее отвечали на этот вопрос в нашем ТГ канале, предлагаю вам ознакомиться
https://t.me/aerodisk_official/96
Здравствуйте, к счастью вы ошибаетесь.
По железу, если очень грубо, то так
1)корпуса, материнки, бэкплейн, плюс часть элементов питания российские
2)процессоры в зависимости от модели, Восток - российские, Engine - зарубежные
3)диски и адаптеры, а также ряд элементов питания зарубежные
Подробности можно почитать тут
https://habr.com/ru/company/aerodisk/blog/504306/
По софту. Функционал A-Core значительно шире чем просто программный рэйд, можете посмотреть подробнее тут
https://aerodisk.ru/wp-content/uploads/2022/07/Tehnicheskoe_opisanie_-AERODISK-VOSTOK-5_ENGINE-5.pdf
Да, хорошая идея, спасибо. Сделаем в течение пары часов.
Про NT сказать ничего не могу. Не читал, не осуждаю. Могу сказать только, что указанные в статье решения показали себя хорошо.
На сайте разработчика
https://rubackup.ru/index.php/try
Здравствуйте, ну не будем же мы писать, "что в отличие от Акрониса....))))"
Здравствуйте
Дедупликация работает в онлайне.
Восстановление ВМ происходит в другую ВМ. Если при возникновении ВМ уже существует, то она восстановливается рядом с другим именем (префикс добавляется)
Здравствуйте. Очень правильный вопрос, почему-то забыл об этом написать в статье. Рассказываю о принципах масштабирования по линиям.
Первая линия. Технический колл-центр, масштабируется также как и другие колл-центры, путем набора и быстрого обучения людей на местах, либо расширением услуг внешнего колл-центра (также с обучением сотрудников) и оплатой по объему обращений.
Вторая линия. Исходя из нашей практики, на 100 "условных СХД" на поддержке требуется один инженер второй линии (с нашим расширенным функционалом). Набор и обучение - процесс сложный, но оно того стоит. Также у инженера второй линии есть ресурс в виде внешних удаленных рук (как правило это несколько специально обученных подрядчиков с высокими компетенциями). Этот ресурс инженер привлекает сам когда требуется (у него есть специальный бюджет для этого). В случае необходимости этот ресурс наращивается с оплатой по запросам.
Третья линия. Разработка. Тут похожая математика, как и с инженерами. Только "200 условных СХД" = 1 разработчик на поддержке.
С виртуализацией математика отличается, но принцип тот же.
1. Эльбрусы сейчас в России в достаточном для наших задач (СХД) количестве.
2. Новые будут делаться на других заводах (детали, пожалуйста, не к нам, а к производителю).
3. Корпуса, материнские платы, бэкплейны итп давно уже в России делаются (во всяком случае для наших систем)
4. Другие комплектующие (втч процессоры ) мы уже давно завозим по своим специальным каналам
Резюмирую. Производство СХД у нас налажено давно, тк мы в наших прогнозах рассматривали в том числе и подобный поворот событий, то есть были к этому готовы. Поэтому и сейчас, и через несколько лет мы готовы производить и поддерживать наши системы хранения (и не наши кстати тоже если очень попросят))
Ясно, спасибо.
Мы в предыдущей статье писали про поддержку, в этой решили не баянить :-)
Думаю в следующих будем просто краткую справку про поддержку, документацию и пр. давать в конце статьи.
Не будет. Процесс отлажен годами.
Да, все верно
Engine название старое, первая система так называлась, решили не трогать.
А Восток, да отсылка к космосу. А что не так?