Ou c'est possible ? Bien sûr, la migration des systèmes SAP est un processus complexe et laborieux dont le succès repose sur la collaboration harmonieuse de tous les participants. Et si la migration doit se faire dans un délai réduit, la tâche est considérablement compliquée. Tout le monde n'ose pas s'y lancer. Les raisons peuvent être diverses. Par exemple, le processus lui-même est long et organisationnellement complexe. De plus, il y a un risque d'arrêts non planifiés des systèmes. Ou les clients ne sont pas sûrs que, après une telle opération, ils obtiendront des bénéfices proportionnels aux efforts fournis. Cependant, il y a des exceptions.
Dans cet article, nous parlerons des difficultés auxquelles les clients sont confrontés lors de la migration et de l'accompagnement des systèmes SAP, nous discuterons des raisons pour lesquelles les stéréotypes ne correspondent pas toujours à la réalité, et nous partagerons un cas où nous avons réussi à migrer les systèmes d'un client vers une nouvelle infrastructure en un peu plus de trois mois.
Hébergement des systèmes SAP
Il y a à peine cinq ans, il était difficile d'imaginer que les clients commenceraient à utiliser massivement des ressources d'hébergement pour des applications SAP. Dans la plupart des cas, elles étaient mises en œuvre sur site. Cependant, avec le développement des modèles d'externalisation et du marché des services cloud, la mentalité des clients a commencé à évoluer. Quels sont les arguments qui influencent le choix du cloud pour SAP ?
- Pour les débutants qui viennent tout juste de planifier l'implémentation de SAP, une infrastructure cloud est pratiquement un choix standard — la flexibilité des ressources en fonction des besoins actuels du système et le désir de ne pas détourner des ressources pour développer des compétences non essentielles.
- Dans les entreprises avec un large paysage système, grâce à l'hébergement des systèmes SAP, les DSI atteignent un niveau de gestion des risques qualitativement différent, car le partenaire est responsable du SLA.
- Le troisième des arguments les plus souvent cités est le coût élevé de la construction d'une infrastructure pour mettre en œuvre des scénarios de haute disponibilité et de reprise après sinistre.
- Facteur 2027 — l'annonce par le fournisseur de la fin du support pour les systèmes obsolètes en 2027. Cela signifie le transfert de la base de données vers HANA, ce qui entraîne des coûts liés à la modernisation et à l'achat de nouvelles capacités de calcul.
Le marché de l'hébergement SAP en Russie peut désormais être considéré comme assez mature. Cela offre de nombreuses possibilités aux clients souhaitant changer de plateformes d'hébergement. Cependant, de tels projets peuvent légitimement susciter des inquiétudes au sein des entreprises en raison de la complexité du processus de migration. Cela amène les clients à formuler des exigences plus strictes envers les fournisseurs de services, qui doivent posséder non seulement des compétences exceptionnelles en matière d'hébergement et de support des systèmes SAP, mais aussi une expérience réussie en matière de migration.
Quelles sont les difficultés liées au changement d'hébergement SAP ?
Il existe différents types d'hébergements. Le non-respect du niveau de service annoncé, de nombreux « mais » et astérisques avec des restrictions en petits caractères, la limitation des ressources et des capacités fournisseur d'hébergement, l'absence de flexibilité dans la communication avec le client, la bureaucratie, les limitations techniques, la faible compétence des spécialistes du support technique, ainsi que de nombreux autres détails — ce n'est là qu'une petite partie des écueils que les clients peuvent rencontrer lors de l'exploitation de leurs systèmes d'affaires dans des infrastructures externalisées. Souvent, tout cela reste dans l'ombre pour le client, enfoui dans les méandres d'un contrat pluriannuel, et éclate au grand jour seulement lorsqu'ils utilisent les services.
À un moment donné, il devient évident pour le client que le niveau de service qu'il reçoit est éloigné de ses attentes. Cela sert de catalyseur à la recherche de solutions pour rectifier la situation et, en cas d'échec, lorsque les problèmes s'accumulent à un point tel qu'ils deviennent insupportables, ils passent à des actions concrètes pour explorer des alternatives en vue de changer de fournisseur de services.
Pourquoi attendre jusqu'à la dernière minute ? La raison est simple : le processus de transfert des systèmes n'est pas toujours transparent et compréhensible pour les clients. Il est difficile pour le client d'évaluer les véritables risques liés au processus de migration. On pourrait dire que la migration pour les clients est une sorte de boîte noire : on ne sait pas le coût, le temps d'arrêt des systèmes, les risques et comment les atténuer, et c'est généralement obscur et effrayant. Si cela ne fonctionne pas, la tête des dirigeants et des exécutants risque de tomber.
SAP est un système de niveau entreprise, complexe et disons le franchement, coûteux. Des budgets considérables sont alloués à son implantation, son développement et son support, et la disponibilité ainsi que le bon fonctionnement de ces systèmes sont essentiels pour la viabilité d'une entreprise. Imaginez maintenant les conséquences d'un arrêt de production dans une grande usine. Ce sont des pertes financières qui peuvent s'élever à des millions, sans oublier les risques réputationnels et d'autres dangers tout aussi significatifs.
Analysons les difficultés qui peuvent survenir à chaque étape à travers le cas de migration des systèmes SAP d'un de nos clients.
Préparation et conception
La migration est une formule avec de nombreuses composantes différentes. L'une des plus importantes est le processus de conception et de préparation de l'infrastructure cible (nouvelle).
Nous devions nous plonger dans l'implémentation existante des systèmes, leur architecture. Dans l'infrastructure cible, nous avons en partie reproduit les solutions existantes, amélioré certaines d'entre elles et dans d'autres cas, repensé et choisi des solutions pour assurer la résilience et la disponibilité, tout en consolidant au maximum toutes les ressources.
Au cours de la phase de conception, de nombreux exercices ont été réalisés, permettant d'être au mieux préparé à la migration et de prendre en compte toutes les nuances et pièges (dont nous parlerons plus tard).
Voici ce que nous avons finalement obtenu : une infrastructure cloud privé conçue sur mesure basée sur notre centre de données :
- serveurs physiques dédiés pour SAP HANA;
- plateforme de virtualisation VMware pour les serveurs d'applications et les services d'infrastructure;
- canaux de communication redondants entre les centres de données pour le L2; VPN;
- deux systèmes de stockage principaux pour séparer la production et "tout le reste";
- solution de sauvegarde basée sur Veritas Netbackup avec un serveur séparé, une baie de disques et une bibliothèque de bandes.
Voici comment nous avons réalisé tout cela d'un point de vue technique.
SAP
- Pour une utilisation efficace des stockages pour HANA en production, nous avons utilisé des disques partagés sans réplication de base de données par les moyens de SAP. Tout cela a été emballé dans un cluster Active-Standby SUSE HAE basé sur Pacemaker. Oui, le temps de récupération est un peu plus long qu'avec la réplication, mais cela nous permet d'économiser deux fois plus d'espace de stockage et par conséquent, de réduire le budget du client.
- Dans les environnements préproductifs, les clusters HANA ont été abandonnés, mais la configuration de production a été techniquement reproduite.
- Les environnements de test et de développement ont été répartis sur plusieurs serveurs sans clusters dans la configuration MCOS.
- Tous les serveurs d'applications ont été virtualisés et hébergés dans VMware.
Réseaux
- Les contours des réseaux de gestion et des réseaux de production ont été physiquement séparés par des piles de commutateurs, en orientant les réseaux de production vers le centre de données du client.
- Un nombre suffisant d'interfaces réseau a été prévu pour ne pas mélanger les gros flux de trafic.
- Pour la transmission des données du stockage SAN, des usines FC SAN classiques ont été mises en place.
SAN
- La charge productive et préproductive de SAP a été laissée sur un système all-flash.
- Les environnements de test des développeurs et les services d'infrastructure ont été placés sur un ensemble hybride séparé.
PDU
- Cela a été réalisé sur la base de Veritas Netbackup.
- Nous avons ajouté quelques scripts intégrés pour sauvegarder les configurations MCOS.
- Les copies actives ont été placées sur une étagère de disques pour une récupération rapide, tandis que pour le stockage à long terme, nous utilisons des bandes.
Surveillance
- Tout le matériel, les systèmes d'exploitation et SAP ont été intégrés sous Zabbix.
- Nous avons rassemblé de nombreux tableaux de bord utiles dans Grafana.
- En cas d'alerte, Zabbix peut créer un ticket dans le système de gestion des incidents, qui est réalisé sur Jira. Les informations sont également doublées dans un canal Telegram.
Telegram
État général de HANA
État du serveur d'applications SAP :
Services d'infrastructure
- Pour gérer les espaces de noms internes, nous avons mis en place un cluster de serveurs DNS qui se synchronise avec les serveurs du client.
- Un serveur de fichiers séparé a été créé pour l'échange de données.
- Pour stocker différentes configurations, nous avons ajouté Gitlab.
- Pour divers sensitive informations, nous avons pris HashiCorp Vault.
Processus de migration
En général, le processus de migration se compose des étapes suivantes :
- préparation de toute la documentation de projet nécessaire ;
- négociations avec le fournisseur actuel — résolution des questions organisationnelles ;
- achat, livraison et installation du nouveau matériel pour le projet ;
- migration de test et réglage du processus ;
- transfert des systèmes, migration de production.
À la fin d'octobre 2019, nous avons signé le contrat, puis nous avons conçu l'architecture, et après son approbation par le client, nous avons commandé le matériel nécessaire.
Les délais de livraison de l'équipement sont la priorité. En moyenne, la livraison de matériel certifié pour SAP NAHA, conforme aux exigences du fournisseur logiciel concernant les plates-formes matérielles, prend entre 10 et 12 semaines. Compte tenu de la saisonnalité (la réalisation du projet coïncidait avec le Nouvel An), ce délai pouvait encore être prolongé d'un mois. Il était donc nécessaire d'accélérer le processus au maximum : nous avons travaillé avec le distributeur-fournisseur et convenu d'une livraison accélérée par avion (au lieu de routes terrestres et maritimes).
Les mois de novembre et décembre ont été consacrés à la préparation de la migration et à l'obtention d'une partie de l'équipement. La préparation a été effectuée sur un banc d'essai dans notre cloud public, où nous avons testé toutes les étapes principales et identifié les éventuelles difficultés et problèmes :
- nous avons élaboré un plan détaillé d'interaction des équipes de projet avec des horaires minutés ;
- nous avons construit un banc d'essai pour les bases de données et les serveurs d'applications de manière similaire à l'infrastructure cible ;
- nous avons configuré les canaux de communication nécessaires et les services d'infrastructure pour tester le fonctionnement des intégrations ;
- nous avons travaillé sur des scénarios de cutover ;
- le cloud nous a également aidés à créer des modèles de machines virtuelles préconfigurés que nous avons ensuite importés et déployés dans le paysage cible.
Peu avant les vacances de Nouvel An, la première partie de l'équipement est arrivée. Cela a permis de déployer une partie des systèmes sur du matériel réel. Comme nous n'avions pas tout reçu, nous avons branché du matériel de remplacement, dont la livraison avait été négociée avec le fournisseur et les distributeurs. Le reste de l'infrastructure cible a été reçu lors de la phase finale.
Pour respecter les délais, nos ingénieurs ont dû sacrifier leurs vacances de Nouvel An et commencer à préparer l'infrastructure cible le 2 janvier, en plein milieu des festivités. Oui, cela arrive parfois, quand l'urgence ne laisse pas d'autre choix. La viabilité des systèmes, sur lesquels dépend l'activité de l'entreprise, était en jeu.
Le processus global de migration était le suivant : en premier lieu, les systèmes les moins critiques (environnement de développement, environnement de test), puis les systèmes productifs. La phase finale de la migration s'est déroulée fin janvier-début février.
Le processus de migration a été planifié avec une précision minute par minute. Il s'agit d'un plan de coupure avec une liste de toutes les tâches, le temps d'exécution et les personnes responsables. Tous les étapes avaient déjà été testées lors de la migration de test, donc la migration en production nécessitait simplement de suivre le plan et de coordonner le processus.
La migration a été réalisée par système en plusieurs étapes. À chaque étape, deux systèmes.
Au terme de trois mois de sprint, nous avons obtenu un système entièrement fonctionnel dans le centre de données KROK. Dans l'ensemble, le résultat positif a été obtenu grâce au travail collectif, la contribution et l'engagement de tous les participants au processus ont été maximaux.
Le rôle du client dans le projet
Communiquer avec le fournisseur dont notre client se séparait n'était pas simple. C'est compréhensible, ils étaient les derniers sur la liste des parties intéressées à la réussite du projet. Le client a pris en charge les tâches d'escalade et de facilitation de toutes les questions de communication, réussissant à le faire à 100500%. Pour cela, un grand merci à lui. Sans une telle participation active dans le processus, le résultat du projet aurait pu être tout autre.
En raison de la formalisation des processus chez l'ancien fournisseur, le soutien de l'infrastructure était assuré par des spécialistes qui, en réalité, étaient éloignés des problèmes de leur ancien client. Par exemple, le processus d'exportation de la même base de données pouvait prendre de une heure à cinq. À l'époque, cela semblait être de la magie, un secret qui ne nous a jamais été révélé. Probablement, les ingénieurs du support technique, entre deux tâches, se livraient à la méditation, oubliant que là-bas en Russie, les délais, les ingénieurs sans salades de Nouvel An pleuraient et souffraient pour le client...
Résultats du projet
Le dernier acte de la migration a été le transfert des systèmes pour leur soutien.
Actuellement, nous offrons un service de guichet unique pour les demandes des clients et gérons l'ensemble des tâches liées à l'assistance des composants de l'infrastructure et de SAP Basis en collaboration avec notre partenaire — itelligence. Le client vit dans un cloud privé depuis six mois. Voici les statistiques des incidents de service durant ce temps :
- 90 incidents (20 % résolus sans impliquer le client)
- Résolus dans le cadre du SLA – 100%
- Arrêts imprévus des systèmes – 0
Si vous avez des tâches similaires à celles de notre client et souhaitez en savoir plus sur la manière de les résoudre, écrivez : ahaidukov@croc.ru
Source : habr.com
