По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Прежде чем приступить к изучению виртуальной локальной сети (VLAN), необходимо иметь определенное представление о локальной сети. Локальную сеть можно рассмотреть с двух сторон. С одной стороны, локальная сеть это все пользовательские устройства, серверы, коммутаторы, маршрутизаторы, кабели и точки беспроводного доступа, расположенные в одном месте. С другой стороны, в более узком понимании определения локальной сети, позволяет нам освоить концепцию виртуальной локальной сети: локальная сеть включает все устройства в одном широковещательном домене.
p>
Широковещательный домен это устройства, подключенные к локальной сети, таким образом, что, когда одно из устройств отправляет широковещательный кадр, все остальные устройства получают копию этого кадра. Таким образом, понятие локальной сети и широковещательного домена является практически одинаковым.
Коммутатор, с настройками по умолчанию, считает, что все его интерфейсы находятся в одном широковещательном домене. То есть, когда широковещательный кадр приходит на один конкретный порт коммутатора, устройство пересылает этот широковещательный кадр на все остальные свои порты. В связи с таким принципом работы коммутатора, чтобы создать два разных широковещательных домена, придется купить два разных коммутатора для локальной сети Ethernet, как показано на рисунке:
Показаны два домена: домен 1 (подсеть 1) и домен 2 (подсеть 2). В первом домене два компьютера, а именно ПК1 и ПК2, подключены к коммутатору SW1 для создания широковещательного домена 1. Аналогично, во втором домене два компьютера, а именно ПК3 и ПК4, подключены к коммутатору SW2 для создания широковещательного домена 2.
Используя два VLAN’а, можно организовать те же две сети, что изображены на рисунке 1- создать два широковещательных домена с помощью одного коммутатора. С VLAN’нами коммутатор может настроить некоторые интерфейсы в один широковещательный домен, а некоторые в другой, создавая несколько широковещательных доменов. Эти отдельные широковещательные домены, созданные коммутатором, называются виртуальными локальными сетями (VLAN).
Рисунок ниже демонстрирует использование одного коммутатора для создания двух VLAN’ов, рассматривая порты в каждом VLAN’е как полностью самостоятельные. Коммутатор никогда не перешлет кадр, отправленный ПК1 (VLAN 1) либо ПК3 либо ПК4 (VLAN 2).
Из рисунка мы видим, что используется один коммутатор для нескольких широковещательных доменов. Из широковещательного домена 1 (подсеть 1) две системы ПК1 и ПК2 подключены к коммутатору SW1. Из широковещательного домена 2 (подсеть 2) к коммутатору SW1 подключены две системы ПК3 и ПК4.
Проектирование локальных сетей кампуса с использованием большего количества VLAN’ов, в каждом из которых используется минимальное количество коммутационного оборудования, часто помогает улучшить локальную сеть во многих отношениях. Например, широковещательная передача, отправленная одним узлом во VLAN1, будет приниматься и обрабатываться всеми другими узлами этого VLAN1-но не узлами из другого VLAN. Чем меньше посторонних узлов в сети получают широковещательные кадры, тем выше безопасность локальной сети.
Это всего лишь несколько причин для разделения хостов на разные VLAN. В следующем списке перечислены наиболее распространенные причины, по которым следует создавать VLAN’ны:
Чтобы уменьшить нагрузку на процессор на каждом устройстве; повышение производительности узла, путем уменьшения числа устройств, которые принимают каждый широковещательный кадр;
Повысить уровень безопасности за счет уменьшения числа хостов, получающих копии кадров, которые коммутаторы отправляют (broadcasts, multicasts, and unknown unicasts);
Повышение безопасности хостов за счет применения различных политик безопасности для каждого VLAN;
Создание подразделений, группирующих пользователей по отделам или группам, которые работают вместе, а не по физическому местоположению;
Уменьшение нагрузки для протокола связующего дерева (STP) путем ограничения VLAN одним коммутатором доступа.
Cisco CUBE (Cisco Unified Border Element) - контролер граничных сессий (SBC) от компании Cisco. В статье мы поговорим о том, как настроить так называемый SIP Forking, который позволяет отправить SIP сигнализацию на несколько устройств сразу.
В примере мы покажем, как настроить SIP Forking на CUBE для записи видео – звонков, например, для последующего анализа системой записи.
Что мы имеем
Интегрированное приложение Cisco Unified Border Element (далее CUBE) является частью программного обеспечения маршрутизатора CISCO2911, параметры которого приведены ниже:
Cisco CISCO2911/K9 (revision 1.0) with 483328K/40960K bytes of memory.
Processor board ID ABCDEFAAAAA
3 Gigabit Ethernet interfaces
6 Serial interfaces
1 terminal line
2 Channelized E1/PRI ports
1 Virtual Private Network (VPN) Module
DRAM configuration is 64 bits wide with parity enabled.
255K bytes of non-volatile configuration memory.
32K bytes of USB token usbtoken0 (Read/Write)
255744K bytes of ATA System CompactFlash 0 (Read/Write)
Prerequisites
Перед началом нужно выполнить следующие условия:
маршрутизатор сконфигурирован в качестве CUBE;
версия Cisco IOS 15.2(1) или выше;
видео – звонок устанавливается по схеме SIP-to-SIP;
используется адресация версии IPv4;
ключевые составляющие вызова проходят через CUBE, включая SIP – сигнализацию и медиа - потоки;
в рамках устанавливаемого видео – вызова не происходит транскодирования с высокой нагрузкой;
не используется SRTP (Secure Real-time Transport Protocol);
Схема следующая:
Настройка
Для настройки CUBE необходимо подключится к серверу по протоколу Telnet и ввести следующие логин и пароль:
UserName: merionet
Password: ******
Переходим в режим конфигурации:
enable
configure terminal
У нас 192.168.0.2 – IP – адрес системы записи, а 192.168.0.3 - адрес CUCM. В разделе voice service voip, необходимо добавить IP – адрес системы записи и CUCM в список «доверенных» IP – адресов и указать прочие опции, как указано ниже:
voice service voip
ip address trusted list
ipv4 192.168.0.2 255.255.255.255
ipv4 192.168.0.3 255.255.255.255
address-hiding
mode border-element
media flow-around
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
asymmetric payload full
early-offer forced
midcall-signaling passthru
g729 annexb-all
video screening
Создаем media profile recorder, в котором необходимо указать тэг dial – peer, который смотрит в сторону системы записи. Помимо этого, необходимо создать профиль для записи видео с опциями, которые указаны ниже. Оба профиля записи указываются в настройке media class:
media profile recorder 100
media-recording 114
!
media profile video 455
monitor-ref-frames
h264-packetization-mode 0
ref-frame-req rtcp retransmit-interval 50 retransmit-count 4
ref-frame-req sip-info
!
media class 3
recorder profile 100
video profile 455
Теперь, на входящем и исходящем dial – peer указываем созданный ранее media class:
dial-peer voice 123 voip
destination-pattern 114
rtp payload-type cisco-codec-video-h264 112
session protocol sipv2
session target ipv4:192.168.0.2
voice-class sip options-keepalive
voice-class codec 1 offer-all
media-class 3
dtmf-relay rtp-nte
no vad
!
dial-peer voice 124 voip
destination-pattern 1402$ // маршрут в сторону PBX
rtp payload-type cisco-codec-video-h264 112
session protocol sipv2
session target ipv4:192.168.0.3
session transport tcp
voice-class codec 1 offer-all
voice-class sip options-keepalive up-interval 100 down-interval 50 retry 6
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
media-class 3
dtmf-relay rtp-nte
no vad
Сохраняем конфигурацию:
copy running-config startup-config
В программировании понятие «состояние» (state) относится к состоянию системы, компонента или приложения в какой-то определенный момент времени.
Приведем простой пример. Допустим, вы совершаете покупки на amazon.com, и будь то факт того, что вы вошли в данный момент на сайт, или есть ли какие-то товары в вашей корзине, это все является примерами состояния.
Состояние – это данные, которые хранятся и используются для отслеживания текущего статуса приложения. Именно понимание и управление состоянием играет решающую роль в создании интерактивных и динамических веб-приложений.
Понятие «состояние» относится к многим компонентам архитектуры. Шаблоны проектирования (например, REST или GraphQL), протоколы (например, HTTP и TCP), межсетевые экраны и функции могут как сохранять состояние, так и не делать этого. Однако основной принцип «состояния» (независимо от компонента, к которому оно привязывается) остается прежним.
В этой статье мы расскажем, что такое состояние. Кроме того, мы объясним, что такое stateful и stateless-архитектуры, а также их плюсы и минусы.
Что такое stateful-архитектура?
Представьте, что вы идете в пиццерию, чтобы пообедать. В этом ресторане работает только один официант, и он подробно записывает всю информацию о вас: номер вашего стола, ваш заказ, ваши предпочтения на основе предыдущих заказов (тип корочки, который вам нравится, или начинки, на которые у вас аллергия) и т.д.
Иллюстрация: официант принимает заказ в пиццерии
Вся информация, которую официант записывает в блокнот, и есть состояние клиента. Доступ к этой информации имеет только официант, который вас обслуживает. Если вы хотите внести какие-то изменения в свой заказ или проверить готовность заказа, вам нужно обратиться к тому же официанту. Ну и поскольку официант всего один, это не является проблемой.
А теперь представьте, что в ресторане стало больше посетителей. Вашему официанту приходится обслуживать и других гостей, поэтому на работу вызывают дополнительных официантов. И в данной ситуации вы хотите проверить статус вашего заказа и внести в него небольшое изменение – обычную корочку вместо сырной. А единственный официант, который может вас обслужить, - не тот, который принял ваш заказ.
Иллюстрация: другой официант не может изменить заказ клиента
У этого официанта нет информации о вашем заказе, то есть о вашем состоянии. И по понятным причинам он не сможет проверить статус вашего заказа или внести в него изменения. Ресторан, где сообщать о готовности заказа или вносить в него изменения могут только официанты, принявшие этот заказ, придерживается архитектуры с сохранением состояния (stateful).
Подобным образом stateful-приложение будет иметь сервер, который будет запоминать данные клиентов (то есть их состояния). Все будущие запросы будут перенаправляться через балансировщик нагрузки (придерживаясь при этом механизма «липких сессий» (Sticky Sessions)) на тот же сервер. Таким образом, сервер всегда будет знать все о клиенте.
На схеме ниже показаны два разных пользователя, и они оба хотят получить доступ к веб-серверу через балансировщик нагрузки. Так как состояние приложения сохраняется на сервере, пользователи при каждом запросе должны направляться на один и тот же сервер, чтобы сохранять состояние.
Схема: как работает stateful-приложение
Sticky sessions (липкие сессии) – это настройка, позволяющая балансировщику нагрузки раз за разом направлять запросы пользователя на один и тот же внутренний сервер на протяжении всей сессии. В этом и заключается ее отличие от обычной балансировки нагрузки, при которой запросы пользователя направляются на любой доступный сервер по циклическому алгоритму или по какому-то другому шаблону распределения нагрузки.
В чем же проблема stateful-архитектуры? Представьте себе ресторан, который работает таким образом. Несмотря на то, что это такой вариант может оказаться вполне идеальным и простым в реализации для небольшого семейного ресторана с небольшим количеством посетителей, его
нельзя назвать отказоустойчивым
и масштабируемым
.
Что будет, если у официанта, который принял у клиента заказ, возникнет ЧП и ему придется уйти? Вся информация по заказу так и останется у этого официанта. Это подрывает качество обслуживания клиентов, так как любой новый официант, который придет, чтобы заменить старого, не будет ничего знать о предыдущих заказах. Такая структура не является отказоустойчивой.
Кроме того, распределение запросов таким образом, что клиент может обращаться только к одному и тому же официанту, подразумевает, что нагрузка на официантов распределяется неравномерно. Кто-то будет завален заказами, особенно если он обслуживает какого-нибудь требовательного клиента, который постоянно меняет или добавляет что-то в свой заказ. А кому-то будет нечем заняться, и при этом они не смогут вмешиваться и помогать другим официантам. И опять-таки, такая структура не является масштабируемой.
Точно так же хранение данных о состоянии разных клиентов на разных серверах нельзя назвать отказоустойчивым и масштабируемым. Если произойдет сбой сервера, то все данные о состоянии будут утеряны. Так что, если пользователь вошел в систему и собирается оформить большой заказ, например, на amazon.com, ему придется снова пройти этап аутентификации, и при этом его корзина окажется пустой. Покупателю придётся снова входить в систему и заново заполнять корзину, и это явно испортит его впечатление от использования сайта.
Кроме того, добиться масштабируемости в час пик, например, в Черную пятницу, при использовании stateful-структуры будет не так просто. Структура будет автоматически масштабироваться, добавляя новые серверы, но, так как работает механизм «липких сессий», клиенты будут направляться на одни и те же серверы, что может привести к их перегрузке, что, в свою очередь, приведет к увеличению времени отклика, и это плохо скажется на взаимодействии с пользователем.
Многие из этих проблем может решить stateless-архитектура.
Что такое stateless-архитектура?
Stateless-архитектура – это термин, который в какой-то степени сбивает с толку, так как подразумевает, что система не фиксирует состояние. Но тем не менее такой тип архитектуры вовсе не означает, что информация о состоянии нигде не сохраняется. Это лишь значит, что информация о состоянии хранится вне сервера. Так что, понятие «stateless» может применяться только к серверу.
Вернемся к примеру с рестораном. В данном случае можно сказать, что официанты в этом ресторане имеют крайне плохую память. Они не помнят старых клиентов и тем более не помнят, что вы заказывали ранее и какая пицца вам нравится. Они просто принимают заказы клиентов в отдельной системе, скажем, на компьютере, к которому есть доступ у всех официантов. После чего они могут обратиться к компьютеру, чтобы получить более подробную информацию о заказе и внести в него необходимые изменения.
Иллюстрация: «забывчивый» официант принимает заказ, а затем обращается к компьютеру, чтобы получить больше информации о заказе
Сохраняя «состояние» заказа клиента в централизованной системе, которая доступна всем официантам, любой из них может обслужить любого клиента.
В рамках stateless-архитектуры HTTP-запросы от клиентов могут отправляться на любой из серверов.
Как правило, состояние хранится в отдельной базе данных, которая доступна для всех серверов. Таким образом, вы получаете отказоустойчивую и масштабируемую архитектуру, так как при необходимости вы можете удалять или добавлять серверы, не влияя при этом на данные о состоянии.
Кроме того, нагрузка будет равномерно распределяться по всем серверам, так как балансировщику нагрузки не нужно придерживаться схемы липких сессий для направления одних и тех же клиентов на одни и те же сервера.
На схеме ниже продемонстрированы два разных пользователя, которые пытаются получить доступ к веб-серверу через балансировщик нагрузки. Так как состояние приложения хранится отдельно от серверов, пользователи могут быть направлены на любой из них. После чего сервер запросит информацию о состоянии из внешней базы данных, которая доступна для всех серверов.
Иллюстрация: схема stateless-архитектуры
В большинстве случаев данные о состоянии хранятся в кэше, например, в Redis – внутреннем хранилище данных. В отличие от хранения на диске, хранение данных в оперативной памяти требует меньше времени на такие операции, как чтение и запись.
Объединяем все вместе
В этой статье описывается, как работают веб-приложения с сохранением и без сохранения состояния, а также их недостатки. Однако принципы stateful и stateless-архитектуры могут применяться не только к веб-приложениям.
Если мы в качестве примера посмотрим на сетевые протоколы, то увидим, что, например, HTTP – это протокол без сохранения состояния. Это значит, что каждый HTTP-запрос от клиента к серверу является
независимым
и
не содержит информации о предыдущих запросах
или их содержимом. Сервер обрабатывает каждый запрос как отдельную транзакцию и по определению не сохраняет информацию о состоянии клиента между запросами.
Состояние может храниться либо на серверах (stateful-архитектура), либо в отдельной базе данных вне серверов (stateless-архитектура). Сам по себе HTTP-протокол не сохраняет состояние.
В отличие от HTTP, который не сохраняет состояние, TCP-протокол устанавливает соединение и сохраняет состояние. Он устанавливает соединение между двумя устройствами (как правило, это клиент и сервер) и поддерживает непрерывный канал связи до тех пор, пока соединение не будет завершено.
Та же логика может применяться и к межсетевым экранам – они могут как сохранять состояние, так и не делать этого.
В AWS группа безопасности – это виртуальный брандмауэр, который контролирует входящий и исходящий трафик виртуальных машин или облачных экземпляров. Группы безопасности сохраняют состояние. Когда вы пропускаете определенный входящий трафик, соответствующий исходящий трафик пропускается автоматически. Иными словами, отслеживается состояние соединения.
Для управления входящим и исходящим трафиком в AWS на уровне подсети используются Списки управления сетевым доступом (NACL - Network Access Control Lists), которые не сохраняют состояние. Отсутствие фиксации состояния говорит о том, что вы должны явно определить правила как для входящего, так и для исходящего трафика.
В отличие от групп безопасности, где при пропуске входящего трафика исходящий трафик пропускается автоматически, NACL требуют определить отдельные правила для входящего и исходящего трафика.
Функции и шаблоны проектирования тоже могут сохранять или не сохранять состояние.
Основная идея, которая лежит в основе чего-то, что сохраняет состояние, заключается в том, что это что-то обладает идеальной памятью или знает все о предыдущих вызовах и запросах. А вот то, что не сохраняет состояние, ничего не запоминает и не обладает знаниями о предыдущих вызовах или запросах.
Надеюсь, что теперь вы стали лучше понимать, как работают stateful и stateless-приложения, и сможете решить, какой вариант вам больше подходит.