Pull to refresh

Comments 16

Из текста не особо понятно как происходит защита данных на дисках в рамках одной ноды.


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

Все промежуточные действия над данными алгоритмом FlexiRemap выполняются в оперативной памяти контроллера. Но массив выдаст подтверждение хосту об успешном завершении операции только после физической записи на SSD.

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


Что делать если производительности пары контроллеров не хватает? Какие варианты масштабирования?

Если формально подходить к вопросу, то да, на некоторое время данные помещаются в ОЗУ ноды. Но подтверждение записи выдается только после физического размещения блоков на накопителях. Поэтому такой подход называют «без использования кэша». Низкие задержки достигаются за счет скорости обработки блоков ввода/вывода.
Защита данных в рамках ноды достигается за счет использования контрольных сумм (фактически — минус объем одного SSD в группе). Но алгоритм иной, не как в RAID.
Система пока что не масштабируется выше двух контроллеров. Но разработки в этом направлении ведутся.

Для чего данном случае контрольные суммы? Это erasure coding? Тогда какая схема защиты используется?
Контрольные суммы могут служить вообще для проверки целостности записанных блоков T10-DIF, но при этом никак не обеспечивать защиту данны при выходы из строя SSD.
EC опять-таки накладывает задержки, особенно при записи мелкими блоками.


Низкие задержки достигаются за счет скорости обработки блоков ввода/вывода.

Это не ответ. Объединение данных в цепочки подразумевает храние их в памяти. По вашему же тексту, подтверждения хосту нет пока данные не попали на SSD.

Это не ответ. Объединение данных в цепочки подразумевает храние их в памяти. По вашему же тексту, подтверждения хосту нет пока данные не попали на SSD.

Паспортное значение latency для SSD ~40us. По приведенным тестам выше у массива при записи latency ~90us. Это и есть накладные расходы на формирование цепочек из поступающих блоков пока данные в ОЗУ ноды, но еще не на накопителе.
Контрольные суммы могут служить вообще для проверки целостности записанных блоков T10-DIF, но при этом никак не обеспечивать защиту данны при выходы из строя SSD.

Т.е. вы не верите, что выдернув любой SSD, массив не развалится?

Забавная аргументация. Вы написали пост, в котором вроде как объясняете технологические особенности продукта. При этом на конкретные вопросы про принципы работы ответить не можете.
Каким образом у нас 890 микросекунд превращаются в 90 микросекунд?

Каким образом у нас 890 микросекунд превращаются в 90 микросекунд?

Пардон, нулем ошибся. Да, 890us задержка
SSD Enterprise класса. Чаще всего с интерфейсом SATA, т.к. работы с двумя контроллерами не требуется. Имеются также модели All Flash массивов на базе NVMe дисков.

Хочется услышать уточнения по этим моментам? То есть вы используете обычные Sata диски и ставите переходник Sata<-->SAS и называете это Enterprise?

Умеет ли СХД NVMe over Fibre Channel?
В серверном сегменте под «обычными» SSD понимают консьюмерские/десктопные модели (аля Kingston или A-Data). Enterprise SSD — это SSD, рассчитанные на серьезные нагрузки, например, Intel, HGST и пр. Диски подключаются напрямую без каких-либо переходников SATA-SAS.
Умеет ли СХД NVMe over Fibre Channel?

Текущие модели нет. Сейчас активно разрабатывается решение NVMe-oF
Умеет ли СХД NVMe over Fibre Channel?

Текущие модели нет. Сейчас активно разрабатывается решение NVMe-oF


Так это не одно и тоже разве?
Не совсем. В качестве транспорта не обязательно используется Fibre Channel.
Интересная у вас железка. Мы можем рассмотреть ваше решение для задач нашей компании. Если будет интересно сотрудничество с российским ретейлом напишите мне в личку.
А зачем проверка пульса по ethernet? Латенси больше и не ясно, допустим IB не работает, а по ETH все ок. Что дальше?
Основной канал для обмена между нодами конечно же IB. Но его как-то нужно дублировать «за недорого». Пульс же все равно с некоторыми интервалами измеряется, latency в Ethernet этому не помеха.
Если IB выйдет из строя, одна из нод перейдет в offline, т.к. синхронизация будет недоступна. Если же Ethernet сломается, то просто alarm.

Вы не ответили на вопрос. ИБ56 Гб, эзернет 1гб или 10? что дублирует в итоге то?
Я знаю про распределение контрол трафика и дата. Но не очень пока понимаю суть у вас.
Более того с иб можно и qos выделить для контрол трафика.

Еще раз. Основной канал обмена информацией между нодами — это IB 56G. Канал теоретически может выйти из строя. Об этом нужно как-то узнать. Нужен резерв исключительно для проверки пульса. В качестве такого резерва используется 1G Ethernet.

Если эзернет только для ссш, тогда не ясно к чему про дублировать за недорого.

Sign up to leave a comment.