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

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

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

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

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

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

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

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

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

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

Используй iSCSI multipathing

Изучаю...

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

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

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

NR-N4860 + SNT-3051SS

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

mdadm

FCoE

Изучаю...

Неет.

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

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

NR-N4860 + SNT-3051SS

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

mdadm

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

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

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

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

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

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

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

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

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

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

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

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

За 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.

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

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

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

тот же LVM

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

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

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

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

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

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

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

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

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

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

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

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

(c) DRBD

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

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

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

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

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

http://fghaas.wordpress.com/2011/11/29/dual-primary-drbd-iscsi-and-multipath-...

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

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

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

В общем, в случае использования 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

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

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

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

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

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

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

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

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

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

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

это где там написано про снапшоты лвм?

это для сравнения

У меня одно из хранилищ сделано именно на 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, Спасибо! Когда дело дойдет до реализации не откажусь от конфигов.