По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Говоря о виртуализации, вы не можете не упомянуть VMware. Компания была основана в 1998 году и претерпела ряд изменений за последние два десятилетия, в последнее время она стала частью семейства Dell Technologies. В этой статье мы немного расскажем про историю компании и перейдем к обзору её основных продуктов.
О компании
История VMware
Компания была основана Дайан Грин и Мендель Розенблюм вместе со Скоттом Девином, Эллен Ван и Эдуардом Бугнионом. Затем она была приобретена в 2004 году корпорацией EMC, став частью Федерации EMC. Корпорация EMC была приобретена компанией Dell Technologies в 2016 году и в настоящее время является семейной компанией VMware. Грин занимал должность генерального директора в течение 10 лет, прежде чем в 2008 году был уволен советом директоров и заменён на Пола Марица, ветерана Microsoft. В 2012 году Мариц сменил Пэта Гелсингера, который до этого времени был директором отдела продуктов информационной инфраструктуры EMC. Несмотря на то, что VMware является дочерней компанией Dell Technologies, она по-прежнему находится в публичной торговле. Помимо семейной компании, заметными инвесторами являются JPMorgan, BlackRock и Cisco. Последние годовые показатели выручки, имеющиеся у компании, - за 2016 год, когда она отчиталась об общем доходе в $7 млрд (5 млрд). Ожидается, что данные за 2017 год будут опубликованы в начале февраля 2018 года, но его последние квартальные результаты, за Q2 2017 года, показывают рост в годовом выражении на 12%.
Что продает VMware?
Наследие VMware заключается в программном обеспечении виртуализации для облачных сред и центров обработки данных. Одним из популярных продуктов является vSphere, который наряду с Microsoft HyperV является одним из наиболее известных и наиболее широко используемых гипервизоров. Компания имеет несколько программ виртуализации настольных ПК и приложений, большинство из которых относятся к ее ассортименту продуктов Horizon, хотя она имеет три персональных продуктов виртуализации настольных ПК Fusion для Mac, Workstation для Windows и Workstation для Linux, которые выходят за рамки этого брендинга. Она также предлагает Horizon FLEX для управления этими тремя продуктами. Что касается облачной стороны вещей, то компания предлагает ряд управленческих продуктов под брендом vImplementation и vCloud. Интеграция с Amazon Web Services позволяет клиентам запускать средства VMware vSphere в общедоступном облаке. Другие менее основные продукты включают AirWatch для мобильности предприятия, vSAN для хранения данных и Pule IoT Center.
Показатели VMware
Пэт Гелсингер является нынешним генеральным директором VMware и занимает эту должность с 2012 года. Несмотря на короткое время пребывания в должности, Гелсингер фактически является третьим генеральным директором компании. Майкл Делл является председателем VMware с момента поглощения Dell в 2016 году предыдущей семейной компании VMware - EMC.
У компании есть три COO: Санджай Поонен, который присматривает за операциями клиентов, за продуктами и облачными сервисами присматривают Рагху Рагхурам и Раджив Рамасвами.
Рэй О 'Фаррелл - CTO компании, Зейн Роу - её финансовый директор и Жан-Пьер Брулард - SVP и GM для EMEA.
Основные продукты
Виртуализация
Гипервизор VMware (VMware hypervisor)
VMware виртуализирует физические компьютеры с помощью своего основного продукта гипервизора. Гипервизор - это тонкий слой программного обеспечения, который взаимодействует с базовыми ресурсами физического компьютера (называемого хостом) и распределяет эти ресурсы для других операционных систем (называемых гостями). Гостевая ОС запрашивает ресурсы у гипервизора.
Гипервизор разделяет каждую гостевую ОС, чтобы каждая могла работать без вмешательства других. Если одна гостевая ОС потерпит крах приложения, станет нестабильной или заражена вредоносным ПО, это не повлияет на производительность или работу других операционных систем, работающих на хосте.
VMware ESX
Гипервизор VMware ESXi для центров обработки данных представляет собой гипервизор типа 1 или «bare metal», заменяющий основную операционную систему, которая будет взаимодействовать с физическими компонентами компьютера. Это наследник ESX, который был большим гипервизором, который использовал больше ресурсов главного компьютера. VMware заменила ESX обновленым ESXi.
Ранняя версия гипервизора, ESX, включала ядро Linux (центральная часть ОС, управляющая аппаратным обеспечением компьютера). Когда VMware выпустила ESXi, она заменила ядро Linux своим собственным. ESXi поддерживает широкий спектр гостевых операционных систем Linux, включая Ubuntu, Debian и FreeBSD.
ESXi от VMware конкурирует с несколькими другими гипервизорами типа 1:
VMware vs Hyper-V: Microsoft Hyper-V - это продукт гипервизора, который позволяет запускать несколько операционных систем на одном сервере или клиентском компьютере. Как и ESXi от VMware, Hyper-V является гипервизором типа 1, который взаимодействует с базовыми физическими вычислительными ресурсами и ресурсами памяти. Hyper-V работает иначе, чем ESXi, используя разделы для управления своими виртуальными машинами. Hyper-V должен работать с ОС Windows. При активации он устанавливается вместе с операционной системой Windows в корневой раздел, что дает Windows привилегированный доступ к базовому оборудованию. Затем он запускает гостевые операционные системы в дочерних разделах, которые взаимодействуют с физическим оборудованием через корневой раздел. Hyper-V также поставляется с клиентами Windows 10, конкурирующими с гипервизорами VMware Type 2 Workstation.
VMware vs Citrix: Citrix предлагает продукты для виртуализации приложений и настольных систем и имеет большой опыт работы на рынке интеграции виртуальных десктопов. Основным предложением гипервизора является Citrix Hypervisor (известный как XenServer), который конкурирует с VMware vSphere. Продукты Citrix для виртуализации приложений и настольных компьютеров конкурируют с продуктом VMware Horizon для интеграции виртуальных десктопов.
VMware vs KVM: VMware ESXi и KVM являются гипервизорами, но KVM является частью ядра Linux (сердце ОС). Большое преимущество KVM перед VMware ESXi заключается в том, что он является продуктом с открытым исходным кодом, что делает его кодовую базу прозрачной. Вы можете использовать различные инструменты управления виртуализацией с открытым исходным кодом, которые интегрируются с ядром Linux. Как и во многих проектах с открытым исходным кодом, им может потребоваться дополнительная настройка. Вы также можете купить Red Hat Virtualization, которая предоставляет набор инструментов управления для виртуальных серверов, построенных на KVM.
Виртуализация десктопов
VMware Workstation
VMware Workstation включает в себя гипервизоры типа 2. В отличие от гипервизора типа 1, который полностью заменяет базовую ОС, гипервизор типа 2 запускается как приложение в настольной ОС и позволяет пользователям настольных компьютеров запускать вторую ОС поверх своей основной (host) ОС.
VMware Workstation поставляется в двух вариантах:
Workstation Player - бесплатная версия, которая поддерживает одну гостевую ОС (VMware Fusion — версия VMware Workstation для Mac).
Workstation Pro - поддерживает несколько гостевых операционных систем и интегрируется с инструментами управления виртуализацией предприятия VMware.
VMware Tools
Есть только одна вещь лучше, чем наличие второй ОС на настольном компьютере: наличие второй ОС, которая может обмениваться данными с первой. Вот тут и появляются VMware Tools. Это важная часть любой среды VMware Workstation. Это позволяет гостевой ОС, работающей в гипервизоре типа 2, лучше работать с хост-ОС.
Преимущества установки VMware Tools включают более высокую производительность графики и поддержку общих папок между гостевой и хост-ОС. Вы можете использовать VMware Tools для перетаскивания файлов, а также для вырезания и вставки между двумя операционными системами.
Гипервизоры VMware Type 2 конкурируют с другими на рынке, включая следующие:
VMware и Virtualbox: VirtualBox - это гипервизор типа 2, производимый принадлежащим Oracle Innotek, который конкурирует с VMware Workstation. Это бесплатный продукт с открытым исходным кодом, который позволяет устанавливать и использовать другую ОС поверх той, которая уже установлена на вашем настольном компьютере или ноутбуке. Вы можете установить продукты VMware на Linux и Windows. VirtualBox поддерживает Linux, Windows, Solaris и FreeBSD в качестве хост-операционных систем. Каждый продукт имеет свои сильные и слабые стороны в разных областях. Продукты VMware предлагают лучшую поддержку 3D-графики, а VirtualBox поддерживает больше образов виртуальных дисков, которые представляют собой файлы, содержащие данные виртуальной машины.
VMware и Parallels: Parallels - это гипервизор типа 2, предназначенный для работы гостевых операционных систем на платформе macOS. Это конкурирует с VMware Fusion. VMware Fusion доступен за разовую плату, но вы можете лицензировать Parallels только по модели подписки.
Интеграция с виртуальным рабочим столом (VDI - Virtual desktop integration)
VMware предлагает третью модель, которая находится где-то между виртуализацией серверов и настольных систем, описанной выше - интеграция виртуальных рабочих столов (VDI). VDI виртуализирует настольные операционные системы на сервере.
VDI предлагает централизованное управление настольными системами, позволяя вам настраивать и устранять неполадки операционных систем настольных систем без удаленного доступа или посещений на месте. Пользователи могут получать доступ к своим приложениям и данным с любого устройства в любом месте без необходимости инвестировать в дорогостоящее, мощное клиентское оконечное оборудование. Конфиденциальные данные никогда не покидает сервер.
VMware Horizon
VMware Horizon - это набор инструментов VDI от VMware. Он поддерживает рабочие столы как Windows, так и Linux. Вы можете запускать свои виртуальные рабочие столы в своих собственных помещениях или использовать Horizon Cloud для запуска их в нескольких размещенных облачных средах.
Пакет Horizon включает в себя Horizon Apps, платформу, которая позволяет вам создавать свой собственный магазин приложений для корпоративных пользователей для работы на их виртуальных рабочих столах. Ваши пользователи могут получить доступ к различным локальным, SaaS и мобильным приложениям, используя единый набор учетных данных для входа.
Vsphere
VMware vSphere - это платформа виртуализации предприятия VMware, включающая как программное обеспечение гипервизора ESXi, так и платформу управления vCenter Server для управления несколькими гипервизорами.
VSphere доступен в трех конфигурациях: Standard, Enterprise Class и Platinum. Каждый поддерживает хранилище виртуальных машин на основе политик, миграцию рабочей нагрузки в реальном времени и встроенные функции кибербезопасности. Варианты более высокого уровня включают шифрование на уровне виртуальной машины, интегрированное управление контейнерами, балансировку нагрузки и централизованное управление сетью. Платина сама по себе поддерживает автоматическое реагирование на угрозы безопасности и интеграцию со сторонними инструментами безопасности.
vCenter
Одним из важных компонентов vSphere является vCenter Server. Это компонент управления vSphere. Это позволяет вам управлять развертыванием виртуальной машины на большой коллекции серверов хоста. Он назначает виртуальные машины хостам, выделяет для них ресурсы, отслеживает производительность и автоматизирует рабочий процесс. Этот инструмент может использоваться для управления привилегиями пользователя на основе собственных политик пользователя.
VCenter Server состоит из трех основных компонентов:
VSphere Web Client - это пользовательский интерфейс платформы, предоставляющий администраторам доступ на основе браузера ко всем функциям.
База данных VCenter Server - это хранилище данных для продукта. Он хранит данные, необходимые хост-серверам для запуска гипервизоров и виртуальных машин.
Единый вход VCenter (Single Sign-On) - позволяет получить доступ ко всей инфраструктуре vSphere с помощью единого входа.
Кластеризация
Использование гипервизора на хост-сервере позволит максимально эффективно использовать это оборудование, но большинству корпоративных пользователей потребуется больше виртуальных машин, чем они могут уместить на одном физическом сервере. Вот где появляется технология кластеризации VMWare.
VMware распределяет ресурсы между хостами, группируя их в кластер и рассматривая их как одну машину. Затем вы можете использовать технологию кластеризации VMware для объединения аппаратных ресурсов между гипервизорами, работающими на каждом хосте в кластере. При добавлении виртуальной машины в кластер вы можете предоставить ей доступ к этим объединенным ресурсам. На предприятии с поддержкой VMware может быть много кластеров.
VMware позволяет создавать кластеры и управлять ими в своей среде vSphere. Кластер поддерживает множество функций vSphere, включая балансировку рабочей нагрузки, высокую доступность и отказоустойчивость.
Кластеризация VMware предоставляет вам доступ к нескольким функциям VMware, которые обеспечивают бесперебойную и надежную работу вашей виртуальной инфраструктуры.
VMware HA
Решение VMware vSphere High Availability (HA) позволяет переключать виртуальные машины между физическими хостами в случае сбоя основного оборудования. Оно контролирует кластер и, если обнаруживает аппаратный сбой, перезапускает свои виртуальные машины на альтернативных хостах.
VSphere HA определяет один хост в кластере как «ведущий», остальные называются «ведомыми». Мастер связывается с vCenter Server, сообщая о состоянии защищенных виртуальных машин и подчиненных хостов.
VMware Fault Tolerance
Несмотря на то, что vSphere HA обеспечивает быстрое восстановление после сбоев, вы все равно можете ожидать простоев во время перемещения и перезагрузки виртуальной машины. Если вам нужна дополнительная защита для критически важных приложений, vSphere Fault Tolerance предлагает более высокий уровень доступности. Он не обещает потери данных, транзакций или соединений.
VSphere Fault Tolerance работает путем запуска первичной и вторичной виртуальной машины на отдельных хостах в кластере и обеспечения их идентичности в любой точке. В случае сбоя одного из хостов оставшийся хост продолжает работать, и vSphere Fault Tolerance создает новую вторичную виртуальную машину, восстанавливая избыточность. VSphere автоматизирует весь процесс.
VMware DRS
Если вы позволите многим виртуальным машинам работать на хост-машинах неуправляемо, у вас возникнут проблемы. Некоторые виртуальные машины будут более требовательными к ресурсам процессора и памяти, чем другие. Это может создавать несбалансированные рабочие нагрузки: хосты обрабатывают больше, чем их доля работы, в то время как другие бездействуют. Распределенное планирование ресурсов VMware (DRS) решает эту проблему путем балансировки рабочих нагрузок между различными гипервизорами ESXi.
DRS, функция vSphere Enterprise Plus, работает в кластере хостов ESXi, которые совместно используют ресурсы. Он отслеживает использование ЦП и ОЗУ хоста и перемещает виртуальные машины между ними, чтобы избежать перегруженности и неиспользования хостов. Вы можете сами установить эти политики распределения, чтобы агрессивно перераспределять ресурсы или реже балансировать.
Виртуализация остальной части центра обработки данных
VMware сделала себе имя для виртуализации серверов, а затем и настольных операционных систем. В 2012 году компания объявила о планах виртуализации и автоматизации всего в центре обработки данных в рамках концепции, называемой программно-определяемым центром обработки данных (SDDC - software-defined data center).
Элементы VMDC SDDC включают следующее.
VMware NSX
VMware NSX - это продукт для виртуализации сети, позволяющий вам логически определять и контролировать свою ИТ-сеть в программном обеспечении. Вы можете объединить сетевые функции, такие как коммутация, маршрутизация, балансировка нагрузки трафика и брандмауэры, в гипервизоры, работающие на компьютерах x86. Вы можете управлять этими функциями вместе на одном экране, а не вручную настраивать различное оборудование для разных интерфейсов, а также применять программные политики для автоматизации сетевых функций. Это сетевой компонент SDDC от VMware, который обеспечивает те же преимущества виртуализации для сетевых, программных и вычислительных функций.
Продукт поддерживает несколько сред, включая ваш центр обработки данных, частное облако и общедоступные облака. Это упрощает поддержку вашей облачной сети приложениями, которые используют контейнерные среды и микросервисы.
VMware vSAN
VMware vSAN является частью решения VMware для виртуализации хранилищ. Он создает программный интерфейс между виртуальными машинами и физическими устройствами хранения. Это программное обеспечение - часть гипервизора ESXi - представляет физические устройства хранения в виде единого пула общего хранилища, доступного для компьютеров в одном кластере.
Используя VMware vSAN, ваши виртуальные машины могут использовать хранилище на любом компьютере в кластере, а не полагаться только на один компьютер, который может исчерпать хранилище. Это также позволяет избежать потери памяти физического компьютера, если виртуальные машины, работающие на этом компьютере, не используют ее. Виртуальные машины, работающие на других хостах, также могут использовать его хранилище.
VSAN интегрируется с vSphere для создания пула хранения для задач управления, таких как высокая доступность, миграция рабочей нагрузки и балансировка рабочей нагрузки. Пользовательские политики дают вам полный контроль над тем, как vSphere использует общее хранилище.
VMware Cloud
VMware предлагает несколько продуктов и услуг под баннером VMware Cloud. VMware Cloud Foundation, интегрированный программный пакет, поддерживающий гибридные облачные операции, включает в себя ряд услуг для программно-определяемых вычислений, систем хранения, сетей и безопасности, а также доступен в качестве услуги от различных поставщиков облачных услуг. Вы можете развернуть его в частной облачной среде через vSAN ReadyNode, проверенную конфигурацию сервера, предоставленную OEM, работающим с VMware.
VMware HCX (Сервис)
VMware HCX является компонентом VMware Cloud, который помогает компаниям использовать различные вычислительные среды. Это дает ИТ-командам необходимую функциональность по разумной цене и позволяет им хранить более конфиденциальные данные на своих компьютерах. Задача состоит в том, чтобы заставить эти виртуальные машины работать вместе в разных средах.
HCX - это ответ VMware на сложность этого гибридного облака. Это предложение программного обеспечения как услуги (SaaS), которое позволяет вам управлять несколькими экземплярами vSphere в разных средах, от локальных центров обработки данных до размещенных облачных сред. Ранее называвшийся Hybrid Cloud Extension и NSX Hybrid Connect, HCX абстрагирует вашу среду vSphere, так что виртуальные машины, которыми она управляет, имеют одинаковый IP-адрес, независимо от того, где они работают. HCX использует оптимизированное соединение глобальной сети (WAN) для расширения локальных приложений до облака без перенастройки. Это позволяет вам использовать дополнительные вычислительные мощности из облака для поддержания производительности локальных приложений, когда вычислительные потребности превышают локальные физические ресурсы.
Вы можете часто видеть эту ситуацию в розничной торговле. Резкий рост спроса на электронную коммерцию может израсходовать все ресурсы вашего центра обработки данных. Вы можете поддерживать выполнение заказов и избежать разочарований клиентов, используя вычислительные ресурсы в облаке. HCX позволяет вам реплицировать ваши данные в облачный экземпляр vSphere для аварийного восстановления. Если вам нужно переключиться на резервный сервер или систему, если локальная инфраструктура становится недоступной, вы можете сделать это без перенастройки IP-адресов.
Резервное копирование и снимки
Как и физические компьютеры, виртуальные машины должны быть зарезервированы. VMware использовала свою собственную систему защиты данных vSphere, но больше не выпускала этот продукт. Вместо этого вы можете использовать программное обеспечение EMC Avamar для резервного копирования, восстановления и дедупликации, которое обеспечивает защиту vSphere Data Protection. Есть также другие сторонние решения для резервного копирования, доступные от партнеров VMware.
Снимок VMware (снепшот) - это файл, который сохраняет состояние виртуальной машины и ее данных в определенный момент времени. Снимок позволяет восстановить виртуальную машину к моменту создания снимка. Снимки не являются резервными копиями, поскольку они сохраняют только изменения из исходного файла виртуального диска. Только полное решение для резервного копирования может полностью защитить ваши виртуальные машины.
Контейнеры VMware
Разработчики все чаще используют контейнеры в качестве альтернативы виртуальным машинам. Как и виртуальные машины, они представляют собой виртуальные среды, содержащие приложения, абстрагированные от физического оборудования. Однако контейнеры совместно используют ядро базовой операционной системы вместо виртуализации всей ОС, как это делают виртуальные машины.
Контейнеры обеспечивают большую гибкость и используют физические вычислительные мощности более эффективно, чем виртуальные машины, но они подходят не для всех случаев. Возможно, вы захотите разработать совершенно новое приложение, которое разделяет небольшие функциональные части, называемые микросервисами, на отдельные контейнеры, что делает разработку и обслуживание приложений более гибкими. С другой стороны, устаревшее приложение, написанное для запуска в виде одной двоичной программы, может быть более подходящим для работы в виртуальной машине, которая отражает среду, в которой она используется. Вы можете использовать контейнеры и виртуальные машины вместе, используя функцию интегрированных контейнеров vSphere VMware, которая устраняет разрыв между ними, позволяя контейнерам работать в средах VMware. Он состоит из трех компонентов:
VSphere Integrated Container Engine - позволяет разработчикам запускать контейнерные приложения на основе популярного формата контейнера Docker вместе с виртуальными машинами в той же инфраструктуре vSphere.
Project Harbor - это корпоративный реестр контейнеров, который позволяет разработчикам хранить и распространять образы контейнеров, чтобы другие разработчики могли их повторно использовать.
Project Admiral - это портал управления, который позволяет командам разработчиков предоставлять и управлять контейнерами.
AirWatch
AirWatch - это подразделение VMware, специализирующееся на управлении мобильностью предприятия. Его технология лежит в основе продукта VMware Workspace ONE Unified Endpoint Management, который позволяет управлять конечными точками, начиная с настольных ПК и заканчивая небольшими по размеру устройствами Интернета вещей (IoT), с помощью единой консоли управления.
Конечные точки являются уязвимостями безопасности для компаний. Злоумышленники могут получить доступ ко всей сети, заразив одну конечную точку вредоносным ПО. Конечные точки также уязвимы для физической кражи, что делает данные на них уязвимыми. Централизованное управление всеми конечными точками, даже если они не находятся в офисной сети, помогает администраторам обеспечить надлежащую защиту и шифрование конечных точек.
Продукт управления конечными точками поддерживает целый ряд операционных систем, от Android до MacOS и даже систем, ориентированных на IoT, таких как QNX. Вы можете настроить политики использования и параметры безопасности для каждого устройства в сети.
Заключение
Мы перечислили основные продукты компании VMware. Больше материалов про виртуализацию можно найти в нашем разделе.
Виртуальные сети - это, в простейшем виде, создание логических топологий, построенных на основе физической топологии. Эти логические топологии часто называют виртуальными топологиями - отсюда и концепция виртуализации сети. Эти топологии могут состоять из одного виртуального канала в более крупной сети, называемого туннелем, или набора виртуальных каналов, которые кажутся полной сетью поверх физической сети, называемой наложением.
Этот раздел лекций начнется с обсуждения того, почему создаются и используются виртуальные топологии, проиллюстрированные двумя примерами использования. Во втором разделе этих лекций будут рассмотрены проблемы, которые должно решить любое решение виртуализации, а в третьем разделе будут рассмотрены сложности при виртуализации сети. Далее будут рассмотрены два примера технологий виртуализации: сегментная маршрутизация (segment routing-SR) и программно - определяемые глобальные сети (Software-Defined Wide Area Networks- SD-WAN).
Понимание виртуальных сетей
Виртуализация усложняет проектирование протоколов, сетей и устранение неполадок, так зачем же виртуализировать? Причины, как правило, сводятся к разделению нескольких потоков трафика в одной физической сети. Это может показаться подозрительно похожим на другую форму мультиплексирования, потому что это еще одна форма мультиплексирования. Основные различия между рассмотренными до сих пор формами мультиплексирования и виртуализацией заключаются в следующем:
Позволяет нескольким плоскостям управления работать с различными наборами информации о достижимости в рамках одной физической топологии;
Позволяет нескольким наборам достижимых пунктов назначения работать в одной физической топологии без взаимодействия друг с другом;
Рассмотренные до этого момента методы мультиплексирования были сосредоточены на том, чтобы позволить нескольким устройствам использовать одну физическую сеть (или набор проводов), позволяя каждому устройству взаимодействовать с любым другим устройством (при условии, что они знают друг о друге с точки зрения достижимости). Виртуализация направлена на разбиение одной физической сети на несколько доменов достижимости, где каждое устройство в домене достижимости может взаимодействовать с любым другим устройством в том же домене достижимости, но устройства не могут связываться между доменами достижимости (если нет какой-либо точки соединения между достижимостью домены).
На рисунке 1 показана сеть с виртуальной топологией, расположенной поверх физической топологии.
На рисунке 1 виртуальная топология была создана поверх физической сети, с виртуальным каналом [C,H], созданным для передачи трафика по сети. Чтобы создать виртуальную топологию, C и H должны иметь некоторую локальную информацию пересылки, отделяющую физическую топологию от виртуальной топологии, которая обычно проходит либо через E, либо через D. Это обычно принимает форму либо специального набора записей виртуального интерфейса в локальной таблице маршрутизации, либо таблицы виртуальной маршрутизации и пересылки (VRF), содержащей только информацию о виртуальной топологии.
Рассмотрение потока пакетов через виртуальную топологию может быть полезно для понимания этих концепций. Как бы выглядел поток пакетов, если бы C и H имели виртуальные интерфейсы? Рисунок 2 демонстрирует это.
На рисунке 2 процесс пересылки выполняется следующим образом:
A передает пакет к M.
C получает этот пакет и, исследуя свою локальную таблицу маршрутизации, находит, что кратчайший путь к месту назначения лежит через виртуальный интерфейс к H. Этот виртуальный интерфейс обычно называется туннельным интерфейсом; он выглядит с точки зрения таблицы маршрутизации, как и любой другой интерфейс маршрутизатора.
Виртуальный интерфейс, через который необходимо передать пакет, имеет инструкции перезаписи, которые включают добавление нового заголовка, заголовка туннеля или внешнего заголовка в пакет и пересылку полученного пакета. Исходный заголовок пакета теперь называется внутренним заголовком. C добавляет внешний заголовок и обрабатывает новый пакет для пересылки.
Теперь C исследует новый пункт назначения, которым является H (помните, что исходным пунктом назначения был M). H не подключен напрямую, поэтому C необходимо выяснить, как достичь H. Это называется рекурсивным поиском, поскольку C ищет путь к промежуточному месту назначения, чтобы доставить пакет к конечному месту назначения, но не к нему.
Теперь C поместит правильную информацию в пакет в заголовок link local, чтобы перенаправить трафик на E.
Когда E получает этот пакет, он удаляет внешнюю информацию о переадресации, Заголовок link local и пересылает трафик на основе первого заголовка C, помещенного в пакет, во время первоначального поиска. Этот внешний заголовок говорит E переслать пакет в H; E не видит и не включает исходный внутренний заголовок, помещенный на пакет A.
E добавит новый Заголовок link local, чтобы пакет был правильно переадресован в H, и передаст пакет по правильному интерфейсу.
Когда H получает пакет, он удаляет Заголовок link local и обнаруживает внешний заголовок. Внешний заголовок говорит, что пакет предназначен для самого H, поэтому он очистит этот заголовок и обнаружит исходный заголовок пакета или внутренний заголовок.
Теперь H посмотрит в своей локальной таблице маршрутизации и обнаружит, что M локально подключен. H поместит правильный Заголовок link local в пакет и передаст его через правильный интерфейс, чтобы пакет достиг M.
Если C и H используют VRF, а не туннельные интерфейсы, процесс в предыдущем списке изменяется на шагах 2 и 8. На шаге 2 C будет искать M как пункт назначения в VRF, связанном каналом [A, C]. Когда C обнаруживает, что трафик к M должен пересылаться через виртуальную топологию через H, он помещает внешний заголовок в пакет и снова обрабатывает пакет на основе этого внешнего заголовка через базовый VRF или, скорее, таблицу маршрутизации, представляющую физическую топологию. Когда H получает пакет, он удаляет внешний заголовок и снова обрабатывает пакет, используя VRF, к которому подключен M, для поиска информации, необходимой для пересылки трафика в его конечный пункт назначения. В этом случае интерфейс туннеля заменяется отдельной таблицей пересылки; вместо того, чтобы обрабатывать пакет через одну и ту же таблицу дважды с использованием двух разных адресатов, пакет обрабатывается через две разные таблицы пересылки.
Термин туннель имеет много различных определений; в этих статьях туннель будет использоваться для описания виртуального канала, где внешний заголовок используется для инкапсуляции внутреннего заголовка, и:
Внутренний заголовок находится на том же уровне или более низком уровне, чем внешний заголовок (например, заголовок Ethernet, переносимый внутри заголовка IPv6; обычно IPv6 переносится внутри Ethernet).
По крайней мере, некоторые сетевые устройства на пути, будь то виртуальные или физические, пересылают пакет только на основе внешнего заголовка.
Переход от виртуальных интерфейсов к VRFs концептуально отличается достаточно, чтобы породить различные описательные термины. Underlay -это физическая (или потенциально логическая!) топология, через которую туннелируется трафик. Overlay - это набор туннелей, составляющих виртуальную топологию. В большинстве случаев термины Underlay и Overlay не используются с отдельными туннелями или в случае службы, работающей через общедоступный Интернет. Сервис, который создает виртуальную топологию через общедоступный Интернет, часто называют сервисом over-the-top.
Опять же, эти термины используются в некоторой степени взаимозаменяемо и даже очень небрежно в более широком мире сетевой инженерии. На этом фоне пора перейти к вариантам использования, чтобы узнать о наборе проблем, которые необходимо решить виртуализацией.
Предоставление услуг Ethernet по IP-сети.
Хотя приложения не должны создаваться с использованием подключения Ethernet в качестве базового, многие из них это делают. Например:
Некоторые поставщики систем хранения данных и баз данных строят свои устройства с предположением, что подключение Ethernet означает короткое расстояние и короткую задержку, или они проектируют системы поверх проприетарных транспортных протоколов непосредственно поверх кадров Ethernet, а не поверх пакетов интернет-протокола (IP).
Некоторые продукты виртуализации включают в свои продукты предположения о возможности подключения, такие как надежность кеширования Ethernet для IP-адресов для шлюза по умолчанию и других доступных мест назначения.
Для таких приложений требуется то, что выглядит как соединение Ethernet между устройствами (физическими или виртуальными), на которых работают различные узлы или копии приложения. Помимо этого, некоторые сетевые операторы считают, что запуск большого плоского домена Ethernet проще, чем запуск крупномасштабного IP-домена, поэтому они предпочли бы создавать самые большие домены Ethernet, которые они могут ("коммутация, где можно, маршрутизация, где необходимо", была распространенная поговорка в те времена, когда коммутация выполнялось аппаратно, а маршрутизация выполнялась программно, поэтому коммутация пакетов выполнялась намного быстрее, чем их маршрутизация). Некоторые кампусы также построены с основной идеей - никогда не просить устройство коммутировать свой IP-адрес после подключения. Поскольку пользователи могут быть подключены к разным сегментам Ethernet в зависимости от их домена безопасности, каждый сегмент Ethernet должен быть доступен в каждой точке беспроводного доступа и часто на каждом порте Ethernet в кампусе.
Учитывая сеть, основанную на IP, которая предполагает Ethernet как один из многих транспортных средств, поверх которых будет работать IP, как вы можете обеспечить подключение Ethernet к устройствам, связанным по IP-сети? На рисунке 3 показаны задачи, которые необходимо решить.
На рисунке 3 процесс, работающий на A с IP-адресом 2001:db8:3e8:100::1, должен иметь возможность взаимодействовать со службой, работающей на B с IP-адресом 2001:db8:3e8:100::2, как если бы они находились в одном сегменте Ethernet (две службы должны видеть друг друга в обнаружении соседей и т. д.). Чтобы сделать проблему более сложной, служба на A также должна иметь возможность перемещаться в K без изменения своего локального кэша обнаружения соседей или маршрутизатора по умолчанию. Сама сеть, является маршрутизируемой сетью, работающей под управлением IPv6.
Что необходимо для выполнения требований?
Должен быть способ передачи кадров Ethernet по IP-сети, разделяющей серверы. Обычно это будет своего рода туннельная инкапсуляция, как описано в начале этого раздела. Туннелирование позволило бы принимать кадры Ethernet на C, например, инкапсулированные в какой-то внешний заголовок, чтобы их можно было транспортировать по маршрутизируемой сети. Когда пакет, содержащий кадр Ethernet, достигает D, этот внешний заголовок может быть удален, и кадр Ethernet пересылается локально. С точки зрения D, фрейм имеет локальное происхождение.
Должен быть способ узнать о пунктах назначения, доступных через туннель, и привлечь трафик в туннель. На самом деле это две отдельные, но взаимосвязанные проблемы. Привлечение трафика в туннель может включать запуск второй плоскости управления с ее собственными VRFs или добавление дополнительной информации в существующую плоскость управления об адресах Ethernet Media Access Control (MAC), доступных на каждом пограничном маршрутизаторе.
Может потребоваться перенести маркировку качества обслуживания (QoS) из внутреннего заголовка во внешний заголовок, чтобы трафик обрабатывался правильно при его пересылке.
Виртуальный частный доступ к корпоративной сети.
Почти в каждой организации есть какие-то удаленные сотрудники, либо на полную ставку, либо просто люди, которые перемещаются, и у большинства организаций есть какие-то удаленные офисы, где часть сотрудников работает вдали от главного офиса, чтобы напрямую взаимодействовать с местным организациями в некоторых отраслях, например, с покупателями или поставщиками. Все эти люди по-прежнему нуждаются в доступе к сетевым ресурсам, таким как электронная почта, системы путешествий, файлы и т. д. Эти службы, конечно, не могут быть доступны в общедоступном Интернете, поэтому необходимо предоставить какой-то другой механизм доступа. На рисунке 4 показаны типичное проблемное пространство.
В этом варианте использования есть две основные проблемы:
Как можно защитить трафик между отдельным хостом - B - и тремя хостами в небольшом офисе - C, D и E - от перехвата и чтения злоумышленником? Как можно защитить сами адреса назначения от попадания в публичную сеть? Эти проблемы связаны с некоторой защитой, которая, в свою очередь, подразумевает некоторую форму инкапсуляции пакетов.
Как можно управлять качеством работы пользователей в этих удаленных местах для поддержки передачи голоса по IP и других приложений в реальном времени? Поскольку провайдеры в Интернете не поддерживают QoS, необходимо обеспечить другие формы гарантии качества.
Таким образом, задача, которую необходимо решить, включает еще две общие проблемы.
Должен быть способ инкапсулировать трафик, передаваемый по общедоступной сети, без раскрытия исходной информации заголовка и без подвергания информации, содержащейся в пакете, для проверки. Самым простым решением этих проблем является туннелирование (часто в зашифрованном туннеле) трафика от A и F к граничному маршрутизатору в сети организации G, где инкапсуляция может быть удалена, а пакеты перенаправлены на A.
Должен быть способ объявить достижимые пункты назначения от G к удаленным пользователям, а также существование (или достижимость) удаленных пользователей к G и сети позади G. Эта информация о достижимости должна использоваться для привлечения трафика в туннели. В этом случае плоскости управления может потребоваться перенаправить трафик между различными точками входа и выхода в общедоступную сеть и попытаться контролировать путь трафика через сеть, чтобы обеспечить удаленным пользователям хорошее качество работы.
Подведем итоги
Два варианта использования, показанные выше, актуализируют два вопроса, которые должно решить каждое решение сетевой виртуализации:
Как трафик инкапсулируется в туннель, чтобы можно было отделить пакеты и информацию плоскости управления от базовой сети?
Решением этой проблемы обычно является некоторая форма инкапсуляции, в которую помещается исходный пакет, когда он передается по сети. Основное внимание при инкапсуляции - поддержка аппаратной коммутации в базовой сети, чтобы обеспечить эффективную пересылку инкапсулированных пакетов. Второстепенным соображением является размер формата инкапсулирующего пакета; каждый октет дополнительного заголовка инкапсуляции уменьшает объем полезной нагрузки, которую туннель может нести (если нет разницы между максимальной единицей передачи или MTU в сети, предназначенной для учета дополнительной информации заголовка, налагаемой туннелированием).
Примечание
Path MTU Detection (PMTUD) часто плохо определяет MTU инкапсулированных пакетов. Из-за этого часто требуется ручная настройка MTU в точке наложения заголовка туннеля.
Как пункты назначения достигаются через туннель, объявленный через сеть?
В более общих туннельных решениях туннель становится "просто еще одним звеном" в общей топологии сети. Пункты назначения, доступные через туннель, и дополнительная виртуальная связь просто включены как часть плоскости управления, как и любые другие пункты назначения и каналы. В этих решениях существует одна таблица маршрутизации или пересылки в каждом устройстве, и рекурсивный поиск используется для обработки пакета посредством пересылки в точке, где трафик входит в туннель или головной узел туннеля. Трафик привлекается в туннель путем изменения метрик таким образом, чтобы туннель был более желательным путем через сеть для тех пунктов назначения, которые оператор сети хотел бы получить через туннель. Это обычно означает в основном ручные решения проблемы привлечения трафика в туннель, такие как установка метрики туннеля ниже пути, по которому проходит туннель, а затем фильтрация пунктов назначения, объявленных через туннель, чтобы предотвратить объявления пунктов назначения, которые должны быть недоступны через туннель. На самом деле, если пункты назначения, достижимые через туннель, включают конечную точку туннеля (хвост туннеля), может образоваться постоянная петля маршрутизации, или туннель будет циклически переключаться между правильной переадресацией трафика и не переадресацией трафика вообще.
В решениях с overlay и over-the-top развертывается отдельная плоскость управления (или передается отдельная база данных с информацией о доступности для адресатов, достижимых в underlay и overlay в единой плоскости управления). Пункты назначения, доступные через underlay и overlay, помещаются в отдельные таблицы маршрутизации (VRF) на головной станции туннеля, а таблица, используемая для пересылки трафика, основана на некоторой форме системы классификации. Например, все пакеты, полученные на конкретном интерфейсе, могут быть автоматически помещены в оверлейный туннель, или все пакеты с определенным классом обслуживания, установленным в их заголовках пакетов, или весь трафик, предназначенный для определенного набора пунктов назначения. Механизмы полного наложения и верхней виртуализации обычно не полагаются на метрики для привлечения трафика в туннель на головной станции.
Еще одно необязательное требование - обеспечить качество обслуживания либо путем копирования информации QoS из внутреннего заголовка во внешний заголовок, либо путем использования какой-либо формы проектирования трафика для передачи трафика по наилучшему доступному пути.
Да – да, CUCM умеет собирать CDR (Call Detail Record). А в статье мы покажем, как включить данный функционал, который по умолчанию, отключен.
Включение CDR
Подключаемся к интерфейсу Cisco Unified CM Administration:
Переходим по пути System → Service Parameters и выбираем следующее:
Server - 192.168.1.1 (Active), например. Тут мы выбираем ноду, на которой проведем работы. У вас, конечно, IP будет другой. А может и такой же :)
Service - отметьте сервис Cisco CallManager (Active);
Листаем на появившейся страницу параметры и находим сегмент System, в котором отмечаем вот что:
CDR Enabled Flag * - True. Этим параметром мы говорим колл – менеджеру, создавать и хранить CDR – записи по каждому звонку, который пройдет через этот UCM;
CDR Log Calls with Zero Duration Flag * - True. Включая этот параметр, мы говорим, чтобы сервер сохранял звонки, которые не состоялись, или длительность которых менее 1 секунды (это полезно для траблшутинга);
Не забывайте сохранить изменения. Повторите данные процедуры для каждой ноды в кластере (если на этапе выбора в сегменте System → Service Parameters → Server у вас больше одного сервера).
Дополнительная настройка
После этого, давайте познакомимся с дополнительными параметрами. Для этого, в меню настройки нажмите на кнопку Advanced:
Выставьте следующие параметры:
Call Diagnostics Enabled - Enabled Only When CDR Enabled Flag is True. Параметр отвечает за включение так называемых Call Management Records (CMR), которые очень полезны при диагностике проблем и траблшутинге;
Display FAC in CDR - True. Отображать ли Forced Authorization Code (FAC) в CDR записях. То есть, отображаться ли код доступа в CDR – записях. В целом, данный параметр зависит от ваших политик безопасности. Мы отображаем :);
Show Line Group Member DN in finalCalledPartyNumber CDR Field - True. Если коротко – параметр в таком положении, будет показывать DN (directory number) человека, который ответил на звонок внутри группы, а не номер самой группы;
Show Line Group Member Non Masked DN in finalCalledPartyNumber CDR Field: Required Field - по факту, почти тоже самое, что и выше;
Переходим в интерфейс Cisco Unified Serviceability, переходим в раздел Tools → CDR Analysis and Reporting. Далее, во вкладке CDR можете воспользоваться поиском или выгрузкой данных. Enjoy :)