LINUX.ORG.RU
ФорумAdmin

Концепт-модель. Построение сети данных

 , , ,


1

2

Инициаторы iscsi-initiator-utils и Таргет scsi-target-utils программные. В силу бюджета и желания разобраться с темой.

  • Критерии выбора сетевых адаптеров (Мой выбор пал на что-то из этого списка Intel® 10 Gigabit Server Adapters)?
  • Критерии выбора коммутатора (bonding в сторону Таргет)? ;
  • Критерии выбора CPU для Таргета?
  • Критерии выбора объема памяти для Таргета?
  • Выбор мат.платы для Таргета (С заведомо большим кол-вом SATA интерфейсов)?

С требуемыми IOPS и пропускной способностью не все ясно. Нагрузка смешанная и будет меняться. Необходимо заложить возможность горизонтального расширения.

★★★★★

Последнее исправление: CYB3R (всего исправлений: 4)

1. 10G да, гуд. Ты будешь цеплятся напрямую? Или через свич?

2. Бондинг с ISCSI забудь, работать не будет. Используй iSCSI multipathing.

3. CPU если нет шифрования пофиг какой в общем

4. Память чем больше тем лучше (кэш вещь хорошая)

5. Плата... ну если это относительно бюджетно, то какой-нибудь http://www.supermicro.nl/products/motherboard/Xeon/C600/X9SRi-3F.cfm там 14 SATA суммарно. Но вообще нормальный корпус с экспандером плюс рейд контроллер рулит :)

Можно еще попробовать заморочится с FCoE, оно перспективнее.

blind_oracle ★★★★★
()

а не посмотреть ли в силу бюджета и горизонтального расширения на glusterfs, ceph и lustre?

anonymous
()
Ответ на: комментарий от blind_oracle

Ты будешь цеплятся напрямую? Или через свич?

Кокой-то свич

Используй iSCSI multipathing

Изучаю...

Плата... ну если это относительно бюджетно

Бюджет должен коррелировать с функционалом. Совет принял.

Но вообще нормальный корпус с экспандером

NR-N4860 + SNT-3051SS

плюс рейд контроллер рулит

mdadm

FCoE

Изучаю...

petav ★★★★★
() автор топика
Ответ на: комментарий от petav

Кокой-то свич

Просто если этот свич умеет Lossless Ethernet, то лучше попробовать поднять FCoE

NR-N4860 + SNT-3051SS

Я имел в виду супермикровские, а это какой-то ноунейм я извиняюсь :)

mdadm

Дело хозяйское, разницы в принципе нет

FCoE таргет под линуксом есть в рамках проекта LIO (http://linux-iscsi.org/wiki/Fibre_Channel_over_Ethernet)

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

то лучше попробовать поднять FCoE

А какой ожидаемый профит?

Я имел в виду супермикровские

Приблизительную ссылку на то что Вы имели ввиду можно, для сравнения?

а это какой-то ноунейм я извиняюсь :)

Пока прикидываю стоимость проекта. Решил сэкономить.

petav ★★★★★
() автор топика
Ответ на: комментарий от petav

А какой ожидаемый профит?

Отсутствие оверхеда от IP, TCP протоколов. Только езернет, только хардкор :) Латентность ниже

Приблизительную ссылку на то что Вы имели ввиду можно, для сравнения?

http://www.supermicro.nl/products/chassis/3U/836/SC836BE16-R920.cfm Например такое. У меня стоят пару примерно таких, только с двойными экспандерами, нареканий нет. Но учти что бэкплейны там подключаются по mini-SAS портам, т.е. нужен какой-то HBA или мать с такими портами на борту.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

За LIO спасибо

Native support for the LIO Linux SCSI Target in QEMU/KVM, libvirt, and OpenStack™ makes it an attractive storage option for cloud deployments.

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

[Задумался]Стоит ли держать диски на инциаторах под корень?[/Задумался]

petav ★★★★★
() автор топика
Ответ на: комментарий от petav

Можно и не держать.

Если использовать\придумать удобную систему выделения лунов на таргете (тот же LVM), то вполне можно грузится и с него. Современные карты поддерживают загрузку как с iSCSI, так и с FCoE, сам правда не проверял, но интель про свои 10G карты заявляет именно так.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

тот же LVM

Именно это подразумеваю.

А среда (медь/оптика) передачи влияющая характеристика?

petav ★★★★★
() автор топика
Последнее исправление: petav (всего исправлений: 2)
Ответ на: комментарий от petav

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

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

т.к. избежать потерь в ней судя по всему проще

Аналогично думал, когда задавал этот вопрос.

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

petav ★★★★★
() автор топика
Ответ на: комментарий от petav

blind_oracle, позвольте спросить Ваше мнение на счет отказоустойчивости. При существовании нескольких гипервизоров подключенных к единственному СХД, СХД является тонким местом. Я полагаю, что отказоустойчивость необходимо строить:

  1. на транспортном уровне. Необходимо строить второй транспортный контур, со своими проводами и активными устройствами.
  2. на уровне устройства хранения данных. Мне в голову приходят: DRBD репликация между СХД (не факт что при наличии более двух узлов схема будет простой) и создание raid 1 на стороне гипервизора из дисков принадлежащих разным СХД. В брендовых СХД это все решается на уровне самого СХД. Сконструировано так, что не может стать единой точкой отказа, но стоимость данного решения только для очень крупного бизнеса.
petav ★★★★★
() автор топика
Последнее исправление: petav (всего исправлений: 2)
Ответ на: комментарий от petav

Думаешь, зачем я сказал про распределённые фс и масштабирование, прозревая наперёд, что речь пойдёт о нищехранилке виртуалок? DRBD не может работать больше чем на двух узлах, требует кластерной фс для одновременного монтирования несколькими клиентами, а в синхронном primary-primary режиме представляет собой жалкое зрелище и грозит сплит-брейном. Кроме того, в случае хранения DRBD на самих хостах с виртуалками в асинхронном режиме отпадает надобность в отдельном SAN.

anonymous
()
Ответ на: комментарий от anonymous

DRBD не может работать больше чем на двух узлах

Три узла это сложно и не известно как работает.

DRBD поддерживает только два узла (более сложные конструкции могут строиться с помощью использования drbd-устройства в качестве «локального диска» для ещё одного drbd-устройства).

(c) DRBD

требует кластерной фс для одновременного монтирования несколькими клиентами, а в синхронном primary-primary режиме представляет собой жалкое зрелище и грозит сплит-брейном.

Одновременное монтирование несколькими клиентами не требуется

Кроме того, в случае хранения DRBD на самих хостах с виртуалками в асинхронном режиме отпадает надобность в отдельном SAN.

В таком режиме учитывая, что DRBD из трех узлов еще тот костыль, более двух гипервизоров не возможно подключить в работу. В схеме с СХД, пусть даже нищебродской возможно подключить более 2 гипервизоров. Так же со структурной стороны это намного гибче.

Мне кажется Вы валите все в кучу.

petav ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Чортов форум, не даёт править сообщения.

В общем, в случае использования iscsi поверх drbd, надо заранее знать, что не все таргеты одинаково полезны: http://fghaas.wordpress.com/2011/11/29/dual-primary-drbd-iscsi-and-multipath-...

Кстати, интересно, со времён В связке Heartbeat+DRBD+iSCSI+KVM какая роль у iSCSI? ничего не изменилось?

anonymous
()
Ответ на: комментарий от anonymous

В общем, в случае использования iscsi поверх drbd, надо заранее знать, что не все таргеты одинаково полезны: http://fghaas.wordpress.com/2011/11/29/dual-primary-drbd-iscsi-and-multipath-...

Если в какой-то степени пренебречь живой миграцией, то dual primary не нужен для ha кластера.

Кстати, интересно, со времён В связке Heartbeat+DRBD+iSCSI+KVM какая роль у iSCSI? ничего не изменилось?

Спасибо, перепрочел. Вот кстате и к Вашему комментарию подтверждение. Но в моем случае нужен скорее primary-secondary как и советует nnz

petav ★★★★★
() автор топика
Последнее исправление: petav (всего исправлений: 1)
Ответ на: комментарий от petav

Мне до сих пор интересно, удавалось ли кому-то хотя бы два десятка виртуалок на подобнобном хранилище запускать чтоб они работали как надо, а не «с приемлемой скоростью»? Ну и, кстати, qemu уже давно может миграцию без общего хранилища http://fedoraproject.org/wiki/Features/Virt_Storage_Migration

anonymous
()
Ответ на: комментарий от anonymous

Ну и, кстати, qemu уже давно может миграцию без общего хранилища

Весь диск по сети тянет на второй хост. Думаю производительность внутри домена должна очень сильно проседать. В связи с эти не очень приемлемо.

petav ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Мне до сих пор интересно, удавалось ли кому-то хотя бы два десятка виртуалок на подобнобном хранилище запускать чтоб они работали как надо, а не «с приемлемой скоростью»?

Тут все от мелочей зависеть будет. Естественно в этой конструкции будет оверхед, его нужно верно учесть и заложить в оборудование. Скажу по другому. Если сервер работал впритык на 7 200 rpm, а мы еще слой DRBD положили, даже по быстрой сети, то в соотношении без DRBD c скорость будет приемлемой. Пример грубый конечно, прошу учитывать, но посыл определить можно.

petav ★★★★★
() автор топика
Последнее исправление: petav (всего исправлений: 2)
Ответ на: комментарий от petav

Весь диск по сети тянет на второй хост

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

anonymous
()
Ответ на: комментарий от anonymous

Думается мне, что там производительность будет проседать ровно настолько, насколько даёт прирост кеширование

Позвольте на согласиться. Путь данных увеличивается. Отчасти смотрите на работу lvm-тома в режиме snapshot. Полагаю, что в основе принцип тот же, замедления есть, но гипервизора нет.

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

petav ★★★★★
() автор топика
Последнее исправление: petav (всего исправлений: 1)
Ответ на: комментарий от petav

У меня одно из хранилищ сделано именно на DRBD, правда там не 10G, 6х1G, но сути дела не меняет.

Работает на основе таргета SCST, он наиболее вменяемый из всех на мой взгляд, если не нужен FCoE, там он не доделан. Переключением нод управляет Pacemaker/Corosync.

Синхронизация DRBD идет через бонд 4х1G в режиме balance-rr с задранным tcp_reorder в sysctl, под тестам выдает почти 4Gbit/s без проблем.

Причем на нодах создано два массива - один активен на одной, второй - на другой. Получается распределение нагрузки, перекрестная репликация.

У каждого массива свои IP адреса (по 6 штук на каждый интерфейс).

Если одна из нод падает, то менеджер кластера переводит DRBD этого массива в активный режим и поднимает его IP адреса у себя, создает iSCSI таргет, луны и т.п.

Инициаторы (ESXi) ничего заметить не успевают.

Почти все это делается штатными средствами Pacemaker, разве что пришлось дописать ресурсы для SCST.

Если нужны будут подробности - скину конфиги и т.п.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

blind_oracle, Спасибо! Когда дело дойдет до реализации не откажусь от конфигов.

petav ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.