The Day after Hana Going Live

Pour beaucoup, le passage à Hana et S/4 est un énorme changement, car ce n'est pas seulement la base de données qui change, mais aussi le système d'exploitation sous-jacent. L'exploitation actuelle et donc le manuel d'exploitation doivent être revus en profondeur.

C'est à partir de là que commence une thématique que beaucoup négligent souvent dans leurs projets, car le lien pratique avec le nouvel environnement fait également défaut pour de nombreux administrateurs, ce qui fait que certains pièges ne sont découverts que lors de la mise en œuvre.

La plupart du temps, il n'existe pas encore de concepts pour les paquets de travail que sont le provisionnement du système sous Linux, les copies du système avec Hana, la surveillance, le transport des objets Hana, les autorisations, les maintenances cycliques ou pour la vérification et la validation des nouvelles révisions Hana.

Il ne faut pas sous-estimer les efforts à fournir en matière de maintenance, car de nombreux composants ont des interdépendances qui n'ont pas dû être prises en compte auparavant.

Outre les restrictions connues de tous en matière de stockage, de serveurs et de systèmes d'exploitation, il existe d'autres limitations. Cela a pour conséquence que de nombreuses équipes (serveurs, système d'exploitation, bases de données, base SAP) doivent se concerter encore plus qu'avant.

Pour produire le moins de temps d'arrêt possible, il est recommandé de synchroniser les cycles de maintenance des composants. Dans le "Suse Linux Enterprise Server for SAP Applications" avec le support étendu pour le produit, Suse a déjà intégré cela avec beaucoup de succès.

Ici, par exemple, la fin de la maintenance de Hana 2 SPS01 a été couplée à SLES for SAP 12 SP1. Les prochaines échéances seront SLES for SAP 12 SP2 en avril 2019 et Hana 2 SPS02 en fin de maintenance.

Lors d'une telle maintenance, la question de la vérification technique et de la validation fonctionnelle se pose toujours. La plupart des utilisateurs clés n'ont guère de capacités pour les tests en plus du travail de projet et de l'exploitation normale. C'est là que la fonctionnalité "Capture & Replay", qui est gratuite - c'est-à-dire déjà incluse dans la licence Hana - entre en jeu.

Cela permet de reproduire 1:1 sur un autre système la charge de travail générée par les instructions SQL. Ainsi, si votre système ERP de production compte 2000 utilisateurs, vous pouvez exécuter à nouveau toutes les transactions dans un délai défini. Les seules conditions sont une sauvegarde du système de production ainsi qu'un enregistrement d'une telle période.

Cette sauvegarde est transférée sur un autre système, par exemple le système d'assurance qualité (QAS). Vous pouvez y reproduire plusieurs itérations de modifications (patch Hana/Linux, modifications de paramètres) et comparer les résultats à chaque passage, par exemple si les requêtes étaient plus rapides ou plus lentes, ou même si une erreur s'est produite.

Cette procédure permet de décharger les utilisateurs clés et même d'effectuer un test de charge avec des données productives, y compris 2000 utilisateurs ou plus. A la fin, le système ne doit pas être "éliminé", mais peut être réintroduit dans le paysage en tant que QAS avec les travaux ultérieurs de la copie du système. Il est donc très judicieux de coupler de tels travaux de maintenance à la planification existante des copies du système.

Que ne peut pas faire "Capture & Replay" ? Il n'est pas possible de tester un remplacement de noyau SAP ou un changement de version.

Conclusion

En raison de la complexité et des interdépendances des composants du système Hana, une automatisation partielle des tests s'impose. En raison des exigences croissantes, de la diminution du nombre de fenêtres de maintenance et des cycles de mise à jour serrés, une optimisation du processus de maintenance est plus que souhaitée.

Si l'on combine encore cela avec la procédure "Near Zero Downtime Maintenance" (Hana System Replication + DBSL Suspend) et un Rolling Kernel Switch (RKS), il serait possible d'effectuer des maintenances en semaine pratiquement sans impact sur l'utilisateur final.