КОМПЬЮТЕРНАЯ СИСТЕМА И СПОСОБ ОСУЩЕСТВЛЕНИЯ СВЯЗИ В КОМПЬЮТЕРНОЙ СИСТЕМЕ
COMPUTER SYSTEM AND METHOD FOR COMMUNICATION IN COMPUTER SYSTEM

Область техники, к которой относится изобретение
Настоящее изобретение относится к компьютерной системе и способу осуществления связи в компьютерной системе и, в частности, относится к компьютерной системе, использующей метод OpenFlow.
Предшествующий уровень техники
При осуществлении связи с использованием Ethernet (зарегистрированный товарный знак) гибкость физической линии связи, которую можно использовать в сети, утрачивается вследствие протокола связующего дерева (STP) и, соответственно, постепенно утрачивается возможность осуществления связи по множественным маршрутам.
Для решения проблемы предложено управление маршрутами посредством OpenFlow (см. непатентный источник 1). Компьютерная система, использующая метод OpenFlow, раскрыта, например, в JP 2003-229913A (патентный источник 1). Сетевой коммутатор, соответствующий методу (далее именуемый программируемым коммутатором потоков (PFS), сохраняет подробную информацию, например, тип протокола и номер порта, в таблице потоков и может управлять потоком. Следует отметить, что PFS также именуется коммутатором OpenFlow.
На фиг.1 показана схема, демонстрирующая пример конфигурации компьютерной системы, использующей метод OpenFlow. Согласно фиг.1 программируемый контроллер 100 потоков (PFC, именуемый открытым контроллером потоков) задает элемент потока для PFS 200 и 300 в единичной подсети (сети P-потока) для осуществления управления потоками в подсети.
Каждый из PFS 200 и 300 обращается к своей таблице потоков для выполнения действия (например, ретрансляции и выбраковки пакета данных), заданного в элементе потока и соответствующего информации заголовка принятого пакета. В частности, в случае приема пакета переносимый между хостами (HOST) 400 каждый из PFS 200 и 300 выполняет действие, заданное в элементе потока, если информация заголовка принятого пакета согласуется с (совпадает с) (правилом) элементом потока, заданным в его собственной таблице потоков. С другой стороны, когда информация заголовка принятого пакета не согласуется с (совпадает с) (правилом) элементом потока, заданным в его собственной таблице потоков, каждый из PFS 200 и 300 распознает принятый пакет как первый пакет, информирует PFC 100 о приеме первого пакета и передает информацию заголовка пакета на PFC 100. PFC 100 задает элемент потока (поток + действие), соответствующий сообщаемой информации заголовка, для PFS, который является источником информирования первого пакета.
Как описано выше, в традиционном методе OpenFlow после того, как любой из PFS 200 и 300 принимает пакет, переносимый между хостами 400, управление переносом осуществляется в отношении пакета, передаваемого и принимаемого между хостами 400 посредством PFC 100.
Библиография
Патентный источник 1: JP 2003-229913A.
Непатентный источник 1: OpenFlow Switch Specification Version 1.0.0 (Wire Protocol 0x01) December 31, 2009.
Сущность изобретения
PFC в традиционном методе OpenFlow задает маршрут пакета, переносимого между исходным терминалом и терминалом-адресатом, и задает элемент потока для коммутаторов на маршруте. Кроме того, даже при наличии одного и того же пункта назначения, элемент потока и маршрут между исходным терминалом и терминалом-адресатом необходимо задавать всякий раз при генерации на исходном терминале другого пакета. Таким образом, при использовании метода OpenFlow существует опасность того, что ресурсы системы в целом (количество элементов потока) будут расходоваться в большом объеме.
Компьютерная система настоящего изобретения включает в себя контроллер; множество коммутаторов, каждый из которых осуществляет операцию ретрансляции, определенную в элементе потока, заданном контроллером, в отношении пакета, согласующегося с элементом потока; и множество узлов, осуществляющих связь через любой из множества коммутаторов. Контроллер задает адрес пункта назначения как правило элемента потока и задает обработку переноса для узла-адресата как действие элемента потока. Каждый из множества коммутаторов переносит пакет, содержащий адрес пункта назначения, на узел-адресат на основании элемента потока, заданного для коммутатора, независимо от адреса источника пакета приема.
Кроме того, желательно, чтобы контроллер задавал элемент потока для каждого из множества коммутаторов до переноса пакета среди множества узлов.
Кроме того, желательно, чтобы контроллер получал первый адрес MAC (управления доступом к среде) первого узла из множества узлов в ответ на первый запрос ARP (протокола разрешения адресов) от первого узла и задавал первый MAC-адрес для каждого из множества коммутаторов как правило элемента потока.
Кроме того, желательно, чтобы контроллер передавал на первый узел ответ ARP, имеющий MAC-адрес другого узла из множества узлов в качестве источника передачи, как ответ на первый запрос ARP от первого узла на другой узел.
Кроме того, контроллер получает первый адрес MAC (управления доступом к среде) первого узла (VM1) на основании первого запроса ARP (протокола разрешения адресов) от первого узла из множества узлов и задает первый MAC-адрес для каждого из множества коммутаторов как правило элемента потока. Кроме того, желательно, чтобы контроллер выдавал второй запрос ARP и задавал второй MAC-адрес второго узла полученный на основании ответа на второй запрос ARP, для каждого из множества коммутаторов как правило элемента потока.
Кроме того, контроллер передает на первый узел ответ ARP, имеющий MAC-адрес упомянутого другого узла в качестве адреса источника в ответ на первый запрос ARP, адресованный другому узлу, от первого узла. Кроме того, желательно, чтобы контроллер передавал на другой узел ответ ARP на третий запрос ARP, адресованный первому узлу и переданный от другого узла.
Кроме того, желательно, чтобы множество коммутаторов включало в себя множество первых коммутаторов, непосредственно подключенных к множеству узлов. В этом случае желательно, чтобы контроллер задавал элемент потока для произвольно выбранных коммутаторов из множества первых коммутаторов, не задавая его для оставшихся коммутаторов.
Кроме того, желательно, чтобы контроллер задавал элемент потока для каждого из множества коммутаторов для осуществления маршрутизации ECMP (выбора множественных маршрутов одинаковой стоимости) на пакете приема.
Способ осуществления связи по настоящему изобретению включает в себя этап задания контроллером элемента потока для каждого из множества коммутаторов; этап осуществления каждым из множества коммутаторов операции ретрансляции, заданной в элементе потока, в отношении пакета приема, согласующегося с элементом потока, заданный контроллером; и этап осуществления связи каждым из множества узлов через каждый из множества коммутаторов. Задание элемента потока включает в себя этап задания контроллером адреса пункта назначения как правила элемента потока; и этап задания обработки переноса для узла-адресата как действия элемента потока. Осуществление связи включает в себя перенос каждым из множества коммутаторов пакета приема, содержащего адрес пункта назначения, на узел-адресат независимо от адреса передачи источника пакета приема.
Кроме того, желательно, чтобы задание элемента потока осуществлялось до переноса пакета среди множества узлов.
Согласно настоящему изобретению можно уменьшить потребление ресурсов компьютерной системы в целом, использующей метод OpenFlow.
Краткое описание чертежей
Другие задачи, эффекты и признаки вышеупомянутого изобретения станут более очевидными на основании описания примерных вариантов осуществления, приведенного совместно с прилагаемыми чертежами:
фиг.1 - схема, демонстрирующая пример конфигурации компьютерной системы, использующей метод OpenFlow;
фиг.2 - схема, демонстрирующая пример конфигурации компьютерной системы согласно настоящему изобретению;
фиг.3A - схема, демонстрирующая пример способа задания потока и способа осуществления связи в компьютерной системе согласно настоящему изобретению;
фиг.3B - схема, демонстрирующая пример способа задания потока и способа осуществления связи в компьютерной системе согласно настоящему изобретению;
фиг.3C - схема, демонстрирующая пример способа задания потока и способа осуществления связи в компьютерной системе согласно настоящему изобретению;
фиг.3D - схема, демонстрирующая пример способа задания потока и способа осуществления связи в компьютерной системе согласно настоящему изобретению;
фиг.3E - схема, демонстрирующая пример способа задания потока и способа осуществления связи в компьютерной системе согласно настоящему изобретению;
фиг.3F - схема, демонстрирующая пример способа задания потока и способа осуществления связи в компьютерной системе согласно настоящему изобретению;
фиг.3G - схема, демонстрирующая пример способа задания потока и способа осуществления связи в компьютерной системе согласно настоящему изобретению;
фиг.3H - схема, демонстрирующая пример способа задания потока и способа осуществления связи в компьютерной системе согласно настоящему изобретению;
фиг.3I - схема, демонстрирующая пример способа задания потока и способа осуществления связи в компьютерной системе согласно настоящему изобретению;
фиг.3J - схема, демонстрирующая пример способа задания потока и способа осуществления связи в компьютерной системе согласно настоящему изобретению; и
фиг.4 - схема, демонстрирующая конфигурацию логической сети, разделенной на множество сетей вследствие управления потоками, согласно настоящему изобретению.
Описание примерных вариантов осуществления
Далее примерные варианты осуществления настоящего изобретения будут описаны со ссылкой на прилагаемые чертежи. В чертежах одинаковые или аналогичные ссылочные позиции назначены одинаковым или аналогичным компонентам.
Конфигурация компьютерной системы
Согласно фиг.2 будет описана конфигурация компьютерной системы согласно настоящему изобретению. На фиг.2 показана схема, демонстрирующая пример конфигурации компьютерной системы согласно настоящему изобретению. Компьютерная система согласно настоящему изобретению включает в себя программируемый контроллер 10 потоков (далее именуемый PFC 10), множество программируемых коммутаторов 20-1 - 20-3 и 30-1 - 30-3 потока (далее именуемых PFS 20-1 - 20-3 и 30-1 - 30-3), физические серверы 40-1 - 40-5 (далее именуемые SV 40-1 - 40-5), и хранилище 50, которые соединены через сеть связи. При этом когда PFS 20-1 - 20-3 и 30-1 - 30-3 описаны без различения их между собой, каждый из PFS 20-1 - 20-3 и каждый из PFS 30-1 - 30-3 именуются PFS 20 и PFS 30 соответственно. И когда SV 40-1 - 40-5 описаны без различения их между собой, каждый из SV 40-1-40-5 именуется SV 40.
SV 40 и хранилище 50 являются компьютерными блоками, каждый из которых имеет центральный процессор (ЦП), главный блок хранения и внешнее запоминающее устройство, которые не показаны на фигуре, и осуществляют связь с другими SV 40 путем выполнения программы, хранящейся во внешнем запоминающем устройстве. Связь с SV 40 осуществляется через PFS 20 и 30. В соответствии с выполняемой программой SV 40 осуществляет функцию, представленную веб-сервером, файловым сервером, сервером приложений, клиентским терминалом и пр. Например, когда SV 40 выступает в качестве веб-сервера, SV 40 переносит документ HTML и данные изображения из блока хранения (не показан) на другой SV 40 (например, клиентский терминал) в соответствии с запросом клиентского терминала, который не показан.
SV 40 включает в себя виртуальную машину VM, реализованную путем логического или физического разделения ЦП (не показан) и области хранилища блока хранения (не показан). В примере, показанном на фиг.2, виртуальные машины VM1 и VM2 реализованы в SV 40-1, виртуальные машины VM3 и VM4 реализованы в SV 40-2, виртуальные машины VM5 и VM6 реализованы в SV 40-3 и виртуальные машины VM7 и VM8 реализованы в SV 40-4. Виртуальные машины VM1-VM8 могут быть реализованы гостевой операционной системой (GOS), эмулируемой на главной операционной системе (HOS) на каждом из серверов, или программным обеспечением, исполняющимся на GOS.
Виртуальная машина VM передает и принимает данные на и от других устройств (например, компьютерный блок на внешней сети и виртуальной машине VM на другом физическом сервере 40) через виртуальные коммутаторы (не показаны), управляемые монитором виртуальной машины или физической NIC (не показана). В настоящем примерном варианте осуществления передача пакетов осуществляется, в порядке примера, в соответствии с TCP/IP (протокол управления передачей/интернет-протокол).
Кроме того, управление виртуальным коммутатором (не показан) согласно настоящему изобретению может осуществляться на основании метода OpenFlow, описанного ниже, и виртуальный коммутатор может осуществлять традиционную операцию переключения (уровень 2). Кроме того, каждая из виртуальных машин VM1-VM8 и наружная среда физического сервера соединены друг с другом по принципу моста. Таким образом, прямая передача из наружной среды может осуществляться на основании MAC-адресов и IP-адресов виртуальных машин VM1-VM8.
PFC 10 управляет связью в системе на основании метода OpenFlow. Метод OpenFlow демонстрирует метод, согласно которому, в соответствии с политикой маршрутизации (элемент потока: поток и действие) контроллер (в данном случае, PFC 10) задает многослойную структуру и маршрутизирует данные в единицах потоков на PFS 20 и 30 для осуществления управления маршрутами и управления узлами. Таким образом, функция управления маршрутами отделена от маршрутизатора и коммутатора, и оптимальные маршрутизация и управление трафиком можно реализовать посредством контроллера централизованного управления. PFS 20 и 30, к которым применяется метод OpenFlow, манипулируют не связью в единицах транзитных сегментов, как в традиционных маршрутизаторе и коммутаторе, а связью в качестве сквозного потока (END2END).
PFC 10 реализован компьютером, имеющим ЦП и блок хранения (не показан). Обработка по управлению потоками в PFC 10 осуществляется путем исполнения программы, хранящейся в блоке хранения (не показан), и управляет операциями PFS 20 и 30 (например, операцией ретрансляции пакетов данных) путем задания элемента потока (потока и действия) для каждого из PFS 20 и 30.
Кроме того, MAC-адреса хост-терминала (SV 40 и хранилища 50) и виртуальной машины VM задаются для PFC 10 согласно настоящему изобретению, до переноса пакетов между терминалами (например, между виртуальными машинами VM). Например, PFC 10 заранее получает MAC-адреса хост-терминала и виртуальной машины VM в ответ на запрос ARP (протокола разрешения адресов).
PFC 10 генерирует элемент потока, применяя полученный MAC-адрес для правила, и задает элемент потока для всех PFS 20 и 30 в сети. Например, PFC 10 генерирует для каждого PFS элемент потока, используемый для указания пункта назначения переноса пакета, адресованного по MAC-адресу виртуальной машины VM1, и для переноса пакета и задает элемент потока для всех коммутаторов PFS 20 и 30 в сети. В настоящем изобретении, поскольку управление потоком осуществляется на основании только MAC-адреса пункта назначения, пункт назначения переноса пакета, соответствующий правилу (MAC-адресу пункта назначения), заданный для элемента потока, определяется независимо от источника передачи. По этой причине управление потоками может осуществляться безотносительно к источнику передачи пакета. Таким образом, согласно настоящему изобретению, поскольку множественный маршрут для переноса пакетов формируется путем задания оптимального маршрута для терминала-адресата, можно реализовать оптимальную многомаршрутную операцию. Кроме того, поскольку элемент потока можно задавать для PFS, не ожидая приема первого пакета, в отличие от традиционного метода, можно повысить пропускную способность сети. Кроме того, в настоящем изобретении, поскольку элемент потока генерируется и задается до переноса пакета между терминалами, то есть до начала работы системы, обработочная нагрузка для управления потоками в ходе эксплуатации снижается в сравнении с традиционным методом.
Дополнительно PFC 10 генерирует элемент потока, применяя полученный MAC-адрес для правила, и задает элемент потока для произвольно выбранных из PFS 20 и 30 в сети, и элемент потока не задается для оставшихся PFS. Например, элемент потока, применяющий MAC-адрес виртуальной машины VM1 в качестве правила, задается для выбранной части PFS 30, непосредственно подключенных к хост-терминалу (SV 40 и хранилищу 50). В этом случае, когда PFS 30, для которого элемент потока не задан, принимает пакет, адресованный виртуальной машине VM1, пакет выбраковывается и никуда больше не переносится. Таким образом, поскольку пункт назначения переноса пакета можно логически отделить, одну физическую сеть можно разделить на множество логических сетей и эксплуатировать. Следует отметить, что, когда элемент потока, определенный для выбраковки пакета, адресованного по конкретному MAC-адресу, назначается для конкретного PFS, можно добиться аналогичного эффекта.
Каждый из PFS 20 и 30 включает в себя таблицу потоков (не показана), для которой задан элемент потока, и осуществляет обработку пакета приема (например, процесс ретрансляции и выбраковку) в соответствии с заданным элементом потока. PFS 30 представляет собой коммутатор первого каскада, непосредственно подключенный к хост-терминалу (SV 40 и хранилищу 50), и в качестве PFS 30 предпочтительно применять, например, коммутатор верхнего размещения (TOR). Кроме того, для коммутатора L2 и коммутатора L3, подключенных ко второму каскаду или следующих за хост-терминалом, в PFS 20 предпочтительно применять, например, базовый коммутатор (CORE).
Каждый из PFS 20 и 30 обращается к своей собственной таблице потоков (не показана) и осуществляет действие (например, ретрансляцию и выбраковку пакета данных), заданное в элементе потока и соответствующее данным заголовка пакета приема (в частности, MAC-адресу пункта назначения). В частности, каждый из PFS 20 и 30 осуществляет действие, заданное в элементе потока, когда данные заголовка пакета приема совпадают с (соответствуют) потоком, определенным элементом потока, заданным в его собственной таблице потоков. Кроме того, каждый из PFS 20 и 30 не осуществляет никакой обработки на пакете, когда данные заголовка пакета приема не совпадают с (соответствуют) потоком, определенным элементом потока, заданным в его собственной таблице потоков. В этом случае PFS 20 и 30 могут информировать PFC 10 о приеме пакета и могут выбраковывать пакет.
В элементе потока в качестве данных (далее именуемых правилом) для указания потока (пакета данных) задаются любые комбинации адресов и идентификаторов от уровня 1 до уровня 4 эталонной модели OSI (взаимодействия открытых систем), и адреса и идентификаторы включаются, например, в данные заголовка пакета данных TCP/IP. Например, любая из комбинаций физического порта уровня 1; MAC-адреса уровня 2, IP-адреса уровня 3, физического порта уровня 4, и тега VLAN задается для элемента потока в качестве правила. Однако в настоящем изобретении MAC-адрес и IP-адрес источника передачи не задаются для элемента потока, и MAC-адрес пункта назначения всегда задается для элемента потока. При этом для элемента потока можно задавать заранее определенный диапазон идентификатора, например, номер порта, адрес и пр. Например, MAC-адреса виртуальных машин VM1 и VM2 можно задавать в качестве MAC-адресов пункта назначения как правило элемента потока.
Действие элемента потока определяет, например, способ обработки пакета данных TCP/IP. Например, задаются информация, указывающая, ретранслируется ли принятый пакет данных, и пункт назначения пакета данных в случае ретрансляции пакета данных. Дополнительно при выполнении действия можно задавать данные, предписывающие копирование или выбраковку пакета данных.
Способ задания потока и способ осуществления связи в компьютерной системе
Далее согласно фиг.3A-3J будут подробно описаны способ задания потока и способ осуществления связи в компьютерной системе согласно настоящему изобретению. Задание потока для виртуальной машины VM1 и задание потока для виртуальной машины VM5 будут описаны ниже в порядке примера. Кроме того, когда виртуальные машины VM1-VM8, физические серверы 40-1 - 40-5 и хранилище 50 относительно не различаются, они совместно именуются узлами.
На момент окончания конфигурации системы (или изменения конфигурации системы), PFC 10 узнает топологию системы аналогично тому, как это делает традиционный контроллер потоков. Данные топологии, известные на этот момент, включают в себя данные, относящиеся к состоянию соединения PFS 20 и 30, узлов (виртуальных машин VM1-VM8, физических серверов 40-1 - 40-5 и хранилища), внешней сети, которая не показана (например, интернета), и пр. В частности, в качестве данных топологии, количество портов устройства и данные порта назначения связаны с идентификатором устройства для указания PFS 20 и 30 и узлов, и, таким образом, идентификатор устройства записывается в блок хранения PFC 10. Данные порта назначения включают в себя тип соединения (коммутатор/узел/внешняя сеть) для указания противоположной стороны соединения, и данные для указания пункта назначения соединения (ID коммутатор в случае коммутатора, MAC-адрес в случае узла и ID внешней сети в случае внешней сети).
Согласно фиг.3A PFC 10 блокирует запрос ARP от узла для получения (изучения) местоположения (MAC-адреса) запрашивающего узла. Например, запрос ARP, адресованный виртуальной машине VM5 от виртуальной машины VM1, поступает на PFC 10. PFC 10 выделяет MAC-адрес виртуальной машины VM1 как исходного узла из принятого запроса ARP. PFC 10 определяет правило для задания MAC-адреса для пункта назначения для генерации элемента потока. В этом случае генерируется элемент потока для всех PFS 20 и 30 в системе. Следует отметить, что элемент потока на MAC-адрес можно заранее задавать для блока хранения PFC 10.
Согласно фиг.3B PFC 10, изучивший местоположение (MAC-адрес) узла, регистрирует маршрут к узлу. Например, PFC 10 задает для всех PFS 20 и 30 элемент потока, определяющий перенос пакета, адресованного по MAC-адресу виртуальной машины VM1, и устройство назначения переноса. В этом случае предпочтительно задавать элемент потока для PFS 30-1, чтобы определять физический порт, подключенный к виртуальной машине VM1, в качестве пункта назначения вывода, и задавать элемент потока для PFS 30 на первом каскаде, отличных от PFS 30-1, для выравнивания нагрузки для PFS 20 на втором или следующем каскаде. Например, предпочтительно задавать элемент потока для PFS 30 для осуществления маршрутизации ECMP (выбора множественных маршрутов одинаковой стоимости) для PFS 30.
При нормальном изучении уровня 2 (изучении L2) возможны случаи, когда петля (LOOP) формируется вследствие переполнения (FLOODING) и когда предполагаемое изучение нельзя осуществлять вследствие выравнивания нагрузки. Однако в настоящем изобретении применяется метод OpenFlow, и, соответственно, эти проблемы не возникают.
Согласно фиг.3C PFC 10, для которого задан элемент потока, передает запрос ARP для пункта назначения, запрашиваемого узлом, на все узлы, кроме узла при получении (изучении) MAC-адреса. Например, PFC 10 передает запрос ARP, адресованный виртуальной машине VM5 в качестве пункта назначения запроса ARP, показанного на фиг.3A, на все узлы (виртуальные машины VM2-VM8, SV 40-5 и хранилище 50), кроме запрашивающей виртуальной машины VM1.
Согласно фиг.3D PFC 10 получает (изучает) местоположение (MAC-адрес) узла-адресата на основании ответа (ответа ARP) на запрос ARP, показанный на фиг.3C. В настоящем примере ответ ARP передается от виртуальной машины VM5, и PFC 10 получает местоположение (MAC-адрес) виртуальной машины VM5 путем блокировки ответа ARP.
Согласно фиг.3E PFC 10, получивший (изучивший) местоположение (MAC-адрес) узла, регистрирует маршрут к узлу. В данном случае PFC 10 задает для всех PFS 20 и 30 элемент потока, определяющий перенос пакета, адресованного по MAC-адресу виртуальной машины VM5, и устройство назначения. В этом случае, аналогично описанному выше, предпочтительно задавать элемент потока для PFS 30 на первом каскаде от хост-терминала для выравнивания нагрузки для PFS 20 на втором или следующем каскаде.
Согласно фиг.3F PFC 10 отвечает на запрос ARP от узла, показанного на фиг.3A, через посредника. В данном случае PFC 10 использует MAC-адрес виртуальной машины VM5 как источника передачи и выдает ответ ARP, пунктом назначения которого является виртуальная машина VM1. Виртуальная машина VM1 принимает ответ ARP на запрос ARP, переданный ею самой, и получает запрашиваемый MAC-адрес виртуальной машины VM5.
В вышеупомянутой операции обработка (элемент потока), применяемая к пакетам, соответственно адресованным как узлу-адресату, так и запрашивающему исходному узлу запроса ARP, задается для всех PFS 20 и 30 в системе. В примере, показанном на фиг.3G, посредством вышеописанной операции, элемент потока, применяемый к пакетам, соответственно адресованным виртуальным машинам VM1 и VM5, задается для всех PFS 20 и 30. Таким образом, передача, адресованная виртуальной машине VM1, и передача, адресованная виртуальной машине VM5, осуществляются нормально. В этом случае пакет, адресованный каждому из пунктов назначения, передается по маршруту, согласующемуся с элементом потока, определенному MAC-адресом пункта назначения, независимо от источника передачи.
Дополнительно для конфигурирования единичной структуре дерева в протоколе связующего дерева согласно традиционному Ethernet (зарегистрированный товарный знак) генерируется физическая линия связи, которая не используется. По этой причине не удается задать множество маршрутов между конкретными узлами в Ethernet (зарегистрированный товарный знак). Однако в настоящем изобретении пункт назначения переноса пакетов задается для каждого из PFS согласно пункту назначения, что позволяет формировать множественные маршруты для реализации распределения нагрузки. Например, в случае вышеупомянутого примера множественные маршруты формируются согласно элементу потока в каждой из передачи для виртуальной машины VM1 и передачи для виртуальной машины VM5, и реализуется распределение нагрузки.
В вышеупомянутом примере применяется выравнивание нагрузки посредством ECMP, заданного в элементе потока. Однако настоящее изобретение этим не ограничивается, и для каждого элемента потока можно применять агрегацию линий связи или распределение нагрузки.
С другой стороны, чтобы можно было передавать запрос ARP и осуществлять двустороннюю связь между запрашивающим исходным узлом и узлом-адресатом, узел-адресат получает (изучает) местоположение (MAC-адрес) запрашивающего исходного узла от PFC 10. В частности, согласно фиг.3H запрос ARP, адресованный виртуальной машине VM1 от виртуальной машины VM5, передается на PFC 10. Согласно фиг.3I PFC 10, где хранится местоположение (MAC-адрес) виртуальной машины VM1, передает ответ ARP, имеющий MAC-адрес виртуальной машины VM1 как источника передачи, на виртуальную машину VM5. Виртуальная машина VM5 блокирует его для получения местоположения (MAC-адрес) виртуальной машины VM1. Таким образом, как показано на фиг.3J, виртуальная машина VM5 может передавать пакет данных, адресованный виртуальной машине VM1. Следует отметить, что, поскольку элемент потока, адресованный виртуальной машине VM1, и элемент потока, адресованный виртуальной машине VM5, задаются независимо друг от друга, маршрут связи от виртуальной машины V1 к виртуальной машине V5 и маршрут связи от виртуальной машины V5 к виртуальной машине V1 не всегда одинаковы.
Посредством вышеописанной операции обе виртуальные машины VM1 и VM5 получают (изучают) местоположения (MAC-адреса) друг друга, и пункт назначения переноса для пакета, адресованного каждой из виртуальных машин VM1 и VM5, задается для всех PFS 20 и 30. Таким образом, обеспечивается возможность двусторонней связи между виртуальной машиной VM1 и виртуальной машиной VM5.
В настоящем изобретении, поскольку элемент потока задается на основании MAC-адреса пункта назначения, местоположение исходного узла передачи не всегда требуется при задании элемента потока. По этой причине элемент потока можно задавать до начала осуществления связи между узлами. Кроме того, не требуется задавать элемент потока для маршрута связи между узлами, в отличие от традиционного метода, и достаточно задать элемент потока MAC-адреса пункта назначения для каждого из PFS. Соответственно, можно уменьшить потребление ресурсов в компьютерной системе в целом.
Далее согласно фиг. 4 будет описан пример применения компьютерной системы согласно настоящему изобретению. В вышеописанном примере элемент потока для пакета, адресованного узлу, задается для всех PFS 20 и 30. Однако настоящее изобретение этим не ограничивается, и узлы, для которых задан элемент потока, могут ограничиваться частью PFS 30, непосредственно подключенных к узлу.
Компьютерная система, показанная на фиг.4, включает в себя коммутаторы (PFS 20-1 и 20-2) более высокого уровня, подключенные к сети 500, PFS 30-1, 30-2 и 30-3, непосредственно подключенные к хост-терминалу (не показан), например, SV40, и узлы S и A. При этом узел A подключен к системе через PFS 30-2, и узел S подключен к системе через PFS 30-3.
В настоящем примере с помощью PFC 10 (не показан) элемент потока задается для PFS 20-1, 20-2 и 30-3 для управления потоком, адресованным узлу S, и элемент потока задается для PFS 20-1, 20-2, 30-1 и 30-2 для управления потоком, адресованным узлу A. В этом случае пакет, адресованный узлу S, достигает узла S по маршруту связи, проходящему через любой из PFS 20-1, 20-2 и 30-3, и пакет, адресованный узлу A, достигает узла A по маршруту связи, проходящему через любой из PFS 20-1, 20-2, 30-1 и 30-2. Таким образом, узел S оказывается в составе логической сети, сконфигурированной PFS 20-1, 20-2 и 30-3, и узел A оказывается в составе логической сети, сконфигурированной PFS 20-1, 20-2, 30-1 и 30-2.
Как описано выше, компьютерная система, показанная на фиг.4, конфигурирует одну физическую сеть. Однако при выборочном задании элемента потока компьютерная система делится на две логические сети. Соответственно, одной физической топологией можно манипулировать как множеством VLAN.
Как описано выше, примерные варианты осуществления настоящего изобретения были подробно описаны. Однако конкретная конфигурация не ограничивается вышеописанными примерными вариантами осуществления. Различные модификации в пределах объема настоящего изобретения включены в настоящее изобретение. На фиг.2 система, имеющая группу PFS с двухкаскадной конфигурацией, показана в порядке одного примера. Однако настоящее изобретение этим не ограничивается, и система может иметь группу PFS с конфигурацией большего количества каскадов. Кроме того, внешняя сеть может быть подключена к PFS 20 через коммутатор уровня 3 (L3), как в традиционном методе.
Настоящая заявка основывается на японской заявке № JP 2010-202468, раскрытие которой включено в данное описание в порядке ссылки.