Vladislav Kirilin

about life, work and …

про зонирование / FibreChannel Zoning

В последнее время частенько сталкиваюсь с проблемами, вызванными неверной конфигурацией SAN. Перечислю их:

  • использование зон, включающих в себя более одного initiator’а и target’а;
  • неоправданное использование RDM – Raw Divice Mapping;
  • отсутствие балансировки нагрузки на стороне массива и соответствующих настроек на стороне гипервизора:
    • слишком большие LUN’ы и, соответственно, тома VMFS;
    • слишком большое или слишком маленькое число портов, обслуживающих LUN’ы виртуальной платформы.

Проблемы эти приводят к заметному проседанию производительности всей виртуальной платформы вплоть до её недоступности. Наиболее часто встречается либо полное отсутстиве зонирования (одна общая зона), либо неверная конфигурация зон. Перечислять всё многообразие встреченных мной конфигураций не буду – всё равно список будет неполным 🙂

Лучше расскажу как делать правильно и почему нужно именно так, а не иначе.

Единственно правильная схема зонирования формулируется принципом “Single Initiator and Single Target”. Опишу на примере. Положим имеется:

  • две фабрики (FC Fabric):
    • каждая фабрика использует WWN based zonng;
  • одна СХД с двумя Service Processor’ами:
    • на каждом Service Processor’е выделено по два порта;
    • разные порты одного Service Processor’а подключены в разные фабрики;
  • четыре сервера с двумя портами FC:
    • каждый порт подключен в разные фабрики.

Правильно число зон будет таким:

  • для одной фабрики: 4 = 1 (число портов, которыми сервер подключен в одну фабрику) x 4 (число серверов) x 1 (число target’ов – СХД);
  • для двух фабрик зон будет в два раза больше.

На всякий случай напомню очевидное правило. Каждая фабрика – это полностью независимая инфраструктура. Ни при каких условиях коммутационное оборудование разных фабрик (FC switch, FC director) не соединяется между собой. К разным фабрикам одновременно могут быть подключены только устройства, не коммутирующие трафик между своими портами – Initiator’ы и Target’ы.

Если же по каким-то причинам в вашем сервере имеется 4 FC порта, то для каждой фабрики будет по две зоны на сервер, а всего на фабрику – 8 = 2 (FC порта) x 4 (сервера) x 1 (СХД). Понятно, что число портов всегда чётное, так как фабрик две. Кстати, мне реальные предпосылки для подключения одного сервера к SAN числом портов, отличным от двух неизвестны. И, более того, я абсолютно убеждён, что их просто нет – не в теории, а в жизни. По крайней мере у тех клиентов, с которыми я работаю, а это самый крупный российский бизнес, таковых мною не обнаружено.

Теперь в двух словах о технической подоплёке описанных требований.

Есть такой SCSI Discovery Process. Когда каждое устройство включается, то оно начинает опрашивать все доступные устройства. Каждый HBA пытается залогиниться на всех SCSI устройствах, которые ему доступны. И если у нас используется одна общая зона, то число таких сочетаний растёт в геометрической прогрессии.

Возвращаясь к нашему примеру. При правильном зонировании каждый сервер проведёт опрос всего 4-х устройств или же 2-х в каждой из фабрик – по одному порту с каждого из Service Processor’ов, подключенному в одну фабрику.

При наличии же одной общей зоны для каждой фабрики общее число событий SCSI login показано на графике – по горизонтали отложено число хостов в одной зоне, по вертикали указано число попыток SCSI login в зоне.

События эти инициируются при любых изменениях в зоне для всех устройств в этой зоне. Например, если в одной зоне содержащей два сервера, один из них будет перезагружен или кабель из его HBA будет переключен в другой порт на коммутаторе FibreChannel, то произойдёт событие RCSN (Register Change State Notification). Возникновение этого события приведёт к необходимости logback для всех устройств в зоне. Таким образом смысл зонирования – снизить недоступность ресурсов для одних устройств по причине изменений в SAN.

Надеюсь этот пост снимет вопросы о необходимости зонирования в соответствии с документацией VMware.

Advertisements

5 responses to “про зонирование / FibreChannel Zoning

  1. Михаил 14.01.2012 at 13:43

    К слову – “Слишком большие LUN” – это сколько??

    исходя из каких факторов делается этот вывод?

    чем плохо разместить 100 ВМ на одном хранилище?

    • ivladek 14.01.2012 at 17:20

      Ничем не плохо – максимум 2048 VM (для vSphere).

      Я не старался дать абсолютного рецепта, подходящего на все случаи – возможно для вашей ситуации 100 VM на том приемлемое число.

      Для себя же я сделал вывод – для средних VM (30-50 GB) оптимальным размером LUN’а является 1 TB. Если имеем множество маленьких машин (то даже меньше), если же машины “толстые”, то 2 TB.

      Если у нас всего 100 VM, то стоит разнести их по 2-4 LUN’ам. Так как балансировка нагрузки на стороне СХД производится на уровне LUN’ов.
      Если же машин за тысячу, то вполне возможно разместить и 100 на один LUN.

      На маленьких томах (до 2 TB) легче проводить сборку “мусора”. Эти тома можно быстрее освободить при необходимости. Меньше IOPS’ов на одни и те же шпиндели и очереди на Service Processor’ы. Меньшее воздействие всплесков утилизации СХД одними машинами на работу других.

      Вообще, конечно же, размер LUN’а определяется для каждого конкретного случая индивидуально. 1 TB – это, на мой взгляд, тот средний размер, который стоит использовать когда нет возможности хорошо продумать размещение данных на СХД.

      PS. Вообще этот диалог не по теме поста. На эту тему напишу в ближайшее время отдельную статью – предлагаю отложить обсуждение до этого момента.

  2. Михаил 14.01.2012 at 17:33

    спасибо.

    а NPIV зачем-либо приходилось использовать?

  3. Pavel Alexei 19.01.2012 at 23:57

    > Кстати, мне реальные предпосылки для подключения одного сервера к SAN числом портов, отличным от двух неизвестны. И, более того, я абсолютно убеждён, что их просто нет – не в теории, а в жизни.
    Ленточки. Везьде пишут – если надо подключить сервер и к сторижду и к ленточному носителю, лучше это делать через физически разные карточки. Читать со стрижда и сразу писать на ленту во время backup, и при этом еще клиентов обслуживать, говорят “больно”.
    Возможно при 8Gb, это уже не актуально. LTO растет в размере, но скорости растут медленно. Но я как-то пытаюсь придерживаться этого правила.

    • ivladek 20.01.2012 at 00:01

      Интересно, зачем отдельные карточки для лент ? Отдельная зона – могу понять. Это необходимо.
      А отдельные карточки для лент – не актуально даже при 2 G – проверено на практике. К тому же медиасерверы, официально не поддерживаются в виртуальной среде, хотя и прекрасно там работают.
      Не слушайте тех, которые “говорят”. Почитайте теорию и проверьте на практике.

%d bloggers like this: