SAP NetWeaver на виртуальных машинах Azure. Руководство по развертыванию СУБД SQL Server
В этом документе рассматривается несколько аспектов, которые следует учитывать при развертывании SQL Server для рабочей нагрузки SAP в Azure IaaS. Перед чтением этого документа следует ознакомиться с документом Вопросы развертывания СУБД для рабочей нагрузки SAP на виртуальных машинах Azure, а также с другими руководствами в документации по рабочей нагрузке SAP в Azure.
Важно!
Этот документ относится к версии SQL Server на Windows. SAP не поддерживает версию SQL Server на Linux с программным обеспечением SAP. В этом документе не обсуждается База данных SQL Microsoft Azure, которая представляет собой предложение в формате "платформа как услуга" на платформе Microsoft Azure. В этом документе рассматривается запуск продукта SQL Server в том виде, в каком он традиционно используется для локальных развертываний на виртуальных машинах Azure, с использованием функций инфраструктуры как услуги в Azure. Возможности и функции базы данных в этих двух предложениях различаются, и их не следует путать друг с другом. Дополнительные сведения приведены в статье База данных SQL 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.
Рекомендации по структуре виртуальных машин и виртуальных жестких дисков для связанных с 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 в существующих системах.
Примечание.
Если вы помещаете файлы журнала и файлы данных tempdb в созданную вами папку на диске D:\, убедитесь, что эта папка существует после перезагрузки виртуальной машины. Так как диск D:\ можно инициализировать после перезагрузки виртуальной машины все структуры файлов и каталогов, которые можно удалить. Возможность повторно создать в конечном итоге структуры каталогов на диске D:\ до начала службы SQL Server описаны в этой статье.
Конфигурация виртуальной машины, которая выполняет 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.
Форматирование дисков
Для SQL Server размер блока NTFS для дисков, содержащих файлы данных и журналов SQL Server, должен быть равен 64 КБ. Форматировать диск D:\ нет необходимости. Он предварительно отформатирован.
Чтобы избежать того, что восстановление или создание баз данных инициализирует файлы данных путем нуля содержимого файлов, убедитесь, что контекст пользователя, в котором выполняется служба SQL Server, имеет задачи обслуживания тома справа от пользователя. Дополнительные сведения см. в разделе Мгновенная инициализация файлов базы данных.
SQL Server 2014 и более поздних версий: хранение файлов базы данных непосредственно в хранилище BLOB-объектов Azure
SQL Server 2014 и более поздних версий открывает возможность хранить файлы базы данных непосредственно в хранилище BLOB-объектов Azure без создания вокруг них "оболочки" виртуального жесткого диска. Эта функция предназначена для решения недостатков блочного хранилища Azure на протяжении многих лет. В эти дни не рекомендуется использовать этот метод развертывания и вместо этого выбрать хранилище Azure уровня "Премиум" версии 1, хранилище класса "Премиум" версии 2 или диск "Ультра". Зависит от требований.
Расширение буферного пула SQL Server 2014
В SQL Server 2014 появилась новая функция, которая называется расширением буферного пула. Эта функция, хотя и протестированная в рабочей нагрузке SAP в Azure, не обеспечила улучшение рабочей нагрузки размещения. Поэтому его не следует рассматривать
Рекомендации по резервному копированию и восстановлению для 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 в развертываниях Azure IaaS для 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)
Примечание.
В статье Общие сведения о группах доступности Always On SQL Server в виртуальных машинах Azure приведены сведения о прослушивателе прямого имени сети (DNN) SQL Server. Эта новая функция появилась в SQL Server 2019 CU8. Она устраняет необходимость в использовании подсистемы балансировки нагрузки Azure для обработки виртуального IP-адреса прослушивателя группы доступности.
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.
Важно!
Использование TDE SQL Server, особенно с хранилищем ключей Azure, рекомендуется использовать последние исправления SQL Server 2014, SQL Server 2016 и SQL Server 2017. Это связано с отзывами клиентов, оптимизацией и исправлениями, примененными к коду. Например, см. KBA 4058175.
Минимальные конфигурации развертывания
В этом разделе мы предлагаем набор минимальных конфигураций для разных размеров баз данных в рабочей нагрузке SAP. Слишком трудно оценить, соответствуют ли эти размеры конкретной рабочей нагрузки. В некоторых случаях мы можем быть щедрыми на память по сравнению с размером базы данных. С другой стороны, размер диска может быть слишком низким для некоторых рабочих нагрузок. Таким образом, эти конфигурации следует рассматривать как то, что они есть. Они — это конфигурации, которые должны дать вам точку для начала. Конфигурации для точной настройки конкретных рабочих нагрузок и требований к экономичности.
Пример конфигурации для небольшого экземпляра SQL Server с размером базы данных в диапазоне от 50 ГБ до 250 ГБ может выглядеть следующим образом.
| Настройка | виртуальной машины СУБД | Комментарии |
|---|---|---|
| Тип виртуальной машины | E4s_v3/v4/v5 (4 vCPU/32 ГиБ ОЗУ) | |
| Ускорение работы в сети | Enable | |
| Версия SQL Server | SQL Server 2019 или более поздней версии | |
| Число файлов данных | 4 | |
| # файлов журнала | 1 | |
| # временных файлов данных | 4 или по умолчанию с SQL Server 2016 | |
| Операционная система | Windows Server 2019 или более поздней версии | |
| Объединение дисков | дисковые пространства при желании | |
| Файловая система | NTFS | |
| Размер блока формата | 64 КБ | |
| Число и тип дисков с данными | Хранилище класса Premium версии 1: 2 x P10 (RAID0) Хранилище класса Premium версии 2: 2 x 150 ГиБ (RAID0) — число операций ввода-вывода в секунду по умолчанию и пропускная способность |
Кэш = только для чтения для хранилища класса Premium версии 1 |
| Число и тип дисков с журналами | Хранилище класса Premium версии 1: 1 x P20 Хранилище класса Premium версии 2: 1 x 128 ГиБ — число операций ввода-вывода в секунду по умолчанию и пропускная способность |
Кэш = NONE (НЕТ) |
| Параметр максимальной памяти SQL Server | 90 % физического ОЗУ | Предполагается наличие единственного экземпляра |
Пример конфигурации или небольшого экземпляра SQL Server с размером базы данных от 250 ГБ до 750 ГБ, например меньшей системы SAP Business Suite, может выглядеть следующим образом.
| Настройка | виртуальной машины СУБД | Комментарии |
|---|---|---|
| Тип виртуальной машины | E16s_v3/v4/v5 (16 виртуальных ЦП/128 ГиБ ОЗУ) | |
| Ускорение работы в сети | Enable | |
| Версия SQL Server | SQL Server 2019 или более поздней версии | |
| Число файлов данных | 8 | |
| # файлов журнала | 1 | |
| # временных файлов данных | 8 или по умолчанию с SQL Server 2016 | |
| Операционная система | Windows Server 2019 или более поздней версии | |
| Объединение дисков | дисковые пространства при желании | |
| Файловая система | NTFS | |
| Размер блока формата | 64 КБ | |
| Число и тип дисков с данными | Хранилище класса Premium версии 1: 4 x P20 (RAID0) Хранилище класса Premium версии 2: 4 x 100 ГиБ — 200 ГиБ (RAID0) — пропускная способность по умолчанию и 25 МБ/с дополнительной пропускной способности на диск |
Кэш = только для чтения для хранилища класса Premium версии 1 |
| Число и тип дисков с журналами | Хранилище класса Premium версии 1: 1 x P20 Хранилище класса Premium версии 2: 1 x 200 ГиБ — число операций ввода-вывода в секунду по умолчанию и пропускная способность |
Кэш = NONE (НЕТ) |
| Параметр максимальной памяти SQL Server | 90 % физического ОЗУ | Предполагается наличие единственного экземпляра |
Пример конфигурации для среднего экземпляра SQL Server с размером базы данных в диапазоне от 750 ГБ до 2000 ГБ, например средней системы SAP Business Suite, может выглядеть следующим образом.
| Настройка | виртуальной машины СУБД | Комментарии |
|---|---|---|
| Тип виртуальной машины | E64s_v3/v4/v5 (64 vCPU/432 ГиБ ОЗУ) | |
| Ускорение работы в сети | Enable | |
| Версия SQL Server | SQL Server 2019 или более поздней версии | |
| Число устройств с данными | 16 | |
| Число устройств с журналами | 1 | |
| # временных файлов данных | 8 или по умолчанию с SQL Server 2016 | |
| Операционная система | Windows Server 2019 или более поздней версии | |
| Объединение дисков | дисковые пространства при желании | |
| Файловая система | NTFS | |
| Размер блока формата | 64 КБ | |
| Число и тип дисков с данными | Хранилище класса Premium версии 1: 4 x P30 (RAID0) Хранилище класса Premium версии 2: 4 x 250 ГиБ - 500 ГиБ - плюс 2000 операций ввода-вывода в секунду и 75 МБ/с пропускной способности на диск |
Кэш = только для чтения для хранилища класса Premium версии 1 |
| Число и тип дисков с журналами | Хранилище класса Premium версии 1: 1 x P20 Хранилище класса Premium версии 2: 1 x 400 ГиБ — пропускная способность по умолчанию и 75 МБ/с |
Кэш = NONE (НЕТ) |
| Параметр максимальной памяти SQL Server | 90 % физического ОЗУ | Предполагается наличие единственного экземпляра |
Пример конфигурации для большего экземпляра SQL Server с размером базы данных от 2000 ГБ до 4000 ГБ, например более крупной системы SAP Business Suite, может выглядеть следующим образом.
| Настройка | виртуальной машины СУБД | Комментарии |
|---|---|---|
| Тип виртуальной машины | E96(d)s_v5 (96 vCPU/672 GiB RAM) | |
| Ускорение работы в сети | Enable | |
| Версия SQL Server | SQL Server 2019 или более поздней версии | |
| Число устройств с данными | 24 | |
| Число устройств с журналами | 1 | |
| # временных файлов данных | 8 или по умолчанию с SQL Server 2016 | |
| Операционная система | Windows Server 2019 или более поздней версии | |
| Объединение дисков | дисковые пространства при желании | |
| Файловая система | NTFS | |
| Размер блока формата | 64 КБ | |
| Число и тип дисков с данными | Хранилище класса Premium версии 1: 4 x P30 (RAID0) Хранилище класса Premium версии 2: 4 x 500 ГиБ - 800 ГиБ - плюс 2500 операций ввода-вывода в секунду и 100 МБ/с пропускной способности на диск |
Кэш = только для чтения для хранилища класса Premium версии 1 |
| Число и тип дисков с журналами | Хранилище класса Premium версии 1: 1 x P20 Хранилище класса Premium версии 2: 1 x 400 ГиБ — плюс 1000 операций ввода-вывода в секунду и 75 МБ/с дополнительной пропускной способности |
Кэш = NONE (НЕТ) |
| Параметр максимальной памяти SQL Server | 90 % физического ОЗУ | Предполагается наличие единственного экземпляра |
Пример конфигурации для большого экземпляра SQL Server с размером базы данных размером 4 ТБ+, например крупной глобально используемой системой SAP Business Suite, может выглядеть следующим образом.
| Настройка | виртуальной машины СУБД | Комментарии |
|---|---|---|
| Тип виртуальной машины | Серия M (ОЗУ от 1,0 до 4,0 ТБ) | |
| Ускорение работы в сети | Enable | |
| Версия SQL Server | SQL Server 2019 или более поздней версии | |
| Число устройств с данными | 32 | |
| Число устройств с журналами | 1 | |
| # временных файлов данных | 8 или по умолчанию с SQL Server 2016 | |
| Операционная система | Windows Server 2019 или более поздней версии | |
| Объединение дисков | дисковые пространства при желании | |
| Файловая система | NTFS | |
| Размер блока формата | 64 КБ | |
| Число и тип дисков с данными | Хранилище класса Premium версии 1: 4+ x P40 (RAID0) Хранилище класса Premium версии 2: 4+ x 1000 ГиБ - 4000 ГиБ - плюс 4500 операций ввода-вывода в секунду и 125 МБ/с пропускной способности на диск |
Кэш = только для чтения для хранилища класса Premium версии 1 |
| Число и тип дисков с журналами | Хранилище класса Premium версии 1: 1 x P30 Хранилище класса Premium версии 2: 1 x 500 ГиБ — плюс 2000 операций ввода-вывода в секунду и 125 МБ/с |
Кэш = NONE (НЕТ) |
| Параметр максимальной памяти SQL Server | 95% физической ОЗУ | Предполагается наличие единственного экземпляра |
Например, эта конфигурация — это конфигурация виртуальной машины СУБД sap Business Suite на SQL Server. Эта виртуальная машина размещает 30 ТБ базу данных одного глобального экземпляра SAP Business Suite глобальной компании с более чем $200B годовой выручкой и более 200K сотрудников полного времени. Система выполняет всю финансовую обработку, обработку продаж и распространителя и многие другие бизнес-процессы из разных областей, включая Северная Америка н заработной платы. Система работает в Azure с начала 2018 года с использованием виртуальных машин серии Azure M в качестве виртуальных машин СУБД. Так как система использует Always On с одной синхронной реплика в другой зоне доступности одного региона Azure и другой асинхронной реплика в другом регионе Azure. Уровень приложений NetWeaver развертывается на виртуальных машинах Ev4.
| Настройка | виртуальной машины СУБД | Комментарии |
|---|---|---|
| Тип виртуальной машины | M192dms_v2 (192 vCPU/4,196 ГиБ ОЗУ) | |
| Ускорение работы в сети | Включен | |
| Версия SQL Server | SQL Server 2019 | |
| Число файлов данных | 32 | |
| # файлов журнала | 1 | |
| # временных файлов данных | 8 | |
| Операционная система | Windows Server 2019 | |
| Объединение дисков | Дисковые пространства | |
| Файловая система | NTFS | |
| Размер блока формата | 64 КБ | |
| Число и тип дисков с данными | Хранилище класса Premium версии 1: 16 x P40 | Кэш = Read Only (только для чтения) |
| Число и тип дисков с журналами | Хранилище класса Premium версии 1: 1 x P60 | Использование акселератора записи |
| # и тип дисков tempdb | Хранилище класса Premium версии 1: 1 x P30 | Без кэширования |
| Параметр максимальной памяти SQL Server | 95% физической ОЗУ |
Общие сведения об SQL Server для SAP в Azure
Это руководство содержит много рекомендаций, и мы советуем прочитать его несколько раз перед планированием развертывания в Azure. В целом необходимо учитывать основные рекомендации, касающиеся СУБД в Azure:
- Используйте последний выпуск СУБД, например SQL Server 2019, который имеет самые преимущества в Azure.
- Тщательно спланируйте системный ландшафт SAP в Azure, чтобы сбалансировать макет файла данных и ограничения Azure:
- Не устанавливайте слишком много дисков, но обеспечьте достаточное количество для достижения необходимого числа операций ввода-вывода.
- Создавайте stripe-массив из дисков только при необходимости обеспечить более высокую пропускную способность.
- Не устанавливайте слишком много дисков, но обеспечьте достаточное количество для достижения необходимого числа операций ввода-вывода.
- Никогда не устанавливайте программное обеспечение или не помещайте файлы, требующие сохраняемости на диске D:\, так как он не является постоянным и что-либо на этом диске можно потерять при перезагрузке Windows или перезапуске виртуальной машины.
- Используйте решение HA/DR поставщика СУБД для репликации данных из базы данных.
- Всегда используйте разрешение имен, не полагайтесь на IP-адреса.
- Если вы используете прозрачное шифрование данных в SQL Server, применяйте последние исправления для SQL Server.
- Соблюдайте осторожность при использовании образов SQL Server из Azure Marketplace. При использовании образа SQL Server необходимо изменить параметры сортировки экземпляра, прежде чем устанавливать на него систему SAP NetWeaver.
- Установите и настройте мониторинг узла SAP для Azure, как описано в руководстве по развертыванию.
Следующие шаги
Читать статью