Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Trunking | about NetApp

Posts tagged ‘trunking’

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, то в случае кластерного файловера алиасы также перенесутся на партнерский интерфейс

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

Continue reading ‘Multimode VIF в NetApp (часть 2)’ »

20/0.077

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.