Нюансы связки esxi, flexfabric, 10 gbit и nfs

Migrate Management Network

Migrate the management network (vmk0) and its associated uplink (vmnic0) from the standard vSwitch to the distributed vSwitch (vDS).

  1. Add hosts to the vDS.
    1. Right-click the vDS and select menu Add and Manage Hosts.
    2. Add hosts to the vDS. Click the green Add icon (+), and add all hosts from the cluster.
  2. Configure the physical adapters and VMkernel adapters.
    1. Click Manage physical adapters to migrate the physical adapters and VMkernel adapters, vmnic0 and vmk0 to the vDS.
    2. Select an appropriate uplink on the vDS for physical adapter vmnic0. For this example, use Uplink1. The physical adapter is selected and an uplink is chosen.
  3. Migrate the management network on vmk0 from the standard vSwitch to the distributed vSwitch. Perform these steps on each host.
    1. Select vmk0, and click Assign port group.
    2. Assign the distributed port group created for the management network earlier.
  4. Finish the configuration.
    1. Review the changes to ensure that you are adding four hosts, four uplinks (vmnic0 from each host), and four VMkernel adapters (vmk0 from each host).
    2. Click Finish.

When you examine the networking configuration of each host, review the switch settings, with one uplink (vmnic0) and the vmk0 management port on each host.

Repeat this process for the other networks.

Load Balancing

Первым пунктом в настройке является load-balancing policy. Говоря по простому мы выбираем как vSwitch будет обрабатывать исходящий трафик.

Имеется 4 варианта обработки трафика:

  • Route based on the originating virtual port
  • Route based on IP hash
  • Route based on source MAC hash
  • Use explicit failover order

Route based on the originating virtual port

Данная опция является стандартным для любого только что созданного vSwitch и каждая виртуальная машина и VMkernel порт на vSwitch подключён к виртуальному порту. Когда vSwitch получает трафик от подключённых к нему объектов он назначает виртуальный порт и физический порт и использует его для передачи данных. Выбранный физический порт  не меняется до тех пор пока не произойдёт какая либо ошибка или виртуальная машина не выключится или не мигрирует на другой сервер.

Route based on IP hash

Данная опция используется совместно с группой агрегации каналов LAG, так же называется EtherChannel или Port Channel. Когда трафик попадает на vSwitch, политика балансировки каналов создаёт в пакете хеш IP-адреса источника и назначения. Результирующий хеш указывает какой физический порт будет использоваться.

Route based on source MAC hash

Данная опция схожа по принципу работы с Route based on IP hash, за исключением того, что политика рассматривает только MAC-адрес источника в кадре Ethernet.

Use explicit failover order

Данная опция в действительности не выполняет никакой балансировки нагрузки и если у вас используется для подключения несколько физических портов то в любой момент времени использоваться будет только один. Сначала система пытается использовать первый активный физический сетевой порт. Если использовать первый физический порт не удаётся, то используется следующий активный физический порт и так далее.

Пример настройки

Пример показывает как с помощью vSphere Client можно настроить NIC Teaming на хосте с использованием Route based on IP hash.

В моем случае все физические порты ESXi хоста подключены к коммутатору Cisco, на котором уже собран EtherChannel

1. Выбираем необходимы хост и переходим во вкладку Configuration — Networking. По умолчанию в системе всегда уже имеется стандартный vSwitch — его свойства мы и откроем нажав на кнопку Properties.

2. В появившемся окне выбираем vSwitch и нажмем кнопку редактировать Edit

3. В появившемся окне откроем вкладку NIC Teaming и укажем следующие параметры:

Опцию Load Balancing установим в Route based on IP hashОпцию Network Failure Detection установим в link status onlyОпцию Notify Switches установим в YesОпцию Failback установим в Yes

Так же проследим, что все физические порты активированы и переведены в раздел Active Adapters

Network Failure Detection

Данный пункт отвечает за определение ошибок в подключении физических портов и имеет две опции.

link status only

Данная опция позволяет определить ошибки, вызванные отключением кабеля или проблемой физического интерфейса и не способна определять конфигурационный ошибки, такие как если физический коммутатор заблокировал порт из-за ошибок конфигурации VLAN,spanning tree или отключения кабеля на другой стороне физического коммутатора.

Beacon probing

Данная опция отправляет и слушает специальные пакеты-маяки на все физические интерфейсы в группе и использует полученную информацию. В дополнение так же использует статус физического порта для определения проблемы подключения. Данная опция способна более точно определить проблему в отличие от link status only.

Не используйте Beacon probing вместе с Route based on IP hash чтобы избежать ложных срабатываний.

Create Port Groups

A single default port group was created for the management network. Edit this port group to make sure it has all the characteristics of the management port group on the standard vSwitch, such as VLAN and NIC teaming, and failover settings.

Configure the management port group.

  1. In the vSphere Client Networking view, select the distributed port group, and click Edit.
  2. For some port groups, you must change the VLAN. Since VLAN 51 is the management VLAN, tag the distributed port group accordingly.
  3. Click OK.

Create distributed port groups for vMotion, virtual machine networking, and
vSAN networking.

  1. Right-click the vSphere Distributed Switch and select menu Distributed Port Group > New Distributed Port Group.
  2. For this example, create a port group for the vMotion network.

Create all the distributed port groups on the distributed vSwitch. Then migrate the uplinks, VMkernel networking, and virtual machine networking to the distributed vSwitch and associated distributed port groups.

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

  • 15.10.15 07:51


chestor2

#268859

Хабрахабр

5653

ИТ-инфраструктура

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

Особое внимание уделено нюансам работы 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»

Migrate VM Network

The final task needed to migrate the network from a standard vSwitch to a distributed vSwitch is to migrate the VM network.

Manage host networking.

  1. Right-click the vDS and choose menu Add and Manage Hosts.
  2. Select all the hosts in the cluster, to migrate virtual machine networking for all hosts to the distributed vSwitch.

    Do not move any uplinks. However, if the VM networking on your hosts used a different uplink, then migrate the uplink from the standard vSwitch.

  3. Select the VMs to migrate from a virtual machine network on the standard vSwitch to the virtual machine distributed port group on the distributed vSwitch. Click Assign port group, and select the distributed port group.
  4. Review the changes and click Finish. In this example, you are moving to VMs. Any templates using the original standard vSwitch virtual machine network must be converted to virtual machines, and edited. The new distributed port group for virtual machines must be selected as the network. This step cannot be achieved through the migration wizard.

Since the standard vSwitch no longer has any uplinks or port groups, it can be safely removed.

This completes the migration from a vSphere Standard Switch to a vSphere Distributed Switch.

Виды VMware vMotion

У компании VMware есть целый пласт технологий, который относится к vMotion, давайте я покажу из каких видом он состоит и для чего используется:

  • Change compute resource only vMotion — Это обычный, классический вид миграции между хостами ESXI, виртуальный сервер переезжает на ресурсы (CPU, RAM) другого сервера ESXI.
  • Change storage only — это описанная мной ранее Storage vMotion.
  • Change both compute resource and storage vMotion — это перемещение виртуальной машины и ее дисков на другой хост и хранилище
  • Cross vCenter Server export — Перенос на другой сервер vCenter
  • Shared-Nothing vMotion – миграция ВМ между серверами ESXi по сети без использования общего хранилища (требуется L2 сеть)
  • Long Distance vMotion — Многие компании делают отказоустойчивые решения и могут легко растягивать свою инфраструктуру между несколькими цодами. Для таких задач, есть решение «Long Distance vMotion», которое позволяет переносить виртуальные машины между удаленными площадками максимальная задержка Round Trip Time до 150 мс, в том числе в L3-сетях). Идет под капотом vCenter 6 и выше.
  • Cross-Cloud Cold и Hot Migration —  Это миграция между облачной vCenter и наземной, все как в Active Directory on premise и Azure
  • Encrypted vSphere vMotion — Это шифрование виртуальной машины при передаче по сети, фишка vSphere 6.5 и выше

Flow Control

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.«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».
NETAPP vs VMWARE FLOW CONTROL DILEMMAConfiguring Flow Control on VMware ESXi and VMware ESX

Как включить Vmotion в vCenter 7

Давайте покажу как активируется vMotion на хостах ESXI 7 через vCenter 7. Откройте HTML клиента и выберите нужный вам хост, перейдите на вкладку «Configure — Networking — VMkernel adapters». У вас тут будет список интерфейсов VMkernel. Слева вы можете увидеть совершенно непримечательную кнопку в виде трех вертикальных точек, нажмите ее.

Далее вам остается просто активировать на данном VMkernel нужную галку «vMotion». Так, что если вы до этого не знали, где активируется vMotion в vCenter 7, то вам придется попотеть в поисках данной кнопки.

Ограничения на одновременные миграции

vCenter Server устанавливает ограничения на количество одновременных операций миграции и подготовки виртуальных машин, которые могут выполняться на каждом узле, сети и хранилище данных. Каждой операции, такой как миграция с помощью vMotion или клонирование виртуальной машины, назначается стоимость ресурсов. Каждый хост, хранилище данных или сетевой ресурс имеет максимальную стоимость, которую он может поддерживать в любой момент. Любая новая операция миграции или подготовки, которая приводит к превышению максимальной стоимости ресурса, не выполняется немедленно, а ставится в очередь до тех пор, пока другие операции не завершатся и не освободят ресурсы. Для продолжения операции должны быть соблюдены все ограничения для сети, хранилища данных и хоста.

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

Сетевая карта блейд-сервера должна быть совместима с модулями Virtual Connect

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

Второй способ.

Править вручную маску CPU и ВМ. Основным плюсом можно назвать, что конфигурировать можно более гибко. Например в кластере с разношерстными хостами по CPU и ВМ по функциям. Но и главный недостаток в том, что конфигурировать придется каждую ВМ по отдельности. Плюс ко всему данный способ официально не поддерживается VMware, так что скажем buy сапорту VMware.

И так как править маски CPU у ВМ.

Первое что нужно сделать это прочитать вот .

Если с английским плохо, читаем дальше. Опишу, как изменить маску по примеру приведенному выше для CPU x5400 и x5500.

Из KB для Intel CPU дана вот такая таблица.

Как включить EVC (Enhanced vMotion Compatibility) в vMware Esxi 5.x.x-01

Отличие инструкций между семействами CPU x5400 и x5500 только в поддержки SSE 4.2 у последнего. Поэтому в маске нужно указать, чтобы не использовались данные инструкции. Все очень просто. Выключаем нужную ВМ. Идем в ее свойства. Вкладка Options -> CPUID Mask.

Как включить EVC (Enhanced vMotion Compatibility) в vMware Esxi 5.x.x-02

Жмем Advanced. Далее исходя из таблички выше нам нужно подправить маску в уровнях 1, строку ecx  и 800000001, строку edx. Кликаем на нужную строчку, в нашем случае edx строка  и пишем туда следующее —- 0— —- —- —- —- —- —-

Как включить EVC (Enhanced vMotion Compatibility) в vMware Esxi 5.x.x-03

Далее находим следующую строчку, и пишем как указано в таблице из KB —- —- 0—0 —- —- —- —- —-

Как включить EVC (Enhanced vMotion Compatibility) в vMware Esxi 5.x.x-04

Все применяем нужные изменения. Ждем когда закончится реконфигурация ВМ и запускаем ее. Все теперь данную ВМ можно спокойно мигрировать. Мастер VMotion не должен выдавать предупреждений по поводу несовпадения масок.

Migrate vSAN Network

If you have a single uplink for the vSAN network, then use the same process as before. However, if you are using more than one uplink, there are additional steps.

If the vSAN network is using Link Aggregation (LACP), or it is on a different VLAN to the other VMkernel networks, place some of the uplinks into an unused state for certain VMkernel adapters.

For example, VMkernel adapter vmk2 is used for vSAN. However, uplinks vmnic3, 4 and 5 are used for vSAN and they are in a LACP configuration. Therefore, for vmk2, all other vmnics (0, 1 and 2) must be placed in an unused state. Similarly, for the management adapter (vmk0) and vMotion adapter (vmk0), place the vSAN uplinks/vmnics in an unused state.

Modify the settings of the distributed port group and change the path policy and failover settings. On the Manage physical network adapter page, perform the steps for multiple adapters.

Assign the vSAN VMkernel adapter (vmk2) to the distributed port group for vSAN.

Note: If you are only now migrating the uplinks for the
vSAN network, you might not be able to change the distributed port group settings until after the migration. During this time,
vSAN might have communication issues. After the migration, move to the distributed port group settings and make any policy changes and mark any uplinks to be unused.
vSAN networking then returns to normal when this task is finished. Use the
vSAN health service to verify that everything is functional.

Create a Distributed Switch

Create the distributed vSwitch and give it a name.

  1. In the vSphere Client Host and Clusters view, right-click a data center and select menu New Distributed Switch.
  2. Enter a name.
  3. Select the version of the vSphere Distributed Switch. In this example, version 6.6.0 is used for the migration.
  4. Add the settings. Determine how many uplinks you are currently using for networking. This example has six: management, vMotion, virtual machines, and three for vSAN (a LAG configuration). Enter 6 for the number of uplinks. Your environment might be different, but you can edit it later.

    You can create a default port group at this point, but additional port groups are needed.

  5. Finish the configuration of the distributed vSwitch.

The next step is to configure and create the additional port groups.

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Мой редактор ОС
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: