Ou est-ce possible ? Bien entendu, la migration des systèmes SAP est un processus complexe et laborieux, dont le succès nécessite le travail bien coordonné de tous les participants. Et si la migration s’effectue dans un délai court, la tâche devient bien plus compliquée. Tout le monde ne décide pas de faire cela. Il peut y avoir plusieurs raisons. Par exemple, le processus lui-même est long et complexe sur le plan organisationnel. De plus, il existe un risque d’arrêt imprévu du système. Ou les clients ne sont pas sûrs qu'après avoir subi une telle opération, ils recevront des bénéfices à la hauteur des efforts déployés. Il existe cependant des exceptions.
Sous la coupe, nous parlerons des difficultés auxquelles les clients sont confrontés lors du processus de migration et de maintenance des systèmes SAP, expliquerons pourquoi les stéréotypes ne correspondent pas toujours à la réalité et partagerons une étude de cas sur la façon dont nous avons réussi à migrer les systèmes d'un client vers un nouvelle infrastructure en un peu plus de trois mois.
Hébergement de systèmes SAP
Il y a seulement cinq ans, il était difficile d'imaginer que les clients commenceraient massivement à utiliser des ressources d'hébergement pour les applications SAP. Dans la plupart des cas, ils ont été mis en œuvre sur site. Cependant, avec le développement des modèles d’externalisation et du marché des services cloud, la vision du monde des clients a commencé à changer. Quels sont les arguments qui influencent le choix en faveur du cloud pour SAP ?
- Pour les débutants qui viennent d'envisager de mettre en œuvre SAP, l'infrastructure cloud est presque un choix standard - évolutivité des ressources selon les besoins actuels du système et réticence à consacrer des ressources au développement de compétences non essentielles.
- Dans les entreprises disposant d'un vaste paysage système, grâce à l'hébergement de 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 argument le plus courant 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 – le fournisseur a annoncé la fin du support des systèmes existants en 2027. Cela implique de transférer la base de données vers HANA, ce qui entraîne des coûts de modernisation et d'achat de nouvelle puissance de calcul.
Le marché de l'hébergement SAP en Russie peut désormais être considéré comme assez mature. Et cela offre de nombreuses opportunités aux clients qui souhaitent changer de plateforme d’hébergement. Cependant, de tels projets peuvent à juste titre inquiéter les entreprises en raison de la complexité de la procédure de migration. Cela oblige les clients à imposer des exigences accrues aux prestataires de services, qui doivent non seulement disposer de compétences exceptionnelles en matière d'hébergement et de maintenance des systèmes SAP, mais également d'une expérience réussie dans le domaine de la migration.
Quelles sont les difficultés de changer d’hébergement SAP ?
Les hébergements sont différents. Incohérence avec le niveau de service déclaré, nombreux « mais » et astérisques avec réserves en petit texte, ressources et capacités limitées de l'hébergeur, manque de flexibilité en matière de communication avec le client, bureaucratie, limitations techniques, faible compétence du support technique spécialistes, ainsi que de nombreuses autres nuances - ce ne sont là que quelques-uns des pièges que les clients peuvent rencontrer lorsqu'ils exploitent leurs systèmes d'entreprise dans des infrastructures d'externalisation. Souvent, pour le client, tout cela reste dans l'ombre, dans la jungle d'un contrat de plusieurs pages, et émerge au cours du processus d'utilisation des services.
À un moment donné, il devient évident pour le client que le niveau de service qu'il reçoit est loin de ses attentes. C'est une sorte de catalyseur pour trouver des solutions pour corriger la situation et, en cas d'échec, lorsque les problèmes s'accumulent jusqu'à la limite et que cela devient très douloureux, ils passent à des actions actives pour développer des options alternatives dans le sens d'un changement de prestataire de services. .
Pourquoi attendent-ils la dernière minute ? La raison est simple : le processus de migration des systèmes pour les clients n'est pas toujours transparent et compréhensible. Il est difficile pour le client d'évaluer les risques réels associés au processus de migration. On peut dire que la migration pour les clients est une sorte de boîte noire : on ne sait pas clairement le prix, les temps d'arrêt du système, les risques et comment les atténuer, et en général c'est sombre et effrayant. C'est comme si ça ne marchait pas, alors les têtes rouleraient à la fois au sommet et chez les interprètes.
SAP est un système d'entreprise, complexe et, pour le moins, pas bon marché. Des budgets décents sont consacrés à leur mise en œuvre, à leur modification et à leur maintenance, et la durée de vie de l'entreprise dépend de leur disponibilité et de leur bon fonctionnement. Imaginez maintenant les conséquences de l’arrêt d’une production importante. Il s'agit de pertes financières, qui peuvent être calculées en nombres comportant un grand nombre de zéros, ainsi que de risques de réputation et d'autres risques tout aussi importants.
Nous analyserons les difficultés qui peuvent survenir à chaque étape dans le cas d'une migration des systèmes SAP d'un de nos clients.
Préparation et conception
La migration est une formule comportant de nombreux éléments différents. Et l’une des plus importantes est l’étape de conception et de préparation de la (nouvelle) infrastructure cible.
Nous devions nous plonger dans la mise en œuvre existante des systèmes, leur architecture. Dans l'infrastructure cible, nous avons répété quelque part les solutions existantes, les avons complétées et améliorées à certains moments, les avons refaites quelque part, réfléchi et sélectionné des solutions pour garantir la tolérance aux pannes et la disponibilité, et avons également consolidé toutes les ressources autant que possible.
Au cours du processus de conception, de nombreux exercices différents ont été réalisés, ce qui a finalement permis de préparer au maximum la migration et de prendre en compte toutes sortes de nuances et d'embûches (nous y reviendrons plus tard).
Nous avons finalement obtenu une infrastructure de cloud privé conçue individuellement et basée sur notre centre de données :
- serveurs physiques dédiés pour SAP HANA ;
- Plateforme de virtualisation VMware pour serveurs d'applications et services d'infrastructure ;
- canaux de communication dupliqués entre les centres de données pour le VPN L2 ;
- deux systèmes de stockage principaux pour séparer le produit et « tout le reste » ;
- SRC basé sur Veritas Netbackup avec un serveur, une étagère de disques et une bibliothèque de bandes séparés.
Et voici comment nous avons mis en œuvre tout cela d'un point de vue technique.
SAP
- Pour utiliser efficacement le stockage pour HANA productif, nous avons utilisé des disques partagés sans réplication systémique de base de données à l'aide de SAP. Tout cela était intégré dans un cluster SUSE HAE actif-veille basé sur Pacemaker. Oui, le temps de récupération est un peu plus long qu’avec la réplication, mais nous économisons de moitié l’espace de stockage et, par conséquent, économisons le budget du client.
- Dans les environnements de pré-production, les clusters HANA ont été abandonnés, mais techniquement, la configuration de production a été répétée.
- Les environnements de test et de développement ont été répartis sur plusieurs serveurs supplémentaires sans clusters dans une configuration MCOS.
- Tous les serveurs d'applications étaient virtualisés et hébergés chez VMware.
réseau
- Nous avons physiquement séparé les contours des réseaux de contrôle et de production avec des piles de commutateurs, orientant les plus productifs vers les centres de données du client.
- Nous avons installé un nombre suffisant d'interfaces réseaux pour ne pas mélanger de gros flux de trafic.
- Pour transférer les données des systèmes de stockage, nous avons réalisé des usines FC SAN classiques.
Espace de rangement
- La charge productive et préproductive de SAP a été laissée sur la baie XNUMX % Flash.
- Les environnements de test des développeurs et les services d'infrastructure ont été placés sur une baie hybride distincte.
SCI
- Réalisé avec Veritas Netbackup.
- Nous avons ajouté un peu aux scripts intégrés pour sauvegarder les configurations MCOS.
- Nous plaçons des copies opérationnelles sur une étagère de disques pour une récupération rapide et nous utilisons des bandes pour le stockage à long terme.
Surveillance
- Tout le matériel, le système d'exploitation et SAP ont été installés sous Zabbix.
- Nous avons rassemblé de nombreux tableaux de bord utiles dans Grafana.
- Lorsqu'une alerte se produit, Zabbix peut créer une requête dans le système de gestion des incidents ; nous l'avons implémentée dans Jira. Les informations sont également dupliquées dans la chaîne Telegram.
Telegram
État de santé général de HANA
Statut du serveur d'applications SAP :
Services d'infrastructures
- Pour gérer les espaces de noms internes, un cluster de serveurs DNS a été créé, qui est synchronisé avec les serveurs du client.
- Nous avons créé un serveur de fichiers distinct pour l'échange de données.
- Pour stocker diverses configurations, Gitlab a été ajouté.
- Pour diverses informations sensibles, nous avons utilisé HashiCorp Vault.
Processus de migration
En général, le processus de migration comprend les étapes suivantes :
- préparation de toute la documentation nécessaire au projet ;
- négociations avec le fournisseur actuel - résolution des problèmes d'organisation ;
- achat, livraison et installation de nouveaux équipements pour le projet ;
- tester la migration et le débogage des processus ;
- transfert de systèmes, lutte contre la migration.
Fin octobre 2019, nous avons signé un contrat, puis conçu l'architecture, et après accord avec le client, nous avons commandé le matériel nécessaire.
Ce à quoi vous devez d’abord prêter attention, c’est le délai de livraison du matériel. En moyenne, la livraison du matériel certifié pour SAP NAHA qui répond aux exigences du fabricant de logiciels en matière de plates-formes matérielles prend 10 à 12 semaines. Et compte tenu de la saisonnalité (la mise en œuvre du projet tombait exactement au nouvel an), cette période aurait pu augmenter d'un mois supplémentaire. Il a donc fallu accélérer le processus autant que possible : 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).
Novembre et décembre ont été consacrés à la préparation de la migration et à la réception d'une partie du matériel. Nous avons effectué la préparation sur un banc de test dans notre cloud public, où nous avons parcouru toutes les étapes principales et détecté d'éventuelles difficultés et problèmes :
- préparé un plan détaillé pour l'interaction entre les membres de l'équipe de projet avec des horaires minute par minute ;
- construit un banc de test pour les serveurs de base de données et d'applications à peu près de la même manière que dans l'infrastructure cible ;
- configuré les canaux de communication et les services d'infrastructure nécessaires pour tester le fonctionnement des intégrations ;
- élaboration de scénarios de basculement ;
- Le cloud nous a également aidé à créer des modèles de machines virtuelles préconfigurés, que nous avons ensuite simplement importés et déployés dans le paysage cible.
Peu avant les vacances du Nouvel An, le premier lot de matériel nous est arrivé. Cela a permis de déployer certains systèmes sur du matériel réel. Comme tout n'était pas arrivé, nous avons connecté du matériel de remplacement, dont nous avons réussi à convenir avec le vendeur et les distributeurs. Nous avons reçu les restes de l'infrastructure cible au stade final.
Pour respecter le délai, nos ingénieurs ont dû sacrifier les vacances du Nouvel An et commencer les travaux de préparation de l'infrastructure cible le 2 janvier, en pleine période des vacances. Oui, cela arrive parfois lorsqu’il est en feu et qu’il n’y a tout simplement pas d’autres options. L’enjeu était la performance des systèmes dont dépend la vie de l’entreprise.
L'ordre général de migration ressemblait à ceci : d'abord, les systèmes les moins critiques (paysage de développement, paysage de tests), puis les systèmes productifs. La dernière étape de la migration a eu lieu fin janvier et début février.
Le processus de migration a été planifié à la minute près. Il s'agit d'un plan de transition avec une liste de toutes les tâches, du temps d'exécution et des personnes responsables. Toutes les étapes avaient déjà été élaborées lors de la migration test. Lors de la migration en direct, il suffisait donc de suivre le plan et de coordonner le processus.
La migration s'est effectuée systématiquement en plusieurs étapes. Il existe deux systèmes à chaque étape.
Le résultat d'un sprint de trois mois a été un système pleinement opérationnel dans le centre de données CROC. En général, un résultat positif a été obtenu grâce au travail d'équipe, la contribution et le dévouement de tous les participants au processus ont été maximaux.
Le rôle du client dans le projet
Communiquer avec le prestataire que notre client quittait n'était pas facile. C'est compréhensible, ils étaient les derniers sur la liste des personnes intéressées par la réussite du projet. Le client a pris la tâche de remonter et de régler tous les problèmes de communication et a fait face à cela à 100500 XNUMX %. Un merci spécial à lui pour cela. Sans une telle participation possible au processus, le résultat du projet aurait pu être complètement différent.
En raison de la formalisation des processus du côté de «l'ancien» fournisseur, le support de l'infrastructure a été assuré par des spécialistes qui étaient littéralement loin des problèmes, alors encore leur client. Par exemple, le processus d’exportation de la même base de données peut prendre entre une heure et cinq heures. Ensuite, il a semblé que c'était une sorte de magie, un secret qui ne nous a jamais été révélé. Probablement, les ingénieurs du support technique se sont laissés aller à méditer entre-temps, oubliant que quelque part dans la lointaine Russie il y a des délais, les ingénieurs sans salades du Nouvel An, le client pleure et souffre...
Résultats du projet
La dernière étape de la migration était le transfert des systèmes pour maintenance.
Nous fournissons désormais un service de guichet unique pour les demandes des clients et couvrons l'ensemble des tâches liées au support des composants d'infrastructure et de la base SAP en collaboration avec notre partenaire - itelligence. Le client vit dans un cloud privé depuis six mois. Voici les statistiques sur les cas de service pendant cette période :
- 90 incidents (20 % résolus sans impliquer le client)
- Résolu dans le cadre du SLA – 100 %
- Arrêts imprévus du système – 0
Si vous rencontrez des problèmes similaires à ceux de notre client et que vous souhaitez en savoir plus sur la manière de les résoudre, écrivez à : [email protected]
Source: habr.com