Как стать автором
Обновить

Комментарии 43

Спасибо, интересно смотреть на разнообразные системы.
Отличное описание системы, спасибо :)
Спасибо, стараюсь :)

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


А тесты производительности документировали? Статью планируете?

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

Что будет через год — покажет время, может и будет что интересного рассказать, а может и нет :)

Хорошо, тогда не касаясь глубоко "сферических коней в вакууме", производительность в тех тестах, что были проведены, полностью устроила?


Интересно еще поведение системы в случае выхода из строя двух контроллеров. А то доступные данные разнятся. Система продолжит работать, но отключит write cache? Или все же уйдет в некий сервисный read only режим до исправления ситуации?


По поводу выхода из строя одного контроллера. Я правильно понимаю, что IP адреса и port WWN-ы (для FC) переезжают в этом случае на другой контроллер? Что касается FC, на портах используется NPIV? И если да, то как обстоят дела с возможностью прямого подключения хостов к портам Infinibox без использования FC свитчей?


Есть прогнозы по появлению не просто репликации (синхронной\асинхронной), а функционала metro кластера между двумя массивами Infinibox?

полностью устроила

Бизнес — устроила, инженеры хотят NVMe :)

в случае выхода из строя двух контроллеров

Система переходит в сервисный режим

переезжают в этом случае на другой контроллер?

Нет

на портах используется NPIV

Нет

прямого подключения хостов к портам Infinibox

Тут не подскажу, не пробовал.

metro кластера между двумя массивами Infinibox

Про это, к сожалению, ничего не говорят.

По поводу переезда wwn есть упоминание в статье Василия Кострюкова (“Архитектура хранения для цифрового предприятия”), на которую вы сослались в данной статье. Т.е. все таки в случае выхода из строя одного контроллера часть путей от хоста теряется?

Честно признать, не знаю о какой настройке виртуального WWN для физического говорит Василий, при возможность уточню у него. По факту настроек для FC никаких и нет, есть лишь одна красивая картинка со схематичным представлением FC сети, из которой можно или узнать подробности о портал или их отключить. Но уточню, что имелось ввиду. Опять-таки — могли быть какие то изменения в ПО по этой части, всё-таки его статье почти 2 года.

Возможно отдельной настройки и нет. А вот как отрабатывается авария одного контроллера на front-е я думаю интересно было бы узнать. И не только по FC, но и по IP (на массиве же и NAS функционал есть).

Да, пообщался с Василием, он подтвердил — для блочного доступа просто отваливаются пути, реализация с виртуальными адресами была раньше, но от неё отказались, а вот адреса для файлового доступа — переезжают на живые контроллеры.
А клиенты к этой железке могут по Infiniband приходить? Или только Ethernet?
Нет
А что помешало? Infiniband-овское железо внутри всяк есть, почему не сделать (как опцию, ок) возможность подцепляться к железке и снаружи быстрым интерконнектом?
Наверное это уже не совсем по адресу вопрос :)
Попробуйте ниже у Odondon_Labama спросить, он всё-таки Storage guy @ INFINIDAT :)

Это уже скорее из разряда религиозных войн :). Но если вы плотно работаете с Infiniband, то может объясните (с вашей точки зрения) в чем его "серебряная пуля" по сравнению со старым добрым Fiber Channel Protocol, давно прижившимся и ставшим стандартом де-факто в сетях хранения данных? И почему компания Infinidat должна срочно все бросить и добавить в новую прошивку поддержку подключения хостов по Infiniband?

Ну, можете сходить вот сюда — www.snia.org/sites/default/files/SDC15_presentations/datacenter_infra/RupinMohan_NextGeneration_Low_Latency_SAN_SHARE_FINAL.pdf и посмотреть, что пишут ребята из HP. Содержательно — на infiniband-подключенном железе они видели задержку в 25 микросекунд. А на fiber channel — 50. По моим тестам, сам по себе инфинибанд имеет задержку в 1.5 — 2.5 микросекунды. Как следствие — быстрый кеш (NVMe) за инфинибанд с локальной машины может быть вынесен, а за FC — нет, он уже перестанет быть таким отзывчивым.

Вы как то отклонились от темы :). Про вынос "быстрого" кэша на NVMe на сторону СХД тут речи вроде бы не шло. Да и у Infinibox такого функционала не заявлено. У меня не было возможности тестировать отдельно Infiniband, но совершенно точно в реальных инсталляциях он встречается крайне редко в качестве интерфейса подключения серверов к СХД. Хотя еще лет 8-10 назад пророчили, что Inifiniband полностью заменит собой и Ethernet, и FC. Скорее всего есть вполне объективные причины, почему этого до сих пор не произошло. При этом Infiniband бесспорно занял определенную нишу в отрасли. Чаще именно во внутри кластерных соединениях между нодами.

есть ряд причин, например, 1) соединение между контроллерами реализовано по IB без коммутаторов, напрямую каждый с каждым. Если делать внешнее подключение, то либо коммутатор, либо ставить еще карты. То есть будет нужен другой формфактор контроллера, дополнительное место в стойке. 2) любую дополнительную опцию надо тестировать, то есть выше стоимость системы (кроме железа) и дольше тестирование и разработка 3) реальный спрос на IB подключение на Enterprise рынке мал, да и в облаках тоже, вот HPC другое дело
Я как раз с HPC-колокольни и поглядывал на эту тему. Отсутствие коммутатора многое объясняет, да. Хотя на мой (субъективный) вкус — экономия тут исключительно на спичках — сексодром с драйверами инфинибанда командой уже, вероятно, пройден, а вот из разделения рынка по потребностям следует предложение — выпустите отдельный вариант стораджа для HPC-сегмента. Или по крайней мере анонсируйте и посмотрите, найдутся ли под это потенциальные клиенты.
Обычно разработка работает от обратного, оценивается возможный рост продаж от реализации фичи/интерфейса/продукта, оценивается время и сложность разработки и выбирается то, что можно быстро разработать и максимально увеличить объем продаж.
У HPC, как правило, нет требований к продвинутым фичам массива, основные критерии это производительность на поток+цена. Есть сектора HPC, где и функционал нужен получше и надежность (например медицина), но там и IB реже бывает.
Я правильно понимаю, что IP адреса и port WWN-ы (для FC) переезжают в этом случае на другой контроллер?

В случае отказа одного контроллера (или конкретных сервисов на нём)
IP адреса переедут довольно быстро
FC порты — нет
функционала metro кластера между двумя массивами Infinibox?

В версии 5.0 — ETA — 2018-2019. Любые апгрейды бесплатны и недеструктивны.

*INFINIDAT employee here, но лучше призвать Василия
Я думаю, что метро и быстрее появится, Алексей, звони, расскажу :)
насчет мнения людей, работающих больше года с сиcтемой, из тех кто точно есть на хабре, можно пригласить msolovyev в каменты :)
Большое спасибо за обзор, но могли бы Вы рассказать и о схеме подключения SAS полок к storage nodes?
Вас что то конкретное интересует? SAS-коммутаторы уже встроены в сами полки, от каждой полке к каждому серверу идёт линк. Все серверы соединены со всеми полками. Собственно всё :)
В таком случае, правильно я понимаю, что в storage node предусмотрено 12 SAS портов для подключения дисковых полок (кажется, максимально число в стойке 6)?
В наших нодах по 4 порта
Максимальный полезный объём F2000 серии — 330Тб в 18U, так что к ней 6 полок точно не подключается, возможно у F4000/F6000 и больше портов на хостах.
Спасибо, но, к сожалению, ясности не появилось (
ок, там для F6000, что несколько сложнее.
В случае F2000, как у Онланты, просто от каждого контроллера SAS кабель идет к каждой полке, собственно все!
Добавить 1000 хостов
Можно еще посредством Infinishell это сделать, там очень простой скриптовый неязык вида:

host.create name=NAME
host.add_port host=NAME port=PORT
Про Infinishell я упоминал в видео, но на мой взгляд это всё-таки средство управления для любителей, в противовес GUI.
На самом деле даже не смотрел на его возможности в плане обработки строк, циклов, регулярных выражений и тд, именно те средства, которые позволяют упростить работу с большими объёмами хостов/лунов и т.д. Тем более, API всё-таки позволяет производить это удалённо, а не из интерфейса массива. Но да, шел удобный и приятный для выполнения простых и рутинных задач, если вы конечно любите консоль :)
А, нет, там нету возможностей, которые вы упомянули — это ненастоящий скриптовый язык.

Мы его используем таким способом: на баше / питоне / любом удобном языке генерируем текстовый файл, в котором требуемые инфинишелловые команды, например тысяча команд по созданию хоста, как в вашем примере. И потом infinishell -c FILE.

Она тоже удаленно запускается, кстати, это вполне такой standalone клиент. Мы даже инсталлятор под ОС виндовс сделали. (Или можно прицепиться к нашему PyPI и pip install infinishell, в любой ОС, CI даже на Солярисе настроен.)

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

Система действительно интересная, синтетические тесты для Инфинидат скорее будут некорректны, т.к. будут нагружать 22Тб кеш а как его "пробьют" — а за ним уже нлсас, но "пробить" его проблематично. Основная нагрузка по латенси (до 20-25мс) у нас происходит при резервном копировании, что логично, т.к. данные качаются минуя кеш, но при этом системы все работают стабильно и без просадок. Мы довольны. Есть некоторые минусы самой операционной системы (нельзя погасить из веб морды отдельные порты, допустим 10GE) и ещё не полная интеграция с забиксом, но это некритично. Тот же ИнфиниМетрик даёт историю по нагрузке- что удобно.

При резервном копировании размер блока как правило в районе 1МБ, обычно задержки выше именно поэтому. Насчет Zabbix, я и темплейт сделал и скрипты для discovery и population, так что зовите в гости и все сделаем в лучшем виде. Потом можно будет все это и на GitHub запилить
Тестировал это решение 2 года назад. На сколько я понял, там обычные сервера DELL используются. По факту это ceph допиленный и разработан интерфейс управления СХД. Работая с этим решением, ты получаешь сразу одно общее дисковое пространство и не можешь распределять нагрузку, т.е. получать гарантированные IOPS на конкретный объём.

Интересно было бы получить результат теста в разнородной среде запросов к СХД. Т.е. типичное состояние хранилки для хостеров.

У инфинидат интересная финансовая политика. Когда можно брать большую железку, а оплатить только часть её, пока не загрузил её достаточным количеством данных.
Станислав, там внутри точно не ceph :) Но OpenStack поддерживает, да
Коллеги, вопрос немного не в тему — хочется занедорого(с) хранилище с растущим raid-ом (чтобы можно было на лету добавлять дисков), запросом на последовательную запись непрерывного потока данных (до 500 мегабайт в секунду, в несколько потоков), и редкое и квазислучайное чтение (раз в несколько суток вычитать по 10-20 гигов). На какие решения и технологии кто бы предложил посмотреть внимательно?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий