По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:

Если вам проще ориентироваться в графическом интерфейса FreePBX тринадцатой версии на русском языке, то у нас хорошие новости – перевод на русский язык включен в дистрибутив и не требует дополнительных инсталляционных пакетов. Итак, переходим к настройке
Настройка в Advanced Settings
Подключитесь к графическому интерфейсу и перейдите во вкладку Settings -> Advanced Settings. В секции GUI Behavior включите опцию Show Language setting как показано на скриншоте ниже:
После включения, нажмите последовательность кнопок Submit и затем Apply Config. Как только вы примените конфигурацию, в верхнем меню навигации у вас появится кнопка смены языка. На скриншоте она выделена красным:
Нажмите на нее и выберете русский язык. После этого, нажмите на красную кнопку Применить изменения. Язык интерфейса стал русским:
Как говорят в мире IT, административный интерфейс должен быть на английском языке, а интерфейс пользователя на нативном (в нашем случае на русском). Учите английский друзья :)

Это продолжение статьи про пакетную коммутацию. Первая часть тут.
Схемы агрегации каналов берут несколько физических каналов и объединяют их в один виртуальный канал. В целях протоколов маршрутизации и алгоритмов предотвращения петель, таких как связующее дерево, виртуальный канал обрабатывается, как если бы он был одним физическим каналом.
Агрегирование каналов используется для увеличения пропускной способности между узлами сети без необходимости замены более медленных физических каналов на более быстрые. Например, два канала 10 Гбит/с можно объединить в один канал 20 Гбит/с, тем самым удвоив потенциальную полосу пропускания между двумя узлами, как показано на рисунке 6. Слово «потенциал» было выбрано тщательно, поскольку агрегированные каналы на практике не масштабируются линейно.
Проблема, с которой сталкивается агрегация каналов, заключается в определении, какие пакеты должны быть отправлены по какому элементу связи. Интуитивно это может показаться не проблемой. В конце концов, казалось бы, имеет смысл использовать группу каналов связи в циклическом режиме. Первоначальный фрейм будет отправлен по первому элементу связки, второй фрейм - по второму элементу и так далее, в конечном итоге возвращаясь к первому элементу связки. Таким образом, канал должен использоваться идеально равномерно, а пропускная способность - линейно.
В реальной жизни существует очень мало подобных реализаций, в которых агрегированные каналы используются на такой циклической основе, как эта, потому что они рискуют доставить неупорядоченные пакеты. Предположим, что первый кадр Ethernet отправляется первому звену нисходящего канала, а второй кадр - второму элементу нисходящего канала сразу после него. По какой-то причине второй кадр попадает на другой конец раньше первого кадра. Пакеты, содержащиеся в этих кадрах, будут доставлены принимающим узлам в неупорядоченном порядке - пакет два перед пакетом один. Это проблема, потому что теперь на хост возлагается вычислительная нагрузка по переупорядочению пакетов, чтобы можно было правильно собрать всю дейтаграмму.
Поэтому большинство поставщиков реализуют хеширование потоков, чтобы гарантировать, что весь поток трафика использует один и тот же элемент пакета. Таким образом, нет никакого риска того, что хост получит пакеты не по порядку, так как они будут отправляться последовательно через один и тот же элемент канала.
Хеширование потока работает путем выполнения математической операции над двумя или более статическими компонентами потока, такими как MAC-адреса источника и получателя, IP-адреса источника и получателя, протокол управления передачей (TCP) или протокол дейтаграмм пользователя (UDP). номера портов для вычисления элемента связи, который будет использовать поток. Поскольку характеристики потока статичны, алгоритм хеширования приводит к идентичным вычислениям для каждого кадра или пакета в потоке трафика, гарантируя, что один и тот же канал будет использоваться в течение всего срока службы потока.
Хотя хеширование потока решает проблему неупорядоченных пакетов, оно создает новую проблему. Не все потоки имеют одинаковый размер. Некоторые потоки используют большую полосу пропускания, например те, которые используются для передачи файлов, резервного копирования или хранения. Их иногда называют «слоновьими потоками» (elephant flows). Другие потоки довольно малы, например, те, которые используются для загрузки веб-страницы или связи с использованием передачи голоса по IP. Их иногда называют «мышиными потоками» (mouse flows). Поскольку потоки имеют разные размеры, некоторые элементы связи могут работать на полную мощность, а другие - недостаточно.
Это несоответствие в использовании возвращает нас к вопросу о линейном масштабировании. Если бы фреймы были сбалансированы по нагрузке через агрегированный набор каналов совершенно равномерно, то добавление новых каналов в набор равномерно увеличило бы емкость. Однако алгоритмы хэширования в сочетании с непредсказуемым объемом потоков трафика означают, что связанные каналы не будут загружаться равномерно.
Задача сетевого администратора - понять тип трафика, проходящего через агрегированный канал, и выбрать доступный алгоритм хеширования, который приведет к наиболее равномерному распределению нагрузки. Например, некоторые соображения по этому поводу:
Обмениваются ли многие хосты в одном широковещательном домене друг с другом через агрегированный канал? Хеширование против MAC-адресов, найденных в заголовке кадра Ethernet, является возможным решением, потому что MAC-адреса будут разными.
Обменивается ли небольшое количество хостов с одним сервером через агрегированный канал? В этом сценарии может не хватить разнообразия MAC-адресов или IP-адресов. Вместо этого хеширование по номерам портов TCP или UDP может привести к наибольшему разнообразию и последующему распределению трафика по агрегированным ссылкам.
Протокол управления агрегацией каналов (LACP)
При объединении каналов связи необходимо учитывать сетевые устройства на обоих концах канала связи и проявлять особую осторожность, чтобы обеспечить формирование пакета каналов связи при сохранении топологии без петель. Наиболее распространенным способом решения этой проблемы является использование отраслевого стандарта Link Aggregation Control Protocol (LACP), кодифицированного как стандарт 802.3 ad института инженеров электротехники и электроники (IEEE).
На каналах, обозначенных сетевым администратором, LACP объявляет о своем намерении сформировать агрегированный канал с другой стороной. Другая сторона, также выполняющая LACP, принимает это объявление, если объявленные параметры действительны, и формирует канал. Как только группа каналов сформирована, агрегированный канал переводится в состояние пересылки. Затем операторы сети могут запросить LACP для получения информации о состоянии агрегированного канала и о состоянии его членов.
LACP также знает, когда элемент связки выходит из строя, так как управляющие пакеты больше не проходят через сбойный канал. Эта возможность полезна, так как позволяет процессу LACP уведомлять сетевую операционную систему о необходимости пересчета хэшей потока. Без LACP сетевой операционной системе может потребоваться больше времени, чтобы узнать о сбойном канале, что приведет к хешированию трафика к элементу связи, который больше не является допустимым путем.
Существуют и другие протоколы управления агрегацией каналов. В некоторых случаях также возможно создавать пакеты каналов вручную без защиты управляющего протокола. Однако LACP доминирует в качестве стандарта, используемого сетевыми поставщиками, а также ведущими операционными системами и поставщиками гипервизоров для агрегации каналов.
Multichassis Link Aggregation
Multichassis Link Aggregation (MLAG) - это функция, предлагаемая некоторыми сетевыми поставщиками, позволяющая одному агрегированной связке каналов охватывать два или более сетевых коммутатора. Чтобы облегчить это, специальный протокол управления поставщика будет работать между коммутаторами-членами MLAG, заставляя несколько сетевых коммутаторов действовать так, как если бы они были одним коммутатором, в отношении LACP, протокола связующего дерева (STP) и любых других протоколов.
Обычным обоснованием для MLAG является физическая избыточность, когда сетевому инженеру требуется более низкий уровень (например, Ethernet) смежности между сетевыми устройствами (вместо маршрутизируемого соединения), а также требуется, чтобы связка каналов оставалась включенной, если удаленная сторона канала выходит из строя. Распространение связки каналов между двумя или более коммутаторами позволяет выполнить это требование. Рисунок 7 демонстрирует это.
В то время как многие сети используют некоторые разновидности MLAG в производстве, другие уклоняются от этой технологии, по крайней мере частично, потому что MLAG является собственностью. Нет такой вещи, как multivendor MLAG. Тенденции к лучшему проектированию сети в сторону от широко рассредоточенных коммутируемых доменов, сценарий, который выигрывает у MLAG. Вместо этого при проектировании сети наблюдается тенденция к ограниченным коммутируемым доменам, взаимосвязанным посредством маршрутизации, что устраняет необходимость в технологиях MLAG.
Маршрутизированные параллельные каналы
Маршрутизируемые плоскости управления, называемые протоколами маршрутизации, иногда вычисляют набор нескольких путей через сеть с равными затратами. В случае маршрутизации несколько каналов с одинаковой стоимостью могут даже не подключать одну пару устройств; Рисунок 8 демонстрирует это.
На рисунке 8 есть три пути:
[A, B, D] общей стоимостью 10
[A, D] общей стоимостью 10
[A, C, D] общей стоимостью 10
Поскольку эти три пути имеют одинаковую стоимость, все они могут быть установлены в локальной таблице переадресации в точках A и D. Маршрутизатор A, например, может пересылать трафик по любому из этих трех каналов в направлении D. Когда маршрутизатор имеет несколько вариантов. чтобы добраться до того же пункта назначения, как он решает, какой физический путь выбрать?
Как и в случае с ECMP нижнего уровня, ответ - хеширование. Маршрутизированное хеширование ECMP может выполняться в различных областях. Общие поля для хеширования включают IP-адреса источника или назначения и номера портов источника или назначения. В результате хеширования выбирается согласованный путь на протяжении потока L3. Только в случае сбоя канала потребуется перестроить поток и выбрать новый канал пересылки.
Механизмы обработки пакетов
Шаги, связанные с маршрутизацией одного пакета, могут показаться очень простыми—найдите пункт назначения в таблице, создайте (или извлеките) перезапись заголовка MAC, перепишите заголовок MAC, а затем поместите пакет в правильную очередь для исходящего интерфейса. Как бы просто это ни было, все равно требуется время, чтобы обработать один пакет. На рисунке 9 показаны три различных пути, по которым пакет может быть коммутироваться в сетевом устройстве.
Рисунок 9 иллюстрирует три различных пути коммутации через устройство; это не единственные возможные пути коммутации, но они являются наиболее распространенными. Первый путь обрабатывает пакеты через программное приложение, работающее на универсальном процессоре (GPP), и состоит из трех этапов:
Пакет копируется с физического носителя в основную память
Физический сигнальный процессор, чип PHY, посылает сигнал на GPP (вероятно, но не обязательно, главный процессор в сетевом устройстве), называемый прерыванием.
Прерывание заставляет процессор останавливать другие задачи (вот почему это называется прерыванием) и запускать небольшой фрагмент кода, который будет планировать запуск другого процесса, приложения коммутации, для выполнения позже.
Когда приложение коммутации запустится, оно выполнит соответствующий поиск и внесет соответствующие изменения в пакет.
После коммутации пакета он копируется из основной памяти исходящим процессором. Такое переключение пакета через процесс часто называется коммутацией процесса (по понятным причинам) или иногда медленным путем. Независимо от того, насколько быстрым является GPP, для достижения полной линейной скорости коммутации на высокоскоростных интерфейсах требуется большая настройка - до такой степени, что это практически невозможно. Второй путь коммутации, показанный на рисунке 9, был разработан для более быстрой обработки пакетов:
Пакет копируется с физического носителя в основную память
Микросхема PHY прерывает GPP; код обработчика прерывания, а не вызов другого процесса, фактически обрабатывает пакет.
После коммутации пакета, пакет копируется из основной памяти в процесс вывода, как описано ниже. По понятным причинам этот процесс часто называют interrupt context switching; многие процессоры могут поддерживать коммутацию пакетов достаточно быстро, чтобы передавать пакеты между интерфейсами с низкой и средней скоростью в этом режиме. Сам код коммутации, конечно же, должен быть сильно оптимизирован, потому что коммутация пакета заставляет процессор прекращать выполнение любых других задач (например, обработки обновления протокола маршрутизации). Первоначально это называлось - и до сих пор иногда называется fast switching path. Для действительно высокоскоростных приложений процесс коммутации пакетов должен быть выгружен с главного процессора или любого типа GPP на специализированный процессор, предназначенный для конкретной задачи обработки пакетов. Иногда эти процессоры называются сетевыми процессорами (Network Processing Units -NPU), подобно тому, как процессор, предназначенный для обработки только графики, называется графическим процессором (Graphics Processing Unit-GPU). Эти специализированные процессоры являются подмножеством более широкого класса процессоров, называемых специализированными интегральными схемами (Application-Specific Integrated Circuits -ASIC), и инженеры часто просто называют их ASIC. Переключение пакета через ASIC показано как шаги с 7 по 9 на рисунке 9:
Пакет копируется с физического носителя в память ASIC
Микросхема PHY прерывает работу ASIC; ASIC обрабатывает прерывание путем переключения пакета.
После коммутации пакета пакет копируется из памяти ASIC в процесс вывода, как описано ниже.
Многие специализированные ASIC для обработки пакетов имеют ряд интересных функций, в том числе:
Структуры внутренней памяти (регистры) настроены специально для обработки различных типов адресов, используемых в сетях.
Специализированные наборы команд, предназначенные для выполнения различных требований к обработке пакетов, таких как проверка внутренних заголовков, переносимых в пакете, и перезапись заголовка MAC.
Специализированные структуры памяти и наборы инструкций, предназначенные для хранения и поиска адресов назначения для ускорения обработки пакетов
Возможность повторного использования пакета через конвейер пакетов для выполнения операций, которые не могут поддерживаться за один проход, таких как глубокая проверка пакетов или специализированные задачи фильтрации.

MongoDB представляет собой универсальную структурированную и документно-ориентированную распределенную базу данных, созданную для современных приложений.
Почему MongoDB?
MongoDB NoSQL является базой данных с открытым исходным кодом, хотя, для корпоративных версий, придется покупать лицензии.
MongoDB использует масштабируемую архитектуру на основе документов, которая хранит данные в формате JSON. Она обладает такими функциями, как совместное использование, кластеризация, репликация, агрегирование, формат BSON, индексирование, коллекции ограниченного объема и хранение файлов. Для хранения и извлечения данных из базы данных используется механизм wiredTiger, которая намного быстрее по сравнению с другими СУБД. Есть и другие полезные функции, которые включает в себя MongoDB, например, функция многодокументных ACID транзакций.
В зависимости от варианта использования, у нас могут быть два аспекта, на которых необходимо обратить внимание при выборе хостинга на платформе MongoDB. Первым из них будет цена, а вторым возможности, которые она предлагает.
Если говорить о ценообразовании, во-первых, нужно проверить хостинг провайдеры, которые предоставляют либо бесплатные, либо пробные версии. Как только мы воспользуемся этой схемой, будет легче принять решение. После использования бесплатной или пробной версии, мы можем сравнить и поискать другие более дешевые варианты.
Говоря о функциях, ниже приведены ключевые особенности, которые необходимо принять во внимание, прежде чем выбирать для MongoDB хостинг платформу.
Насколько хороша производительность?
Размышляя о производительности, мы рассматриваем такие факторы, как время безотказной работы, например, скорость скачки и скорость закачки.
Насколько хороша поддержка?
Поддержка является очень важной частью при выборе платформы. Так как если возникнет какая-либо проблема, необходимо иметь надежную систему поддержки, которая может вовремя подключиться и быстро устранить проблемы.
Насколько хороши методы резервного копирования?
Каждая хостинговая компания имеет различные методы и процедуры резервного копирования. Некоторые компании берут дополнительную плату за хранение резервных копий и ставят ограничения на размер резервных копий. Это также важно, поскольку для резервного копирования базы данных требуется остановка системы или перезапуск.
Существует два способа арендования хостингов MongoDB.
Self-hosted
Буквально переводится как самоуправляемый. Вы получаете облачную виртуальную машину и сами заботитесь об установке, настройке, мониторинге и администрировании. Это хорошо, если вы технически подкованный человек и у вас есть время заниматься всей этой кропотливой работой. Это может обойтись немного дешевле, но вы соглашаетесь на трату своего времени (а может и бессонные ночи).
Managed
В данном варианту вся забота настройки и текущего обслуживания лежит на персонале хостинг провайдера, и вы оплачиваете то, что используете. Ниже приведены некоторые из популярных платформ для размещения MongoDB.
В этом материале постараемся рассмотреть их.
1. Atlas
Atlas - облачный сервис баз данных компании MongoDB.
Он имеет упрощенный пользовательский интерфейс для настройки баз данных и управления ими, а также многие другие функции, такие как совместное использование, кластеризация, репликация и т.д. Имеется возможность размещения на AWS, GCP или Azure.
Такие компании, как eharmony, InVision, SEGA, KPMG, 7-ELEVEN широко используют облачный Atlas.
Вы можете начать пользоваться им БЕСПЛАТНО, чтобы изучить платформу. Бесплатная версия предоставляет вам следующее.
512 МБ памяти
Общая ОЗУ
Наборы точных копий высокой надежности, сквозное шифрование, автоматические исправления, REST API
Кроме того, при запуске выделенного кластера получите доступ к следующему:
10 ГБ или более ресурсов хранения
Выделенная ОЗУ
Инструменты оптимизации производительности
Резервное копирование и восстановление на определенный момент времени
Функции корпоративной безопасности, включая управление ключами шифрования, интеграцию LDAP и выборочный аудит баз данных
Глобальные кластеры
2. Kamatera
Kamatera является глобальным поставщиком облачных услуг и предоставляет инфраструктуру корпоративного уровня для малых и крупных предприятий.
Центры обработки данных Kamatera расположены в Америке, Европе, Азии и на Ближнем Востоке. Инфраструктуру приложений можно легко расширить, добавив подсистему балансировки нагрузки, хранилище, сетевой брандмауэр и частные сети. Она может масштабироваться до большего количества серверов за считанные секунды и обеспечивает гарантированное время безотказной работы в 99,95%.
Он предоставляет 30-дневный бесплатный пробный период, который можно использовать в качестве демонстрации для тестирования производительности. А после можно выбрать подходящий тарифный план, цены на которых начинаются с 4 долларов в месяц.
3. A2 Hosting
A2 Хостинг популярен для WordPress, Joomla, Magento, Drupal и т.д. Но знаете ли вы, вы также можете получить хостинг MongoDB?
Ну, теперь знаете.
A2 предлагает множество удобных для разработчиков и ориентированных на производительность функций. Наряду с MongoDB можно разместить и другие базы данных, такие как MariaDB и SQLite.
4. ScaleGrid
ScaleGrid - это полностью управляемое решение DBaaS (Database as-a-service). Поддерживает различные платформы баз данных, включая PostgreSQL, MySQL, Redis и MongoDB.
На выбор предлагается два варианта.
Вы можете либо мигрировать свое уже существующую облачную инфраструктуру, как AWS, DigireOcean, Azure или же завести тут выделенное облако. Они также предлагают локальное управление базами данных для предприятия. При заказе сервера можно выбрать автономный или с набором реплик.
5. Scalingo
Scalingo полностью управляется и обеспечивает готовую к производству среду для MongoDB.
Он предоставляет кластер MongoDB по запросу. Начальная цена базового пакета составляет $3,6, что дает нам 256MB ОЗУ и 1.25GB емкость хранения.
В Scalingo экземпляр MongoDB будет находиться в контейнере Docker, поэтому он будет изолирован от других экземпляров, работающих на сервере. Вы получаете метрики и логи в реальном времени, которые могут помочь в устранении неполадок и планировании емкости.
6. ObjectRocket
ObjectRocket решает проблемы масштабируемости и производительности, которые возникали до сих пор у экспертов по базам данных благодаря неограниченному доступу к DBA MongoDB и Fanatical Support. Он отслеживает более 250 метрик в минуту на каждом экземпляре базы данных и предпринимает действия для поддержания оптимальной производительности среды.
Особенности:
Мониторинг и оповещения
Миграция базы данных
Балансировка экземпляра
Масштабирование ресурсов и управление ими
Масштабирование и анализ запросов
Проектирование схемы MongoDB
Консультации по архитектуре и проектированию
Аудит базы данных производственного уровня
Белый список SSL и IP
7. IBM
IBM Cloud предлагает гибридную облачную платформу следующего поколения с возможностями BigData и AI. Он имеет множество функций, таких как масштабирование без сервера и автоматическое резервное копирование.
С помощью IBM Cloud разработчики могут сосредоточиться на создании приложений, а не на решении таких задач инфраструктуры, как безотказность, резервное копирование, ведение журналов, мониторинг, масштабирование и исправление программного обеспечения. Полностью управляемая база данных IBM MongoDB обеспечивает готовую интеграцию с IBM Identity and Access Management и IBM Activity Tracker для расширенного контроля доступа и аудита.
Заключение
Надеюсь, приведенный выше список дал лучшее представление о хостинг-платформе MongoDb. Почти каждая платформа предлагает пробную версию, поэтому стоит попробовать и посмотреть, что больше подходит под ваши требования.