По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
gRPC — это мощная платформа для работы с удаленными вызовами процедур (Remote Procedure Calls). RPC позволят писать код так, как будто он будет выполняться на локальном компьютере, даже если он может выполняться на другом компьютере. Что такое RPC? RPC — это форма взаимодействия клиент-сервер, в которой используется вызов функции, а не обычный вызов HTTP. Идея в том, что мы можем вызвать и выполнить функцию где-то на удаленной системе, как если бы это была локальная функция. Он использует IDL (Interface Definition Language - язык описания интерфейса) как форму контракта на вызываемые функции и тип данных. RPC — это протокол "запрос-ответ", т.е. он следует модели "клиент-сервер": Клиент делает запрос на выполнение процедуры на удаленном сервере. Как и при синхронном локальном вызове, клиент приостанавливается до тех пор, пока не будут возвращены результаты процедуры. Параметры процедуры передаются по сети на сторону сервера. Процедура выполняется на сервере и, наконец, результаты передаются обратно клиенту. gRPC воспроизводит этот архитектурный стиль взаимодействия клиент-сервер через вызовы функций. Таким образом, gRPC технически не является новой концепцией. Скорее, он был заимствован из этой старой техники и улучшен, что сделало ее очень популярной. Что такое gRPC? В 2015 году Google открыл исходный код своего проекта, который в конечном итоге получил название gRPC. Но что на самом деле означает буква «g» в gRPC? Многие люди могут предположить, что это для Google, потому что Google это сделал, но это не так. Google меняет значение «g» для каждой версии до такой степени, что они даже сделали README, чтобы перечислить все значения. С момента появления gRPC он приобрел довольно большую популярность, и многие компании используют его. Есть много причин, по которым gRPC так популярен: простая абстракция, он поддерживается во многих языках и он очень эффективный. И помимо всех вышеперечисленных причин, gRPC популярен потому, что очень популярны микросервисы и имеется большое количество взаимодействий между ними. Именно здесь gRPC помогает больше всего, предоставляя поддержку и возможности для решения типичных проблем, возникающих в таких ситуациях. А поскольку разные сервисы могут быть написаны на разных языках, gRPC поставляется с несколькими библиотеками для их поддержки. Архитектура gRPC Мы сказали что производительность gRPC очень высока, но что делает ее такой хорошей? Что делает gRPC намного лучше, чем RPC, если их дизайн очень похож? Вот несколько ключевых отличий, которые делают gRPC столь эффективным. HTTP/2 HTTP был с нами очень долго. Сейчас почти все серверные службы используют этот протокол. HTTP/1.1 долгое время оставался актуальным, затем в 2015 году, появился HTTP/2, который фактически заменил HTTP/1.1 как самый популярный транспортный протокол в Интернете. Если вы помните, что 2015 год был также годом выхода gRPC, и это было вовсе не совпадение. HTTP/2 также был создан Google для использования gRPC в его архитектуре. HTTP/2 — одна из важных причин, почему gRPC может работать так хорошо. И в следующем разделе вы поймете, почему. Мультиплексирование запроса/ответа В традиционном протоколе HTTP невозможно отправить несколько запросов или получить несколько ответов вместе в одном соединении. Для каждого из них необходимо создать новое соединение. Такой вид мультиплексирования запроса/ответа стал возможен в HTTP/2 благодаря введению нового уровня HTTP/2, называемого binary framing. Этот двоичный уровень инкапсулирует и кодирует данные. На этом уровне HTTP-запрос/ответ разбивается на кадры (они же фреймы). Фрейм заголовков (HEADERS frame) содержит типичную информацию заголовков HTTP, а фрейм данных (DATA frame) содержит полезные данные. Используя этот механизм, можно получить данные из нескольких запросов в одном соединении. Это позволяет получать полезные данные из нескольких запросов с одним и тем же заголовком, тем самым идентифицируя их как один запрос. Сжатие заголовка Вы могли столкнуться со многими случаями, когда заголовки HTTP даже больше, чем полезная нагрузка. И HTTP/2 имеет очень интересную стратегию под названием HPack для решения этой проблемы. Во-первых, все в HTTP/2 кодируется перед отправкой, включая заголовки. Это помогает повысить производительность, но это не самое важное в сжатии заголовков. HTTP/2 сопоставляет заголовок как на стороне клиента, так и на стороне сервера. Из этого HTTP/2 может узнать, содержит ли заголовок одно и то же значение, и отправляет значение заголовка только в том случае, если оно отличается от предыдущего заголовка. Как видно на картинке выше, запрос № 2 отправит только новый путь, так как другие значения точно такие же как и были. И да, это значительно сокращает размер полезной нагрузки и, в свою очередь, еще больше повышает производительность HTTP/2. Что такое Protocol Buffer (Protobuf)? Protobuf — это наиболее часто используемый IDL для gRPC. Здесь вы храните свои данные и функциональные контракты в виде так называемого прото-файла. По сути это протокол сериализации данных, такой как JSON или XML. Выглядит это так: message Person { required string name = 1; required int32 id = 2; optional string email = 3; } Так мы определили сообщение Person с полями name, id и email Поскольку это форма контракта то и клиент, и сервер должны иметь один и тот же прото-файл. Файл proto действует как промежуточный контракт для клиента, чтобы вызвать любые доступные функции с сервера. Protobuf также имеет собственные механизмы, в отличие от обычного REST API, который просто отправляет строки JSON в виде байтов. Эти механизмы позволяют значительно уменьшить полезную нагрузку и повысить производительность. Что еще может предложить gRPC? Метаданные Вместо обычного заголовка HTTP-запроса в gRPC есть то, что называется метаданными (Metadata). Метаданные — это тип данных «ключ-значение», которые можно установить как на стороне клиента, так и на стороне сервера. Заголовок может быть назначен со стороны клиента, в то время как серверы могут назначать заголовок и трейлеры, если они оба представлены в виде метаданных. Потоковая передача Потоковая передача (Streaming) — это одна из основных концепций gRPC, когда в одном запросе может выполняться несколько действий. Это стало возможным благодаря упомянутой ранее возможности мультиплексирования HTTP/2. Существует несколько видов потоковой передачи: Server Streaming RPC: когда клиент отправляет один запрос, а сервер может отправить несколько ответов. Например, когда клиент отправляет запрос на домашнюю страницу со списком из нескольких элементов, сервер может отправлять ответы по отдельности, позволяя клиенту использовать отложенную загрузку. Client Streaming RPC: когда клиент отправляет несколько запросов, а сервер отправляет обратно только один ответ. Например, zip/chunk, загруженный клиентом. Bidirectional Streaming RPC: клиент и сервер одновременно отправляют сообщения друг другу, не дожидаясь ответа. Перехватчики gRPC поддерживает использование перехватчиков для своего запроса/ответа. Они перехватывают сообщения и позволяют вам изменять их. Это звучит знакомо? Если вы работали с HTTP-процессами в REST API, перехватчики очень похожи на middleware (оно же промежуточное ПО). Библиотеки gRPC обычно поддерживают перехватчики и обеспечивают простую реализацию. Перехватчики обычно используются для: Изменения запроса/ответа перед передачей. Это можно использовать для предоставления обязательной информации перед отправкой на клиент/сервер. Позволяет вам манипулировать каждым вызовом функции, например, добавлять дополнительные логи для отслеживания времени отклика. Балансировки нагрузки Если вы еще не знакомы с балансировкой нагрузки, это механизм, который позволяет распределять клиентские запросы по нескольким серверам. Но балансировка нагрузки обычно делается на уровне прокси (например, nginx). Так причем это здесь? Дело в том, что gRPC поддерживает метод балансировки нагрузки клиентом. Он уже реализован в библиотеке Golang и может быть легко использован. Хотя это может показаться какой-то магией, это не так. Там есть что-то типа преобразователя DNS для получения списка IP-адресов и алгоритм балансировки нагрузки под капотом. Отмена вызова Клиенты gRPC могут отменить вызов gRPC, когда им больше не нужен ответ. Однако откат на стороне сервера невозможен. Эта функция особенно полезна для потоковой передачи на стороне сервера, когда может поступать несколько запросов к серверу. Библиотека gRPC оснащена шаблоном метода наблюдателя, чтобы узнать, отменен ли запрос, и позволить ей отменить несколько соответствующих запросов одновременно.
img
Привет! Сегодня в статье мы хотим рассмотреть систему восстановления Cisco Unified Communications Manager (CUCM) после сбоев, которая называется Disaster Recovery System (DRS) . С ее помощью можно делать бэкапы системы, которые будут храниться на SFTP сервере, и восстанавливать из них систему в случае такой необходимости. Архивирование при помощи DRS включает следующие компоненты: Cisco Unified Communications Manager database (CCMDB), включая Cisco Unified Communications Manager/CDR Analysis and Reporting/Call Detail Records); Platform Music On Hold (MOH); BAT Bulk Provisioning Service (BPS); CCM Preference Files (CCMPREFS); TFTP Phone device files (TFTP); SNMP Syslog Component (SYSLOGAGT SNMP); SNMP CDP Subagent (CDPAGT SNMP); Trace Collection Tool (TCT); Cluster Manager (CLM); Cisco Extended Functions (CEF); Настройка Прежде всего, для выполнения резервного копирования нам нужно развернуть SFTP сервер. Cisco рекомендует использовать такие клиенты как Cygwin, Titan FTP, GlobalSCAPE EFT, но можно использовать и другие. Загружаем желаемый клиент, устанавливаем его на машине, на которой будет использоваться SFTP сервер, в нем самом настраиваем сетевые параметры подключения, указываем корневую папку и затем запускаем сервис. Теперь переходим к настройке CUCM. Нам нужно войти в систему восстановления после сбоев, для этого нам нужно в правом верхнем углу из выпадающего меню выбрать пункт Disaster Recovery System. Здесь переходим во вкладку Backup → Backup Device и нажимаем Add New. В открывшемся окне необходимо указать названия для бэкапа в строке Backup device name. Ниже в поле Select Destination выбираем Network Directory и указываем IP адрес SFTP сервера в строке Host name/IP address, реквизиты для подключения указываем в полях User name и Password, а поле Path name указываем путь для каталога, где будут храниться наши данные (если необходимо хранить файл в корневом каталоге, то указываем ’’’’). После этого нажимаем Save. Если SFTP сервер работает и доступен, то мы увидим надпись Update Successful. Теперь чтобы создать бэкап нам нужно перейти во вкладку Backup → Manual Backup, выбрать созданные нами ранее настройки резервирования и нажать Start Backup. Создать расписание для выполнения архивирования можно в меню Backup → Scheduler, где нужно нажать Add New для создания нового расписания. Тут выбираем бэкап, указываем время выполнения архивации и нажимаем Save. После чего нажимаем Enable Schedule наверху экрана. Теперь рассмотрим восстановление системы, которое называется Restoring a Node or Cluster to a Last Known Good Configuration (No Rebuild) , то есть до последней рабочей конфигурации. Для того чтобы восстановить систему из созданного бэкапа нужно перейти во вкладку Disaster Recovery System → Restore → Restore Wizard. Тут выбираем Backup Device, затем нажимаем Next и выбираем один из доступных файлов. Далее указываем, какие функции должны быть восстановлены. Затем выбираем нужные серверы для восстановления и нажимаем Restore. После этого начнется восстановление системы. Статус текущего восстановления можно посмотреть во вкладке Disaster Recovery System → Restore → Status. После того как произойдет восстановление нужно будет перезагрузить сервер. Проверить статус репликации можно либо при помощи RTMT, в пункте Call Manager → Database Summary → Replication Status, где для всех нод мы должны видеть одинаковое значение, либо через систему отчетов CUCM Unified Reporting в пункте Unified Reporting → System Reports → Unified CM Database Status, где мы должны найти строчку All servers have a good replication status, либо через командную строку CLI, выполнив команду utils dbreplication status, результатом которой мы должны получить строчку No Errors or Mismatches found. Replication status is good on all available servers.
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 предпочтительным алгоритмом очередей для голоса; Существует много других алгоритмов для очередей, эти три охватывают методы, используемые большинством современных сетей
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59