« Simplicité, vitesse, standard et stabilité » :
Modèle de dimensionnement pour déploiement rapide des applications

Chez Sprint, les nouvelles applications sont soumises à des tests par notre équipe du service des opérations d'environnement avant leur production et leur utilisation par des groupes de clientèle internes. Cette procédure suit un cycle standard de type développement/essai/production.

Cependant, alors que le volume et la complexité de l’organisation et de l’infrastructure informatique augmentaient, des ralentissements considérables commencèrent à se faire sentir, notamment dans notre capacité à déployer des environnements d'essai et de production. En conséquence, la mise en place de l’infrastructure sous-jacente pouvait prendre plusieurs mois.

Avec le développement de plus en plus de solutions prêtes à la production, notre équipe a commencé par rechercher d’autres manières de s’adapter à l'innovation plus rapide et aux besoins de cycles de déploiement des applications de la société.

C’est à ce stade que nous avons commencé à discuter des facteurs entravant le déploiement rapide de nos environnements d’essai. Cela a donné naissance à notre modèle initial de livraison de services « 4S ». Ayant entendu parler du succès de la société australienne Testra et de son projet OmniPresence de « stockage en tout lieu », notre équipe a commencé à examiner comment une infrastructure de ferme de serveurs et de stockage pourrait permettre le dimensionnement, le déséquipement et la restauration plus rapides de nos environnements de production et d'essai. Ce modèle de livraison de services est basé sur quatre critères nous permettant d’atteindre notre objectif : les quatre « S » :

  • « Simplicity (simplicité) » : Nous savions que notre processus de déploiement impliquant plusieurs équipes et couches informatiques était bien trop complexe. Pour que notre nouvelle infrastructure permette le déploiement d’environnements d’essai, elle devait nécessiter moins d’étapes et exiger moins d'assistance de la part de groupes variés.
  • « Speed (vitesse) » : Nous avons tout d’abord défini un niveau de service « zéro heure » pour la livraison d'environnements d’essai à notre clientèle. Notre cycle de livraison d'environnements pouvant habituellement prendre plusieurs semaines voire même plusieurs mois, cet objectif constituait un véritable défi.
  • « Standard » : L’incohérence de notre environnement était incroyable. Nous avons pensé que la standardisation des composants clé de l’infrastructure à utiliser dans nos environnements de serveur, de stockage, de base de données, d’inter logiciel et d’applications simplifierait nos efforts et permettrait une livraison plus rapide de nos produits. Notre but était d’arriver à construire rapidement 50 à 100 serveurs strictement identiques.
  • « Stability (stabilité) » : Nous souhaitions que nos déploiements soient suffisamment stables pour les développer, les déséquiper ou les reconstruire aussi facilement et qu'ils soient également capables de redimensionner la capacité libérée pour un autre essai ou un autre environnement de production.

En nous concentrant sur ces quatre aspects, nous avons été capables de développer un modèle de dimensionnement de service qui nous permet maintenant de n'utiliser que quelques commandes pour la mise en œuvre d’un serveur et l’installation d’Oracle®, de WebSphere ou tout autre composant d’application. Ce modèle comprend la création automatique de volumes de stockage et la capacité à allouer un stockage avec une telle rapidité que nous avons pu observer une attribution de jusqu’à 1 To de stockage à un hôte en quelques secondes à peine.

Résultats du projet :

  • Capacité d’allouer 1 To à un hôte en quelques secondes.
  • Capacité à identifier et à appliquer automatiquement des mesures de protection aux nouveaux ensembles de données dimensionnés.
  • Réduction à 15 minutes du temps de dimensionnement de l’application de la base de données et du stockage sur un serveur.

Frustrations et retards : l’impulsion donnée au changement
Lorsqu’un client nous a demandé d'installer un nouvel environnement d'essai, le processus nécessitait une coordination entre un minimum de six équipes. Le composant du serveur pouvait être fournit par des ressources matérielles et le [stockage] pouvait être à la charge de notre organisation d'administration des systèmes. Ensuite, un groupe différent était chargé de l’installation de l’intergiciel ou de la couche de base de données. Une autre personne était chargée de l’application ou de l’installation de BEA Weblogic ou d’IBM Websphere si ces composants étaient nécessaires. La plupart des logiciels supplémentaires étaient traités par autres groupes individuels.

Le déploiement de nos environnements dépendaient tellement de la disponibilité de toutes les équipes concernées que tout le processus en était retardé. Lorsque nous arrivions enfin à organiser le planning de tout le monde, le temps écoulé, depuis la demande jusqu’au déploiement, pouvait prendre généralement des semaines voire des mois.

Nous avons commencé à nous demander jusqu’à quel point nous pourrions accélérer le déploiement d’environnements d’essai en minimisant notre dépendance vis-à-vis des autres équipes pour l’exécution de leur composant. Pourquoi ne pas simplement automatiser leur part d’implémentation basée sur les processus et mesures préétablies par leur propre groupe ? Si l’on réussissait à séparer la part « exécution » du déploiement d’environnements du côté « mesure » propre à chaque groupe, de quels avantages pourrions-nous bénéficier ?

Afin de tenter cette stratégie, nous avons décidé l’année dernière d’effectuer un essai pilote informel avec le soutien d’un cadre délégué. Avec une équipe principale composée uniquement de quatre ou cinq personnes, nous avons pu créé un processus de prototype encore largement manuel. Cependant, ce prototype nous a permis de prouver notre capacité à réduire considérablement le temps de livraison d'un environnement pilote ou d’une production réelle à notre clientèle. Dans notre essai, nous sommes parvenus à passer de 80 à quatre heures à peine et à réduire le personnel à une personne. Cela nous a permis de séparer le temps et le travail réels nécessaires pour effectuer ces tâches relativement minimes du groupe de coordination et des fonctions de programmation.

L’une des stratégies de réduction de temps utilisée au cours de l'essai pilote consistait à remplacer l'intergiciel traditionnel de l'organisation et nos processus d’installation de logiciel par une image installée de l’application de l’intergiciel, créée à l’aide du logiciel NetApp Snapshot™ fonctionnant sur l’un de nos systèmes de stockage NetApp FAS. La copie Snapshot, préalablement stockée et cataloguée dans sa forme installée, pouvait alors être rapidement déployée vers un nouvel environnement d'essai à l'aide d'un montage rapide, en utilisant NFS sur un serveur cible désigné.

Notre théorie préliminaire prouvée, nous avons abordé un projet encore plus important consistant à développer notre modèle actuel de dimensionnement des services 4S.

Vers une plateforme commune de livraison de services
Nous avons commencé par développer et tester une nouvelle ferme informatique qui nous permettrait de dimensionner rapidement et d’adapter le serveur ainsi que les ressources de stockage aux besoins de n'importe quel hôte. Après un examen rigoureux des pratiques de déploiement les plus efficaces, nous avons décidé de nous intéresser à l'automatisation du déploiement d'environnements d'essai, comprenant des serveurs Sun™ Solaris™ et une base de données Oracle ou BEA Weblogic, IBM Websphere ou encore iPlanet. Les applications avec un ou plus de ces composants représentaient environ 45 % de la totalité des environnements déployés. Ces applications feraient l'objet de notre premier essai pour notre future modélisation de livraison de services.

Nous avons développé une ferme de serveurs et de stockage, toutes deux fonctionnant sur un réseau TCP/IP et gérées par une couche de logiciel de gestion d'infrastructure. La couche de gestion de l’infrastructure serait utilisée pour faciliter l’automatisation et la rapidité de livraison des ressources depuis la ferme. Quelques fonctions clé que la couche de gestion d’infrastructure devait effectuer :

  • Le dimensionnement
  • La gestion du stockage et de la sauvegarde
  • Les déploiements de SE utilisant Jumpstart

Ces fonctions, ainsi que la conception logique de la ferme, sont illustrées en figure 1. Nous avons supossé que chaque ligne de la figure, du point A au point B, demanderait un travail considérable d'intégration et de développement customisés avant de pouvoir transformer la livraison des environnements d’essai et des services connexes en un processus plus automatisé de type « bouton-poussoir ». Cependant, en ce qui concerne les composants de gestion de stockage et de sauvegarde, nous avons été surpris de constater le peu d'intégration nécessaire grâce au Protection Manager de NetApp, l’application que nous avions choisie pour la gestion du processus.



Figure 1) Modèle de livraison des services de ferme de serveurs et de stockage Sprint 4S.
Pour la ferme de serveurs, nous avons déployé 50 serveurs Sun Solaris pour commencer, avec l’objectif d’en déployer 100. Pour le stockage, nous avons alloué 100 To de stockage primaire NetApp FAS3000 et 100 To de stockage secondaire NetApp NearStore. Les systèmes sont connectés grâce à un IP SAN reliant tous les éléments de notre centre de données. L’architecture-même est conçue pour supporter des milliers d’hôtes.

Pour la gestion de notre plus large infrastructure et de nos composants de dimensionnement, nous avons opté pour IBM Tivoli Provisionning Manager afin de faciliter la gestion du catalogue et automatiser le dimensionnement en amont des environnements de serveurs / SE pour les réutiliser. Afin de faciliter la gestion, la sauvegarde et le dimensionnement des ensembles de données propres à chaque essai, nous avons évalué quelques applications de restauration et de sauvegarde avant d'opter pour NetApp Protection Manager combiné avec des outils de protection de données supplémentaires tels que SnapShot, SnapMirror® et SnapVault® de NetApp.

La détermination de la meilleure solution de gestion du stockage et des sauvegardes a représenté la tâche la plus délicate de l’implémentation du modèle.

Nouvel usage des outils de protection de données : Dimensionnement allégé et libération rapide des ressources de stockage
Lorsque nous avons démarré la conception du nouveau modèle 4S, notre désir était d'obtenir une capacité flexible de sauvegarde hautement disponible afin de pouvoir éviter d’éventuels retards de livraison des services. Nous avions également l'intention de développer davantage la gestion des ensembles de données plutôt que de les sauvegarder simplement dans le cas d'une défaillance de système locale ou plus importante.

Nous avions besoin d’une solution nous permettant d'approvisionner le stockage et d’effectuer le déséquipement ou la libération qui découlent de ce service de façon à pouvoir réutiliser la capacité de stockage sous-jacente. Nous souhaitions également établir des « points de contrôle » de l’environnement d’essai pour pouvoir l’arrêter et toutefois le réactiver ultérieurement, libérant ainsi momentanément la capacité de notre serveur pour une meilleure utilisation.

Conception centrée sur l’hôte comparée à celle centrée sur le stockage Lorsque nous avons comparé NetApp Protection Manager à d’autres applications de sauvegarde sur hôte, nous avons apprécié sa conception des données sauvegardées centrée sur le stockage plutôt sur l’hôte. Afin de pouvoir fournir des services de stockage pour un nouvel environnement d'essai, monter le(s) volume(s) sur un hôte, le(s) démonter ensuite et le(s) supprimer, nous avons pensé qu’une approche de sauvegarde basée sur l’hôte risquait d’égarer certaines parties du stockage. Voilà pourquoi nous avons préférer écarter le principe de l’hôte en matière de protection et de gestion des ensembles de données.

Après avoir évalué Protection Manager, nous avons apprécié sa capacité à maintenir la surveillance du stockage physique sous-jacent, des volumes, des copies SnapShot et des ensembles de données. De plus, le logiciel possédait une fonction que les autres solutions analysées ne possédaient pas : la capacité de découverte automatique des composants de stockage et des volumes de stockage sous-jacents au sein de nos systèmes NetApp FAS et NearStore. C’était pour nous d’une importance capitale, car il ne serait plus nécessaire de passer des mois à construire des scripts customisés afin de permettre au système de découvrir et de rapporter l’état des divers ensembles de données.

Nous avons également apprécié la flexibilité de Protection Manager permettant le regroupement des ensembles de données ou des volumes selon leurs exigences de protection et de pouvoir par la suite prédéfinir une procédure de sauvegarde/restauration. Ces fonctions ont constitué une procédure différente de dimensionnement au sein de notre modèle. Cette solution satisfait également notre souhait de réduire l'implication de divers groupes pour la conception des environnements d'essai, tout en leur laissant la supervision des procédures relatives à la conception.

Nous avons mis en place une ferme de stockage partagé simple et générique, constituée de procédures de protection individuelles pour la sauvegarde de nos clones de logiciel, des données des utilisateurs, des volumes racine et des fichiers de systèmes de stockage. Ce processus est illustré dans la figure 2.



Figure 2) Ensembles de données et sauvegardes gérées par NetApp Protection Manager.
Exemple de dimensionnement rapide et (de rédimensionnement)
Les performances de NetApp Protection Manager furent exceptionnelles. Après quelques jours seulement d’implémentation de ce modèle et avec l’aide de quelques consignes écrites, nous avons pu déployer facilement de nouveaux environnements de stockage et d’essai.

A présent, afin de déployer un environnement standard de serveur sur trois niveaux (dont 3 serveurs, représentant chacun un système de base de données, des applications, des environnements Web et même des téraoctets de stockage), nous sommes parvenus à abaisser à seulement 15 minutes le temps de dimensionnement et une seule personne est requise pour taper quelques commandes. Ce processus prenait généralement des heures ou des semaines à effectuer.

Dans un autre cas, nous avions déjà dimensionné des ressources pour un environnement d’essai basé sur la demande d’un client pour une base de données Oracle 10g™. Après le dimensionnement de l’environnement, le client nous a contacté pour changer la base de données afin de faire tourner l’environnement sur Oracle 9i™. Cette situation aurait tourné au cauchemar avec notre ancien style de dimensionnement. Grâce à notre nouveau modèle de service, nous avons pu, uniquement en activant quelques fonctions, déconnecter les ressources d'Oracle 10g et les reconnecter sous Oracle 9i.

En quête d’efficacité, puis d’économie des coûts
L’un des aspects intéressants de ce projet est que nous ne l'avons pas abordé avec l’idée prioritaire de réduire les coûts. Dans certains cas, un trop fort intérêt pour les économies peut altérer l’essence même d’un projet. Au lieu de cela, nous avons eu la chance de pouvoir traiter le projet en profondeur en nous intéressant d'abord aux problèmes rencontrés par les entreprises. L'économie de coûts n’était pas la priorité du projet. Il s’agissait plutôt de trouver un moyen d’accélérer le déploiement des applications et des environnements pour la production. Nous avons le sentiment que notre modèle 4S nous a permis d’atteindre notre objectif. Nous démarrons actuellement une étude de ses performances à travers des aspects différents de l'organisation. Les bénéfices de cette approche commencent par une économie de coûts et se traduisent ensuite par une meilleure utilisation du stockage et un temps de production plus rapide.

L’élément important que les autres groupes doivent garder à l’esprit, c’est que ce type d’infrastructure de livraison de services ne supprime en aucun cas leur responsabilité et la propriété de leur part d'infrastructure. Au contraire, cette approche leur permet de se réorganiser de manière à pouvoir adopter une attitude plus proactive dans la mise en place et le développement des décisions de procédure et de standards. En démontrant les mérites de notre projet avec le soutien de quelques membres principaux et d’un cadre délégué, nous avons pu mettre en évidence le succès de notre modèle et nous espérons que cela aidera l'organisation à s'adapter plus rapidement aux avantages qu’une telle architecture peut offrir dans d’autres domaines.

Rich Angalet
Directeur de Sprint

Doté d’une expérience en informatique de plus de 25 ans, M. Angalet (à gauche), est spécialisé en opérations, matériel informatique, SE, réseau, centre de données, gérance et automatisation. Il est actuellement responsable de l’implémentation de l’initiative 4S de Sprint. Rich a poursuivi ses études à l'université de Rutgers dans le New Jersey et se passionne pour les motos, les voitures classiques et les promenades en plein air.

  Dale Elmer
Directeur de IT Operations Management pour Sprint

Dale Elmer a fait ses débuts en 1976 chez Centel, une petite entreprise de services rattachée à Sprint en 1993. Dale a occupé plusieurs postes au sein de la société Sprint et avant d’occuper son poste actuel, Dale était directeur de l'assurance qualité pour l'initiative 4S de Sprint.

Explore