По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Многим организациям необходимо предоставлять и поддерживать большое количество удаленных офисов.
Например:
Розничные сети могут иметь сотни или даже тысячи магазинов по всему миру.
Региональный банк может иметь сотни отделений и тысячи банкоматов.
Когда поставщики услуг фиксированной частной телефонной связи предлагали свои услуги в любом масштабе, такого рода проблемы решались с помощью large-scale и hub-and-spoke сетей. На рисунке показана hub-and-spoke сеть.
Сеть, показанная на рисунке выше, на самом деле довольно мала: три узла в центре удаленных сайтов могут представлять сотни или тысячи дополнительных узлов. Во многих реализациях (особенно старых) каналы связи между двумя маршрутизаторами-концентраторами, A и B, и удаленными устройствами, такими как C и N, являются двухточечными. Это означает, что на концентраторе-маршрутизаторе должен быть настроен интерфейс для каждого удаленного маршрутизатора, фильтры маршрутизации, фильтры пакетов и любые конфигурации Quality of Service. Это не только серьезная проблема с точки зрения конфигурации, но также трудно поддерживать тысячи отдельных соседей с точки зрения использования процессора и памяти.
Чтобы уменьшить объем вычислительной мощности, необходимой для обслуживания такой сети, протоколы были изменены, чтобы исключить обработку удаленных узлов, как если бы они были частью дерева. Вместо этого, эти модификации позволили рассматривать эти удаленные узлы, как если бы они были выходными или тупиковыми сетями. Еще одним шагом на пути к упрощению создания таких сетей и управления ими было использование интерфейса point-to-multipoint (с соответствующей базовой технологией, такой как Frame Relay) на концентраторах-маршрутизаторах. Когда соединения с удаленными узлами настроены как point-to-multipoint, концентраторы-маршрутизаторы A и B обрабатывают все периферийные устройства так, как если бы они находились в одном сегменте широковещательной передачи (фактически, как сегмент Ethernet). Однако каждый spoke маршрутизатор по-прежнему рассматривает свое соединение с маршрутизаторами-концентраторами как соединение point-to-point. Даже с этими модификациями создание и обслуживание таких больших сетей все еще очень сложно. Необходимо проложить каналы на каждый удаленный узел и управлять ими, необходимо настроить удаленное оборудование и управлять им, необходимо управлять конфигурацией маршрутизаторов-концентраторов и т. д.
Программно-определяемые глобальные сети (SD-WAN) изначально были разработаны для решения этой конкретной задачи. Идея DMVPN, зародившаяся в Dynamic Multipoint Virtual Private Network (DMVPN) от Cisco, заключалась в использовании туннелируемой оверлейной сети, работающей поверх общедоступного Интернета. Это позволило удаленным узлам использовать локально доступное подключение к Интернету, а не покупать канал для каждого узла, а также сократить время настройки и обслуживания за счет автоконфигурации и других инструментов.
SD-WAN - это еще один шаг вперед в концепции сети over-the-top. Решение SDWAN обычно строится с использованием нескольких компонентов:
Специализированное устройство или виртуализированная служба для замены маршрутизаторов, обычно размещаемых в центральных и оконечных точках.
Модифицированная версия стандартного протокола маршрутизации для обеспечения доступности (и, возможно, одного из показателей жизнеспособности цепи) и передачи политик по сети.
Реализация либо IP-безопасности (IPsec), либо безопасности транспортного уровня (TLS) для обеспечения безопасной туннельной передачи между оконечными устройствами.
Контроллер для мониторинга состояния каждого виртуального канала, приложений, использующих канал, и количества полезной пропускной способности по сравнению с объемом трафика, а также для динамической корректировки потока трафика и параметров QoS для оптимизации работы приложений в over-the-top сети виртуальной сети.
Есть много разных способов реализации SD-WAN, например:
SD-WAN может заменить "последнюю милю". Вместо того чтобы устанавливать схему на каждом удаленном узле, вы можете использовать решения SD-WAN для достижения точки обмена или коллокации, а затем передавать трафик через более традиционную службу через провайдера обратно к маршрутизаторам-концентраторам (это форма backhaul).
SD-WAN может заменить весь путь от сети организации до удаленных узлов.
SD-WAN можно использовать для привлечения трафика в облачную службу, где может быть выполнена некоторая предварительная обработка или развернуты некоторые приложения, причем только трафик, который должен быть перенесен в сеть организации, переносится остальная часть пути в маршрутизаторы-концентраторы.
Существуют компромиссы с SD-WAN и другими передовыми решениями, как и с любой другой сетевой технологией. Например, передача трафика корпоративного удаленного узла через "обычное" публичное интернет-соединение (или пару услуг, или какую-то другую услугу, завершенную Ethernet) может быть "достаточно хорошей" в некоторых ситуациях, но провайдеры, как правило, лучше относятся к трафику в более дорогих услугах (что вполне естественно), особенно при отключениях.
Привет! Сегодня в статье мы покажем, как собирать трейсы с Cisco Unified Communications Manager (CUCM) . Это используется для траблшутинга системы, а так же эта информация будет необходима TAC инженерам Cisco при заведении заявки.
Для того чтобы снять трейсы нам понадобится программа Real-Time Monitoring Tool. О том как ее установить можно прочитать в нашей статье.
Сначала идем в меню Cisco Unified Serviceability, и переходим во вкладку Trace → Configuration. Здесь выбираем наш сервер, в строке Server, в строке Service Group выбираем CM Services, а в строке Service указываем Cisco CallManager. Дефолтные настройки показаны на скриншоте.
Убедитесь, что галочка стоит в пункте Trace On, а в выпадающем меню Debug Trace Level выбран пункт Detailed.
Тоже самое нужно повторить на других серверах кластера, если они имеются.
Далее запускаем RTMT и подключаемся к нашему серверу. Тут переходим во вкладку System → Tools → Trace & Log Central. Нажимаем Collect Files и в открывшемся окне ставим галочки в строке Cisco CallManager выбрав необходимые сервера.
Нажимаем Next и в следующем окне ставим галочки в пунктах Event Viewer → Application Log и Event Viewer → System Log.
Далее необходимо выбрать временной промежуток снятия наших данных в поле Collection Time. В этом же окне, в поле Download File Options указываем папку, в которою все будет скачиваться.
Теперь можно нажать Finish и после сбора информации нужные нам файлы окажутся в указанной ранее папке.
Порой при попытке подключения к БД в режиме SQL аутентификации, вы можете получить следующую ошибку:
A connection was successfully established with the server but then an error occurred during login process. (Provider: Shared Memory Provider, error: 0 – No process is on the end of the pipe.) (Microsoft SQL Server, Error: 233).
У нас есть пару способов, которые могут помочь в решение этой проблемы.
Включить TCP/IP стек
По умолчанию, SQL сервер использует порт 1433, которые использует в качестве транспорта TCP. Нам нужно включить TCP/IP в настройках Configuration Manager:
Подключитесь к SQL серверу;
Откройте SQL Server Configuration Manager. Перейдите в настройку SQL Server Network Configuration → Protocols for %название%;
Проверяем, чтобы TCP/IP был включен (Enabled). Если выключен, то дважды левой кнопкой мыши нажмите на опцию и выберите Enabled = Yes;
После указанного вида работ службу (сервис) SQL необходимо перезагрузить.
Named Pipes
Так называемый Named Pipes (именованный канал) обеспечивает взаимодействие между процессами на одной машине, без снижения производительности. Эту опцию нужно включить, если вы столкнулись с 233 ошибкой:
Подключитесь к SQL серверу;
Откройте SQL Server Configuration Manager. Перейдите в настройку SQL Server Network Configuration → Protocols for %название%;
Проверяем, чтобы Named Pipes был включен (Enabled). Если выключен, то дважды левой кнопкой мыши нажмите на опцию и выберите Enabled = Yes;
Данная опция соседствует с параметром TCP/IP, который мы включали ранее (см. скриншот выше).
Гре***ый фаеравол!
На самом деле, фаервол это хорошо. Он защищает от атак наши системы. Но порой, из – за него у нас не работают нужные компоненты, и, в том числе, появляется ошибка 233.
Добавим 1433 порт в исключения. Для этого:
Запустить службу WF.msc (открыв меню Пуск и набрав в поиске);
В настройка Windows Firewall with Advanced Security, слева, нажмите на Inbound Rules, после чего нажмите на New Rule в открывшемся меню справа;
В Rule Type выбираем Port, нажимаем Next;
В разделе Protocol and Ports, укажите TCP. В пункте Specific local ports указываем 1433. Нажмите Next;
В разделе Action (действия, что делать?), выбираем Allow the connection, и нажимаем Next;
В разделе Profile применяем политику для всех видов (Domain, Private, Public). Важно! - настройка данного пункта зависит от ваших корпоративных политик безопасности и мы не рекомендуем открывать Public;
В финальном окне даем имя нашему правилу, например, Allow inbound SQL;
Проверяем удаленные подключения
Важно не забыть разрешить удаленные подключения к серверу. Сделать это не трудно:
Открываем SQL Server Management Studio и подключаемся (доменная или SQL аутентификация);
Выбираем сервер (верхняя сущность в иерархии слева, в меню), нажимаем на него правой кнопкой мыши и выбираем пункт Properties;
В открывшемся окне нажимаем на Connections. В меню настройки нажимаем на чекбокс Allow remote connections to this server;
Нажимаем OK;
Перезагружаем сервис SQL, проверяем, пропала ли ошибка? :)