У меня есть желание передавать трафик iSCSI между моей лабораторной системой Windows 2K8 Server и моим фильтром NetApp через два отдельных сетевых стека *.
Моя конфигурация следующая:
Я настроил компонент MPIO для регистрации класса «адаптер» программного инициатора iSCSI.
Затем я вошел в панель управления инициатора iSCSI, добавил оба адреса фильтрующего элемента в качестве «целей» и запустил обнаружение для них. Это показывает единственный доступный LUN.
Затем я дважды «входил» в LUN, выбирая другой «исходный» IP-адрес для каждого соединения. Оба соединения имеют отметку "повторное соединение при загрузке" и отметку "MPIO".
Когда я исследую цель, я вижу два соединения с целью, по одному для каждого IP-адреса, используемого NetApp.
Когда я исследую свои постоянные соединения, я вижу два соединения, по одному для каждого IP-адреса, используемого NetApp.
(Здесь я должен упомянуть, что я протестировал оба IP-адреса файлового сервера, продемонстрировав одно соединение с каждым IP-адресом, подключив его и затем используя диск через этот IP-адрес.)
Затем я захожу в Disk Mangler, настраиваю раздел на LUN и помечаю его как Online. Диск работает как положено.
Теперь я захожу в свойства нового диска и щелкаю вкладку MPIO. Я вижу, что для этого диска используются два соединения. Однако я не знаю, как связать соединение, которое я вижу на этой вкладке, с подключением, которое я вижу на экранах инициатора iSCSI, поэтому, хотя я предполагаю, что для каждого соединения на экране инициатора iSCSI есть одно соединение, я не могу это доказать. .
На вкладке MPIO у меня есть несколько вариантов.
Я уменьшил все таймеры до 1 секунды каждый и включил проверку пути. Итак, мое понимание этих настроек означает:
Что касается избыточности, я попробовал несколько вещей:
Я провел небольшое исследование и нашел Microsoft KB 968287, в котором говорится о том, что аварийное переключение не завершается из-за ошибки счетчика в драйвере MPIO.sys в Win2K8 и Vista, но установка этого исправления не изменила ничего, что я вижу.
Все это заставляет меня подозревать, что я упускаю нечто фундаментальное. Я делаю это неправильно?
Настоящая цель здесь - предоставить более надежный транспорт iSCSI, по которому можно будет запускать виртуальные машины и монтировать хранилища Exchange в моем кластере Hyper-V. Мы знаем, что Exchange, в частности, очень быстро отключит информационные хранилища при обнаружении сбоя на диске, поэтому мы надеялись, что MPIO разрешит поток данных даже в случае сбоя одного из путей.
* = В настоящее время у нас есть один коммутатор iSCSI, но когда он начал работать некорректно, нам пришлось отключить весь наш мир, чтобы прошить прошивку на одном коммутаторе. Поэтому нам нужны два полностью изолированных сетевых пути - сетевые карты, коммутаторы и интерфейсы на другом конце - чтобы мы могли вывести половину из них из строя в любой момент времени для обслуживания, не убивая мир.
Насколько я понимаю, в режиме 7 в NetApp каждый LUN будет иметь предпочтительный путь, даже если вы отправляете ввод-вывод по двум путям. Фактически вы отправляете каждый второй ввод-вывод через дополнительный переход, в то время как другой контроллер перенаправляет его на основной контроллер для этого LUN через межсоединение. Наблюдаемая вами 30-секундная задержка - это, вероятно, время, необходимое для выполнения смены узла жесткого кластера.
Режим 8 - это сейчас едва ли что-то большее, чем игрушка (и если вам не нравится альфа-тестирование для Netapp, режим 7 - единственный реальный вариант), но он решит эту проблему путем виртуализации нескольких слоев фильтра, включая интерфейсы Ethernet.
Если вам нужен действительно активный активный блок для iSCSI или любого другого блочного протокола, вам не нужен NetApp. Нет никакой гарантии, что это займет время, и в прошлом я видел, что это занимало намного больше 30 секунд.