• Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    –1

    Макс, спасибо! Наши с вами главные успехи еще впереди :-)

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    0

    Восток — это СХД общего назначения, т.е. СУБД, виртуализация, почта, файлы, видеонаблюдение и пр.


    Для закона Яровой, столько функциональных плюшек, как в Востоке не нужно, там все просто как в армии :-)

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    0

    Все к этому и идет

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    0

    ПО СХД и ОС наши, железо 70/30 в нашу пользу.

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    0

    У нас таких планов пока нет

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    0

    Наше ПО там примерно таким же образом, как и другое:


    https://reestr.minsvyaz.ru/reestr/121021/


    Лицензируется по количеству контроллеров и дисков.

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    +2

    Да, субъект никуда не исчез, но очень ослаб.


    Но это уже разговор совсем не про технологии :-).

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    0

    Очень хорошие вопросы, спасибо, отвечаем:


    1) При выходе из строя любого вентилятора – поток воздуха, по пути наименьшего сопротивления, начинает забирать воздух из внешнего пространства. Появляется обратный поток, который уменьшает обдув сервера и приводит к перегреву. Для устранения этого эффекта применяем ‘’обратный клапан’’. Он состоит из ряда пластин, которые ориентированы ребром к потоку при правильной продувке и поворачиваются все плоскостью к потоку, перекрывая его при аварийных ситуациях или при сервисной замене вентилятора.


    2) Шасси делится на несколько зон, каждая зона работает по своим правилам с изоляцией воздушных потоков и исключением перемешивания. Суммарно моделирование и выпуск шасси, перебор компоновок во время проектирования более полугода занял.


    3) Для uATX-SE — 8/16GFC либо 1/10/25Gbe, для ЕАТХ — кратно больше плюс появляется 32GFC и 40Gbe


    4) Что касается направляющих для дисков. Они льются из пластика, а решетка под диски фрезеруется из алюминия.

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    0

    По умолчанию используем Альт-Линукс (специальная версия). Но есть сборки на Астре и Дебиане.


    Что касается реестра, то наше ПО там есть.

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    +1

    FC/iSCSI/SMB/NFS

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    +3

    Ну для хранилок EMС\HP\NetApp кулеры же не на Яндекс маркете же покупают?
    Хотя вот на авито я видел предложения)))))

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    +2

    Расскажем на вебинаре, кроме того, чуть позже про Восток отдельный раздел на нашем сайте добавим.


    Что касается шпинделей, также как и с SAS3 чипами их делает 2 компании (или вроде уже одна?!) в мире, поэтому быстро организовать производство в России невозможно. Да и вопрос, нужно ли, с учетом, что ССД делать научились? Мое личное мнение что лет через 5-7 шпиндели умрут. Хотя может я не прав.

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    +3

    Смущает, но чипы SAS3 делают, если я не ошибаюсь, 2 компании в мире (втч Бродком).


    Разработать такие чипы в России здесь и сейчас (напомню, что потребность именно "здесь и сейчас", если не "вчера") возможным пока не представляется, а вот свои платы напечатать со своим дизайном вполне возможно.

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    +3

    Спасибо. Главное что у проектировщиков мониторы большие.


    image

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    0

    Спасибо большое!

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    +1

    Это просто полка :-)

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    +4

    Дополню немного свой ответ комментарием от НОРСИ. У WD есть технология т.н. "ArcticFlow" которая опирается на воздушный коридор, но мало кто знает что ее исток — специальные вырезы на плате бэкплейнов для гашения вибрации, при этом вокруг врубного разъема жесткого диска на бекплейне делается П-образный вырез, на котором "ходит" диск при работе.


    Именно по причине такого подхода к гашению вибрации инженерам WD пришлось под него подбирать технологическое решение продува шасси и изобретать "коридоры". В нашей же платформе ток воздуха и исключение завихрения воздушных потоков решены иным образом — за счет смещения размещения дисков между рядами и способом их вертикальной загрузки в шасси. Такой подход усложнил конструкцию самого шасси и плат бэкплейнов (несущей рамы на которые монтируются PCB) однако позволил реализовать более простое решение по теплоотводу.

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    +3

    Спасибо за комментарий.


    Три вентилятора установлены сзади, но есть еще внутри платформы. Я поищу фотки, чуть позже выложу.


    Разницы температуры между первым и последним рядом в среднем 5-7 градусов (см картинка)


    image


    На фото ССД GS Nanotech они идут в качестве дисков для ОС по умолчанию. А для данных могут быть разные диски. Конкретно в платформе Э124 это чаще всего 3,5 дюймовые NL-SAS

  • Как делается российское железо для СХД Аэродиск Восток на Эльбрусах
    +3

    В данном случае речь идет об HDD, градусы конечно Цельсия.

  • СХД AERODISK на отечественных процессорах Эльбрус 8С
    –1

    Эмулятор есть. Доступен в репозиториях qemu.

  • СХД AERODISK на отечественных процессорах Эльбрус 8С
    0

    Про более глубокие тесты само собой напишем, но чуть позднее)

  • СХД AERODISK на отечественных процессорах Эльбрус 8С
    0

    RDMA заведем в 2020-ом никуда он не денется :-)


    Гиперконвергент имеет смысл поднимать только на процессорах, которые виртуализацию поддерживают (это Эльбрус 16С — 2021 год). Наш гиперконвергент сейчас (Aerodisk vAIR), работает на x86 и на ARM, как только появится Эльбрус 16С будет гиперконвергент на e2k)

  • СХД AERODISK на отечественных процессорах Эльбрус 8С
    0

    Большое спасибо!

  • СХД AERODISK на отечественных процессорах Эльбрус 8С
    +1
    Это как раз совсем не «бантики», а экономия места. Стойка стоит денег, площадь в цоде своём или чужом тоже стоит денег, а расходование 2 юнитов таким образом -бессмысленная трата денег в итоге.

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


    Почему-то у меня есть серьёзное подозрение что на эти деньги я смогу собрать хранилище на Storage Space Direct на SSD, с 500 000+ IOPS и ещё на сдачу лицензий на винду купить и коммутаторы, и при этом будет не просто СХД, а HCI-кластер виртуализации, с которого можно будет еще через SOFS место презентовать. Ну или можно выкинуть винду, использовать KVM, но тогда дельта будет ещё забавнее

    Цены будут доступны в январе, тогда будет смысл сравнивать.


    MPIO не только для увеличения производительности нужен всё-же.

    MPIO в СХД Аэродиск на e2k поддерживается. Не поддерживается планировщик многопоточного ввода-вывода, пока.

  • СХД AERODISK на отечественных процессорах Эльбрус 8С
    –1

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

  • СХД AERODISK на отечественных процессорах Эльбрус 8С
    +1
    1) Насколько это конкурентноспособное решение по сравнению с другими компаниями которые также совершают импортозамещение, но делают это просто заклеивая оригинальный бренд? Это ведь можно в любом подвале делать и оно по-идее дёшево.

    Переклейкой заниматься действительно дешево, но законодательство становится жестче с каждым с месяцем и это становится просто не выгодно, а иногда и опасно. Лучше и выгоднее честно делать свой продукт.
    Что касается конкурентоспособности, то по задачам начального и среднего уровня текущая реализация e2k + софтовая обвязка вполне закрывает потребности. Задачи более серьезные могут быть решены через два года с выходом 16С.


    2) Не вызывает ли у вас опасения предполагаемая национализация Т-систем?
    Вы наверное имеете ввиду Т-платформы?
  • Архитектура AERODISK vAIR или особенности национального кластеростроения
    0
    Для HCI гипервизор и сетка пока слабоваты

    Ну, Москва не сразу строилась :-) Пока реализованы самые необходимые функции, дальше — больше.


    Когда появитесь, если вообще планируете, в HCL VMware хотя бы для ISCSI?

    Сейчас почти закончена сертификация VMware для классических СХД — Engine, vAIR на очереди, планируем iSCSI и NFS.

  • Архитектура AERODISK vAIR или особенности национального кластеростроения
    0
    Диски на нодах должны быть одной емкости?

    Желательно чтобы диски на нодах были одной емкости, но это не обязательное требование.


    ConfigDB сохраняется на отдельном разделе первого диска ноды? или как?

    Конфигурации хранятся в отдельном логическом разделе

  • Архитектура AERODISK vAIR или особенности национального кластеростроения
    0
    Сколько всего займёт процесс «сбора бюллетеней» т.е. после секундной задержки, сколько еще будет простаивать система?

    Вся процедура выбора/перевыбора лидера выполняется от 150 миллисекунд до 1-ой секунды, т.е. максимальный простой из-за перевыборов не может продолжится более 1-ой секунды.


    Возможна ли ситуация «чехарды» лидеров при пиковых нагрузках, когда все ноды заняты?

    Пиковая нагрузка на лидере не сказывается. Он просто командует кому что делать.

  • Гиперконвергентное решение AERODISK vAIR. Основа — файловая система ARDFS
    +1

    Ясно, спасибо.


    Программно мы от этого защищаемся следующим образом.
    В системе должно работать 50% + 1 нода от всего количества задействованных в IO нод. Если это количество меньше, то система автоматически остановит ввод-вывод.


    Например, если у вас 4 ноды и все хранят виртуальные диски. Упала 1 = ОК, упало 2 = автостоп IO.


    Например №2, если у вас 100 нод и все хранят виртуальные диски. Упало 49 = ОК, упало 50 = автостоп IO.


    Данные останутся живы (именно ради них все и автостопится), но будут недоступны, пока не включиться нода, которая +1 после 50%.


    Если допускать работу меньшинства нод (менее 50%), это чревато ( т.е. резко возрастает риск) потерей данных при любых схемах RF и EC. Понятное дело, на это мы пойти не можем.


    Если упадет вся стойка (все ноды), то всё выключится :-). Тут только аппаратная защита — резервный ввод, ИБП, дизель и т. п.

  • Гиперконвергентное решение AERODISK vAIR. Основа — файловая система ARDFS
    +1

    обязательно, ну и надеюсь обаятельно тоже получится :-)

  • Гиперконвергентное решение AERODISK vAIR. Основа — файловая система ARDFS
    +1

    Зачем нам vSAN? У нас есть vAIR))))


    Из гипервизоров поддерживается наша улучшенная реализация KVM, которая управляется из той-же web-gui, что и хранилище ARDFS с программной сетью. Также поддерживается VMware. В будущем будет ещё HyperV.

  • Гиперконвергентное решение AERODISK vAIR. Основа — файловая система ARDFS
    0

    Не очень понял вопрос. Вы имеете ввиду аппаратную защиту от потери питания в целой стойке? Поясните?

  • Гиперконвергентное решение AERODISK vAIR. Основа — файловая система ARDFS
    +1

    Метаданные ARDFS условно делятся на два класса.


    1)нотификации (инфа об операциях с объектами хранения, информация о самих объектах и т.п.)
    2)служебная информация (блокировка, информация о конфигурации нод-хранилищ и т.п.)


    Для распределения этих данных используется служба RCD (raft cluster driver) она автоматически назначает ноду с ролью лидера, задачей которого является получение и распространение информации по нодам. Лидер является единственно верным источником этой информации. Кроме того, лидер организовывает хартбит. Если по какой-либо причине для одной из рядовых нод лидер стал недоступен более одной секунды, эта рядовая нода организовывает перевыборы лидера, запрашивая доступность лидера с других рядовых нод. Если собирается кворум, лидер переизбирается. После того как бывший лидер "проснулся" он автоматически становится рядовой нодой, т.к. ему новый лидер отправляет соответствующую команду.


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


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

  • Гиперконвергентное решение AERODISK vAIR. Основа — файловая система ARDFS
    +1

    Больше спасибо за развернутый комментарий.


    как на счет тестов производительности? откуда 2 мсек задержки?
    Далее приведены факты, они могут быть проверены из открытых источников Производительность:
    очень много различных тестов, например
    longwhiteclouds.com/2017/11/14/1-million-iops-in-1-vm-world-first-for-hci-with-nutanix

    По этой ссылке задержки ниже 2 миллисекунд указаны для операций чтения (возможно есть другие источники). Для операций записи они выше или примерно равны 2 миллисекундам.


    Задержки в микросекунды на чтение само собой в ARDFS тоже реализуемы. К примеру с помощью локализации чтения данных, чтобы ВМ не ходила за чтением своих данных на другие ноды, а читала их именно с той ноды, где она выполняется. Похожий механизм, насколько нам известно, успешно используется у решений Нутаникс (про других не знаю)


    С записью же дела обстоят сложнее, т.к. при записи системе следует дождаться подтверждения записи от всех нод, которые участвуют в хранении копий виртуального диска. Это подтверждение (обязательное) происходит по внутреннему интеконнекту и пока оно состоится, как раз и проходят те самые миллисекунды. Во всяком случае так сделано у нас.


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


    Возможно другие разработчики эту задачу ещё как-то решили, мы точно не знаем, но если есть методы, которые решают эту проблему (мы ещё в начале пути, все-таки), мы с радостью бы о них поговорили бы и не только))))

  • Гиперконвергентное решение AERODISK vAIR. Основа — файловая система ARDFS
    +1

    С помощью сенсоров, как и в наших СХД. Про аппаратку и список совместимости обаятельно напишем отдельную статью

  • Гиперконвергентное решение AERODISK vAIR. Основа — файловая система ARDFS
    +1

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

  • Гиперконвергентное решение AERODISK vAIR. Основа — файловая система ARDFS
    +1

    Различные сценарии масштабирования в т.ч. между ЦОД-ами, покажем тут, опишем плюсы, минусы и подводные камни их само собой достаточно.


    По производительности EC для блочного доступа работает он хорошо (файловый примерно тоже самое, т.к. подложка используется та же), понятное дело медленнее чем RF, но терпимо. К примеру EC 2+1 примерно на 5-10% медленнее, чем RF-2, но по объему EC значительно выгоднее.

  • Гиперконвергентное решение AERODISK vAIR. Основа — файловая система ARDFS
    +1

    Спасибо за комментарий.


    QOS сейчас реализован на уровне ВМ, возможно задавать на каждую в отдельности.


    Более подробно напишем в статье про функциональность.