Информация

Дата основания
Местоположение
Россия
Сайт
aerodisk.ru
Численность
31–50 человек
Дата регистрации

Блог на Хабре

Обновить

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

Блог компании AERODISKСистемное администрированиеСерверное администрированиеХранение данныхХранилища данных
Рейтинг +18
Количество просмотров 3,7k Добавить в закладки 10 Читать комментарии 25
Комментарии 25

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


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


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

По описанию очень похоже на Sheepdog. Помню даже комитил в него несколько лет назад, пока верил что с ним можно сварить что-то годное в больших масштабах. НО…
NTT его забросила, плюс междоусобица между корными разработчиками из ntt и china mobile.
Проблема в таком простом варианте состоит в том, что нет возможности гибко влиять на отказоустойчивость в рамках стойки или даже дц. Все же crushmap Ceph это крутая штука, которая позволяет гибко для пула указывать какая степень надежности нужна.
Если все это расползается между 3 дц и дальше то вот с такой простой схемой как у вас аля «sheepdog» не очень представляю как это будет дружить.
П.С. Erasure Code клево, но только для объектного хранилища. Для фс накладно слишком. Может у вас есть какое-то ноу хау, но перезапись куска данных в 4Mb блоке заставить прочесть весь блок. обновить кусок и пересчитать четность и все это записать. Не помню как сделали в Ceph.

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


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

Просто гиперконвергентный + EC мне кажется плохим сочетанием. Сделаешь больше кусков — меньше оверхед при перезаписи, но больше операций по сети, чтобы это распихать на соседей, плюс затраты на цпу для обсчета четности все равно остаются. В общем у меня, конечно, данные уже не очень актуальны, но обычно там где работают виртуалки не запускают EC, ну только для совсем бедного по железу варианта.

Между цодами не очень интересно, там решений полно, а вот в рамках одной стойки и как передивает отключение питания стойки...

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

я писал, про одну стойку, а вы про разные пишите
Как переживает одну стойку?

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

Я имею ввиду поведение решения при пропадании питания во всей единственной стойке, или отказе большинства нод.

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


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


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


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


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


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


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

Каким образом происходит регулировка оборотов куллеров?

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

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

ScaleIO был прекрасен, пока его продавали.
Может перестали продавать не с проста?:)

Таки все еще продают, только называется оно теперь VxFlex и доступно только с Ready нодами от Dell. Софтовый вариант официально не доступен без нод. Но неофициально это все тот же SDS, которому пофиг на каком железе и OS работать (поддерживаются почти все популярные коммерческие).

Не-не) Они его пилят вовсю, но хотят поставлять только в своих решениях к сожалению.
как на счет тестов производительности? откуда 2 мсек задержки?
Далее приведены факты, они могут быть проверены из открытых источников, можно заказать оборудование на тест у местных реселлеров и т.д.
Я не имею никакого отношения к компании Nutanix и это не реклама :)
Вот эта фраза сразу цепляет:
Многие компании — производители ГКС (особенно те, у которых в портфеле нет СХД) говорят: «СХД отживает своё, гиперконвергент only!». Это смелое заявление, но оно не совсем отражает действительность

Тут явно прослеживается отсылочка к конкретному вендору т.к. по фактам реальных конкурентов особо нет — для тех кто немного в теме HCI понятно что эта фраза точно не может относится к VMware vSAN или к HPE SimpliVity и уж подавно не может относится к Cisco HyperFlex, про Microsoft с Storage Spaces Direct я вообще промолчу как и про Red Hat Hyperconverged Infrastructure на базе gluster storage.

На рынке сейчас есть решение которое является эталонной HCI системой — это Nutanix — Erasure coding(лучший на рынке), Deduplication(inline для RAM и SSD уровней и post-process для SSD\HDD capacity уровня — фактически inline позволяет в принципе меньше записывать данных на диски в реальном времени, а post-process это capacity deduplication), Compression(inline — опять же на примере записи позволяет значительно ускорить операции за счет того что нужно меньше данных записать на диски, offline), Storage Tiering(лучший или один из лучших на рынке).
Так же есть Rack Fault Tolerance позволяющий управлять отказоустойчивостью нод, блоков и стоек с учетом механизма Erasure coding.
При это все эти технологии могут быть использованы в рамках одного кластера неограниченного(!) размера.
Производительность:
очень много различных тестов, например
longwhiteclouds.com/2017/11/14/1-million-iops-in-1-vm-world-first-for-hci-with-nutanix
As with any major achievement there is a big team involved. This time is no different. Felipe helped me get a single Ubuntu VM on Nutanix NX9030 cluster up to 1M IOPS at 4KB. 100% Random Read. I ran a series to tests to make sure it could be sustained and then thought why can’t we do 8KB instead of 4KB. After more work with Felipe and some last minute tuning by Malcolm Crossly (Staff Engineer on AHV Team), we got to 1M IOPS at 8KB 100% random read and could sustain it for 24 hours. What was also impressive was that the latency was just 110 microseconds, or 0.11ms.

1 миллион IOPS блоками по 8KB 100% random read непрерывно в течении 24 часов с latency 110 микросекунд.

Вопросы обычные к производителям HCI:
— почему вы против data locality раз уж у вас HCI и вы достоверно можете узнать на какой ноде работает виртуальный сервер, зачем лишний раз ходить куда-то по сети если этого можно не делать?;
— почему бы не сделать нормальный tiering — ram, optane, nvme — могут невероятно ускорить ввод-вывод и для этого не нужно делать весь кластер из них? ведь на самом деле эра AF схд настала из-за того что флеш начал быстро падать в цене и производители не могут или не хотят осилить нормальный tiering;
— почему вы вообще считаете нормальным вспоминать и даже предложить использовать аппаратные raid-контроллеры зная какое количество проблем они создают в реальной жизни и то что ваш софт в принципе не сможет понимать что происходит с дисковой подсистемой. Как не плохой пример можно вспомнить zfs которому практически 15 лет и уже тогда люди поняли что овчинка не стоит выделки и намного надежнее и проще работать с устройствами для хранения данных напрямую.

Я ничуть не умаляю ваших достижений — это на самом деле круто что вы делаете такие системы, тем более в рамках текущей политической ситуации такие решения могут быть хорошим выбором, но безапелляционность некоторых утверждений ставит прямо таки в тупик.
Можно взять лучшее что уже придумали сейчас другие, если появятся идеи как сделать лучше — доработать, но местами выглядит так что некоторые решения принципиально не хотят использовать только из-за того что их ранее придумал вендор X.
Ситуация прям напоминает то что происходит на рынке электрокаров — есть отличное решение, которое по совокупности всех факторов гениально, но при этом все вокруг упорно пытаются сделать так что только бы было так не у того кто делает качественное и успешное решение.

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


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

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


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


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


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


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

Интересны подробности по внутреннему устройству ARDFS и как она работает с метаданными. Из этого будет понятнее про надежность/ненадежность.

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


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


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


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


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

Я правильно понимаю что служба RCD тоже распределенная?
Каким образом защищаются от потери сами метаданные? Тоже дублированием? С каким RF?
Предусмотрено ли кеширование метаданных на флеш при шпиндельных конфигурациях нод в кластере, что может быть критично при больших конфигурациях?

А давайте в комплекте с СХД обычными прикладывать лицензии на VSAN?
Для вас технически не в убыток, а покупателям СХД приятно и есть возможность поиграть.
Из гипервизоров только KVM я так понял?

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


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

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