Résilience pour les déploiements SAP sur Google Cloud

Ce document décrit des considérations de conception qui vous aideront à exécuter des systèmes SAP résilients et fiables sur Google Cloud.

L'infrastructure et les logiciels peuvent échouer. Les causes et l'ampleur de ces échecs exigent que les déploiements de systèmes SAP respectent certains principes afin de tirer pleinement parti de l'infrastructure Google Cloud. La combinaison d'options d'infrastructure avec des architectures de déploiement de logiciels SAP résilientes garantit l'intégrité des données et la protection contre la perte de données ou la non-disponibilité du système.

Options de résilience et de fiabilité

Vous pouvez déployer des systèmes résilients et robustes en utilisant des fonctionnalités au niveau de l'infrastructure et des couches d'application pour absorber les défaillances ou permettre de les récupérer. Pour garantir la résilience et la fiabilité des déploiements de systèmes SAP sur Google Cloud, nous vous recommandons d'envisager les options suivantes :

  • Résistance de la plate-forme : les services et produits Google Cloud sont conçus pour être résistants et disposent d'une redondance intégrée afin de respecter les contrats de niveau de service publiés. Lorsque vous déployez vos systèmes SAP conformément aux consignes et aux bonnes pratiques de Google Cloud, les mécanismes de la plate-forme sous-jacente augmentent la résilience de votre système SAP. Cela vous permet de poursuivre vos activités en cas de défaillance ou de sinistre.
  • Haute disponibilité (HA) : en utilisant des configurations d'infrastructure et de logiciels compatibles avec la HA, vous pouvez activer la récupération automatique du système avec un minimum de perturbations. Cette utilisation garantit également une intervention minimale de votre part en cas de défaillance dans certaines parties de l'infrastructure ou du logiciel d'application sous-jacent. La haute disponibilité vise à protéger votre système contre la défaillance ou la dégradation d'un seul composant en fournissant une redondance pour les composants de votre système.
  • Reprise après sinistre (DR) : la reprise après sinistre permet de récupérer les opérations commerciales en cas de défaillance causée par un sinistre. La reprise après sinistre consiste à déplacer les services et les applications vers un emplacement secondaire physiquement isolé, à partir duquel les opérations peuvent se poursuivre. Les systèmes de DR vont au-delà d'un seul composant ou d'un seul service défaillant pour atténuer les événements moins fréquents, mais plus importants. Il peut s'agir d'événements régionaux tels que des catastrophes naturelles, des pannes de réseau électrique et des événements localisés tels que des incendies ou des erreurs humaines. Les dispositions de DR incluent les éléments suivants :
    • Réplication des données : vous pouvez utiliser la réplication logicielle ou au niveau du stockage pour vous assurer que vos données sont transférées vers un emplacement secondaire avec une perte de données potentielle minimale.
    • Sauvegardes : vous pouvez récupérer un système ou une base de données à l'aide de sauvegardes stockées séparément de votre espace de stockage de données principal. Cela peut inclure l'utilisation d'instantanés ou de sauvegardes importés dans Cloud Storage, à condition qu'ils soient stockés dans une région autre que celle où le système est déployé.

Comme ces options sont complémentaires, vous pouvez combiner des aspects de chacune d'elles pour améliorer la résilience de vos déploiements SAP. Les options que vous sélectionnez ont une incidence sur l'objectif de temps de récupération (RTO) et l'objectif de point de récupération (RPO) de votre déploiement. Par conséquent, vous devez également évaluer le coût de ces options par rapport à leur impact sur la résilience du système et la continuité de l'activité. Nous vous recommandons d'examiner attentivement toutes les options disponibles et de les implémenter en fonction de vos objectifs de reprise après sinistre.

La section suivante décrit un exemple de déploiement SAP et l'impact que vous pouvez attendre des différentes configurations de haute disponibilité et de reprise après sinistre sur sa résilience et sa fiabilité.

Exemples de cas de figure

Prenons l'exemple d'un déploiement à l'échelle de SAP S/4HANA sur Google Cloud. Le tableau suivant présente des exemples de configurations de haute disponibilité et de reprise après sinistre qui peuvent être appliquées à ce déploiement, ainsi que leur impact attendu sur la résilience et la fiabilité du système, par exemple en termes de disponibilité, de RTO et de RPO.

Configuration HA ou DR Dimension de résilience ou de fiabilité Attentes
Configuration HA. Réfléchissez aux éléments suivants :
  • us-central1 est la région principale.
  • Les instances X4 sont déployées dans deux zones différentes, telles que us-central1-a et us-central1-b.
 Disponibilité
  • 99,99 % ou plus pour l'ensemble du système.
  • 99,9 % ou plus pour chaque instance
Une configuration de DR qui utilise la réplication système SAP HANA asynchrone sur un système de DR entièrement résident en mémoire Réfléchissez aux éléments suivants :
  • us-central1 est l'emplacement principal.
  • us-east4 est l'emplacement de DR et exécute une instance X4 de la même taille que l'emplacement principal.
  • Les données sont préchargées dans l'instance X4 exécutant SAP HANA sur l'emplacement de reprise après sinistre.
  • Dans l'emplacement de DR, les serveurs d'applications sont provisionnés ou vous avez acheté des réservations pour eux. Remarque 1
 Temps de récupération Quelques heures, y compris le temps nécessaire pour la propagation du DNS vers les systèmes clients.
Point de récupération Minutes, par rapport à la dernière réplication asynchrone.
Configuration de DR qui utilise des sauvegardes avec une infrastructure préprovisionnée Remarque 1. Prenons l'exemple d'un système qui utilise la sauvegarde et la restauration basées sur Backint. Temps de récupération Délai de récupération de la base de données à partir de la sauvegarde Remarque 2.
Point de récupération Au dernier point dans le temps de la sauvegarde ou de l'instantané du journal SAP HANA.
Configuration de DR qui utilise des sauvegardes sans infrastructure provisionnée à l'avance Remarque 3. Prenons l'exemple d'un système qui utilise la sauvegarde et la récupération basées sur Backint. Temps de récupération Plusieurs jours pour provisionner l'infrastructure Remarque 4 et récupérer les données de la sauvegarde Remarque 3.
Point de récupération Au dernier point dans le temps de la sauvegarde ou de l'instantané du journal SAP HANA.

Remarques concernant le tableau :

  1. Vous pouvez déployer votre solution de reprise après sinistre sans provisionner au préalable l'infrastructure requise en réservant les ressources requises à l'avance. Cela permet de s'assurer que les ressources requises sont disponibles lorsque vous devez activer votre solution de reprise après sinistre en cas de catastrophe sur le site principal. Pour en savoir plus, consultez la section Réservations de ressources zonales Compute Engine.

  2. Le temps d'exécution d'une opération de récupération dépend fortement de la solution de sauvegarde utilisée et de la taille des fichiers de sauvegarde. Pour déterminer le délai exact de récupération en fonction de la taille de votre base de données et de votre taux de modification, vous devez évaluer la vitesse de récupération de la solution de sauvegarde que vous utilisez, telle que Backint ou Instantané de disque.

  3. Le déploiement d'une solution de reprise après sinistre sans préprovisionnement ni réservation des ressources requises peut entraîner des situations où les ressources requises ne sont pas disponibles. Cela peut augmenter le temps de récupération de votre déploiement, ce qui a un impact sur vos opérations commerciales.

  4. Pour les types de machines tels que X4, qui ne sont pas disponibles à la demande et doivent être commandés, plusieurs semaines de délai peuvent être nécessaires sans réservation préalable de la capacité.

Considérez les informations présentées dans le tableau précédent comme un complément aux conceptions et plans de reprise après sinistre existants que vous avez déduits des consignes du secteur. Pour en savoir plus, consultez les ressources suivantes :

Recommandations pour les déploiements résilients

Les sections suivantes présentent les configurations de HA et de DR que nous recommandons pour déployer des charges de travail SAP résilientes et fiables sur Google Cloud.

Bien que nous vous recommandions vivement de mettre en œuvre ces recommandations pour les charges de travail SAP qui hébergent des opérations de production critiques pour l'activité, vous pouvez également les mettre en œuvre pour les systèmes SAP non destinés à la production, où une panne prolongée peut avoir un impact négatif sur vos activités.

Pour en savoir plus sur les recommandations, consultez les sections suivantes :

Recommandations pour la haute disponibilité

  • Utilisez au moins deux zones différentes dans la même région pour déployer des instances.
  • Supprimez les points de défaillance uniques. Pour ce faire, ajoutez des ressources supplémentaires qui fournissent la résilience et la redondance aux services ou composants d'application défectueux en cas de défaillance.
  • Utilisez des services régionaux dotés d'une redondance intégrée. Par exemple, utilisez Filestore Enterprise pour héberger des fichiers partagés et des équilibreurs de charge fournis par Cloud Load Balancing.
  • Utiliser l'automatisation pour le basculement. L'automatisation limite le besoin d'intervention manuelle en cas d'échec et réduit l'impact sur les opérations commerciales. Par exemple, vous pouvez utiliser un gestionnaire de clusters Linux tel que Pacemaker.

  • Utilisez des chemins réseau redondants. Assurez-vous d'avoir une connectivité redondante dans votre région principale. Selon vos besoins en connectivité, différentes options sont disponibles. Pour en savoir plus, consultez la page Connectivité Google Cloud.

    Pour atteindre une disponibilité de 99,99 % pour vos connexions aux régions Google Cloud, nous vous recommandons de configurer plusieurs connexions. Pour en savoir plus, consultez Établir une disponibilité de 99,99 % pour Dedicated Interconnect.

  • Activez les règles de migration à chaud et de redémarrage automatique sur les ressources Compute Engine :

    • Pour que les instances de calcul restent en ligne lors des événements de maintenance initiés par Google, vous pouvez utiliser la migration à chaud en définissant la propriété onHostMaintenance avec l'option MIGRATE (par défaut). Pour les instances de calcul qui ne sont pas compatibles avec la migration à chaud, définissez la propriété automaticRestart sur true (par défaut). Cela permet à Google de redémarrer toute instance qui ne répond plus. Pour en savoir plus, consultez À propos des événements hôtes.
    • Pour les instances de calcul qui ne sont pas compatibles avec la migration à chaud ou la maintenance planifiée, des commandes de maintenance avancées sont disponibles. Pour en savoir plus, consultez Activer le contrôle de maintenance avancé pour les nœuds à locataire unique.

  • Avant le lancement, testez le basculement dans votre environnement.

Recommandations pour la reprise après sinistre

  • Hébergez la solution de DR dans un emplacement autre que l'emplacement principal. Pour éviter que votre solution de reprise après sinistre ne soit affectée par le même événement que votre système principal, assurez-vous que les deux sont hébergés à des emplacements différents.

    Idéalement, votre emplacement de DR doit se trouver dans une région différente. Toutefois, si l'utilisation d'une deuxième région n'est pas une bonne option en raison de problèmes de résidence ou de souveraineté des données, contactez l'équipe commerciale Google Cloud pour discuter d'autres options disponibles.

    Le schéma suivant illustre l'architecture de haut niveau d'un déploiement SAP HANA sur Google Cloud avec les provisions HA et DR suivantes :

    • Pour assurer la haute disponibilité, le système principal dispose de deux nœuds déployés dans différentes zones de la même région.
    • Pour assurer la résilience, les systèmes principal et de reprise après sinistre sont hébergés dans des régions différentes, avec une réplication asynchrone.

    Diagramme d'architecture de haut niveau pour SAP HANA sur Google Cloud avec haute disponibilité et reprise après sinistre

  • Assurez-vous que la capacité est suffisante dans l'emplacement de DR.

    • Déterminez si votre système de DR doit fonctionner à la même capacité que le système principal ou à une capacité réduite. Pour les bases de données telles que SAP HANA, votre site de DR doit disposer de suffisamment de ressources pour exploiter efficacement votre charge de travail SAP.
    • Vérifiez également à l'avance que les ressources requises sont disponibles dans votre site de reprise après sinistre. Pour vous assurer de la disponibilité des ressources, vous pouvez les provisionner sur le site de reprise après sinistre ou acheter des réservations à l'avance. L'achat de réservations vous permet d'éviter les scénarios où, après un échec, les ressources ne sont pas disponibles, car elles sont allouées à d'autres clients Google Cloud. Cela est particulièrement important pour les types d'instances de calcul plus importants, tels que M2 ou X4. Pour en savoir plus sur les réservations, consultez la section Réservations de ressources zonales Compute Engine.

    Pour optimiser les coûts, l'infrastructure de votre site de DR peut être utilisée pour des charges de travail hors production, et basculer pour assurer votre charge de travail de production lors d'un événement de DR. Toutefois, cela se fait au détriment d'un temps de récupération plus long.

  • Vérifiez la connectivité de votre emplacement de DR. Comme pour les chemins réseau redondants vers votre emplacement principal, envisagez d'ajouter des options de remplacement telles que Cloud VPN.

  • Identifiez les signaux qui peuvent être utilisés pour identifier un sinistre. Ces signaux vous aident à décider quand déclencher votre solution de DR. Voici quelques exemples de ces signaux :

    • Informations sur l'état des services Google Cloud provenant de Service Health de Google Cloud.
    • Perte totale de la disponibilité de l'instance, comme indiqué par Cloud Monitoring, tel que configuré pour vos projets Google Cloud.
    • Communication de Google Cloud Customer Care ou du représentant de votre compte Google Cloud, qui informe des interruptions de service et des délais de résolution potentiels.
    • Corruptions logiques de votre base de données déterminées par les utilisateurs ou les administrateurs de votre système SAP, qui ne peuvent pas être résolues par les mécanismes de haute disponibilité.

  • Testez régulièrement votre solution de DR. Assurez-vous que votre solution fonctionne en cas de sinistre. Cela peut avoir une incidence sur vos opérations quotidiennes. Si vos opérations le permettent, envisagez d'opérer de manière symétrique sur vos emplacements principaux et secondaires, et de faire tourner les opérations entre eux tous les trois à six mois.

  • Utilisez la réplication pour obtenir le meilleur point de récupération. La réplication fournit une version en temps quasi réel de votre site principal sur votre site de DR. Les options de réplication suivantes sont disponibles, en fonction de la conception de votre charge de travail SAP :

    • Réplication au niveau de la base de données en exploitant des mécanismes tels que la réplication du système SAP HANA, qui réplique les données à un niveau logique entre le site principal et le site de DR.
    • Réplication au niveau du stockage en exploitant des mécanismes tels que la réplication asynchrone des disques persistants, qui réplique au niveau du stockage de blocs. Selon l'option de stockage utilisée par votre charge de travail SAP, les options de réplication au niveau du stockage disponibles varient.

    Veillez à surveiller la réplication à l'aide d'un outil approprié, tel que SAP HANA Cockpit. Cela permet de vérifier que votre charge de travail SAP a été entièrement répliquée avant que votre solution de reprise après sinistre ne soit déclenchée en cas d'événement de reprise après sinistre.

  • Utilisez des sauvegardes de données pour permettre une récupération à un instant précis.

    • Pour créer une redondance, utilisez plusieurs emplacements de stockage pour stocker vos sauvegardes. Exemple :
      • Lorsque vous créez une sauvegarde à l'aide de la fonctionnalité Backint de l'agent Google Cloud pour SAP, utilisez un emplacement de bucket birégional ou multirégional. Pour en savoir plus, consultez la page Créer des buckets Cloud Storage.
      • Lorsque vous créez une sauvegarde à l'aide de la fonctionnalité d'instantané de disque de l'agent, utilisez Cloud Storage multirégional ou birégional. Pour en savoir plus sur les emplacements des buckets Cloud Storage, consultez la page Emplacements des buckets.
    • Utilisez des sauvegardes incrémentielles ou différentielles, qui peuvent inclure le stockage d'instantanés dans Google Cloud.
    • Surveillez vos sauvegardes pour vous assurer qu'elles sont correctement créées conformément à votre stratégie de sauvegarde. Pour une solution complète de protection des données, envisagez d'utiliser le service de sauvegarde et de reprise après sinistre de Google Cloud.
    • Testez régulièrement vos sauvegardes pour vous assurer qu'elles sont récupérables en cas de sinistre et vérifiez le temps nécessaire pour récupérer votre système ou votre base de données. Il est conseillé de tester la récupération une fois par cycle de sauvegarde, qui dure généralement 28 jours.
    • Protégez vos sauvegardes comme vous le feriez pour votre système principal, par exemple en utilisant des paramètres de conservation de l'espace de stockage et des clés de chiffrement.

Autres recommandations

  • Évaluez le coût des configurations de haute disponibilité et de reprise après sinistre par rapport à l'impact qu'elles ont sur les aspects suivants de votre entreprise :
    • Temps d'arrêt potentiel des opérations et des transactions commerciales.
    • Perte potentielle de données entraînant une perte de confiance des clients, des fournisseurs ou des ventes, ou des échecs de conformité.
  • Chaque entreprise a des besoins spécifiques. Si votre situation nécessite une solution plus personnalisée, n'hésitez pas à contacter l'équipe commerciale Google Cloud.

Étape suivante