По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Продолжаем рассказывать про механизмы QoS (Quality of Service) . Мы уже рассказаывали про то, какие проблемы могут быть в сети и как на них может повлиять QoS. В этой статье мы поговорим про механизмы работы QoS. Механизмы QoS В связи с тем, что приложения могут требовать различные уровни QoS, возникает множество моделей и механизмов, чтобы удовлетворить эти нужды. Рассмотрим следующие модели: Best Effort –негарантированная доставка используется во всех сетях по умолчанию. Положительная сторона заключается в том, что эта модель не требует абсолютно никаких усилий для реализации. Не используются никакие механизмы QoS, весь трафик обслуживается по принципу “пришел первым – обслужили первым”. Такая модель не подходит для современных сетевых сред; Integrated Services (IntServ) – эта модель интегрированного обслуживания использует метод резервирования. Например, если пользователь хотел сделать VoIP вызов 80 Кбит/с по сети передачи данных, то сеть, разработанная исключительно для модели IntServ, зарезервировала бы 80 Кбит/с на каждом сетевом устройстве между двумя конечными точками VoIP, используя протокол резервирования ресурсов RSVP (Resource Reservation Protocol) . На протяжении звонка эти 80 Кбит/с будут недоступны для другого использования, кроме как для VoIP звонка. Хотя модель IntServ является единственной моделью, обеспечивающей гарантированную пропускную способность, она также имеет проблемы с масштабируемостью. Если сделано достаточное количество резервирований, то сеть просто исчерпает полосу пропускания; Differentiated Services (DiffServ) – модель дифференцированного обслуживания является самой популярной и гибкой моделью для использования QoS. В этой модели можно настроить каждое устройство так, чтобы оно могло использовать различные методы QoS, в зависимости от типа трафика. Можно указать какой трафик входит в определенный класс и как этот класс должен обрабатываться. В отличие от модели IntServ, трафик не является абсолютно гарантированным, поскольку сетевые устройства не полностью резервируют полосу пропускания. Однако DiffServ получает полосу, близкую к гарантированной полосе пропускания, в то же время решая проблемы масштабируемости IntServ. Это позволило этой модели стать стандартной моделью QoS; Инструменты QoS Сами механизмы QoS представляют собой ряд инструментов, которые объединяются для обеспечения уровня обслуживания, который необходим трафику. Каждый из этих инструментов вписывается в одну из следующих категорий: Классификация и разметка (Classification and Marking) - Эти инструменты позволяют идентифицировать и маркировать пакет, чтобы сетевые устройства могли легко идентифицировать его по мере пересечения сети. Обычно первое устройство, которое принимает пакет, идентифицирует его с помощью таких инструментов, как списки доступа (access-list), входящие интерфейсы или deep packet inspection (DPI), который рассматривает сами данные приложения. Эти инструменты могут быть требовательны к ресурсам процессора и добавлять задержку в пакет, поэтому после того как пакет изначально идентифицирован, он сразу помечается. Маркировка может быть в заголовке уровня 2 (data link), позволяя коммутаторам читать его и/или заголовке уровня 3 (network), чтобы маршрутизаторы могли его прочитать. Для второго уровня используется протокол 802.1P, а для третьего уровня используется поле Type of Service. Затем, когда пакет пересекает остальную сеть, сетевые устройства просто смотрят на маркировку, чтобы классифицировать ее, а не искать глубоко в пакете; Управление перегрузками (Congestion Management)– Перегрузки возникают, когда входной буфер устройства переполняется и из-за этого увеличивается время обработки пакета. Стратегии очередей определяют правила, которые маршрутизатор должен применять при возникновении перегрузки. Например, если интерфейс E1 WAN был полностью насыщен трафиком, маршрутизатор начнет удерживать пакеты в памяти (очереди), чтобы отправить их, когда станет доступна полоса пропускания. Все стратегии очередей направлены на то, чтобы ответить на один вопрос: “когда есть доступная пропускная способность, какой пакет идет первым?“; Избегание заторов (Congestion Avoidance) – Большинство QoS механизмов применяются только тогда, когда в сети происходит перегрузка. Целью инструментов избегания заторов является удаление достаточного количества пакетов несущественного (или не очень важного) трафика, чтобы избежать серьезных перегрузок, возникающих в первую очередь; Контроль и шейпинг (Policing and Shaping) – Этот механизм ограничивает пропускную способность определенного сетевого трафика. Это полезно для многих типичных «пожирателей полосы» в сети: p2p приложения, веб-серфинг, FTP и прочие. Шейпинг также можно использовать, чтобы ограничить пропускную способность определенного сетевого трафика. Это нужно для сетей, где допустимая фактическая скорость медленнее физической скорости интерфейса. Разница между этими двумя механизмами заключается в том, что shaping формирует очередь из избыточного трафика, чтобы выслать его позже, тогда как policing обычно сбрасывает избыточный трафик; Эффективность линков (Link Efficiency) – Эта группа инструментов сосредоточена на доставке трафика наиболее эффективным способом. Например, некоторые низкоскоростные линки могут работать лучше, если потратить время на сжатие сетевого трафика до его отправки (сжатие является одним из инструментов Link Efficiency); Механизмы Link Efficiency При использовании медленных интерфейсов возникают две основных проблемы: Недостаток полосы пропускания затрудняет своевременную отправку необходимого объема данных; Медленные скорости могут существенно повлиять на сквозную задержку из-за процесса сериализации (количество времени, которое маршрутизатору требуется на перенос пакета из буфера памяти в сеть). На этих медленных линках, чем больше пакет, тем дольше задержка сериализации; Чтобы побороть эти проблемы были разработаны следующие Link Efficiency механизмы: Сжатие полезной нагрузки (Payload Compression) – сжимает данные приложения, оправляемые по сети, поэтому маршрутизатор отправляет меньше данных, по медленной линии; Сжатие заголовка (Header Compression) – Некоторый трафик (например, такой как VoIP) может иметь небольшой объем данных приложения (RTP-аудио) в каждом пакете, но в целом отправлять много пакетов. В этом случае количество информации заголовка становится значимым фактором и часто потребляет больше полосы пропускания, чем данные. Сжатие заголовка решает эту проблему напрямую, устраняя многие избыточные поля в заголовке пакета. Удивительно, что сжатие заголовка RTP, также называемое сжатым транспортным протоколом реального времени (Compressed Real-time Transport Protocol - cRTP) уменьшает 40-байтовый заголовок до 2-4 байт!; Фрагментация и чередование (Link Fragmentation and Interleaving) - LFI решает проблему задержки сериализации путем измельчения больших пакетов на более мелкие части до их отправки. Это позволяет маршрутизатору перемещать критический VoIP-трафик между фрагментированными частями данных (которые называются «чередованием» голоса); Алгоритмы очередей Постановка в очереди (queuing) определяет правила, которые маршрутизатор должен применять при возникновении перегруженности. Большинство сетевых интерфейсов по умолчанию используют базовую инициализацию First-in, First-out (FIFO) . В этом методе сначала отправляется любой пакет, который приходит первым. Хотя это кажется справедливым, не весь сетевой трафик создается равным. Основная задача очереди - обеспечить, чтобы сетевой трафик, обслуживающий критически важные или зависящие от времени бизнес-приложения, отправлялся перед несущественным сетевым трафиком. Помимо очередности FIFO используются три первичных алгоритма очередности: Weighted Fair Queuing (WFQ)– WFQ пытается сбалансировать доступную полосу пропускания между всеми отправителями равномерно. Используя этот метод, отправитель с высокой пропускной способностью получает меньше приоритета, чем отправитель с низкой пропускной способностью; Class-Based Weighted Fair Queuing (CBWFQ) – этот метод массового обслуживания позволяет указать гарантированные уровни пропускной способности для различных классов трафика. Например, вы можете указать, что веб-трафик получает 20 процентов полосы пропускания, тогда как трафик Citrix получает 50 процентов пропускной способности (вы можете указать значения как процент или конкретную величину полосы пропускания). Затем WFQ используется для всего неуказанного трафика (остальные 30 процентов в примере); Low Latency Queuing (LLQ) - LLQ часто упоминается как PQ-CBWFQ, потому работает точно так же, как CBWFQ, но добавляется компонент приоритета очередей (Priority Queuing - PQ). Если вы указываете, что определенный сетевой трафик должен идти в приоритетную очередь, то маршрутизатор не только обеспечивает пропускную способность трафика, но и гарантирует ему первую полосу пропускания. Например, используя чистый CBWFQ, трафику Citrix может быть гарантированно 50% пропускной способности, но он может получить эту полосу пропускания после того, как маршрутизатор обеспечит некоторые другие гарантии трафика. При использовании LLQ приоритетный трафик всегда отправляется перед выполнением любых других гарантий. Это очень хорошо работает для VoIP, делая LLQ предпочтительным алгоритмом очередей для голоса; Существует много других алгоритмов для очередей, эти три охватывают методы, используемые большинством современных сетей
img
Ваш клиент хочет перестроить свою систему IP-телефона или, возможно, впервые перейти на нее. Вы придете к нему с проприетарной системой, например, CUCM, или открытой стандартной системой, например, Asterisk? Прежде чем сделать выбор, важно не упускать сразу ни один из вариантов. Понимание всех входов и выходов каждого типа системы, а также конкретных требований вашего клиента имеет важное значение. Давайте рассмотрим некоторые сильные и слабые стороны каждого подхода. Положительные и отрицательные стороны открытых АТС АТС с открытым стандартом являются решениями с открытым стеком, использующими стандартный подход - например, SIP - для передачи мультимедийных сообщений. Широко распространенные и признанные благодаря своей универсальности в использовании и гибкости, системы АТС с открытым стандартом не имеют многих недостатков для многих предприятий сегодня. Наряду с необходимыми функциями телефонии, некоторые передовые решения, также предлагают высококачественные унифицированные коммуникации из коробки. В целом системы АТС с открытым стандартом обеспечивают: Лучшее соотношение цены и качества: Опенсорс АТС часто ассоциируется с существенной экономией, потому что ею легко управлять, и в большинстве случаев нужно беспокоиться о небольших лицензионных сборах. По сравнению с запатентованными решениями, которые заключают вас в долгосрочные контракты на обслуживание или дорогостоящий ремонт системы, решения с открытыми стандартами могут быть более рентабельными во многих бизнес-сценариях. Устранить риск блокировки поставщика: Истинная ценность таких АТС заключается в возможности сочетать набор стандартных компонентов для предоставления инновационных услуг. С системой можно использовать практически любой SIP-телефон, шлюз или периферийные устройства на основе стандарта, что способствует удовлетворенности пользователей и производительности бизнеса. Проще установить и настроить: Если вы используете проприетаруню телефонную систему, вы, вероятно, уже знаете о трудностях, возникающих при ее установке, использовании и обслуживании. Вместо этого системы АТС открытого стандарта просты в использовании и управлении. Это может быть особенно актуально для тех, кто использует Asterisk с интуитивно понятным интерфейсом. Совместимость и настройка: Кастомизация очень важна для телефонных систем. И на этом этапе выигрывают АТС открытого стандарта. Относительно легко интегрироваться с другими стандартными приложениями, такими как базы данных, CRM, PMS отеля, колл-центр и другие, чтобы удовлетворить специфические потребности клиентов. Хотя АТС с открытым стандартом, по большому счету, не имеют многих недостатков, качество всей системы сильно зависит от поставщиков и интеграторов. Некоторые, выбравшие бесплатные открытые решения утверждают, что им не хватает нужных функций, профессиональной поддержки и частых обновлений. Положительные и отрицательные стороны проприетарной АТС Проприетарной АТС являются «закрытой» системой, разработанной специально производителями, в комплекте с собственным брендом. Большинство проприетарных решений, таких как NEC или Panasonic, считаются относительно надежными, но менее привлекательными с финансовой точки зрения. С проприетарной системой вы получаете практически все ваше оборудование и программное обеспечение от одного поставщика, который будет поддерживать и гарантировать все, от АТС до мобильных телефонов. Таким образом, некоторые из преимуществ включают в себя: Единый пользовательский опыт: В большинстве случаев проприетарные системы предлагают единый пользовательский интерфейс. Вся система VoIP остается согласованной для всех совместимых аппаратных и программных приложений. Таким образом, вы можете ожидать аналогичного и знакомого взаимодействия с каждым устройством. Поддержка производителя: Благодаря проприетарной системе ваш поставщик имеет единоличный контроль над обновлениями, обновлениями и модификациями. Как следствие, вы, как торговый посредник или дистрибьютор, могли бы иметь больший контроль над клиентами, но вам нужно будет вкладывать больше ресурсов в освоение сложных запатентованных систем и интерфейсов для лучшей поддержки клиентов. Наряду с преимуществами проприетарного решения, есть некоторые недостатки, которыми нельзя пренебрегать. Самые большие из них могут быть связаны с затратами, риском блокировки поставщиков и ограниченной гибкостью. Многие запатентованные продукты могут функционировать должным образом только при использовании с другими продуктами того же производителя. Другими словами, вы, скорее всего, будете заложниками проприетарных мобильных телефонов и периферийных устройств, которые могут быть переоценены с ограниченной функциональностью, что приведет к негативным последствиям в процессе продаж. Еще одна важная вещь, которую следует помнить, это то, что с проприетарной системой АТС вы не сможете достичь того же уровня гибкости, что и решения с открытыми стандартами. Поскольку проприетарные решения обычно не допускают обходных путей для разработчиков, специфичных для данной проблемы, скорее всего, вы не сможете реализовать наименьшие изменения, необходимые для лучшей адаптации решения к потребностям вашего бизнеса. И когда возникают сложные проблемы, ваш поставщик является вашей единственной резервной копией. Предвидение: бизнес-экосистема и возможности В условиях постоянно расширяющегося горизонта и достижений на рынке VoIP ключом к тому, чтобы телефонная система оставалась впереди, было стремление идти в ногу с рыночными тенденциями и предлагать жизнеспособные решения, чтобы вписаться в более широкий спектр потребностей клиентов. И нельзя отрицать, что решения открытых стандартов имеют конкурентные преимущества. Роль собственности как первичного новатора на рынке ушла на второй план. Распространенность промышленных открытых стандартов, таких как SIP и телефония с открытым исходным кодом, таких как Asterisk, произвела революцию в экосистеме и принесла больше возможностей для бизнеса. Используя коллективные усилия огромного мирового сообщества экспертов, новые непатентованные, то есть открытые, системы набирают обороты. Они приносят преимущества, связанные с открытым SIP и открытым исходным кодом: стабильность, быстрое развитие, гибкость и, самое главное, экономия затрат. Благодаря постоянно развивающимся решениям открытого стандарта пользователям теперь предоставляется больше свободы для взаимодействия нескольких приложений и интеграции систем данных. Интеграторы все чаще хотят их, а конечные пользователи требуют от них более высокого уровня соотношения цена-качество и устранения риска привязки к поставщику. Итого И проприетарные, и открытые стандартные системы имеют свои явные преимущества. Важно знать своих клиентов и понимать их потребности. Сколько они могут позволить себе новую телефонную систему? Какой уровень гибкости и настройки они требуют? Есть ли у них собственный опыт по обслуживанию системы? Задавая правильные вопросы, вы сможете сделать выбор, чтобы предложить наилучшее решение.
img
OpenVZ и LXD позволяют вам запустить полноценную операционную систему внутри контейнера, не сильно отличающиеся друг от друга. Но является ли одна системная платформа лучше другой? Вот сравнение OpenVZ и LXD. Обе платформы представляют собой “системные контейнеры”, предназначенные для размещения готовых клиентских операционных систем без необходимости эмуляции в стиле VMware. Системные контейнерные платформы отличаются от контейнеров Docker тем, что Docker предназначен в первую очередь для размещения отдельных приложений внутри контейнеров. Основным преимуществом OpenVZ и LXD является то, что они предоставляют более легкое решение для запуска клиентских операционных систем, чем VMware, KVM или других платформ виртуализации. С точки зрения качества, оба работают одинаково. OpenVZ против LXD Но есть некоторые важные характеристики, которые разделяют эти две платформы. Детали, характерные для OpenVZ, включают в себя: Она существует с середины 2000-х годов, и это уже устоявшаяся технология. Поддерживает все основные дистрибутивы Linux. Вам не нужно использовать определенный дистрибутив, чтобы использовать OpenVZ. Для его установки требуется специальное ядро. Это может быть проблемой, если Вам необходимы специальные функции в Вашем ядре, которые не встроены в пакеты ядра, предоставляемые OpenVZ. Коммерческая поддержка доступна от Virtuozzo, основной компании, занимающейся разработкой OpenVZ. Вы вряд ли найдете варианты коммерческой поддержки в другом месте. Доступ к физическому оборудованию из контейнера по умолчанию отключен при использовании OpenVZ. Это означает, если Вам необходимо, чтобы приложение внутри Вашей контейнерной клиентской операционной системы имело доступ к такому устройству, как видеокарта, Вам придется настроить доступ вручную (Это неудобство можно считать сильной стороной, поскольку ограничение доступа к оборудованию, возможно, является функцией безопасности.) А вот характерные особенности для LXD: Он основан на LXC, платформе контейнеризации Linux, которая существует с конца 2000-х годов. Однако сама LXD является новой технологией - её первый стабильный релиз состоялся весной 2016 года. В настоящее время он поддерживает только Ubuntu, дистрибутив Linux от Canonical. Он не требует специального ядра; Вы можете использовать стандартное ядро Ubuntu с LXD. Canonical заявляет, что предлагает коммерческую поддержку LXD, но для этого, во всей видимости, требуется оплатить план поддержки всей системы Ubuntu. Выбор между OpenVZ и LXD Какая из этих системных контейнерных платформ лучше всего подходит? Конечно, Вы можете начать с чего угодно. Но в целом LXD, вероятно, является лучшим решением, если Вы уже используете Ubuntu для размещения своих рабочих нагрузок или можете легко переключиться на него. В противном случае, поскольку LXD не работает на других дистрибутивах Linux, OpenVZ будет единственным вариантом, если Вы подключены к другой операционной системе. Я предполагаю, что, поскольку LXD пользуется сильной поддержкой со стороны Canonical, он будет продолжать развиваться и в конечном итоге поддерживать другие дистрибутивы. Когда это произойдет, это может быть лучшим выбором в целом, поскольку на него не распространяются некоторые ограничения OpenVZ, такие как требование установки специального ядра. Но до тех пор OpenVZ явно имеет большую ценность в качестве решения для запуска системных контейнеров на дистрибутивах, отличных от Ubuntu.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59