Examiner les meilleures pratiques de migration de bases de données très volumineuses

Effectué

Les instructions suivantes contenues sont basées sur des projets clients réels et sur les apprentissages dérivés de ces projets. Les instructions identifient les scénarios qui ont échoué dans le passé. Par exemple, il est recommandé de ne pas utiliser des serveurs UNIX ou serveurs virtualisés en tant que serveurs d’exportation R3load :

• Souvent, le niveau de performance d’exportation sont un facteur déterminant sur les temps d’arrêt globaux. Souvent, le matériel actuel est âgé de plus de 4 à 5 ans et est prohibitif pour la mise à niveau.
• Vous devez donc obtenir les performances d’exportation maximales qu’il est possible d’atteindre.
• Les projets précédents ont demandé des heures ou des mois de travail pour régler le niveau de performance de l’exportation R3load sur UNIX ou sur des plateformes virtualisées, avant d’abandonner et d’utiliser des serveurs Intel R3load.
• Les serveurs Intel double sockets sont peu coûteux et offrent des gains de performances importants, dans certains cas, dans des ordres de grandeur supérieurs aux améliorations de réglage mineures possibles sur les serveurs UNIX ou virtualisés.
• Les clients ont souvent des batteries de serveurs de machines virtuelles existantes, mais elles ne prennent pas en charge les technologies modernes de déchargement ou de SR-IOV le plus souvent. La version VMware est souvent ancienne, non patchée ou n’est pas configurée pour un haut débit réseau et une faible latence. Les serveurs d’exportation R3load requièrent un niveau de performance de thread rapide et un débit réseau extrêmement élevé. Les serveurs d’exportation R3load peuvent s’exécuter pendant 10 à 15 heures à presque 100 % d’utilisation du processeur et du réseau. Ce n’est pas le cas d’usage classique de la plupart des batteries de serveurs VMware, et la plupart des déploiements VMware n’ont jamais été conçus pour gérer une charge de travail de type R3load.

Conseil

Ne consacrez pas du temps à l’optimisation du niveau de performance d’exportation R3load sur les plateformes UNIX ou virtualisées. En effet, vous gaspillerez non seulement du temps, mais cela coûtera beaucoup plus cher que d’acheter des serveurs Intel à faible coût au début du projet. Les clients de la migration de VLDB sont donc invités à s’assurer que l’équipe de projet dispose de serveurs d’exportation R3load modernes rapides et disponibles au début du projet. Cela réduit le coût total et le risque du projet.

Bonnes pratiques

• Enquêtez et inventoriez le paysage SAP actuel. Identifiez les niveaux de pack de support SAP et déterminez si une mise à jour corrective est nécessaire pour prendre en charge le SGBD cible. En général, la compatibilité du système d’exploitation est déterminée par le noyau SAP et la compatibilité du SGBD est déterminée par le niveau de patch SAP_BASIS.
• Créez une liste de notes OSS SAP qui doivent être appliquées dans le système source, comme les mises à jour de SMIGR_CREATE_DDL. Mettez à niveau les noyaux SAP dans les systèmes sources pour éviter un changement important pendant la migration vers Azure (par exemple, si un système exécute un ancien noyau 7.41, passez à la dernière version 7.45 sur le système source pour éviter un changement important pendant la migration).
• Développez et documentez la solution de haute disponibilité et de récupération d’urgence. La documentation doit décomposer la solution dans la couche de base de données, la couche ASCS et la couche du serveur d’applications SAP. Des solutions distinctes peuvent être nécessaires pour les solutions autonomes, comme TREX ou liveCache.
• Développez un document de configuration et de dimensionnement qui détaille les types de machine virtuelle Azure et la configuration du stockage. Nombre de disques Premium, nombre de fichiers de données, répartition des fichiers de données sur les disques, utilisation des espaces de stockage, taille de format NTFS = 64 Ko. En outre, la sauvegarde/restauration de documents et la configuration SGBD, telles que les paramètres de mémoire, le degré maximal de parallélisme et les indicateurs de traces.
• Développez un document de conception de réseau incluant la configuration de réseaux virtuels, de sous-réseaux, de groupes de sécurité réseau (NSG) et de routes définies par l’utilisateur (UDR).
• Documentez et implémentez le concept de sécurité et de renforcement. Supprimez Internet Explorer, créez un conteneur Active Directory pour les comptes de service SAP et les serveurs, puis appliquez une stratégie de pare-feu bloquant tout sauf un nombre limité de ports requis.
• Créer un document de conception pour la migration du système d’exploitation/base de données détaillant le concept de fractionnement de table et de package, nombre de R3loads, indicateurs de traces SQL Server, trié/non trié, paramètre RowID Oracle, SMIGR_CREATE_DDL, compteurs Perfmon (comme les lignes BCP/s et débit BCP ko/s, UC, mémoire), paramètres RSS, paramètres réseau accélérés, configuration du fichier journal, paramètres BPE, configuration de TDE.
• Créez un graphique « plan de vol » qui indique la progression de l’exportation/importation R3load sur chaque cycle de test. Cela permet à l’équipe de migration de valider si les réglages et les modifications améliorent le niveau de performance d’exportation ou d’importation R3load. L’axe des X est le nombre de packages terminés et l’axe des Y est la durée calendaire. Ce plan de vol est également critique au cours de la migration de production afin que la progression planifiée puisse être comparée à la progression réelle et à tout problème identifié en amont.
• Créez un plan de test de niveau de performance. Identifiez les 20 premiers rapports en ligne, travaux de traitement par lots et interfaces. Documentez les paramètres d’entrée (tels que la plage de dates, le bureau de vente, l’usine, le code de la société, etc.) et les runtimes sur le système source d’origine. Comparez au runtime sur Azure. S’il existe des différences du niveau de performance, exécutez SAT, ST05 et d’autres outils SAP pour identifier les instructions inefficaces.
• Auditez le déploiement et la configuration et assurez-vous que les délais d’attente du cluster, les noyaux, les paramètres réseau et la taille du format NTFS sont tous cohérents avec les documents de conception. Définissez des compteurs Perfmon sur des serveurs importants pour enregistrer les paramètres d’intégrité de base toutes les 90 secondes. Vérifiez que les serveurs SAP se trouvent dans un conteneur AD distinct et qu’une stratégie de groupe est appliquée au conteneur avec la configuration du pare-feu.
• Vérifiez que le consultant en migration du système d’exploitation/de la base de donne est concédé sous licence ! Demandez le nom du consultant, l’utilisateur s et la date de certification. Ouvrez un message OSS sur BC-INS-MIG et demandez à SAP de confirmer que le consultant est à jour et sous licence.
• Si possible, l’ensemble de l’équipe de projet est associé au projet de migration de VLDB au sein d’un emplacement physique et n’est pas dispersé géographiquement sur plusieurs continents et fuseaux horaires.
• Vérifiez que vous avez un plan de secours approprié et qu’il fait partie de la planification générale.
• Sélectionnez des modèles d’UC Intel du nombre de Threads rapides pour les serveurs d’exportation R3load. N’utilisez pas des modèles de processeur « économiseurs d’énergie », car ils ont des performances inférieures, et n’utilisez pas de serveurs à 4 sockets. Intel Xeon E5 Platinum 8158 est un bon exemple.

Bonnes pratiques pour éviter les problèmes

• Ne sous-traitez pas l’exportation et l’importation a des organisations de conseil différentes. Occasionnellement, le système source est externalisé et géré par un partenaire ou une organisation de conseil et un client souhaite migrer vers Azure et passer à un autre partenaire. Compte tenu du couplage étroit entre la configuration et le réglage de l’exportation et de l’importation, l’attribution de ces tâches à différentes organisations peut difficilement produire un résultat satisfaisant.
• Ne faites pas l’économie des ressources matérielles Azure pendant la migration et la mise en ligne. Les Machines Virtuelles Azure sont facturées par minute et peuvent être réduites facilement. Pendant une migration de VLDB, utilisez la machine virtuelle la plus puissante disponible. Les clients se sont mis en ligne sur des systèmes surdimensionnés à 200-250 %, puis se sont stabilisés sur ces systèmes surdimensionnés. Après le monitoring de l’utilisation du système pendant 4 à 6 semaines, les machines virtuelles qui ont une capacité excédentaire sont réduites en taille ou arrêtées pour réduire les coûts.