Explorer la phase de préparation et de planification du projet
Cette phase doit produire l’ensemble d’éléments suivant :
Document général de conception contenant
- Un inventaire du paysage SAP planifié (et, dans le scénario de migration, le paysage existant).
- Une matrice d’affectation des responsabilités (RACI) qui définit les responsabilités et les affectations de toutes les parties impliquées dans la livraison du projet.
- Une architecture de solution de haut niveau.
- Sélection des régions Azure cibles. La disponibilité des ressources n’est pas cohérente d’une région à l’autre.
- Architecture réseau qui fournit la connectivité entre les sites locaux et Azure. Vous devez envisager d’aligner votre conception sur le blueprint du centre de données virtuel pour Azure.
- Les principes de sécurité pour l'exécution des données à impact commercial élevé dans Azure. Vous devez penser à consulter la documentation sur la sécurité Azure.
Document de conception technique contenant
Un diagramme de blocs de la solution.
Le dimensionnement des composants de calcul, de stockage et de réseau dans Azure. Pour le dimensionnement SAP des machines virtuelles Azure, consultez la note SAP #1928533.
Architecture de la haute disponibilité et de la reprise d’activité.
L’architecture doit être basée sur le RTO et le RPO fournis par l’entreprise.
Pour une haute disponibilité au sein de la même zone, identifiez les fonctionnalités du produit SGBD cible. La plupart des SGBD offrent un serveur de secours synchrone, recommandé pour les systèmes de production. Consultez également la documentation SAP relative aux différentes bases de données dans l’article Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP. L’utilisation du service de cluster de basculement Windows avec une configuration de disques partagés pour la couche SGBD n’est PAS prise en charge. Au lieu de cela, envisagez des solutions comme :
- SQL Server AlwaysOn
- Oracle Data Guard
- Réplication de système HANA
Pour la reprise d’activité du niveau SGBD, dans les régions Azure, identifiez les options spécifiques au produit proposées par les fournisseurs du SGBD. La plupart d’entre eux prennent en charge la réplication asynchrone ou la copie des journaux de transaction.
Pour la couche Application SAP, déterminez si vous allez exécuter vos systèmes de test de régression métier (qui doivent correspondre à vos systèmes de production) dans la même région Azure ou dans la région de reprise d’activité après sinistre (DR). Dans ce dernier cas, vous pouvez utiliser les systèmes de tests de régression comme cibles de la récupération d’urgence pour la production.
Si vous décidez de ne pas utiliser les systèmes de tests de régression comme cibles de la récupération d’urgence, envisagez l’utilisation d’Azure Site Recovery comme méthode de réplication de la couche Application SAP dans la région Azure de récupération d’urgence. Pour plus d’informations, reportez-vous à la documentation Microsoft Configurer la reprise d’activité pour un déploiement d’application SAP NetWeaver multiniveau.
Si vous décidez d’utiliser une configuration combinant haute disponibilité et récupération d’urgence qui utilise des zones de disponibilité Azure, vérifiez que la région Azure que vous sélectionnez prend en charge les zones de disponibilité. La latence interzone est plus élevée que la latence entre machines virtuelles Azure qui font partie du même groupe à haute disponibilité.
Inventaire détaillé des versions des systèmes d’exploitation, des bases de données, des noyaux et des packs de support SAP. La prise en charge par SAP d’une configuration donnée dans des scénarios locaux n’implique pas que la même configuration est prise en charge par les machines virtuelles Azure. En fonction du résultat, il peut être nécessaire de mettre à niveau certains composants logiciels. Pour plus d’informations sur la configuration prise en charge, consultez les notes SAP suivantes :
- Note SAP #1928533. La note fournit également le dimensionnement SAP des références SKU des machines virtuelles Azure prises en charge par SAP.
- Note SAP #2039619. La note fournit la matrice de prise en charge d’Oracle sur Azure, selon laquelle Oracle prend en charge Windows et Oracle Linux seulement en tant que système d’exploitation invité dans les machines virtuelles Azure. Cette déclaration de prise en charge s’applique également à la couche d’application SAP exécutant des instances SAP. Toutefois, Oracle ne prend pas en charge la haute disponibilité pour les services SAP Central Services dans Oracle Linux par le biais de Pacemaker. Si vous avez besoin de la haute disponibilité pour ASCS sur Oracle Linux, vous devez utiliser SIOS Protection Suite pour Linux. Pour obtenir des informations détaillées sur la certification SAP, consultez la note SAP #1662610. Pour Windows, la solution de cluster de basculement Windows prise en charge par SAP pour SAP Central Services est prise en charge conjointement avec Oracle comme couche SGBD.
- Note SAP #2235581, qui fournit le tableau de prise en charge SAP HANA sur les différentes versions de système d’exploitation.
- Le répertoire matériel SAP HANA.
Conceptions à 3 niveaux pour les systèmes de production SAP (recommandé par rapport aux conceptions à 2 niveaux). La combinaison de (A)SCS et de serveurs d’applications sur la même machine virtuelle Azure n’est pas recommandée. Azure prend en charge l'utilisation de configurations de cluster multi-SID pour SAP Central Services avec Windows en tant que système d'exploitation invité. En revanche, Azure ne prend pas en charge les configurations de cluster multi-SID pour SAP Central Services sur les systèmes d’exploitation Linux. La documentation relative au système d’exploitation invité Windows se trouve dans les articles suivants :
Un inventaire de toutes les interfaces SAP
Incluez toutes les interfaces SAP et non-SAP.
Conception des services fondamentaux, notamment
- Services d’authentification et de résolution de noms (Active Directory et DNS).
- Topologie du réseau.
- Topologie du groupe de ressources.
- Contrôles d’accès en fonction du rôle pour la gestion de l’infrastructure et des applications.
- Stratégie d’étiquetage.
- Convention de nommage pour les composants de l’infrastructure, notamment les machines virtuelles Azure.
Informations de référence sur le contrat de Support Premier Microsoft
Référence de contrat de support Premier Microsoft, incluant un contact direct avec le responsable technique de compte Microsoft. Pour connaître les exigences de prise en charge SAP, consultez la note SAP #2015553.
Liste des abonnements Azure
La liste des abonnements Azure et leurs quotas de base respectifs. Si nécessaire, ouvrez des demandes de support pour augmenter les quotas des abonnements Azure.
Plan de réduction et de migration des données
Plan de réduction et de migration des données pour le transfert des données SAP dans Azure (dans les scénarios de migration). Pour les systèmes SAP NetWeaver, SAP offre des guides expliquant comment limiter le volume des données.
Approche de déploiement automatisé
L’objectif de l’automatisation des déploiements d’infrastructures sur Azure est de garantir des résultats déterministes. De nombreux clients utilisent des scripts PowerShell ou Azure CLI, et des modèles Azure Resource Manager. Mais il y a souvent d’autres technologies open source (comme Terraform et Ansible) qui peuvent être utilisées pour déployer une infrastructure Azure pour SAP et même pour installer des logiciels SAP. Vous trouverez des exemples sur GitHub dans Infrastructure d’automatisation des déploiements de SAP sur Azure.
Centre Azure pour les solutions SAP (ACSS) est une offre Azure qui fait de SAP une charge de travail de plus haut niveau sur Azure. Centre Azure pour les solutions SAP (ACSS) est une solution de bout en bout qui vous permet de créer et d’exécuter des systèmes SAP en tant que charge de travail unifiée sur Azure. Vous pouvez tirer parti des [capacités de gestion ACSS(/azure/sap/center-sap-solutions/manage-virtual-instance)] pour les systèmes SAP basés sur Azure nouveaux et existants.
Remarque
Définissez un rythme régulier de révision de la conception et du déploiement entre vous (le client), l’intégrateur système, Microsoft et les autres parties concernées.