fcoe коммутатор

В пределах 1-2-3 стоек дешевле и лучше twinax кабели юзать, а не оптику. Хотя при ценах на твинаксы в этом начинаешь сомневаться.

Медь в плане RJ45 использовать категорически нельзя т.к. добавляет латентности и очень жрёт энергию на 10Гбит, поэтому их никто особо и не юзает.

• r/s = 1.49req/s - интенсивность чтения с диска;
• w/s = 63.67req/s - интенсивность записи на диск;

• avgqu-sz = 0.15reg - средний размер очереди на диск;
• svctm = 2.03ms - время выполнения операций на диске;
• await = 8.83ms - полное время ответа от диска;

хочешь дешево — бери iscsi.

хочешь относительно дешево, но с минимальным latency и наилучшей неджностью — бери fc.

(c) fcoe коммутатор (комментарий)

В случае с FC непонятно как реализовывать СХД. Если я правильно понимаю, то программные таргеты и инициаторы есть только в iSCSI.

Если я правильно понимаю, то программные таргеты и инициаторы есть только в iSCSI.

Неправильно понимаешь. Программных таргетов есть и не один. Для FC инициаторы вообще не нужны - воткнул карту в свич и у тебя появились /dev/sdX, никаких лишних телодвижений и утилит, в отличии от.

Встроенный в ядро - http://linux-iscsi.org/wiki/Target, читай, впитывай. С 3.9 поддерживает даже 16Gbit FC карты. Я юзаю внешний SCST http://scst.sourceforge.net/

Напрямую не сравнивал, так сложилось исторически. В LIO также есть и FCoE таргет. Скорости у них более чем приличные.

хочешь относительно дешево, но с минимальным latency и наилучшей неджностью — бери fc.

Это не более чем заблуждение. iSCSI дешевле только в виде 1Гбит.

Для FC инициаторы вообще не нужны - воткнул карту в свич и у тебя появились /dev/sdX

• Для таргета таже самая плата используется, как я понял, что и для инициатора (т.е. как wi-fi хочешь клиент, хочешь точка-доступа);
• А имена /dev/sdX имеется возможность назначать, иначе в них на гипервизоре запутаешься.

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

есть два «но». вы указали iops, но не throughput. может, вы блоками по 1Гб пишете, кто вас знает. Но при таких сервис таймах это маловероятно, скорее стандартные 8к в среднем. также важно, чтобы вашему приложению не сильно плохело от повышения latency, хотя в пределах пиковых 10ms ее скорее всего получится удержать (если не пускать сторедж через общую data сеть).

а зачем вам вообще сторедж? вы написали только про абстрактный «более удобный менеджмент» при 1 или 2 или 3 серверах. выиграете вы, честно говоря, мало, денег потратите порядочно. iscsi это отдельный геморрой, fc лучше но тоже... в чем суть?

Для таргета таже самая плата используется, как я понял, что и для инициатора (т.е. как wi-fi хочешь клиент, хочешь точка-доступа);

таргент на аррее, или ты хочешь из линукса fc таргет сделать?

А имена /dev/sdX имеется возможность назначать, иначе в них на гипервизоре запутаешься.

udev же. по lunid привязка.

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

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

а зачем вам вообще сторедж? вы написали только про абстрактный «более удобный менеджмент» при 1 или 2 или 3 серверах. выиграете вы, честно говоря, мало, денег потратите порядочно. iscsi это отдельный геморрой, fc лучше но тоже... в чем суть?

Удобный менеджмент. Планируется расширить парк гипервизоров. Кол-во доменов будет расти. Для удобства перемещения доменов между гипервизорами.

Для таргета таже самая плата используется, как я понял, что и для инициатора (т.е. как wi-fi хочешь клиент, хочешь точка-доступа);

Та же, переводится в режим таргета и всё. Потом ядру указываешь что отдавать такое-то блочное устройство через такие-то WWN (это типа мак адреса, но у FC) и всё, больше ничего не надо. Инициаторы его увидят.

А имена /dev/sdX имеется возможность назначать, иначе в них на гипервизоре запутаешься.

Это уже к FC отношения не имеет - это удел udev и прочих линуксовых утилит. Какие udev-правила нарисуешь, так и будет. По дефолту есть директория /dev/disk в которой по ранзым признака сгруппированы симлинки на девайсы. По uuid ФС, по сгенерированному id, еще по каким-то.

А вообще если кластер ограничится 5-10 серверами и есть возможность взять брендовое хранилище то дешевле всего и лучше будет SAS. А вот построить на его основе хранилище не получится т.к. таргетов можно сказать что и нет (в scst есть какой-то бета качества таргет для SAS Marvell, я такое в продакшен не пущу).

А FC таргеты, наоборот, самые оттестированые и проработаные.

или ты хочешь из линукса fc таргет сделать?

Я изучаю информацию и мнения, возможно ли это. Что бы выработать достойный вариант.

udev же. по lunid привязка.

К примеру, в случае с iSCSI, virsh может подключить том не зависимо от того на каком гипервизоре он поднимается главное что юбы у гипервизора был доступ в сеть данных. В случае с FC уровень ниже. Мне пока не понятно как в этом случае удобно управлять этой ситуацией.

из сообщения не понял причём FCoE и iSCSI ???

Что первый что второй - костыли с оверхэдом поверх существующей технологии.

Рекомендую е мучится и взять Coraid с AoE :)

Это уже к FC отношения не имеет - это удел udev и прочих линуксовых утилит. Какие udev-правила нарисуешь, так и будет. По дефолту есть директория /dev/disk в которой по ранзым признака сгруппированы симлинки на девайсы. По uuid ФС, по сгенерированному id, еще по каким-то.

А как принято в таком случае разруливать миграции виртуальных доменов между гипервизорами, если вся сетевая логика заканчивается на FC HBA. Если домен уезжает,то и его /dev/sdX должен поехать за ним. Не править же на каждом гипервизоре udev правила.

Да, признаю каламбур в описании топика.

Каламбур не каламбур, интересно какой ориентации сторадж то нужен ? Блочный или файловый, от того и плясать :)

Блочный или файловый, от того и плясать :)

Блочный

Это уже у «ваших линаксав» нужно спрашиваться, всё зависит от того, как будут использоваться ЛУНы экспортируемые.

Я юзаю vmware в качестве гипервизора, который наворачивает поверх ЛУНа кластерную ФС VMFS и все хосты ее с этого луна одновременно монтируют.

Ты можешь нарезать поверх ЛУНа каким-нибудь LVM тома, отдать их виртуалкам, и они будут виндны со всех хостов. Главное чтобы их не юзал более чем один хост одновременно :)

Или просто использовать уникальный ID луна в /dev/disk для доступа к нему, у всех хостов он будет идентичен.

Как вариант - тоже навертеть кластерную ФС типа GFS или какие там сейчас есть, я не особо в курсе и хранить образы ВМ на них. Но как там со скоростью будет я хз.

Но как там со скоростью будет я хз

Плохо

Что первый что второй - костыли с оверхэдом поверх существующей технологии.

Первый относительно второго очень неплох, он не хуже самого FC, в принципе. И, я думаю, будет потихоньку давить ФЦ в будущем засчет удешевления и унификации сетей. Оно в итоге всё равно придет к converged сетям где сети хранения и данных будут едины. Экономически выгодно, значит так и будет.

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

Но я бы сам и не стал так юзать, проще на таргете поверх массива нарезать LVM и их уже экспортировать, а на хостах обращаться к ним через /dev/disk по уникальным именам.

Но я бы сам и не стал так юзать, проще на таргете поверх массива нарезать LVM и их уже экспортировать, а на хостах обращаться к ним через /dev/disk по уникальным именам.

Я просто мыслил по другому, каждой машине свой LUN (если я верно терминологию употребил). Ваш вариант с LVM логичен.

Ну если ты планируешь мигрировать ВМ с хоста на хост, то все ЛУНы должны быть видны со всех хостов. Как эти ЛУНы будут организованы - дело уже десятое. Можно нарезать LVM тома на таргете и экспортировать их как отдельные ЛУНы, либо экспортировать весь массив и нарезать его LVMом уже на хостах.

Правда как в таком случае будет отрабатывать добавление нового тома не совсем ясно, я с LVM не особо работал. Наврное можно добавить на одном хосте а с других пересканировать тома.

В общем, нарезка на таргете выглядит более удобной.

Я изучаю информацию и мнения, возможно ли это.

возможно. в линуксе норм.

Мне пока не понятно как в этом случае удобно управлять этой ситуацией.

тебе blind_oracle плюс-минус обьяснил.

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

каждой машине свой LUN

каждой _виртуальной_ машине.

AoE на 10GbE уделывает FC :)

Ну да, а много вендоров железа и софта его поддерживают, можно узнать? :) Если в перспективе развитие сети, то маргинальные технологии не самый лучший выбор.

val-amart, расширенные данные за сутки с гипервизора:

• r/s = мин - 0 rps, сред - 1,52 rps, макс - 75,31 rps
• w/s = мин - 2,15 rps, сред - 41,25 rps, макс - 181 rps
• await = мин - 1,23 rps, сред - 8,94 rps, макс - 58,08 rps

Осмыслив предидущие советы и комментарии выработал следующий набросок топологии сети данных.
Основные моменты функционирования:

• В качестве среды, по рекомендации val-amart, выбрана медь, 1Gb до гипервизоров и c запасом пропускной способности 10Gb до СХД;
• iSCSI multipatch через две независимые сети данных;
• В качестве сетевых карт выбрана модель Intel X540-T по рекомендации madgnu;
• В качестве iSCSI таргета, по рекомендации blind_oracle выбран LIO;
• В качестве операционной системы iSCSI таргета выбран Debian stable;

Неопределено:

• Не выбрана модель коммутатора. Прошу совет в выборе;
• Окончательно не выбран SATA или SAS, а как следствие материнская плата. Требуются доп. тесты с учетом проектируемой нагрузки;
• Окончательно не выбран процессор для СХД. Прошу совет в выборе;
• Концепция отказоустойчивости iSCSI таргета. (Размышляю над несколькими вариантами, в одном из них классический DRBD);

Критикам:
Данная концепция SAN не намного превосходит прямые DAS системы по степени отказоустойчивости, но и не вносит (если пренебречь увеличением кол-ва звеньев) видимых неудобств, которые кстате компенсируется (по моему мнению) повышением удобств эксплуатации дисковых массивов.

Буду рад конструктивным комментариям!

В качестве среды, по рекомендации val-amart, выбрана медь, 1Gb до гипервизоров и c запасом пропускной способности 10Gb до СХД;

Смысла делать 1Гб до свича и 10Гбит до хранилки нет, делай сразу везде 10Гбит. И делай не обычной медью (витухой), а через SFP-кабели twinax - карты X520-DA2 я их юзаю уже пару лет - всё идеально.

Еще раз повторю - витуха добавляет ненужную латентность и не дает свободы маневра (заменить SFP+ twinax на оптику дело пары минут)

Не выбрана модель коммутатора. Прошу совет в выборе;

Тут всё сильно зависит от денех. Я бы брал Cisco 4500-X парочку в VSS, но это ~750тыс.руб за обоих. Если денех стока нет или любишь экстрим, то упомянутые уже D-Link DXS-3600-16S (там 8 портов SFP+ на рыло, можно модулем до 16 расширить).

Окончательно не выбран SATA или SAS, а как следствие материнская плата. Требуются доп. тесты с учетом проектируемой нагрузки;

SSD бери. Сейчас цены на Intel DC S3700 достаточно гуманные, а надежность у него конская, 5 лет можно в день по 10 раз его перезаписывать.

Окончательно не выбран процессор для СХД. Прошу совет в выборе;

Xeon E3 v3 на хасвелле. Дохуядерность там не нужна, 4 ядер более чем. А вот частота - самое то, особенно если шифровать то, что хранишь, как я :) На схеме у тебя смотрю мать супермикро под 2011 сокет - не бери их, я сравнивал e5-2620 c e3-1270v3: е5 шифрует в 4 раза медленнее.

Концепция отказоустойчивости iSCSI таргета. (Размышляю над несколькими вариантами, в одном из них классический DRBD);

Вот мой высер на хабре на эту тему, там достаточно подробно описано что и как: http://habrahabr.ru/post/209460/

В качестве среды, по рекомендации val-amart, выбрана медь, 1Gb до гипервизоров и c запасом пропускной способности 10Gb до СХД;

я как-бы как-раз за оптику агитировал. в промежуточном варианте SFP/twinax не вижу особого смысла, не сильно дешевле ведь?

коммутатор такой посоветовать не могу.

Концепция отказоустойчивости iSCSI таргета.

тебе это реально надо? просто следующий логичный шаг — это DR в другой ДЦ и там парный таргет и все прочее. если надо именно no spof в одном дц, то я не уверен как сейчас с мультипасом в линуксе — раньше была масса проблем, особенно в интересующем нас случае — по два раунд-робин паса на два таргента. правда это было год назад и на fc + multipathd. как на iscsi не знаю, наверное от инициатора зависит, но если все пучком, то drdb вполне адекватен для репликации бекенда.

удваиваю Xeon E3 haswell хотя можно и пятилетный б/у-шный зеон, если цель подешевле. главное памяти побольше. можно сэкономить и ssd'шек взять только несколько под кеш, основную массу забить хоть обычными сата винтами.

в промежуточном варианте SFP/twinax не вижу особого смысла, не сильно дешевле ведь?

Если брать коротковолновые лазеры, то, в общем, более менее сравнимо (твинакс дешевле всего раза в два). Если длинноволновые - то уже твинакс дешевле будет раза в три-четыре. Это если считать модули от дэлинка, если цыскины - то там разница еще больше.

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

Гонял на днях линух-линух через 2хFC 8Gb как раз в multipath round-robin - всё работало нормально, мучил через FIO.

При таком раскладе сеть данных получается на вырост. Не только мои скоромные требования протянет, но многократное увеличение сверх этого. А теперь по тексту:

Смысла делать 1Гб до свича и 10Гбит до хранилки нет, делай сразу везде 10Гбит.

Это наверно больше имеет смысл если SSD (о чем я уже задумался) использовать на iSCSI таргете.

заменить SFP+twinax на оптику дело пары минут

• В таком случае прикупаем SFP модули и оптический патч-корд, а twinax кабели это сразу SFP+кабель?
• А если это все сразу на оптику перевести, то на сколько стоимость увеличится, что необходимо из оборудования?

Если денех стока нет или любишь экстрим, то упомянутые уже D-Link DXS-3600-16S (там 8 портов SFP+ на рыло, можно модулем до 16 расширить).

Деньги не обсуждаю, необходимо технологии и устройства выбрать на чем решать, а затем аргументировать. Dlink, честно страшно для сети данных!

Вот мой высер на хабре на эту тему,

Ознакомлюсь.

я как-бы как-раз за оптику агитировал

А twinax схожими характристиками обладет?

Вот мой высер на хабре на эту тему, там достаточно подробно описано что и как: http://habrahabr.ru/post/209460/

Почерпнул идею для каждого LUN свой адрес. Удобнее в pacemaker управлять, к примеру, не всю СХД перекидывать, а только часть LUN.

Это наверно больше имеет смысл если SSD (о чем я уже задумался) использовать на iSCSI таргете.

У тебя даже один SAS диск при линейном чтении перекрывает гигабит в два раза. (Гигабит =~ 110Мбайт\сек, диски 10к оборотов читают под 200Мбайт\сек). Про массивы из таких дисков - вообще молчу. Поэтому делать 1Гбит (пусть даже 3-6 штук) - особого смысла не вижу, только ворох кабелей и много гемора в работе и настройке такой кучи каналов.

В таком случае прикупаем SFP модули и оптический патч-корд, а twinax кабели это сразу SFP+кабель?
А если это все сразу на оптику перевести, то на сколько стоимость увеличится, что необходимо из оборудования?

Если брать к примеру оптику д-линк (я их на цисках юзаю успешно, пока не подводили, у самой циски некоторых модулей вообще нет, а другие конских денег стоят), то для одного коннекта (до 300метров) тебе надо 2 модуля по ~6 т.р. и патчик оптический ну рублей 400. Итого ну пусть 13 т.р.

Твинакс стоит тысячи 2-4 вроде, это медный провод с 2 сфп на концах. По характеристикам он не хуже, а может и лучше оптики.

Деньги не обсуждаю, необходимо технологии и устройства выбрать на чем решать, а затем аргументировать. Dlink, честно страшно для сети данных!

Мне тоже страшно, поэтому не покупаю :) Тем более они дурных денег стоят сами по себе, непонятно за что. Catalyst 4500-x умеет отказоустойчивость через Virtual Switching System, стоит 370т.р. с двумя БП и 16 портов SFP+. Если посчитать стоимость на порт, то выходит чуть ли не дешевле д-линка. Зачем нужен д-линк тогда - непонятно.

Да, см. выше. Латентность такая же или лучше.

Почерпнул идею для каждого LUN свой адрес. Удобнее в pacemaker управлять, к примеру, не всю СХД перекидывать, а только часть LUN.

Да, как-никак получаем два активных хранилища.

Почерпнул идею для каждого LUN свой адрес. Удобнее в pacemaker управлять, к примеру, не всю СХД перекидывать, а только часть LUN.

и это, после столькоих лет обсасывания тобой этой темы, ты только сейчас «почерпываешь» такие базовые вещи? моё лицо жесточайше ударилось об ладонь.

да, анонимный брат, такой вот он, этот petav

Гонял на днях линух-линух через 2хFC 8Gb как раз в multipath round-robin - всё работало нормально, мучил через FIO.

я имел ввиду случай когда есть два активных путя на один аррей, два на другой, но они неактивны и используются только в случае фейловера. ни через multipathd, ни через veritas нормального фейловера добиться не получилось, тогда докопались до пучка багов в BIO ядра уводящих в панику. мы об одном и том же говорим? редхат сказал бууу это надо все переписывать; чем закончилось не знаю, год назад уволился, доступа в багзиллу больше нет, может, пофикшено но вроде в релизноутах не проскалькивало? полные чейнджлоги я увы давно перестал читать...

просто ТС начал говорить про отказоустойчивость таргета, а по-другому, без полного фейловера на активных путях этого не добиться. можно было бы еще менять «зонирование» при фейле основного аррея, но а) скорость реакции вероятно была бы ниже б) блок девайсы на уровне VFS все равно бы отваливались и в) костыли из кастомных скриптов.

про цену твинакса, да, не знал что разница все же существенная.

У тебя даже один SAS диск при линейном чтении перекрывает гигабит в два раза.

Тогда возникает необходимость увеличивать пропускную способность от коммутатора до СХД. Bonding не работает, что же тогда, или необходимости нет или я что-то недопонимаю.

просто ТС начал говорить про отказоустойчивость таргета, а по-другому, без полного фейловера на активных путях этого не добиться

В случае айскази айпиадрес просто прозрачно перелетает на соседа и делается gratious arp чтобы оповестить всех о новом маке. Инициатор просто реконнектится на тот же адрес и всё. По крайней мере с ESXi такой финт прокатывает.

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

про цену твинакса, да, не знал что разница все же существенная.

Да и вообще в пределах трех-четырех стоек юзать фибер мне кажется незачем. Я бы и FC на твинаксах сделал, но почти все FC карты уже идут в комплекте с трансиверами коротковолновыми - т.е. за них уже один хрен уплочено. Ну и медь не такая нежная как оптика, ее проще разводить.

Почему возникает? 10Гбит тебе будет более чем достаточно.

Операции линейного доступа пусть и достаточно редки при «стандартной» нагрузке, но, например, при резервном копировании ночью тебе 10Гбит очень даже пригодятся если ты тащишь очень большой объем. У меня в свое время на гигабите файловый сервер бэкапился чуть не все выходные.

Так что не стремись, чтобы каналы от СХД до свичей был == сумме каналов от хостов до свичей. Все вместе каналы будут юзаться очень и очень редко, а по очереди - часто.

Бондинг нафиг не нужен с iSCSI, я об этом писал. Настроишь multipathd и хосты будут посылать I/O по очереди в оба канала. В теории получится удвоение полосы. На практике почти так и есть.

можно сэкономить и ssd'шек взять только несколько под кеш, основную массу забить хоть обычными сата винтами.

Можно пару слов о затронутой Вами теме. Нагуглил bcache и dm-cache.

Кэш можно сделать либо силами рейд-контроллера, либо тем что ты нагуглил. Но эффективность кэша сильно зависит от типа нагрузки + кэш требует предварительного «прогревания», то бишь заполнения часто юзающимися данными.

В общем - дёшево, но не всегда эффективно.

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

каких слов ты хочешь услышать? задавай вопросы. если что, я не держу стореджа на линуксе и не могу сравнить bcache и dmcache «вживую», я использую опениндиану iscsi/nfs дома и нормальные арреи fc/ib на работе.

посмотри его профиль нагрузки. это же смешно, скорее всего хватит и пары семитысячников в зеркале. конечно, мы не знаем расспределение random vs linear и размер io, но я уверен даже при наихудшем раскладе достаточно будет raid10 на 4 диска. конечно, если места много не надо (в чем я сомневаюсь) то можно поставить raid1 из ссдшек.

random vs linear

Для невилирования влияния нагрузок друг на друга, я полагаю эти типы нагрузок разнести на разные физические массивы. Под random нагрузки использовать массив 10 из SSD или кеш SSD как Вы советовали выше.

• avgrq-sz = мин - 2.46 sector/request, сред - 23.6 sector/request, макс - 689,49 sector/request - Средний размер запроса

Не заставляй анонимуса биться в исступлении головой об стол. Делай что-нибудь.

.... я все.

Большое спасибо за участие.

Господа, подскажите, в более «домашних» условиях возможно ли использование FCoE без DCB? Одновременно и SAN и LAN займут не более 50% ресурса 10GE-интерфейса, при необходимости можно будет разделить SAN и LAN на отдельные интерфейсы.

Смущает то, что многие пишут, что DCB как бы required для FCoE, однако в моей инсталляции возможности lossless ethernet'а особо и не нужны из-за относительно низкой загрузки интерфейсов.

В качестве таргета какая-нибудь посудина на Linux'е. С обратной стороны пара xen или kvm гипервизоров с небольшим кол-вом гостей.