Это канонический вопрос об iSCSI, который мы можем использовать в качестве справочного материала.
iSCSI - это протокол, который помещает команды SCSI в качестве полезной нагрузки в сетевые пакеты TCP. Как таковой, он подвержен иному набору проблем, чем, скажем, Fibre Channel. Например, если канал перегружен и буферы коммутатора заполнены, Ethernet по умолчанию отбросит кадры вместо того, чтобы дать команду хосту замедляться. Это приводит к повторным передачам, что приводит к высокой задержке для очень небольшой части трафика хранилища.
Существуют решения для этой проблемы, в зависимости от операционной системы клиента, включая изменение настроек сети. Как выглядит оптимальная конфигурация клиента iSCSI для следующего списка ОС? Будет ли это включать изменение настроек на переключателях? Как насчет хранения?
- VMWare 4 и 5
- Windows Hyper-V 2008 и 2008r2
- Windows 2003 и 2008 на голом металле
- Linux на голом металле
- AIX VIO
- Любая другая ОС, которую вы считаете нужной
Ответы:
Я не знаком с VMWare, но я использую Xenserver, и я использовал Hyper-V (R2).
С моей текущей конфигурацией Xenserver у меня есть:
Я настроил свои коммутаторы в конфигурации с несколькими путями и оптимизировал их для iSCSI следующим образом:
Каждый сервер имеет несколько сетевых карт для подключения к каждому коммутатору, что, в свою очередь, обеспечивает избыточность через многолучевое распространение между серверами и iSCSI SAN. Сети VLAN iSCSI не содержат другого трафика, кроме iSCSI.
Я рад сообщить, что с этой конфигурацией «кластер» Xenserver работает блестяще.
Кстати, у меня есть сервер Windows 2008, напрямую подключенный через iSCSI к HP SAN (старый файловый сервер). Раньше он работал под управлением Windows 2003 и регулярно прерывал соединение (даже после переустановки 2003); однако, как только я обновился до Windows 2008, он остается подключенным.
Я буду рад ответить на любой вопрос о моей настройке.
источник
Это не ответ ... пока. Это основа для общего ответа. Если у вас есть время, пожалуйста, заполните все, что вы знаете о. Что касается настройки конкретного оборудования, пожалуйста, опубликуйте отдельный ответ для каждого поставщика, чтобы мы могли сохранить эту информацию организованной и отдельной.
Профиль QoS для портов, а также отключение штормового управления, настройка MTU на 9000, включение управления потоком и перевод портов в portfast
Пропускная способность и задержка
Обновленные прошивки, драйверы и другие системы
MPIO
Jumbo Frames / MTU
По мере увеличения скорости сетевых соединений количество потенциально генерируемых пакетов также увеличивается. Это дает все больше и больше времени ЦП / прерывания, затрачиваемого на генерацию пакетов, что приводит как к чрезмерной нагрузке на передающую систему, так и к чрезмерному увеличению пропускной способности канала при кадрировании.
Так называемые "большие" кадры - это кадры Ethernet, которые превышают канонический предел в 1518 байт. Хотя эти цифры могут различаться в зависимости от поставщиков коммутаторов, операционных систем и сетевых адаптеров, наиболее типичные размеры больших пакетов составляют 9000 и 9216 байт (последний является наиболее распространенным). Учитывая, что примерно в 6 раз данные могут быть помещены в кадр 9 КБ, количество фактических пакетов (и прерываний) уменьшается на столько же на хосте. Это усиление особенно заметно на высокоскоростных (т. Е. 10GE) каналах, которые отправляют большие объемы данных (т. Е. ISCSI).
Включение jumbo-фреймов требует настройки как хоста, так и коммутатора Ethernet, и перед внедрением следует позаботиться о нем. Необходимо следовать нескольким
1.) В пределах данного сегмента Ethernet (VLAN) все хосты и маршрутизаторы должны иметь одинаковый MTU. Устройство без правильной конфигурации будет видеть большие кадры как ошибки связи (в частности, «гиганты») и сбрасывать их.
2.) В рамках протокола IP двум хостам с разными размерами кадров необходим некоторый механизм для согласования подходящего общего размера кадра. Для TCP это обнаружение MTU пути (PMTU) и основано на передаче ICMP недоступных пакетов. Убедитесь, что PMTU включен во всех системах, и что любые ACL или правила брандмауэра разрешают эти пакеты.
Ethernet Flow Control (802.3x)
Несмотря на то что рекомендуются некоторыми поставщиками ISCSI, простое управление потоком 802.3x Ethernet должна не быть включено в большинстве сред , если все порты коммутатора, сетевые карты, а также ссылки не полностью посвященный ISCSI трафик и ничего другого. Если на ссылках есть какой-либо другой трафик (такой как общий доступ к файлам SMB или NFS, пульс для кластерного хранилища или VMware, контроль / мониторинг трафика NIC и т. Д.), Не следует использовать простое управление потоком 802.3x, поскольку оно блокирует целые порты и другой трафик не-iSCSI также будет заблокирован. Повышение производительности Ethernet Flow Control часто минимально или отсутствует, поэтому необходимо провести реалистичный сравнительный анализ для всех комбинаций ОС / NIC / коммутатор / хранилище, чтобы определить, есть ли какое-либо реальное преимущество.
Фактический вопрос с точки зрения серверов: останавливаю ли я сетевой трафик, если мой сетевой адаптер или сеть переполнен, или я начинаю отбрасывать и ретранслировать пакеты? Включение управления потоком позволит буферам NIC быть очищенными на стороне получателя, но создаст нагрузку на буферы на стороне отправителя (обычно сетевое устройство здесь буферизует).
Контроль перегрузки TCP (RFC 5681)
TOE (двигатели разгрузки TCP / IP)
iSOE (двигатели разгрузки iSCSI)
LSO (сегментация TCP / большая разгрузка отправки)
Изоляция сети
Распространенной рекомендацией для iSCSI является изоляция как инициаторов, так и целей от другого сетевого трафика, не связанного с хранением. Это дает преимущества с точки зрения безопасности, управляемости и, во многих случаях, выделения ресурсов для трафика хранилища. Эта изоляция может принимать несколько форм:
1.) Физическая изоляция - все инициаторы имеют один или несколько сетевых карт, выделенных исключительно для трафика iSCSI. Это может или не может подразумевать выделенное сетевое оборудование в зависимости от возможностей рассматриваемого оборудования и конкретных требований безопасности и эксплуатации в данной организации.
2.) Логическая изоляция. В основном в более быстрых (т. Е. 10GE) сетях инициаторы имеют теги VLAN (см. 802.1q), настроенные для разделения трафика между хранилищами и не-хранилищами.
Во многих организациях используются дополнительные механизмы, чтобы также гарантировать, что инициаторы iSCSI не могут связаться друг с другом по этим выделенным сетям и что, кроме того, эти выделенные сети недоступны из стандартных сетей передачи данных. Меры, используемые для достижения этой цели, включают стандартные списки контроля доступа, частные VLAN и брандмауэры.
Здесь тоже кое-что о объединительной плате и коммутационной матрице.
QoS (802.1p)
VLAN (802.1q)
STP (RSTP, MSTP и т. Д.)
Подавление трафика (шторм-контроль, многоканальный контроль)
Безопасность
Аутентификация и безопасность
ГЛАВА
IPSec
LUN Mapping (лучшие практики)
источник
Некоторое рассмотрение и исследование вы должны быть приняты субъективно в отношении:
1) Multi-pathing - вашему SAN-решению и вашей ОС, будь то гипервизор или операционная система с открытым исходным кодом, может потребоваться специальное программное обеспечение от поставщика для его правильной работы.
2) Инициаторы - вам необходимо проверить, достаточно ли производительности программного инициатора на основе требований. Многие сетевые адаптеры имеют возможности разгрузки iSCSI, которые могут значительно улучшить пропускную способность, но известно, что некоторые старые гипервизоры очень раздражаются в отношении поддержки. Более зрелые предложения (ESXi 4.1+) кажутся приятными.
3) Безопасность / Разрешения - Убедитесь, что полностью выяснили, каким инициаторам требуется доступ к каким логическим устройствам ... у вас будет плохой день, если администратор на одном из ваших компьютеров с Windows выполнит «инициализацию диска» на диске, который действительно используется другим сервером в качестве хранилища данных VMware.
источник