Vue d’ensemble de la plateforme SAP BusinessObjects BI sur Azure

La plateforme SAP BusinessObjects BI (BOBI) est une plateforme décisionnel pour la création de rapports, l’analytique et la visualisation des données. Lorsque vous déployez la plateforme SAP BOBI sur Azure, vous pouvez utiliser des services de calcul, de stockage managé et de base de données évolutifs pour simplifier le déploiement et réduire la surcharge opérationnelle.

Cet article vous aide à planifier, déployer et configurer la plateforme SAP BOBI sur Azure en couvrant les scénarios de déploiement courants et les services Azure qui les prennent en charge.

Considérations relatives à l’architecture et au déploiement

Microsoft Azure offre un large éventail de services, notamment le calcul, le stockage et la mise en réseau, afin de pouvoir créer des applications sans longs cycles d’approvisionnement. Les machines virtuelles Azure vous aident à déployer des ressources informatiques à la demande et évolutives pour différentes applications SAP. Ces applications incluent des applications BASÉEs sur SAP NetWeaver, SAP Hybris et sap BusinessObjects BI, basées sur vos besoins métier. Azure prend également en charge la connectivité intersite, ce qui vous permet d’intégrer des machines virtuelles Azure dans vos domaines locaux, clouds privés et paysage du système SAP.

Cette section fournit des conseils sur la planification et l’implémentation des considérations relatives à la plateforme SAP BusinessObjects BI sur Azure. Il vient compléter la documentation d'installation SAP et les Notes SAP, qui constituent les principales ressources à consulter pour les installations et les déploiements de SAP BOBI.

Présentation de l'architecture

La plateforme SAP BusinessObjects BI peut s’exécuter sur une seule machine virtuelle Azure ou effectuer une mise à l’échelle dans un cluster à plusieurs machines virtuelles avec des composants distribués. La plateforme SAP BOBI se compose de six niveaux conceptuels. Pour plus d’informations sur chaque niveau, consultez le Guide de la plateforme Business Intelligence SAP BusinessObjects. La liste suivante fournit des détails généraux sur chaque niveau :

• Niveau client : Contient toutes les applications clientes de bureau qui interagissent avec la plateforme BI pour fournir différents types de rapports, d’analytique et d’administration.
• Niveau web : Contient des applications web déployées sur des serveurs d’applications web Java. Les applications web fournissent des fonctionnalités de plateforme BI aux utilisateurs via un navigateur web.
• Niveau de gestion : Coordonne et contrôle tous les composants qui composent la plateforme BI. Il inclut le serveur de gestion centralisée (CMS) et le serveur d’événements et les services associés.
• Niveau de stockage : Gère les fichiers, tels que les documents et les rapports. Il gère également la mise en cache des rapports pour enregistrer les ressources système lorsque les utilisateurs accèdent aux rapports.
• Niveau de traitement : Analyse les données et produit des rapports et d’autres types de sortie. Cette couche est la seule qui accède aux bases de données contenant les données des rapports.
• Niveau données : Se compose des serveurs de base de données hébergeant les bases de données système CMS et le magasin de données d’audit.

La plateforme SAP BI se compose d’une collection de serveurs s’exécutant sur un ou plusieurs hôtes. Il est essentiel de choisir la stratégie de déploiement appropriée en fonction du dimensionnement, des besoins métier et du type d’environnement. Pour les petites installations, telles que le développement ou le test, vous pouvez utiliser une seule machine virtuelle Azure pour le serveur d’applications web, le serveur de base de données et tous les serveurs de plateforme BI. Si vous utilisez une offre Database-as-a-Service (DBaaS) à partir d’Azure, le serveur de base de données s’exécute séparément d’autres composants. Pour les installations moyennes et volumineuses, vous pouvez avoir des serveurs s’exécutant sur plusieurs machines virtuelles Azure.

Le diagramme suivant illustre l’architecture d’un déploiement à grande échelle de la plateforme SAP BOBI sur des machines virtuelles Azure, avec chaque composant distribué. Pour garantir la résilience de l’infrastructure contre les interruptions de service, vous pouvez déployer des machines virtuelles à l’aide de groupes identiques flexibles, de groupes à haute disponibilité ou de zones de disponibilité.

Détails de l'architecture

• Équilibreur de charge

  Dans le déploiement à plusieurs instances DE SAP BOBI, les serveurs d’applications web (ou la couche web) s’exécutent sur deux hôtes ou plus. Pour répartir uniformément la charge utilisateur entre les serveurs web, vous pouvez utiliser un équilibreur de charge entre les utilisateurs et les serveurs web. Dans Azure, vous pouvez utiliser Azure Load Balancer ou Azure Application Gateway pour gérer le trafic vers vos serveurs web.

• Serveurs d’applications web

  Le serveur web héberge les applications web de la plateforme SAP BOBI, telles que la console de gestion centralisée (CMC) et le panneau de lancement BI. Pour obtenir une haute disponibilité pour le serveur web, vous devez déployer au moins deux serveurs d’applications web pour gérer la redondance et l’équilibrage de charge. Dans Azure, ces serveurs d’applications web peuvent être placés dans un ensemble de mise à l'échelle flexible, des zones de disponibilité ou des groupes de disponibilité pour une meilleure disponibilité.

  Tomcat est l’application web par défaut pour la plateforme SAP BI. Pour obtenir une haute disponibilité pour Tomcat, activez la réplication de session à l’aide de l’intercepteur d’appartenance statique dans Azure. Cette configuration garantit qu’un utilisateur peut accéder à l’application web SAP BI même lorsque le service Tomcat est interrompu.

  Important

  Par défaut, Tomcat repose sur une adresse IP et un port de multidiffusion pour le clustering, ce qui n’est pas pris en charge sur Azure (note SAP 2764907).

• Serveurs de plateforme BI

  Les serveurs de plateforme BI incluent tous les services qui font partie de l’application SAP BOBI (niveau de gestion, niveau de traitement et niveau de stockage). Lorsqu’un serveur web reçoit une demande, il détecte chaque serveur de plateforme BI (en particulier, tous les serveurs CMS d’un cluster) et équilibre automatiquement la charge des demandes. Si l’un des hôtes de plateforme BI échoue, le serveur web envoie automatiquement des requêtes à un autre hôte.

  Pour obtenir une haute disponibilité ou une redondance pour la plateforme BI, vous devez déployer l’application dans au moins deux machines virtuelles Azure. En fonction du dimensionnement, vous pouvez mettre à l’échelle votre plateforme BI pour qu’elle s’exécute sur d’autres machines virtuelles Azure.

• Serveur de référentiel de fichiers (FRS)

  Le serveur de référentiels de fichiers contient tous les rapports et autres documents BI créés. Dans le déploiement à plusieurs instances, les serveurs de la plate-forme BI s’exécutent sur plusieurs machines virtuelles, et chaque machine virtuelle doit avoir accès à ces rapports et à d’autres documents BI. Un système de fichiers doit être partagé sur tous les serveurs de plateforme BI.

  Dans Azure, vous pouvez utiliser Azure Premium Files ou Azure NetApp Files pour le serveur de référentiel de fichiers. Ces deux services Azure proposent une fonctionnalité de redondance intégrée.

• Cms et base de données d’audit

  La plateforme SAP BOBI nécessite une base de données pour stocker ses données système, appelées base de données CMS. Il stocke les informations de plateforme BI telles que les informations d’utilisateur, de serveur, de dossier, de document, de configuration et d’authentification.

  Azure offre Azure Database pour MySQL et Azure SQL Database en tant qu’offres DBaaS pour la base de données CMS et la base de données Audit. En tant qu’offres DBaaS, vous n’avez pas à vous soucier des opérations, de la disponibilité et de la maintenance des bases de données. Vous pouvez également choisir votre propre base de données pour le référentiel CMS et Audit en fonction des besoins de votre entreprise.

Matrice de prise en charge

Cette section décrit la prise en charge de différents composants SAP BOBI, notamment les versions de la plateforme SAP BusinessObjects BI, les systèmes d’exploitation et les bases de données dans Azure.

Plateforme SAP BusinessObjects BI

Azure Infrastructure as a Service (IaaS) vous permet de déployer et de configurer la plateforme SAP BusinessObjects BI sur Azure Compute. Il prend en charge les versions suivantes de la plateforme SAP BOBI :

• SAP BusinessObjects BI Platform 4.3
• SAP BusinessObjects BI Platform 4.2 SP04+
• SAP BusinessObjects BI Platform 4.1 SP05+

La plateforme SAP BI s’exécute sur différents systèmes d’exploitation et bases de données. Pour plus d’informations sur les combinaisons prises en charge de la plateforme SAP BOBI, du système d’exploitation et des versions de base de données, consultez la matrice de disponibilité des produits pour SAP BOBI.

Système d’exploitation

Azure prend en charge les systèmes d’exploitation suivants pour le déploiement de la plateforme SAP BusinessObjects BI :

• Microsoft Windows Server
• SLES (SUSE Linux Enterprise Server)
• Red Hat Enterprise Linux (RHEL)
• Oracle Linux (OL)

Les versions du système d’exploitation répertoriées dans la matrice de disponibilité des produits (PAM) pour SAP BusinessObjects BI Platform sont prises en charge tant qu’elles sont compatibles pour s’exécuter sur l’infrastructure Azure.

Bases de données

La plateforme BI dépend d’une base de données pour le stockage de données CMS et d’audit. Les options de base de données prises en charge sont définies dans la matrice de disponibilité des produits SAP. Les bases de données prises en charge sont les suivantes :

• Microsoft SQL Server

• Azure SQL Database (pris en charge uniquement pour la plateforme SAP BOBI sur Windows)

  Azure SQL Database est un moteur de base de données SQL Server entièrement managé, basé sur la dernière édition Enterprise Stable de SQL Server. Azure SQL Database gère la plupart des fonctions de gestion de base de données telles que la mise à niveau, la mise à jour corrective et la surveillance sans intervention de l’utilisateur. Avec Azure SQL Database, vous pouvez créer une couche de stockage de données hautement disponible et très performante pour les applications et les solutions dans Azure. Pour plus d’informations, consultez la documentation Azure SQL Database .

• Azure Database pour MySQL (suivez les mêmes instructions de compatibilité que celles mentionnées pour MySQL AB dans SAP PAM)

  Azure Database pour MySQL est un service de base de données relationnelle alimenté par MySQL Community Edition. En tant qu’offre DBaaS (Database-as-a-Service) entièrement managée, elle peut gérer des charges de travail stratégiques avec des performances prévisibles et une scalabilité dynamique. Il intègre nativement la haute disponibilité, les sauvegardes automatiques, les correctifs logiciels, la détection automatique des défaillances et la restauration à un point dans le temps jusqu'à 35 jours, ce qui réduit considérablement les tâches opérationnelles. Pour plus d’informations, consultez la documentation Azure Database pour MySQL .

• SAP HANA

• SAP ASE

• IBM DB2

• Oracle (pour plus d'informations sur les versions et restrictions, consultez la Note SAP 2039619)

• MaxDB

Cet article décrit les instructions pour déployer la plateforme SAP BOBI sur Windows avec Azure SQL Database et la plateforme SAP BOBI sur Linux avec Azure Database pour MySQL. Il s’agit également de l’approche recommandée pour l’exécution de la plateforme SAP BusinessObjects BI sur Azure.

Dimensionnement

Le dimensionnement est le processus de détermination de la configuration matérielle requise pour exécuter l’application efficacement. Pour la plateforme SAP BOBI, utilisez l’outil de dimensionnement SAP appelé Quick Sizer. L’outil fournit SAPS en fonction de l’entrée, que vous mappez ensuite aux types de machines virtuelles Azure certifiés pour SAP. La Note SAP 1928533 fournit la liste des produits SAP et des types de machines virtuelles Azure (avec les SAPS) pris en charge. Pour plus d’informations sur le dimensionnement, consultez le Guide de dimensionnement SAP BI.

Pour les besoins de stockage de la plateforme SAP BOBI, Azure offre différents types de disques managés. Pour le répertoire d’installation DE SAP BOBI, utilisez un disque managé Premium. Pour la base de données qui s’exécute sur des machines virtuelles, suivez les instructions du déploiement SGBD pour la charge de travail SAP.

Azure prend en charge deux offres DBaaS pour le niveau de données de la plateforme SAP BOBI : Azure SQL Database (application BI s’exécutant sur Windows) et Azure Database pour MySQL (application BI s’exécutant sur Linux et Windows). En fonction du résultat de dimensionnement, vous pouvez choisir le modèle d’achat qui correspond le mieux à vos besoins.

Conseil

Pour une référence de dimensionnement rapide, notez que 800 SAPS sont équivalents à 1 vCPU lors du mappage du résultat en SAPS de la couche de base de données de SAP BOBI Platform avec Azure Database-as-a-Service (Azure SQL Database ou Azure Database pour MySQL).

Dimensionnement des modèles pour Azure SQL Database

Azure SQL Database propose les trois modèles d'achat suivants :

• basé sur vCore

  Le modèle vCore vous permet de choisir le nombre de vCores, la quantité de mémoire et la quantité et la vitesse de stockage. Le modèle d’achat vCore vous permet également d’utiliser Azure Hybrid Benefit pour SQL Server pour réaliser des économies. Ce modèle est adapté pour vous si vous appréciez la flexibilité, le contrôle et la transparence.

  Trois options de niveau de service sont proposées dans le modèle vCore : Usage général, Critique pour l’entreprise et Hyperscale. Le niveau de service définit l'architecture de stockage, l'espace, les limites d'E/S et les options de continuité d'activité liées à la disponibilité et à la récupération d'urgence. La liste suivante fournit des détails généraux sur chaque option de niveau de service :

  • Le niveau de service Usage général convient le mieux aux charges de travail métier. Il propose des options de calcul et de stockage équilibrées, évolutives et économiques. Pour plus d’informations, consultez Options et limites des ressources.
  • Le niveau de service Critique pour l'entreprise offre aux applications métier la meilleure résilience aux défaillances, en utilisant plusieurs réplicas isolés, ainsi que les meilleures performances d'E/S par réplica de base de données. Pour plus d’informations, consultez Options et limites des ressources.
  • Le niveau de service Hyperscale convient aux charges de travail métier dont les besoins en termes de stockage et d'échelle lecture sont très évolutifs. Il offre une meilleure résilience aux défaillances en permettant la configuration de plusieurs réplicas de base de données isolés. Pour plus d’informations, consultez Options et limites des ressources.

• Basé sur DTU

  Le modèle d'achat DTU offre une combinaison de ressources de calcul, de mémoire et d'E/S réparties sur trois niveaux de service pour prendre en charge les charges de travail de base de données, aussi bien légères qu'importantes. Les tailles de calcul au sein de chaque niveau fournissent une combinaison différente de ces ressources, auquel vous pouvez ajouter d’autres ressources de stockage. Ce modèle est mieux adapté si vous souhaitez des options de ressources simples et préconfigurées.

  Les niveaux de service DTU diffèrent par taille de calcul avec une allocation de ressources fixe pour :

  • Stockage inclus
  • Période de rétention des sauvegardes
  • Tarification

• Sans serveur

  Le modèle serverless met automatiquement à l’échelle le calcul en fonction de la demande de charge de travail et facture la quantité de calcul utilisée par seconde. Le niveau de calcul serverless met automatiquement en pause les bases de données pendant les périodes d'inactivité, lorsque seul le stockage est facturé, et relance automatiquement leur exécution lorsque l'activité reprend. Pour plus d’informations, consultez Options et limites des ressources.

  Le modèle serverless est plus adapté à une utilisation intermittente et imprévisible avec une faible utilisation moyenne du calcul au fil du temps. Vous pouvez utiliser ce modèle pour le déploiement SAP BOBI hors production.

Remarque

Pour SAP BOBI, il est pratique d’utiliser le modèle vCore et de choisir le niveau de service Usage général ou Critique pour l’entreprise en fonction des besoins de l’entreprise.

Dimensionnement des modèles pour Azure Database pour MySQL

Azure Database pour MySQL est fourni avec trois niveaux tarifaires différents. Ils diffèrent en fonction du nombre de vCores, de la quantité de mémoire par vCore et de la technologie de stockage utilisée pour le stockage des données. La liste suivante fournit des détails généraux sur les options. Pour plus d’informations sur différents attributs, consultez la documentation du niveau tarifaire pour Azure Database pour MySQL.

• De base : utilisé pour les charges de travail cibles nécessitant des performances de calcul et d’E/S légères.

• Usage général : adapté à la plupart des charges de travail métier qui nécessitent un calcul et une mémoire équilibrés avec un débit d’E/S évolutif.

• Mémoire optimisée : conçue pour les charges de travail de base de données hautes performances qui nécessitent des performances en mémoire pour un traitement transactionnel plus rapide et une concurrence plus élevée.

Remarque

Pour SAP BOBI, il est pratique d’utiliser le niveau tarifaire Usage général ou Mémoire optimisée en fonction de la charge de travail métier.

Ressources Azure

Sélection de la région

Une région Azure est une ou une collection de centres de données qui contient l’infrastructure permettant d’exécuter et d’héberger différents services Azure. Cette infrastructure comprend un grand nombre de nœuds qui fonctionnent en tant que nœuds de calcul ou nœuds de stockage, ou exécutent des fonctionnalités réseau. Toutes les régions ne proposent pas les mêmes services.

Certains composants de la plateforme SAP BI dépendent de types de machines virtuelles spécifiques, de services de stockage tels qu’Azure Files ou Azure NetApp Files ou DBaaS pour le niveau de données qui peuvent ne pas être disponibles dans certaines régions. Vous trouverez les informations exactes sur les types de machines virtuelles, les types stockage Azure ou d’autres services Azure sur les produits disponibles par site de région . Si vous exécutez déjà vos systèmes SAP sur Azure, votre région est identifiée. Dans ce cas, examinez d’abord que les services nécessaires sont disponibles dans ces régions pour décider de l’architecture de la plateforme SAP BI.

Ensembles de mise à l'échelle de machines virtuelles avec orchestration flexible

Les Virtual Machine Scale Sets à orchestration flexible permettent de regrouper logiquement des machines virtuelles gérées par la plateforme. Vous pouvez créer un Virtual Machine Scale Set dans une région donnée ou l’étendre sur plusieurs zones de disponibilité. Lorsque vous créez un jeu d'échelle flexible dans une région et que vous définissez platformFaultDomainCount sur une valeur supérieure à 1 (FD>1), Azure répartit les machines virtuelles du jeu d'échelle sur le nombre spécifié de domaines d'erreur dans cette région. Lorsque vous créez un ensemble échelonnable flexible à travers les zones de disponibilité avec platformFaultDomainCount=1 (FD=1), les machines virtuelles sont distribuées à travers les zones spécifiées. Le groupe d'échelles distribue également les machines virtuelles entre différents domaines de défaillance au sein de la zone sur la base du meilleur effort.

Pour les charges de travail SAP, seul un ensemble à dimensionnement flexible avec FD=1 est pris en charge. Par rapport aux déploiements traditionnels de zone de disponibilité, les groupes d'échelle flexibles avec FD=1 fournissent une meilleure distribution des pannes. Les machines virtuelles du Virtual Machine Scale Set sont réparties sur plusieurs domaines d’erreur dans chaque zone selon un principe de « meilleur effort ». Pour en savoir plus sur le déploiement de charges de travail SAP avec des groupes d'échelle flexibles, consultez le guide de déploiement de groupes d'échelle de machines virtuelles flexibles.

Zones de disponibilité

Les zones de disponibilité sont des emplacements physiquement distincts au sein d’une région Azure. Chaque zone de disponibilité se compose d’un ou plusieurs centres de données équipés d’une alimentation, d’un refroidissement et d’une mise en réseau indépendants.

Pour obtenir une haute disponibilité sur chaque niveau pour la plateforme SAP BI, vous pouvez distribuer des machines virtuelles entre des zones de disponibilité en implémentant une infrastructure de haute disponibilité, qui peut fournir le meilleur contrat SLA dans Azure. Pour le contrat SLA de machine virtuelle dans Azure, consultez la dernière version des contrats SLA de machine virtuelle.

Pour le niveau de données, Azure DBaaS fournit une infrastructure de haute disponibilité par défaut. Vous devez simplement sélectionner la région et les fonctionnalités inhérentes à la haute disponibilité, à la redondance et à la résilience du service réduisent les temps d’arrêt de la base de données à partir de pannes planifiées et non planifiées, sans avoir à configurer de composants supplémentaires. Pour plus d’informations sur le contrat SLA pour les offres DBaaS prises en charge sur Azure, consultez Haute disponibilité dans Azure Database pour MySQL. Consultez également la haute disponibilité pour Azure SQL Database.

Ensembles de disponibilité

Un groupe à haute disponibilité est une fonctionnalité de regroupement logique permettant d’isoler les ressources de machine virtuelle les unes des autres lors du déploiement. Azure garantit que les machines virtuelles que vous placez dans un groupe à haute disponibilité s’exécutent sur plusieurs serveurs physiques, racks de calcul, unités de stockage et commutateurs réseau. Si une défaillance matérielle ou logicielle se produit, seul un sous-ensemble de vos machines virtuelles est affecté et votre solution globale reste opérationnelle. Lorsque des machines virtuelles sont placées dans des groupes à haute disponibilité, Azure Fabric Controller distribue les machines virtuelles sur différents domaines d’erreur et de mise à niveau pour empêcher toutes les machines virtuelles d’être inaccessibles en raison de la maintenance ou de l’échec de l’infrastructure au sein d’un domaine d’erreur.

La plateforme SAP BI contient de nombreux composants différents. Lorsque vous concevez l’architecture, assurez-vous que chaque composant est résilient à l’interruption. Vous pouvez atteindre la résilience en plaçant des machines virtuelles Azure de chaque composant dans des groupes à haute disponibilité. Le mélange de familles de machines virtuelles dans le même groupe à haute disponibilité peut entraîner des problèmes de compatibilité qui empêchent l’ajout de certains types de machines virtuelles. Utilisez des groupes à haute disponibilité distincts pour l’application web et l’application BI pour la plateforme SAP BI, comme indiqué dans la vue d’ensemble de l’architecture.

Le nombre de domaines de mise à jour et de défaillance disponibles pour un ensemble de disponibilité Azure au sein d'une unité de mise à l'échelle Azure est fini. Si vous continuez à ajouter des machines virtuelles à un seul groupe à haute disponibilité, deux machines virtuelles ou plus finissent par se retrouver dans le même domaine d’erreur ou de mise à jour. Pour plus d’informations, consultez la section Ensembles de disponibilité Azure de la planification et de l’implémentation des machines virtuelles Azure pour le document SAP.

Pour obtenir une vue d’ensemble des groupes à haute disponibilité Azure et leur relation avec les domaines d’erreur et de mise à jour, consultez l’article Gérer la disponibilité .

Important

• Les concepts de zones de disponibilité Azure et de groupes à haute disponibilité Azure s’excluent mutuellement. Vous pouvez déployer deux machines virtuelles ou plus dans une zone de disponibilité ou dans un groupe à haute disponibilité, mais pas dans les deux à la fois.

• Si vous envisagez un déploiement sur plusieurs zones de disponibilité, privilégiez un Virtual Machine Scale Set flexible avec FD=1 plutôt qu’un déploiement standard par zone.

Machines virtuelles

La machine virtuelle Azure est une offre de service qui vous permet de déployer des images personnalisées sur Azure en tant qu’instances IaaS. Elle réduit la complexité de la maintenance et des opérations des applications via le calcul et le stockage à la demande pour :

• Hébergement
• Croissance
• Gestion des applications web
• Gestion des applications connectées

Azure propose différentes machines virtuelles pour tous vos besoins en application. Toutefois, pour les charges de travail SAP, Azure a réduit la sélection à différentes familles de machines virtuelles qui conviennent spécifiquement aux charges de travail SAP et aux charges de travail SAP HANA. Pour plus d’informations, consultez Les logiciels SAP pris en charge pour les déploiements Azure.

En fonction du dimensionnement de la plateforme SAP BI, mappez vos besoins à une machine virtuelle Azure prise en charge dans Azure pour les produits SAP. La note SAP 1928533 est un bon point de départ qui répertorie les types de machines virtuelles Azure pris en charge pour les produits SAP sur Windows et Linux. N’oubliez pas que, au-delà de la sélection des types de machines virtuelles pris en charge, vous devez également vérifier si ces types de machines virtuelles sont disponibles dans une région spécifique. Vous pouvez vérifier la disponibilité des types de machines virtuelles sur la page Produits disponibles par région . Pour choisir le modèle de tarification, consultez machines virtuelles Azure pour la charge de travail SAP.

Stockage

Stockage Azure est un service cloud géré par Azure qui fournit un stockage hautement disponible, sécurisé, durable, évolutif et redondant. Certains types de stockage offrent une prise en charge limitée des charges de travail SAP. Toutefois, plusieurs types de stockage Azure sont bien adaptés ou optimisés pour des scénarios de charge de travail SAP spécifiques. Pour plus d’informations, consultez le guide des types de stockage Azure pour la charge de travail SAP , car il met en évidence différentes options de stockage adaptées à SAP.

Stockage Azure dispose de différents types de stockage disponibles. Pour plus d’informations, consultez l’article Quels types de disques sont disponibles dans Azure ? La plateforme SAP BOBI utilise le stockage Azure suivant pour générer l’application :

• Disques gérés Azure

  Un disque managé est un volume de stockage au niveau du bloc géré par Azure. Vous pouvez utiliser les disques pour les serveurs d’applications et les bases de données de la plateforme SAP BOBI lorsqu’ils sont installés sur des machines virtuelles Azure. Il existe différents types de disques managés Azure disponibles, mais les disques SSD Premium sont recommandés pour l’application et la base de données de la plateforme SAP BOBI.

  Dans l’exemple suivant, les disques SSD Premium sont utilisés pour le répertoire d’installation de la plateforme BOBI. Pour une base de données installée sur une machine virtuelle, vous pouvez utiliser des disques managés pour les volumes de données et de journaux conformément aux instructions. Les bases de données CMS et Audit sont généralement petites et n’ont pas les mêmes exigences de performances de stockage que les autres bases de données SAP OLTP/OLAP.

• Azure Premium Files ou Azure NetApp Files

  Dans la plateforme SAP BOBI, le serveur de référentiels de fichiers (FRS) fait référence aux répertoires de disque où le contenu, tel que les rapports, les univers et les connexions, est stocké. Ce contenu est utilisé par tous les serveurs d’applications de ce système. Le stockage Azure Premium Files ou Azure NetApp Files peut être utilisé comme système de fichiers partagé pour l’application SAP BOBI FRS. Étant donné que ces offres de stockage ne sont pas disponibles dans toutes les régions, consultez le site Produits disponibles par région pour des informations à jour.

  Si le service n’est pas disponible dans votre région, vous pouvez créer un serveur NFS à partir duquel vous pouvez partager le système de fichiers vers l’application SAP BOBI. Toutefois, vous devez également prendre en compte sa haute disponibilité.

Mise en réseau

SAP BOBI est une plateforme bi de création de rapports et d’analytique qui ne contient aucune donnée métier. Le système est connecté à d’autres serveurs de base de données où il récupère toutes les données et fournit des insights aux utilisateurs. Azure fournit une infrastructure réseau qui prend en charge tous les scénarios de la plateforme SAP BI. Scénarios tels que la connexion à des systèmes locaux, des systèmes dans différents réseaux virtuels, etc. Pour plus d’informations, consultez Mise en réseau Microsoft Azure pour la charge de travail SAP.

Pour les offres Database-as-a-Service, toute base de données nouvellement créée (Azure SQL Database ou Azure Database pour MySQL) dispose d’un pare-feu qui bloque toutes les connexions externes. Pour autoriser l’accès au service DBaaS à partir de machines virtuelles de la plateforme BI, spécifiez une ou plusieurs règles de pare-feu au niveau du serveur pour permettre l’accès à votre serveur DBaaS. Pour plus d’informations, consultez Les règles de pare-feu pour Azure Database pour MySQL et la section contrôles d’accès réseau pour Azure SQL Database.

Contenu connexe

• Déploiement de la plateforme SAP BusinessObjects BI sur Linux
• Planification et implémentation des machines virtuelles Azure pour SAP
• Déploiement de machines virtuelles Azure pour SAP
• Déploiement du SGBD sur les VMs Azure pour SAP