Содержание


Проектирование сетей для IBM PureApplication System

Часть 2. Как подключать нагрузки к сети

Comments

Серия контента:

Этот контент является частью # из серии # статей: Проектирование сетей для IBM PureApplication System

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Проектирование сетей для IBM PureApplication System

Следите за выходом новых статей этой серии.

IBM PureApplication System – это готовая система облачных вычислений со встроенным аппаратным и программным обеспечением, предназначенная для развертывания и решения задач в облаке – все, что нужно корпоративному центру обработки данных для добавления среды частного облака. Хотя система (по большей части) автономна, ее нужно подключить к сети ЦОД, чтобы внешние пользователи могли подключаться к системе и управлять ею, а также развертывать свои приложения, подключаться к этим приложениям и использовать их.

Часть 1 демонстрирует, как подключить систему к сети ЦОД. В этой, второй статье мы объясним, как подсоединить приложения к сети ЦОД, чтобы ее клиенты могли обращаться к этим приложениям.

Использование приложений в сети

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

Размещение приложений

Приложение, развернутое в PureApplication System, работает в облачной среде системы. Система подразделяет свою облачную среду на облачные группы. Каждая облачная группа содержит некоторое оборудование системы (так называемые вычислительные узлы) и кластер гипервизоров для виртуализации этих вычислительных ресурсов. Гипервизор – это специализированная операционная система, которая позволяет виртуальным машинам совместно использовать вычислительные ресурсы. Каждая виртуальная машина (ВM) – это имитация компьютера, который работает под управлением операционной системы (ОС) точно так же, как физический компьютер. В PureApplication System на операционных системах ВM исполняются серверы промежуточного уровня. Приложения выполняется на серверах промежуточного уровня набором ВМ; такое приложение, исполняемое набором ВМ, называется рабочей нагрузкой.

Для подключения к своим ВМ облачная группа предоставляет две сети. Они нужны ВМ облачной группы для работы в облачной среде и размещения приложения. Это следующие две сети:

  • VLAN управления облачной группой – система должна иметь возможность управлять виртуальными машинами облачной группы;
  • VLAN данных приложения - ВM должна обеспечить сетевое соединение с работающим на ней приложением.

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

VLAN данных приложения соединяет приложение с сетью за пределами виртуальной машины. Администратор облачной среды делает эту VLAN доступной для облачной группы, настроив IP-группу. IP-группа состоит из набора IP-адресов и нескольких других параметров сети, определяющих сеть ЦОД. Один из этих параметров – ID VLAN, который указывает на одну из VLAN, определенных в конфигурации сети системы для подключения системы к сети ЦОД. Когда система назначает ВМ один из этих IP-адресов, она через этот адрес и VLAN соединяет ВМ с сетью ЦОД. Эта связь позволяет клиентам приложения виртуальной локальной сети подключиться к приложению, а приложению – к ресурсам в этой VLAN.

Сетевые подключения виртуальной машины

Как объяснялось выше, ВM нужны два сетевых соединения – управления и данных. Как показано на рисунке 1, по умолчанию система настраивает для каждой ВМ две виртуальных сетевых карты (vNIC).

Рисунок 1. Сетевые соединения виртуальных машин, размещенных в облачной группе
Сетевые соединения виртуальных машин, размещенных в облачной группе
Сетевые соединения виртуальных машин, размещенных в облачной группе

Это следующие соединения:

  • vNIC управления: eth0 – подсоединяет ВM к сети управления облачной группой. Это позволяет системе управлять ВМ;
  • vNIC данных: eth1 – подсоединяет ВМ к сети данных приложений облачной группы, которая представляет собой одну из VLAN в сети рабочей нагрузки. Это позволяет клиентам приложений подключиться к приложениям ВМ, а приложеням ВМ – к ресурсам предприятия.

Каждой vNIC нужен свой IP-адрес, который идентифицирует ВM в этой сети. По умолчанию IP-адрес для vNIC управления назначается системой, соединяющей ВМ с сетью управления облачной группы через eth0.

По умолчанию IP-адрес vNIC данных выбирается из одной из групп IP-адресов облачной группы. IP-адрес соединяет ВM через eth1 с VLAN, указанной в облачной группе.

Изоляция сети приложений

Каждая IP-группа может указать свою VLAN, так что каждый набор виртуальных машин, развернутых с другой группой IP, подключается к своей VLAN; таким образом, каждый набор виртуальных машин логически изолирован от других наборов ВМ. Это делает приложения в сети изолированными друг от друга.

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

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

Рисунок 2. Развертывание трехуровневого приложения с помощью нескольких облачных групп и групп IP
Развертывание трехуровневого приложения с помощью нескольких облачных групп и IP-групп
Развертывание трехуровневого приложения с помощью нескольких облачных групп и IP-групп

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

Управление облаком

В предыдущем разделе сказано, что каждая ВМ подключена к двум сетям: сети управления, чтобы система могла управлять ВМ, и сети данных для связи приложений с внешними ресурсами. По умолчанию сеть управления представляет собой внутреннюю сеть управления облаком. Как показано на рисунке 1, ВМ непосредственно подсоединена к службам управления системой и недоступна снаружи.

В PureApplication System версии 2.0 появился новый тип облачных групп, который позволяет системному администратору создавать внешний маршрут трафика для управления виртуальным машинам. Чтобы создать облачную группу, управляемую извне, нужно при создании облачной группы присвоить параметру Cloud Management значение By way of external network, как показано на рисунке 3.

Рисунок 3. Создание облачной группы, управляемой из внешней сети
Создание облачной группы, управляемой из внешней сети
Создание облачной группы, управляемой из внешней сети

В версии 2.0 облачные группы можно создавать так, чтобы они работали как в версии 1.x – теперь это называется облачной группой с внутренним управлением. Однако уже существующие облачные группы нельзя переводить с одного типа управления на другой.

Облачная группа с внешним управлением содержит IP-группы двух типов:

  • IP-группа управления облаком – используется для присвоения IP-адреса vNIC управления каждой виртуальной машины, трафик которой проходит через VLAN управления облаком, определенную в сетевых настройках системы;
  • IP-группа данных – используется для присвоения IP-адреса vNIC данных каждой виртуальной машины, трафик которой проходит через VLAN данных приложений, определенную в сетевых настройках системы.

На рисунке 4 показано, как настроить IP-группу управления облаком.

Рисунок 4. Настройка IP-группы управления облаком
Настройка IP-группы управления облаком
Настройка IP-группы управления облаком

Если на рисунке 1 показаны сетевые соединения с vNIC на виртуальной машине, размещенной в облачной группе с внутренним управлением, то рисунок 5 иллюстрирует те же соединения, когда ВM размещена в облачной группе, управляемой извне.

Рисунок 5. Сетевые соединения виртуальных машин, размещенных в облачной группе с внешним управлением
Сетевые соединения виртуальных машин, размещенных в облачной группе с внешним управлением
Сетевые соединения виртуальных машин, размещенных в облачной группе с внешним управлением

Обратите внимание, что службы системного управления больше не подключены к виртуальной машине через VLAN управления облаком. Вместо этого VLAN управления облаком подсоединяет ВМ к сети ЦОД, которая должна направлять этот трафик управления обратно в систему, к службам системного управления, чтобы система могла продолжать управление ВM.

Внешняя сеть управления облаком

В предыдущем разделе мы показали сетевые подключения для ВM, размещенных в облачной группе с внешним управлением. Мы сказали, что VLAN управления облаком соединяет ВМ с сетью ЦОД, которая должна возвращать этот трафик в службы системного управления, чтобы система могла продолжать управление ВM. Как именно сеть ЦОД возвращает трафик управления в систему?

Внешнее управление системой

Для поддержки облачных групп с внешним управлением системе требуются несколько дополнительных параметров сети. Эти параметры представляет собой 2-3 IP-адреса, указанных системным администратором, которые система назначает своим службам управления: системной консоли, консоли рабочей нагрузки и (в Power-системах) системам управления DLPAR. Эти IP-адреса подключают службы управления системой к сети ЦОД через сеть управления системой, чтобы сеть ЦОД могла соединить службы управления с ВM, работающими в облачных группах с внешним управлением.

На рисунке 6 показаны дополнительные IP-адреса для управления облаком посредством раздела внешних сетей страницы конфигурации сети, которая используется для настройки IP-адресов служб управления системой. Некоторые из полей внешнего управления повторяют поля IP-адресов управления системой, поэтому их значения уже заполнены и доступны только для чтения. В настоящее время (по состоянию на PureApplication System v2.0.0.0) внешнее управление системой поддерживает только адреса IPv4, так что этот раздел страницы нельзя включить до тех пор, пока не заполнены поля настройки IPv4 в разделе управления системой.

Рисунок 6. Настройка IP-адресов внешнего управления
Настройка IP-адресов внешнего управления
Настройка IP-адресов внешнего управления

Пример облачной группы с внешнем управлением

Рассмотрим пример системы и облачной группы, настроенных для внешнего управления.

  1. VLAN, которые будут использоваться в остальной части этого примера, должны быть определены в конфигурации сети системы. Эти VLAN приведены в таблице 1. В таблице также показаны каналы, с которыми связана каждая VLAN.
    Таблица 1. Настройка конфигурации сетей VLAN
    НазначениеТипID VLANКанал
    Сеть VLAN управления системойУправление системой100Канал управления системой
    Управление облакомIP-группа200Канал рабочей нагрузки
    Данные приложенияIP-группа300Канал рабочей нагрузки
  2. Сеть управления системой необходимо настроить, независимо от того, должна ли система поддерживать облачные группы с внешним управлением. Эти параметры настройки приведены в таблице 2.
    Таблица 2. Настройка параметров управления системой
    ПараметрЗначение
    System management network VLAN100
    System Management IP
    -- IPv4 address (floating)192.168.100.11
    -- Hostnamepureapplication
    -- Domainmydomain.com
    -- Primary IPv4 address192.168.100.12
    -- Secondary IPv4 address192.168.100.13
    -- Netmask255.255.255.0
    --Default gateway192.168.100.1
  3. Чтобы система поддерживала облачные группы с внешним управлением, должны быть настроены параметры управления внешнего облака. Эти параметры приведены в таблице 3; параметры, унаследованные от параметров управления системой, выделены курсивом и не изменяются.
    Таблица 3. Настройка параметров управления внешним облаком
    ПараметрЗначение
    VLAN100
    IP address 1 (system console access)192.168.100.11
    IP address 2 (workload console access)192.168.100.14
    IP address 3 (DLPAR management access)192.168.100.15
    Netmask255.255.255.0
    Gateway192.168.100.1
  4. Для облачной группы с внешним управлением необходима IP-группа управления облаком. В таблице 4 приведены параметры, используемые при ее создании.
    Таблица 4. Настройка IP-группы управления облаком
    ПараметрЗначение
    Used forCloud Management
    IP address192.168.200.2
    VLAN200
    Subnet192.168.200.0
    Netmask255.255.255.0
    Gateway192.168.200.1
    Route
    -- Subnet192.168.100.0
    -- Netmask255.255.255.0
    -- Gateway192.168.100.1
  5. Чтобы службы управления системой и облачная группа могли поддерживать связь друг с другом по сети, администратор сети ЦОД должен разрешить связь между IP-адресами в VLAN управления облаком и IP-адресами VLAN управления системой.
  6. Как и любая облачная группа, облачная группа внешнего управления нуждается в IP-группе для данных. В таблице 5 приведены параметры, используемые при ее создании.
    Таблица 5. Настройка IP-группы для данных
    ПараметрЗначение
    Used forData
    IP address192.168.300.2
    VLAN300
    Subnet192.168.300.0
    Netmask255.255.255.0
    Gateway192.168.300.1
  7. Создайте облачную группу, управление облаком которой осуществляется через внешнюю сеть, и добавьте IP-группы, обеспечивающие IP-адреса управления облаком и IP-адреса данных приложений. На Рисунке 7 показано, как будет выглядеть система в этой конфигурации.
Рисунок 7. Сетевые соединения ВМ, размещенных в облачной группе с внешним управлением
Сетевые соединения ВМ, размещенных в облачной группе с внешним управлением
Сетевые соединения ВМ, размещенных в облачной группе с внешним управлением

На шаге 5 мы упомянули, что администратор сети должен реализовывать мост в сети ЦОД, соединяющий VLAN управления облаком и VLAN управления системой. В частности, каждый из IP-адресов в каждой IP-группе управления облаком (см. таблицу 4) должен иметь возможность соединяться с тремя внешними IP-адресами управления облаком (см. таблицу 3), и наоборот. Как показано на рисунке 7, в этом примере (только с одной ВM) требуются следующие маршруты:

  • 192.168.100.11 <==> 192.168.200.2
  • 192.168.100.14 <==> 192.168.200.2
  • 192.168.100.15 <==> 192.168.200.2

Эта связь позволяет службам управлять ВМ (пуск, останов, состояние и т.п.), а ВМ – обращаться к необходимым им службам (NTP, SMTP и т.п.).

Сравнение внешнего и внутреннего управления

Между облачными группами с внутренним и с внешним управлением имеются два основных различия.

  • Внешнее управление облаком – если в системе размещены облачные группы с внешним управлением, то ей требуются только IP-адреса внешнего управления облаком (см. таблицу 3). Если же в ней размещаются только облачные группы с внутренним управлением, то нет никаких причин настраивать IP-адреса внешнего управления облаком.
  • Мостовая связь между VLAN управления – для каждой облачной группы с внешним управлением сети ЦОД необходима мостовая связь между IP-адресами VLAN управления облаком и VLAN управления системой. Для облачной группы с внутренним управлением это не обязательно; это даже невозможно, потому что облачная группа с внутренним управлением не предоставляет доступ к своей VLAN управления облаком из сети ЦОД.

Как показано на рисунке 5 и рисунке 7, трафик VLAN управления облаком в облачной группе с внешним управлением должен проходить вне системы и возвращаться в нее. Напротив, трафик VLAN управления облаком на основе облачной группы с внутренним управлением остается в системе, как показано на рисунке 2, и системному администратору или администратору сети больше не нужно ничего настраивать.

Облачная группа с внутренним управлением имеет ряд преимуществ. Ей легче управлять, как описано выше. Виртуальные машины, развернутые в облачной группе, могут логически изолировать сетевой трафик данных своих приложений, если они развернуты с разными IP-группами данных и отдельными идентификаторами VLAN. Однако все ВМ будут разделять общую VLAN управления облаком. Если нужно, чтобы ВM логически изолировали свой сетевой трафик управления облаком, то они должны быть развернуты либо в разных облачных группах с внутренним управлением, либо в облачной группе с внешним управлением, в которой разным IP-группам управления облаком присвоены отдельные идентификаторы VLAN.

Облачная группа с внешним управлением имеет ряд преимуществ. Ее ВM могут логически изолировать как сетевой трафик данных своих приложений, так и трафик сети управления облаком. Так как маршрут трафика сети управления облаком проходит вне сетевой системы ЦОД, а затем возвращается в систему, устройства в сети ЦОД могут контролировать трафик сети управления облаком и управлять конфигурацией IP-адресов для управления vNIC каждой виртуальной машины.

Вынесенная вовне, каждая виртуальная машина облачной группы с внешним управлением может подключаться к сети через собственную пару подсетей. Каждая виртуальная машина может быть развернута со своей собственной IP-группой данных (из одного IP-адреса) и своей собственной IP-группой управления облаком (из одного IP-адреса). Если каждая такая пара IP-групп использует пару идентификаторов VLAN и подсетей, которые не используются ни для каких других IP-групп, то каждая виртуальная машина будет развернута на базе своей собственной пары виртуальных локальных сетей и подсетей. Если каждая виртуальная машина подключена к сети через отдельную пару виртуальных локальных сетей и подсетей, то доступ из одной виртуальной машины к другой возможен только в том случае, если в сети ЦОД разрешены маршруты для каждого такого соединения.

Например, в случае облачной группы с внешним управлением трехуровневое приложение, показанное выше, можно развернуть с полной изоляцией сети, используя всего одну облачную группу, вместо трех. На рисунке 1 мы показали трехуровневое приложение, развернутое с логической изоляцией не только сетевого трафика данных приложений ВM, но и сетевого трафика управления облаком. Для изоляции сетевого трафика управления облаком потребовались три облачные группы с внутренним управлением. На рисунке 8 показано, как можно достичь логической изоляции сети с помощью одной облачной группы с внешним управлением и трех пар IP-групп – для данных и для управления облаком.

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

Если для топологии, показанной на рисунке 2, требуются три облачных группы, по одной для каждого уровня приложений, то для топологии, показанной на рисунке 11, достаточно одной облачной группы. Однако эта одна облачная группа должна быть облачной группой с внешним управлением, так чтобы ее можно было настроить с IP-группами для трех отдельных сетей управления, соответствующих трем отдельным сетям передачи данных.

Настройка сети для мультисистемного управления

Подобный пример можно привести и для мультисистемного управления. Существует два уровня мультисистемного управления:

  • управление доменом – позволяет копировать компоненты рабочей нагрузки и синхронизировать их между каталогами шаблонов нескольких систем;
  • развертывание субдомена – позволяет развертывать шаблон как экземпляр с виртуальными машинами, работающими в нескольких облачных группах на нескольких системах.

Для присоединения системы к домену управления ее необходимо настроить для внешнего управления. У каждой системы в домене будет своя собственная сеть управления системой, у каждой из которых может быть отдельный идентификатор VLAN. Эти сети управления системой должны быть связаны с сетями своих ЦОД так, чтобы их IP-адреса управления маршрутизировались между собой.

Для присоединения системы к поддомену развертывания в ее облачной среде должна быть настроена по крайней мере одна облачная группа с внешним управлением. В поддомене могут участвовать только облачные группы с внешним управлением. Сеть ЦОД должна включить взаимосвязь между всеми VLAN управления облачными группами и VLAN управления системой, чтобы любую службу управления системой можно было использовать для управления всеми облачными группами в поддомене.

Администрирование доменами управления и поддоменами развертывания выходит за рамки этой статьи. Более подробная информация содержится в разделе Администрирование мультисистемной среды Центра знаний PureApplication System.

Заключение

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

В Части 3 будут рассмотрены альтернативные способы подключения к сети ЦОД.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere, Облачные вычисления
ArticleID=1018746
ArticleTitle=Проектирование сетей для IBM PureApplication System: Часть 2. Как подключать нагрузки к сети
publish-date=10272015