Изменить

Запуск SAP HANA для виртуальных машин Linux в вертикально масштабируемой архитектуре в Azure

Azure
Виртуальные машины Azure

В этой эталонной архитектуре показан набор проверенных методов запуска SAP HANA в высокодоступной среде масштабирования, поддерживающей аварийное восстановление в Azure. Эта реализация посвящена только уровню базы данных.

Архитектура

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

На следующей схеме показана эталонная архитектура SAP HANA в Azure:

Схема, демонстрирующая архитектуру регионального развертывания.

Скачайте файл Visio, содержащий схемы в этой статье.

Примечание.

Для развертывания этой эталонной архитектуры требуется соответствующее лицензирование продуктов SAP и других технологий, отличных от Майкрософт.

Рабочий процесс

Эта эталонная архитектура описывает типичную базу данных SAP HANA, запущенную в Azure, в высокодоступном развертывании для повышения доступности системы. Архитектуру и ее компоненты можно настроить на основе бизнес-требований (RTO, RPO, ожиданий в работе, системной роли) и потенциально сократить до одной виртуальной машины. Макет сети упрощен для демонстрации архитектурных субъектов такой среды SAP и не предназначен для описания полной корпоративной сети.

Сеть

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

Если приложения, подключающиеся к SAP HANA, работают на виртуальных машинах, виртуальные машины приложений должны находиться в одной виртуальной сети, но в выделенной подсети приложения. Кроме того, если подключение SAP HANA не является основной базой данных, виртуальные машины приложения могут находиться в других виртуальных сетях. Разделение на подсети по рабочей нагрузке позволяет упростить включение групп безопасности сети (NSG) для задания правил безопасности, применимых только к виртуальным машинам SAP HANA.

Шлюз, избыточный между зонами. Шлюз подключает различные сети, расширяя локальную сеть к виртуальной сети Azure. Мы рекомендуем использовать ExpressRoute для создания частных подключений, которые не проходят через общедоступный Интернет. Вы также можете использовать подключение типа "сеть — сеть ". Azure ExpressRoute или VPN-шлюзы можно развертывать в зонах для защиты от сбоев зоны. Сведения о различиях между зональным развертыванием и развертыванием, избыточным между зонами, см . в шлюзах виртуальной сети, избыточных между зонами. IP-адреса, используемые для развертывания зоны шлюзов, должны иметь номер SKU уровня "Стандартный".

Группы безопасности сети (NSG). Чтобы ограничить входящий и исходящий сетевой трафик виртуальной сети, создайте группы безопасности сети, которые, в свою очередь, назначаются определенным подсетям. Базы данных и подсети приложений защищены с помощью определенных групп безопасности безопасности рабочей нагрузки.

Группы безопасности приложений (ASG). Чтобы определить детализированные политики безопасности сети в группах безопасности сети на основе рабочих нагрузок, ориентированных на приложения, используйте группы безопасности приложений вместо явных IP-адресов. Они позволяют группировать сетевые интерфейсы виртуальных машин по имени и помогают защитить приложения путем фильтрации трафика из доверенных сегментов сети.

Сетевые карты (NIC). Сетевые интерфейсы карта обеспечивают все обмен данными между виртуальными машинами в виртуальной сети. Традиционные локальные развертывания SAP реализуют несколько сетевых адаптеров на компьютере для разделения административного трафика от бизнес-трафика.

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

Сетевые карты Azure поддерживают несколько IP-адресов. Эта поддержка соответствует рекомендуемой методике SAP использовать имена виртуальных узлов для установки. Полный обзор см . в заметке SAP 962955. (Для доступа к заметкам SAP требуется учетная запись SAP Service Marketplace.)

Примечание.

Как указано в примечании SAP 2731110, не помещайте виртуальные сетевые (модуль) (NVA) между приложением и уровнями базы данных для любого стека приложений SAP. Это позволяет значительно сократить время обработки пакетов данных и неприемлемо замедляет производительность приложения.

Виртуальные машины

Эта архитектура использует виртуальные машины (виртуальная машина). Azure предлагает масштабирование с одним узлом до 23,5 Tebibytes (TiB) памяти на виртуальных машинах. Каталог оборудования SAP сертифицированных и поддерживаемых sap HANA содержит виртуальные машины, сертифицированные для базы данных SAP HANA. Дополнительные сведения о поддержке SAP для типов виртуальных машин и метрик пропускной способности (SAPS) см. в 1928533 . Приложения SAP в Microsoft Azure: поддерживаемые продукты и типы виртуальных машин Azure. (Для доступа к этим и другим заметкам SAP требуется учетная запись SAP Service Marketplace.)

Корпорация Майкрософт и SAP совместно сертифицируют диапазон размеров виртуальных машин для рабочих нагрузок SAP HANA. Например, небольшие развертывания могут выполняться на виртуальной машине Edsv4 или Edsv5 с 160 ГиБ или более ОЗУ. Для поддержки крупнейших размеров памяти SAP HANA на виртуальных машинах( до 23 ТиБ) можно использовать виртуальные машины серии Mv2. Типы виртуальных машин M208 обеспечивают приблизительно 260 000 SAPS, а типы виртуальных машин M832ixs обеспечивают приблизительно 795 900 SAPS.

Виртуальные машины поколения 2(2-го поколения). При развертывании виртуальных машин можно использовать виртуальные машины поколения 1 или поколения 2. Виртуальные машины поколения 2 поддерживают ключевые функции, недоступные для виртуальных машин поколения 1. Для SAP HANA это особенно важно, так как некоторые семейства виртуальных машин, такие как Mv2 и Mdsv2, поддерживаются только как виртуальные машины 2-го поколения. Аналогичным образом, сертификация SAP в Azure для некоторых более новых виртуальных машин может потребовать, чтобы они были только 2-го поколения для полной поддержки, даже если Azure разрешает оба этих виртуальных машина. Дополнительные сведения см. в заметке SAP 1928533 — приложения SAP в Microsoft Azure: поддерживаемые продукты и типы виртуальных машин Azure.

Так как все остальные виртуальные машины, поддерживающие SAP HANA, позволяют выбирать только 2-го поколения или 1-го поколения, рекомендуется развертывать только все виртуальные машины SAP как 2-го поколения. Это также относится к виртуальным машинам с низкими требованиями к памяти. Даже наименьшая виртуальная машина SAP HANA 160 ГиБ может выполняться как виртуальная машина 2-го поколения и может быть изменена на самую большую виртуальную машину, доступную в вашем регионе и подписке.

Группы размещения близкого взаимодействия (PPG). Чтобы оптимизировать задержку сети, можно использовать группы размещения близкого взаимодействия, которые предпочитают коллокацию, то есть виртуальные машины находятся в одном центре обработки данных, чтобы свести к минимуму задержку между SAP HANA и подключением виртуальных машин приложений. Для самой архитектуры SAP HANA не требуются PPG, они предназначены только для совместного размещения SAP HANA с виртуальными машинами уровня приложений. Из-за потенциальных ограничений с PPG добавление базы данных AvSet в PPG системы SAP должно выполняться разреженно, только если требуется для задержки между приложением SAP и трафиком базы данных. Дополнительные сведения о сценариях использования PPG см. в связанной документации. Так как PPG ограничивает рабочие нагрузки одним центром обработки данных, PPG не может охватывать несколько зон доступности.

Компоненты

Рекомендации

В этом разделе описываются основные рекомендации по запуску SAP HANA в Azure.

Масштабируемость

Эта архитектура выполняет SAP HANA на виртуальных машинах, которые могут масштабировать до 23 ТиБ в одном экземпляре.

Если рабочая нагрузка превышает максимальный размер виртуальной машины, рекомендуется использовать конфигурации HANA с несколькими узлами. Для приложений обработки транзакций в сети (OLTP) общая емкость памяти горизонтального масштабирования может быть не более 4 x 23 ТиБ. Для приложений оперативной аналитической обработки (OLAP) емкость памяти горизонтального масштабирования может быть не более 16 x 7,6 ТиБ. Например, вы можете развернуть SAP HANA в конфигурации горизонтального масштабирования с резервным копированием на виртуальных машинах под управлением Red Hat Enterprise Linux или SUSE Linux Enterprise Server с помощью Azure NetApp Files для общих томов хранилища.

Хранилище

Эта архитектура использует управляемые диски Azure для хранения на виртуальных машинах или Azure NetApp Files. Рекомендации по развертыванию хранилища с управляемыми дисками подробно описаны в документе конфигураций хранилища виртуальных машин SAP HANA Azure. Кроме того, для управляемых дисков тома Azure NetApp Files NFS можно использовать в качестве решения для хранения SAP HANA.

Чтобы обеспечить высокую пропускную способность ввода-вывода в секунду и пропускную способность дискового хранилища, распространенные методики оптимизации производительности тома хранилища также применяются к макету хранилища Azure. Например, объединение нескольких дисков вместе с LVM для создания полосатого тома диска повышает производительность ввода-вывода. Кэширование дисков Azure также играет важную роль в достижении требуемой производительности ввода-вывода.

Для дисков журналов SAP HANA, работающих на SSD azure Premium версии 1, используйте одну из следующих технологий в расположениях, где хранится /hana/log для рабочей среды:

Эти технологии необходимы для согласованного удовлетворения требуемой задержки хранения менее 1 мс.

Ssd Azure premium версии 2 предназначен для критически важных для производительности рабочих нагрузок, таких как SAP. Ускоритель записи не требуется, если /hana/log работает на SSD уровня "Премиум" версии 2. Сведения о преимуществах и текущих ограничениях решения для хранилища см. в статье "Развертывание SSD уровня "Премиум" версии 2.

Дополнительные сведения о требованиях к производительности SAP HANA см. в 1943937 sap Note 1943937 — средство проверки конфигурации оборудования.

  • Проектирование экономичного хранилища для непроизводственных систем. Для сред SAP HANA, которые не требуют максимальной производительности хранилища во всех ситуациях, можно использовать архитектуру хранилища, оптимизированную для затрат. Этот выбор оптимизации хранилища может применяться к мало используемым производственным системам или некоторым непроизводственных средам SAP HANA. Вариант хранилища, оптимизированный для затрат, использует сочетание дисков SSD уровня "Стандартный", а не "Премиум" или "Ультра", которые используются для рабочих сред. Он также объединяет /hana/data и /hana/log файловых систем на один набор дисков. Рекомендации и рекомендации доступны для большинства размеров виртуальных машин. Если вы используете Azure NetApp Files для SAP HANA, вы можете использовать уменьшенные объемы для достижения той же цели.

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

  • Группа томов приложений Azure NetApp Files. Для развертываний с файлами SAP HANA, содержащимися в томах NFS Azure NetApp Files, группы томов приложений позволяют развертывать все тома в соответствии с рекомендациями. Этот процесс также обеспечивает оптимальную производительность для базы данных SAP HANA. Подробные сведения о том, как продолжить этот процесс. Для этого требуется вмешательство вручную. Разрешите некоторое время для создания.

Высокая доступность

В приведенной выше архитектуре показано высокодоступное развертывание с SAP HANA, содержащегося на двух или нескольких виртуальных машинах. Используются следующие компоненты.

Подсистемы балансировки нагрузки.Azure Load Balancer используется для распространения трафика на виртуальные машины SAP HANA. При включении Azure Load Balancer в зональное развертывание SAP убедитесь, что выбран балансировщик нагрузки SKU уровня "Стандартный". Балансировщик SKU "Базовый" не поддерживает зональную избыточность. В этой архитектуре Load Balancer выступает в качестве виртуального IP-адреса для SAP HANA. Сетевой трафик отправляется на активную виртуальную машину, где выполняется экземпляр базы данных-источник. Архитектура SAP HANA с поддержкой активного и чтения доступна (SLES/RHEL), где второй виртуальный IP-адрес, адресованный подсистеме балансировки нагрузки, используется для перенаправления сетевого трафика к вторичному экземпляру SAP HANA на другой виртуальной машине для рабочих нагрузок с интенсивным чтением.

По умолчанию Load Balancer (цен. категория предоставляет уровень безопасности. Виртуальные машины, которые находятся за Load Balancer (цен. категория , не имеют исходящего подключения к Интернету. Чтобы включить исходящий интернет в этих виртуальных машинах, необходимо обновить конфигурацию Load Balancer (цен. категория . Кроме того, вы также можете использовать шлюз NAT Azure для получения исходящего подключения.

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

Параметры развертывания. В Azure развертывание рабочей нагрузки SAP может быть региональным или зональным в зависимости от требований к доступности и устойчивости приложений SAP. Azure предоставляет различные варианты развертывания, такие как Масштабируемые наборы виртуальных машин с гибкой оркестрацией (FD=1), зонами доступности и группами доступности, чтобы повысить доступность ресурсов. Чтобы получить полное представление о доступных вариантах развертывания и их применимости в разных регионах Azure (включая между зонами, в пределах одной зоны или в регионе без зон), см . архитектуру и сценарии высокой доступности для SAP NetWeaver.

SAP HANA. Для обеспечения высокой доступности SAP HANA выполняется на двух или более виртуальных машинах Linux. Репликация системы SAP HANA (HSR) используется для реплика обработки данных между основными и вторичными (реплика) системами SAP HANA. HSR также используется для аварийного восстановления между регионами или между зонами. В зависимости от задержки в обмене данными между виртуальными машинами синхронное реплика tion можно использовать в пределах региона. HSR между регионами для аварийного восстановления в большинстве случаев выполняется асинхронно.

Для кластера Linux Pacemaker необходимо решить, какой механизм ограждения кластера следует использовать. Ограждение кластера — это процесс изоляции неудающейся виртуальной машины из кластера и ее перезапуска. Для RedHat Enterprise Linux (RHEL) единственный поддерживаемый механизм ограждения Pacemaker в Azure — агент забора Azure. Для SUSE Linux Enterprise Server (SLES) можно использовать агент забора Azure или устройство STONITH Block (SBD). Сравните время отработки отказа для каждого решения и, если существует разница, выберите решение на основе бизнес-требований для цели времени восстановления (RTO).

Агент забора Azure. Этот метод ограждения зависит от API Azure ARM, при этом Pacemaker запрашивает API ARM о состоянии виртуальных машин SAP HANA в кластере. Если сбой одной виртуальной машины, например ос без ответа или сбоя виртуальной машины, диспетчер кластеров снова использует API ARM для перезапуска виртуальной машины и при необходимости завершается сбоем базы данных SAP HANA на другой активный узел. Для этого субъект имени службы (SPN) с настраиваемой ролью для запроса и перезапуска виртуальных машин используется для авторизации в API ARM. Для использования агента забора Azure не требуется другая инфраструктура, виртуальные машины SBD в документах архитектуры не развертываются.

SBD. Устройство блочного устройства STONITH (SBD) использует диск, доступ к которому осуществляется как блочное устройство (необработанное без файловой системы) диспетчером кластеров. Этот диск или диски, если несколько, выступает в качестве голосования. Каждый из двух узлов кластера, на которых выполняется SAP HANA, обращается к дискам SDB и периодически считывает и записывает в них небольшие биты сведений о состоянии. Таким образом, каждый узел кластера знает состояние о другом без зависимости от сети между виртуальными машинами.

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

Вместо этого можно использовать общий диск Azure с помощью виртуальных машин SBD. Затем узлы кластера SAP HANA получают доступ к одному общему диску. Общий диск может быть локальным (LRS) или зонально (ZRS), если ZRS доступен в вашем регионе Azure.

Аварийное восстановление

В следующей архитектуре показана рабочая среда HANA в Azure, которая обеспечивает аварийное восстановление. Архитектура включает зоны доступности.

Схема, показывающая архитектуру с аварийным восстановлением.

Сведения о стратегиях аварийного восстановления и реализации см . в обзоре и рекомендациях по инфраструктуре аварийного восстановления для рабочих нагрузок SAP и рекомендаций по аварийному восстановлению для приложения SAP.

Примечание.

Если существует региональная катастрофа, которая вызывает большое событие отработки отказа для многих клиентов Azure в одном регионе, емкость ресурсов целевого региона не гарантируется. Как и все службы Azure, Azure Site Recovery продолжает добавлять функции и возможности. Последние сведения о реплика azure в Azure см. в матрице поддержки.

Помимо локальной реализации высокой доступности двух узлов HSR поддерживает многоуровневую и многотарьную реплика tion. Поэтому HSR поддерживает межзоны и межрегиональная реплика. Для SAP HANA 2.0 SPS 03 и более поздних версий доступно многотарное реплика tion.

Обязательно проверьте емкость ресурсов целевого региона.

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

Резервное копирование

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

Для резервного копирования на уровне файлов SAP HANA можно использовать выбранное средство, например hdbsql или SAP HANA Studio, и хранить файлы резервной копии на локальном томе диска. Общая точка подключения для этого тома резервного копирования — /hana/backup. Политики резервного копирования определяют период хранения данных на томе. После создания резервной копии запланированная задача должна скопировать файлы резервных копий в хранилище BLOB-объектов Azure для безопасного хранения. Локальные файлы резервного копирования хранятся для целесообразного восстановления.

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

Azure NetApp Files обеспечивает поддержку резервных копий на основе моментальных снимков. Интеграция с SAP HANA для согласованных моментальных снимков приложений осуществляется с помощью средства приложение Azure согласованного моментального снимка (AzAcSnap). Созданные моментальные снимки можно использовать для восстановления нового тома для восстановления системы или копирования базы данных SAP HANA. Созданные моментальные снимки можно использовать для аварийного восстановления, где он выступает в качестве точки восстановления с журналами SAP HANA, сохраненными в другом томе NFS.

Наблюдение

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

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

Безопасность

Многие меры безопасности используются для защиты конфиденциальности, целостности и доступности ландшафта SAP. Например, для защиты доступа пользователей SAP имеет собственный модуль управления пользователями (UME) для управления доступом на основе ролей и авторизацией в приложении SAP и базах данных. Дополнительные сведения см. в разделе "Безопасность SAP HANA" — обзор.

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

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

  • Для шифрования дисков виртуальных машин можно использовать функциональные возможности, описанные в обзоре шифрования дисков.

  • Серверы базы данных SAP: используйте прозрачное шифрование данных, предлагаемые поставщиком СУБД (например, технологией собственного шифрования SAP HANA), чтобы защитить файлы данных и журналов и обеспечить шифрование резервных копий.

  • Данные в физическом хранилище Azure (шифрование на стороне сервера) автоматически шифруются с помощью управляемого ключа Azure. Вы также можете выбрать управляемый клиентом ключ (CMK) вместо управляемого ключа Azure.

  • Сведения о поддержке Шифрование дисков Azure в определенных дистрибутивах, версиях и образах Linux см. в Шифрование дисков Azure для виртуальных машин Linux.

Примечание.

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

Для безопасности сети используйте группы безопасности сети (NSG) и Брандмауэр Azure или виртуальную сетевую (модуль) следующим образом:

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

  • Используйте Брандмауэр Azure или виртуальную (модуль) сети Azure для проверки и управления маршрутизацией трафика из центральной виртуальной сети в периферийную виртуальную сеть, где находятся приложения SAP, а также для управления исходящим подключением к Интернету.

Для пользователей и авторизации реализуйте управление доступом на основе ролей (RBAC) и блокировки ресурсов следующим образом:

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

  • Используйте блокировки ресурсов, чтобы предотвратить случайные или вредоносные изменения. Блокировки ресурсов помогают предотвратить удаление или изменение критически важных ресурсов Azure, где находится решение SAP.

Дополнительные рекомендации по безопасности см. в статьях Майкрософт и SAP .

Сообщества

Участники сообществ отвечают на вопросы и помогают настроить успешное развертывание. Рассмотрим следующие общины:

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Автор субъекта:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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

Дополнительные сведения о технологиях компонентов:

Сведения о связанных архитектурах: