Генерация топологии виртуальной сети - RU2382398C2

Чертежи

Описание

СВЯЗАННЫЕ ЗАЯВКИ

Данная заявка на патент связана со следующими заявками на патенты США (которые включены в данное описание посредством ссылки):

Заявка на патент США №09/695812, поданная 24 октября 2000 г., на “Систему и способ для распределенного управления совместно используемыми компьютерами”.

Заявка на патент США №09/695813, поданная 24 октября 2000 г., на “Систему и способ для логического моделирования распределенных компьютерных систем”.

Заявка на патент США №09/695820, поданная 24 октября 2000 г., на “Систему и способ для ограничения переносов данных и управления компонентами программного обеспечения распределенных компьютеров”.

Заявка на патент США №09/695821, поданная 24 октября 2000 г., на “Использование фильтров пакетов и виртуализации сети для ограничения сетевых коммуникаций”.

Заявка на патент США №09/696707, поданная 24 октября 2000 г., на “Систему и способ для создания логической модели распределенной компьютерной системы и распределение физических ресурсов в соответствии с логической моделью”.

Заявка на патент США №09/696752, поданная 24 октября 2000 г., на “Систему и способ обеспечения автоматической реализации стратегии в приложениях мультикомпьютерных услуг”.

ОБЛАСТЬ ТЕХНИКИ

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

За последние годы произошел заметный рост использования Интернета, который продолжает расширяться. Множество услуг (сервисов), предоставляемых всемирной паутиной (WWW), как электронная почта, покупки в сети, получение новостей и сбор информации, прослушивание музыки, просмотр видеоклипов, поиск работы и т.д., делают жизнь людей более комфортной. С ростом потребностей сетевых услуг сильно разрослись и компьютерные системы, предназначенные для поддержки (хостинга) сайтов и предоставления вычислительных машин с базами данных для этих сайтов, а также сохранения информации, связанной с этими сайтами.

Один из типов распределенной вычислительной системы - центр данных Интернета (ЦДИ, IDC) - представляет собой комплекс, спроектированный специально для использования множества компьютеров для оказания сетевых услуг. ЦДИ, известные также как “веб-фермы” или “группы серверов”, обычно вмещают от сотен до тысяч компьютеров в физически охраняемых зданиях с регулируемым климатом. Эти компьютеры соединены для выполнения одной и более программ, поддерживающих одну и более сетевых услуг или веб-сайтов. ЦДИ обеспечивает надежный доступ к сети, надежные источники питания и защищенную операционную среду. Другой тип распределенной вычислительной системы - центры данных предприятия (ЦДП, EDC). ЦДП подобны ЦДИ, но предназначены для предприятий.

Фиг.1 показывает ЦДИ 100. Он имеет много серверных компьютеров 102, размещенных в специально созданном помещении. Компьютеры представляют собой компьютеры общего назначения, обычно сконфигурированные как серверы. ЦДИ может быть создан для размещения единственного сайта для отдельного объекта (например, центр данных Yahoo! или MSN) или размещать множество сайтов для множества объектов (например, Exodus центр предоставляет место для сайтов множества компаний).

ЦДИ 100 проиллюстрирован с тремя объектами - объект A, объект B, объект C, которые совместно используют компьютерные ресурсы. Эти объекты представляют различные компании, которые хотят присутствия в сети. ЦДИ 100 имеет пул дополнительных компьютеров 104, который может использоваться объектами во время интенсивного трафика. Например, объект, занятый в сетевой продаже, может испытывать существенное повышение спроса в период рождественских праздников. Дополнительные компьютеры придают ЦДИ гибкость для удовлетворения этого спроса.

Сегодня большие ЦДИ сложны и часто призваны для размещения разнообразных приложений. Например, некоторые сайты могут использовать несколько тысяч компьютеров и принимать множество распределенных приложений. Эти распределенные приложения часто имеют сложные требования по организации сети, из-за которых операторам необходимо физически подключать компьютеры к надежным сетевым коммутаторам, а также вручную укладывать провода внутри ЦДИ для поддержки сложных приложений. В результате эта задача построения физической сетевой топологии, соответствующей прикладным требованиям, может быть длительным и трудоемким процессом, подверженным человеческим ошибкам. Поэтому существует потребность в улучшенных методах проектирования и развертывания распределенных приложений на физической вычислительной системе.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

Автоматизированное подсоединение компьютеров включает две операции. Первая операция - назначение принадлежности ВЛС к порту коммутатора, с которым соединен компьютер. Этот определенный порт коммутатора будет принимать пакеты, помеченные как принадлежащие указанной ВЛС. Вторая операция - создание виртуальных сетевых интерфейсов (ВСИ, VNIC) по единственному физическому сетевому интерфейсу (СИ, NIC) в каждом компьютере. Каждый ВСИ уникально представляет связанную с ним ВЛС. Это позволяет компьютеру с одним физическим СИ участвовать в нескольких ВЛС. Пакеты, связанные с конкретной ВЛС, направляются к компьютеру и обрабатываются через соответствующий ВСИ этой ВЛС.

Способность создавать виртуальную сетевую топологию позволяет архитекторам приложений создавать по существу любой тип сетевой конфигурации автоматически “на лету”. Для примера, архитектор может определить изоляционные зоны (т.е. “DMZ”) путем дистанционного назначения системы межсетевой защиты для ВЛС, назначая коммутаторы и добавляя серверы к ВЛС внутри данной зоны. Затем приложения могут быть развернуты на одной и той же вычислительной системе, где отдельные серверы содержат множество различных приложений.

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

Фиг.1 - традиционный центр данных Интернета (ЦДИ, IDC).

Фиг.2 - распределенная вычислительная система с физическими вычислительными ресурсами, которые могут быть автоматически настроены на поддержку одного и более распределенных приложений.

Фиг.3 - уровни платформенной архитектуры для автоматического проектирования, развертывания и управления распределенным приложением на распределенной вычислительной системе.

Фиг.4 - физическая сетевая топология приведенных для примера физических вычислительных ресурсов, которые могут быть использованы для размещения распределенных приложений.

Фиг.5 - виртуальная сетевая топология распределенного приложения, которое может размещаться на физических вычислительных ресурсах по фиг.4.

Фиг.6 - сервер, используемый в виртуальной сетевой топологии по фиг.4, и драйвер ВЛС, реализованной на сервере. Дополнительно фиг.6 показывает используемый менеджер ресурсов для развертывания физических ресурсов для распределенного приложения согласно виртуальной сетевой топологии.

Фиг.7 - процесс формирования виртуальной сетевой топологии из физических вычислительных ресурсов.

ПОДРОБНОЕ ОПИСАНИЕ

Ниже описано формирование виртуальной сетевой топологии для автоматизированного развертывания распределенного программного приложения на физических вычислительных ресурсах. Способность формирования произвольной виртуальной сетевой топологии из физической вычислительной системы обеспечивает создание заказных сетевых топологий для каждого распределенного приложения, которое размещается на той же самой распределенной вычислительной системе. Это особенно полезно для больших центров обработки данных, которые являются сложными и часто содержат множество приложений. Распределенное приложение, установленное в таких центрах, часто имеет сложные требования к организации сети и формированию физической сетевой топологии. Процесс согласования с этими требованиями может быть очень длительным, тяжелым и подверженным человеческим ошибкам. Возможность формирования виртуальной сетевой топологии, которая не требует физической перенастройки вычислительной системы для каждого развернутого приложения (например, новая укладка проводов, физическое подсоединение компьютеров к различным коммутаторам и т.д.), уменьшает зависимость от человеческих действий, сокращая затраты и вероятность человеческой ошибки.

Распределенная вычислительная система

Фиг.2 показывает распределенную вычислительную систему 200, которая по необходимости может быть автоматически развернута для поддержки одного и более распределенных приложений. Распределенная вычислительная система 200 включает совокупность множества серверов 202(1), 202(2), …, 202(N), связанных сетевыми коммутаторами 204. В одной из реализаций сетевые коммутаторы 204 являются не блокирующими Ethernet коммутаторами, но могут использоваться и другие типы коммутаторов. Сеть 204 проиллюстрирована как имеющая множество физических портов P₁, P₂, …, P_N, к которым соответственно подсоединены серверы 202(1)-202(N). Распределенная вычислительная система 200 содержит компьютеры с системой 206 выравнивания нагрузки и один и более компьютеров 208 с межсетевой защитой. Каждый из этих типов отображен подсоединенным к физическим портам P_N+1 и P_N+2 сетевых коммутаторов 204. Дополнительно помимо систем выравнивания нагрузки и межсетевой защиты распределенная вычислительная система может включать в себя и другие типы устройств специального назначения как кэш сети, акселераторы протоколов защищенных сокетов (SSL), подсоединенные сетевые хранилища (NAS) и т.д.

Распределенная вычислительная система 200 представляется физическими ресурсами, развернутыми в крупномасштабной вычислительной системе типа ЦДИ, в которых размещаются сетевые службы или, в более общем случае, центры обработки данных. Примерный центр обработки данных может включать от сотен до тысяч компьютеров, связанных локальной сетью.

Распределенная вычислительная система 200 также включает в себя один и более серверов 210 формирования виртуальной сетевой топологии, который показан подсоединенным к сетевому коммутатору 204 через физический порт P_N+3. Этот сервер 210 дает возможность прикладному архитектору создавать виртуальную сетевую топологию из распределенной вычислительной системы 200, так что множество распределенных приложений могут находиться на одной и той же системе 200. Распределенное приложение - программа, выполнение которой обеспечивается множеством компьютеров, соединенных сетью. Примерами таких приложений служат почтовые услуги, сайты, содержимое баз данных, сетевая торговля, хранилища, новостные и информационные услуги, услуги развлечения и т.д.

Для формирования виртуальной сетевой топологии сервер 210 создает, по меньшей мере, одну виртуальную локальную сеть (ВЛС) для каждого распределенного приложения. Затем сервер 210 направляет выбранные серверы и ассоциированные порты коммутатора на связь их с отдельной ВЛС. Сервер 210 формирования виртуальной сетевой топологии запускает один и более менеджеров 212 ресурсов, которые облегчают развертывание физического ресурса для соответствующих ВЛС, обслуживающих распределенные приложения. Менеджер(ы) 212 ресурсов взаимодействует(ют) с сервером 202, сетевым коммутатором 204, компьютером(ами) 206 выравнивания нагрузки и компьютером(ами) 208 межсетевой защиты, чтобы установить различные ВЛС так, что ассоциированные приложения могут надежно работать в изоляции друг от друга. Менеджер(ы) 212 ресурсов прослеживает(ют) формирование и выделение ВЛС, а также компьютеров, подсоединенных к этим ВЛС. Эта информация может сохраняться в базе данных, обслуживаемой менеджером(ами) 212 ресурсов в серверах 210 формирования виртуальной сетевой топологии. Сервер 210 также допускает настройку топологии приложений. Например, он может создавать изоляционные зоны (DMZ) в рамках приложения, чтобы изолировать критические компоненты.

Есть несколько путей использования виртуальных сетевых топологий. Например, для облегчения автоматизации. Сетевая топология может быть сформирована по запросу без вмешательства оператора, как описано более подробно ниже. Формирование виртуальной топологии также позволяет одной физической сети безопасно содержать множество приложений без их взаимного вмешательства. Формирование виртуальной топологии позволяет прикладному архитектору определять и предписывать отдельные изоляционные зоны для изоляции различных частей приложения. Такие зоны могут быть созданы оперативно за короткое время. Другое возможное использование формирования виртуальной топологии - объединение специализированных аппаратных ресурсов среди разнообразных распределенных приложений. Например, на фиг.2 пул компьютеров с системой выравнивания нагрузки может быть определен и подсоединен к любой точке физической сети. Затем система выравнивания может быть распределена из этого пула и помещена в виртуальную сеть приложения.

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

Архитектура Платформы

На фиг.3 показана платформенная архитектура 300 для автоматизированного проектирования, развертывания и управления распределенными приложениями на распределенной вычислительной системе 200. Архитектура 300 отображает различные уровни поверх базового уровня 302, представляющего физические вычислительные ресурсы распределенной вычислительной системы 200. Уровень 304 услуг автоматического развертывания обеспечивает инструментальные средства для преобразования машин в серверы, используемых в распределенной вычислительной системе 200. Такие инструментальные средства позволяют создание, редактирование и развертывание образов операционных систем (ОС, OS). Удаленное программирование машины выполняется полностью программируемыми интерфейсами, такими как WMI (Windows Management Instrumentation), являющимися программным интерфейсом в операционных системах MS Windows® и позволяющими настраивать и управлять системой и сетевыми устройствами.

Уровень 306 управления сетью находится выше уровня 304 услуг автоматического развертывания. Частично уровень управления сетью поддерживает модель драйвера для сетевых компьютеров, которая облегчает подсоединение отдельных компьютеров к одной и более ВЛС через единый физический сетевой интерфейс, подключенный к связанному порту сетевого коммутатора 204. Согласно модели драйвера ВЛС драйвер устанавливается на сервере и используется для создания ВСИ для каждой ВЛС. ВСИ всегда находятся выше сетевого интерфейса в IP стеке сервера так, чтобы обрабатываемые сервером пакеты проходили через более чем одну ВЛС даже при том, что все пакеты физически передаются через один физический СИ. Более подробно это описано ниже для фиг.6.

Модель драйвера дает возможность настройки ВЛС, помечая порты коммутатора, что позволяет передавать пакеты данных в распределенной вычислительной системе с маркерами (тегами), идентифицирующими ВЛС, к которым принадлежат коммутаторы. Сетевые коммутаторы 204 обусловливают маркировку и принимают только пакеты с маркерами, идентифицирующими определенные ВЛС, к которым принадлежат коммутаторы. В одном из вариантов сетевые коммутаторы 204 могут иметь маркированные и немаркированные порты. Маркированные порты коммутатора помечаются идентификаторами ВЛС и используются для подключения к маркированным портам других коммутаторов. Это обеспечивает быструю передачу пакетов через сеть коммутаторов. Немаркированные порты коммутатора используются для подключения к серверам 202 или компьютерам 206, 208. Когда пакеты достигают порта коммутатора адресованного сервера, маркеры ВЛС удаляются из пакетов до вхождения в серверы, поэтому серверам нет необходимости знать о маркировке.

Уровень управления физическими ресурсами находится над уровнем 306 управления сетью. Уровень 308 управления физическими ресурсами обслуживает физическую модель распределенной вычислительной системы 200, прослеживая принадлежность и координируя выделение всех физических вычислительных ресурсов. Более того, уровень 308 управления физическими ресурсами обслуживает групповое распределение ресурсов, таким образом допуская динамическую конфигурацию и управление физическими вычислительными ресурсами.

Уровень 310 управления логическими ресурсами расположен над уровнем 308 управления физическими ресурсами. Уровень 310 управления логическими ресурсами облегчает распределение логического ресурса, запрашиваемого распределенным приложением. Например, приложение может запросить такие ресурсы, как базы данных, службы выравнивания нагрузки, межсетевую защиту и другие сетевые службы. Уровень 310 управления логическими ресурсами выставляет такие логические ресурсы.

Следующий уровень - уровень 312 модели определения сервиса и выполнения, который обеспечивает описание распределенного приложения и прослеживание ее операций. Модель определения услуг (SDM) обеспечивает именованное пространство, контекст описания операционных процессов и программный интерфейс (API) для анализа приложения и управления ресурсами приложения. Более того, это дает возможность операторам и разработчикам совместно использовать общие представления о приложениях.

Шестой уровень над уровнем 200 вычислительных ресурсов - уровень 314 компонентов. Этот уровень обеспечивает определение многократно используемых строительных блоков распределенного приложения, которые используют интерфейсы программирования приложений SDM для контекста, именования и связывания. Эти блоки упоминаются как "компоненты".

Наивысший уровень - уровень 316 логики операций, который вмещает операционные аспекты распределенного приложения. Логика операций ответственна за запуск сервиса, расширение и сжатие сервиса, обновление и откат, обнаружение ошибок и восстановление и за состояние разделения. Логика операций допускает повторное использование проверенных операционных методов развертывания и приложений. Через использование уровня SDM логика операций имеет контекст для лучшего понимания проблем, которые могут возникать. Например, когда происходит отказ, логика операций может решить, что отказ произошел во внешнем интерфейсе почтовой службы, а не в каком-то сервере в середине помещения.

Виртуальные сетевые топологии

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

Фиг.4 показывает физическую сетевую топологию 400, имеющую типичное расположение пяти серверов 402(1)-402(5), связанных через сетевой коммутатор 404. Каждый сервер 402 физически соединен с соответствующим портом P₁-P₅ сетевого коммутатора 404. Для целей обсуждения принимается, что сетевой коммутатор реализован как один и более Ethernet коммутаторов.

Виртуальная сетевая топология может быть создана для представления распределенных приложений, выполняющихся на физических вычислительных ресурсах 400. В этом типичном исполнении виртуальная сетевая топология создана с использованием Ethernet коммутаторов, ВЛС и ВСИ. Ethernet сети позволяют сегрегацию во множество ВЛС для сетевой изоляции. Узлы ВЛС могут свободно связываться с другими узлами той же ВЛС, но не могут непосредственно обращаться к узлам вне ее. ВЛС могут быть реализованы как ВЛС на основе портов или как ВЛС на основе протокола. В первом случае ВЛС формируются в пределах одного коммутатора, во втором случае ВЛС может охватывать множество коммутаторов. ВЛС, основанные на протоколах, стандартизированы согласно IEEE 802.1Q. Стандарт IEEE 802.1Q описывает маркирование пакетов и поддержку ВЛС. Этот стандарт описывает расширение пакета 802.1Q через маркирующий заголовок, поскольку каждый пакет (кадр) маркируется информацией 802.1Q путем добавления маркирующего заголовка к кадру.

Размещение двух и более компьютеров в ВЛС является физическим эквивалентом подсоединения этих компьютеров к той же самой физической сети. Это свойство расширено до создания произвольной виртуальной топологии поверх физической сети. Предположим, например, что приложение запрашивает три сетевых сервера 402(1), 402(3) и 402(5) и одну базу данных на сервере 402(2). Кроме того, пусть прикладной архитектор заинтересован в безопасности и хотел бы разместить сетевые серверы 402(1), 402(3) и 402(5) в одной изоляционной зоне, а сервер базы данных 402(2) в другой и соединить обе изоляционные зоны с системой межсетевой защиты.

Фиг.5 показывает виртуальную сетевую топологию 500, которая может быть сформирована из физических ресурсов 400 из фиг.4, для достижения целей прикладных архитекторов. Виртуальная сетевая топология 500 имеет две ВЛС: WEB VLAN (ВЛС глобальной сети) 502 и DB VLAN (ВЛС базы данных) 504. Сетевые серверы 402(1), 402(3) и 402(5) помещены в ВЛС 502, а сервер базы данных 402(2) помещен в ВЛС 504. Система межсетевой защиты развернута на сервере 402(4), который соединен с ВЛС 502 и ВЛС 504. Система межсетевой защиты 402(2) создает две изоляционные зоны для приложений, представленных DMZ_Web 506 и DMZ_DB 508.

В этом примере сервер 402(4) межсетевой защиты является членом двух ВЛС. Однако сервер имеет только один физический интерфейс для подключения к порту P₄ сетевого коммутатора 404. Чтобы обеспечить возможность отдельному физическому интерфейсу обслуживать две ВЛС, на сервере 402(4) устанавливается драйвер ВЛС для создания двух ВСИ таким образом, что физический СИ соединяется с двумя ВЛС. С точки зрения сервера, каждый ВСИ проявляется как физическое подсоединение к отдельной сети.

Фиг.6 показывает сервер 402(4) межсетевой защиты более подробно. Он реализует драйвер 602 ВЛС, который установлен в стеке протоколов между драйвером 604 СИ и IP-драйвером 606. В одном из вариантов драйвер 602 ВЛС загружается и устанавливается менеджером 212 ресурсов. Драйвер 604 СИ может обрабатывать весь трафик пакетов через физическое соединение к порту P₄ коммутатора 404. Драйвер 602 ВЛС привязывается к физическому сетевому интерфейсу и создает один и более ВСИ над каждым физическим сетевым интерфейсом. Каждый ВСИ уникально идентифицирует ВЛС. В этом примере ВЛС 602 создает два ВСИ: ВСИ ВЛС_Web 608 для Web-ВЛС 502 и ВСИ ВЛС_DB 610 для DB ВЛС 504 базы данных.

Выходящие пакеты, предназначенные для конкретной ВЛС, маркированы идентификатором соответствующей ВЛС, связанной с ВСИ. Приложение выбирает соответствующую ВЛС, непосредственно привязываясь к определенному ВСИ. Затем пакеты посылаются по физическому интерфейсу сетевому коммутатору. Коммутатор проверяет маркер ВЛС и устанавливает, с какой ВЛС связан пакет. Аналогично маркированы входящие пакеты. Соответствующий ВСИ получает пакеты, удаляет маркер и пропускает пакеты дальше к IP-драйверу для использования в соответствующем приложении. Это позволяет серверу с одним физическим СИ участвовать в нескольких ВЛС.

Сервер 210 формирования виртуальной сетевой топологии показан подсоединенным к коммутатору 404. Используя методы дистанционного программирования, этот сервер 210 может загрузить и установить драйвер ВЛС на сервере межсетевой защиты (если он еще не существует) и затем выдать команды для создания ВСИ для виртуальной сетевой топологии. Отметим, что если сервер является членом только одной ВЛС (например, сетевые серверы 402(1), 402(3), 402(5) и сервер 402(2) базы данных), то нет никакой потребности устанавливать драйвер 602 ВЛС или создавать ВСИ. Сетевой интерфейс может определять соответствующее физическое подключение к порту коммутатора, и порт коммутатора может быть настроен с соответствующим ВЛС членством, направляя весь трафик к/от сервера через ВЛС. С другой стороны, нет никаких препятствий к установке ВЛС драйвера и создания отдельного ВСИ, даже если сервер используется только для одной ВЛС.

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

Формирование виртуальных сетевых топологий

Фиг.7 отображает процесс 700 формирования виртуальной сетевой топологии, чтобы обслуживать распределенное приложение и развертывать для него ресурсы. Процесс 700 показан последовательностью блоков, которые представляют операции, выполняемые различными компьютерами в вычислительной системе 200. Операции могут быть реализованы программным обеспечением, которое может выполняться на различных компьютерах. Также блоки представляют команды, сохраненные на читаемых компьютером носителях и которые могут быть выполнены процессором для исполнения связанных операций.

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

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

После того как архитектура приложения и экземпляры компонентов приложения определены, менеджер 212 ресурсов реализуется на сервере 210 формирования виртуальной сетевой топологии с использованием ВЛС и ВСИ, чтобы реализовать отображение виртуальной сетевой топологии в физическую сеть. В блоке 706 сервер 210 формирования виртуальный сетевой топологии создает, по меньшей мере, одну ВЛС для каждого приложения. Виртуальная сетевая топология одного приложения может использовать более одной ВЛС, чтобы установить несколько изоляционных зон, что приведено для виртуальной сетевой топологии 500 на фиг.5. В этом примере сервер 210 формирования виртуальной сетевой топологии формирует две ВЛС: ВЛС 502 Web и ВЛС 504 базы данных. Сетевые серверы 402(1), 402(3), 402(5) изолированы от сервера 402(2) базы данных путем создания двух изоляционных зон DMZ_Web 506 и DMZ_DB 508.

В блоке 708 менеджер 212 ресурсов на сервере 210 формирования виртуальной сетевой топологии развертывает физический вычислительный ресурс для соответствующих ВЛС. Другими словами, менеджер 212 ресурсов назначает физические ресурсы из физической сети 400 (фиг.4) для обслуживания виртуальной сетевой топологии приложения. Это развертывание включает две подоперации, обозначенные как блоки 708(1) и 708(2) на фиг.7.

В блоке 708(1) менеджер 212 ресурсов назначает внешний порт сетевых коммутаторов 404 (т.е. порт, который подсоединен к серверу) к указанной ВЛС, к которой принадлежит сервер. Настройки внешнего порта коммутатора позволяют ему быть членом более чем одной ВЛС.

В блоке 708(2) менеджер 212 ресурсов создает ВСИ на сервере для обеспечения информационного обмена по указанной ВЛС, так что сервер может стать членом ВЛС. Отметим, что эта операция необязательна, если сервер - член только одной ВЛС (например, сетевые серверы 402(1), 402(3), 402(5) и сервер 402(2) базы данных). В этом случае настройка порта коммутатора с ВЛС членством адекватна, потому что сервер будет осуществлять связь только посредством одной ВЛС. Коммутатор предполагает, что весь трафик от сервера предназначен для одной настроенной ВЛС. Когда сервер является членом двух и более ВЛС (например, сервер 402(4) межсетевой защиты), на сервере устанавливается ВЛС драйвер. ВЛС драйвер связывается с физическим сетевым интерфейсом и создает два и более ВСИ поверх физического. Каждый виртуальный сетевой интерфейс представляет уникальную идентификацию ВЛС. Коммутатор проверяет маркер ВЛС и устанавливает, с какой ВЛС связан пакет.

Физические вычислительные ресурсы продолжают использоваться таким способом с двумя операциями, пока приложение не будет полностью установлено, как представлено блоком 710 решений.

Чтобы проиллюстрировать развертывание физических ресурсов, рассмотрим, как менеджер 212 ресурсов развертывает компьютеры для виртуальной сетевой топологии 500 по фиг.5. Этот процесс будет описан со ссылками на фиг.5 и 6. Первоначально, две ВЛС: ВЛС 502 Web и ВЛС 504 базы данных - формируются операцией 706. Затем, предположим, что менеджер 212 ресурсов решает добавить сервер 402(4) межсетевой защиты к ВЛС 502 Web, чтобы определить изоляционную зону DMZ_Web 506. Менеджер 212 ресурсов сообщает коммутатору 404, что нужно установить для порта 4 ссылку на ВЛС 502 Web, как показано на фиг.6, добавлением идентификации "VLAN_Web" к порту 4. Это представляется операцией 708(1) в процессе 700. Коммутатор 404 теперь понимает, что это - часть изоляционной зоны DMZ_Web 506. Затем менеджер 212 ресурсов направляет драйвер 602 ВЛС на сервер 402(4) межсетевой защиты, чтобы создать ВСИ для ВЛС Web, это показано как ВСИ-ВЛС_Web 604. В процессе 700 это представлено операцией 708(2). Пакеты, пропускаемые через ВСИ-ВЛС_Web 604, отмечены идентификацией VLAN_Web и корректно передаются коммутатором 404 по ВЛС 502 Web.

Теперь предположим, что менеджер 212 ресурсов добавляет тот же самый сервер 402(4) межсетевой защиты к ВЛС 504 базы данных, чтобы определить другую изоляционную зону DMZ_DB 508. Менеджер 212 ресурсов сообщает коммутатору 404, что нужно установить в порт 4 дополнительно ссылку на ВЛС 504 базы данных, что проиллюстрировано на фиг.6 добавлением идентификации "VLAN_DB" к порту 4. В процессе 700 это опять представляется операцией 708(1). Коммутатор 404 теперь также является частью изоляционной зоны DMZ_DB 508 и будет принимать пакеты с идентификацией VLAN_DB. Затем менеджер 212 ресурсов выдает команду драйверу 602 ВЛС в сервере 402(4) межсетевой защиты, чтобы создать второй ВСИ, но на этот раз для ВЛС базы данных, что проиллюстрировано на фиг.6 как ВСИ-ВЛС_DB 606. Это другое представление операции 708(2) в процессе 700. Пакеты, пропускаемые через ВСИ-ВЛС_DB 606, помечены идентификацией VLAN_DB и корректно маршрутизируются коммутатором 404 по ВЛС 504 базы данных.

Процесс может быть повторен для соединения каждого сетевого сервера 402(1), 402(3) и 402(5) к ВЛС 502 Web и сервера базы данных к ВЛС 504 базы данных. Как отмечалось выше, добавление этих серверов может быть выполнено простой настройкой соответствующих коммутационных портов P₁, P₂, P₃ и P₅ на соответствующее ВЛС членство. Нет нужды создавать ВСИ на серверах, так как серверы в данный момент являются частью одной ВЛС.

Иллюстративные интерфейсы программирования приложений (API) менеджера ресурсов

Следующий раздел предоставляет приведенный для примера набор API, обеспечиваемых менеджером 212 ресурсов (МР, RM) для удаленной настройки коммутаторов и серверов. API используются для установки ВЛС, подключения коммутаторов к соответствующим ВЛС и создания ВСИ на серверах для облегчения информационного обмена по связанным ВЛС, таким образом реализуя отображение топологий виртуальной сети на физические сетевые ресурсы. Отметим, что это отображение топологии выполняется с использованием внутриполосных методов по существующей сети, а не с использованием специализированной внеполосной сети. Соответственно существует возможность соединения по умолчанию, с которого все начинается. Таким образом, обеспечивается основа для настройки новых ВЛС по необходимости.

Формирование и отмена виртуальных топологий облегчается следующими основными сетевыми методами, предоставляемыми МР:

AllocateVlan() ConstructVlan()

AttachCumputerToVlan()

DetachComputerFromVlan()

ReleaseVlan()

Далее перечисляются примерные интерфейсы, предоставляемые МР, включая обсуждение этих пяти сетевых методов:

Register

///

/// IP адрес машины.

/// Возвращает экземпляр компонента этого менеджера ресурсов.

///

///При повторном вызове метода возвращается только экземпляр компонента этого менеджера

///ресурсов.

///

[WebMethod(Description=”Регистрирует менеджера ресурсов из рабочего цикла.”)]

public void Unregister(string runtimeAddress)

Unregister

///

/// IP адрес рабочего цикла, регистрация из которого будет ///удалена.

///

/// Ничего не делает при повторном вызове.

///

[WebMethod(Description=”Удаляет регистрацию менеджера ресурсов из рабочего цикла.”)]

public void Unregister(string runtimeAddress)

RegisterComputer

///

///

///сетевой менеджер ресурсов (СМР, NRM) имеет разрешение обновлять виртуальный интерфейс

///компьютера и IP адресацию. В противном случае неуправляемый компьютер

///перемещается в указанную VLAN и недоступен (вызывающий должен создать

///надлежащий виртуальный интерфейс на компьютере).

///

[WebMethod(Description=”Регистрация компьютера сетевым менеджером ресурсов.”)]

public void RegisterComputer(NrmComputer computer)

RegisterDevice

///

/// Идентификатор компьютера, регистрация которого удаляется.

/// Идентификатор устройства, регистрация которого удаляется.

/// Идентификация владельца выделенного ресурса.

/// Возвращает VLAN идентификатор новой распределенной VLAN.

///

///Распределение выполняется только в базе данных сетевых ресурсов и не влияет на

///сеть. Необходим вызов 'ConstructVlan' для создания текущей VLAN в сетевом

///окружении.

///

[WebMethod(Description=”Распределение VLAN”)]

///

///Предшествующее состояние:

///Число доступных VLAN в пределах сетевой структуры определяется тремя факторами:

///типом и конфигурацией физических коммутаторов, числом зарезервированных VLAN

///для внутреннего использования и предыдущими операциями распределения VLAN. В

///настоящее время текущий теоретический диапазон VLAN от 1 до 4095, фактическое

///число может быть ограничено реализацией VLAN на коммутаторе. Например,

///коммутатор может поддерживать диапазон только от 1 до 1001 с максимальным ///распределением VLAN 256. Информация об архитектуре коммутатора, резервные VLAN

///для внутреннего использования и уже распределенные VLAN прослеживаются в

///постоянной базе данных.

///

///Описание:

/// 1. Проверка правильности параметра. OwnerId должен быть не нулевым.

/// 2. Блокировка базы данных от транзакций.

/// 3. Проверка базы данных на наличие возможности распределения новой VLAN без ///превышения разрешенного максимума текущей сетевой структурой.

/// 4. Если распределение VLAN запрещено, то вызвать исключение и удалить блокировку базы

/// данных.

/// 5. Создать новую строку в базе данных, которая будет представлять запись

///распределенной VLAN. Идентификатор VLAN определяется линейным просмотром записей ///существующих VLAN для нахождения первого доступного (не распределенного) идентификатора.

/// 6. Совершить транзакцию.

/// 7. Возвратить идентификатор распределенной VLAN вызывающему.

///

public int AllocateVlan(long ownerId)

AllocateVlanWithId

///

///Идентификатор распределяемой VLAN.

///

///Распределение выполняется только в базе данных сетевых ресурсов и не влияет на сеть.

///Необходим вызов 'ConstructVlan' для создания текущей VLAN в сетевом

///окружении. Невозможно распределение VLAN по умолчанию.

///

[WebMethod(Description=”Распределение конкретной VLAN.”)]

public void AllocateVlanWithId(long ownerId, int vlanId)

ConstructVlan

///

/// Идентификатор подсоединяемого компьютера.

/// VLAN является маркированной и требует VLAN

///драйвер.

///

///VLAN, указанной в режиме маркировки. Для этого требуется использование

///компьютером виртуального VLAN драйвера для создания виртуального интерфейса,

///для VLAN, чтобы она имела доступ к сети. Компьютер может существовать во множестве

///маркированных VLAN, и только в одной немаркированной. Невозможно смешивать

///маркированные и немаркированные VLAN.

///

///“Управляемый” компьютер - компьютер, содержащий драйвер маркированной VLAN

///(драйвер маркера VLAN), и сетевой менеджер ресурсов имеет разрешение

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

///Если аргумент 'managed' сеть “true”, то и аргумент 'tagged' должен быть “true”. Если

///аргумент “managed” есть “false”, а аргумент “tagged” - “true”, то вызывающий должен

///создать виртуальный интерфейс на компьютере.

///

[WebMethod(Description=”Подсоединение компьютера к указанной VLAN.”)]

///

///Предшествующее состояние:

///

///Подсоединяемый компьютер зарегистрирован в СМР для обеспечения данных

/// о проводном соединении между физическими СИ на компьютере и подсоединенным

///портом коммутатора. Указанная VLAN успешно сформирована.

///

/// Описание:

/// 1. Блокировка базы данных от транзакций.

/// 2. computerId должен существовать в базе данных с подробными данными о топологии.

/// 3. vlanId должен существовать в базе данных в состоянии “сформирована”.

/// 4. Добавление нового ВСИ на указанный компьютер для предоставленной VLAN

/// идентификатора, используя удаленный вызов.

/// 5. Для каждого коммутатора в базе данных привязка порта коммутатора, физически

///связанного с компьютером, к VLAN идентификатору, используя специфический для устройства ///драйвер для коммутатора.

/// 6. Добавление новой записи “подсоединен” в базу данных, чтобы указать связь компьютера

///с VLAN.

/// 7. Совершить транзакцию.

///

public string AttachComputerToVlan(long computerId, in vlanId, bool tagged, bool managed)

DetachComputerFromVlan

///

/// Идентификатор отсоединяемого компьютера.

///Идентификатор подсоединяемого компьютера.

///Целевой компьютер управляемый.

///

///Возвращает IP адрес и маску подсети, используемые для доступа к компьютеру в

///указанной VLAN.

///

///

///Если аргумент “tagged” есть “true”, то компьютер будет подсоединен к VLAN указанной в

///маркированном режиме. При этом от компьютера требуется использование

///виртуального VLAN драйвера для создания виртуального интерфейса той VLAN для

///доступа к сети. Компьютер может существовать в нескольких маркированных VLAN, но

///только в одной немаркированной VLAN. Невозможно смешивать маркированные и

///немаркированные VLAN.

///

///”Управляемый” компьютер - компьютер, содержащий драйвер маркера VLAN, и сетевой

///менеджер ресурсов имеет разрешение изменять виртуальный интерфейс компьютера

///и IP адресацию. Если компьютер неуправляемый, то он перемещается в указанную

///VLAN и остается недоступным. Если аргумент “managed” есть “true”, то аргумент

/// “tagged” должен быть “true”. Если “managed” есть “false” и “tagged” есть “true”, то

///вызывающий должен создать виртуальный интерфейс на компьютере.

///

[WebMethod(Description=”Подсоединение компьютера к внешней VLAN.”)]

public string AttchComputerToExternal(long computerId, bool tagged, bool managed)

DetachComputerFromExternal

///

///Целевой компьютер управляем.

///

/// Если флаг 'managed' установлен, СМР требует удаленного доступа к драйверу маркера

///VLAN, и виртуальный интерфейс VLAN будет удален с указанного компьютера. Если

///удаленный компьютер потерпел неудачу, установить параметр “managed” в “false”.

///

[WebMethod(Description=”Отcоединить компьютер от внешней VLAN.”)]

public void DetachComputerFromExternal(long computerId, bool managed)

ReleaseVlan

///

///Идентификатор компьютера в аппаратном менеджере ресурсов

///(HRM).

///Объект, представляющий владельца ресурсов.

///

[WebMethod(Description=”Освободить все сетевые ресурсы указанного владельца.”)]

public void ReleaseResourcesByOwner(long ownerId)

ReleaseResourcesByComputer

///

///Целевой компьютер управляемый.

///

///Освободить все VLAN, подсоединенные к данному компьютеру. Обычно используется

///логикой очищения для удаления компьютера из сети. Если флаг “managed” установлен,

///СМР требует удаленного доступа к драйверу маркера VLAN, и все созданные

///виртуальные интерфейсы VLAN будут удалены с указанного компьютера. Если

///на удаленном компьютере произошла ошибка, установить параметр “managed” в “false”.

///

[WebMethod(Description=” Освободить все сетевые ресурсы указанного владельца.”)]

Public void ReleaseResourcesByComputer(long computerId, bool managed)

QueryConfiguration

///

///Значение NrmConfiguration.

[WebMethod(Description=”Запрос параметров настройки.”)]

public NrmConfiguration QueryConfiguration()

QueryComputer

///

/// Значение NrmComputer.

[WebMethod(Description=”Запрос о зарегистрированном сетевом компьютере.”)]

public NrmComputer QueryComputer()

QueryComputerIpAddress

///

/// VLAN идентификатор для запроса IP адреса.

///

///Возвращает IP адрес для доступа в указанной VLAN.

///

///

///Для каждой VLAN, компьютер, присоединенный к ней, должен иметь фиксированный

///(статический) IP адрес для удаленного доступа к нему через указанную VLAN.

///

[WebMethod(Description=” Запрос IP адреса компьютера в указанной VLAN.”)]

public string QueryComputerIpAddress(long computerId, int vlanId)

QueryComputers

///

///Массив значений NrmComputer.

[WebMethod(Description=”Запрос обо всех зарегистрированных сетевых компьютерах.”)]

public NrmComputer[] QueryComputers()

QueryDevice

///

/// Значение NrmDevice

///

[WebMethod(Description=”Запрос о зарегистрированном сетевом устройстве.”)]

public NrmDevice QueryDevice(long deviceId)

QueryDevice

///

Формула