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

Решения
10.02.2017
65
10 min

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

#функциональность #sap

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

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

SAP HANA

в рамках виртуального дата-центра и уделим отдельное внимание настройке VMwrae NSX.

Что такое SAP HANA

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

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

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

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

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

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

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

Client

,

Internal

,

Storage

.

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

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

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

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

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

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

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

vSphere

Web

Client

->

Networking

&

Security

.

Networking & Security

Networking & Security

В открывшемся окне

NSX

Home

переходим на панель

Logical

Switches

и, нажав на значок

«+»

, открываем окно

New

Logical

Switch

.

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

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

В поле

Name

указываем значение

DT

Internode

Switch

, в поле

Transport

Zone

нажимаем на кнопку

Change

. В открывшемся окне выбираем

Global

-

Transport

-

Zone

и нажимаем

ОК

.

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

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

В качестве

Replication

Mode

оставляем значение по умолчанию:

Unicast

. Убеждаемся, что опция

Enable

IP

Discovery

находится в активном статусе, и нажимаем

ОК

.

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

На этом шаге рассмотрим, как выполняется привязка ВМ к логическому коммутатору. Согласно сценарию, мы работаем с

Database

Internode

Switch

, и связка со свитчем потребуется только для виртуальных машин:

HANA

ВМ

и

Dynamic

Tiering

Extended

Storage

ВМ

. Для привязки виртуальной машины выполним следующие шаги: кликнем по новому логическому свитчу, созданному в предыдущем шаге:

DT

Internode

Switch

. Далее открываем меню

Actions

и выбираем опцию

Add

VM

для добавления виртуальной машины.

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

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

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

vhHAN

110_

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

Определение параметров 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 к сети

Подключение 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

. Таким образом в группу добавились две виртуальные машины:

vh

HAN

110_

ProdDB

и

vsHDT

110_

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



Екатерина Юдина
Профильный эксперт