SAP NetWeaver на виртуальных машинах Azure. Руководство по развертыванию СУБД SQL Server

В этом документе рассматривается несколько аспектов, которые следует учитывать при развертывании SQL Server для рабочей нагрузки SAP в Azure IaaS. В качестве предварительных условий для этого документа ознакомьтесь с рекомендациями по развертыванию СУБД Azure Виртуальные машины для рабочей нагрузки SAP и другим руководствам по рабочей нагрузке SAP в документации По Azure.

Как правило, рекомендуется использовать последние выпуски SQL Server для выполнения рабочей нагрузки SAP в Azure IaaS. Последние выпуски SQL Server обеспечивают лучшую интеграцию с некоторыми службами и функциями Azure. Или содержат изменения для оптимизации работы в инфраструктуре Azure IaaS.

Общие сведения о SQL Server, работающем в Azure Виртуальные машины (виртуальная машина), см. в следующих статьях:

• SQL Server в Azure Виртуальные машины (Windows)
• Автоматизация управления с помощью расширения агента IaaS Windows SQL Server
• Настройка интеграции Azure Key Vault для SQL Server на виртуальных машинах Azure (Resource Manager)
• Контрольный список: рекомендации для SQL Server на виртуальных машинах Azure
• Хранилище. Рекомендации по производительности SQL Server на виртуальных машинах Azure
• Рекомендации по настройке HADR (SQL Server на виртуальных машинах Azure)

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

Существуют некоторые специальные сведения об SQL Server в IaaS, которые следует знать перед продолжением:

• Поддержка версий SQL: даже с примечанием SAP #1928533 заявив, что минимальный поддерживаемый выпуск SQL Server — SQL Server 2008 R2, окно поддерживаемых версий SQL Server в Azure также определяется жизненным циклом SQL Server. Расширенное обслуживание SQL Server 2012 закончилось в середине 2022 года. В результате текущий минимальный выпуск для вновь развернутых систем должен быть SQL Server 2014. Чем в последнее время, тем лучше. Последние выпуски SQL Server обеспечивают лучшую интеграцию с некоторыми службами и функциями Azure. Или содержат изменения для оптимизации работы в инфраструктуре Azure IaaS.
• Использование образов из Azure Marketplace. Самый быстрый способ развернуть новую виртуальную машину Microsoft Azure — использовать образ из Azure Marketplace. В Azure Marketplace имеются образы, содержащие последние выпуски SQL Server. Образы, в которых уже установлен SQL Server, нельзя сразу же использовать для приложений SAP NetWeaver. Причина в том, что параметры сортировки SQL Server по умолчанию устанавливаются в этих образах, а не в параметрах сортировки, необходимых для систем SAP NetWeaver. Чтобы использовать такие образы, выполните действия, описанные в разделе Использование образов SQL Server из Microsoft Azure Marketplace.
• Поддержка нескольких экземпляров SQL Server на одной виртуальной машине Azure. Этот метод развертывания поддерживается. Но следует учитывать ограничения ресурсов, особенно в отношении пропускной способности сети и хранилища для типа виртуальной машины, которую вы используете. Подробные сведения см. в статье Размеры виртуальных машин в Azure. Эти ограничения квоты могут препятствовать реализации архитектуры с несколькими экземплярами, которую вы можете реализовать локально. Что касается конфигурации и вмешательства в совместное использование ресурсов, доступных в пределах одной виртуальной машины, необходимо учитывать те же аспекты, что и при локальном использовании.
• Несколько баз данных SAP в одном экземпляре SQL Server на одной виртуальной машине: поддерживаются такие конфигурации. Рекомендации по использованию нескольких баз данных SAP, совместно использующих общие ресурсы одного экземпляра SQL Server, аналогичны соответствующим рекомендациям для локальных развертываний. Имейте в виду другие ограничения, такие как количество дисков, которые можно подключить к определенному типу виртуальной машины. А также квоты сети и хранилища для определенных типов виртуальных машин, как описано в статье Размеры виртуальных машин в Azure.

Новые виртуальные машины серии M и SQL Server

Azure выпустила несколько новых семейств номеров SKU серии M под семейством Mv3. Некоторые типы виртуальных машин в этом семействе не должны использоваться для SQL Server, включая SQL Server 2022 без отключения SMT (Hyperthreading) в гостевой ОС Windows Server. Причина заключается в количестве узлов NUMA, представленных в гостевой ОС Windows Server, которая с более чем 64 виртуальными ЦП слишком велика для размещения SQL Server. Отключив SMT в гостевой ОС Windows Server, количество виртуальных ЦП уменьшается. Таким образом, количество виртуальных ЦП меньше 64 в каждом узле NUMA. Способ отключения SMT описан здесь. Конкретные типы виртуальных машин:

• M176(d)s_3_v3 — отключите SMT или используйте M176bds_4_v3 или M176bds_4_v3 в качестве альтернативы
• M176(d)s_4_v3 — отключите SMT или используйте M176bds_4_v3 в качестве альтернативы
• M624(d)s_12_v3 — отключите SMT или используйте M416ms_v2 в качестве альтернативы
• M832(d)s_12_v3 — отключите SMT или используйте M416ms_v2 в качестве альтернативы
• M832i(d)s_16_v3 — отключите SMT или используйте M416ms_v2 в качестве альтернативы

Рекомендации по структуре виртуальных машин и виртуальных жестких дисков для связанных с SAP развертываний SQL Server

В соответствии с общим описанием, операционной системой, исполняемыми файлами SQL Server, исполняемые файлы SAP должны размещаться или устанавливаться на отдельных дисках Azure. Как правило, большинство системных баз данных SQL Server не используются на высоком уровне с рабочей нагрузкой SAP NetWeaver. Тем не менее, системные базы данных SQL Server должны располагаться вместе с другими каталогами SQL Server на отдельном диске Azure. База данных tempdb SQL Server должна находиться на не сохраняемом диске (D:\) или на отдельном диске.

• Все типы сертифицированных виртуальных машин SAP (см. примечание SAP #1928533), данные tempdb и файлы журналов можно поместить на диск, отличном от D:\.
• В выпусках SQL Server, где SQL Server устанавливает tempdb только с одним файлом данных, рекомендуется использовать несколько файлов данных tempdb. Учитывайте, что тома диска D:\ отличаются по размеру и возможностям на основе типа виртуальной машины. Точный размер диска D:\ разных виртуальных машин см. в статье Размеры виртуальных машин Windows в Azure.

При таких конфигурациях база данных tempdb может потреблять больше пространства и, что особенно важно, больше операций ввода-вывода в секунду, а также большую пропускную способность хранилища, чем может предоставить системный диск. Диск, отличный от D:\, также обеспечивает лучшую задержку ввода-вывода и пропускную способность. Чтобы определить необходимый размер tempdb, можно проверить размеры tempdb в существующих системах.

Конфигурация виртуальной машины, которая выполняет SQL Server с базой данных SAP и где данные tempdb и файл журнала tempdb помещаются на диск D:\ и хранилище Azure класса Premium версии 1 или 2 будет выглядеть следующим образом:

На схеме показан простой случай. Как упоминалось в статье Вопросы развертывания СУБД для рабочей нагрузки SAP на виртуальных машинах Azure, тип хранилища Azure, количество и размер дисков зависят от различных факторов. Но, как правило, мы рекомендуем:

• Для небольших и средних развертываний используется один большой том, содержащий файлы данных SQL Server. Причина этой конфигурации заключается в том, что проще справиться с различными рабочими нагрузками ввода-вывода в случае, если файлы данных SQL Server не имеют одного свободного места. В то время как в крупных развертываниях, особенно при развертывании, где клиент перемещен с разнородной миграцией базы данных на SQL Server в Azure, мы использовали отдельные диски, а затем распределяли файлы данных по этим дискам. Такая архитектура выполняется только в том случае, если каждый диск имеет одинаковое количество файлов данных, все файлы данных имеют одинаковый размер и примерно имеют одинаковое свободное место.
• Использовать диск D:\ для базы данных tempdb, если производительность достаточно высокая. Если общая рабочая нагрузка ограничена производительностью tempdb, расположенной на диске D:\, необходимо переместить tempdb в хранилище Azure уровня "Премиум" версии 1 или 2 или диск "Ультра", как рекомендуется в этой статье.

Механизм пропорционального заполнения SQL Server равномерно распределяет операции чтения и записи по всем файлам данных при условии, что все файлы данных SQL Server имеют одинаковый размер и имеют одинаковую скорость свободного доступа. SAP на SQL Server обеспечивает лучшую производительность при равномерном распределении операций чтения и записи во всех доступных файлах данных. Если база данных содержит слишком мало файлов данных или существующие файлы данных с высокой степенью балансировки, лучший способ исправления — это экспорт и импорт R3load. Экспорт и импорт R3load требуют периода простоя, и их следует выполнять только в случае очевидных проблем с производительностью, которые необходимо устранить. Если файлы данных имеют только умеренный размер, увеличьте все файлы данных до одного размера, а SQL Server перебалансирует данные с течением времени. SQL Server автоматически увеличивает файлы данных, даже если установлен флаг трассировки 1117 или используется ли SQL Server 2016 или более поздней версии без флага трассировки.

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

Для виртуальной машины Серии Azure M задержка записи в журнал транзакций может быть сокращена по сравнению с производительностью хранилища Azure уровня "Премиум" версии 1 при использовании ускорителя записи Azure. Если указанная задержка хранилища класса Premium версии 1 ограничивает масштабируемость рабочей нагрузки SAP, диск, в который хранится файл журнала транзакций SQL Server, можно включить для ускорителя записи. Дополнительные сведения см. в документе об ускорителе записи. Акселератор записи Azure не работает с диском хранилища Azure уровня "Премиум" версии 2 и "Ультра". В обоих случаях задержка лучше, чем то, что обеспечивает хранилище Azure класса Premium версии 1. Ускоритель записи не поддерживает SSD класса Premium версии 2.

Форматирование дисков

Для SQL Server размер блока NTFS для дисков, содержащих файлы данных и журналов SQL Server, должен быть равен 64 КБ. Форматировать диск D:\ нет необходимости. Этот диск имеет преформатированную форму.

Чтобы избежать того, что восстановление или создание баз данных инициализирует файлы данных путем нуля содержимого файлов, убедитесь, что контекст пользователя, в котором выполняется служба SQL Server, имеет задачи обслуживания тома справа от пользователя. Дополнительные сведения см. в разделе Мгновенная инициализация файлов базы данных.

SQL Server 2014 и более поздних версий SQL Server — хранение файлов базы данных непосредственно в Хранилище BLOB-объектов Azure

SQL Server 2014 и более поздних версий открывает возможность хранить файлы базы данных непосредственно в хранилище BLOB-объектов Azure без создания вокруг них "оболочки" виртуального жесткого диска. Эта функция предназначена для решения недостатков блочного хранилища Azure на протяжении многих лет. В эти дни не рекомендуется использовать этот метод развертывания и вместо этого выбрать хранилище Azure уровня "Премиум" версии 1, хранилище класса "Премиум" версии 2 или диск "Ультра". Зависит от требований.

Рекомендации по резервному копированию и восстановлению для SQL Server

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

Существует несколько способов резервного копирования и восстановления баз данных SQL Server в Azure. Чтобы получить лучший обзор и подробные сведения, ознакомьтесь с резервным копированием и восстановлением документа для SQL Server на виртуальных машинах Azure. В статье описано несколько возможностей.

Использование образов SQL Server из Microsoft Azure Marketplace

Корпорация Майкрософт предлагает виртуальные машины в Azure Marketplace, которые уже содержат версии SQL Server. Следовательно, клиенты SAP, которым нужны лицензии на SQL Server и Windows, с помощью этих образов могут удовлетворить потребность в лицензиях, развертывая виртуальные машины с уже установленной средой SQL Server. Чтобы использовать такие образы для SAP, необходимо учитывать следующие факторы.

• Неознакомительные версии SQL Server стоят дороже, чем виртуальная машина "только для Windows", развернутая из Azure Marketplace. Чтобы сравнить цены, воспользуйтесь страницами цен на виртуальные машины Windows и цен на виртуальные машины SQL Server Enterprise.
• Вы можете использовать только выпуски SQL Server, поддерживаемые SAP для своего программного обеспечения.
• Параметры сортировки экземпляра SQL Server, который устанавливается на виртуальных машинах из Azure Marketplace, не соответствуют параметрам, необходимым SAP NetWeaver для запуска экземпляра SQL Server. Параметры сортировки можно изменить, выполнив инструкции из следующего раздела.

Изменение параметров сортировки SQL Server на виртуальной машине с Microsoft Windows и SQL Server

Так как образы SQL Server в Azure Marketplace не настроены для использования параметров сортировки, необходимых для приложений SAP NetWeaver, его необходимо изменить сразу после развертывания. Чтобы изменить параметры сортировки в SQL Server, выполните следующие действия сразу после того, как виртуальная машина будет развернута и администратор сможет выполнить в нее вход.

• Откройте окно командной строки Windows с правами администратора.
• Перейдите в каталог C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012.
• Выполните команду: Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2
  • <local_admin_account_name> — это учетная запись, которая была определена как учетная запись администратора при развертывании виртуальной машины в первый раз с помощью коллекции.

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

• Откройте Среда SQL Server Management Studio.
• Откройте окно запроса.
• Выполните команду sp_helpsort в базе данных master SQL Server.

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

Latin1-General, binary code point comparison sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data

Если результат отличается, остановите любое развертывание и изучите, почему команда установки не работала должным образом. Развертывание приложений SAP NetWeaver на экземпляре SQL Server с различными кодовыми страницами SQL Server, чем упоминалось, не поддерживается для развертываний NetWeaver.

Высокая доступность SQL Server для SAP в Azure

С помощью SQL Server в развертываниях IaaS Azure для SAP можно добавить несколько различных возможностей для развертывания уровня базы данных с высоким уровнем доступности. Azure предоставляет разные соглашения об уровне обслуживания для одной виртуальной машины с помощью разных хранилищ блоков Azure, пары виртуальных машин, развернутых в группе доступности Azure, или пары виртуальных машин, развернутых в Azure Зоны доступности. Для производственных систем мы ожидаем, что вы развернете пару виртуальных машин в масштабируемом наборе виртуальных машин с гибкой оркестрацией в двух зонах доступности. Дополнительные сведения см . в сравнении различных типов развертывания для рабочей нагрузки SAP. Одна виртуальная машина запускает активный экземпляр SQL Server. Другая виртуальная машина запускает пассивный экземпляр

Кластеризация SQL Server с помощью файлового сервера горизонтального масштабирования Windows или общего диска Azure

В Windows Server 2016 корпорация Майкрософт представила локальные дисковые пространства. В большинстве случаев кластеризация экземпляра отказоустойчивого кластера SQL Server поддерживается на основе развертывания Локальных дисковых пространств. Azure также предоставляет Общие диски Azure, которые можно использовать для кластеризации Windows. Для рабочей нагрузки SAP мы не поддерживаем эти параметры высокой доступности.

Доставка журналов SQL Server

Одна из функций высокого уровня доступности — доставка журналов SQL Server. Если для виртуальных машин в конфигурации HA работает разрешение имен, проблем нет. Настройка в Azure не отличается от любой настройки, выполняемой в локальной среде, связанной с настройкой доставки журналов и принципов доставки журналов. Сведения о доставке журналов SQL Server см. в статье о доставке журналов (SQL Server).

Функциональные возможности доставки журналов SQL Server почти не использовались в Azure для обеспечения высокой доступности в пределах одного региона Azure. Тем не менее в следующих сценариях клиенты SAP успешно использовали доставку журналов с использованием Azure:

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

Always On в SQL Server

Так как AlwaysOn поддерживается для локальной среды SAP (см. примечание SAP #1772688), она поддерживается в сочетании с SAP в Azure. Существуют некоторые особые рекомендации по развертыванию прослушивателя группы доступности SQL Server (не следует путать с набором доступности Azure). Поэтому необходимо выполнить некоторые различные действия по установке.

Ниже приведены некоторые рекомендации по использованию прослушивателя группы доступности.

• Использование прослушивателя группы доступности возможно, только если в качестве гостевой ОС виртуальной машины используется Windows Server 2012 или более поздней версии. Для Windows Server 2012 убедитесь, что установлено обновление для включения прослушивателей группы доступности SQL Server на виртуальных машинах Microsoft Azure под управлением Windows Server 2008 R2 и Windows Server 2012.
• Для Windows Server 2008 R2 это исправление не существует. В этом случае AlwaysOn необходимо использовать таким же образом, как зеркальное отображение базы данных. Указав партнера отработки отказа в строке подключений (выполняется с помощью параметра SAP default.pfl dbs/mss/server — см. примечание SAP #965908).
• Используя прослушиватель группы доступности, необходимо подключить виртуальные машины базы данных к выделенной подсистеме балансировки нагрузки. Статические IP-адреса следует назначить сетевым интерфейсам этих виртуальных машин в конфигурации AlwaysOn (определение статического IP-адреса описано в этой статье). Статические IP-адреса по сравнению с DHCP препятствуют назначению новых IP-адресов в случаях, когда обе виртуальные машины могут быть остановлены.
• Особые действия требуются при построении конфигурации кластера WSFC, где кластеру требуется назначить специальный IP-адрес, так как Azure с текущими функциональными возможностями назначит имени кластера тот же IP-адрес, что и у узла, на котором создается кластер. Такое поведение означает, что необходимо вручную назначить кластеру другой IP-адрес.
• Прослушиватель группы доступности будет создан в Azure с конечными точками TCP/IP, назначенными виртуальным машинам, на которых запускаются первичная и вторичная реплики группы доступности.
• Может возникнуть необходимость обеспечить безопасность этих конечных точек с помощью списков управления доступом.

Подробная документация по развертыванию AlwaysOn с SQL Server на виртуальных машинах Azure:

• Введение в группы доступности AlwaysOn SQL Server на виртуальных машинах Azure.
• Настройка группы доступности AlwaysOn на виртуальных машинах Azure в разных регионах.
• Настройка подсистемы балансировки нагрузки для группы доступности AlwaysOn в Azure.
• Рекомендации по настройке HADR (SQL Server на виртуальных машинах Azure)

SQL Server AlwaysOn — это самая популярная функция высокой доступности и аварийного восстановления, которая используется в Azure для развертываний рабочей нагрузки SAP. Большинство клиентов применяет AlwaysOn для обеспечения высокой доступности в одном регионе Azure. Если развертывание будет ограничено только двумя узлами, у вас есть два варианта подключения:

• Использование прослушивателя группы доступности. При использовании прослушивателя группы доступности необходимо развернуть подсистему балансировки нагрузки Azure.
• С SQL Server 2016 с пакетом обновления 3 (SP3), SQL Server 2017 CU 25 или SQL Server 2019 CU8 или более поздних выпусков SQL Server в Windows Server 2016 или более поздней версии можно использовать прослушиватель direct Network Name (DNN) вместо подсистемы балансировки нагрузки Azure. Это устранит необходимость в использовании подсистемы балансировки нагрузки Azure.

Использование параметров подключения зеркального отображения базы данных SQL Server следует учитывать только для изучения проблем с другими двумя методами. В этом случае необходимо настроить подключение приложений SAP так, чтобы были указаны имена обоих узлов. Точные сведения о такой конфигурации на стороне SAP задокументированы в примечании к SAP 965908. При использовании этого параметра не придется настраивать прослушиватель группы доступности. И с этим нет подсистемы балансировки нагрузки Azure и с этим может исследовать проблемы этих компонентов. Но помните, что этот параметр работает, только если вы ограничите группу доступности двумя экземплярами.

Большинство клиентов используют функции AlwaysOn SQL Server для аварийного восстановления между регионами Azure. Некоторые клиенты также используют возможность создавать резервные копии из вторичной реплики.

Прозрачное шифрование данных SQL Server

Многие клиенты используют прозрачное шифрование данных (TDE) SQL Server при развертывании баз данных SAP SQL Server в Azure. Функция прозрачного шифрования данных для SQL Server полностью поддерживается системой SAP (см. примечание к SAP 1380493).

Применение прозрачного шифрования данных SQL Server

В случаях, когда вы выполняете разнородную миграцию из другой базы данных, работающей в локальной среде, в Windows/SQL Server, запущенную в Azure, необходимо создать пустую целевую базу данных в SQL Server заранее. На следующем шаге вы будете применять функциональные возможности TDE SQL Server к этой пустой базе данных. Причина такой последовательности в том, что процесс шифрования пустой базы данных может занять немало времени. Процессы импорта SAP импортируют данные в зашифрованную базу данных во время фазы простоя. Импорт зашифрованной базы данных требует гораздо меньше ресурсов, чем шифрование базы данных после завершения этапа экспорта в фазе простоя. У некоторых пользователей был негативный опыт применения прозрачного шифрования данных с нагрузкой SAP в базе данных. Поэтому рекомендации рассматривают развертывание TDE как действие, которое необходимо выполнить без рабочей нагрузки SAP в конкретной базе данных. В SQL Server 2016 можно остановить и возобновить проверку TDE, которая выполняет начальное шифрование. Документ прозрачное шифрование данных (TDE) описывает команду и сведения.

Если вы перемещаете базы данных SAP SQL Server из локальной среды в Azure, мы рекомендуем протестировать, в какой инфраструктуре шифрование будет выполнено быстрее. В этом случае учитывайте следующие факты:

• Невозможно определить, сколько потоков используется для шифрования данных в базе данных. Число потоков во многом зависит от числа томов диска, по которым распределены файлы данных и журналов SQL Server. Означает, что чем больше разных томов (букв дисков), тем больше потоков параллельно выполняют шифрование. Такая конфигурация немного противоречит предыдущим рекомендациям по конфигурации диска, когда мы советовали использовать одно или всего несколько дисковых пространств для файлов базы данных SQL Server на виртуальных машинах Azure. В конфигурации с небольшим числом томов во время шифрования будет задействовано небольшое число потоков. Один поток считывает экстент размером 64 КБ, шифрует его и затем делает запись в файл журнала транзакций о том, что экстент был зашифрован. В результате журнал транзакций испытывает умеренную нагрузку.
• В предыдущих выпусках SQL Server сжатие резервных копий уже не позволяло повысить эффективность при шифровании базы данных SQL Server. Такое поведение могло превратиться в проблему, если вы планировали зашифровать базу данных SQL Server локально, а затем скопировать резервную копию в Azure, чтобы восстановить базу данных в Azure. Сжатие резервных копий SQL Server может достичь коэффициента сжатия 4.
• В SQL Server 2016 SQL Server представила новые функциональные возможности, которые позволяют эффективно сжимать резервные копии зашифрованных баз данных. Дополнительные сведения см. в этом блоге.

Использование Azure Key Vault

Azure предлагает службу Key Vault для хранения ключей шифрования. SQL Server, с другой стороны, предлагает соединитель, чтобы использовать Azure Key Vault для хранения сертификатов TDE.

Дополнительные сведения об использовании Azure Key Vault для прозрачного шифрования данных в SQL Server см. в следующих разделах:

• Настройка интеграции Azure Key Vault для SQL Server на виртуальных машинах Azure (Resource Manager).
• Дополнительные вопросы клиентов о прозрачном шифровании данных в SQL Server — TDE + Azure Key Vault.

Минимальные конфигурации развертывания

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

Пример конфигурации для небольшого экземпляра SQL Server с размером базы данных в диапазоне от 50 ГБ до 250 ГБ может выглядеть следующим образом.

Пример конфигурации или небольшого экземпляра SQL Server с размером базы данных от 250 ГБ до 750 ГБ, например меньшей системы SAP Business Suite, может выглядеть следующим образом.

Пример конфигурации для среднего экземпляра SQL Server с размером базы данных в диапазоне от 750 ГБ до 2000 ГБ, например средней системы SAP Business Suite, может выглядеть следующим образом.

Пример конфигурации для большего экземпляра SQL Server с размером базы данных от 2000 ГБ до 4000 ГБ, например более крупной системы SAP Business Suite, может выглядеть следующим образом.

Пример конфигурации для большого экземпляра SQL Server с размером базы данных размером 4 ТБ+, например крупной глобально используемой системой SAP Business Suite, может выглядеть следующим образом.

Например, эта конфигурация — это конфигурация виртуальной машины базы данных SAP Business Suite на SQL Server. Эта виртуальная машина размещает базу данных 30TB одного глобального экземпляра SAP Business Suite глобальной компании с более чем $200B годовой выручкой и более 200 КБ сотрудников полного времени. Система выполняет все финансовые процессы, продажи и распространительную обработку и многие другие бизнес-процессы из разных областей, включая Северная Америка заработную плату. Система работает в Azure с начала 2018 года с использованием виртуальных машин серии M Azure в качестве виртуальных машин базы данных. Так как система использует AlwaysOn с одной синхронной репликой в другой зоне доступности одного региона Azure. Асинхронная реплика в другом регионе Azure. Уровень приложений NetWeaver развертывается в последних семействах виртуальных машин D(a)/E(a).

Общие сведения об SQL Server для SAP в Azure

Это руководство содержит много рекомендаций, и мы советуем прочитать его несколько раз перед планированием развертывания в Azure. В целом, однако, обязательно следуйте лучшим рекомендациям SQL Server в Azure:

1. Используйте последний выпуск SQLServer, например SQL Server 2022, который имеет самые преимущества в Azure.
2. Тщательно спланируйте системный ландшафт SAP в Azure, чтобы сбалансировать макет файла данных и ограничения Azure:
   • Не устанавливайте слишком много дисков, но обеспечьте достаточное количество для достижения необходимого числа операций ввода-вывода.
     • Создавайте stripe-массив из дисков только при необходимости обеспечить более высокую пропускную способность.
3. Никогда не устанавливайте программное обеспечение или не помещайте файлы, требующие сохраняемости на диске D:\, так как он не является непреднаправленным. Все, что на этом диске может быть потеряно при перезагрузке Windows или перезапуске виртуальной машины.
4. Используйте решение SQL Server AlwaysOn для репликации данных базы данных.
5. Всегда используйте разрешение имен, не полагайтесь на IP-адреса.
6. Если вы используете прозрачное шифрование данных в SQL Server, применяйте последние исправления для SQL Server.
7. Соблюдайте осторожность при использовании образов SQL Server из Azure Marketplace. При использовании образа SQL Server необходимо изменить параметры сортировки экземпляра, прежде чем устанавливать на него систему SAP NetWeaver.
8. Установите и настройте мониторинг узла SAP для Azure, как описано в руководстве по развертыванию.

Следующие шаги

Читать статью

• Вопросы развертывания СУБД для рабочей нагрузки SAP на виртуальных машинах Azure