Еще до праздников коллега Virus хотел поведать нам эту историю, но из-за технических причин публикация задерживалась 🙂
Речь пойдет о том, как сделать из 1 компьютера и двух дешевых гигабитных свитчей “D-Link DGS-1005D” дисковый типа “массив”, застраховавшись от наиболее вероятных аварий – гибели диска и гибели блока питания дешевого свитча. Наличие быстрого и дешевого D-Link позволит для рабочего траффика использовать медленные и дешевые 100mbit Cisco Catalyst с поддержкой vlan и прочих радостей жизни, а для миграции и доступа к “массиву” дешевые D-Link. Конечно, вы не будете застрахованы от выгорания материнок, БП или иных запчастей в этом “массиве”. Впрочем, эта проблема решаема, но она выходит за рамки данной статьи точно так же, как и использование FC карт вместо ethernet или загрузки с usb-flash. Хотя все эти темы очень интересны, и скорее всего будут мной описаны, после того как “сервер” с корнем на флешках отработает пару месяцев, я расскажу про него и ещё несколько упомянутых извращений.
Также стоит помнить, что если у вас будет корень на рейде, то вы ограничены только первым рейдом + старым форматом метаданных+скоростью одного диска, то есть в случае если есть 3 или более диска, то оптимально для корня использовать пару флешек, объединенных в рейд-1, а остальное использовать в виде raid5 (в силу ряда очевидных причин с софт-raid5 загрузиться нельзя).
Начнем
Сперва соединим каждый свитч с каждым компьютером(iSCSI+2ESXi), установим систему (gentoo linux) и пропишем конфиги:
/etc/modprobe.d/bond.conf
alias bond0 bonding
options bond0 mode=0 miimon=100
# ниже описание параметров, возможно вам пригодится:
# arp_interval:arp interval in milliseconds (int)
# arp_ip_target:arp targets in n.n.n.n form (array of charp)
# arp_validate:validate src/dst of ARP probes: none (default), active,
backup or all (charp)
# downdelay:Delay before considering link down, in milliseconds (int)
# lacp_rate:LACPDU tx rate to request from 802.3ad partner (slow/fast) (charp)
# max_bonds:Max number of bonded devices (int)
# miimon:Link check interval in milliseconds (int)
# mode:Mode of operation : 0 for balance-rr, 1 for active-backup, 2
for balance-xor, 3 for broadcast, 4 for 802.3ad, 5 for balance-tlb, 6
for balance-alb (charp)
# primary:Primary network device to use (charp)
# updelay:Delay before considering link up, in milliseconds (int)
# use_carrier:Use netif_carrier_ok (vs MII ioctls) in miimon; 0 for
off, 1 for on (default) (int)
# xmit_hash_policy:XOR hashing method: 0 for layer 2 (default), 1 for
layer 3+4 (charp)
/etc/conf.d/network
ifconfig_eth1=”10.2.123.44 netmask 255.255.255.0″
defaultroute=”gw 10.2.123.254″
interfaces=”bond0″
ifup_bond0=”modprobe bonding; ifconfig \$int up; ifenslave \$int eth2;
ifenslave \$int eth3″
ifconfig_bond0=”10.2.254.1 netmask 255.255.255.0″
ifdown_bond0=”rmmod bonding”
/etc/tgt/targets.conf
default-driver iscsi
<target iqn.2008-09.com.workdesk:plain.l4t>
backing-store /raid/iscsi
incominguser esxiuser secur789
MaxConnections 10
write-cache on
</target>
Создаем софтрейд, как это сделать тема многократно раскрыта, например, тут http://en.gentoo-wiki.com/wiki/RAID/Software
Сохраним конфигурацию, чтобы имена не съехали, и укажем адрес куда
слать уведомления:
mdadm --detail --scan >> /etc/mdadm.conf
echo "MAILADDR admin@domain.com">>/etc/mdadm.conf
перезапускаем демон mdadm и проверяем емайл-уведомления
mdadm -Fs1t
Cоздаем битмап, чтобы рейд пересобирался быстрее в случае аварий, ключевое значение “131072”. Чем больше куски, которые контролируются, и следовательно тем меньше паразитная нагрузка на диски (и очевидно меньше тормозит), но тем дольше будет синхронизация, так как большего размера куски (это 128Мб, можно делать куски до 256).
mdadm --grow --bitmap=internal --bitmap-chunk=131072 /dev/md127
Создаем файл 200G для iscsi данных, (тут я должен вам напомнить, что
если версия esxi меньше 5, то делать файл более 2ТБ категорически
нельзя).
dd if=/dev/zero of=/raid/iscsi seek=209715200 bs=1024 count=1
Прописываем в автозапуск tgtd и перезагружаемся.
Теперь наш iscsi “массив” должен уже работать и быть доступен для узлов esxi.
Заходим на наши узлы esxi и настраиваем там адреса из сети бонд-адаптера 10.2.254.2 и 10.2.254.3
Ключевое условие: для указанного мной конфига у вас должен быть активен режим “route based on IP hash” для iSCSI_VMK, иначе либо будут дублироваться пакеты, либо теряться. После этого нужно проверить с “массива” связность при потере сетевых линков (выгорании адаптеров) или потере свитчей (высыхании
конденсаторов в БП).
Теперь идем в “storage adapters” включаем iscsi адаптер и прописываем
наши логин и пароль в “Dynamic discovery”->”CHAP” (если забыли это
esxiuser и secur789)
После этого все должно появиться и работать.
PS: Почему не стоит использовать RAID1. Как ни странно, оказалось что
RAID1 (что факерейд, что софтрейд) не умеет балансировать нагрузку по
чтению (хотя есть вероятность что я не нашел какой-нить особо-тайной
ручки в софтрейде чтобы этот режим включить) RAID5 как ни странно
балансирует чтение сразу “из коробки”.
PPS: при проблемах на одном из дисков – запись идет на скорости самого
медленного (читай сбойного) диска и получается скорость очень плохая.
а вы не смотрели в торону freenas? у меня работает, софтрейд5, zfs. вопросов нет.
фринас смотрели.
только мне непонятно, в чем именно плюсы? там нет например bitmap-ов, т.е. если у вас завтра случайно вспухнут конденсаторы в блоке питания – скорее всего рейд5 свой вы проклянете, т.к. он будет пересинхронизировать до одури выпадающий (от нехватки напряжения) диск
а почему Linux ?
Solaris (в крайнем случае BSD ) = вот приличный storage сервер “из коробки”
ZFS собирается при полудохлых дисках не в пример легче и кешируется всей ОЗУ – 1Гб и iscsi в ней “добрее” и NFS “мягче”
>> случайно вспухнут конденсаторы
Для этого нужно брать хорошие БП, xilence, например.
Конечно даже ультра бренд не спасет на 100%, но вероятность этого ничтожно мала.
Насчет 5\6 рейдов и FREEnas – если не повезет, то может развалиться даже после выпадения 1 диска. Дважды с подобным сталкивался, теперь стараюсь избегать FreeNas.
я предпочту избегать споров на тему “теплого лампового звука”)
но, в первую очередь солярис это с недавних пор платный продукт!
и насколько я помню бесплатно он не обновляется (по крайней мере легко)
поверх этого – если что-то поломается, с солярисом вы найдете в интернете много меньше ссылок и туториалов (чем для линукса) и будете вынуждены приложить много больше усилий.
резюмируя, solaris и zfs это прекрасно, если вы хотите лавку залокинить на себя.
плюсом идет то, что всякие разные “желаемые” (лично мной) фишки ZFS (типа компрессии и дедупликации) были в интернете разобраны и стало понятно что не все так хорошо как я думал (см например http://blog.wadmin.ru/2011/04/solaris-zfs-deduplication/ или что “Transparent filesystem compression. Supports LZJB and gzip” качество компрессии гзип в пояснении не нуждается, и lz думаю тоже)
по поводу БП xilence:
я пока не видел БП (ценовой категории ниже 200 долларов) где бы не стояли электролитические конденсаторы (которые и есть корень проблемы).
а за 200 долларов можно купить 10 дешевых блоков питания.
ps: я бы очень советовал никогда не собирать на “полудохлых дисках”, как я упоминал выше “запись идет на скорости самого
медленного … диска” на практике она может “достигать” 100 килобайт в секунду при времени доступа к сектору 10 секунд, как вы понимаете сотня операций тогда уже будет не в секунду а в час :))))))
PPS: “в крайнем случае BSD” а чего тогда не Windows?…))))
вообще в случае бзд вы весьма вероятно сможете столкнуться с тем, что сетевой адаптер не работает, или что под sata чипсет нет драйверов и работает только 2 из 8 впаянных в материнку sata.
ну а проблема с “запустить на этой железяке ещё oracle или kvm” вас тогда точно не посетит
про полудохлые – это не изначально, а если сыпаться начали в процессе
ZFS в отличии от аппаратного RAID дольше не развалит массив.
Dim-soft, с этого места поподробнее
если у нас RAID5 и один диск посыпался, то raid контроллер вычеркивает его из списка живых и превращается в RAID 0
если есть хот спаре то начинается ребилд, НО если во время ребилда выйдет из строя (хотя бы 1 bad) еще один диск то все raid контроллер отключит весь массив.
в ZFS осознали что диск умирает – вставили еще один (или был назначен нот спаре)
при чтении ZFS не может прочитать кусок – восстанавливает его по избыточности и пишет на новый диск – в RAIDZ можно тянуть инфу с массива где все диски битые (с bad блоками, но электроника работает) причем консольной командой можно получить список файлов которые ZFS не смог восстановить.
в случае с RAID 5 контроллер просто не знает – что там на диске.
плюс защита от фантомной записи, от проблем с кабелями и контактами, тк данные и контрольная сумма хранятся в разных местах.
И всетаки действительно, не совсем ясна приверженность автора к Linux-констркутору с кучей лишних телодвижений как при начальной установке пациента, так и при аварийном восстановлении системы.
После появления ZFS софт-RAID все больше теряет свою актуальность, IMHO.
В качестве альтернативы, можно предложить пару вполне достойных решений где имеется реализация ZFS, встроен необходимый минимум для организации стораджа, простота и быстрота установки/настройки/восстановления:
1. FreeNAS
2. NexentaStor Community Edition (ограничение до 6Tb дискового пространства)
У FreeNAS действительно встречаются кривые сборки, с теми или иными косяками в разных модулях. Это одно из основных отличий stable релизов от nightly 😉 Кроме того, ветки 0.7 и 8 имеют ряд технических различий, на что также стоит обращать внимание.
У самого в продакшене около двух лет на разных площадках стабильно работают 5 хранилищ (iSCSI, NFS, CIFS). Используются исключительно stable сборки.
NexentaStor – готовое софт-решение для организации стораджа (iSCSI, NAS, CIFS) на основе Solaris. Прост в установке. Настройка через web-морду. Все просто и достаточно понятно. Для получения лучшего по производительности результата настоятельно рекомендуется почитать best practics.
Оба решения, прежде всего, интересны своей готовностью для большинства случаев, простотой настройки “из коробки”, простотой восстановления работоспособности хранилища после аварии или смены железа, простотой организации резервирования всего стораджа или его части (Rsync).
nexenta stor com ed уже 18Тб ограничение 🙂
а solaris (любой) настраивается как storage server 1 командой 🙂
http://www.napp-it.org
Приверженность к линукс/солярис-конструктору можно объяснить тем, что в этом случае проще реализовать какие-то вещи, изначально не вложенные в софт-решение. Типа тех же битмапов или таргетов поверх IB/FC.
Помню, когда у меня полетел винт под Freenas, было очень приятно узнать, что, оказывается, для более хорошей работы fsck необходимо знать номер суперблока. Который в моем случае хрен знает какой при создании из GUI.
Прочитал статью два раза, но так и не понял, при чем тут D-Link DGS-1005D
Вместо него можно подставить любой другой дешевый гигабитный свитч.