Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Как спроектировать сеть iSCSI

Говард Маркс

Наконец-то вы получили финансирование на построение iSCSI-сети SAN. Вам удалось убедить свое руководство в том, что покупка дискового массива SCSI для каждого нового серверного кластера или действующего сервера, которому перестало хватать емкости внутренних накопителей, приводит к загромождению центра обработки данных оборудованием и неоправданной трате денежных средств. Затем вы выбрали подходящие дисковые массивы iSCSI и уверили начальство в том, что сеть Ethernet - это все, что вам необходимо для запуска этих устройств в работу.

Но на этом этапе проектирования сети вас ждет горькое разочарование. Тот факт, что трафик iSCSI технически реально передавать по имеющейся сети наряду с другими видами трафика, отнюдь не означает, что именно так и нужно делать. Типичные сетевые приложения разработаны с учетом возможности отказа сети, но ОС "предполагают", что их дисковые накопители постоянно доступны. Инфицированный ноутбук, создающий большую нагрузку на сеть, может вызвать сбой в работе серверов, поскольку последние потеряют доступ к своим дискам. Поэтому главный принцип проектирования iSCSI-сети SAN состоит в передаче ее трафика по выделенной для этого виртуальной ЛВС или, что более предпочтительно, по полностью изолированной гигабитовой сети.

Выбор коммутатора

В своих демонстрациях технологии iSCSI я задействовал коммутатор Gigabit Ethernet потребительского класса, а также (просто ради хохмы) пробовал передавать трафик iSCSI через 10-Мбит/с концентратор Ethernet. Однако, развертывая сеть iSCSI на предприятии, не следует использовать подобные устройства. Дело в том, что коммутаторы потребительского класса, как правило, не способны поддерживать передачу данных между многочисленными портами на полной скорости сетевых каналов (wire-speed), поэтому они могут сбрасывать пакеты без предупреждения.

Полную версию данной статьи смотрите в 2-ом номере журнала за 2006 год.

Мы видели 24-портовый коммутатор начального уровня с двумя 12-портовыми коммутационными подсистемами и одним гигабитовым соединением между ними. Если вы подключите серверы к портам 1-16 такого коммутатора, а дисковые массивы - к его портам 18-24, то это единственное гигабитовое соединение окажется перегруженным, что приведет к потере пакетов и значительному снижению производительности сети (или к чему-нибудь похуже).

В вашей iSCSI-сети SAN нужно использовать неблокирующий коммутатор Gigabit Ethernet корпоративного класса таких компаний, как Extreme Networks и Foundry Networks. Причем для повышения надежности работы он должен быть оснащен резервным источником питания.

Имейте в виду, какой бы коммутатор вы ни выбрали, если ваш сервер будет взаимодействовать с дисковым массивом iSCSI по единственному гигабитовому соединению с этим коммутатором, то он потеряет связь с ним при выходе данного соединения из строя. Это вполне может произойти в следующих случаях: если кто-нибудь прихлопнет сетевой кабель дверью монтажного шкафа, сгорит порт коммутатора или сетевая плата сервера, поработает нечистая сила (с которой обычно связывают все необъяснимые неполадки в работе сети). В результате ваш сервер лишится доступа к своим данным, произойдет аварийное завершение работы запущенного на нем приложения и, что весьма вероятно, искажение данных.

С момента появления на рынке 10-Мбит/с коммутаторов компании Kalpana администраторы серверов логически объединяют их сетевые адаптеры в группы, чтобы сетевое соединение сервера перестало быть единственной точкой отказа и повысилась скорость передачи данных между сервером и сетью. Это делается с помощью драйверов серверных сетевых плат, балансирующих трафик между двумя соединениями (или более) сервера с одним и тем же коммутатором. Такое решение повышает отказоустойчивость сетевых соединений, но не гарантирует связи при выходе из строя самого коммутатора.

Для сети SAN на базе одного-единственного коммутатора его поломка подобна взрыву нейтронной бомбы: все оборудование на месте, но серверы не "видят" сеть, данные им не доступны и, возможно, повреждены. Что бы там ни говорили производители коммутаторов Ethernet об их надежности, все мы прекрасно знаем, что эти устройства выходят из строя, причем зачастую в самый неподходящий момент.

Лучшей страховкой от этого является использование технологии Multipath I/O (MPIO), которая работает на уровне 3 и позволяет создавать множество соединений между iSCSI-инициатором каждого сервера и дисковым массивом, а также определять путь передачи данных. В отличие от работающей на уровне 2 технологии объединения сетевых адаптеров, которая требует, чтобы все соединения находились в одном и том же широковещательном домене, технология MPIO дает каждой сетевой плате сервера свой собственный IP-адрес, поэтому вы можете организовывать маршруты передачи данных по разным подсетям.

Большинство инициаторов iSCSI поддерживают технологию MPIO без какой-либо доплаты, но некоторые производители корпоративных систем хранения данных, такие, как компании EMC и Network Appliance, взимают плату за дополнительный драйвер MPIO, устанавливаемый на каждый сервер, взаимодействующий с их дисковыми массивами по этой технологии.

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

Сверхдлинные кадры

Производители устройств iSCSI и различные специалисты в области систем хранения данных утверждают, что в iSCSI-сетях SAN нужно использовать сверхдлинные (jumbo) кадры. Первые сети Ethernet представляли собой полудуплексные разделяемые инфраструктуры. Для них был выбран максимальный размер кадра 1500 байт, гарантирующий, что ни одна станция не сможет монополизировать сеть. Однако большинство ОС записывают данные на диски и считывают их с дисков кластерами длиной 4 Кбайт (такова принятая по умолчанию длина кластера в файловой системе NTFS) или более, поэтому при использовании стандартных кадров размером 1500 байт для выполнения большинства операций, связанных передачей iSCSI-данных, требуется пересылать множество кадров. В этом случае стек TCP/IP создает значительную нагрузку на ЦПУ хост-машины, ведь данные делятся на множество пакетов, и для каждого из них вычисляется контрольная сумма, на приемном же конце соединения данные должны быть вновь собраны. Кроме того, применение коротких кадров снижает эффективность работы сети, поскольку на передачу заголовков кадров, контрольных сумм, а также на реализацию межкадровых интервалов тратится больше вре-мени, а значит, на пересылку самих данных его остается меньше.

Хорошей новостью является тот факт, что большинство корпоративных устройств Gigabit Ethernet поддерживают сверхдлинные кадры. Мы определили, что при их использовании производительность систем iSCSI повышается на 5%, а загрузка ЦПУ сервера, оборудованного обычной или более "интеллектуальной" сетевой платой, снижается на 2-3%. В случае же применения сетевых плат с устройством TOE (TCP Off-load Engine) или хост-адаптеров iSCSI, освобождающих ЦПУ от осуществления вычислений, связанных с работой протоколов TCP/IP (TCP/IP-вычислений), передача сверхдлинных кадров практически не снижает загрузку ЦПУ, но все же благоприятно сказывается на производительности сети.

Решив задействовать сверхдлинные кадры, убедитесь в том, что все оборудование вашей сети iSCSI, включая коммутаторы, инициаторы и целевые устройства, сконфигурировано для работы с кадрами одинаковой максимальной длины. Не существует стандарта, регламентирующего максимальный размер сверхдлинного кадра; нам встречалось оборудование, поддерживающее кадры длиной от 9 до 16 Кбайт.

Если серверы или дисковые массивы настроены на максимальный размер кадров - больший, чем тот, который поддерживают коммутаторы, то система iSCSI будет нормально работать до тех пор, пока не начнется передача кадров большей длины, чем максимальный размер кадра коммутатора. В этом случае появятся ошибки дисковых операций ввода-вывода.

Возможности "интеллектуальных" сетевых плат

Большинство современных ОС поддерживают программные инициаторы iSCSI, позволяющие применять любые сетевые платы Ethernet для подключения серверов к дисковому массиву iSCSI, но все же не стоит задействовать для этого старые гигабитовые адаптеры. Предназначенные для рабочих станций платы Ethernet используют 32-разрядную шину PCI с пропускной способностью чуть выше 1 Гбит/с, которая делится между всеми устройствами, подключенными к этой шине. Серверный Ethernet-адаптер работает с гораздо более быстрой шиной PCI-X или PCI-Express, а также выполняет TCP/IP-вычисления, снижая тем самым нагрузку на ЦПУ сервера при обработке трафика iSCSI. Аналогичные вычисления осуществляют и микросхемы сетевых контроллеров NetXtreme компании Broadcom, устанавливаемые практически на все серверные материнские платы.

Для любой выбранной вами модели сетевой платы используйте новейший драйвер, рекомендуемый ее производителем. Поставляемые вместе с ОС Windows типичные драйверы обычно не поддерживают широкого набора функций, в том числе работу со сверхдлинными кадрами и TCP/IP-вычисления.

Сетевые платы TOE компаний Alacritech, Chelsio и ряда других имеют процессоры, осуществляющие TCP-сегментацию данных и их повторную сборку, а также вычисляющие контрольные суммы. Платы TOE ускоряют обработку TCP-трафика любого назначения (а не только трафика iSCSI SAN) и работают с теми же самыми программными инициаторами, с которыми работают другие сетевые платы Ethernet. Хост-адаптеры iSCSI, например, производимые компаниями QLogic и Adaptec, освобождают ЦПУ от выполнения не только TCP/IP-вычислений, но и операций, связанных с работой более высокоуровневого протокола iSCSI. Операционная система "воспринимает" такой хост-адаптер, как дисковый контроллер, а не как сетевую плату Ethernet.

Снижая нагрузку на ЦПУ сервера (на 10-15% при выполнении широко распространенных приложений, в том числе SQL Server), платы TOE и хост-адптеры iSCSI, как показывает наш практический опыт, не ускоряют дисковый ввод-вывод вопреки обещаниям их производителей. Кроме того, большинству серверов среднего класса вполне хватает мощности их ЦПУ, поэтому мы рекомендуем вам использовать платы TOE и хост-адаптеры iSCSI в тех редких серверах, ЦПУ которых слишком сильно загружены.

Существенное преимущество хост-адаптера iSCSI заключается в том, что он обеспечивает начальную загрузку хоста из iSCSI-сети SAN. Поскольку хост-адаптеры iSCSI действуют подобно дисковым контроллерам (использующим прерывание INT13 BIOS), вы можете расположить системный диск на целевом устройстве iSCSI. Возможность загрузки из сети SAN позволяет легко инсталлировать многочисленные идентичные серверы: нужно лишь создать копию загрузочного тома - и очередной терминальный сервер или сервер Web готов к работе. Также просто заменить вышедший из строя сервер: подсоединение тома отказавшего устройства к новому блейд-модулю или серверу высотой 1U той же модели.

Программное обеспечение netboot/i компании EmBoot, использующее технологию PXE (Pre-Execution Environment) и сервер TFTP, обеспечивает загрузку оснащенных обычными сетевыми Ethernet-платами серверов из iSCSI-сети SAN. Однако для этого придется потратить больше времени, создав сначала системный том на локальном диске, а затем скопировав его на устройство хранения данных сети SAN. Мы предполагаем, что производители серверов встроят подобную функциональность в свои продукты следующего поколения, так что следите за новостями.

Безопасность сетей iSCSI

Серверы, подключенные к iSCSI-сети SAN, управляют файловыми системами на логических дисках, к которым они (серверы) имеют доступ. Это означает, что нужно контролировать доступ к томам iSCSI, иначе несколько серверов, работающих с одним и тем же логическим диском, будут перезаписывать данные друг друга. Таким образом, за исключением случаев применения серверных кластеров, имеющих средства регулирования доступа узлов к дискам, и специализированных файловых систем SAN, с каждым логическим диском должен работать только один сервер.

Целевые устройства iSCSI обычно позволяют управлять доступом посредством IP-адреса. Этот подход неплохо работает в изолированной среде, в открытой же среде он не препятствует злоумышленнику задействовать неавторизованный сервер и осуществить доступ к ценной корпоративной информации. В качестве альтернативы можно использовать имя IQN (iSCSI Qualified Name) хоста-инициатора. В этом случае в крупномасштабных средах будет значительно проще заменять вышедшие из строя серверы, поскольку изменить имя IQN работающего запасного сервера легче, чем его IP-адрес.

Если администраторам предстоит управлять серверами, которые не должны быть "привязаны" к определенным выделенным им ресурсам, то с целью обеспечения парольной защиты томов с конфиденциальной информацией они могут сконфигурировать свои целевые устройства для работы по протоколу аутентификации CHAP (Challenge Handshake Authentication Protocol). Кроме того, спецификация iSCSI определяет, как средства iSCSI могут использовать технологию IPsec в целях контроля доступа к информационным ресурсам и шифрования сетевого трафика, передаваемого между сервером и целевым дисковым устройством. Однако это делается редко из-за высокой нагрузки на ЦПУ и значительной временной задержки. Единственными целевыми устройствами iSCSI с поддержкой IPsec, с которыми мы встречались, были системы хранения данных на базе ПО (типа программы WinTarget компании Stringbean Software), работающего под управлением ОС Windows и использующего встроенную в нее реализацию IPsec. Таким образом, время для шифрования трафика iSCSI-сетей SAN еще не пришло.

Развертывание производственной iSCSI-сети SAN - дело не такое уж простое, как, возможно, думают некоторые специалисты. Однако вы вполне сможете построить такую сеть, правильно спланировав этот процесс и купив пару хороших коммутаторов..





  
9 '2006
СОДЕРЖАНИЕ

инфраструктура

• Тестируем серверы медиапотоков

• Как спроектировать сеть iSCSI

• Перспективы развития устройств NAS

• Средства кластеризации и виртуализации устройств NAS

информационные системы

• Пять новых технологий для call-центров

• Тестируем пакеты ESB

• Информатизация образования в Югре

сети связи

• Оптические кабели связи

защита данных

• CDP-продукты готовы к защите данных

кабельные системы

• Технология PoE и сертификация СКС

• Экспансия фальшполов

новые продукты

• Новая тестовая платформа Ixia; Новые моноблочные коммутаторы от Allied Telesyn; Новые промышленные компьютеры ROBO; Новый KVM-переключатель от Aten International


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх