По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Продолжаем рассказывать про механизмы 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 предпочтительным алгоритмом очередей для голоса;
Существует много других алгоритмов для очередей, эти три охватывают методы, используемые большинством современных сетей
Давно прошли те времена, когда «база данных» представляла собой единую СУБД на основе реляционной модели данных, которую обычно устанавливали на самом мощном сервере в центре обработки данных. Такая база данных могла обслуживать все виду запросов – OLTP (On-Line Transaction Processing – обработка транзакций в режиме реального времени), OLAP (On-Line Analytical Processing – аналитическая обработка данных в режиме реального времени) – все, что нужно для бизнеса.
В настоящее время базы данных работают на самом обычном оборудовании, они также стали более сложными с точки зрения высокой доступности и более специализированными для обработки определенного типа трафика. Специализация позволяет добиться гораздо большей производительности баз данных – все оптимизировано для работы с определенным типом данных: оптимизатор, механизм хранения, даже язык может быть не SQL, как это бывает обычно. Он может быть основан на SQL с некоторыми расширениями, которые позволяют более эффективно манипулировать данными, или может быть чем-то абсолютно новым, созданным с нуля.
На сегодня мы имеем аналитические столбчатые базы данных, такие как ClickHouse или MariaDB AX, платформы обработки и анализа больших данных, такие как Hadoop, решения NoSQL, такие как MongoDB или Cassandra, хранилища данных типа «ключ-значение», такие как Redis. Мы также имеем базы данных временных рядов, такие как Prometheus или TimeScaleDB. Это именно то, на чем мы акцентируем внимание в данной статье. Базы данных временных рядов (Time Series Databases) – что это такое и зачем вам нужно еще одно хранилище данных в своей среде.
Для чего нужны базы данных временных рядов?
Как видно из названия, базы данных временных рядов предназначены для хранения данных, которые изменяются со временем. Это могут быть абсолютно любые данные, собранные с течением времени. Это могут быть метрические показатели, собранные из некоторых систем – все системы трендов являются примерами данных временных рядов.
Каждый раз, когда вы смотрите на информационные панели в ClusterControl, на самом деле вы видите визуальное представление временных рядов, хранящихся в Prometheus – базе данных временных рядов.
Временные ряды не ограничиваются метрическими показателями базы данных. Метриками может быть что угодно – изменение потока людей, входящих в торговый центр, с течением времени, изменение трафика в городе, использование общественного транспорта в течение дня, течение воды в реке или ручье, количество энергии, вырабатываемое водной установкой – все это и все остальное, что можно измерить во времени, является примером временных рядов. Такие данные можно запросить, построить, проанализировать, чтобы найти корреляционную зависимость между различными метриками.
Структура данных в базе данных временных рядов
Как вы понимаете, самая важная составляющая данных в базе данных временных рядов – это время. Существует два основных способа хранения данных. Первый способ чем-то похож на хранилище «ключ-значение» и выглядит так:
Метка времени
Метрика 1
2019-03-28 00:00:01
2356
2019-03-28 00:00:02
6874
2019-03-28 00:00:03
3245
2019-03-28 00:00:04
2340
Проще говоря, для каждой метки времени имеется некоторое значение метрики.
Второй способ подразумевает хранения большего числа показателей. Вместо того, чтобы хранить каждую метрику в отдельной таблице или коллекции, их можно хранить вместе.
Метка времени
Метрика 1
Метрика 2
Метрика 3
Метрика 4
Метрика 5
2019-03-28 00:00:01
765
873
124
98
0
2019-03-28 00:00:02
5876
765
872
7864
634
2019-03-28 00:00:03
234
7679
98
65
34
2019-03-28 00:00:04
345
3
598
0
7345
Такая структура данных, когда все метрики связаны, позволяет более эффективно запрашивать данные. Вместо того, чтобы читать несколько таблиц и объединять их для получения всех метрик, достаточно прочитать лишь одну единственную таблицу, чтобы подготовить данные к обработке и представлению.
У вас может возникнуть вопрос – что же здесь нового? Чем эта база данных отличается от обычной таблицы в MySQL или в любой другой реляционной базе данных? Да, действительно, конструкция таблиц очень похожа. Однако есть существенные различия в рабочей нагрузке, которые могут существенно повысить производительность, если хранилище данных предназначено для использования такого рода таблиц,
Временные ряды, как правило, только растут. Маловероятно, что вы будете обновлять старые данные. Чаще всего строки в таблице не удаляются, однако вам может понадобиться какая-то агрегация данных с течением времени. Если принять это при проектировании внутреннего устройства базы данных, то этот факт будет иметь существенное расхождение в сравнении со «стандартными» реляционными (и не реляционными) базами данных, предназначенными для обработки транзакций в режиме реального времени. Что здесь является наиболее важным, так это способность последовательно хранить большие объемы данных, поступающих со временем.
Можно, конечно, использовать РСУБД для хранения временных рядов, но она не оптимизирована для этого. Данные и индексы, сгенерированные на ее основе, могут стать слишком большими, и запросы будут проходить очень медленно. Механизмы хранения данных, используемые в СУБД, предназначены для хранения различных типов данных. Обычно они оптимизированы для рабочей нагрузки обработки транзакций в режиме реального времени, которая включает в себя частое изменение и удаление данных. В реляционных базах данных также часто отсутствуют специализированные функции и функции, предназначенные для обработки временных рядов. Мы уже упоминали, что вы вероятно столкнетесь с необходимостью агрегировать данные, полученные ранее какой-то временной метки. Вы также можете иметь возможность легко запускать некоторые статистические функции для ваших временных рядов, чтобы сглаживать их, определять и сравнивать тренды, интерполировать данные и многое другое. Здесь, например, вы можете найти некоторые функции, которые Prometheus предоставляет пользователям.
Примеры баз данных временных рядов
На рынке существует множество баз данных временных рядов, поэтому, естественно, что рассмотреть все мы не сможем. Но мы все же хотели привести несколько примеров баз данных временных рядов, которые, возможно, вам уже знакомы или которые вы уже, возможно, используете (сознательно или нет).
InfluxDB
InfluxDB была разработана компанией InfluxData. Это база данных временных рядов с открытым исходным кодом, написанная языке программирования Go. Хранилище данных позволяет вводить запросы данных на языке, подобном SQL, что позволяет разработчикам легко интегрировать эту базу данных в свои приложения. InfluxDB также может работать как часть коммерческого решения, которое охватывает весь стек, предназначенный для обеспечения процесса обработки данных временных рядов, полнофункциональной высоко доступной средой.
Prometheus
Prometheus – это еще один проект с отрытым исходным кодом, который также написан на языке программирования Go. Он обычно используется в качестве серверной части для различных инструментов и проектов с открытым исходным кодом, например, Percona Monitoring and Management. Prometheus также является наилучшим вариантом для ClusterControl.
Prometheus можно развернуть из ClusterControl с целью хранения данных временных рядов, собранных на серверах баз данных, контролируемых и управляемых ClusterControl:
Prometheus широко используется в мире Open Source, поэтому его довольно легко интегрировать в уже существующую среду с помощью нескольких экспортеров.
RRDtool
Это один из примеров базы данных временных рядов, которую многие используют, даже не подозревая об этом. RRDtool – это достаточно популярный проект с открытым исходным кодом для хранения и визуализации временных рядов. Если вы хоть раз использовали Cacti, то и RRDtool вы тоже использовали. Если вы разработали свое собственное решение, вполне вероятно, что и здесь вы тоже использовали RRDtool в качестве серверной части для хранения данных. Сейчас RRDtool, возможно, не так популярен, как это было в 2000-2010 годах. В те годы это был самый распространенный способ хранения временных рядов. Забавный факт – ранние версии ClusterControl использовали именно RRDtool.
TimeScale
TineScale – это база данных временных рядов, разработанная на основе PostgreSQL. Это расширение для PostgreSQL, которое использует основное хранилище данных для предоставления доступа к ним, что означает, что оно поддерживает все разновидности SQL, доступные для использования. Поскольку это расширение, то оно использует все функции и расширения PostgreSQL. Вы можете совмещать временные ряды с другими типами данных, например, объединять временные ряды с метаданными, пополняя информацией выходные данные. Вы также можете выполнить более сложную фильтрацию, используя JOIN и таблицы без временных рядов. Геоинформационное обеспечение в PostgreSQL TimeScale можно использовать для отслеживания географических местоположений с течением времени, а также использовать все возможности масштабирования, предлагаемые PostgreSQL, включая репликацию.
Timestream
Amazon Web Services также предлагает базы данных временных рядов. О Timestream было объявлено совсем недавно, в ноябре 2018 года. Она добавляет еще одно хранилище данных в портфель AWS, помогая пользователям обрабатывать временные ряды, поступающие из таких источников, как устройства Интернет вещей или отслеживаемые сервисы. Его также можно использовать для хранения метрических данных, полученных из журналов, созданных несколькими службами. Это позволяет пользователям выполнять аналитические запросы к ним, помогая понять закономерности и условия, в которых работают службы.
Tiemstream, как и большинство сервисов AWS, обеспечивает простой способ масштабирования в случае, если с течением времени возрастает потребность в хранении и анализе данных.
Как видите, вариантов баз данных временных рядов на рынке множество, и это не удивительно. В последнее время, все более популярным становится анализ временных рядов, поскольку он становится все более важных для различных бизнес-операций. К счастью, есть большое количество проектов как с открытым кодом, так и коммерческих. И с большой долей вероятности вы сможете найти инструмент, который полностью удовлетворит ваши потребности.
Огромный и “кровавый" энтерпрайз врывается в нашу IT - базу знаний. Говорить будем о продукте (точнее продуктах) американской компании Genesys. Эти ребята делают ПО для контактных центров, так сказать, высшего разряда - банки, государство и крупнейшие предприятия. Хотя сам Genesys подчеркивает, что решение может помочь и малому бизнесу, но, честно говоря, автор статьи не на своем веку не встречал инсталляций Genesys в SMB сегменте (по крайней мере в России).
/p>
Genesys постоянно фигурирует в сводке компании Gartner, в 2018 году ребятам даже удалось стать лидером в “магическом квадранте". Давайте разбираться.
Что умеет контакт - центр на базе Genesys?
Вендор позиционирует свой продукт в четырех плоскостях. Разберемся по порядку.
Улучшение клиентского сервиса
Первая часть профита. Genesys обеспечит умную маршрутизацию на агентов (умнее чем даже модный prescission routing у Cisco), которая маршрутизирует на агентов не только на базе привычных скиллов или атрибутов, на и подключается искусственный интеллект и технологии машинного обучения. Клиент попадет именно на того агента, который сможет решить его вопрос. Так сказать, дата - дривен подход в маршрутизации клиентских обращений - и это не только голос. Конечно Genesys умеет в модный омниченнел.
Помимо фронтовой части КЦ (звонки и разговоры с агентами), Genesys обеспечит вас инструментами WFO, которые позволяет более эффективно планировать смены агентов, чтобы нагрузка на КЦ была обеспечена в рамках требуемого service level.
Что касается так называемых “порталов самообслуживания" - у ребят есть решение. Создавать сервисы, в рамках которых при обращении в КЦ клиент сам сможет решить свою проблему довольно просто.
Это основные пункты. Но далеко не все. Погнали дальше.
Маркетинг
Омниканальный возможности вендора (чаты, мессенджеры, то есть не только голос) обеспечат точечную доставку ваших маркетинговых кампаний до клиентов. Вы уверены, что 20ти летний клиент вашего бизнеса хочет принять звонок? Может быть он ждет сообщения в мессенджер?
Продажи
Инструментов много. Но самый популярный - это конечно исходящий обзвон (дайлер). Genesys OCS (outbound contact server) вместе с интеграционными возможностями и гибкой кастомизацией обзвона (днем звоним на мобильный, вечером на домашний в зависимости от часового пояса, как вам?), с возможностью обзвона в режимах ручного набор, превью (preview, тут агенту выгружается список контактов и он сам решает, кому звонить), progressive (тоже самое что и превью, только оператор не выбирает) или predictive (дайлер угадывает доступность абонента) - изи.
Конкуренты
Основные конкуренты это Cisco и Avaya. У Cisco можно выделить 2 продукта (на оба у нас есть статьи, ознакомьтесь нажав ниже):
Cisco UCCX - конкурентом, конечно, можно назвать с натяжкой. Ибо это контакт - цент экспресс;
Cisco UCCE - тяжеловесная энтерпрайзная машина для контакт - центров. Полноценный конкурент;
И решения Avaya Aura. Мы не будем делиться субъективными мнения, кто круче и у кого “очереди больше". Посмотрите анализ гартнера ,если хотите понимать динамику во временном разрезе.
Примерная архитектура
От инсталляции к инсталляции. И это важно. Но мы очень постарались в общих чертах с детализацией роли серверов нарисовать, как работает КЦ от Genesys. Гляньте на картинку. Мы очень верхнеуровнево постарались показать, как работает обработка цифровых и голосовых каналово в Genesys:
Теперь давайте поговорим компоненты:
Клиент - хммм. Кто же это может быть?
Голос - голосовой обращение клиента в КЦ (звонок);
Чат - текстовое сообщение через мессенджер, чат на сайте или мобильном приложении, например;
SIP сервер - это интерфейс между SIP (телефония) и компонентами Genesys. Принимает SIP запросы и транслирует их дальше на понятный остальным компонентам язык;
GVP - он же Genesys Voice Platform. Гибкая платформа создания приложений для обработки вызовов и работы с RTP потоками. У Cisco есть CVP, а у Genesys GVP, вай нот?) ;
ASR/TTS - сердце синтеза и распознавания речи (если мы делаем голосовые сервисы). Genesys активно топит за Nuance, но не переживайте - там живет MRCP. Можно и ЦРТ подключить, и что угодно;
GMS - Genesys Mobile Services. Расширяет функции REST API для интеграции с внешними приложениями. Например, с API от Telegram (мессенджер);
Interaction сервер - часть PureEngage Digital (eServices). То есть это не голосовые, а цифровые коммуникации. Сервер помогает выполнить обмен сообщениями и выполнять контроль воркфлоу обработки, как было нарисовано в IRD (Interaction Routing Designer). Кстати, IRD это конструктор скриптов маршрутизации. Об этом в следующих статьях;
ORS - важный. Очень важный. Его зовут Orchestration Server и он помогает в маршрутизации запросов. ORS интегрируется с другими компонентами, и по факту, просто выполняет на себе SCXML скрипты (стратегии), которые вы сможете сделать в Composer (инструмент для генерации стратегий маршрутизации);
Conversation Manager - сам по себе конверсейшн менеджер, это некое приложение, которое обеспечивает согласованную клиентскую коммуникацию. Давайте про его модули поконкретнее:
Context Services - помогает определить клиента. Кто он? Чего хочет? Где он находится в процессе всего пути клиентского обращения?;
Genesys Rules - набор каких то правил. Например, если мы знаем, что этот клиент интересуется кредитами, часто звонит и исправно платит свой текущий кредит, то в качестве опций, предлагаемых ему, будет предложено воспользоваться приложениям для самообслуживания, например. Условно говоря, этот модуль живет на принятии решений вида if..then;
Journey Timeline - классная штука. Визуальная шкала того, какой путь прошел ваш клиент, какие пункты IVR послушал, какие порталы самообслуживания “поюзал" и так далее. CJM (customer journey map), так сказать;
Pulse коллектор - компонент, который напрямую коннектится к Stat серверу (сервер сбора статистики) и забирает с него статистику по объектам КЦ;
Data Depot - берет данные из Context Services, чтобы передать в статистику информацию по клиенту;
Pulse - компонент отчетности и анализа статистики КЦ;
Вот так. Это примерная архитектура контактного центра на базе Genesys.
Итоги
КЦ на базе Genesys - отличный и конкурентный вариант. Продукт имеет мощных конкурентов, борьба с которыми обеспечивает его динамичное развитие. Набор продуктов Genesys создан для того, чтобы прогреть лояльность ваших клиентов то температуры кипения, увеличить продажи и улучшить маркетинговые кампании.