Explorer la phase pilote

  • 20 minutes

Le pilote peut s’exécuter en parallèle à la planification et à la préparation du projet. Cette phase peut également être utilisée pour tester les options identifiées dans la phase de planification et de préparation. Dans le cadre du pilote, il est recommandé de configurer et de valider une solution HA/DR (haute disponibilité/reprise d’activité) complète ainsi que la conception de la sécurité. Dans certains cas, il est également possible d’utiliser cette phase pour effectuer des tests de scalabilité ou de déployer des systèmes de bac à sable (sandbox) SAP. Pour exécuter un pilote, les clients doivent commencer par identifier un système non critique qu’ils veulent migrer vers Azure et continuer en effectuant les tâches suivantes :

1. Optimiser le transfert de données vers Azure

L’approche et le résultat sont fortement dépendants de la connectivité d’un client à Azure. En fonction de la quantité de données, il peut être possible d’utiliser pour cela ExpressRoute, un VPN de site à site ou des services de transfert de données hors ligne, comme Azure Data Box ou le service Azure Import/Export.

2. Migration de la plateforme hétérogène SAP

Dans le cas d’une migration de plateforme hétérogène SAP, cela implique l’exportation et l’importation des données de la base de données, et de tester et d’optimiser les phases d’exportation et d’importation. Pour les grandes migrations hétérogènes ciblant SQL Server, consultez l’article SAP OS/DB Migration to SQL Server–FAQ. Vous pouvez utiliser Migration Monitor/SWPM si vous n’avez pas besoin de combiner la migration avec une mise à niveau de version ou SAP Database Migration Option (DMO) dans le cas contraire. Pour plus de détails, consultez l’article Database Migration Option (DMO) of SUM – Introduction. Dans les deux cas, effectuez les étapes suivantes :

  • Mesurez le temps nécessaire pour exporter à partir de la source, pour charger le contenu exporté sur Azure et pour effectuer l’importation. Optimisez le chevauchement entre l’exportation et l’importation.
  • Utilisez la comparaison entre les bases de données source et cible pour dimensionner correctement l’infrastructure cible.
  • Validez et optimisez le timing.

3. Effectuer la validation technique

Types de machines virtuelles

  • Reportez-vous aux notes du support SAP, au répertoire du matériel SAP HANA et à la matrice PAM (Product Availability Matrix) SAP pour vérifier l’exactitude des informations sur les références SKU des machines virtuelles Azure prises en charge, sur les versions des systèmes d’exploitation prises en charge pour ces références SKU de machine virtuelle Azure, et sur les versions de SAP et de SGBD prises en charge.
  • Vérifiez le dimensionnement de l’infrastructure et des composants d’application que vous déployez dans Azure. Lors de la migration d’applications existantes, vous pouvez normalement obtenir les mesures SAPS nécessaires en fonction de la télémétrie existante. Récupérez le benchmark SAP et comparez-le aux chiffres des SAPS listés dans la Note SAP 1928533. Consultez également les informations fournies dans SAPS ratings on Azure VMs – where to look and where you can get confused.
  • Évaluez et testez le dimensionnement de vos machines virtuelles Azure en fonction du débit de stockage et du débit réseau maximum des différents types de machines virtuelles que vous avez choisis lors de la phase de planification. Ces données sont disponibles dans l’article Tailles des machines virtuelles dans Azure. Quand Windows est le système d’exploitation invité de machines virtuelles Azure, il est important de prendre en compte le débit maximal du disque non mis en cache pour le dimensionnement. Dans le cas de Linux, il est également important de prendre en compte le débit maximal du disque non mis en cache pour le dimensionnement.

Stockage

  • Utilisez au minimum le stockage Azure SSD Standard pour les machines virtuelles représentant les couches d’applications SAP et pour un déploiement de SGBD non sensible aux performances, et le Stockage Premium Azure pour toutes les machines virtuelles des SGBD sensibles aux performances.
  • Évitez d’utiliser des disques HDD Standard Azure.
  • Utilisez Azure Disques managés.
  • Activez l’Accélérateur d’écriture Azure pour les lecteurs des journaux d’activité des SGBD avec des machines virtuelles Azure de la série M. Tenez compte des limites et des restrictions d’utilisation documentées de l’Accélérateur d’écriture.
  • Pour plus d’informations sur le stockage SGBD, consultez l’article Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP ainsi que la documentation spécifique au SGBD référencée dans ce document.
  • Pour les déploiements de SAP HANA, reportez-vous à la section Configurations et opérations de l’infrastructure SAP HANA sur Azure.
  • Ne montez jamais de disques de données Azure dans une machine virtuelle Azure Linux en utilisant l’ID d’appareil. À la place, utilisez l’identificateur unique universel (UUID). Soyez prudent quand vous utilisez des outils graphiques pour monter un disque de données Azure. Vérifiez bien les entrées dans /etc/fstab pour être sûr que les disques sont montés en utilisant l’UUID. Pour découvrir plus d’informations, consultez Se connecter à la machine virtuelle Linux afin de monter le nouveau disque.

Mise en réseau

Testez et évaluez votre infrastructure de réseau virtuel et la distribution de vos applications SAP entre ou dans les réseaux virtuels Azure.

  1. Évaluez l’approche de l’architecture de réseau virtuel hub-and-spoke ou de la micro-segmentation au sein d’un seul réseau virtuel Azure en fonction des critères suivants :

    • Coûts liés à l’échange de données entre des réseaux virtuels Azure appairés (pour obtenir plus de détails, voir Tarification du réseau virtuel Azure.
    • Comparaison entre la possibilité de mettre fin à un Peering entre des réseaux virtuels Azure et l’utilisation de groupes de sécurité réseau pour isoler les sous-réseaux au sein d’un réseau virtuel, dans les cas où les applications ou les machines virtuelles hébergées dans un sous-réseau du réseau virtuel deviennent un risque pour la sécurité.
    • Journalisation et l’audit centralisés du trafic réseau entre les sites locaux, Internet et le centre de données virtuel Azure.

  2. Évaluez et testez le chemin des données entre la couche d’application SAP et la couche SGBD SAP. Dans le cadre de votre évaluation, considérez ceci :

    • Le placement d’appliances virtuelles réseau sur le chemin d’accès de communication entre l’application SAP et la couche SGBD de systèmes SAP NetWeaver, Hybris ou S/4HANA basés sur SAP n’est pas pris en charge.
    • Le placement d’une couche Application SAP et d’un SGBD SAP sur différents réseaux virtuels Azure non appairés n’est pas pris en charge.
    • L’utilisation de groupes de sécurité d’application (ASG) et de groupes de sécurité réseau (NSG) Azure pour contrôler le flux de trafic entre la couche Application SAP et la couche SGBD SAP est prise en charge.

  3. Veillez à ce que les performances réseau accélérées Azure soient activées sur les machines virtuelles Azure utilisées dans la couche Application SAP et la couche SGBD SAP. Gardez à l’esprit la configuration requise du système d’exploitation pour la prise en charge des performances réseau accélérées dans Azure :

    • Windows Server 2012 R2 ou versions ultérieures.
    • SUSE Linux 12 SP3 ou versions ultérieures.
    • RHEL 7.4 ou versions ultérieures.
    • Oracle Linux 7.5. Le noyau RHCKL nécessite la version 3.10.0-862.13.1.el7. Le noyau Oracle UEK nécessite la version 5.

  4. Testez et évaluez la latence du réseau entre la machine virtuelle de la couche Application SAP et la machine virtuelle du SGBD conformément à la Note SAP 500235 et la Note SAP 1100926. Évaluez les résultats par rapport aux indications de latence réseau figurant dans la Note SAP 1100926. La latence du réseau doit être modérée à bonne.

  5. Vérifiez que les déploiements de l’équilibreur de charge interne Azure sont configurés pour utiliser Retour direct du serveur. Ce paramètre permet de réduire la latence dans les cas où les équilibreurs de charge sont utilisés pour des configurations de haute disponibilité sur la couche SGBD.

  6. Si vous utilisez Azure Load Balancer conjointement avec des systèmes d’exploitation invités Linux, vérifiez que le paramètre réseau Linux net.ipv4.tcp_timestamps est défini sur 0. Notez que cela contredit les recommandations générales de la Note SAP 2382421. La note SAP a été mise à jour pour indiquer que le paramètre doit être défini sur 0 pour être compatible les équilibreurs de charge Azure.

Déploiements de haute disponibilité et de reprise d’activité

  • Si vous déployez la couche Application SAP sans cibler des zones de disponibilité Azure spécifiques, vérifiez que toutes les machines virtuelles exécutant des instances de dialogue SAP ou des instances d’intergiciel du même système SAP sont déployées dans le même groupe à haute disponibilité.

    • Si vous n’avez pas besoin de la haute disponibilité pour les services SAP Central Services et le SGBD, ces machines virtuelles peuvent être déployées dans le même groupe à haute disponibilité que la couche Application SAP.

  • Si vous avez besoin de protéger SAP Central Services et la couche SGBD pour une haute disponibilité avec des réplicas passifs, déployez les deux nœuds pour SAP Central Services dans un groupe à haute disponibilité et les deux nœuds SGBD dans un autre groupe à haute disponibilité.

  • Si vous procédez à des déploiements dans des zones de disponibilité Azure, vous ne pouvez pas utiliser de groupes à haute disponibilité. Au lieu de cela, vous devez veiller à déployer les nœuds Central Services actifs et passifs dans deux zones de disponibilité différentes qui offrent la plus petite latence entre zones.

  • N’oubliez pas que vous devez utiliser Azure Load Balancer Standard lors de la création de clusters de basculement basés sur Windows Server ou Pacemaker pour la couche SGBD et SAP Central Services dans les zones de disponibilité. Load Balancer Essentiel ne prend pas en charge les déploiements dans les zones.

Paramètres liés au délai d'expiration

  • Consultez les rapports des développeurs de SAP NetWeaver pour les instances SAP et vérifiez qu’il n’y a pas d’interruptions de connexion entre le serveur de mise en file d’attente et les processus de travail SAP. Ces interruptions de connexion peuvent être évitées en définissant les deux paramètres de registre suivants.

    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Pour plus de détails, voir KeepAliveTime.
    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Pour plus de détails, voir KeepAliveInterval.

  • Pour éviter les dépassements de délai d’expiration de l’interface graphique utilisateur entre les interfaces graphiques SAP locales et les couches Application SAP déployées dans Azure, définissez les paramètres suivants dans le fichier default.pfl ou dans le profil d’instance :

    • rdisp/keepalive_timeout = 3600
    • rdisp/keepalive = 20

  • Si vous utilisez un clustering de basculement Windows, vérifiez que les paramètres déterminant le basculement déclenché par des nœuds non réactifs sont définis correctement. L’article Microsoft TechCommunity Tuning Failover Cluster Network Thresholds énumère les paramètres et leur impact sur le comportement du basculement. Par exemple, en supposant que les nœuds de cluster se trouvent dans le même sous-réseau, veillez à configurer les paramètres de basculement de la manière suivante :

    • SameSubNetDelay = 2000

    • SameSubNetThreshold = 15

    • RoutingHistorylength = 30

    • Tester la haute disponibilité et les procédures de reprise d’activité :

      • Simulez un basculement en arrêtant des machines virtuelles Azure (systèmes d’exploitation invités Windows) ou en plaçant les systèmes d’exploitation en mode panique (systèmes d’exploitation invités Linux).

      • Mesurez le temps nécessaire à la réalisation des basculements. Si les délais sont trop longs, tenez compte des éléments suivants :

        • Pour SUSE Linux, utilisez des appareils SBD au lieu de l’agent Azure Fencing pour accélérer le basculement.
        • Par SAP HANA, si le rechargement des données prend trop de temps, envisagez d’améliorer les performances du stockage.

      • Testez la séquence et les temps de sauvegarde et de restauration, et améliorez-les si nécessaire. Ne vérifiez pas seulement les temps de sauvegarde. Testez également la restauration et prenez le temps de restaurer les activités. Vérifiez que les délais de restauration sont conformes à vos contrats SLA RTO lorsque votre RTO s’appuie sur un processus de restauration de base de données ou de machine virtuelle.

      • Testez l’architecture et la fonctionnalité de reprise d’activité.

4. Effectuez des contrôles de la sécurité

  • Testez la validité de l’approche du contrôle d’accès en fonction du rôle Azure que vous avez implémentée. L’objectif est de séparer et de limiter l’accès et les autorisations déléguées aux différentes équipes. Par exemple, les membres de l’équipe SAP Basis doivent pouvoir déployer des machines virtuelles Azure sur un réseau virtuel Azure donné et affecter des disques à ces machines virtuelles Azure. Cependant, l’équipe SAP Basis ne doit pas être en mesure de créer des réseaux virtuels ou de changer les paramètres des réseaux virtuels existants. À l’inverse, les membres de l’équipe réseau ne doivent pas être en mesure de déployer des machines virtuelles Azure dans des réseaux virtuels où des machines virtuelles SGBD et l’application SAP sont exécutées. Les membres de cette équipe réseau ne doivent pas non plus être en mesure de modifier les attributs des machines virtuelles ou de supprimer des machines virtuelles et leurs disques.
  • Vérifiez que les règles NSG fonctionnent comme prévu et protègent effectivement les ressources protégées.
  • Vérifiez le chiffrement au repos et en transit. Définissez et implémentez des processus pour sauvegarder, stocker et accéder aux certificats, et vérifiez le processus de restauration des entités chiffrées.
  • Utilisez Azure Disk Encryption pour les disques de système d’exploitation.
  • Adoptez une approche pragmatique pour décider s’il faut implémenter un mécanisme de chiffrement. Par exemple, déterminez s’il est nécessaire d’appliquer à la fois le chiffrement Azure Disk encryption et le chiffrement Transparent Data Encryption pour SGBD.

5. Test des performances

Dans les scénarios de migration, utilisez le suivi et les mesures SAP pour comparer le pilote avec l’implémentation actuelle, en fonction des éléments suivants :

  • Les 10 principaux rapports en ligne
  • Les 10 principaux travaux par lots
  • Les transferts de données via des interfaces dans le système SAP, en vous concentrant sur le trafic entre les sites locaux