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