По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Мы хотели бы поговорить про Quality of Service (QoS) в VoIP сетях, рассказать что это такое, как это работает, зачем это нужно и как это настраивать. В этой статье мы рассмотрим, какие проблемы мы можем иметь в сети, и как QoS может с ними помочь.
Для успешного функционирования VoIP сетей голосовой трафик (voice traffic) должен иметь приоритет над трафиком с данными (data traffic). Quality of Service можно определить как способность сети предоставить лучший или особый сервис для группы пользователей и приложений за счет других пользователей и приложений.
Звучит как то, что как раз необходимо для голосового трафика – “лучший” сервис необходим для VoIP не из-за больших требований по пропускной способности (VoIP трафик использует маленькую полосу пропускания, по сравнению с другими приложениями), а из-за требований по задержке. В отличие от трафика с данными, время за которое пакет проходит из одного конца сети в другой имеет значение. Если пакет с данными при прохождении через сеть испытал задержку (delay), то файловый сервер получит файл секундой позже или страничка в браузере будет загружаться чуть дольше, и с точки зрения пользователя не произойдет ничего страшного. Однако если голосовой трафик проходит по сети и испытывает задержку, то голоса начинают перекрываться (например, абонент начинает говорить одновременно с другим абонентом) и продолжать разговор становится невозможно.
Чтобы побороть эти проблемы нужно убедиться, что для голосового трафика подходит не только полоса пропускания, но и что голосовой трафик получает первую доступную полосу. Это означает что если бутылочное горлышко (самое узкое место) находится в сети, где маршрутизатор ставит трафик в очередь, то перед тем как его выслать, маршрутизатор будет перемещать голосовой трафик перед трафиком данных, чтобы отправить его в первом доступном интервале. И это как раз задача Quality of Service. QoS, по сути, является не отдельным инструментом, а классом инструментов, направленных на то чтобы дать администратору полный контроль над трафиком внутри сети. Как и когда использовать каждый инструмент QoS зависит от требований к сети от трафика и ее характеристик.
Понимание основных проблем
Перед тем как применять QoS, нужно разораться с тем, какие проблемы мы пытаемся решить. Рассмотрим основные:
Недостаток пропускной способности (Lack of bandwidth) – Множественные потоки голосового трафика и трафика с данными конкурируют за ограниченную полосу пропускания.
Задержка (Delay) – Для того чтобы пакет дошел из пункта отправления в пункт назначения требуется какое-то время. Задержка имеет три формы:
Фиксированная задержка (Fixed delay) – Значение задержки, которое нельзя изменить. Например, требуется определенное время, чтобы пакет добрался до определенной географической локации. Это значение считается фиксированным и QoS не может повлиять на него.
Переменная задержка(Variable delay) – Значения задержки, которые можно изменить. Например, задержка в очереди интерфейса маршрутизатора является переменной, потому что она зависит от того, сколько пакетов находится на данный момент в очереди. На эту задержку можно повлиять поставив голосовые пакеты перед пакетами с данными.
Джиттер (Jitter) – Разница задержек между пакетами. Например, первому пакету разговора потребовалось 100 мс чтобы добраться до точки назначения, в то время как второму потребовалось 110 мс. В этой ситуации джиттер составляет 10 мс.
Потеря пакетов (Packet loss) – пакеты теряются из-за переполненного или ненадежного сетевого подключения.
Очень важно понимать эти проблемы, поскольку они вызывают наложения звука, эхо, потрескивания и разорванные звонки.
Механизм QoS предназначен для того, чтобы обеспечить бесперебойную передачу голоса в течение временных перегрузок в сети. Однако это не волшебная палочка, которая сможет решить все проблемы в сети. Например, если в сети есть недостаток пропускной способности, то при добавлении голосовых пакетов не стоит ожидать что QoS сможет все решить – получится что либо приложения с данными будут работать так медленно, что перестанут быть функциональными, либо голосовой трафик будет испытывать проблемы с качеством.
Цель QoS – обеспечить постоянную пропускную способность для голосового трафика таким образом, чтобы была низкая постоянная задержка с одного конца сети в другой. Чтобы выполнить это требование необходимо иметь настроенные механизмы QoS в каждой точке сети, где существует перегрузка.
Требования к голосовому и видео трафику
Разный тип трафика, который используется в сети, имеет разные требования QoS. В отличие от трафика данных, голосовой трафик считается предсказуемым. В то время как трафик данных может значительно увеличиваться при скачивании или передачи большого объема данных, голосовой трафик остается постоянным для каждого звонка поступающего и покидающего сеть. Фактический объем полосы пропускания, требуемый для голоса сильно зависит от используемого кодека.
Помимо требований к пропускной способности, голосовой трафик имеет следующие дополнительные требования:
Задержка (End-to-end delay) : 150 мс или меньше
Джиттер: 30 мс или меньше
Потеря пакетов: 1% или меньше
Видео трафик имеет такие же требования по задержке, но потребляет большую полосу пропускания. Кроме того ширина полосы пропускания может меняться в зависимости от того, сколько движения происходит в видео (большее количество движений значительно увеличивают необходимую пропускную способность).
Требования к трафику данных
Невозможно подогнать весь трафик данных под одно требование, потому что каждое отдельное приложение имеет свои QoS требования. Приложения данных можно разделить на несколько категорий:
Критически важные приложения (Mission-critical applications) – эти приложения критически важны для организации и требуют выделенной полосы пропускания.
Транзакционные приложения (Transactional applications) – эти приложения обычно взаимодействуют с пользователями и требуют быстрого времени отклика. Например, сотрудник техподдержки может использовать приложение базы данных чтобы получать информацию о абоненте на основе ID предыдущих запросов.
Низкоприоритетные приложения (Best-effort applications) – эти приложения некритичны или некатегоризированы. Это может быть почта, веб и FTP.
“Мусорные ” приложения (Scavenger applications) – это непродуктивные приложения, в которых нет необходимости для работы, но которые поглощают значительные объемы полосы пропускания. Например, это могут быть p2p приложения типа BitTorrent
Каждой из этих категорий приложений можно назначить определенный уровень QoS.
Друг, на днях к нам в офис подъехал E1 - шлюз от китайского вендора Dinstar модели MTG200-1-E1. Взяв в руки коробку мы устремились в лабораторию – скрещивать шлюз с E1 потоком со стороны ТфОП и с IP – АТС Asterisk другой.
Коротко про шлюз
Произведем небольшой «анбоксинг» шлюза. Изделие поставляется в коробке и защищено специальной пленкой:
В комплект поставки входит:
Ethernet – кабель;
Провод для подключения E1 потока;
Консольный кабель;
Сам шлюз;
На фронтальной панели MTG200 расположились:
Индикатор питания;
Индикатор «алярмов»;
Физический разъем, предназначенный для сброса настроек устройства к заводским;
Консольный порт;
Индикация E1/T1 и Fast Ethernet интерфейсов;
Разворачиваем шлюз на 180 градусов и видим:
Разъем для подключения питания;
Физические интерфейсы для E1/T1;
Физический интерфейсы для Fast Ethernet;
Вот такой шлюз ожидает своего владельца :) Мы переходим к настройке связки с IP – АТС Asterisk с помощью FreePBX.
Связка со стороны Asterisk
Настройки мы будем выполнять с помощью графического интерфейса FreePBX 14 версии. Подключившись, переходим в раздел Connectivity → Trunks и добавляем новый транк для MTG200 (chan_sip). Дайте удобное для вас имя транка в поле Trunk Name. В разделе Outgoing (исходящие параметры) заполняем:
host=IP_адрес_Dinstar
type=friend
fromuser=логин
username=логин
secret=пароль
qualify=yes
port=5060
context=from-pstn
Переключаемся на вкладку Incoming (входящие параметры) и указываем следующие реквизиты:
disallow=all
allow=alaw&ulaw
canreinvite=no
context=from-pstn
dtmfmode=rfc2833
username=логин
secret=пароль
qualify=yes
insecure=invite
host=dynamic
type=friend
Отлично. Теперь давайте проверим статус этих пиров:
Мы немного забежали вперед, и, как видите, статус нашего входящего пира так же отмечен как OK. Это возможно, только после создания «плеча» в сторону Asterisk на шлюзе. Мы наглядно покажем этот процесс далее.
После, создайте входящий/исходящий маршрут для направления вызовов в нужном направлении или формате. Как это сделать, можно прочитать в этой статье.
Связка со стороны провайдера
Приступаем к настройке шлюза. Провайдер прислал нам следующие параметры:
Каждая настройка сильно зависит от параметров вашего провайдера. Свяжитесь с ним, перед настройкой
CRC выключен
D-канал User
А-номер от Вашей АТС должен приходить 10 знаков с типом National (49Xxxxxxxx)
План нумерации А-номера должен быть ISDN/Telephony
С ними мы и будем работать. По умолчанию, шлюз почти готов к работе – поменяем некоторые параметры. Переходим в раздел PRI Config → PRI Trunk и добавляем новый транк со следующими настройками:
Скорректируем SIP параметры: переходим в SIP Config → SIP Parameter:
Скорректируем SIP параметры: переходим в SIP Config → SIP Trunk. Указываем IP – адрес и порт со стороны Asterisk:
Настроим общие E1/T1 параметры: PSTN Group Config → E1/T1 Parameter :
Готово. Делаем телефонный звонок и проверяем, как занимаются тайм – слоты на нашем шлюзе: Status & Statistics → E1/T1 Status :
Мы сделали входящий звонок – как видите, зеленым цветом, отображается занятый тайм – слот, а сам звонок, улетает по SIP в сторону Asterisk.
Несмотря на доступ к все более эффективному и мощному оборудованию, операции, выполняемые непосредственно на традиционных физических (или «чистых») серверах, неизбежно сталкиваются со значительными практическими ограничениями. Стоимость и сложность создания и запуска одного физического сервера говорят о том, что эффективное добавление и удаление ресурсов для быстрого удовлетворения меняющихся потребностей затруднено, а в некоторых случаях просто невозможно. Безопасное тестирование новых конфигураций или полных приложений перед их выпуском также может быть сложным, дорогостоящим и длительным процессом.
Исследователи-первопроходцы Джеральд Дж. Попек и Роберт П. Голдберг в статье 1974 года («Формальные требования к виртуализируемым архитектурам третьего поколения» (“Formal Requirements for Virtualizable Third Generation Architectures”) - Communications of the ACM 17 (7): 412–421) предполагали, что успешная виртуализация должна обеспечивать такую среду, которая:
Эквивалента физическому компьютеру, поэтому доступ программного обеспечения к аппаратным ресурсам и драйверам должен быть неотличим от невиртуализированного варианта.
Обеспечивает полный контроль клиента над аппаратным обеспечением виртуализированной системы.
По возможности эффективно выполняет операции непосредственно на базовых аппаратных ресурсах, включая ЦП.
Виртуализация позволяет разделить физические ресурсы вычислений, памяти, сети и хранилища («основополагающая четверка») между несколькими объектами. Каждое виртуальное устройство представлено в своем программном обеспечении и пользовательской среде как реальный автономный объект. Грамотно настроенные виртуальные изолированные ресурсы могут обеспечить более защиту приложений приложений без видимой связи между средами. Виртуализация также позволяет создавать и запускать новые виртуальные машины почти мгновенно, а затем удалять их, когда они перестанут быть необходимыми.
Для больших приложений, поддерживающих постоянно меняющиеся бизнес-требования, возможность быстрого вертикального масштабирования с повышением или понижением производительности может означать разницу между успехом и неудачей. Адаптивность, которую предлагает виртуализация, позволяет скриптам добавлять или удалять виртуальные машины за считанные секунды, а не недели, которые могут потребоваться для покупки, подготовки и развертывания физического сервера.
Как работает виртуализация?
В невиртуальных условиях, архитектуры х86 строго контролируют, какие процессы могут работать в каждом из четырех тщательно определенных уровней привилегий (начиная с Кольца 0 (Ring 0) по Кольцо 3).
Как правило, только ядро операционной системы хоста имеет какой-либо шанс получить доступ к инструкциям, хранящимся в кольце под номером 0. Однако, поскольку вы не можете предоставить нескольким виртуальным машинам, которые работают на одном физическом компьютере, равный доступ к кольцу 0, не вызывая больших проблем, необходим диспетчер виртуальных машин (или «гипервизор»), который бы эффективно перенаправлял запросы на такие ресурсы, как память и хранилище, на виртуализированные системы, эквивалентные им.
При работе в аппаратной среде без виртуализации SVM или VT-x все это выполняется с помощью процесса, известного как ловушка, эмуляция и двоичная трансляция. На виртуализированном оборудовании такие запросы, как правило, перехватываются гипервизором, адаптируются к виртуальной среде и возвращаются в виртуальную машину.
Простое добавление нового программного уровня для обеспечения такого уровня организации взаимодействия приведет к значительной задержке практически во всех аспектах производительности системы. Одним из успешных решений было решение ввести новый набор инструкций в ЦП, которые создают, так называемое, «кольцо 1», которое действует как кольцо 0 и позволяет гостевой ОС работать без какого-либо влияния на другие несвязанные операции.
На самом деле, при правильной реализации виртуализация позволяет большинству программных кодов работать как обычно, без каких-либо перехватов.
Несмотря на то, что эмуляция часто играет роль поддержки при развертывании виртуализации, она все же работает несколько иначе. В то время как виртуализация стремится разделить существующие аппаратные ресурсы между несколькими пользователями, эмуляция ставит перед собой цель заставить одну конкретную аппаратную/программную среду имитировать ту, которой на самом деле не существует, чтобы у пользователей была возможность запускать процессы, которые изначально было невозможно запустить. Для этого требуется программный код, который имитирует желаемую исходную аппаратную среду, чтобы обмануть ваше программное обеспечение, заставив его думать, что оно на самом деле работает где-то еще.
Эмуляция может быть относительно простой в реализации, но она почти всегда несет за собой значительные потери производительности.
Согласно сложившимся представлениям, существует два класса гипервизоров: Type-1 и Type-2.
Bare-metal гипервизоры (исполняемые на «голом железе») (Type-1), загружаются как операционная система машины и – иногда через основную привилегированную виртуальную машину – сохраняют полный контроль над аппаратным обеспечением хоста, запуская каждую гостевую ОС как системный процесс. XenServer и VMWare ESXi – яркие примеры современных гипервизоров Type-1. В последнее время использование термина «гипервизор» распространилось на все технологии виртуализации хостов, хотя раньше оно использовалось только для описания систем Type-1. Первоначально более общим термином, охватывающим все типы систем, был «Мониторы виртуальных машин». То, в какой степени люди используют термин «мониторы виртуальных машин» все это время, наводит меня на мысль, что они подразумевают «гипервизор» во всех его интерпретациях.
Гипервизоры, размещенные на виртуальном узле (Type-2) сами по себе являются просто процессами, работающими поверх обычного стека операционной системы. Гипервизоры Type-2 (включая VirtualBox и, в некотором роде, KVM) отделяют системные ресурсы хоста для гостевых операционных систем, создавая иллюзию частной аппаратной среды.
Виртуализация: паравиртуализация или аппаратная виртуализация
Виртуальные машины полностью виртуализированы. Иными словами, они думают, что они обычные развертывания операционной системы, которые живут собственной счастливой жизнью на собственном оборудовании. Поскольку им не нужно взаимодействовать со своей средой как-то иначе, чем с автономной ОС, то они могут работать с готовыми немодифицированными программными стеками. Однако раньше за такое сходство приходилось платить, потому что преобразование аппаратных сигналов через уровень эмуляции занимало дополнительное время и циклы.
В случае с паравиртуализацией (PV – Paravirtualization) паравиртуальные гости хотя бы частично осведомлены о своей виртуальной среде, в том числе и том, что они используют аппаратные ресурсы совместно с другими виртуальными машинами. Эта осведомленность означает, что хостам PV не нужно эмулировать хранилище и сетевое оборудование, и делает доступными эффективные драйверы ввода-вывода. На первых порах это позволяло гипервизорам PV достигать более высокой производительности для операций, требующих подключения к аппаратным компонентам.
Тем не менее, для того, чтобы предоставить гостевой доступ к виртуальному кольцу 0 (т.е. кольцу -1), современные аппаратные платформы – и, в частности, архитектура Intel Ivy Bridge – представили новую библиотеку наборов инструкций ЦП, которая позволила аппаратной виртуализации (HVM – Hardware Virtual Machine) обойти узкое место, связанное с ловушкой и эмуляцией, и в полной мере воспользоваться преимуществами аппаратных расширений и немодифицированных операций ядра программного обеспечения.
Также значительно повысить производительность виртуализации может последняя технология Intel – таблицы расширенных страниц (EPT – Extended Page Tables).
В связи с этим, в большинстве случаев можно обнаружить, что HVM обеспечивает более высокую производительность, переносимость и совместимость.
Аппаратная совместимость
Как минимум, несколько функций виртуализации требуют аппаратную поддержку, особенно со стороны ЦП хоста. Именно поэтому вы должны убедиться, что на вашем сервере есть все, что вам необходимо для задачи, которую вы собираетесь ему дать. Большая часть того, что вам нужно знать, храниться в файле /proc/cpuinfo и, в частности, в разделе «flags» (флаги) каждого процессора. Однако вам нужно знать, то искать, потому что флагов будет очень много.
Запустите эту команду, чтобы посмотреть, что у вас под капотом:
$ grep flags /proc/cpuinfo
Контейнерная виртуализация
Как мы уже видели ранее, виртуальная машина гипервизора – это полноценная операционная система, чья связь с аппаратными ресурсами «основополагающей четверки» полностью виртуализирована – она думает, что работает на собственном компьютере.
Гипервизор устанавливает виртуальную машину из того же ISO-образа, который вы загружаете и используете для установки операционной системы непосредственно на пустой физический жесткий диск.
Контейнер в свою очередь фактически представляет собой приложение, запускаемое из скриптообразного шаблона, которое считает себя операционной системой. В контейнерных технологиях, таких как LXC и Docker, контейнеры – это не что иное, как программные и ресурсные (файлы, процессы, пользователи) средства, которые зависят от ядра хоста и представления аппаратных ресурсов «основополагающей четверки» (т.е. ЦП, ОЗУ, сеть и хранилище) для всего, то они делают.
Конечно, с учетом того, что контейнеры фактически являются изолированными расширениями ядра хоста, виртуализация Windows (или более старых или новых версий Linux с несовместимыми версиями libc), например, на хосте Ubuntu 16.04 будет сложна или невозможна. Но эта технология обеспечивает невероятно простые и универсальные вычислительные возможности.
Перемещение
Модель виртуализации также позволяет использовать широкий спектр операций перемещения, копирования и клонирования даже из действующих систем (V2V). Поскольку программные ресурсы, определяющие виртуальную машину и управляющие ею, очень легко идентифицировать, то обычно не требуется очень много усилий для дублирования целых серверных сред в нескольких местах и для разных целей.
Иногда это не сложнее, чем создать архив виртуальной файловой системы на одном хосте, распаковать его на другом хосте по тому же пути, проверить основные сетевые настройки и запустить. Большинство платформ предлагают единую операцию командной строки для перемещения гостей между хостами.
Перемещение развертываний с физических серверов на виртуализированные среды (P2V) иногда может оказаться немного сложнее. Даже создание клонированного образа простого физического сервера и его импорт в пустую виртуальную машину может сопровождаться определенными трудностями. И как только все это будет выполнено, вам, возможно, придется внести некоторые корректировки в системную архитектуру, чтобы можно было использовать возможности, предлагаемые виртуализацией, в полную силу. В зависимости от операционной системы, которую вы перемещаете, вам также может потребоваться использование паравиртуализированных драйверов для того, чтобы ОС могла корректно работать в своем «новом доме».
Как и в любых других ситуациях управления сервером: тщательно все продумывайте заранее.