Речь пойдет о том, как сделать из 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: при проблемах на одном из дисков – запись идет на скорости самого
медленного (читай сбойного) диска и получается скорость очень плохая.

А далее уже по делу, пост будет коротким, но немного в неформальном стиле – это всё же не How-to.

Появилась у меня нужда сделать загрузку ESXi 4.1 с iSCSI стораджа.

В качестве стораджа используется Celerra NX4, серверы – Dell R710 11G. Сетевые карты на основе broadcom 5709, а это значит, что они есть в VMWare HCL.

Так же они являются dependant iSCSI адаптерами и поддерживают загрузку с iBFT, что мне и требовалось.

Осталось только произвести настройку и наткнуться на грабли!

Я быстро настроил загрузку по следующим пунктам:

1. iSCSI SAN configuration guide, пункт 4 для общего понимания, и пункт iBFT iSCSI Boot Overview уже по моему предмету.
2. Так же не забыл установить Boot to iSCSI target:  Disabled
3. Проверил рекомендации от Dell по этой инструкции
4. Перепроверил настройки на NAS, всё верно.

Запуск: сервер стартует, обнаруживает iSCSI Boot LUN – это видно в прошивке Broadcom при загрузке, Celerra рапортует о подключении инициатора к таргету. Загружается ESXi и сообщает, что он не видит ни одного устройства, куда можно установить систему.

Странно.

Дубль два, на этот раз использую Intel адаптеры, которые тоже есть в HCL.

Настраиваю всё по той-же инструкции от Dell, включаю и оказывается Intel не поддерживает vlan для iSCSI boot!

Причина: The VLAN ID field was grayed out in the Intel® iSCSI Boot firmware screen because the Microsoft iSCSI Boot Initiator does not support Vlans

Ничего, кроме WTF?! у меня не вышло сказать. Позвонил в Intel US Support – подтвердили, разблокировать возможности нет. К сожалению в моей инфраструктуре загрузиться без vlan нельзя. Но вообще – работает, проверил. Перевёл порт в access режим и загрузился.

Привлёк поддержку Dell, EMC, VMWare.

VMWare – покопались, ничего не нашли, сказали: должно работать, проблемы с Celerra.

Dell покопалсиь, посмотрели, что всё настроено правильно, ничего не сказали.

EMC – попросили денег за “Set up”, молодцы – правильный подход к клиентам. Кстати с ними больше всего проблем. Их сторадж уже ремонтировали 5 раз за 7 месяцев, правда без прерывания работы, но всё же это напрягает.

Решение

Виной тому, что загрузка не работала была моя невнимательность. С этим “нюансом” я столкнулся еще при первичной настройке у заказчика и успешно забыл о нём.

Broadcom dependent iSCSI adapters do not support Jumbo Frames.

Всё было предельно просто. Проблемы все же были на стороне EMC. Достаточно было создать отдельный таргет и интерфейсы к нему без Jumbo Frames, как ESXi тут же нашёл LUN.

Правда к этому моменту мы уже забили на iSCSI boot, так как сетевых интерфейсов не хватало для подключения всех сетей и купили SD карточки. Тут же проснулись DELL, сказали что нашли проблему, ту же что и я и порекомендовали использовать SD карты и использовать iSCSI boot для ESXi они не рекомендуют, так как с ним слишком много проблем впоследствии.

Итак, ситуация:

У Вас есть ESXi хосты с independent iSCSI HBA, есть iSCSI хранилище подключенное к хостам и желание настроить загрузку с SAN по каким-либо причинам (бездисковые сервера, указание руководства и т.п.).

Изучаем задачу:

1. ESXi поддерживает загрузку с iSCSI, начиная с версии 4.1.

-ОК

2.Загрузка c independent iSCSI HBA не поддерживается.

-Не проблема, у нас есть обычные NIC.

3. Зато поддерживается загрузка с dependent HBA и software iSCSI, но NIC должен поддерживать iBFT (iSCSI Boot Firware Table).

-У нас как раз такие есть (Broadcom 5709), отлично.

4. Включение iBFT на адаптере автоматически включает software iSCSI на хосте ESXi и не позволяет его выключить

-Ну а в чем подвох?

А подвох вот в этом:

ESX/ESXi does not support multipathing when you combine an independent hardware adapter with either
software iSCSI adapter or dependent hardware iSCSI adapter.

 

ESX/ESXi не поддерживает multipathing в конфигурации, когда на хосте одновременно работают Independent iSCSI HBA и Dependent/Software iSCSI.

Ответ:

Да, вы можете настроить загрузку с iSCSI для Independent iSCSI HBA, но в обмен на это вы отдадите multipathing, а с ним и распределение нагрузки и частично HA.

Мое мнение в том, что это того не стоит

А как же быть?

Есть 3 варианта:

1. Купить в сервер диски, если это возможно
2. Установить ESXi на флешку и загружаться с неё – это дешевле первого варианта
3. Настроить PXE Boot.

Ок, если первые два варианта ясны, то третий немного озадачивает.

PXE BOOT

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

http://www.vmware.com/pdf/vsp_4_pxe_boot_esxi.pdf

Или же можно взглянуть на VMware PXE manager, но он еще имеет статус Technical Preview. Для работы с ним можно почитать вот эти статьи:

Часть 1:

http://www.virtual-blog.com/2011/06/howto-install-pxe-manager-for-vcenter/

Часть 2:

http://www.virtual-blog.com/2011/06/howto-configure-pxe-manager-for-stateless-esxi-deployments/

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

Скорость оказалась на уровне 50% от ожидаемой

Константин Введенский научил пользоваться кнопкой F1 и подсказал тюнинг для стека TCP/IP:

а) Включаем 9K Jumbo frames на адаптерах и свитче (MTU=9000);

б) Вносим изменения в реестр:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]

1) GlobalMaxTcpWindowSize = 0x01400000 (DWORD)

2) TcpWindowSize = 0x01400000 (DWORD)

3) Tcp1323Opts = 3 (DWORD)

4) SackOpts = 1 (DWORD)

Перезагружаемся. Поигравшись с размером блока для теста (1 или 2 MB), получаем увеличение скорости!

Было:

Стало:

В виртуальном железе версии 7 появился новый виртуальный сетевой адаптер – VMXnet3. Одна из его особенностей – поддержка скорости обмена данными в 10Gbit/sec. Это означает, что виртуальные машины, работающие на одном хосте, могут обмениваться данными через Ethernet на скорости в 10Gbit/sec без каких-либо вложений в инфраструктуру (то есть покупку новых сетевых адаптеров и свитчей).

Недавно мы писали про бесплатный iSCSI-target под Windows. Одна из его отличительных особенностей – возможность раздать по iSCSI RAM-диск. Это позволяет протестировать производительность локальной сети.

Соответственно, я поставил себе задачу – проверить, как работает iSCSI поверх 10Gbit’ных адаптеров. Естественно, при скорости доступа к RAM слабое звено – сеть.

Вперед!

Сервер: Windows 2003 x32 std, 2CPU, 4GB RAM. IP – 10.0.0.1/30.

Клиент: Windows 2003 x32 std, 2CPU, 1GB RAM. IP – 10.0.0.2/30.

ПО сервера: iSCSI Target: Starwind, размер диска – 3500MB.

ПО клиента: MS iSCSI Initiator 2.08, HDTune

Запускаем HDTune на клиенте:

Включение Jumbo Frames скоростей не дало.

UPD: Продолжение и тюнинг во второй части статьи.

• Синхронное зеркалирование с автоматическим переход при отказе (Synchronous Mirroring with Automatic Failover)
• Быстрая синхронизация при восстановлении оригинального хранилища после сбоя (Failback with Fast Synchronization)
• Удалённая репликация через Интернет (Remote Replication across a WAN)
• CDP & Snapshots
• Серверная кластеризация(Windows Server 2008, Hyper-V, VMware ESX  vSphere 4.0 и приложения)
• Обновленный дизайн

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

Сравнение версий.

Неожиданно, в марте, “добрые”  дяди из этой компании решили выпустить бесплатную версию своего продукта. Но, видать, желание слегка поиздеваться победило и продукт мог оперировать с хранилищем размером аж 2 GB, именно, 2 гигабайта. Шутка не прокатила.

Совесть с общественностью мучила их недолго – 2 месяца. Результат – налицо.

Новая версия поддерживает хранилище до 2TB. Ура, товарищи, ура!

Также заявлено:

• Неограниченное количество соединений
• Поддержка для виртуальных сред – VMware, Hyper-V, XenServer, Virtual Iron
• Поддержка для функций VMware: VMotion, VMware HA, DRS, VCB
• Поддержка кластеров Windows, в том числе для SQL Server, Exchange, SharePoint