Il y a plus de 10 ans, Microsoft a annoncé la disponibilité de la plate-forme Azure à un large public d'utilisateurs. Pendant ce temps, de nombreuses entreprises souhaitaient profiter de l'infrastructure cloud pour résoudre les problèmes informatiques actuels. Certains d'entre eux nous ont contactés pour obtenir des conseils sur le déploiement de systèmes dans le cloud. Mais le temps a passé et l'entreprise envisage maintenant la possibilité de placer des systèmes gourmands en ressources tels que SAP HANA dans les nuages. Nous, à notre tour, avons déjà mis en œuvre plusieurs projets similaires et sommes prêts à partager ces observations qui peuvent assurer un déploiement plus réussi du système SAP dans le cloud MS Azure. Certaines observations ne seront pas une découverte, mais nous voulions montrer l'applicabilité de certaines approches dans une plateforme cloud. Nous voulons partager les principales leçons apprises avec vous.
# 1: Optimiser systématiquement l'architecture informatique à l'aide du cloud
Dans le cadre de la migration d'un système productif, nous avons été confrontés au problème de la consommation élevée de ressources dans les processus de test et de développement, ce qui nous a finalement amenés à réfléchir aux raisons pour lesquelles nous avons besoin de tant de ressources pour l'environnement de test et de développement et à la façon d'optimiser la consommation des ressources d'infrastructure par un système productif.
L'approche recommandée pour créer un système SAP est basée sur une évaluation de la capacité requise à l'aide du calculateur SAP Quick Sizer. Jusqu'à présent, les méthodologies SAP reposent sur des approches standards qui ne prennent pas en compte les particularités des technologies cloud. Nous avons reçu les exigences du client, saisi les données initiales dans les estimateurs SAP et reçu une configuration préliminaire du paysage. Dans le cas des infrastructures classiques, il était possible de s'arrêter là et de passer à l'achat de matériel, mais dans notre cas, il était possible de profiter du cloud. Dans le cloud, les ressources peuvent être augmentées à tout moment, c'est pourquoi nous avons abandonné la réserve de ressources excédentaire incluse dans l'estimateur et déployé des machines moins performantes. Cela a permis de réduire les coûts,et à mesure que la charge augmente, nous pouvons toujours augmenter les performances des machines virtuelles SAP en quelques minutes.
Microsoft fournit un support SAP uniquement sur les machines virtuelles de la série M. L'utilisation de ressources de test similaires à l'environnement de production en termes de niveau de support au stade initial du développement nous a semblé redondante.
Dans le même temps, les machines de la série E ont des caractéristiques similaires à celles de la série M, mais leur coût est nettement inférieur. En conséquence, nous avons remplacé les machines de test par la série E. L'inconvénient de ce remplacement est le transfert de la responsabilité de l'exploitation du système dans les environnements de test du fournisseur à l'intégrateur. Cela impose à l'intégrateur d'avoir une expertise SAP.
# 2: Comment économiser sur la consommation de ressources
MS Azure vous permet d'économiser de manière significative lors de la réservation de ressources avec un prépaiement simultané pendant un ou 3 ans.
Souvent, au stade initial, le client ne peut pas estimer avec précision la date de lancement d'un système productif, car son développement et ses tests sont souvent associés à de nombreuses variables qui sont du côté des développeurs de l'entreprise ou des entrepreneurs.
Par exemple, lors du lancement de l'un des projets, nous avons planifié le déploiement simultané de tous les environnements en fonction des plans actuels du Client. Comme c'est souvent le cas, le développement a nécessité une coordination plus longue avec l'entreprise, ce qui a retardé le lancement productif de plusieurs mois.
Dans cet exemple, une réservation de ressources prépayées entraînerait une perte importante de fonds par le client. Bien sûr, il est nécessaire de réserver des ressources, mais il est plus efficace de le faire aux stades ultérieurs du projet, lorsque l'essentiel du système productif s'est stabilisé et que le développement est devenu prévisible en termes de consommation de ressources. Souvent, lorsque vous réservez des ressources informatiques pendant 3 ans, vous pouvez réaliser environ 70% d'économies par rapport au mode de paiement Pay-As-You-Go.
# 3: Comment choisir une région Azure
Azure dispose d'un large éventail de régions d'hébergement de ressources. L'un des principaux critères de choix d'une région est l'éloignement de votre infrastructure des utilisateurs finaux, ce qui affecte la réponse du système et le fonctionnement des intégrations et des utilisateurs finaux.
Le deuxième critère, non moins important, est la liste des services dans une région particulière.
Certains services sont disponibles selon la région. Très souvent, les services sont fournis en avant-première avant la sortie officielle. Certaines régions introduisent plus rapidement de nouvelles technologies et permettent de tester l'un ou l'autre des services émergents. Toutes les régions n'offrent pas la possibilité d'utiliser la gamme complète des séries de machines virtuelles.
Dans notre pratique, la comparaison des vitesses d'accès montre souvent l'avantage de la région Europe de l'Ouest. Cela est particulièrement visible pour les entreprises dont les serveurs et les clients sont situés dans la partie européenne de la Russie. Dans chaque cas, et surtout si vos centres de données et clients sont situés en Extrême-Orient, il est judicieux de vérifier les retards depuis votre centre de données (ou depuis la région géographique où se trouvent vos clients) pour sélectionner la meilleure région Azure.
Des services tels que Azure Latency Test vous permettent de tester de manière proactive la latence dans chacune de vos régions Azure à partir de votre réseau de centre de données. Un exemple des résultats de la mesure de la latence à l'aide du service mentionné lors des tests depuis notre bureau de Moscou:
# 4: Comment appliquer des méthodes basées sur le sol aux installations cloud
A chaque migration, on se pose la question de savoir comment utiliser des solutions traditionnelles éprouvées par une infrastructure classique dans le cloud. En particulier, lors de la préparation d'une solution, nous nous appuyons sur les recommandations du fournisseur pour développer une solution techniquement correcte. Les projets SAP HANA ne font pas exception et passent également par le prisme des recommandations et des bonnes pratiques.
Sur l'un des projets, au cours de la première étape de la solution, un serveur Jump basé sur Windows a été déployé. Afin d'optimiser les coûts de la phase initiale de développement, un serveur NFS a été déployé sur le même serveur pour les besoins des environnements improductifs, ce qui a couvert les besoins actuels des développeurs et permis d'importantes économies de ressources.
Au fil du temps, les environnements et les besoins en ressources ont augmenté et le serveur NFS a fait face à toutes les tâches. Petit à petit, dans le cadre du projet, nous avons approché l'épuisement des ressources de la VM initiale. Les ressources de VM dans MS Azure peuvent être augmentées en quelques minutes, mais en même temps, les exigences en matière de tolérance aux pannes du serveur ont augmenté, ce qui nous a amené à envisager une reconfiguration plus importante.
Pour la mise en œuvre, un serveur Linux, un service DRBD et la fonctionnalité de jeu de disponibilité ont été utilisés, ce qui a résolu le problème de la réplication des données entre les nœuds du cluster NFS et une disponibilité accrue en cas de défaillance de l'un des deux nœuds du cluster.
À propos: quelques mois après la mise en œuvre de la solution de cluster, le service NetApp Files a été ajouté à Azure, ce qui vous permet de profiter des baies NetApp, mais payé par le modèle Pay-As-You-Go.
# 5: Comment automatiser la planification de VM
Lorsque vous utilisez une infrastructure cloud, il est toujours judicieux d'analyser les mécanismes supplémentaires pouvant être utilisés pour maximiser les économies de coûts.
Dans notre cas, les systèmes sont testés pendant les heures ouvrables. Alors que dans une infrastructure classique, les temps d'arrêt d'un serveur se traduisent principalement par une augmentation des factures d'énergie, dans le cloud, les serveurs inutiles consomment du financement pour la location de capacité. Nous avons évalué les graphiques de charge sur les serveurs de test et de développement et avons remarqué que l'écrasante majorité des développeurs et des testeurs utilisent le système les jours de semaine de 8h00 à 20h00.
Dans les cas où le calendrier de chargement sur des systèmes improductifs est prévisible et cyclique, nous essayons d'utiliser des scripts pour automatiser l'activation / la désactivation de la VM. Azure dispose de plusieurs outils: arrêt automatique, comptes d'automatisation et Cloud Shell. Tous ne nous convenaient pas. L'arrêt automatique a été exclu car il ne peut arrêter que la machine virtuelle. Cloud Shell n'était pas non plus impliqué, car il nécessite la préparation de scripts supplémentaires, le développement de calendriers et un endroit sûr pour stocker tout cela avec la présence de redondance, ce qui réduit les économies au minimum.
Dans notre cas, un mécanisme plus flexible est utilisé. Automation Accounts offre une solution prête à l'emploi et fonctionnelle sous la forme de runbooks qui vous permettent d'activer et de désactiver des machines virtuelles selon un calendrier.
Nous avons préparé des graphiques pour les ressources respectives, chargé les runbooks et formé des liens entre les graphiques et les ressources.
En conséquence, nous avons encore réduit le coût total de possession. Initialement, ces outils n'étaient pas prévus pour la mise en œuvre, mais ils l'étaient déjà au stade de l'opération préliminaire.
La modification de l'horaire se fait en quelques minutes. Tout d'abord, une nouvelle planification est formée, puis la planification générée est associée à la ressource requise. Si nécessaire et qu'il y a un grand nombre de modifications, il est possible d'utiliser Cloud Shell pour automatiser ce processus.
# 6: Suivi de la consommation des ressources
Alors que pour les centres de données conventionnels, la surveillance de l'état et la consommation de ressources, malheureusement, disparaissent généralement en arrière-plan, il n'est pas souhaitable de l'autoriser dans Azure. Les informations sur l'historique de la consommation des ressources affectent directement les possibilités d'optimisation des coûts. Et dans le cas d'une réservation précoce des ressources, cela peut servir de signal pour des améliorations architecturales.
# 7: Filet de sécurité en cas de force majeure
De nombreuses entreprises ont peur de placer leurs systèmes informatiques sur des ressources cloud en raison de la peur des blocages, qui étaient auparavant ciblés par les régulateurs. Comme tout autre risque, cela peut également être pris en compte lors de la conception d'un système. Dans les projets, nous implémentons, en règle générale, un déchargement hebdomadaire des sauvegardes système du cloud vers le centre de données du client. Cela vous permet d'être sûr que le système peut être restauré dans toutes les éventualités. En plus de cela, nous utilisons une stratégie d'installation multi-cloud, qui permettra, en cas de restrictions d'accès, de ne pas se retrouver sans accès aux ressources. Dans ce scénario, des fournisseurs de cloud alternatifs sont utilisés comme sites de reprise après sinistre pour le cloud principal, ce qui permet de restaurer le système en cas de blocages massifs.
N ° 7 + Traitement des données personnelles
Au cours de notre travail, nous avons élaboré une approche sur la façon de stocker et de traiter les données personnelles dans des systèmes qui incluent des ressources cloud étrangères. À noter que la mise en œuvre de cette approche doit être réalisée en tenant compte des exigences des régulateurs. Ce sujet est assez vaste, et nous essaierons de le couvrir dans les articles suivants si nous remarquons l'intérêt correspondant dans les commentaires.
Résultat
Dans cet article, nous avons passé en revue plusieurs leçons pratiques sur l'hébergement de SAP dans le cloud MS Azure. Evidemment, le sujet est extrêmement large et nous n'avons pu aborder qu'une partie des optimisations possibles lors de la migration vers le cloud.
Quelles nuances avez-vous rencontrées? Nous vous serions reconnaissants de partager votre expérience dans les commentaires.