Network I/O Control (NetIOC, NIOC) позволяет контролировать разделение сетевых ресурсов в случае борьбы за ресурсы. NIOC предоставляет дополнительный уровень контроля использования пропускной способности сети в виде лимитов и изоляции. Операции vMotion создают кратковременный скачок трафика, который пытается использовать максимум доступной пропускной способности сети. В конвергентной сети операция vMotion иметь деструктивный эффект на другие типы трафика. Принцип работы NetIOC позволяет каждому типу трафика предоставить гарантированную полосу пропускания учитывая, что все они борются за одну полосу пропускания. Данная статья относится к vSphere 5.1.
Distributed Switch
NetIOC доступен только в vNetwork Distributed Switch (vDS). Чтобы включить данную функцию в vSphere web client необходимо перейти в раздел Networking, Manage, Settings, кликнуть Edit distributed switch settings и включить Network I/O Control.
После включения во вкладке Resource Allocation станет доступен предустановленный список сетевых ресурсных пулов, лимита хостов, квоты для физических адаптеров и квоты для трафика.
Network Resource Pool
Идея сетевых ресурсных пулов у NetIOC очень похожа на таковую для памяти и ЦПУ. Каждому ресурсному пулу присваиваются квоты для определения относительно приоритета данного трафика по отношению к другому типу трафика, использующему те же физические ресурсы. В случае с NetIOC данные пулы используются для распределения типов сетевого трафика. NetIOC знает 7 предустановленных типов трафика: Management, vMotion, Fault Tolerance, iSCSI, vSphere Storage Area Network Traffic (важно отметить, что классический клиет по ошибке показывает данный пул как пользовательский, но веб клиент правильно опознаёт его как системный. Что еще более важно - этот ресурсный пул использует функции на данный момент не реализованные в vSphere, поэтому реально он не работает, и его можно во внимание не принимать), NFS, vSphere Replication, трафик ВМ.
NetIOC классифицирует входящий трафик, и автоматически привязывает его к соответствующему сетевому пулу, в следствие чего вам нет необходимости вручную привязывать группу портов, использующихся, например, для vMotion к пулу. Как только запускается процесс vMotion трафик будет помечен NIOC, и к нему будут применены соответствующие квоты. В свойствах группы портов будет указан сетевой пул default.
Также возможно создание пользовательских пулов ресурсов, но они применимы только к трафику виртуальных машин. Это отлично подходит для ситуаций, когда несколько организаций используют одно сетевое оборудование.
Квоты физических адаптеров
Квоты NetIOC сходны с традиционными квотами для ЦПУ и памяти, но в данном случае квоты присвоенные сетевому пулу ресурсов определяют общий объём доступной полосы пропускания в случае борьбы за ресурсы. Как и в случае с вычислительными ресурсами, квоты применяются и относительны только к другим активным квотам, использующим тот же ресурс.
В NetIOC доступны три предварительно настроенных и собственные уровни квот. Предустановленные – low, normal, high – предоставляют простой способ указания объёма квот для пула сетевых ресурсов. Приоритет квоты Low – 25, Normal – 50, High – 100. Собственным квотам можно назначить любой приоритет от 1 до 100. По умолчанию все системные квоты имеют приоритет 50, и только квота виртуальных машин имеет приоритет 100.
Ключевой момент данной технологии состоит в том, что ресурсные пули и квоты применяются только к физическому адаптеру. Таким образом случае при перегруженности физического адаптера включаются квоты ресурсных пулов. Например, представим, что у используемого распределённого свитча используется четыре группы портов – Management, vMotion, NFS, виртуальные машины. Все ресурсные пулы используют стандартные квоты и 2 сетевых интерфейса как аплинки. Для простоты представим, что оба аплинка у нас активны.
Так как используются 4 стандартные группы портов, то и пулы ресурсов тоже используются системные. Не используемые ресурсные пулы никак не влияют на распределение ресурсов во время борьбы за ресурсы. Как я уже говорил, квоты применяются только при нехватке ресурсов. В следующем сценарии vmnic0 на хосте ESX02 перегружен, а так как на распределённом свитче используются только четыре группы портов, то доли ресурсных пулов распределяются следующим образом.
Так как 50+50+50+100, то общее значение активных квот 250, и, в данном случае, виртуальные машины получат 40% полосы пропускания, так как (100/(50+50+50+100)). Если vmnic0 является 10Гб интерфейсом, то пул ресурсов виртуальных машин получит 4Гб от всей полосы пропускания интерфейса для всех активно передающих трафик ВМ на данном хосте.
Это был наихудший возможный сценарий, а так как обычно не все группы портов одновременно передают трафик, и учитывая, что квоты применяются относительно к другим ресурсным пулам, активно передающим трафик, может случится так, что активно пересылать трафик через какой-то интерфейс будут только виртуальные машины и операции vMotion. В таком случае применяются квоты только этих двух соответствующих пулов.
В случае активации ещё одного типа трафика, NIOC пересчитывает выделяемую каждому типу трафика полосу пропускания. Например, HA хартбиты отсылаются в менеджмент LAN через vmnic0, в результате чего активными становятся три ресурсных пула - Management, vMotion и трафик виртуальных машин и приведёт к следующему распределению ресурсов:
Лимиты хостов
До выхода vSphere 5.1 NetIOC применял лимиты [b]на уровне хоста[/b]. Это значит, что ограничение полосы пропускания хоста применялось ко всем dvUplinks данного ресурсного пула. Ограничение является абсолютной единицей с измерением в Мб\с. То есть, если вы указали ограничение в 3000Мб\с для ресурсного пула vMotion, то данный тип трафика никогда не превысит данного лимита на каком-либо ESXi хосте, который подключён к данному распределённому свитчу.
В vSphere 5.1 представлены существенные улучшения в данных ограничениях – теперь они применяются к каждому отдельному сетевому интерфейсу. Это значит, что в случае указания для vMotion лимита в 3000Мб\с, то vMotion ограничен данной скоростью по одному интерфейсу. В случае использования Multi-NIC vMotion, например, с 2 интерфейсами, максимальная скорость vMotion может достичь 6000Мб\с.
Необходимо отметить, что данные ограничения работают только для входящего трафика, трафик от ВМ к распределённому свитчу, а это значит, что лимиты применяются только к нативному трафику, исходящему с активной ВМ, работающей на данном хосте, или vMotion трафику, инициированному данным хостом.
Оригинал: http://frankdenneman.nl/2013/01/17/a-primer-on-network-io-control/
Distributed Switch
NetIOC доступен только в vNetwork Distributed Switch (vDS). Чтобы включить данную функцию в vSphere web client необходимо перейти в раздел Networking, Manage, Settings, кликнуть Edit distributed switch settings и включить Network I/O Control.
Network Resource Pool
Идея сетевых ресурсных пулов у NetIOC очень похожа на таковую для памяти и ЦПУ. Каждому ресурсному пулу присваиваются квоты для определения относительно приоритета данного трафика по отношению к другому типу трафика, использующему те же физические ресурсы. В случае с NetIOC данные пулы используются для распределения типов сетевого трафика. NetIOC знает 7 предустановленных типов трафика: Management, vMotion, Fault Tolerance, iSCSI, vSphere Storage Area Network Traffic (важно отметить, что классический клиет по ошибке показывает данный пул как пользовательский, но веб клиент правильно опознаёт его как системный. Что еще более важно - этот ресурсный пул использует функции на данный момент не реализованные в vSphere, поэтому реально он не работает, и его можно во внимание не принимать), NFS, vSphere Replication, трафик ВМ.
NetIOC классифицирует входящий трафик, и автоматически привязывает его к соответствующему сетевому пулу, в следствие чего вам нет необходимости вручную привязывать группу портов, использующихся, например, для vMotion к пулу. Как только запускается процесс vMotion трафик будет помечен NIOC, и к нему будут применены соответствующие квоты. В свойствах группы портов будет указан сетевой пул default.
Также возможно создание пользовательских пулов ресурсов, но они применимы только к трафику виртуальных машин. Это отлично подходит для ситуаций, когда несколько организаций используют одно сетевое оборудование.
Квоты физических адаптеров
Квоты NetIOC сходны с традиционными квотами для ЦПУ и памяти, но в данном случае квоты присвоенные сетевому пулу ресурсов определяют общий объём доступной полосы пропускания в случае борьбы за ресурсы. Как и в случае с вычислительными ресурсами, квоты применяются и относительны только к другим активным квотам, использующим тот же ресурс.
В NetIOC доступны три предварительно настроенных и собственные уровни квот. Предустановленные – low, normal, high – предоставляют простой способ указания объёма квот для пула сетевых ресурсов. Приоритет квоты Low – 25, Normal – 50, High – 100. Собственным квотам можно назначить любой приоритет от 1 до 100. По умолчанию все системные квоты имеют приоритет 50, и только квота виртуальных машин имеет приоритет 100.
Ключевой момент данной технологии состоит в том, что ресурсные пули и квоты применяются только к физическому адаптеру. Таким образом случае при перегруженности физического адаптера включаются квоты ресурсных пулов. Например, представим, что у используемого распределённого свитча используется четыре группы портов – Management, vMotion, NFS, виртуальные машины. Все ресурсные пулы используют стандартные квоты и 2 сетевых интерфейса как аплинки. Для простоты представим, что оба аплинка у нас активны.
Так как используются 4 стандартные группы портов, то и пулы ресурсов тоже используются системные. Не используемые ресурсные пулы никак не влияют на распределение ресурсов во время борьбы за ресурсы. Как я уже говорил, квоты применяются только при нехватке ресурсов. В следующем сценарии vmnic0 на хосте ESX02 перегружен, а так как на распределённом свитче используются только четыре группы портов, то доли ресурсных пулов распределяются следующим образом.
Так как 50+50+50+100, то общее значение активных квот 250, и, в данном случае, виртуальные машины получат 40% полосы пропускания, так как (100/(50+50+50+100)). Если vmnic0 является 10Гб интерфейсом, то пул ресурсов виртуальных машин получит 4Гб от всей полосы пропускания интерфейса для всех активно передающих трафик ВМ на данном хосте.
До выхода vSphere 5.1 NetIOC применял лимиты [b]на уровне хоста[/b]. Это значит, что ограничение полосы пропускания хоста применялось ко всем dvUplinks данного ресурсного пула. Ограничение является абсолютной единицей с измерением в Мб\с. То есть, если вы указали ограничение в 3000Мб\с для ресурсного пула vMotion, то данный тип трафика никогда не превысит данного лимита на каком-либо ESXi хосте, который подключён к данному распределённому свитчу.
В vSphere 5.1 представлены существенные улучшения в данных ограничениях – теперь они применяются к каждому отдельному сетевому интерфейсу. Это значит, что в случае указания для vMotion лимита в 3000Мб\с, то vMotion ограничен данной скоростью по одному интерфейсу. В случае использования Multi-NIC vMotion, например, с 2 интерфейсами, максимальная скорость vMotion может достичь 6000Мб\с.
Необходимо отметить, что данные ограничения работают только для входящего трафика, трафик от ВМ к распределённому свитчу, а это значит, что лимиты применяются только к нативному трафику, исходящему с активной ВМ, работающей на данном хосте, или vMotion трафику, инициированному данным хостом.
Оригинал: http://frankdenneman.nl/2013/01/17/a-primer-on-network-io-control/
Сообщения
Комментариев нет:
Отправить комментарий