Нюансы связки ESXi, FlexFabric, 10 Gbit и NFS

В данной статье я хотел бы представить полезную информацию, собранную при проектировании и внедрении отказоустойчивой среды виртуализации. Особое внимание уделено нюансам работы HP Virtual Connect FlexFabric и конфигурации гипервизора VMware vSphere 5.5 при использовании Ethernet 10 Gbit и NFS в качестве Datastore.

Схема сетевого взаимодействия


«Железо»

Блейд-корзина «HP BladeSystem c7000» c парой модулей «HP VC FlexFabric 10/24».
Сервера «HP BL460c Gen8» со встроенной сетевой картой «HP FlexFabric 10Gb 536FLB».
Сетевые коммутаторы «Cisco Nexus 5k».
Система хранения данных «NetApp FAS8020».

Агрегирование каналов


Агрегация каналов является одним из основных средств достижения высокой отказоустойчивости виртуальной среды, поэтому необходимо использовать это на всех уровнях прохождения трафика. В нашем случае:
ESXi FlexFabric Network Storage
vSphere vSwitch в режиме «Port ID» Shared Uplink Set + режим «Auto» (LACP) EtherChannel (LACP) lif

Jumbo Frames


Чтобы получить максимальную выгоду от 10 Gbit рекомендуется включать Jumbo Frames на всех уровнях:
VMkernel port vSwitch FlexFabric Network Storage
Значение 9000 9000 9216 9216 9000

Значение MTU в HP Virtual Connect «зашито» на значение 9216 и не может быть изменено.

Как установить Jumbo Frames на ESXi.

Cisco Discovery Protocol


К сожалению, CDP не поддерживается модулями «HP VC FlexFabric», поэтому включать ее поддержку на гипервизоре смысла нет.
Выдержка из документации: «Virtual Connect does not support CDP. VC does support the industry standard protocol called Link Layer Discovery Protocol (LLDP) by default. LLDP is functionally equivalent to CDP, although the two protocols are not compatible.»

Flow Control


В вопросе использования механизма «Flow Control» мы решили придерживаться рекомендации NetApp и отключить его на всех «уровнях» (ESXi, FlexFabric, Network, Storage).

Рекомендация NetApp: «Modern network equipment and protocols handle port congestion better than those in the past. NFS and iSCSI as implemented in ESXi use TCP. TCP has built-in congestion management, making Ethernet flow control unnecessary. Furthermore, Ethernet flow control can actually introduce performance issues on other servers when a slow receiver sends a pause frame to storage and stops all traffic coming out of that port until the slow receiver sends a resume frame. Although NetApp has previously recommended flow control set to send on ESXi hosts and NetApp storage controllers, the current recommendation is to disable flow control on ESXi, NetApp storage, and on the switches ports connected to ESXi and NetApp storage.»

В конфигурации модулей «HP VC FlexFabric» Flow Control по умолчанию включен только на downlink-ах (значение «Auto»), а на uplink-ах выключено.

«ON» — all ports will advertise support for flow control (if autoneg), or flowcontrol turned on (non-autoneg).
«OFF» — all ports will advertise *no* support for flow control (if autoneg), or flowcontrol turned off (non-autoneg).
«Auto» — all uplink/stacking links will behave like «OFF», and all server links behave like «ON».


Команда для выключения: #set advanced-networking FlowControl=off

Интересные статьи по данной теме:
Virtual Connect FlexFabric interconnect modules and Ethernet Flow Control
NETAPP vs VMWARE FLOW CONTROL DILEMMA
Configuring Flow Control on VMware ESXi and VMware ESX

Smart Link


Режим Smart Link должен быть включен для всех vNet (Ethernet Network) в конфигурации FlexFabric. Это необходимо, чтобы гипервизор правильно отработал балансировку в виртуальном коммутаторе.

Выдержка из документации: «HP’s Virtual Connect supports a feature called Smart Link, a network enabled with Smart Link automatically drops link to the server ports if all uplink ports lose link. This feature is very similar to the Uplink Failure Detection (UFD) that is available on the HP GbE2, GbE2c and most ProCurve switches. I believe there is a similar feature available on Cisco switches called Link State Tracking.»

Виртуальные коммутаторы


Рекомендуется разделять трафик виртуальных машин от трафика управления (vMotion, Management, NFS, FT). Для повышения надежности виртуальной среды мы использовали стандартный коммутатор для трафика управления, а не распределенный, хоть он и имеет ряд преимуществ (например, поддержка LACP).

vSphere vSwitch Load Balancing


В подобной конфигурации в виртуальных коммутаторах рекомендуется использовать режим балансировки нагрузки «Route based on the originating virtual port id».

Режим «Route Based on IP Hash» (рекомендация NetApp) использоваться не может, так как для этого требуется объединение его uplink-ов (виртуального коммутатора) в транк по протоколу 802.3ad, а HP VC FlexFabric не предоставляет такую возможность для downlink к серверам.

Остальные настройки Load Balancing Policy:
Network failure detection: Link status only.
Notify switches: Yes.
Failback: Yes.

VMkernel Port


Для каждого сервиса (vMotion, Management, NFS, FT) рекомендуется создавать отдельный VMkernel Port. Vmk для NFS-трафика (Available Services остается пустым) необходимо создавать в той же подсети, где будут находиться NFS-экспорты. В нашем случае:
VMkernel port Available Services Network Label VLAN ID MTU
vmk0 vMotion vMotion 1 9000
vmk1 Management Management 2 9000
vmk2 - NFS 3 9000

Для vMotion vmkernel-адаптера HP рекомендует установить «failover order» режим в Active/Standby:
«As this Scenario is based on an Active/Active configuration, to ensure that ALL VMotion traffic between servers within the enclosure is contained to the same module, on each server edit the VMotion vSwitch properties and move one of the Adapters to Standby. This will ensure that ALL VMotion traffic will occur on the same Virtual Connect module.»

NFS Advanced Settings


Рекомендуется изменять стандартные значения некоторых параметров работы с NFS-экспортами. Для каждого vSphere хоста в Advanced Settings устанавливаем следующие значения:

NFS.HeartbeatFrequency = 12
NFS.HeartbeatTimeout = 5
NFS.HeartbeatMaxFailures = 10
Net.TcpipHeapSize = 32
Net.TcpipHeapMax = 512
NFS.MaxVolumes = 256
NFS.MaxQueueDepth = 64

Рекомендации описаны в следующих документах:
Best Practices for running VMware vSphere on Network Attached Storage
Increasing the default value that defines the maximum number of NFS mounts on an ESXi/ESX host

Другие нюансы


  1. Сетевая карта блейд-сервера должна быть совместима с модулями Virtual Connect. Совместимость можно проверить в QuickSpecs от HP.
  2. Желательно обновлять Firmware модулей Virtual Connect до последней доступной версии, но делать это стоит очень осторожно, проверяя совместимость FW блейд-серверов и корзины.
  3. В комплекте с модулями Virtual Connect SFP-трансиверы не идут, поэтому заранее планируйте схему физической коммутации, и покупайте правильные трансиверы.
  4. Virtual Connect позволяет гарантировать и устанавливать ограничения пропускной способности для подсетей (на уровне vNet/Ethernet Network/VLAN). Этим стоит пользоваться, например, для ограничения VLAN-а с Management-трафиком ESXi до 1 Gbit и гарантии VLAN-у NFS-а от 4 Gbit до 10 Gbit.

Литература


VMware vSphere 5 on NetApp Clustered Data ONTAP
Best Practices for Running VMware vSphere on Network-Attached Storage (NAS)
HP Virtual Connect FlexFabric Cookbook
FC Cookbook for HP Virtual Connect
HP Virtual Connect for the Cisco Network Administrator
HP Virtual Connect Manager Command Line Interface
Форум HP «HP BladeSystem Virtual Connect»
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 12

    0
    А можете в двух словах объяснить, что из себя представляет FlexFabric сугубо практически? Мы не используем, а гуглится только какой-то маркетинг. В чем там этот Flex?
      0
      Практически, пара модулей «HP VC FlexFabric 10/24» может заменить пару LAN модулей (а иногда и две пары) и пару SAN модулей в блейд-корзине, и позволяет гибко управлять подачей LAN и SAN-адаптеров и VLAN-ов в блейд-сервера. По данной технологии много интересного написано в блоге HP — habrahabr.ru/company/hp
        0
        Можно кинуть пять копеек в сторону нексусов, в зависимости от начинки железки, себестоимость одного «nexus» порта достаточно высока ИМХО, можно заранее расмотреть вариант использования fabric extender в сети.
      +1
      Был опыт внедрения и эксплуатации, похожей инфраструктуры виртуализации, на базе Cisco Nexus 5k /UCS 5800 /6248UP. В свое время, не стали обновлять существующие корзины HP C7000 до 10Gb, решили переехать на новые крзины Cisco UCS. Довольно таки, гибкое решение. Автор, поделитесь опытом эксплуатации NFS в среде виртуализации, интересно узнать ваше мнение?
        0
        К сожалению, опыта эксплуатации NFS у меня не так много. Я не являюсь приверженцем одной из технологий, у каждого из решений NFS/FCoE/FC есть свои плюсы и минусы, мы же остановились на NFS.
        0
        а почему NFS, а не FCoE? у вас вроде все компоненты поддерживают FCoE…
          0
          Это решение было принято СХДшниками. Насколько я знаю NFS проще FCoE в выявлении проблем.
            0
            Легче управляется, проще бэкапится, гранулярность бэкапа-восстановления выше (на уровне отдельного виртуального диска, а не датастора целиком), в ряде случаев может быть выше производительность, из-за отсутствия ограничений «одна очередь SCSI-команд на данный датастор со всеми его VMDK целиком».
              +2
              Когда у вас есть связка на подобии той которая описана в статье, а именно FlexFabric, Nexus 5k, NetApp FAS у нас есть выбор какой протокол запускать по конвергентным линкам FCoE/iSCSI/NFS для VMware. В нашем случае можно по одним и тем же линкам запустить все эти протоколы сразу. Важно отметить что для СХД NetApp все перечисленные протоколы работают практически одинаково быстро. Стоит также отметить что протокол NFS в продуктах VMWare появился именно с подачи NetApp.

              С точки зрения работы с VMware NFS протокол более удобен в плане резервного копирования/восстановления, клонирования, тонкого провиженинга (Thing Provitioning) и Дедубликации в связке с СХД NetApp.
              Когда хранилище отдаёт блочное устройство на котором потом живёт файловая система, а поверх неё лежат виртуалки, то СХД не знает о том что там и где на самом деле лежит. Когда же cистема хранения (не гипервизор) делает снепшоты или клоны с блочного устройства она не может отделить одни виртуальные машины от других, по-этому в снепшоте/клоне будут находиться все виртуальные машины. Если откатываться на ранее сделанный снепшот, то все данные будет откачены назад.
              По-этому удобнее когда СХД управляет файловой системой и соответственно знает о том что где лежит. Когда мы делаем снепшот с файловой шары NFS, то как и в случае блочного устройства откатить мы можем только всю шару целиком, но при этом можем поштучно выборочно клонировать виртуалки средствами хранилища, не нагружая гипервизор. После снятия снепшота все виртуалки зафиксированные в снепшоте будут видны из специальной папки .snapshot в корне NFS датастора, и любая виртуальная машина может быть от туда восстановлена или скопирована просто операцией копирования.


              Зачем вообще исспользовать снепшоты/клоны хранилища?
              На практике использовать снепшоты/клоны NetApp очень выгодно, так как они, в отличае VMWare снепшотов, совсем никак не влияют на производительность всей системы. Напомню, что VMware не рекомендует исспользовать свои снепшоты на высоконагруженных вируальных машинах, потому что снепшоты VMWare влияют на производительность виртуальной машины потому-что работают по технологии CoW, чем больше снепшотов, тем хуже работает виртуальная машина.

              ThingProvitioning / Дедубликация на хранилище
              ThingProvitioning который исспользуется на СХД NetApp FAS тоже не влияет на производительность.
              Когда вы исспользуете эти технологии на стороне хранилища, то высвобожденное пространство в случае NFS возращается «внутрь» файловой шары и может исспользоваться живущими на ней виртуалками, в случае блочного хранения высвобожденное какбы во вне луна (можно создать ещё один лун), а не внутрь.

              Блочные протоколы FC/FCoE/iSCSI удобно исспользовать для загрузки серверов. Важным преимуществом блочных протоколов перед NFS является наличие встроенного механизма мультипасинга и балансировки нагрузки. Так как у NFS нет мультипасинга, его роль должен выполнять коммутатор и технологии на подобии vPC и LACP. Также протоколы FC/FCoE устроены таким образом, что они не теряют свои фреймы, это кстати часто является причиной более низких задержек чем у Ethernet. К счастью Nexus 5k поддерживает DCB (lossless Ethernet), vPC, LACP что позволяет полностью компенсировать все эти недостатки NFS.
                +1
                спасибо! тот случай когда комментарий ценнее статьи )

                едниственный нюанс — imho, LACP или vPC никак не помогут NFS-у. Данные в LACP/vPC распределяются по линкам в лушчем случае в зависимости от хэша (src-ip+port / dst-ip+port) и соответвенно поток данных от хоста к хранилке всегда будет идти одним путем. Ну разве кто-то опубликует хранилку с двумя адресами и это будут два разных стора для машин.
                  0
                  Полностью с вами согласен.
                  Общее правило для LACP гласит, что количество хостов должно быть равное или больше чем линков по которым необходимо балансировать нагрузку, и чем больше хостов тем более вероятно что они более равномерно утилизируют пропускную способность всех агрегированных линков.
                  Но можно и не надеяться на вероятность, а высчитать подходящие IP адреса, чтобы утилизировать все линки.

                  Но к счастью обычно число хостов в ЦОД на намного больше числа линков. По этому для большинства ЦОД ов это совсем не проблема.
                  Кроме того если речь про 10Гб линки, как в нашем случае, то нужно еще постараться чтобы загрузить хотя-бы один 10Гб линк.

                  Посему возвращаюсь к своему первоначальному утверждению, что разницы В ПРАВИЛЬНО НАСТРОЕННОЙ ИНФРАСТРУКТУРЕ между блочным протоколами и nfs быть не должно.
                    0
                    Высчитать правильные IP (если хостов действительно мало) можно так.

              Only users with full accounts can post comments. Log in, please.