В этой части описана конфигурация хостов. Приводится пример настройки с 8 сетевыми адаптерами и iSCSI подключением, а также другие конфигурации

Вот некоторые основные правила:

• Все сети должны иметь минимум два pNICs для обеспечения отказоустойчивости.

• Если не указано иное, все параметры имеют значения по умолчанию. Это согласуется с моим “не изменяйте значение по умолчанию, если у вас есть веская причина” философии (и это делает его легче описать!)

• Есть требование, чтобы поддерживать две отдельные “application zones”. Это логически отдельные сети, которые могут быть разделены через VLANs или физически.

Конфигурация с 8 pNICs и IP Storage

Восемь-это действительно хорошее количество pNICs, если вы планируете использовать хранилище на основе IP. Если вы помните из части 5 этой серии, есть множество сетей, которые нам нужно поддерживать на ESX:

• Сеть Управления VMware. Это сеть, которая соединяет vCenter Server с консолью службы ESX. Так как ESXi не имеет сервисной консоли, сеть управления ESXi прекращена в vmkernel.

• VMotion Network. Эта сеть соединяет различные хосты ESX/i (reminder, ESX/i-это моя сокращенная нотация для ESX и/или ESXi) в кластере VMware и включает VMotion среди этих узлов.

• IP Storage (NFS or iSCSI) Network. Сеть, предоставляющая хранилище для виртуальной машины и вспомогательную поддержку (т. е.файл ISO).

• Virtual Machine Network(s). Одна или несколько сетей, поддерживающих виртуальную машину для доступа и предоставления служб.

Обратите внимание, что есть четыре сети – чтобы получить избыточность, которую я сказал, что мы собираемся реализовать, умножьте четыре на два, и вы получите восемь! (Можете ли вы справиться с этой математикой верхнего уровня? Это иногда бросает меня на петлю!)

Итак, теперь у нас есть достаточно информации, чтобы выбросить конфигурацию (рис.1):

рис.1. Базовая Конфигурация восемь pNIC

Как вы можете видеть, я выложил четыре коммутатора, каждый с двумя настроенными восходящими каналами nic. Алгоритм балансировки нагрузки - "маршрут на основе идентификатора порта виртуального коммутатора". Хотя это совершенно нормальная, надежная и распространенная конфигурация, есть некоторые недостатки, связанные с этой конфигурацией:

vSwitch0 и vSwitch1 каждый имеют два pic, связанных с ними; однако существует одна группа портов и, что более важно, одна служба, связанная с каждым. Это означает, что каждый из этих двух vswitch будет иметь панику, сидя без дела, ожидая активного пути к неудаче. В Великой схеме вещей, это не такая ужасная вещь. Мы говорим о том, что, может быть, тысяча долларов стоит “вещи”, сидя без дела? Между двумя pic, связанными кабелями и физическими портами коммутатора, это может быть немного низким, но в целом, не имеет большого значения.

vSwitch2 посвящена ИС хранения. Во многих случаях это будет или iSCSI или NFS; однако нет ничего, чтобы помешать вам выполнять оба протокола через этот одиночный vSwitch. На самом деле, многие места будут делать именно это – используя iSCSI для хранения томов VMFS и NFS для хостинга .iso и другие "файлы поддержки". Обратите внимание, что при использовании хранилища iSCSI необходимо предоставить консоли службы видимость в этой сети для проверки подлинности.

vSwitch3-это виртуальная машина vSwitch. Поскольку у нас есть две среды приложений, мы определили две различные VLAN (просто добавив номер VLAN в конфигурацию группы портов и гарантировав, что pSwitch настроен для транкинга требуемых VLAN). Если ваша политика диктует, что эти две среды приложений не должны быть позволены comingle на проводе, необходимо было бы добавить два дополнительных pnic (для поддержания избыточности), и гарантировать, что никакой comingling, я рекомендовал бы отдельный vSwitch, а не группы портов с активными/резервными/неиспользуемыми конфигурациями pNIC.

Теперь давайте немного оживим его и добавим требование поддержки Многопутевого ввода-вывода (MPIO) из наших виртуальных машин. Для поддержки MPIO из виртуальной машины VMware необходимо подготовить виртуальную машину с несколькими vNICs. В моем примере я собираюсь настроить виртуальную машину с тремя vNICs-один для "обычного" сетевого трафика и два для поддержки доступа MPIO к цели iSCSI. В дополнение к этим прямым сетевым подключениям виртуальная машина будет обращаться к своему системному тому как к виртуальному диску через стек iSCSI vmkernel (см. рис. 2).

рис. 2. Оценки конфигурации ОС многопутевого ввода-вывода для iSCSI 

Итак, теперь у нас есть одна виртуальная машина, которая подключается к четырем отдельным группам портов (хотя подключение к PG_IPStor полностью прозрачно – абстрагировано через контроллер vscsi гостевой ОС). Что действительно делает этот ВМ отличается двумя дополнительными vNICs, которые подключены к PG_VMStor1 и порт группы PG_VMStor2. Мы будем загружать инициатор iSCSI внутри гостевой операционной системы для доступа к цели iSCSI. Я не буду вдаваться в подробности о том, как настроить инициатор iSCSI для поддержки MPIO, но просто поверьте мне, когда я скажу вам, что вы можете получить лучшую балансировку нагрузки и лучшую общую производительность iSCSI, используя этот подход, а не собственный доступ ESX iSCSI. Это улучшенное представление приходит с значительно ценой, однако. Используя этот подход, теперь необходимо управлять инициатором iSCSI в гостевой ОС и управлять распределением целей iSCSI инициаторам. Кроме того, инициатор iSCSI внутри виртуальной машины значительно повысит загрузку ЦП хоста. Это (более высокая загрузка ЦП) часто не большая проблема, потому что многие среды не ограничены ЦП для начала. Дополнительные управленческие накладные расходы являются большой проблемой (для меня).

Я настоятельно рекомендую вам использовать это решение только тогда, когда вы обнаружите, что стандартный механизм (подключение через интерфейс vSCSI) для доступа к хранилищу iSCSI не обеспечивает необходимый уровень производительности. Помните, только потому, что что-то” быстрее “не делает его”лучше"! Во многих случаях я видел, как люди проходят через боль от реализации этого решения, только чтобы обнаружить, что пропускная способность хранилища не была их узким местом, и предоставление более Толстой трубы вообще не помогло общей производительности. Во многих (большинство?) случаи, узкое место производительности живет в приложении, а не в поддерживающей инфраструктуре.

Вот как это решение будет выглядеть (Рисунок 3):

Рис. 3. Восемь конфигураций pNIC с гостевым MPIO

Подожди! Что я вижу на vSwitch1? Может быть? Это возможно? Кен действительно настроил активные и пассивные фотографии? Да, я сделал! Почему? Ну, это действительно довольно просто. Алгоритм балансировки нагрузки по умолчанию основан на идентификаторе порта коммутатора. Если вы помните из части 3 этой серии, нет никаких гарантий, о которых pNIC ваш vNIC будет ассоциироваться с. В этом случае нам нужно убедиться, что vNICs оказывается на разных фотографиях. Сначала румянец, казалось бы, что я мог бы по умолчанию все и еще быть в порядке, но что произойдет, если подключить и отключить пару vNICs во время операций? Помните, что коммутатора порты закреплены pNICs, если я мощностью до трех виртуальных машин, первый и третий с двумя vNICs, а второй с одного виртуального сетевого адаптера подключение в vSwitch1, я бы в следующем (Рис. 4):

Рис.4. Начальное сопоставление vNIC виртуальной машины

Обратите внимание, что порт vSwitch #3 статически сопоставлен с pNIC2. Теперь, если я выключаю вторую VM (тот с только одним vNIC) и питание на другой VM с двумя vNICs, я заканчиваю с конфигурацией, показанной на рисунке 5.

Рис. 5. Вторичное сопоставление vNIC виртуальной машины

Заметьте теперь, что оба vnic для недавно включенной виртуальной машины сопоставлены с pNIC1-не то, что мы хотели! Если бы вы могли гарантировать, что каждая VM, подключенная к этому vSwitch, имела бы два vnic и что, ни в коем случае, любая из vnic была бы административно отключена, можно было бы позволить конфигурации к умолчанию. Лично, это слишком много "если" для меня, чтобы доверять!

Вау! Мало того, что я нашел оправдание, чтобы сломать мое правило "всегда по умолчанию", я нашел хороший пример того, почему вы хотите использовать активные и резервные адаптеры!

Конфигурация с восемью pNICs без хранения IP

Это очень просто. Если вы возьмете первый пример и сохраните требования такими же, просто удалите потребность в IP-хранилище и все еще используйте восемь pnic, я бы сделал следующее (Рисунок 6):

Рис. 6. Восемь фото без хранения IP

Все, что мы сделали, это разделить две сети приложений на отдельные vSwitches, обеспечивая дополнительную пропускную способность (вероятно, не требуется) и дополнительную отказоустойчивость. Делая это, мы устранили необходимость настраивать транкинг VLAN на коммутаторе, а также не нужно указывать номер VLAN на группах портов PG_App1 и PG_App2.