Guide de planification IBM Db2 pour SAP

Ce guide fournit des informations que vous pouvez utiliser pour planifier l'installation d'un système IBM Db2 AESE (Advanced Enterprise Server Edition) compatible avec les applications SAP sur Google Cloud.

Pour déployer IBM Db2 avec des produits SAP sur Google Cloud, consultez les pages suivantes :

Pour obtenir des liens procurant plus d'informations SAP sur IBM Db2, consultez la documentation de SAP sur IBM Db2 pour Linux, UNIX et Windows.

Pour en savoir plus sur les produits certifiés par SAP pour des exécutions sur Google Cloud, y compris IBM Db2, consultez la note SAP 2456432 - Applications SAP sur Google Cloud : produits et types de machines Google Cloud compatibles..

Principes de base de Google Cloud

Google Cloud comprend de nombreux services et produits basés sur le cloud. Lorsque vous exécutez des produits SAP sur Google Cloud, vous utilisez principalement les services IaaS proposés par Compute Engine et Cloud Storage, ainsi que certaines fonctionnalités communes au niveau de la plate-forme, telles que les outils.

Consultez la page Présentation de Google Cloud Platform pour découvrir les principaux concepts et la terminologie. Ce guide reprend certaines informations de la présentation pour plus de facilité et de cohérence.

Pour une présentation des considérations que les entreprises doivent prendre en compte lors de l'exécution sur Google Cloud, consultez le framework d'architecture Google Cloud.

Interagir avec Google Cloud

Google Cloud propose trois méthodes principales pour interagir avec la plate-forme et vos ressources dans le cloud :

  • Google Cloud Console, qui est une interface utilisateur Web.
  • L'outil de ligne de commande gcloud, qui fournit un sur-ensemble des fonctionnalités offertes par la console Google Cloud.
  • Les bibliothèques clientes, qui fournissent des API pour accéder aux services et gérer les ressources. Ces bibliothèques sont utiles pour créer vos propres outils.

Services Google Cloud

Les déploiements SAP utilisent généralement certains des services Google Cloud suivants, voire la totalité :

Service Description
Mise en réseau VPC

Connectez vos instances de VM les unes aux autres et à Internet.

Chaque instance de VM est membre d'un ancien réseau avec une plage d'adresses IP globale unique ou d'un réseau de sous-réseaux recommandé, où l'instance de VM appartient à un seul sous-réseau membre d'un réseau plus grand.

Notez qu'un réseau cloud privé virtuel (VPC) ne peut pas s'étendre sur plusieurs projets Google Cloud, mais qu'un projet Google Cloud peut englober plusieurs réseaux VPC.

Pour connecter des ressources provenant de différents projets à un réseau VPC commun, vous pouvez utiliser un VPC partagé. Cela permet aux ressources de communiquer entre elles de manière sécurisée et efficace à l'aide d'adresses IP internes de ce réseau. Pour en savoir plus sur le provisionnement d'un VPC partagé, y compris sur les conditions requises, les étapes de configuration et l'utilisation, consultez la page Provisionner un VPC partagé.

Compute Engine Créez et gérez des VM avec le système d'exploitation et la pile logicielle de votre choix.
Persistent Disk et Hyperdisk

Vous pouvez utiliser Persistent Disk et Google Cloud Hyperdisk :

  • Les volumes Persistent Disk sont disponibles sous forme de disques durs standards (HDD) ou de disques durs SSD. Pour les disques persistants avec équilibrage et les disques persistants SSD, la réplication asynchrone des disques persistants fournit une réplication asynchrone des données SAP entre deux régions Google Cloud.
  • Les volumes Hyperdisk Extreme offrent des options d'IOPS et de débit maximales plus élevés que les volumes Persistent Disk SSD.
  • Par défaut, Compute Engine chiffre le contenu client au repos, y compris le contenu des volumes Persistent Disk et Hyperdisk. Pour en savoir plus sur le chiffrement des disques et les options de chiffrement possibles, consultez la page À propos du chiffrement des disques.
Google Cloud Console

Outil basé sur un navigateur pour gérer les ressources de Compute Engine.

Utilisez un modèle pour décrire toutes les ressources et instances de Compute Engine dont vous avez besoin. Il n'est pas nécessaire de créer et de configurer individuellement les ressources, ni de déterminer les dépendances : la console Google Cloud s'en charge pour vous.
Cloud Storage Vous pouvez stocker vos sauvegardes de base de données SAP dans Cloud Storage pour plus de durabilité et de fiabilité, grâce à la réplication.
Cloud Monitoring

Ce service offre une visibilité sur le déploiement, les performances, le temps d'activité et la santé de Compute Engine, du réseau et des disques de stockage persistant.

Monitoring collecte des métriques, des événements et des métadonnées à partir de Google Cloud, afin de générer des insights via des tableaux de bord, des graphiques et des alertes. Vous pouvez surveiller les métriques de calcul gratuitement grâce à Monitoring.
IAM

Ce service fournit un contrôle unifié des autorisations pour les ressources Google Cloud.

IAM vous permet de contrôler qui peut effectuer des opérations du plan de contrôle sur vos VM, y compris la création, la modification et la suppression de VM et de disques de stockage persistant, ainsi que la création et la modification de réseaux.

Tarifs et quotas

Vous pouvez utiliser le simulateur de coût pour estimer vos coûts d'utilisation. Pour en savoir plus sur la tarification, consultez les pages Tarifs de Compute Engine, Tarifs de Cloud Storage, et Tarifs de Google Cloud Observability.

Les ressources Google Cloud sont soumises à des quotas. Si vous envisagez d'utiliser des machines à haute capacité de processeur ou de mémoire, vous devrez peut-être demander un quota supplémentaire. Pour plus d'informations, consultez la section sur les quotas des ressources de Compute Engine.

Contrôles de conformité et de souveraineté

Si vous souhaitez que votre charge de travail SAP s'exécute conformément aux exigences liées à la résidence des données, au contrôle des accès, au personnel d'assistance ou à la réglementation, vous devez planifier l'utilisation d'Assured Workloads. Ce service vous aide à exécuter des charges de travail sécurisées et conformes sur Google Cloud, sans compromettre la qualité de votre expérience cloud. Pour en savoir plus, consultez la page Contrôles de conformité et de souveraineté pour SAP sur Google Cloud.

Architecture de déploiement

Une installation IBM Db2 avec une base de données à partition unique sur Google Cloud comprend les composants suivants :

  • Une VM Compute Engine exécutant votre base de données IBM Db2.

  • Un ou plusieurs disques persistants pour les éléments suivants :

    • Le disque racine.
    • Le volume d'ID de base de données (/db2/<DBSID>/).
    • Le volume d'instance (/db2/db2<dbsid>), qui contient le répertoire d'accueil de l'utilisateur db2<dbsid> et les données d'instance IBM Db2 pour <DBSID> ainsi que le logiciel IBM Db2.
    • Le volume de journal (/db2/<DBSID>/log_dir), qui contient au moins les fichiers journaux de la base de données en ligne.
    • Le volume de vidage/diagnostic (/db2/<DBSID>/db2dump), qui contient les fichiers journaux de diagnostic Db2, les fichiers de vidage Db2 et d'autres informations du technicien de maintenance.
    • Le volume de données (/db2/<DBSID>/sapdata<n> ou /db2/<DBSID>/sapdata/sapdata<n>). Il s'agit de l'emplacement de stockage des espaces de table dotés d'un fichier DMS, ou des espaces de table avec stockage automatique Db2.
    • Le volume des espaces de table temporaires (/db2/<DBSID>/saptmp<n> ou /db2/ <DBSID>/saptmp/saptmp<n>). Il s'agit de l'emplacement de stockage des espaces de table temporaires.

Selon les exigences de votre installation, vous devrez peut-être également inclure les éléments suivants :

  • Une passerelle NAT. Une passerelle NAT vous permet de fournir une connectivité Internet à vos VM tout en refusant la connectivité Internet directe à ces VM. Vous pouvez également configurer cette VM en tant qu'hôte bastion, afin de pouvoir établir des connexions SSH avec les autres VM de votre sous-réseau privé. Pour plus d'informations, consultez la section Passerelles NAT et hôtes bastions.
  • Un volume de sauvegarde pour stocker des sauvegardes de secours.
  • Un volume de stockage pour stocker les archives de journaux.

Des cas d'utilisation différents peuvent nécessiter des appareils ou des bases de données supplémentaires. Pour en savoir plus, consultez les pages suivantes :

Ressources nécessaires

À bien des égards, exécuter IBM Db2 avec SAP sur Google Cloud revient à l'exécuter dans votre propre centre de données. Vous devez là encore tenir compte des considérations relatives aux ressources informatiques, au stockage et au réseau.

Pour plus d'informations, consultez le guide d'installation approprié pour votre système SAP avec IBM Db2.

Configuration de la VM

IBM Db2 est certifié pour fonctionner sur tous les types de machines Compute Engine, y compris les types personnalisés. Dans la plupart des cas, utilisez un type de machine avec deux processeurs virtuels ou plus.

Pour plus d'informations sur les différents types de machines Compute Engine et leurs cas d'utilisation, consultez la section Types de machines dans la documentation Compute Engine.

Configuration du processeur

Le nombre de processeurs virtuels requis varie en fonction de la charge d'application sur IBM Db2 pour LUW. Vous devez allouer au moins deux processeurs virtuels à votre installation IBM Db2. Pour utiliser au mieux les ressources existantes de votre système IBM Db2, suivez les instructions de la documentation SAP sur IBM Db2 pour Linux, UNIX et Windows et ajustez vos ressources informatiques en fonction de vos besoins.

Configuration de la mémoire

Votre VM IBM Db2 doit disposer d’au moins 4 Go de mémoire RAM par processeur virtuel. De ces 4 Go, environ 80 % de votre mémoire RAM doivent être alloués à IBM Db2, le reste étant alloué au système d'exploitation sur lequel IBM Db2 est exécuté.

La quantité de mémoire optimale pour votre cas d'utilisation dépend de la complexité des requêtes que vous exécutez, de la taille de vos données, de la quantité de parallélisme que vous utilisez et du niveau de performance auquel vous vous attendez. Pour plus d'informations sur l'optimisation de votre configuration de mémoire, consultez la documentation de SAP sur IBM Db2 pour Linux, UNIX et Windows.

Configuration de l'espace de stockage

Par défaut, chaque VM Compute Engine possède un petit disque persistant racine contenant le système d'exploitation. De plus, vous devez créer, attacher, formater et monter des disques supplémentaires pour votre base de données, vos journaux et vos procédures stockées.

La taille des disques et les exigences de performances dépendront de votre application. Dimensionnez chaque appareil en fonction de vos besoins.

Pour plus d'informations sur les options de disque persistant pour IBM Db2, consultez la page Disques persistants.

Pour obtenir des conseils de SAP sur le dimensionnement du disque, consultez les pages :

Versions IBM Db2 compatibles

Vous devez utiliser les niveaux de groupe de correctifs logiciels IBM Db2 certifiés SAP. L'utilisation d'autres niveaux de logiciel IBM Db2 n'est pas autorisée.

Pour plus d'informations, consultez : Note SAP 101809 - DB6 : versions Db2 compatibles et niveaux de groupe de correctifs.

Fonctionnalités IBM Db2 compatibles

SAP est compatible avec la plupart des fonctionnalités IBM Db2 sur Google Cloud. Cependant, les fonctionnalités suivantes ne sont pas acceptées :

  • Bases de données Db2 à partitions multiples
  • Fonctionnalité pureScale IBM Db2

Systèmes d'exploitation compatibles

Google Cloud est certifié par SAP pour exécuter IBM Db2 sur les images de système d'exploitation SUSE Linux Enterprise Server (SLES), Red Hat Enterprise Linux (RHEL) et Windows Server suivantes :

  • SLES 12 SP2 et supérieur
  • RHEL 7.4
  • Windows Server 2012 R2 et supérieur

Pour plus d'informations sur les images Compute Engine, consultez la section Images.

Remarques relatives au déploiement

Régions et zones

Lorsque vous déployez une VM, vous devez choisir une région et une zone. Une région est un emplacement géographique spécifique où vous pouvez exécuter vos ressources et correspond à un emplacement de centre de données. Chaque région se compose d'une ou plusieurs zones.

Les ressources globales, telles que les images de disque préconfigurées et les instantanés de disque, sont accessibles dans toutes les régions et les zones. Les ressources régionales, telles que les adresses IP externes statiques, ne sont accessibles qu'aux ressources situées dans la même région. Les ressources zonales, telles que les VM et les disques, ne sont accessibles qu'aux ressources situées dans la même zone.

Régions et zones Google Cloud

Lorsque vous choisissez des régions et des zones pour vos VM, tenez compte des points suivants :

  • L'emplacement de vos utilisateurs et de vos ressources internes, tels que votre centre de données ou votre réseau d'entreprise. Pour réduire la latence, sélectionnez un emplacement situé à proximité de vos utilisateurs et de vos ressources.
  • L'emplacement de vos autres ressources SAP. Votre application SAP et votre base de données doivent être dans la même zone.

Disques persistants

Les disques persistants sont des périphériques de stockage de blocs durables qui fonctionnent de manière semblable aux disques physiques d'un poste de travail ou d'un serveur.

Compute Engine propose différents types de disques persistants. Chaque type présente des caractéristiques de performances différentes. Google Cloud gère le matériel sous-jacent des disques persistants pour garantir la redondance des données et optimiser les performances.

Vous pouvez utiliser l'un des types de disques persistants Compute Engine suivants :

  • Disques persistants standard (pd-standard) : stockage de blocs efficace et économique sauvegardé par des disques durs standards (HDD) pour gérer les opérations de lecture/écriture séquentielles, mais pas optimisé pour gérer des taux élevés d'opérations d'entrée/sortie aléatoires par seconde (IOPS).
  • SSD (pd-ssd) : fournit un stockage de blocs fiable, à hautes performances et sauvegardé par des disques durs SSD.
  • Équilibré (pd-balanced) : fournit un stockage de blocs économique et fiable basé sur SSD.
  • Extrême (pd-extreme) : basé sur SSD, offre des options d'IOPS et de débit maximales plus élevées que pd-ssd pour les types de machines Compute Engine plus volumineux. Pour en savoir plus, consultez la page Disques persistants extrêmes.

Les performances des disques persistants SSD et des disques persistants avec équilibrage évoluent automatiquement avec la taille. Vous pouvez ainsi ajuster les performances en redimensionnant vos disques persistants existants ou en ajoutant des disques persistants à une VM.

Le type de VM que vous utilisez et le nombre de processeurs virtuels qu'elle contient ont également une incidence sur les performances des disques persistants.

Les disques persistants sont hébergés indépendamment de vos VM. Vous pouvez donc dissocier ou déplacer des disques persistants pour conserver vos données, même après la suppression de vos VM.

Pour plus d'informations sur les différents types de disques persistants Compute Engine, leurs caractéristiques de performances et leur utilisation, consultez la documentation de Compute Engine :

Disque SSD local (non persistant)

Google Cloud propose également des disques SSD locaux. Bien que les disques SSD locaux puissent offrir certains avantages par rapport aux disques persistants, ne les utilisez pas dans le cadre d’un système IBM Db2. Les instances de VM avec des disques SSD locaux associés ne peuvent pas être arrêtées, puis redémarrées.

Passerelles NAT et hôtes bastion

Si votre stratégie de sécurité requiert des VM véritablement internes, vous devez configurer manuellement un proxy NAT sur votre réseau et un itinéraire correspondant afin que les VM puissent accéder à Internet. Il est important de noter que vous ne pouvez pas vous connecter directement à une instance de VM entièrement interne à l'aide de SSH. Pour ce faire, vous devez configurer une instance bastion dotée d'une adresse IP externe et vous en servir comme tunnel. Lorsque les VM n'ont pas d'adresses IP externes, elles ne peuvent être accessibles que par d'autres VM du réseau ou par le biais d'une passerelle VPN gérée. Vous pouvez provisionner des VM sur votre réseau pour qu'elles agissent en tant que relais de confiance pour les connexions entrantes, appelées hôtes bastions, ou sortie réseau, appelées passerelles NAT. Pour une connectivité plus transparente sans configurer de telles connexions, vous pouvez utiliser une ressource de passerelle VPN gérée.

Utiliser des hôtes bastion pour les connexions entrantes

Les hôtes bastion constituent un point d'entrée externe dans un réseau contenant des VM de réseau privé. Cet hôte peut fournir un seul point de renforcement ou d'audit et peut être démarré et arrêté pour activer ou désactiver la communication SSH entrante à partir d'Internet.

Hôte bastion indiqué dans le scénario SSH

Vous pouvez obtenir un accès SSH aux VM n'ayant pas d'adresse IP externe en vous connectant d'abord à un hôte bastion. Le renforcement complet d'un hôte bastion n'entre pas dans le cadre de cet article, mais vous pouvez suivre certaines étapes initiales, y compris :

  • Limiter la plage CIDR d'adresses IP sources pouvant communiquer avec le bastion
  • Configurer des règles de pare-feu qui autorisent le trafic SSH vers des VM privées provenant uniquement de l'hôte bastion

Par défaut, SSH sur les VM est configuré pour utiliser des clés privées pour l'authentification. Lorsque vous utilisez un hôte bastion, vous devez d'abord vous connecter à l'hôte bastion, puis à votre VM privée cible. En raison de cette connexion en deux étapes, nous vous recommandons d'utiliser le transfert d'agent SSH pour atteindre la VM cible au lieu de stocker la clé privée de la VM cible sur l'hôte bastion. Vous devez procéder ainsi même si vous utilisez la même paire de clés pour les VM cibles et le bastion, car le bastion a un accès direct uniquement à la moitié publique de la paire de clés.

Utiliser des passerelles NAT pour le trafic sortant

Lorsqu'une VM ne possède pas d'adresse IP externe attribuée, elle ne peut pas établir de connexions directes avec des services externes, y compris d'autres services Google Cloud. Pour permettre à ces VM d'accéder aux services sur Internet, vous pouvez mettre en place et configurer une passerelle NAT. La passerelle NAT est une VM pouvant acheminer le trafic pour le compte de toute autre VM du réseau. Vous devriez avoir une passerelle NAT par réseau. Sachez qu'une passerelle NAT à VM unique ne doit pas être considérée comme étant hautement disponible et n'est pas en mesure d'accepter un débit de trafic élevé pour plusieurs VM. Consultez le guide de déploiement IBM Db2 pour SAP NetWeaver pour obtenir des instructions sur la configuration d'une VM en tant que passerelle NAT.

Images personnalisées

Une fois votre système configuré, vous pouvez créer des images personnalisées. Vous devez créer ces images lorsque vous modifiez l'état de votre disque persistant racine et souhaitez pouvoir restaurer facilement le nouvel état. Vous devriez avoir un plan de gestion des images personnalisées que vous créez. Pour plus d'informations, consultez les bonnes pratiques pour la gestion des images.

Identification de l'utilisateur et accès aux ressources

Lorsque vous planifiez la sécurité d'un déploiement SAP sur Google Cloud, vous devez identifier les éléments suivants :

  • Les comptes utilisateur et les applications qui ont besoin d'accéder aux ressources Google Cloud de votre projet Google Cloud.
  • Les ressources Google Cloud spécifiques à votre projet auxquelles chaque utilisateur doit accéder.

Vous devez ajouter chaque utilisateur à votre projet en ajoutant son ID de compte Google au projet en tant que compte principal. Pour un programme d'application qui utilise les ressources Google Cloud, vous devez créer un compte de service. Il fournit une identité d'utilisateur pour le programme au sein de votre projet.

Les VM Compute Engine possèdent leur propre compte de service. Tous les programmes qui s'exécutent sur une VM peuvent utiliser le compte de service de la VM, à condition que le compte de service de la VM dispose des autorisations liées aux ressources dont le programme a besoin.

Après avoir identifié les ressources Google Cloud dont chaque utilisateur a besoin, accordez à chaque utilisateur l'autorisation d'utiliser chaque ressource en attribuant des rôles spécifiques à l'utilisateur. Examinez les rôles prédéfinis fournis par IAM pour chaque ressource et attribuez des rôles à chaque utilisateur afin de lui accorder les autorisations minimales nécessaires pour exécuter ses tâches ou ses fonctions.

Si vous avez besoin d'exercer un contrôle plus précis et plus restrictif sur les autorisations que celui fourni par les rôles IAM prédéfinis, créez des rôles personnalisés.

Pour en savoir plus sur les rôles IAM dont les programmes SAP ont besoin sur Google Cloud, consultez la page Gestion de l'authentification et des accès pour les programmes SAP sur Google Cloud.

Pour en savoir plus sur la gestion de l'authentification et des accès pour SAP sur Google Cloud, consultez la présentation de la gestion de l'authentification et des accès pour SAP sur Google Cloud.

Mise en réseau et sécurité réseau

Prenez en compte les informations des sections suivantes lors de la planification de la mise en réseau et de la sécurité.

Modèle de privilège minimum

L'une de vos premières lignes de défense consiste à limiter le nombre de personnes pouvant accéder à votre réseau et à vos VM à l'aide de pare-feu. Par défaut, tout le trafic vers les VM, même celui provenant d'autres VM, est bloqué par le pare-feu, sauf si vous créez des règles pour autoriser l'accès. La seule exception est le réseau par défaut créé automatiquement avec chaque projet, et pour lequel des règles de pare-feu sont créées par défaut.

En créant des règles de pare-feu, vous pouvez limiter tout le trafic sur un ensemble de ports donné à des adresses IP source spécifiques. Vous devez suivre le modèle de privilège minimum pour limiter l'accès aux adresses IP, protocoles et ports spécifiques qui nécessitent un accès. Par exemple, vous devez toujours configurer un hôte bastion et autoriser les connexions SSH dans votre système SAP NetWeaver uniquement à partir de cet hôte.

Réseaux personnalisés et règles de pare-feu

Vous pouvez utiliser un réseau pour définir une adresse IP de passerelle et la plage de réseau des VM connectées à ce réseau. Tous les réseaux Compute Engine utilisent le protocole IPv4. Chaque projet Google Cloud est associé à un réseau par défaut doté de configurations et de règles de pare-feu prédéfinies. Cependant, nous vous conseillons d'ajouter un sous-réseau personnalisé et des règles de pare-feu basées sur un modèle de privilège minimum. Par défaut, un réseau nouvellement créé n'a pas de règles de pare-feu et donc pas d'accès au réseau.

Selon vos besoins, vous souhaiterez peut-être ajouter des sous-réseaux supplémentaires pour isoler des parties de votre réseau. Pour plus d'informations, consultez la section sur les sous-réseaux.

Les règles de pare-feu s'appliquent à l'ensemble du réseau et à toutes les VM du réseau. Vous pouvez ajouter une règle de pare-feu qui autorise le trafic entre les VM du même réseau et pour tous les sous-réseaux. Vous pouvez également configurer des pare-feu à appliquer à des VM cibles spécifiques à l'aide du mécanisme de marquage.

Certains produits SAP, tels que SAP NetWeaver, nécessitent l'accès à certains ports. Assurez-vous d'ajouter des règles de pare-feu pour permettre l'accès aux ports indiqués par SAP.

Routes

Les routes sont des ressources globales associées à un seul réseau. Les routes créées par l'utilisateur s'appliquent à toutes les VM d'un réseau. Cela signifie que vous pouvez ajouter une route qui transfère le trafic d'une VM à une autre au sein du même réseau et entre sous-réseaux sans requérir d'adresses IP externes.

Pour un accès externe aux ressources Internet, lancez une VM sans adresse IP externe et configurez une autre VM en tant que passerelle NAT. Cette configuration nécessite que vous ajoutiez votre passerelle NAT en tant que route pour votre instance SAP. Pour plus d'informations, consultez la section Passerelles NAT et hôtes bastions.

Cloud VPN

Vous pouvez connecter de manière sécurisée votre réseau existant à Google Cloud via une connexion VPN avec IPsec en utilisant Cloud VPN. Le trafic circulant entre les deux réseaux est chiffré par une passerelle VPN, puis déchiffré par l'autre passerelle VPN. Ce procédé protège les données lors des transferts via Internet. Vous pouvez contrôler de manière dynamique quelles sont les VM qui peuvent envoyer du trafic via le VPN à l'aide de tags d'instance sur les routes. Les tunnels Cloud VPN sont facturés à un tarif mensuel fixe, majoré des frais de sortie standards. Notez que vous devez quand même payer les frais de sortie standards lorsque vous connectez deux réseaux d'un même projet. Pour plus d'informations, consultez les sections Présentation du réseau VPN et Choisir une option de routage VPN.

Sécuriser un bucket Cloud Storage

Si vous utilisez Cloud Storage pour héberger les sauvegardes de vos données et journaux, assurez-vous d'utiliser TLS (HTTPS) lors de l'envoi de données à Cloud Storage à partir de vos VM afin de protéger les données en transit. Cloud Storage chiffre automatiquement les données au repos. Vous pouvez spécifier vos propres clés de chiffrement si vous disposez de votre propre système de gestion de clés.

Reportez-vous aux ressources de sécurité supplémentaires ci-dessous pour votre environnement SAP sur Google Cloud :

Sauvegarde et récupération

Vous devez mettre en place une marche à suivre pour remettre votre système en état de fonctionnement si le pire se produisait.

Pour plus d'informations sur la sauvegarde et la récupération des systèmes IBM Db2 compatibles avec SAP, consultez les informations suivantes :

Pour obtenir des conseils généraux sur la façon de planifier la reprise après sinistre à l'aide de Google Cloud, consultez les articles suivants :

Automatisation pour les déploiements IBM Db2

Google Cloud fournit un fichier de configuration Terraform qui vous permet d'automatiser le déploiement de ressources pour IBM Db2 avec Linux.

La configuration sap_db2.tf fournie par Google Cloud pour IBM Db2 provisionne les ressources suivantes :

  • Instance de VM Compute Engine en fonction du type de machine de votre choix
  • Système d'exploitation Red Hat Enterprise Linux (RHEL) ou SUSE Linux Enterprise Server (SLES) de votre choix
  • Disques persistants Compute Engine
  • Agent de surveillance Google Cloud pour SAP NetWeaver

Pour obtenir des instructions sur l'automatisation des déploiements, consultez la page Déploiement automatisé de VM pour IBM Db2 sous Linux à l'aide de Terraform.

Clusters IBM Db2 haute disponibilité

Vous pouvez configurer un cluster IBM Db2 hautement disponible, tolérant aux sinistres et compatible avec SAP sur Google Cloud. Le cluster est configuré et géré par IBM Tivoli System Automation for Multiplatforms (TSAMP) et utilise la fonction IBM Db2 HADR à des fins de réplication.

Les applications se connectent au serveur IBM Db2 principal via une adresse IP flottante qui, en cas de basculement, est réaffectée par TSAMP au serveur de secours.

La fonction IBM Db2 HADR accepte jusqu'à trois serveurs de secours. Sur Google Cloud, les VM hôtes du cluster doivent se trouver dans la même région, mais peuvent se trouver dans différentes zones de la région.

La compatibilité de SAP pour les clusters DB2 HA sur Google Cloud est répertoriée dans la note SAP 2456432 - Applications SAP sur Google Cloud : produits et types de machines Google Cloud compatibles.

Pour plus d'informations sur les fonctionnalités IBM Db2 compatibles avec SAP, voir la note SAP 1555903.

Architectures de déploiement

Vous pouvez déployer les VM hôtes dans un cluster IBM Db2 HA sur plusieurs zones de Compute Engine de la même région ou, si nécessaire, les déployer sur une seule zone.

Pour une disponibilité maximale, déployez chaque VM hôte dans une zone différente.

Le diagramme suivant illustre un déploiement multizone utilisant une implémentation de route statique pour l'adresse IP flottante.

Chaque hôte d&#39;un cluster Db2 HA est déployé dans une zone différente.

Le diagramme suivant illustre un déploiement à zone unique utilisant une implémentation IP d'alias pour l'adresse IP flottante.

Les deux hôtes d&#39;un cluster Db2 HA sont déployés dans la même zone.

Documents obligatoires

Pour déployer un cluster IBM Db2 HA pour SAP, vous devez vous servir des documentations de SAP et de Google Cloud.

Vous devrez peut-être vous reporter à de la documentation SAP ou IBM supplémentaire lors de l'installation des composants SAP et IBM.

Configuration requise pour un cluster IBM Db2 HA sur Google Cloud

Sur Google Cloud, SAP est compatible avec les clusters IBM Db2 HA uniquement sur les systèmes d'exploitation RHEL ou SLES.

Consultez la documentation sur les ressources nécessaires pour connaître la configuration logicielle Google Cloud requise pour les instances IBM Db2.

Pour IBM TSAMP, utilisez la dernière version disponible compatible avec votre version d'IBM Db2 et votre système d'exploitation.

Pour toutes les autres exigences matérielles et logicielles, consultez le guide IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms.

Adresses IP flottantes pour les clusters IBM Db2 HA sur Google Cloud

Un cluster IBM Db2 HA pour SAP utilise une adresse IP flottante, également appelée "adresse IP virtuelle" ou "adresse IP partagée".

Pour un cluster IBM Db2 HA, Google Cloud peut mettre en œuvre une adresse IP flottante à l'aide d'une route statique Google Cloud ou d'une adresse IP d'alias Google Cloud.

L'implémentation de la route statique est recommandée pour les clusters IBM Db2 HA multizones. Les déploiements multizones permettent de s’assurer que la défaillance d’une zone unique n'entraînera pas celle de votre système IBM Db2.

Toutefois, si votre architecture de réseau n'est pas compatible avec les routes statiques, ou si vous souhaitez éviter des solutions telles que la superposition d'adresses IP ou le routage complexe, vous pouvez utiliser la mise en œuvre de l'adresse IP d'alias avec un cluster IBM Db2 HA à zone unique. Les adresses IP d'alias ne sont pas recommandées pour les déploiements multizones car la réaffectation de l'alias peut ne pas être garantie en cas de défaillance d'une zone.

Selon que vous choisissez l'implémentation de route statique ou l'implémentation d'adresse IP d'alias, les exigences relatives à l'adresse IP que vous utilisez pour votre adresse IP flottante sont différentes.

L'utilisation d'une route statique nécessite que vous sélectionniez une adresse IP pour votre adresse IP flottante :

  • en dehors des plages IP de vos sous-réseaux de cloud privé virtuel existants où résident les VM ;
  • qui n'entre pas en conflit avec les adresses IP externes de votre réseau étendu.

Consultez votre administrateur réseau pour déterminer une adresse IP appropriée pour l'implémentation d'une route statique.

L'utilisation d'une adresse IP d'alias nécessite de réserver une adresse IP dans la plage d'adresses IP de votre sous-réseau afin de l'utiliser en tant qu'adresse IP flottante.

Pour plus d'informations sur les adresses IP flottantes sur Google Cloud, consultez les bonnes pratiques pour les adresses IP flottantes.

SAP recommande l'utilisation d'adresses IP flottantes dans les clusters IBM Db2 HA. SAP est compatible avec la fonction ACR (réacheminement automatique du client), à condition que vous preniez en compte toutes les exigences et limitations de cette méthode. Pour en savoir plus, référez-vous à la note SAP 1568539.

Le départage réseau

Les clusters IBM Db2 HA envoient généralement une requête ICMP (ping) à une passerelle réseau, qui sert de condition de départage réseau par défaut pour déterminer quel nœud doit prendre le relais en cas de perte de communication entre les nœuds d'un cluster.

Étant donné que les passerelles réseau sur Google Cloud ne répondent pas aux requêtes ICMP, utilisez toute autre adresse IP pouvant faire l'objet d'un ping et qui est hautement disponible. Par exemple, vous pouvez utiliser l'adresse IP virtuelle de votre instance Central Services SAP ou le DNS de Google, 8.8.8.8.

Si la condition de départage du réseau ne peut pas répondre aux requêtes ICMP lors de l'installation, celle-ci échoue.

D'autres conditions de départage réseau existent et sont définies par IBM. Pour en savoir plus, consultez la section Configurer la condition de départage.

Outils de configuration pour un cluster Db2 HA

Vous pouvez utiliser l'un des outils suivants fournis par SAP et IBM pour configurer un cluster IBM Db2 HADR :

  • L'outil de configuration de cluster SAP (sapdb2cluster.sh)
  • L'utilitaire de configuration d'instance IBM DB2 à haute disponibilité (db2haicu)

L'outil de configuration de cluster SAP Db2 (sapdb2cluster.sh)

SAP recommande l'utilisation de l'outil de configuration de cluster fourni par SAP, sapdb2cluster.sh, pour configurer et créer un cluster Db2 HA. Les instructions de déploiement Google Cloud utilisent l'outil de configuration de cluster SAP. L'outil de configuration du cluster simplifie une grande partie de la configuration de cluster et garantit qu'il répond aux exigences SAP.

Avant la création du cluster HA avec l'outil de configuration de cluster SAP, l'une des étapes des instructions de déploiement Google Cloud apporte une modification mineure à l'outil de configuration de cluster SAP, sapdb2cluster.sh, de sorte que l'outil ignore la création de la classe de ressources par défaut IBM.ServiceIP.

Les ressources créées à partir de la classe de ressources IBM.ServiceIP IBM TSAMP engendrent des requêtes ARP gratuites, qui ne sont pas compatibles avec les réseaux VPC sur Google Cloud, comme expliqué dans la section Défis liés à la migration des adresses IP flottantes vers Compute Engine.

Pour télécharger la dernière version de l'outil de configuration de cluster, consultez la note SAP 960843.

L'utilitaire de configuration d'instance IBM DB2 à haute disponibilité (db2haicu)

Au lieu d'utiliser l'outil de configuration de cluster SAP, vous pouvez utiliser l'utilitaire IBM db2haicu, qui fournit également une interface interactive. L'outil de configuration de cluster SAP utilise db2haicu pour la configuration de cluster.

Si vous souhaitez utiliser l'utilitaire db2haicu pour configurer le cluster, vous devez d'abord configurer la relation HADR afin de pouvoir utiliser db2haicu. Bien que la procédure d'installation globale puisse être plus complexe avec l'utilitaire db2haicu, celui-ci permet de personnaliser davantage les configurations réseau complexes ou d'autres exigences spécifiques à votre environnement.

Suivez toujours les directives SAP et IBM lorsque vous utilisez l'utilitaire db2haicu.

Pour plus d'informations sur db2haicu, consultez la documentation IBM Db2.

Script d'aide Google Cloud pour l'intégration de cluster IBM TSAMP

Pour permettre au cluster IBM Db2 HA d'appeler les commandes appropriées de l'API Google Cloud afin de démarrer, d'arrêter et de surveiller la ressource TSAMP pour l'adresse IP flottante, vous devez télécharger un script d'aide Google Cloud sur les VM hôtes. Lorsque vous créez la ressource d'adresse IP flottante dans IBM TSAMP, vous référencez le script d'aide Google Cloud.

Licences

Cette section fournit des informations sur les exigences en matière de licences.

Licences IBM Db2

Lorsque vous exécutez IBM Db2 sur Google Cloud, vous devez apporter votre propre licence (BYOL). Vous pouvez obtenir des licences Db2 auprès de SAP ou d'IBM. Pour plus d'informations sur les licences et l'assistance, consultez les notes SAP suivantes :

Pour plus d'informations sur les licences SAP, contactez SAP.

Licences de système d'exploitation

Dans Compute Engine, il existe deux méthodes d'octroi de licence pour SLES, RHEL et Windows Server :

  • Avec les licences pay-as-you-go (facturation à l'usage), le coût horaire de votre VM Compute Engine inclut les licences. Google gère la logistique des licences. Vos coûts horaires sont plus élevés, mais vous avez toute la flexibilité nécessaire pour augmenter et diminuer les coûts selon vos besoins. Il s'agit du modèle de licence utilisé pour les images publiques Google Cloud incluant SLES, RHEL et Windows Server.

  • Avec BYOL, les coûts de votre VM Compute Engine sont réduits car la licence n’est pas incluse. Vous devez migrer une licence existante ou acheter votre propre licence, ce qui signifie payer à l'avance, et vous avez moins de flexibilité.

Assistance

Pour les problèmes liés à l'infrastructure ou aux services Google Cloud, contactez l'assistance Customer Care. Ses coordonnées sont disponibles sur la page de présentation de l'assistance dans la console Google Cloud. Si l'assistance Customer Care détecte un problème dans vos systèmes SAP, vous serez redirigé vers l'assistance SAP.

Pour les problèmes liés au produit SAP, entrez votre demande d'assistance avec l'outil de l'assistance SAP. SAP évalue la demande d'assistance puis, s'il semble s'agir d'un problème d'infrastructure Google Cloud, la transfère au composant Google Cloud approprié dans son système : BC-OP-LNX-GOOGLE ou BC-OP-NT-GOOGLE.

Exigences liées à l'assistance

Pour bénéficier d'une assistance pour les systèmes SAP ainsi que pour l'infrastructure et les services Google Cloud que ces systèmes utilisent, vous devez satisfaire aux exigences minimales de la formule d'assistance.

Pour en savoir plus sur les exigences minimales concernant l'assistance pour SAP sur Google Cloud, consultez les ressources suivantes :

Pour plus d'informations sur l'assistance SAP pour Db2, consultez la note SAP 1168456 - DB6 : Processus de support et dates de fin de support pour IBM DB2 LUW.

Étapes suivantes

Pour déployer IBM Db2 sur Google Cloud, consultez les pages suivantes :

Pour déployer un cluster IBM Db2 HA sur Google Cloud, consultez le guide de déploiement du cluster à haute disponibilité IBM Db2 pour SAP.