SAP HANA и программно-определяемый ЦОД: практический кейс

В этой статье поговорим о конфигурации SAP HANA в рамках виртуального дата-центра и уделим отдельное внимание настройке VMwrae NSX.

Что такое SAP HANA

Для начала давайте вспомним, что представляет собой SAP HANA.

SAP HANA – это программно-аппаратный комплекс, позволяющий хранить, рассчитывать и обрабатывать данные в режиме реального времени. Заложенная в основе решения технология in-memory обеспечивает высокую производительность приложений, поскольку процесс обработки данных осуществляется средствами оперативной памяти, что гарантирует высокие скорости по сравнению с традиционным подходом в случае обращения к файловой подсистеме. Отметим, что на сегодняшний день решение SAP HANA может быть развернуто в формате on-premise или в облаке.

Сетевые зоны в SAP HANA

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

Пример конфигурации сети

Обратите внимание, что здесь участвуют следующие зоны: Client, Internal, Storage.

• Client zone, или клиентская зона, используется приложениями SAP, программным модулем SAP HANA studio, веб-приложениями, работающими с SAP HANA XS-серверами или другими базовыми решениями, например SAP Business.
• Internal zone, или внутренняя зона, обеспечивает связность между узлами в распределенной системе SAP HANA, а также обеспечивает связь, необходимую для репликации между сайтами SAP HANA.
• Storage zone, или зона хранилища. Несмотря на то что SAP HANA хранит и обрабатывает данные в памяти, эта зона необходима для резервного хранения данных.

HANA SERVER: логика сетевых соединений

Рисунок ниже иллюстрирует логику сетевых соединений в SAP HANA, определяемых требованиями руководства. SAP рекомендует выполнять сегментацию сети и разграничение уровней безопасности внутри зон и логических сетей. Используя озвученные рекомендации, необходимо определиться с дизайном виртуальных сетей NSX. Для этого поговорим об особенностях архитектуры и рассмотрим компоненты сети.

Логика сетевых соединений

Представьте, что NSX – это сетевой гипервизор, где есть возможность абстрагировать и воспроизводить полный набор уровней (от 2 до 7), включая коммутацию, маршрутизацию, межсетевое экранирование и балансировку нагрузки за счет программных средств.

Виртуализация сети в NSX схожа с виртуализацией серверов, когда, создавая ВМ, такие физические ресурсы, как, CPU, RAM, хранилища и сетевые адаптеры попросту абстрагируются. В NSX существуют механизмы для централизованного управления, конфигурации любой комбинации сетевых сервисов и динамического создания изолированных виртуальных сетей. Эти сети не зависят от основного сетевого оборудования, что позволяет ИТ-специалистам использовать физическую сеть как пул транспортных мощностей.

Добавление логического коммутатора NSX

Ознакомившись с теорией, перейдем к практической части кейса: нам потребуется создать логический свитч для сегментирования сети и безопасности сетевого трафика. Основное требование – наличие приватной сети (private) с выделенным vNIC и полностью зарезервированной 10 Gigabit Ethernet сетью.

Для добавления нового логического коммутатора переходим в vSphere Web Client -> Networking & Security.

Networking & Security

В открывшемся окне NSX Home переходим на панель Logical Switches и, нажав на значок «+», открываем окно New Logical Switch.

Создание нового логического свитча

В поле Name указываем значение DT Internode Switch, в поле Transport Zone нажимаем на кнопку Change. В открывшемся окне выбираем Global-Transport-Zone и нажимаем ОК.

Настройка параметров Transport Zone

В качестве Replication Mode оставляем значение по умолчанию: Unicast. Убеждаемся, что опция Enable IP Discovery находится в активном статусе, и нажимаем ОК.

Привязка ВМ к логическому коммутатору

На этом шаге рассмотрим, как выполняется привязка ВМ к логическому коммутатору. Согласно сценарию, мы работаем с Database Internode Switch, и связка со свитчем потребуется только для виртуальных машин: HANA ВМ и Dynamic Tiering Extended Storage ВМ.

Для привязки виртуальной машины выполним следующие шаги: кликнем по новому логическому свитчу, созданному в предыдущем шаге: DT Internode Switch. Далее открываем меню Actions и выбираем опцию Add VM для добавления виртуальной машины.

Добавление виртуальных машин

В открывшемся окне отображается список виртуальных машин, из которого выбираем ВМ с именем vhHAN110_ProdDB и vsHDT110_ProdDB, после чего нажимаем Next.

Добавление ВМ из списка

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

Привязка ВМ к виртуальным адаптерам

После переходим на заключительную страницу мастера, в которой отображается суммарная информация по всем выполненным настройкам. В окне Ready to complete нажимаем кнопку Finish и завершаем конфигурацию.

Пояснение! Рассмотренные шаги использовались для привязки ВМ SAP HANA к логическому свитчу, который используется для коммуникации узлов с базой данных. Чтобы проделать обратные действия и удалить сетевую привязку ВМ, достаточно снова обратиться к меню Actions, выбрать опцию Remove VM, указать соответствующую виртуальную машину и нажать ОК.

Добавление логического распределенного роутера

Отметим, что логический распределенный роутер осуществляет маршрутизацию между объектами, соединенными с логическими коммутаторами. Логические коммутаторы, в свою очередь, могут объединять несколько серверов vCenter. Это позволяет создавать L2-домены сетевого взаимодействия для приложений виртуальной машины, которые смогут взаимодействовать между дата-центрами. В рассматриваемом примере логический распределенный роутер будет использоваться для централизованного управления сетевым ландшафтом SAP HANA и обеспечения коммуникации с внешними физическими сетями.

Для того чтобы создать логический распределенный роутер, или DLR (Distributed Logical Router), переходим в меню NSX Edges веб-клиента vSphere и нажимаем на кнопку «добавить». В открывшемся окне выбираем опцию Logical (Distributed) Router и задаем имя: SAP-COIL-DLR-01. В поле Hostname вводим аналогичное название и нажимаем Next.

Добавление распределенного логического роутера

На следующем шаге вводятся верительные данные в виде логина и пароля, которые могут использоваться при подключении к роутеру средствами командной строки. На практике рекомендуется использовать пароль, содержащий не менее 12 символов с использованием верхнего, нижнего регистра, специальных символов и цифр. Для подключения по SSH активируем опцию Enable SSH access и нажимаем Next.

Задание верительных данных

На странице Configure deployment необходимо определить пул ресурсов и хранилище данных. Этот шаг является обязательным для конфигурации роутера. В поле Datacenter задается имя дата-центра. В нашем примере используется имя COIL. После чего нажимаем кнопку «+» и добавляем новый NSX Edge экземпляр.

В открывшемся окне задаем параметры Cluster/Resource Pool: Compute-Cluster и Datastore: datastore 1. Нажимаем ОК.

Определение параметров Resource Pool и Datastore

Переходим к следующему пункту настройки: Configure interfaces. Опция Management Interface Configuration обеспечивает контроль управления и высокую доступность DLR. Интерфейс управления, или Management Interface, используется для того, чтобы распределенный логический роутер контролировал связь с виртуальными машинами.

В поле Management Interface Configuration переходим к пункту Connected To и нажимаем Select.

Настройка интерфейса управления

В открывшемся окне переходим на закладку Distributed Portgroup и выбираем группу Compute Management DV group. Далее нажимаем ОК.

Подключение NSX Edge к сети

Следующий шаг связан с настройкой логических интерфейсов, или LIF, и включает в себя конфигурацию IP-адресов. При этом каждый LIF сопоставляется с виртуальным MAC-адресом или vMAC. Отметим, что такие MAC-адреса остаются невидимыми для физических сетей. В открывшемся окне в поле Configure interfaces of this NSX Edge нажимаем на «+» и задаем значения:

Затем переходим к конфигурации подсетей, для чего нажимаем «+». В поле IP Address вводим значение 192.168.20.2 и нажимаем ОК. В поле Subnet prefix length задаем маску подсети в формате CIDR равной 29, после чего дважды нажимаем ОК.

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

Теперь переходим на страницу Default gateway settings и деактивируем опцию Configure Default Gateway, после чего переходим на следующую страницу. В окне Ready to complete отображается суммарная информация по всем внесенным настройкам. Если значения указаны верно, завершаем работу мастера.

Отображение суммарной информации

Настройка правил брандмауэра

В этой части кейса создадим Security Group, которые будут содержать виртуальные машины, ассоциированные с SAP HANA, и выполним настройку файервола путем создания правил, позволяющих взаимодействовать ВМ между собой. Для этого переходим в Service Composer, кликаем по Security Groups и нажимаем кнопку создания новой группы. В открывшемся окне вводим имя группы Prod-HANA-Databases и нажимаем Next.

Следующий шаг определяет состав группы, следовательно, здесь указываются ВМ, входящие в нее. В разделе Criteria Details заменим параметр Computer OS Name на VM Name, поскольку поиск объекта будет производиться по имени виртуальной машины. Ищем все ВМ, которые содержат в названии слово ProdDB. После чего трижды нажимаем на кнопку Next. Таким образом в группу добавились две виртуальные машины: vhHAN110_ProdDB и vsHDT110_ProdDB.

После того как группа безопасности была создана, переходим к созданию политик безопасности брандмауэра. Кликаем по закладке Security Policies и нажимаем на иконку создания новой политики безопасности. Задаем имя DB-Internode-Communications и дважды нажимаем Next. В окне Firewall Rules нажимаем на «+», чтобы создать новое правило. В открывшемся окне вводим имя Secure Database и из трех возможных действий выбираем Allow. То есть создаваемое правило будет разрешать выполнять заданные действия.

В поле Destination необходимо определить объект, на который будет распространяться действие создаваемого правила. Выбираем опцию Select Security Groups, указываем группу безопасности с именем Prod-HANA-Databases и нажимаем ОК.

Выбор группы безопасности для правила

Также указываем, чтобы велся журнал событий, для чего активируем опцию Log. Нажимаем ОК, дважды кликаем Next и попадаем в окно Ready to complete. Нажатием Finish завершаем работу мастера.

Пример созданного правила

Созданное правило позволяет виртуальным машинам, выполняющим роль базы данных, взаимодействовать друг с другом без использования шифрования БД. Чтобы правило начало действовать, его необходимо применить. Для этого заходим в меню Actions -> Apply Policy. В открывшемся окне указываем правило, которое необходимо применить: Prod-HANA-Databases.

Применяемое правило

В закладке Canvas видно, что это правило активно и действует на две виртуальные машины.

Обзор примененных правил

Заключение

В этом кейсе мы рассмотрели особенности конфигурации SAP HANA в рамках виртуального ЦОД, уделив отдельное внимание настройке ключевых сетевых элементов. Следите за новыми материалами первого блога о корпоративном IaaS, в них мы продолжим знакомить вас с актуальными вопросами из области SAP-хостинга.

* Источник: docs.hol.vmware