СПОСОБ СОХРАНЕНИЯ СЛИЯНИЯ ВИРТУАЛЬНОГО ПОРТА И МАТЕРИАЛЬНАЯ СРЕДА

ОБЩИЕ СВЕДЕНИЯ

Виртуальная машина (VM) является абстракцией или "виртуализацией" фактической физической компьютерной системы. На фигуре 1 показана одна возможная архитектура компьютерной системы 70, которая осуществляет виртуализацию. В этой архитектуре множество VM 20…20-n абстрагируется программой виртуализации 15 на главном компьютере 10. В настоящем примере программа виртуализации 15 включает ядро VM 60 и один или несколько мониторов VMM 50. Возможны другие конфигурации, чтобы обеспечить функциональные возможности виртуализации, что понятно специалистам в данной области техники. Главный компьютер 10, как правило, включает один или несколько процессоров 11, память 13, запоминающее устройство большой емкости 14, одну или несколько сетевых интерфейсных плат (NIC) 17 и различные другие устройства 19. Как известно, термин "сетевая интерфейсная плата" или "сетевой интерфейс" обычно относится к компонентам, осуществляющим сетевое соединение независимо от того, является ли этот компонент отдельной платой или встроен в материнскую плату компьютера.

Можно предположить, что каждая VM 20…20-n может состоять из виртуального аппаратного обеспечения 22 системы и программного обеспечения 30 гостевой системы. Виртуальное аппаратное обеспечение 22 системы, как правило, включает один или несколько виртуальных процессоров 28, виртуальную память 23, по меньшей мере, один виртуальный диск 24 и одну или несколько виртуальных сетевых интерфейсных плат (VNIC) (на чертеже показана только одна). Одно или несколько дополнительных виртуальных устройств 27, таких как виртуальные устройства пользовательского интерфейса, универсальные последовательные шины (USB) и т.д. также могут быть включены в систему. Аппаратные средства 22 виртуальной системы показаны на фигуре 1 в блоке, обведенном пунктирном, потому что это просто концептуализация, которая не существует отдельно от программы виртуализации 15 и главного компьютера 10. Эта концептуализация - просто одно представление среды выполнения программного обеспечения гостевой системы 30. Все виртуальные аппаратные компоненты VM 20 фактически осуществлены программой виртуализации 15, используя известные методики, и подражают соответствующим физическим компонентам. В настоящем примере программа виртуализации 15 включает один или несколько мониторов VMM 50, каждый из которых включает эмуляторы устройств 53.

Программное обеспечение гостевой системы 30 включает гостевую операционную систему (OS) 32 и драйверы 34, которые необходимы для VNIC 25, виртуальный диск 24 и другие различные виртуальные устройства 27. Гостевая система OS 32 может быть не полной OS с возможностью работы непосредственно на аппаратной платформе (т.е. не в виртуальной машине), или она может быть системой OS, модифицированной для работы в паравиртуальной среде, в зависимости от того, что требуется или разрешено конкретной реализацией программы виртуализации 15. Термин "программа виртуализации" относится здесь к программному уровню, внедряющему либо полную виртуализацию, либо паравиртуализацию. "Полная виртуализация" относится к системе, в которой в гостевую операционную систему не включены никакие программные компоненты любой формы кроме тех, которые были бы найдены в невиртуальном компьютере; таким образом, гостевая OS может быть стандартной, коммерчески доступной системой OS без компонентов, включенных специально, чтобы поддерживать ее использование в виртуальной среде. Напротив, "паравиртуальная" система виртуализирована "не полностью". Скорее гостевая система сконфигурирована, чтобы обеспечить определенные особенности, которые облегчают виртуализацию. С этой целью, здесь термин "виртуализация" включает полную виртуализацию и паравиртуализацию.

В дополнение к гостевой операционной системе 32, одно или несколько гостевых приложений 36 выполняются "в пределах" VM 20, хотя специалисты в данной области понимают, что выполнение гостевой программы OS и команды гостевого приложения происходит через программу виртуализации 15 и гостевую платформу 10. Гостевое приложение 36 может быть любым типом приложения, предназначенного для работы с гостевой операционной системой 32. Как это понимается в технологии виртуализации, пользовательский ввод к VM 20 и вывод из нее может быть переадресован программой виртуализации 15 на отдаленный терминал (не показан) или через оконечное приложение (не показано), выполняемое операционной системой 40.

Программу виртуализации 15 может включать один или несколько программных компонентов и/или уровней, возможно, один или несколько программных компонентов, известных в области технологии виртуальных машин, таких как "мониторы виртуальной машины" (VMM), "гипервизоры" или ядра виртуализации (называемые здесь "ядрами VM"). Поскольку терминология виртуализации развилась довольно долго и еще не стала полностью стандартизированной, эти сроки не всегда обеспечивают ясное различие между программными уровнями и компонентами, к которым они относятся. Как он используется здесь, термин "программа виртуализации" относится к программному уровню или компоненту, логически вставленному между виртуальной машиной и гостевой платформой.

В системе виртуализации, которая показана на фигуре 1, мониторы виртуальных машин VMM 50 развернуты над ядром VM 60. Ядро VM 60 может быть создано конкретно с целью оказания эффективной прямой поддержки виртуальных машин (т.е. не используя универсальной OS, такой как Linux или Windows), когда интерфейсы с физическими ресурсами и устройствами составляют главный компьютер 10. Отметим, что ядро VM 60 не является тем же самым ядром, что и ядро в гостевой системе OS 32. Как известно, каждая типичная операционная система имеет свое собственное ядро OS. Отметим также, что ядро VM 60 может рассматриваться как часть гостевой платформы для VM даже при том, что конфигурацию, которая показана на фигуре 1, обычно называют "не гостевой" конфигурацией.

В другой известной конфигурации (не показана) программа виртуализации 15 может включать универсальную операционную систему (не показана) вместо ядра VM. Такая конфигурация часто упоминается как "гостевая" система виртуализации с универсальной операционной системой, такой как гостевая OS. Гостевая система OS сконфигурирована для выполнения определенной операции устройства ввода-вывода для различных VM, выполняемых в системе параллельно и иногда по требованию мониторов VMM. В этом случае гостевая OS, как предполагается, является частью программы виртуализации, обеспечивающей виртуализацию. Выбор конфигурации программы виртуализации, т.е. гостевой или нет, является ли она полностью виртуальной или паравиртуальной, делается на основе относительных преимуществ и недостатков каждого типа, которые известны специалистам в области виртуализации компьютерных систем.

На фигуре 2 показаны виртуальные машины VM 20-1, 20-2 и VMM 50-1, 50-2, передающие сетевые кадры через сетевой интерфейс (NIC) 17 из главного компьютера 10-1 через виртуальный коммутатор 65. Программа виртуализации 15 передает сетевые кадры от VM 20-1, 20-2 через виртуальные сетевые интерфейсы (VNIC) 25-1, 25-2 физическому центру сетевой информации 17 из главного компьютера 10-1. Каждый VNIC 25-1, 25-2 соединен с соответствующим виртуальным портом 62, 64 виртуального коммутатора 65. Виртуальный коммутатор 65 является логической совокупностью виртуальных портов 62, 64 и поддерживает посылаемую базу данных (не показана) адресов VNIC, например коды аутентификации сообщений MAC. Каждый виртуальный порт 62, 64, 66 является логической точкой встречи для соответствующего интерфейса VNIC и программных компонентов, которые отправляют трафик от VNIC. Этим способом виртуальный коммутатор 65 определяет, как и куда направить сетевые кадры, передаваемые от VNIC 25-1, 25-2 и NIC 17. Таким образом, виртуальный коммутатор 65 функционирует как программный мост, который позволяет множеству VM совместно использовать один или множество физических NIC. Например, если физические NIC не установлены на главном компьютере 10-1, то виртуальный коммутатор 65 может функционировать как виртуальная сеть, которая соединяет виртуальные машины VM 20-1, 20-2, выполненные на главном компьютере 10-1.

Каждый из коммутаторов VNIC 25-1, 25-2 является эмулированным сетевым устройством, предоставляющим по программе 15 виртуальным машинам VM 20-1, 20-2 требуемый доступ к сети. Таким образом, виртуальный коммутатор 65 обрабатывает трафик между VNIC 25-1, 25-2, соединенный с виртуальным коммутатором 65 и, возможно, подключенный к физической сети через один или несколько физических NIC. В целом, виртуальные коммутаторы способны определить на основе заголовка сетевого кадра, предназначен ли кадр для работы в местной сети, и если он предназначен для работы в местной сети, какие виртуальные машины должны получить этот кадр. Администраторы сети вообще обязаны управлять виртуальными коммутаторами 65, чтобы конфигурировать эти особенности. Поскольку число виртуальных коммутаторов 65, как правило, больше числа их физических копий, администратор сети может также выполнять повторные задачи конфигурирования многих виртуальных коммутаторов 65.

Одно преимущество технологии виртуализации состоит в том, что она позволяет перемещать VM от одного физического главного компьютера к другому, выключая или приостанавливая VM на одном главном компьютере и включая или возобновляя работу VM на другом физическом главном компьютере. В этом контексте, "приостановка" VM означает временный или длительный «простой» программы виртуализации. Следует отметить, что выполнение VM часто приостанавливается даже при том, что она "работает". VM может быть приостановлена на мгновение, например, чтобы продолжить выполнение VM другой совместной задачи. Напротив, "выключение" VM относится к виртуализации процедуры выключения питания физической машины. Как и физический компьютер, VM может быть выключена методическим способом, в котором каждый процесс определяется OS как предстоящее выключение питания, позволяя каждому открытому приложению сохранить его данные, и выключение питания может быть выполнено, моделируя выключение питания, когда все процессы выполнения закончены, теряя любые несохраненные данные или состояние, связанное с выполнением процессов. После отключения питания от VM возобновление выполнения, как правило, требует перезагрузки гостевой OS и перезапуска любых приложений, тогда как возобновление выполнения приостановленной VM требует перезагрузки состояния VM и возобновления выполнения.

Когда VM приостановлена, процессы останавливаются и состояние VM, включая содержание ее памяти, параметры, состояние виртуальных устройств и т.д. могут быть записаны на диск. В примере, который показан на фигуре 2, VM 20-2 может быть перемещена, приостанавливая или выключая VM 20-2 на главном компьютере 10-1 и возобновляя или включая VM 20-2 на главном компьютере 10-2, как показано стрелкой 75. Термин "перемещение" относится к процессу перемещения VM от одного главного компьютера к другому, приостанавливая или выключая питание VM на одном главном компьютере и возобновляя или включая эту VM на другом главном компьютере.

К сожалению, перемещение VM от одного главного компьютера до другого может повлечь некоторую потерю статуса, связанного с VNIC для перемещенного VM. Традиционно, когда VM 20-2 перемещена от главного компьютера 10-1 на главный компьютер 10-2 (как обозначено стрелкой 75), соединение 56 между виртуальным интерфейсом VNIC 55-2 и виртуальным портом 64 теряется, как обозначено крестиком 52, и новое соединение 58 устанавливается между виртуальным интерфейсом VNIC 55-3 и виртуальным портом 66 на виртуальном коммутаторе 65' с помощью программы виртуализации 15' на главном компьютере 10-2. MAC и другая информация о состоянии, связанная с VNIC 25-2, могут быть переданы VNIC 25-3 как часть атрибутов виртуальных устройств, составляющих VM 20-2, с тем, чтобы возобновленная VM 20-2 поддерживала свою позицию в сети. Однако VM 20-2 далее соединяется с виртуальным портом 66 виртуального коммутатора 65' на главном компьютере 10-2, предлагая новому порту 66 обеспечение связи по сети, не делая предположений о любом сохранении состояния, не связанного конкретно с виртуальным устройством NIC 25-2 (например, MAC, фильтр вещания/групповой передачи и т.д.). Таким образом, в ходе этого процесса перемещения VM, информация о состоянии, которая может накапливаться в порту виртуального коммутатора 64, как правило, теряется.

В дополнение к этим проблемам, администратор сети, который рассматривает виртуальную сеть с точки зрения коммутации, не имеет никакой постоянной топологии для работы при перемещении VM, когда он пытается рассматривать и/или реконфигурировать виртуальную сеть.

КРАТКОЕ СОДЕРЖАНИЕ ИЗОБРЕТЕНИЯ

Описываемый здесь способ служит для сохранения состояния виртуального порта в виртуальной компьютерной системе. В некоторых примерах воплощения распределенный виртуальный порт (DVport) сохраняется в постоянном участке памяти, причем DVport сохраняет состояние соответствующего виртуального порта и параметры конфигурации виртуального порта. Кроме того, сохраняется связь между виртуальным портом и виртуальной сетевой интерфейсной платой (VNIC), соединенной с виртуальным портом. Когда виртуальная машина, соответствующая VNIC, перезапускается, состояние DVport извлекается из ячейки постоянной памяти и прилагается к новому виртуальному порту.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

На фигуре 1 показана локальная виртуальная система.

На фигуре 2 показаны VM и VMM, передающие сетевые кадры через сетевой интерфейс (NIC) системных аппаратных средств и через виртуальный коммутатор.

На фигуре 3 показан распределенный виртуальный коммутатор (DVswitch), согласно одному примеру воплощения.

На фигуре 4 показано, как сконфигурирован распределенный виртуальный порт (DVport) распределенного виртуального коммутатора DVswitch согласно одному примеру воплощения.

На фигуре 5 показано, как DVswitch реконфигурирует соединение между VNIC и виртуальным коммутатором во время перемещения VM согласно одному примеру воплощения.

На фигуре 6 показан процесс для создания и удаления коммутатора DVswitch согласно одному примеру воплощения.

На фигуре 7 показан процесс для соединения или отсоединения VNIC к или от DVport коммутатора DVswitch согласно одному примеру воплощения.

На фигуре 8 показан процесс для перемещения DVport во время перемещения VM согласно одному примеру воплощения.

На фигуре 9 показан процесс для того, чтобы реконфигурировать DVswitch, выключая и включая главный компьютер, согласно одному примеру воплощения.

ПОДРОБНОЕ ОПИСАНИЕ ПРИМЕРОВ ВОПЛОЩЕНИЯ ИЗОБРЕТЕНИЯ

Ниже будут подробно описаны несколько примеров воплощения изобретения со ссылками на сопроводительные чертежи. Отметим что везде на чертежах аналогичные узлы и устройства обозначены одинаковыми цифровым позициями. Воплощения изобретения на чертежах приведены только в целях иллюстрации. Специалисты в данной области при чтении следующего описания поймут, что могут использоваться альтернативные воплощения показанных здесь структур и способов, не выходя из объема и принципов настоящего изобретения.

На фигуре 3 показана примерная управляемая совокупность 300 виртуальных компьютерных систем. В одном примере воплощения распределенный виртуальный коммутатор (DVswitch) включает компоненты DVswitch 350A, 350В и 350С. Термин "распределенный" здесь использован, чтобы обозначить объекты, которые могут перемещаться от одного физического главного компьютера до другого или охватить множество главных компьютеров как управляемую совокупность главных компьютеров. Поэтому DVswitch - программная абстракция, которая связывает аналогичные виртуальные коммутаторы 602, 602' в управляемой совокупности в единый логический объект с перестраиваемой конфигурацией. На фигуре 3 для иллюстрации представлены только два главных компьютера 100-1, 100-2, каждый из которых имеет только одну VM 320, 320' и соответствующие эмуляторы VNIC 301-1, 301-2. Однако следует понимать, что коммутатор DVswitch может охватить любое число главных компьютеров, каждый из которых может иметь любое число VM, каждая из которых, в свою очередь, может иметь любое число виртуальных сетевых интерфейсных плат (VNIC), любая из которых может быть ограничена по числу доступными аппаратными ресурсами индивидуальных главных компьютеров.

Коммутатор DVswitch, как программная абстракция, постоянно распределен во множестве аппаратных средств, поэтому называется "распределенным" виртуальным коммутатором. Например, компоненты DVswitch 350A, 350В и 350С постоянно находятся в главных компьютерах 100-1, 100-2, так же как в базе данных 370. Компоненты DVswitch 350A, 350В и 350С показаны на фигуре 3 в обозначенном пунктиром блоке с частями DVswitch 350A, 350В и 350С, которые составляют коммутатор DVswitch. В дополнение к этим компонентам, DVswitch, выполняющий логические функции, расположен в пакете программ виртуализации 600 вместе с контроллером базы данных 372, как будет описано ниже более подробно.

Как показано на фигуре 3, единственный виртуальный порт 652, 654 поддерживается для каждого VNIC 215-1, 215-2, соответственно. Каждый VNIC 301-1, 301-2 взаимодействует с драйверами NIC 224-1, 224-2 в VM 200-1, 200-2, чтобы послать и получить данные к и от VM 320, 320'. Например, каждый VNIC 301-1, 301-2 может поддержать состояние для одного или нескольких VNIC для каждого VM 320, 320'. Альтернативно, множество представителей класса эмуляторов VNIC 301-1, 301-2 (только один показан для каждого главного компьютера) могут быть установлены в пределах уровня программы виртуализации. В любом случае, одна VM может иметь один или несколько VNIC, которые могут быть осуществлены одним или несколькими эмуляторами VNIC. С целью иллюстрации на фигуре 3 показана только одна плата VNIC для каждой VM и только одна VM для каждого главного компьютера. Специалисты в данной области понимают, что приведенное здесь обсуждение VNIC 215-1, 215-2 является фактически обсуждением состояния VNIC, осуществленной и поддержанной каждым виртуальным интерфейсом VNIC 301-1, 301-2. Упомянутые выше виртуальные устройства, такие как VNICS 215-1, 215-2, являются программными абстракциями, которые удобны для обсуждения, как если бы они были частью VM 200-1, 200-2, но фактически осуществлены программой виртуализации 600, 600', используя эмуляторы 301-1, 301-2. Однако состояние каждой VM 200-1, 200-2 включает состояние ее виртуальных устройств, которое управляются и поддерживается основной программой виртуализации 600, 600'. Когда VM приостановлена или завершена и перемещена, ее состояние, которое включает сетевые параметры настройки, такие как адреса MAC любой из плат VNIC, перемещается вместе с VM.

Аналогичные виртуальные коммутаторы 602, 602', которые соединены с той же самой физической сетью 442, управляются, используя один DVswitch. Физическая сеть 442 может быть, например, локальной сетью. На фигуре 3 DVswitch включает распределенные виртуальные порты (DVport) 352, 354. DVport - программная абстракция, которая формирует "индивидуальность" (конфигурацию и динамическое состояние) соответствующего виртуального порта. Таким образом, DVport 352 содержит одну или несколько структур данных, представляющих конфигурацию и динамическое состояние виртуального порта 652 виртуального коммутатора 602. Аналогичным образом, DVport 354 содержит одну или несколько структур данных, представляющих конфигурацию, и динамическое состояние виртуального порта 654 виртуального коммутатора 602'. Порты DVport принимают конфигурацию, предопределенную администратором сети. Виртуальные порты 652, 652' созданы и начинаются с открытого состояния конфигурации, но поскольку они связаны с портом DVport, они принимают конфигурацию и динамическое состояние соответствующего DVport. Когда VM перемещается или выключается или включается, на "соединение" между DVport и виртуальным интерфейсом NIC это не влияет, потому что DVport сохраняется и перемещается вместе с VM, с которой он соединен.

Термин "соединение" использован здесь, чтобы описать связь виртуального NIC с портом DVport. В одном воплощении эта связь поддерживается на местном уровне программой виртуализации 600, 600' и в таблице или другой структуре данных в базе данных 370, как описано ниже более подробно. Когда происходит соединение с портом DVport, другой виртуальный интерфейс NIC не может быть подключен к этому DVport, явно не разъединяя уже подключенный виртуальный интерфейс NIC. Термин "подключение" использован здесь, чтобы описать состояние, в котором виртуальный интерфейс NIC и виртуальный порт были подготовлены для передачи и получения кадров. Если и только если и виртуальный NIC и виртуальный порт «договариваются» об этом состоянии соединения, сетевой трафик может отправляться и от виртуального NIC виртуальным коммутатором. Отметим, что термин "фильтр" использован здесь, чтобы описать программный компонент, который создает путь (ввод-вывод) между виртуальным портом и виртуальным NIC. Термин "механизм продвижения данных" использован здесь, чтобы описать программный компонент, который строит и поддерживает таблицы, приложения для построения аппаратного адреса уровня 2 (например, адреса MAC) для виртуальных портов и принимает решения о посылке, основанные на этих таблицах.

Управление состоянием DVswitch and DVport

DVswitch 350 и его порты DVport 352, 354 созданы на основе физических ресурсов, которые должны быть доступны для физических NIC 172, 172' в управляемом домене главных компьютеров 100-1, 100-2. Созданная база данных 370 хранит в памяти состояние DVswitch 350 и DVports 352, 354. База данных 370 может быть создана в контроллере базы данных 372, соединенном с главными компьютерами 100-1, 100-2 через физическую сеть 442. В дополнительном воплощении вторая физическая сеть (не показана) соединяет сервер базы данных 374 с главными компьютерами 100-1, 100-2 через вторые NIC (не показаны), установленные на каждом главном компьютере 100-1, 100-2, чтобы дополнительно изолировать сервер базы данных 374 от сетевых ресурсов (например, от Интернета), который может представлять угрозу безопасности. Поэтому главные компьютеры 100-1, 100-2 в управляемом домене имеют доступ к базе данных 370. Управляемый домен - совокупность главных компьютеров 100-1, 100-2, охватываемых классом объектов базы данных 370. Для состояний, которые являются глобальной переменной к данному коммутатору DVswitch 350, база данных 370 помещает копии только для чтения в каждый из главных компьютеров 100-1, 100-2 в управляемом домене. Поскольку главные компьютеры 100-1, 100-2 не должны изменять данные и их обновления являются нечастыми, агрессивный ввод обновлений всех главных компьютеров 100-1, 100-2 не создает недопустимых издержек.

Однако состояния, которые являются конкретными для данного DVport 352, 354, должны быть изменены главным компьютером, где расположен виртуальный порт DVport 652, 654, и обновления являются частыми. Таким образом, база данных 370 помещает состояние DVport только в необходимый главный компьютер и опрашивает главный компьютер периодически и после определенных критических событий для обновления состояний. В дополнение к длительному хранению в базе данных 370, некоторое состояние DVswitch может кэшироваться на каждом главном компьютере в управляемом домене, чтобы избежать ненужной связи с базой данных 370. Процесс, постоянно выполняемый в базе данных 370, отвечает за ввод соответствующих обновлений в местной памяти каждого главного компьютера 358, 358' в управляемом домене. Выражение "местная память" должно интерпретироваться здесь расширительно, чтобы отразить устройство хранения данных или систему, которая легко доступна от главного компьютера. В одном примере воплощения главные компьютеры 100-1, 100-2 всегда предполагают, что их местная память 358, 358' обновлена и что любые обновления, которые они делают в местной памяти, будут переданы базе данных 370 процессом сервера базы данных контроллера базы данных 372 надлежащим образом. Когда база данных 370 является офлайновой или главный компьютер теряет связь с базой данных 370, главный компьютер может продолжить операции в текущем состоянии, хотя без обновлений от базы данных 370 и без гарантии, что изменения, которые он делает к своей местной памяти, будут сохранены. Риски, связанные с такой потерей обеспечения связи, минимальны (т.е. в отличие от распределенной файловой системы, где может произойти невосполнимая потеря данных, если механизм синхронизации потерян, здесь концептуальны только разделяемые ресурсы).

Монопольное использование DVport

В одном примере воплощения модель монопольного использования с двумя уровнями применена к состоянию DVport. Первый уровень монопольного использования относится к уровню, в котором главный компьютер в настоящее время имеет право изменить состояние конкретного порта DVport. В одном воплощении такое монопольное использование состояния DVport предоставляет контроллер базы данных 370, когда он помещает состояние DVport на данный главный компьютер. Контроллер базы данных 370 отвечает за предоставление и отмену монопольного использования DVports 352, 354. Как только главному компьютеру 100-1 или 100-2 предоставили монопольное использование DVport, он сохраняет монопольное использование до тех пор, пока контроллер базы данных 372 явно не отменит монопольное использование.

Второй уровень монопольного использования относится к уровню, в котором виртуальный NIC в данное время соединяется с DVport. Когда виртуальный NIC 215-1 делает новое "соединение" с DVport 352, виртуальный NIC 215-1 выдает запрос на контроллер базы данных 372 для идентификатора (ID) порта DVport 352. В одном воплощении виртуальный NIC 215-1 идентифицирует DVport 352 по номеру порта DVport (или другого идентификатора), который может быть вручную выбран пользователем (т.е. администратором) или автоматически назначен приложением управления во время конфигурации DVswitch. Например, номер DVport, идентифицирующий конкретный DVport по его номеру, может быть конфигурирован вместе с другими параметрами настройки конфигурации для VM. Если поле соединения идентификатора свободно для требуемого DVport, то создается новый идентификатор соединения контроллером базы данных 372 и возвращается виртуальному интерфейсу 215-1. Когда виртуальный NIC 215-1 получает ID соединения для DVport 352, он получает право использовать сетевую поддержку ресурсов (т.е. связанного) порта DVport 352. ID соединения и номер DVport могут быть сохранены вместе с другими параметрами конфигурации для VM, создавая, таким образом, связь между VM и DVport. Как отмечено выше, виртуальные NIC 215-1, 215-2 являются программными абстракциями физических NIC, созданных виртуальными эмуляторами NIC 301-1, 301-2, соответственно. Следовательно, код для запроса и получения идентификатора соединения может постоянно находиться в компонентах виртуальных эмуляторов NIC 301-1, 301-2 или в других компонентах программы виртуализации 600, 600' на уровне каждого главного компьютера 100-1, 100-2.

Если текущее поле ID соединения для конкретного DVport занято во время запроса на установление соединения, то право соединения в настоящее время принадлежит другому виртуальному интерфейсу и новый запрос на установление соединения будет отклонен. Каждый раз, когда виртуальному интерфейсу предоставляют соединение с портом DVport, виртуальный NIC сохраняет ID соединения и использует его для будущих операций. Виртуальный NIC может освободить соединение в любое время, и оно становится доступным для использования другим виртуальным NIC. Можно отменять соединение, просто генерируя новый ID соединения для DVport или очищая текущее поле ID соединения DVport. При отмене соединения попытки использовать старый ID соединения будут терпеть неудачу.

В другом примере воплощения DVport может принадлежать кластеру главных компьютеров, без явного присвоения одним главным компьютером. Любые конфликты, являющиеся результатом множества главных компьютеров, пытающихся запросить тот же самый DVport, могут быть решены через алгоритм однорангового выбора.

Работа DVport

Когда виртуальный интерфейс NIC 215-1 соединен с DVport 352, виртуальный NIC может попытаться установить соединение, делая вызов в программное обеспечение системного уровня на главном компьютере 100-1, чтобы запросить поддержки DVport 352 виртуальным портом. Программное обеспечение системного уровня может быть программой виртуализации, такой как программа виртуализации 600 или другое системное программное обеспечение. Например, в негостевой системе виртуализации вызов может быть сделан на ядро VMKernel, как это описано выше со ссылками на фигуры 1 и 2. В ответ на вызов программное обеспечение системного уровня может затем связать DVport 352 с виртуальным портом 652 виртуального коммутатора 602, чтобы обеспечить доступ к желательной сети. Как только соединение будет успешно завершено, виртуальный NIC 215-1 будет в состоянии посылать и получать кадры от сети 442.

Как будет объяснено более подробно ниже со ссылкой на фигуру 9, когда виртуальная машина 320 отключена от сети питания или приостановлена, VNIC 215-1 делает вызов в программное обеспечение системного уровня, чтобы понизить состояние канала связи. Это освобождает основной виртуальный порт 652 и ресурсы, связанные с DVport 352, но не отпускает монопольное использование DVport 352. Прежде чем освободить виртуальный порт 652, система синхронизирует все регистрированные состояния порта назад к DVport 352. Когда виртуальная машина включается снова или возобновляет нормальную работу, DVport 352 запрашивает новый виртуальный порт на главном компьютере 100-1, синхронизирует регистрированное состояние порта назад к компьютеру и поднимает состояние канала связи снова, если это состояние было оставлено.

Как будет объяснено ниже более подробно со ссылкой на фигуру 8, когда виртуальная машина 320 перемещается от одного главного компьютера (например, 100-1) на другой главный компьютер (например, 100-2), выполняется та же самая последовательность стадий, как при выключении и включении питания, выполняемых VM, за исключением того, что первая половина процедуры для освобождения основного порта виртуального коммутатора выполняется на исходном главном компьютере, а вторая половина процедуры для получения нового основного порта виртуального коммутатора происходит на целевом компьютере. Требуется одна дополнительная стадия для передачи состояния DVport местной памяти целевого компьютера и объявления этого состояния недействительным в местной памяти главного компьютера. Так как ID соединения составляет часть состояния DVport, перемещение VM вызывает передачу монопольного использования DVport с исходного главного компьютера на целевой компьютер.

Фигура 4 иллюстрирует представление на концептуальном уровне множества распределенных виртуальных коммутаторов 350, 350', 350'', каждый из которых охватывает первый и второй главные компьютеры 100-1, 100-2. В этом представлении на концептуальном уровне каждый интерфейс VNIC присоединен к одному из трех коммутаторов DVswitch, каждый из которых связан с соответствующим физическим интерфейсом NIC для каждого главного компьютера. Таким образом, интерфейсы VNIC 215-1, каждый из которых может соответствовать отдельной VM, связаны с распределенным виртуальным портом, например, 352, 354, которыми управляет DVswitch 350. DVswitch 350, в свою очередь, обеспечивает соединение VNIC 215-1, 215-2 с сетью 442 через физические NIC 172, 172'. С точки зрения пользователя, конкретного знания параметров и состояния индивидуальных виртуальных портов 652, 654 и виртуальных коммутаторов 602, 602', описанных выше со ссылкой на фигуру 3, не требуется. Таким образом, DVswitch представляет удобную абстракцию основной логики установления связи между VNIC и виртуальными коммутаторами, разрешая пользователю управлять коммутатором DVswitch как абстракцией физического коммутатора, подключающего каждую из VM к конкретной локальной сети (LAN). В данном случае упомянутый выше "пользователь" может быть сетевым или хост-администратором. Поскольку DVswitch извлекает параметры настройки отдельных виртуальных коммутаторов и виртуальных портов, администратору нужно только иметь дело с коммутатором DVswitch, приложенным к каждому VNIC с его конфигурацией. Как только это сделано, виртуальные порты и коммутаторы, которые поддерживают DVport и DVswitch, будут должным образом сконфигурированы автоматически путем перезапуска или приостановки и возобновления работы, даже если возобновление или рестарт будут выполнены на другом главном компьютере в управляемой совокупности.

Как показано на фигуре 4, одиночный главный компьютер 100-1 может взаимодействовать с множеством коммутаторов DVswitch, каждый из которых связан с соответствующей сетью. В настоящем примере, главные компьютеры 100-1, 100-2 каждый взаимодействует с распределенными виртуальными коммутаторами DVswitch 350, 350', 350'', которые, в свою очередь, соединены с сетями 442, 446 и 448, соответственно. Главный компьютер 100-1 включает NIC 172, соединяющий DVswitch 350 с сетью 442, NIC 174, соединяющей DVswitch 350' с сетью 446, и NIC 176, соединяющий DVswitch 350» с сетью 448. Главный компьютер 100-2 включает соответствующие компоненты, хотя возможны и другие конфигурации, что очевидно специалистам в данной области.

На фигуре 5 представлен упрощенный вид совокупности 300, показанной ранее на фигуре 3, до перемещения VM 320' от главного компьютера 100-1 к главному компьютеру 100-2. Согласно одному примеру воплощения, когда VM 320' перемещается от исходного главного компьютера 100-1 к целевому компьютеру 100-2, соединение между VNIC 215-2 и виртуальным портом 654 виртуального коммутатора 602 разрывается, и VNIC 215-2 соединяется с новым виртуальным портом 656 виртуального коммутатора 602' на целевом компьютере 100-2. Поскольку DVswitch 350 облегчает передачу состояния и монопольное использование DVport (например, 352) от местной памяти 358 исходного главного компьютера 100-1 к местной памяти 358' целевого компьютера 100-2 через DVswitch 350, информация о состоянии, которая может накапливаться в порту виртуального коммутатора 654, не теряется и также перемещается в виртуальный порт 656 виртуального коммутатора 602'.

Расширяемость

DVswitch и DVport динамически расширяемы с помощью регистрирующего фильтра и классов продвижения данных продвижения класса машины. Один класс программы для продвижения данных (здесь не показан) связан с каждым DVswitch 350, и нулевой или другие классы фильтра связаны с DVswitch 350.

Класс программы для продвижения данных осуществляет основную логику передачи кадра для DVswitch 350. Класс программы для продвижения данных включает правила для определения и индикации, какой DVport должен получать каждый кадр, который входит в DVswitch. Так как класс программы для продвижения данных отвечает за принятие решений по передаче данных, есть только один класс программы для продвижения данных, связанный с каждым DVswitch 350. Класс программы для продвижения данных может регистрировать DVswitch и определенный контекст DVport для конфигурации и динамического состояния. Класс фильтра осуществляет некоторый тип контроля, фильтрации или функциональных возможностей преобразования для DVport. Каждый класс фильтра может быть применен к одному или нескольким портам DVport и может регистрировать конкретное содержание порта для конфигурации и динамического состояния.

Класс программы для продвижения данных назначается во время создания DVswitch. Классы фильтра могут быть добавлены к DVport или удалены из него в любое время. Каждый класс программы для продвижения данных определяет ряд обратных вызовов, чтобы осуществить различные необходимые и дополнительные операции. Каждый класс программы для продвижения данных также может произвольно объявить один или несколько непрозрачных типов данных, поддерживаемых системой. Эти данные будут приложены к состоянию DVswitch и DVport, которое было перемещено и сохранено системой.

На фигуре 6 показан примерный процесс создания и удаления DVswitch, согласно одному примеру воплощения. Обращаясь теперь к фигурам 3 и 6, в операции 601 мы видим, что контроллер базы данных 372 создает новый вход DVswitch 350C и порт DVport коммутатора DVswitch в базе данных 370. При этом DVswitch 350 связан с программой для обслуживания продвижения данных и с конкретным состоянием класса DVswitch. Чтобы создать новый вход DVport в базе данных 370, вход DVport связывается с данным DVswitch и состояние DVport инициализируется значением по умолчанию. Например, "текущий идентификатор соединения" порта DVport может быть установлен в положение "DVPORT_NO_CONNECTION" (нет соединения с DVport), чтобы указать, что в настоящее время никакой виртуальный NIC не соединен с DVport. Контроллер базы данных 372 выдает новую информацию DVport на все главные компьютеры 100-1, 100-2 в управляемом домене, которые сохраняют эту информацию в местной памяти 358, 358'. Кроме того, контроллер базы данных 372 может также установить фильтр DVport, связывая определенное классом непрозрачное состояние с состоянием DVport.

На стадии 604 главный компьютер присоединяется к созданному коммутатору DVswitch 350. В одном примере воплощения эта операция инициируется контроллером базы данных 372, который (i) проверяет, может ли главный компьютер (например, 100-1, 100-2) обеспечить соответствующее сетевое соединение и сервис гостевой части данного коммутатора DVswitch, (ii) включает главный компьютер в список главных компьютеров, связанных с DVswitch 350 в базе данных 370, и (iii) передает текущие данные DVswitch подключаемому главному компьютеру, который сохраняет эти данные в своей местной памяти.

На стадии 606 главный компьютер отключается от DVswitch. В одном примере воплощения эта операция инициализируется контроллером базы данных 372, который (i) проверяет, что главный компьютер (например, 100-1, 100-2), отключаемый от DVswitch, в настоящее время не имеет никакого порта DVport (например, 352, 354, …, 362) от данного DVswitch, связанного с ним, (ii) входит в контакт с главным компьютером (например, 100-1, 100-2), чтобы указать, что он должен очистить свою местную память от любых данных, связанных с данным DVswitch, и (iii) удаляет главный компьютер из списка главных компьютеров, связанных с DVswitch 350 в базе данных 370. Отметим, что главный компьютер может соединяться с 604 и отключаться от 608 DVswitch многократно в течение всего срока службы коммутатора DVswitch.

На стадии 608 контроллер базы данных 372 удаляет DVswitch (например, 350) из базы данных 370. Чтобы удалить DVswitch (например, 350), контроллер базы данных 372 должен убедиться, что все главные компьютеры отключены от DVswitch, и затем удаляет все состояния, соответствующие DVswitch, из базы данных 370.

На фигуре 7 показан процесс для соединения интерфейса VNIC с портом DVport коммутатора DVswitch или отключения от него по одному примеру воплощения. На стадии 702 виртуальный NIC (например, 215-1) соединен с запрошенным DVport (например, 352) коммутатора DVswitch 350. В одном примере воплощения эта операция инициализируется через контроллер базы данных 372, который проверяет текущие соединения на запрошенном DVport (например, 352), гарантируя, что текущий ID соединения - DVPORT_NO_CONNECTION, указывая, что никакой виртуальный NIC в настоящее время не соединен с этим запрошенным DVport. Если другой виртуальный NIC в настоящее время соединен с запрошенным DVport, то запрос о подключении VNIC к запрошенному DVport отклоняется. Если требуемый DVport доступен, то контроллер базы данных 372 генерирует новый ID соединения и устанавливает "текущий ID соединения" для запрашиваемого DVport (например, 352) как новый ID соединения. Контроллер базы данных 372 помещает обновленные данные DVport в главный компьютер (например, 100-1), который в настоящее время является главным компьютером виртуального NIC (например, 215-1), и набор "поля" ID соединения конфигурации виртуального NIC в новый ID соединения.

На стадии 704 виртуальный порт (например, 652) виртуального коммутатора 602 "связан" с "соединенным" виртуальным интерфейсом (например, 215-1). В одном примере воплощения эта операция осуществляется на главном компьютере (например, 100-1), где виртуальный NIC (например, 215-1) принят и не требует участия контроллера базы данных 372. Виртуальный NIC (например, 215-1) запускает системную программу компьютера (например, программу виртуализации 600), информируя DVport (например, 352), что он подключен, и обеспечивает ID соединения. Система DVswitch проверяет, что DVport (например, 352) фактически в настоящее время передается на этот главный компьютер (например, 100-1). В одном примере воплощения наличия данных DVport с текущим идентификатором соединения, отличным от DVPORT_NO_CONNECTION, достаточно для подтверждения, что DVport (например, 352) передан на этот главный компьютер (например, 100-1). Система DVswitch проверяет правильность этого ID соединения, обеспеченного виртуальным NIC (например, 215-1) и соответствующего текущему идентификатору соединения в данных DVport. Если данные ID соединения не соответствуют опорным данным, запрос на установление соединения отклоняется. Если данные ID соединения соответствуют, ресурсы порта на местном виртуальном коммутаторе главного компьютера (например, 602) распределены в виртуальном интерфейсе (например, 215-1) и виртуальный NIC передает маркер ресурсам. Определенные классом обратные вызовы для любого класса продвижения данных или класса фильтрации установлены на основном порту виртуального коммутатора (например, 652), и состояние порта виртуального коммутатора извлекается из местной памяти главного компьютера, используя определенный классом блок преобразования. В результате порт виртуального коммутатора (например, 652) используется для ввода-вывода данных.

На стадии 706 виртуальный порт виртуального коммутатора может также быть "соединен по нисходящей линии" от "подключенного" виртуального NIC (например, 215-1). В одном примере воплощения эта операция выполняется на главном компьютере (например, 100-1), где виртуальный NIC (например, 215-1) запрограммирован и не требует никакого участия контроллера базы данных 372. Виртуальный NIC (например, 215-1) посылает вызов в систему, указывая, что он хотел бы освободить ресурсы порта виртуального коммутатора (например, 652) на главном компьютере (например, 100-1). В результате весь ввод-вывод и другая деятельность в порту виртуального коммутатора (например, 652) находятся в состоянии умолчания. Система DVswitch собирает все транспарантное состояние DVport от основного порта виртуального коммутатора (например, 652). Определенные классом обратные вызовы для любых установленных классов продвижения данных или классов фильтрации удаляются от основного порта виртуального коммутатора (например, 652), и состояние передается в местную память главного компьютера, используя определенные классом последовательно-параллельные преобразователи. Отметим, что виртуальный порт виртуального коммутатора может быть соединен по восходящей или нисходящей лини многократно в течение всего срока службы соединения виртуального NIC с портом DVport коммутатором DVswitch.

На стадии 708 виртуальный NIC (например, 215-1) может быть отключен от DVport (например, 352). В одном примере воплощения эта операция инициализируется через контроллер базы данных 372, который помещает обновление текущего ID соединения в главный компьютер (например, 100-1), которому в настоящее время передается DVport (например, 352), устанавливая текущий ID соединения в позицию DVPORT_NO_CONNECTION. После получения этого обновления главный компьютер (например, 100-1) снижает виртуальное состояние канала связи порта, если состояние канала связи уже не было снижено, и извлекает состояние DVport из местной памяти главного компьютера, чтобы синхронизировать базу данных 370.

На фигуре 8 показан процесс перемещения DVport при перемещении VM, согласно одному примеру воплощения. Как показано на фигурах 5 и 8, DVport (например, 354) может быть перемещен между главными компьютерами 100-1, 100-2 таким же образом, как перемещаются виртуальные машины (например, 200-2). На верхнем уровне DVport перемещает свое состояние в доступный порт виртуального коммутатора, чтобы обеспечить постоянное сетевое соединение для виртуальных интерфейсов NIC (например, 215-2), когда они перемещаются от исходного главного компьютера (например, 100-1) к целевому главному компьютеру (например, 100-2).

В одном примере воплощения перемещение DVport инициализируется через контроллер базы данных 372, который выполняет следующие операции для каждого виртуального NIC в соответствующей перемещаемой виртуальной машине (например, 200-2). На стадии 802 контроллер базы данных 372 перемещает DVport (например, 354) вниз на исходный главный компьютер (например, 100-1), выполняя "нисходящую связь виртуального порта" на исходном главном компьютере (например, 100-1), как описано выше со ссылкой на фигуру 7. На стадии 804 последовательное состояние для DVport (например, 354), извлекаемое из местной памяти (например, 358) исходного главного компьютера (например, 100-1), передается в местную память (например, 358') целевого компьютера (например, 100-2). При перемещении состояния для DVport на целевой главный компьютер, контроллер базы данных 372 передает монопольное использование DVport на целевой главный компьютер. На стадии 806 контроллер базы данных 372 стирает состояние виртуального порта на исходном главном компьютере (например, 100-1), таким образом, отменяя монопольное использование им порта DVport (например, 352). На стадиях 807 и 808 контроллер базы данных 372 поднимает DVport до главного компьютера адресата (например, 100-2), применяя переданное состояние DVport (например, 354) к другому виртуальному порту виртуального коммутатора (например, 602') на главном компьютере адресата (например, 100-2) и выполняя "подключение" виртуального порта на главный компьютер адресата (например, 100-2), как описано выше.

На фигуре 9 показан в качестве примера процесс реконфигурации коммутатора DVswitch путем выключения и включения главного компьютера. Эти операции могут выполняться с участием или без участия контроллера базы данных 372. Если контроллер базы данных 372 знает о неизбежном случае выключения питания, он может выполнить операцию 902, в которой контроллер базы данных 372 извлекает обновления из местной памяти главного компьютера непосредственно перед выключением главного компьютера (например, 100-1). На стадии 904, до выключения питания, главный компьютер (например, 100-1) синхронизирует свою постоянную местную память по внутренней кэш-памяти, если постоянная память доступна. На стадии 906 содержание DVswitch и состояние DVport переносятся из местной памяти в оперативную память главного компьютера сразу после перезагрузки, если главный компьютер имеет копии своего местного DVswitch и состояния DVport в постоянной местной памяти. На стадии 908 контроллер базы данных 372 копирует все состояния DVswitch и DVport в главном компьютере (например, 100-1), как только он обнаруживает наличие главного компьютера. Контроллер базы данных 372 может попытаться объединить или иным образом решить конфликты между старыми данными из кэш-памяти главного компьютера и данными из базы данных 370. В одном примере воплощения данные из базы данных 370 считаются подтвержденными и записываются поверх любого состояния, поддерживаемого в местной памяти. Контроллер базы данных 372 помещает полученные обновления в главный компьютер (например, 100-1).

После чтения этого описания специалисты в данной области оценят все дополнительные альтернативные структурные и функциональные возможности распределенного виртуального коммутатора на базе раскрытых здесь принципов. Конкретные операции описанного выше способа могут быть выполнены одновременно или последовательно в различном порядке. Хотя здесь описаны и показаны на чертежах конкретные воплощения и приложения, для специалистов в данной области будет очевидно, что различные модификации и изменения могут быть сделаны в расположении оборудования, операциях и деталях способа, не выходя за рамки сущности и объема изобретения, как это определено в прилагаемой формуле изобретения.