Настройка QoS на VMWare и Cisco USC

    Есть у нас Asterisk на виртуальной машине под vmware, которая в свою очередь крутится на блейде Cisco UCS. И встала задача приоритезации голосового трафика внутри vmware и внутри Cisco UCS.

    1. Cisco UCS


    Начнём настройку с Cisco UCS. Cisco UCS поддерживает QoS только на втором уровне. Соответственно красить трафик под неё надо CoS битами.
    Настройка QoS в UCS Manager находится на вкладке LAN, пункт LAN Cloud -> QoS System Class

    Здесь необходимо включить маркировки, которые мы собираемся использовать, и по желанию изменить их настройки. Для Gold трафика необходимо поставить CoS 3, а для FC — 4. Подробнее можно почитать здесь.

    По умолчанию, UCS не пропускает маркировку со стороны хостов. Чтобы UCS начал доверять маркировке, необходимо создать QoS Policy в разделе Polices -> root -> QoS Polises.
    В политике мы задаём, как маркировать трафик, так же, при желании, можем зарезать полосу. Важный для нас параметр здесь — это Host Control, если он стоит в значении None, то весь трафик с интерфейса будет маркироваться заданным CoS, в случае значения Full — UCS будет доверять маркировке на интерфейсе, и будет маркировать только не маркированный трафик.
    Ставим в нашей политике Priority: Best Effort (CoS 0) и Host Control: Full, таким образом мы будем доверять маркировке с хостов, а для не маркированных кадров так и оставим CoS 0.

    Дальше необходимо применить данную QoS Policy к интерфейсам (или политикам интерфейсов) в сторону хостов. Данная операция потребует перезагрузки хостов.

    На этом настройка Cisco UCS закончена.

    2. Настройка VMWare


    Теперь настроим vmware. Я буду рассматривать случай со стандартным Distributed Virtual Switch и vSphere 6.0.
    Первое что необходимо сделать, это создать выделенную Port Group для нашего хоста с Asterisk.
    Дальше идём в настройки порт группы (обязательно через Web Client) в раздел Traffic filtering and marking и добавляем новое правило, назовём его RTP. Указываем Action: Tag, CoS Value: 5, Traffic direction: Ingress.

    Далее добавляем правило New IP Qualifier. Protocol: UDP, Source port: range 10000-20000 (сморите настройки rtp портов своего астериска), Source address — адрес вашего астериска. Аналогичное правило делаем для sip трафика, выбрав CoS 3 и Source port: 5060.



    Всё, наш трафик от астериска промаркирован. Теперь дадим астериску ещё и гарантированную полосу на аплинках виртуального свитча.
    Выбираем в веб клиенте наш DVS и идём на вкладку Resource Allocation и выбираем System Traffic.
    Вначале нам необходимо зарезервировать полосу для трафика типа Virtual Machine Type, делаем её в 75% от ширины физического интерфейса, в данному случае это 15000Mbit/s.

    Теперь можно задать полосу для отдельной порт группы. Переходим в Network resource pools и создаём новый пул, назовём его Voice, и зададим ему гарантированную полосу, к примеру, в 20Mbit/s

    Возвращаемся в настройки порт группы и в разделе General применяем созданный Network resource pool к порт группе.

    Всё, на этом настройка закончена. Теперь голосовой трафик будет иметь приоритет внутри виртуального свитча и внутри Cisco UCS.
    Поделиться публикацией

    Похожие публикации

    Комментарии 5

      0
      Далее добавляем правило New IP Qualifier. Protocol: UDP, Source port: range 10000-20000 (сморите настройки rtp портов своего астериска),

      Сюда может попасть любой UDP трафик от астериска, не только RTP. Понятно, что вряд ли астериск будет пулять что-то другое тяжелое помимо голоса, но все-таки… Лучше уж одновременно source и destination диапазоны указывать. Или просто брать из TOS, если можно.

      А с какой целью выставили CoS? Там есть дефолтные механизмы приоритезации в зависимости от него? И почему бы сходу с DSCP не работать?
      делаем её в 75% от ширины физического интерфейса, в данному случае это 15000Mbit/s.

      А не дофига для голоса — 15гб/с? Я правильно помню, что в терминах VMWare reservation — это именно «отложить ресурс в сторону» (фактически полисинг всего остального), а не «если все толкаются — этому гарантировать Х ресурса»?
        0
        1. Матчить в DVS можно только по ip адресам и портам, соответственно по TOS или dscp не получится (dscp астериск сам проставляет верные)
        2. CoS выставил, т.к. в UCS Interconnect есть приоритезация, и только на L2, соответственно DSCP не канает.
        3. 15гб/c — это полоса для всего трафика всех виртуальных машин, для голоса потом из этой полосы выделяется 20мбит/с
          0
          1. Тогда чтобы получить наиболее универсальный вариант, в который не будет попадать половина исходящих UDP соединений любого рода — лучше source и destination порты указывать…
          2. Действительно. «UCS Fabric Interconnect (FI) cannot map L3 DSCP values to L2 CoS values». Жуть какая.
          3. 20гб/с похоже на агрегацию. Что случится, если один из двух линков отвалится в момент, когда астериск пытается говорить на 7гб/с, а сама VMWare — на 4гб/с? Или если оба линка живы, но волей жуткого стечения обстоятельств всё схешировалось в один из них?
            0
            20гб/с — это скорость интерфейса, сетевая карта vic 1340 подключена к каждому интерконнекту по 20гб/с. Тут вопрос в дугом, на каждый хост у меня отдано по 4 «виртуальных» интерфейса, и DVS считает суммарную пропускную способность в 80гб/с на хост, а реально там только 20гб/с на хост, и что будет когда траффик превысит эти 20 не понятно, ведь приоритетных очередей в vmware нет…
              0
              Этот документ внёс больше ясности. Полоса резервируется на физическом адаптере, через который работает виртуалка. И Приоритеты там тоже оказывается есть. Так что теперь вроде всё стало ясно.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое