пїЅпїЅпїЅ-пїЅпїЅпїЅпїЅпїЅпїЅ
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сегодня мы обсудим разницу между технологией VPLS и MPLS, хотя оба эти метода используются для подключения клиентских сетей по всему миру. VPLS – сервисы виртуальной частной службы локальной сети и MPLS- мульти протокол с меткой переключения.
VPLS vs. MPLS
VPLS — это многоточечное подключение на основе технологии ETHERNET IP-сетей или оно может быть выполнено по сетям MPLS. VPLS — это один из способов подключения сетей, которые могут быть point to point или point to multipoint, или может быть тип подключения по IP-сетям multipoint to multipoint.
Рис. 1 Базовая архитектура VPLS
Если вы проанализируете подключение VPLS, то это подключение основано на технологии ETHERNET между сетями. Это означает, что подключение между сетями осуществляется на уровне L2. Все службы в VPLS, по-видимому, находятся в одном и том же сегменте локальной сети. VPLS использует пограничные маршрутизаторы, которые могут обучаться, соединяться и реплицироваться на основе VPN. Эти маршрутизаторы соединены полно связной сетью туннелей, что позволяет подключаться к любому каналу связи.
С другой стороны, MPLS — это метод (это может быть L2 или L3) для подключения сетей по всему миру. В случае MPLS маршрутизация на границе (используемый протокол маршрутизации WAN-главным образом BGP, для подключения связи маршрутизатора PE-CE) и коммутация или маркировка используются в ядре. Таким образом, имеется в виду, что связь между PE-CE осуществляется через протокол маршрутизации (в случае, если используются сервисы MPLS L3), а PE-PE использует коммутацию меток внутри ядра (подключение MPLS L2 или L3). В случае услуг MPLS L2 технология, используемая между PE-CE, может быть Frame-Relay, ATM или любым другим соединением L2.
Рис. 2 Подключение MPLS
Таким образом, тег MPLS находится между L2 и L3 в модели OSI. Правильно говорят, что MPLS — это технология, а VPLS — это сервис, который использует технологию MPLS для подключения в качестве базовой службы. MPLS использует путевую карту и качество обслуживания с высокой доступностью.
Краткое описание разницы:
MPLS — это технология, в то время как VPLS — это сервис на вершине IP-сети или MPLS.
VPLS — это соединение L2 между сетями, в то время как MPLS — это технология внутри поставщика услуг, и пользовательское соединение может быть L3 или L2 в зависимости от требования.
VPLS использует интерфейсы ETHERNET для подключения между сетями, в то время как MPLS может быть запущен с любым типом интерфейсов
С помощью MPLS вы можете иметь путевую карту и качество обслуживания, VPLS не может использовать путевую карту.
VPLS обычно используется в промышленности, где клиент хочет, чтобы информация L2 передавалась по IP-сетям, в то время как MPLS может использоваться в обоих случаях, когда информация L2 или L3 может передаваться по сети MPLS.
VPLS может быть point to point или multipoint соединением VPLS, в то время как MPLS является полностью сетчатой технологией и может использоваться для обмена информацией между сетями на основе требований заказчика (использование RT на месте для импорта и экспорта маршрутов с конкретными PE-маршрутизаторами)
VPLS использует методы мостового соединения IEEE 802.1 q Ethernet, а ядро MPLS будет использовать полную сетку PW и переадресацию «split-horizon».
В Cisco Unified Communications Manager (CUCM) существует разделение по интерфейсам администратора – каждый из них отвечает за свою область настроек.
В CUCM есть следующие интерфейсы:
Cisco Unified CM Administration (https://[IP_сервера]/ccmadmin);
Cisco Unified Serviceability (https://[IP_сервера]/ccmservice);
Cisco Unified OS Administration (https://[IP_сервера]/cmplatform);
Cisco Unified Reporting (https://[IP_сервера]/ccmservice);
Cisco Unified IM and Presence Reporting (https://[IP_сервера]/cucreports);
Disaster Recovery System (https://[IP_сервера]/drf);
Command Line Interface (CLI);
К каждому из них можно подключиться только по HTTPS (кроме интерфейса командной строки CLI, для него используется SSH), а переключаться между интерфейсами можно через выпадающее меню в правой верхней части экрана.
Логин и пароль администратора платформы, которые задаются при установке (administrator id) используется для доступа в DRS и OS Administration. Также при установке задаются логин и пароль (application user) для входа в CM Administration, Serviceability и Cisco Unified Reporting.
Рассмотрим подробнее эти интерфейсы и что в них включено. Стоит заметить что наличие того или иного пункта в меню зависит от версии CUCM.
Интерфейс Cisco Unified Communications Manager Administration
Меню System: включает в себя конфигурирование групп CM, Presence и Device Mobility, настройку Device Pool, Region, Locations, Survivable Site Telephony (SRST), DHCP, LDAP, сервисных параметров, а также лицензирование;
Меню Call Routing: здесь находятся разделы, отвечающие за маршрутизацию звонков, паттерны, интерком, Dial Rules, меню Class of Control, включающее Calling Search Space и Partitions, а также такие функции как Call Pickup, Call Park и другие;
Меню Media Resources: в этом меню расположены настройки таких ресурсов, как Music on Hold (MOH), Annunciator, Transcoder, Media Termination Point (MTP), а также файловый менеджер MOH;
Меню Advanced Features: тут можно найти настройки Voicemail интеграций, Inter-Company Media Engine Configuration и VPN;
Меню Device: настройка IP-телефонов, шлюзов, гейткиперов, транков, профилей телефонов, функциональных кнопок и многое другое;
Меню Application: содержит мастер конфигурации CUCM и меню настройки плагинов;
Меню User Management: настройка пользователей End User, Application User, User Group и ролей;
Меню Bulk Administration: предоставляет множество возможностей для выполнения повторяющихся задач настройки (например, добавления большого числа пользователей или телефонов) автоматическим способом;
Меню Help: тут собранны полезные статьи о работе в CUCM;
Интерфейс Cisco Unified Serviceability Administration
Меню Alarm: тут находятся конфигурационные опции для системных предупреждений для мониторинга производительности и общего состояния системы;
Меню Trace: настройки трекинга для мониторинга системы и поиска проблем;
Меню Tools: здесь в подменю CDR Analysis and Reporting предоставляет интерфейс для сбора журналов вызовов и отчетов о вызовах, выполненных с использованием системы. Раздел Service Activation предоставляет интерфейс для активации сервисов, установленных в первый раз. Используя этот интерфейс, администраторы могут останавливать, запускать или перезапускать активированные службы. Архив отчетов Serviceability Reports обеспечивает доступ к интерфейсу отчетов для анализа системы. Интерфейс управления CDR позволяет администраторам настраивать и проверять использование дискового пространства для Call Detail Report (CDR). Страница Audit Log Configuration содержит параметры для того, что будет включено в журналы аудита;
Меню SNMP: тут расположены подменю (V1/V2c, V3 и SystemGroup) конфигурации протокола Simple Network Management Protocol (SNMP);
Меню Help: здесь также расположены материалы о CUCM;
Интерфейс Cisco Unified Operating System Administration
Этот интерфейс позволяет администратору следить и взаимодействовать с платформой операционной системы на базе Linux. Административные задачи, которые могут быть выполнены здесь, включают в себя:
Мониторинг использования аппаратного ресурса (центральный процессор, дисковое пространство);
Проверка и обновление версий программного обеспечения;
Проверка и изменение информации об IP-адресе;
Управление IP адресом протокола Network Time Protocol (NTP);
Управление безопасностью сервера, включая IPsec и цифровые сертификаты;
Создание учетной записи удаленной помощи TAC;
Ping других IP-устройств;
Интерфейс Disaster Recovery System
Система аварийного восстановления (DRS) обеспечивает резервное копирование (с планировщиком) и возможность восстановления. Доступ к этому интерфейсу использует учетная запись администрирования платформы, определенная при установке (также как и интерфейс Cisco Unified Operating System Administration). Дополнительные учетные записи могут быть созданы для доступа других лиц.
Резервные копии должны быть записаны на сетевой SFTP-сервер. Планировщик предоставляется для автоматического резервного копирования или может быть выбран немедленный запуск копирования. Также может выполняться резервное копирование отдельного сервера или полного кластера.
Интерфейс Cisco Unified Reporting
Cisco Unified Reporting предоставляет упрощенный метод доступа к системным отчетам. Эти отчеты собирают информацию из существующих журналов и форматируют данные в простые, полезные отчеты с одним щелчком мыши. Данные собираются из журналов через кластер (Publisher и Subscribers), чтобы предоставить обобщенную информацию и выделить проблемы или нарушения, которые могут повлиять на работу кластера. Интерфейс также предупреждает, что запуск конкретного отчета может неблагоприятно повлиять на работу сервера и повлиять на производительность или занять много времени.
Command Line Interface
К CLI обычно получают доступ с использованием SSH, хотя можно напрямую подключить клавиатуру и монитор. Изначально единственной учетной записью, которая может войти в систему с использованием CLI, является учетная запись администрирования платформы, определенная во время установки, хотя для доступа можно создать дополнительные учетные записи.
Команды и функциональные возможности CLI включают все те, которые находятся в интерфейсе OS Administration, плюс следующие (но это далеко не полный список):
Выключение или перезагрузка системы;
Изменение версий после обновления;
Запуск, остановка и перезапуск служб;
Изменение сетевых настроек (IP-адрес, маска, шлюз и так далее.);
Использование сетевых инструментов, таких как ping, traceroute и захват пакетов;
Использование DRS (резервное копирование и восстановление);
Добавление и изменение учетных записей администратора;
Отображение нагрузки на сервер и информации о процессах;
Проверка состояния сервера, включая версии программного обеспечения, процессор, память и использование диска, аппаратную платформу, серийные номера и так далее;
Пожалуй, каждый разработчик хочет, чтобы его код был структурированным, несложно запрограммированным и хорошо закомментированным. Есть даже огромное количество шаблонов проектирования, которые представляют собой четкие правила, которым нужно следовать, и структуру, которую нужно учитывать.
Но мы по-прежнему можем найти в программном обеспечении, так называемые, анти-шаблоны. Особенно это касается ПО, которое было написано довольно давно или второпях.
Безобидный самый примитивный прием для быстрого решения какой-то проблемы может стать обычно практикой в вашей кодовой базе. Вы можете начать его копировать в разные места и превратить ваш код в анти-шаблон, который вам придется потом исправлять.
Что же такое анти-шаблон?
Анти-шаблон – это термин, который описывает, как НЕ НАДО решать периодически возникающие в вашем коде проблемы. Анти-шаблоны - это не самый лучший вариант архитектуры программного обеспечения, и, как правило, это неэффективные и мало кому понятные исправления.
В большинстве случаев они также приписывают вам «технический долг», то есть в будущем вам придется вернуться и исправить этот код.
В этой статье мы обсудим шесть анти-шаблонов:
Spaghetti Code
,
Golden Hammer
,
Boat Anchor
,
Dead Code
,
Proliferation of Code
и
God Object
.
Спагетти-код (Spaghetti Code)
Спагетти-код
– это самый известный анти-шаблон. Это код, в котором структура просто отсутствует.
Никакой модульной организации. Случайные файлы разбросаны по случайным каталогам. Трудно уследить за всем потоком, поскольку все запутано капитально (прям как спагетти).
Как правило, такая проблема возникает у тех, кто не продумал заранее программный поток или у тех, кто только начал программировать.
Что здесь происходит? Я не могу ничего понять
Это полный кошмар не только для тех, кто будет сопровождать этот код, но и для тех, кто захочет добавить в него новые функции.
У вас постоянно будет что-то «ломаться», вы не будете понимать масштаб ваших изменений и не сможете дать какую-то более или менее точную оценку вашей работы, поскольку, когда выполняется вот эта вакханалия, крайне сложно предвидеть, какая из бесчисленного множества проблем может возникнуть.
Золотой молоток (Golden Hammer)
«Тот, у кого из всех орудий есть только молоток, склонен на любую проблему смотреть, как на гвоздь», - Аврахам Маслоу.
Представьте вот такую ситуацию: ваша команда разработчиков очень хорошо знает архитектуру Hammer (молоток) и активно ее использует. Это фантастически сработало в ваших прошлых проектах. И вот, вы становитесь ведущей в мире командой, которая использует эту архитектуру.
Но теперь тем или иным образом у вас все сводится к этой архитектуре. Винт с плоской головкой? Молоток. Винт с крестообразным шлицем? Молоток. Вам нужен шестигранный ключ? Нет, не надо, молоток же есть.
Вы начинаете применять один и тот же архитектурный подход к задачам, для которых он
едва
ли подходит (но работу свою все же выполняет). Вы чрезмерно полагаетесь на один шаблон и забываете о том, что для того, чтобы выполнять свою работу на высоком уровне, вам нужно больше.
В конце концов, вы можете нанести серьезный удар по производительности вашей программы. А все потому, что ваши действия похожи на то, как будто вы пытаетесь найти квадратуру круга. При этом вы знаете, что, если будете использовать эту архитектуру для этой задачи, это займет у вас в два раза больше времени, но вам так
проще
и удобнее.
К тому же, такой подход не очень предсказуем. У разных языков есть общие решения каких-то задач, с которыми они сталкиваются, а также свои собственные стандарты. Поэтому вы не можете применять любое правило, которое сработало для одного языка, к другому без каких-либо проблем.
Не закрывайте глаза на тот факт, что нужно постоянно чему-то учиться. Подберите для вашей задачи подходящий язык. Продумайте архитектуру и выйдите из своей зоны комфорта. Находите и изучайте новые инструменты и способы решения задач, с которыми вы сталкиваетесь.
Лодочный якорь (Boat Anchor)
Вы можете наблюдать анти-шаблон
Boat Anchor
, когда программисты оставляют код в кодовой базе на случай
«а вдруг
он еще понадобиться»
.
Они написали что-то, что не очень соответствует техническим условиям. Соответственно, им эту не нужно, но они считают, что это может пригодиться через пару месяцев, поэтому не удаляют. Они отправляют его в производство, а позже, когда он им понадобиться, они смогут быстро ввести в работу.
Но сопровождать кодовую базу, в которой содержится весь этот неактуальный код, будет непросто. Основная проблема заключается в том, что их коллегам будет сложно определить, какой код не используется и, соответственно, не поменяет ход работы, а какой, наоборот, используется.
Представьте такую ситуацию: вы исправляете ошибки и отчаянно пытаетесь выяснить, что в API отвечает за отправку данных карты клиента для вывода средств из банка. Вы можете сидеть и тратить время на прочтение и отладку неактуального кода и при этом даже не осознавать, что вы не там ищете.
И последняя проблема: неактуальный код увеличивает время сборки, и вы можете перепутать рабочий и нерабочий код. Вы даже можете по невнимательности «запустить» его в производство.
Я думаю, теперь вы понимаете, почему этот анти-шаблон называется «лодочным якорем», - он слишком тяжелый, чтобы носить его с собой (приписывает вам «технический долг»), и при этом он ничего не делает (без преувеличений, он бесполезен).
Мертвый код
Вы когда-нибудь сталкивались с такой ситуацией, когда смотрели на код, который написал кто-то, кто уже не работает в вашей компании, и не знали, что с ним делать? Есть функция, которая вроде бы ничего не делает. Но она везде вызывается! Вы спрашиваете других людей, но никто ничего о ней не знает. И при этом все бояться ее удалить.
Иногда вы можете понимать, что она делает, но нет какого-то контекста. Вы способны прочитать и разобрать, что этот поток выполняет, но для чего? Но, похоже, нам это больше не нужно, поскольку для всех пользователей ответ всегда один и тот же.
Это, как правило, называют анти-шаблоном Dead Code. Это когда спустя года 3 вы уже не можете понять, какой конкретно код вам нужен для того, чтобы успешно выполнить поток и программу в целом.
Этот анти-шаблон может очень часто встречаться при проверке концептуального кода или кода для научных вычислений, которые каким-то образом оказались в производстве.
Однажды я встретил парня, у которого была аналогичная проблема. В его кодовой базе было огромное количество кода, которое, как он знал, являлся «мертвым», и такое же количество – как он подозревал. Но при этом он не мог получить разрешение о руководства на то, чтобы удалить весь этот мертвый код.
Он начал комментировать и «отключать» какие-то фрагменты кода, чтобы посмотреть, что на самом деле «раздувает» кодовую базу. Он назвал такой подход
Monkey Testing
. Осторожно! Это может быть слишком рискованно!
Если такой подход тестирования производственного приложения вам не очень нравится, то можете попытаться преподнести руководству «технический долг» как «технический риск». Это должно помочь вам объяснить, почему так важно «наводить порядок» в коде.
Или даже так: запишите все, что вы хотите изменить в вашем конкретном модуле/разделе, и итеративно по частям удаляйте мертвый код. Не забывайте проверять программу на работоспособность после каждого такого удаления, чтобы ничего не «сломать».
Вам не нужно бросать идею масштабной переделки кода с тысячами изменений. Вы лишь поймете, почему это так важно, и задокументируете это или, как вы и хотели, удалите мертвый код.
Ненужное усложнение кода (Proliferation of Code)
Объекты и модули постоянно взаимодействуют друг с другом. Если у вас чистая кодовая база с модульной организацией, то вам довольно часто придется обращаться к другим отдельным модулям и вызывать новые функции.
Проблема анти-шаблона Proliferaion of Code возникает, когда в вашей кодовой базе есть объекты, которые нужны только для того, чтобы вызывать какой-то другой более важный объект. По сути он является просто посредником.
Это лишь добавляет ненужный уровень абстракции (добавляет что-то, что вы должны запомнить). В принципе, все это бесполезно и лишь может сбить с толку людей, которые хотят понять, как работает ваша программа.
В данном случае самое просто решение - просто удалить этот объект. Передайте обязанность вызывать объект, который вам нужно, непосредственно вызываемому объекту.
Всемогущий объект
Если вам нужно обеспечить доступ к одному объекту по всей кодовой базе, то вы можете создать Всемогущий объект.
Всемогущий объект отвечает за
слишком
многое: за идентификатор пользователя, идентификатор транзакции, имя и фамилию клиента, общую сумму транзакции, товары, которые покупает пользователь… ну вы поняли.
Иногда его называют анти-шаблоном
Swiss Army Knife
(Швейцарский армейский нож). Дело в том, что такой нож предназначен для того, что резать веревку, но при этом его также можно использовать в качестве пилки для ногтей, пилы, пинцета, ножниц, открывашки для бутылок и штопора.
В таком случае вам лучше разделить код на модули.
Программисты часто шутят на эту тему: ты попросил банан, а тебе дали гориллу, которая держит банан. Вы получили то, что хотели, но намного больше, чем вам было нужно.
Принципы SOLID недвусмысленно затрагивают эту тему в объектно-ориентированных языках. Все это нужно для того, чтобы вы могли создать лучшую модель своего ПО.
Буква S в этой аббревиатуре обозначает «Single Responsibility», то есть «Единственную ответственность». Каждый класс/модуль/функция должны нести ответственность только за одну часть системы, а не за несколько.
Вы часто могли встречать эту проблему, а что насчет интерфейса ниже?
interface Animal {
numOfLegs: string;
weight: number;
engine: string;
model: string;
sound: string;
claws: boolean;
wingspan: string;
customerId: string;
}
Пробегите глазами этот интерфейс. Можете ли вы сразу сказать, что на нем лежит слишком большая ответственность и что нужно перестроить код?
А как насчет этого?
interface Animal {
numOfLegs: string;
weight: number;
sound: string;
claws: boolean;
}
interface Car {
engine: string;
model: string;
}
interface Bird {
wingspan: string;
}
interface Transaction {
customerId: string;
}
Если вы разделите этот интерфейс на несколько, то ваш код сможет четко понимать, какой интерфейс за что отвечает, и ему не нужно будет заставлять классы реализовывать всё (
engine, customerId, model
и т.д.), несмотря на то, что ему нужно только
wingspan
.
Заключение
Любая крупная компания поддерживает баланс между возвращением «технического долга», началом новой разработки и устранением целого списка ошибок в их продукте.
Я надеюсь, что, прочитав эту статью, вы поняли, как легко можно попасть в ловушку анти-шаблонов, а также узнали о некоторых способах, которые помогут вам оттуда выбраться.