пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Несмотря на доступ к все более эффективному и мощному оборудованию, операции, выполняемые непосредственно на традиционных физических (или «чистых») серверах, неизбежно сталкиваются со значительными практическими ограничениями. Стоимость и сложность создания и запуска одного физического сервера говорят о том, что эффективное добавление и удаление ресурсов для быстрого удовлетворения меняющихся потребностей затруднено, а в некоторых случаях просто невозможно. Безопасное тестирование новых конфигураций или полных приложений перед их выпуском также может быть сложным, дорогостоящим и длительным процессом.
Исследователи-первопроходцы Джеральд Дж. Попек и Роберт П. Голдберг в статье 1974 года («Формальные требования к виртуализируемым архитектурам третьего поколения» (“Formal Requirements for Virtualizable Third Generation Architectures”) - Communications of the ACM 17 (7): 412–421) предполагали, что успешная виртуализация должна обеспечивать такую среду, которая:
Эквивалента физическому компьютеру, поэтому доступ программного обеспечения к аппаратным ресурсам и драйверам должен быть неотличим от невиртуализированного варианта.
Обеспечивает полный контроль клиента над аппаратным обеспечением виртуализированной системы.
По возможности эффективно выполняет операции непосредственно на базовых аппаратных ресурсах, включая ЦП.
Виртуализация позволяет разделить физические ресурсы вычислений, памяти, сети и хранилища («основополагающая четверка») между несколькими объектами. Каждое виртуальное устройство представлено в своем программном обеспечении и пользовательской среде как реальный автономный объект. Грамотно настроенные виртуальные изолированные ресурсы могут обеспечить более защиту приложений приложений без видимой связи между средами. Виртуализация также позволяет создавать и запускать новые виртуальные машины почти мгновенно, а затем удалять их, когда они перестанут быть необходимыми.
Для больших приложений, поддерживающих постоянно меняющиеся бизнес-требования, возможность быстрого вертикального масштабирования с повышением или понижением производительности может означать разницу между успехом и неудачей. Адаптивность, которую предлагает виртуализация, позволяет скриптам добавлять или удалять виртуальные машины за считанные секунды, а не недели, которые могут потребоваться для покупки, подготовки и развертывания физического сервера.
Как работает виртуализация?
В невиртуальных условиях, архитектуры х86 строго контролируют, какие процессы могут работать в каждом из четырех тщательно определенных уровней привилегий (начиная с Кольца 0 (Ring 0) по Кольцо 3).
Как правило, только ядро операционной системы хоста имеет какой-либо шанс получить доступ к инструкциям, хранящимся в кольце под номером 0. Однако, поскольку вы не можете предоставить нескольким виртуальным машинам, которые работают на одном физическом компьютере, равный доступ к кольцу 0, не вызывая больших проблем, необходим диспетчер виртуальных машин (или «гипервизор»), который бы эффективно перенаправлял запросы на такие ресурсы, как память и хранилище, на виртуализированные системы, эквивалентные им.
При работе в аппаратной среде без виртуализации SVM или VT-x все это выполняется с помощью процесса, известного как ловушка, эмуляция и двоичная трансляция. На виртуализированном оборудовании такие запросы, как правило, перехватываются гипервизором, адаптируются к виртуальной среде и возвращаются в виртуальную машину.
Простое добавление нового программного уровня для обеспечения такого уровня организации взаимодействия приведет к значительной задержке практически во всех аспектах производительности системы. Одним из успешных решений было решение ввести новый набор инструкций в ЦП, которые создают, так называемое, «кольцо 1», которое действует как кольцо 0 и позволяет гостевой ОС работать без какого-либо влияния на другие несвязанные операции.
На самом деле, при правильной реализации виртуализация позволяет большинству программных кодов работать как обычно, без каких-либо перехватов.
Несмотря на то, что эмуляция часто играет роль поддержки при развертывании виртуализации, она все же работает несколько иначе. В то время как виртуализация стремится разделить существующие аппаратные ресурсы между несколькими пользователями, эмуляция ставит перед собой цель заставить одну конкретную аппаратную/программную среду имитировать ту, которой на самом деле не существует, чтобы у пользователей была возможность запускать процессы, которые изначально было невозможно запустить. Для этого требуется программный код, который имитирует желаемую исходную аппаратную среду, чтобы обмануть ваше программное обеспечение, заставив его думать, что оно на самом деле работает где-то еще.
Эмуляция может быть относительно простой в реализации, но она почти всегда несет за собой значительные потери производительности.
Согласно сложившимся представлениям, существует два класса гипервизоров: Type-1 и Type-2.
Bare-metal гипервизоры (исполняемые на «голом железе») (Type-1), загружаются как операционная система машины и – иногда через основную привилегированную виртуальную машину – сохраняют полный контроль над аппаратным обеспечением хоста, запуская каждую гостевую ОС как системный процесс. XenServer и VMWare ESXi – яркие примеры современных гипервизоров Type-1. В последнее время использование термина «гипервизор» распространилось на все технологии виртуализации хостов, хотя раньше оно использовалось только для описания систем Type-1. Первоначально более общим термином, охватывающим все типы систем, был «Мониторы виртуальных машин». То, в какой степени люди используют термин «мониторы виртуальных машин» все это время, наводит меня на мысль, что они подразумевают «гипервизор» во всех его интерпретациях.
Гипервизоры, размещенные на виртуальном узле (Type-2) сами по себе являются просто процессами, работающими поверх обычного стека операционной системы. Гипервизоры Type-2 (включая VirtualBox и, в некотором роде, KVM) отделяют системные ресурсы хоста для гостевых операционных систем, создавая иллюзию частной аппаратной среды.
Виртуализация: паравиртуализация или аппаратная виртуализация
Виртуальные машины полностью виртуализированы. Иными словами, они думают, что они обычные развертывания операционной системы, которые живут собственной счастливой жизнью на собственном оборудовании. Поскольку им не нужно взаимодействовать со своей средой как-то иначе, чем с автономной ОС, то они могут работать с готовыми немодифицированными программными стеками. Однако раньше за такое сходство приходилось платить, потому что преобразование аппаратных сигналов через уровень эмуляции занимало дополнительное время и циклы.
В случае с паравиртуализацией (PV – Paravirtualization) паравиртуальные гости хотя бы частично осведомлены о своей виртуальной среде, в том числе и том, что они используют аппаратные ресурсы совместно с другими виртуальными машинами. Эта осведомленность означает, что хостам PV не нужно эмулировать хранилище и сетевое оборудование, и делает доступными эффективные драйверы ввода-вывода. На первых порах это позволяло гипервизорам PV достигать более высокой производительности для операций, требующих подключения к аппаратным компонентам.
Тем не менее, для того, чтобы предоставить гостевой доступ к виртуальному кольцу 0 (т.е. кольцу -1), современные аппаратные платформы – и, в частности, архитектура Intel Ivy Bridge – представили новую библиотеку наборов инструкций ЦП, которая позволила аппаратной виртуализации (HVM – Hardware Virtual Machine) обойти узкое место, связанное с ловушкой и эмуляцией, и в полной мере воспользоваться преимуществами аппаратных расширений и немодифицированных операций ядра программного обеспечения.
Также значительно повысить производительность виртуализации может последняя технология Intel – таблицы расширенных страниц (EPT – Extended Page Tables).
В связи с этим, в большинстве случаев можно обнаружить, что HVM обеспечивает более высокую производительность, переносимость и совместимость.
Аппаратная совместимость
Как минимум, несколько функций виртуализации требуют аппаратную поддержку, особенно со стороны ЦП хоста. Именно поэтому вы должны убедиться, что на вашем сервере есть все, что вам необходимо для задачи, которую вы собираетесь ему дать. Большая часть того, что вам нужно знать, храниться в файле /proc/cpuinfo и, в частности, в разделе «flags» (флаги) каждого процессора. Однако вам нужно знать, то искать, потому что флагов будет очень много.
Запустите эту команду, чтобы посмотреть, что у вас под капотом:
$ grep flags /proc/cpuinfo
Контейнерная виртуализация
Как мы уже видели ранее, виртуальная машина гипервизора – это полноценная операционная система, чья связь с аппаратными ресурсами «основополагающей четверки» полностью виртуализирована – она думает, что работает на собственном компьютере.
Гипервизор устанавливает виртуальную машину из того же ISO-образа, который вы загружаете и используете для установки операционной системы непосредственно на пустой физический жесткий диск.
Контейнер в свою очередь фактически представляет собой приложение, запускаемое из скриптообразного шаблона, которое считает себя операционной системой. В контейнерных технологиях, таких как LXC и Docker, контейнеры – это не что иное, как программные и ресурсные (файлы, процессы, пользователи) средства, которые зависят от ядра хоста и представления аппаратных ресурсов «основополагающей четверки» (т.е. ЦП, ОЗУ, сеть и хранилище) для всего, то они делают.
Конечно, с учетом того, что контейнеры фактически являются изолированными расширениями ядра хоста, виртуализация Windows (или более старых или новых версий Linux с несовместимыми версиями libc), например, на хосте Ubuntu 16.04 будет сложна или невозможна. Но эта технология обеспечивает невероятно простые и универсальные вычислительные возможности.
Перемещение
Модель виртуализации также позволяет использовать широкий спектр операций перемещения, копирования и клонирования даже из действующих систем (V2V). Поскольку программные ресурсы, определяющие виртуальную машину и управляющие ею, очень легко идентифицировать, то обычно не требуется очень много усилий для дублирования целых серверных сред в нескольких местах и для разных целей.
Иногда это не сложнее, чем создать архив виртуальной файловой системы на одном хосте, распаковать его на другом хосте по тому же пути, проверить основные сетевые настройки и запустить. Большинство платформ предлагают единую операцию командной строки для перемещения гостей между хостами.
Перемещение развертываний с физических серверов на виртуализированные среды (P2V) иногда может оказаться немного сложнее. Даже создание клонированного образа простого физического сервера и его импорт в пустую виртуальную машину может сопровождаться определенными трудностями. И как только все это будет выполнено, вам, возможно, придется внести некоторые корректировки в системную архитектуру, чтобы можно было использовать возможности, предлагаемые виртуализацией, в полную силу. В зависимости от операционной системы, которую вы перемещаете, вам также может потребоваться использование паравиртуализированных драйверов для того, чтобы ОС могла корректно работать в своем «новом доме».
Как и в любых других ситуациях управления сервером: тщательно все продумывайте заранее.
Давайте представим себе корпоративную сеть, где мобильная и офисная телефонная сеть слиты воедино, со всеми вытекающими плюсами – как компании могут сэкономить косты и запустить новые инициативы и приложения после интеграции их проводной IP – телефонии с сотовой сетью и беспроводной сетью.
Что такое конвергетная связь?
Практически у каждой компании есть система телефонии в том или ином виде – для внутренних и внешних коммуникаций. Большинство компаний используют систему IP – телефонии и IP – телефоны. Как примеры можно привести такие АТС как Cisco Unified Call Manager, Asterisk, FreeSWITCH и так далее. Все звонки идут через так называемые транки – провайдерские каналы связи, подключенные к АТС. Есть два типа транков – цифровые транки (такие как ISDN, PRI и так далее) и SIP – транки, или, как их ещё иногда называют (довольно редко) – IP – транки.
Мобильные сети также используются повседневно – сотрудникам выдаются корпоративные номера, которые они используют для рабочих звонков и сообщений и подключения к интернету вне офиса.
А представить себе компанию без Wi – Fi сети сейчас просто невозможно – сотрудники давно привыкли работать из любого места в офисе и без большого количества проводов. Опять же, популярной становится практика BYOD – Bring Your Own Device или «Принеси Свое Устройство», когда работники используют свои мобильные телефоны, планшеты и ноутбуки для выполнения корпоративных задач.
Fixed Mobile Convergence (FMC) – или конвергентная связь являет собой все три компоненты, упомянутые выше, интегрированные в одно решение. Это позволяет определять устройствам какую именно сеть или среду использовать для максимально выгодной и эффективной коммуникации. FMC – это концепт, и технически достигается разными вендорами различными способами.
FMC позволит вызовы с мобильных номеров сотрудников маршрутизировать через вашу офисную АТС со всеми вытекающими последствиями: запись разговора, статистика, правила маршрутизации внутреннего номера и так далее. Вы просто делаете SIP – транк между мобильным оператором и вашей АТС.
К примеру, мобильная гарнитура сотрудника также может быть зарегистрирована на корпоративной АТС как SIP – клиент и подключена к АТС через беспроводную сеть. При таком сценарии сотрудник может совершать вызовы, используя как мобильную сеть, так и беспроводную сеть для совершения звонков через его IP – АТС. Опять же, звонки тоже будут приходить на одно и то же устройство, но с двух совершенно разных направлений.
Плюсы использования конвергентной сети
Когда организация предоставляет гарнитуры, подобные тем, что мы упомянули выше, это позволит сэкономить много денег на мобильной связи – так как все звонки с мобильных устройств, которые сотрудники будут совершать с мобильного телефона, находясь в офисе, будут идти через корпоративную АТС. Основной вопрос здесь – это как реализовать бесшовную интеграцию, чтобы сотрудникам не приходилось подключать дополнительный софт или нажимать лишние кнопки при звонках.
Как я уже упомянул, тарифы на корпоративную мобильную связь и на VoIP связь могут быть сильно выгоднее для последних. Также очень часто тарифы на SIP гораздо выгоднее тарифов на классическую аналоговую связь через ТфОП.
Теперь коснёмся такой темы как международные вызовы – при внедрении FMC для компании возможно ввести такие правила, что абсолютно все международные вызовы должны идти через корпоративную телефонию, и, несмотря на то, что это все равно будет идти по повышенным тарифам, стоимость таких вызовов будет на порядки ниже по сравнению с использованием мобильной связи.
А что насчет продуктивности? Все сотрудники могут быть всегда доступны по их корпоративному номеру – в случае, если они находятся вне офиса, звонок будет автоматически перенаправлен на их мобильный номер, причем вызов будет совершен соответствующей АТС – если компания имеет офисы в нескольких городах или странах, это даст большой выйгрыш по качеству связи и затратам. Некоторые FMC вендоры также предоставляют возможность использования единого ящика голосовой почты, доступного как с рабочего телефона, так и с мобильного.
Более того, если в компании есть сотрудники, которые часто находятся в командировках, у вас есть возможность настроить мобильный телефон как удаленный экстеншен на корпоративной АТС и тогда они будут использовать только его – так уменьшатся затраты на оборудование и на его обслуживание. А еще, если сотрудники часто звонят из филиала в филиал, и привыкли использовать для этого мобильный телефон, это тоже позволит сильно уменьшить затраты. Конечно, бесспорным остается тот факт, что по - настоящему это будет ощущаться только при большом количестве сотрудников и наличии филиалов как таковых. Причем возможна настройка телефонов в таком режиме, когда вызов приходит сразу на два устройства и терминируется только на том, на котором подняли трубку – представляете, как это может помочь уменьшить количество неотвеченных вызовов? А вишенкой на торте является возможность реализации бесшовного роуминга между Wi – Fi сетью и сотовой сетью, тогда, к примеру, сотрудники смогут выйти из здания и вызов не прервется, а соединение автоматически переключится на сотовую сеть. Обратная ситуация также возможна – что опять - таки повлияет на затраты на сотовую связь.
Некоторые FMC решения также позволяют делать более гранулярный анализ звонков и активностей сотрудников – при интеграции с CRM системой это может сильно разгрузить продавцов с операционной точки зрения.
Заключение
На этом все, дорогие читатели! Думаю, многие из вас, читая данную статью задумались о том, что сейчас в 2018 году множество из описанных фич используется ежедневно у вас в компании и вы даже не думали, что это называется FMC ;) В 2018 году этот концепт немного устарел, по причине повсеместного развития облачных АТС и быстрого 4G подключения с безлимитным трафиком. Однако, мы все равно подумали, что это будет нелишним про это почитать :)
Привет! В этой статье мы рассмотрим Partitions и Calling Search Space (CSS) в Cisco Unified Communications Manager (CUCM) , которые являются частью механизма Class of Control и применяются при разграничении доступов.
/p>
Partitions можно рассматривать как набор маршрутов, паттернов, номеров DN, каждый из которых может принадлежать к определенным разделам. CSS же представляет собой упорядоченный список Partitions. Чтобы совершить вызов Partition вызываемой стороны должен принадлежать CSS вызывающей стороны.
При попытке выполнить вызов CUCM просматривает CSS вызывающей стороны и проверяет, принадлежит ли вызываемая сторона Partition’у в CSS. Если это так, вызов направляется в Translation Pattern. Если нет, то вызов отклоняется или Translation Pattern игнорируется. Подробнее про маршрутизацию и Translation Pattern’ы можно прочить в наших статьях.
Можно назначить разные CSS IP-телефонам, номерам DN, переадресации всех вызовов (Call Forwarding All – CFA), переадресации без ответа (Call Forwarding No Answer - CFNA), переадресации вызовов в случае занятости (Call Forwarding Busy - CFB), шлюзов и паттернам Translation Pattern.
Разделы и CSS облегчают маршрутизацию вызовов, поскольку они делят план маршрутизации на логические подмножества на основе организации, местоположения и/или типа вызова.
Чтобы лучше понять, как все это работает, рассмотрим пример.
Пример использования Partitions и CSS
Этот пример иллюстрирует, как можно разграничить маршрутизацию звонка между пользователями в пределах организации.
Допустим, у нас имеется три группы пользователей:
Стажеры (могут звонить только на внутренние номера)
Работники (могут звонить на внутренние номера и совершать междугородние звонки)
Руководство (могут звонить на внутренние номера, совершать междугородние и международные звонки)
Для каждого направления необходимо иметь Partition:
Внутренние номера –Partition_1
Междугородние звонки – Partition_2
Международные звонки – Partition_3
Эти разделы отражают все возможные направления звонков. Все телефоны (номера DN) мы поместим в раздел Partition_1 (внутренние номера).
На шлюзе сконфигурировано два паттерна Route Patterns:
Все звонки кроме международных (поместим в раздел Partition_2)
Международные звонки (поместим в раздел Partition_3)
На основании этих ограничений создаем три CSS:
CSS1 содержит разделы: Partition_1
CSS2 содержит разделы: Partition_1, Partition_2
CSS3 содержит разделы: Partition_1, Partition_2, Partition_3
Настраиваем телефоны:
На телефонах стажеров указываем CSS1
На телефонах работников указываем CSS2
На телефонах руководства указываем CSS3
Теперь совершим тестовые звонки с заданными настройками.
Тест 1: Звонок с телефона стажера
Набран внутренний номер:
Вызываемый абонент: Partition_1
Разделы CSS вызывающего абонента: Partition_1
Результат: Вызов выполнится (раздел Partition_1 включен в CSS)
Набран междугородний номер:
Вызываемый абонент: Partition_2
Разделы CSS вызывающего абонента: Partition_1
Результат: Вызов не выполнится (раздел Partition_2 не включен в CSS)
Набран международный номер:
Вызываемый абонент: Partition_3
Разделы CSS вызывающего абонента: Partition_1
Результат: Вызов не выполнится (раздел Partition_3 не включен в CSS)
Тест 2: Звонок с телефона работника
Набран внутренний номер:
Вызываемый абонент: Partition_1
Разделы CSS вызывающего абонента: Partition_1, Partition_2
Результат: Вызов выполнится (раздел Partition_1 включен в CSS)
Набран междугородний номер:
Вызываемый абонент: Partition_2
Разделы CSS вызывающего абонента: Partition_1, Partition_2
Результат: Вызов выполнится (раздел Partition_2 включен в CSS)
Набран международный номер:
Вызываемый абонент: Partition_3
Разделы CSS вызывающего абонента: Partition_1, Partition_2
Результат: Вызов не выполнится (раздел Partition_3 не включен в CSS)
Тест 3: Звонок с телефона руководства
Набран внутренний номер:
Вызываемый абонент: Partition_1
Разделы CSS вызывающего абонента: Partition_1, Partition_2, Partition_3
Результат: Вызов выполнится (раздел Partition_1 включен в CSS)
Набран междугородний номер:
Вызываемый абонент: Partition_2
Разделы CSS вызывающего абонента: Partition_1, Partition_2, Partition_3
Результат: Вызов выполнится (раздел Partition_2 включен в CSS)
Набран международный номер:
Вызываемый абонент: Partition_3
Разделы CSS вызывающего абонента: Partition_1, Partition_2, Partition_3
Результат: Вызов выполнится (раздел Partition_3 включен в CSS)
Таким образом, получается, что вызовы совершать можно, только если раздел Partition вызываемого абонента находится в CSS вызывающего.
Настройка
Начнем с настройки Partitions. В Cisco Call Manager Administration переходим во вкладку Call Routing → Class of Control → Partition и нажимаем Add New. Здесь в поле Name указываем название для раздела и нажимаем Save.
Теперь перейдем к созданию CSS. Для этого выберем вкладку Call Routing → Class of Control → Calling Search Space. Тут указываем имя в поле Name, из поля Available Partitions перенесем в поле Selected Partitions разделы, которые должен содержать CSS. Перенос осуществляется при помощи стрелочек. После чего нажимаем кнопку Save для сохранения.
После того как мы создали CSS и Partitions на наших серверах, применим их к устройствам. Рассмотрим это на примере настройки телефона. Для этого выбираем телефон, который мы хотим настроить во вкладке Device → Phone. В его настройках выбираем желаемую линию и нажимаем на нее, например Line [1] . В открывшемся окне в строке Route Partition в выпадающем списке выбираем раздел для этой линии. После этого нажимаем Save и возвращаемся назад.
Теперь нам осталось применить к телефону CSS. Здесь, в настройках телефона в поле Device Information находим строчку Calling Search Space и в выпадающем меню выбираем созданный ранее CSS. Затем сохраняем и применяем настройки.
Аналогично мы можем настраивать Partitions и CSS на других устройствах, паттернах и номерах.