Multimode VIF в NetApp (часть 2)

MAC Load-Balancing
Этот алгоритм используется не так часто, так как ему присущ ряд недостатков. Основанный на использовании MAC алгоритм балансировки вычисляет XOR между MAC-адресами пар источника и получателя. Источником будет MAC-адрес сетевой карты хосте, подключенного к контроллеру  NetApp. Получателем будет MAC-адрес VIF-интерфейса контроллера NetApp. Алгоритм работает хорошо, когда хосты и контроллер NetApp размещаются в одной подсети или VLAN. Когда хост расположен в другой подсети относительно контроллера NetApp, мы сталкиваемся с недостатками алгоритма. Для понимания того, что происходит, нам надо разобраться с тем, что происходит с фреймом Ethernet, когда он маршрутизируется по сети.

Допустим, мы хотим соединить Host1 с Controller1.

Host1 IP address - 10.10.1.10/24 (default gateway для Host1 - 10.10.1.1)
Controller1 IP address - 10.10.3.100/24 (default gateway для Controller1 - 10.10.3.1)

Выше мы задали для Host1 и Controller1 две отдельные подсети. Единственный путь передачи данных в том случае - через роутер. В рассматриваемом случае, роутер для подсетей 10.10.1.1 и 10.10.3.1 это один и тот же физический роутер, эти адреса просто два физических его интерфейса. Задача роутера - связать две подсети, и обеспечить передачу данных между ними.

Когда Host1 передает frame предназначенный для Controller1, он отправляет его на роутер по адресу default gateway, так как видит, что адрес 10.10.3.100 это IP-адрес не его локальной подсети, потому он отправляет его в адрес default gateway, по которому расположен роутер, в надежде, что роутер знает что с ним делать дальше, и найдет путь к получателю.

с Host1 на Host1Router

-IP Source: Host1 (10.10.1.10)
-MAC Source: Host1
-IP Destination: VIFController1 (10.10.3.100)
-MAC Destination: Host1DefaultRouter

с Host1Router на Controller1

-IP Source: Host1 (10.10.1.10)
-MAC Source: Controller1DefaultRouter
-IP Destination: VIFController1 (10.10.3.100)
-MAC Destination: VIFController1

Обратите внимание: MAC-адреса источника и получателя меняются, когда фрейм передается по сети. Так работает маршрутизация, и когда маршрутизаторы встречаются на пути несколько раз, то и MAC будет изменен несколько раз по пути от источника к получателю. Не важно сколько раз конкретно, главное что он меняется когда фрейм попадает в локальный сегмент контроллера. MAC источника будет являться MAC-ом роутера, а получателем – MAC-адрес VIF контроллера. Для полного понимания проблемы, допустим у нас есть четыре 1Gbps канала, объединенных в Etherchannel на Controller1. Допустим у нас есть 50 хостов в той же подсети, что и  Host1. Пары source и destination для соединения Host1 к Controller1 будут ровно теми же, что и любых других хостов в подсети host1, так как  MAC-адреса source и destination всегда будут равны Controller1DefaultRouter и VIFController1.

IP Load-Balancing
IP Load-Balancing это параметр по умолчанию для всех NetApp MultiMode VIF и наиболее часто используемый на практике метод построения MultiMode VIF на сегодня. Алгоритм не отличается от уже рассмотренного алгоритма с использованием MAC, который мы расмотрели выше. Разница только в том, что мы используем IP-адреса Источника (Source) и Получателя (Destination), которые, если вы посмотрите рассмотренный ранее вариант, никогда не менятся, в отличие от  адресов MAC. Факт того, что IP-адреса не меняются, создает сценарий, в котором у вас больше шансов получить уникальные пары, что, в результате, приводит к более равномерному распределению трафика по физическим линкам.

Для правильного понимания механизма работы следует учесть один важный момент, касающийся пар IP-адресов source и destination: при вычислении пар source-destination принимаются во внимание только последние октеты адресов. Это означает, что в адресе 10.10.1.10 будет использован для идентификации только 10 – последний октет адреса, в адресе 10.10.3.100 - только 100. Принимать во внимание этот момент следует в случае развертывания системы в сети, состоящей из нескольких подсетей, в этом случае может получиться так, что адреса из разных подсетей (но с одинаковым последним октетом) будут передаваться по одному физическому линку.

IP Aliasing
Понимание принципов алгоритмов Load-Balancing позволяет вам, как администратору, использовать их к собственной выгоде. Все NetApp VIF и физичские интерфейсы имеют возможность назначить им так называемые “алиасы”. Это просто дополнительный адрес для самого VIF. Рекомендуется назначит адреса(для VIF + определенное количество алиасов) равное числу физических линков в EtherChannel между контроллером и коммутатором, к которому подключен контроллер. Таким образом если вы используете VIF, состоящий из  4 штук 1Gbps линков в виде MultiMode VIF между контроллером и коммутатором, то назначьте один адрес для VIF и добавьте к нему три алиаса для того же VIF.

Простое назначение дополнительных адресов не поможет использовать преимущества дополнительных адресов. Вы должны убедиться, что хосты, которые смонтировали данные с контроллеров NetApp используют все эти адреса. Этого можно достичь несколькими разными путями, в зависимости от того, какие протоколы используются для доступа к данным, ниже приведены некоторые примеры для NFS.

Oracle NFS -  хосты с Oracle должны монтировать тома NFS равномерно распределяя их по доступным  IP-адресам контроллера. Если у вас есть 4 различных NFS ресурса, то смонтируйте их используя для доступа четыре различных IP-адреса контроллера. Каждый ресурс будет иметь различную пару из источника и получателя (source and destination pair) и полоса передачи между хостом и контроллером будет использована более эффективно.

VMware NFS – хосты ESX должны монтировать каждый NFS Datastore через различные IP-адреса контроллера NetApp. Такой вариант наилучшим способом использует один интерфейс VMkernel (адрес источника (source)). Если у вас больше датасторов, чем  IP-адресов, то просто распределите датасторы по доступным IP-адресам контроллера NetApp поравномернее.

Обратите внимание: Когда вы назначаете алиас интерфейсу, и у вас установлены и включены партнерские отношения между двумя контроллерами (и, естественно, их физическими интерфейсами) кластера NetApp, то в случае кластерного файловера алиасы также перенесутся на партнерский интерфейс

Ну и, наконец, обещанные шаблоны:

LACP - Dynamic MultiMode VIF

____________________________________

Filer RC File

#Manually Edited Filer RC file  3 March, 2009,  by Trey Layton

hostname filer a

vif create lacp template-vif1 -b ip e0a e0b e0c e0d

ifconfig template-vif1 10.10.3.100 netmask 255.255.255.0 mtusize 1500 partner (partner-vif-name)
ifconfig template-vif1 alias 10.10.3.101 netmask 255.255.255.0
ifconfig template-vif1 alias 10.10.3.102 netmask 255.255.255.0
ifconfig template-vif1 alias 10.10.3.103 netmask 255.255.255.0

route add default 10.10.3.1 1
routed on
options dns.domainname template.netapp.com
options dns.enable on
options nis.enable off
savecore

_____________________________________

Cisco Configuration

!!!!!! The following interface is a virtual interface for the etherchannel.
!!!!!!This interface must be referenced
!!!!!! on the physical interface to create the channel.

interface Port-channel 1
description Virtual Interface for Etherchannel to filer
switchport

switchport mode access

switchport nonegotiate
spanning-tree guard loop

spanning-tree portfast
!

!!!!! The following are the physical interfaces in the channel.
!!!!! The above is the virtual interface for the channel.
!!!!! Each physical interface will reference the virtual interface.

interface GigabitEthernet 2/12
description filer interface e0a
switchport
switchport mode access

switchport nonegotiate
flowcontrol receive on

no cdp enable
spanning-tree guard loop
spanning-tree portfast
channel-protocol lacp
channel-group 1 mode active

!!!!!!
!!!!!! The above channel-group command is the command
!!!!!! which bonds the physical interface to the virtual interface
!!!!!! previously created.
!!!!!! The command following the channel number is the mode - active is for LACP.
!!!!!!
!
interface GigabitEthernet 2/13
description filer interface e0b
switchport
switchport mode access

switchport nonegotiate
flowcontrol receive on

no cdp enable
spanning-tree guard loop
spanning-tree portfast
channel-protocol lacp
channel-group 1 mode active

!
interface GigabitEthernet 2/14
description filer interface e0c
switchport
switchport mode access

switchport nonegotiate
flowcontrol receive on

no cdp enable
spanning-tree guard loop
spanning-tree portfast
channel-protocol lacp
channel-group 1 mode active

!
interface GigabitEthernet 2/15
description filer interface e0d
switchport
switchport mode access

switchport nonegotiate
flowcontrol receive on

no cdp enable
spanning-tree guard loop
spanning-tree portfast
channel-protocol lacp
channel-group 1 mode active

Static EtherChannel - Static MultiMode VIF

____________________________________

Filer RC File

#Manually Edited Filer RC file 3 March, 2009, by Trey Layton

hostname filer a

vif create multi template-vif1 -b ip e0a e0b e0c e0d

ifconfig template-vif1 10.10.3.100 netmask 255.255.255.0 mtusize 1500 partner (partner-vif-name)
ifconfig template-vif1 alias 10.10.3.101 netmask 255.255.255.0
ifconfig template-vif1 alias 10.10.3.102 netmask 255.255.255.0
ifconfig template-vif1 alias 10.10.3.103 netmask 255.255.255.0

route add default 10.10.3.1 1
routed on
options dns.domainname template.netapp.com
options dns.enable on
options nis.enable off
savecore

_____________________________________

Cisco Configuration

!!!!!! The following interface is a virtual interface for the etherchannel.
!!!!!! This interface must be referenced
!!!!!! on the physical interface to create the channel.

interface Port-channel 1
description Virtual Interface for Etherchannel to filer
switchport

switchport mode access
switchport nonegotiate
spanning-tree guard loop

spanning-tree portfast
!

interface GigabitEthernet 2/12
description filer interface e0a
switchport
switchport mode access
switchport nonegotiate
flowcontrol receive on

no cdp enable
spanning-tree guard loop
spanning-tree portfast
channel-group 1 mode on

!!!!!!
!!!!!! The above channel-group command is the command
!!!!!! which bonds the physical interface to the virtual interface
!!!!!! previously created. The command following the channel number
!!!!!! is the mode - active is for LACP.
!
interface GigabitEthernet 2/13
description filer interface e0b
switchport
switchport mode access
switchport nonegotiate
flowcontrol receive on

no cdp enable
spanning-tree guard loop
spanning-tree portfast
channel-group 1 mode on

!
interface GigabitEthernet 2/14
description filer interface e0c
switchport
switchport mode access
switchport nonegotiate
flowcontrol receive on

no cdp enable
spanning-tree guard loop
spanning-tree portfast
channel-group 1 mode on

!
interface GigabitEthernet 2/15
description filer interface e0d
switchport
switchport mode access
switchport nonegotiate
flowcontrol receive on

no cdp enable
spanning-tree guard loop
spanning-tree portfast
channel-group 1 mode on

_____________________________________

Примечание читателя: Бывают случаи, когда включение в конфигурацию Cisco параметр flowcontrol recieve on мешает правильной работе LACP. Проверить.

Примечание romx: Я вижу все недостатки переведенного текста, но увы, пока ничего приемлемее не нашлось, хоть самому пиши :(

UPD: На рассмотренную тему рекомендую смотреть более поздний пост - Ethernet Storage и приведенный там перевод.

9 комментариев

  1. paul-k:

    возможно он не заработал потому что со стороны головы не было ‘ifconfig e0a flowcontrol send’ (по умолчанию - full) - а в циске стоит принудиловка только на receive… какой-то косяк в negotiation

  2. Nikolay:

    Multimode VIF в NetApp (часть 2) - почему-то не могу найти в Вашем блоге первую часть статьи :(

  3. Он случайно затерся своей второй частью. Если очень надо, то восстановлю на следующей неделе.

  4. Nikolay:

    Если не затруднит, восстановите пожалуйста.

  5. Anton:

    Приветствую, вторая часть отличная, спасибо, но хочется прочитать и первую. Может к годовому юбилею восстановите?

  6. Anton: нет смысла. Эти два поста являются, фактически, главой из документа TR-3802 Ethernet Storage, того же автора, который я первел целиком и выложил в техбиблиотеку Netwell, о чем есть ссылка в UPD.
    Лучше его читайте.

  7. bbk:

    В
    ifconfig e0a 10.1.1.100 netmask 255.255.255.0 mtusize 9000 partner
    10.1.1.200 flowcontrol send

    что такое 10.1.1.200? По логике вещей это должен быть свич. Или всё-же это партнёр (сервер который примапил шару/лун)?

  8. bbk:

    Это IP интерфейса контроллера-партнера. Того, на который будет перенесен данный интерфейс, в случае отказа данного контроллера.

  9. bbk:

    В результате тестирования я убедился в том, что если речь о IP балансировке в рамках одной подсети и количество физических серверов как минимум равно количеству агрегированных физических линков, то никакие алиасы цеплять не нужно. Как правило эти условия соблюдаются автоматически.
    От алиасов только голавная боль при работе с NFS - такие шары примапленные по разным IP адресам (NAS’a) видятся как разные датасторы и соответственно vMoution произойти не может.

    Интересно, а если мапить с разных IP адресов (хоста) на один IP адрес (СХД) будет ли vSphere’а понимать, что это один и тот же датастор? Если да, то в такой схеме проблем с vMoution по идее быть не должно. Но с этим есть смысл замарачиваться, только если в вышеописанных условиях вместо одной подсети - несколько и последние октеты совпадают у нескольких хостов. Но с другой стороны проще уже выполнить условие уникальности последнего октета узлов подключённых к СХД.

Оставить комментарий

20/0.143

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

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.