Soutenance mémoire
Le Green IT dans un centre de données
Mesurer l’efficacité énergétique
Pour mesurer l’efficacité, on peut se référer à son PUEG12, qui calcule un ratio en divisant l’énergie totale consommée dans le centre de données par l’énergie consommée par les équipements informatiques. L’énergie totale comprend l’énergie consommée par les équipements informatiques, mais aussi l’énergie consommée par les autres équipements, tels que les climatiseurs.Plus le ratio se rapproche de 1, plus la consommation d’énergie du centre de données est optimale. Depuis la création de ce ratio, les entreprises ont réussi à le faire baisser en implémentant différente méthodes de Green IT23.
Conception des centres de données de l’État de Genève et problématique liées
L’infrastructure informatique de l’État de Genève est répartie sur deux centres de données principaux : DC1 et DC224, qui sont placés de chaque côté du Rhône, afin d’éviter qu’un incident majeur25 sur l’un n’impacte l’autre. Ils sont gérés par l’OCSING11, qui est le service informatique de l’État de Genève. Les centres de données sont principalement utilisés pour héberger les serveurs, le stockage et le matériel télécom sur lesquels reposent la totalité des applications et des données. Un 3ème centre beaucoup plus petit est utilisé comme site d’arbitrage pour les installations en haute disponibilité.La plupart des applications est composée d’un middleware26, d’une base de données et de code applicatif. Les applications sont classifiées selon un niveau de criticité afin d’offrir un hébergement adapté. Ainsi, une application en lien avec les services d’urgence doit toujours être disponible, elle sera répartie sur les deux centres de données. A l’inverse, si un service peut accepter une indisponibilité sans impact conséquent, l’application ne sera pas redondée de la même manière.L’OCSING11 favorise aussi la livraison de VMG20, ce qui permet de mutualiser les ressources de plusieurs services, plutôt que des serveurs dédiés. Les VMG20 facilitent aussi le renouvellement et accélèrent la migration du matériel physique.
Architecture
Architecture physique
Les centres de données sont composés de racksG14 équipés d’EPDUG5 redondés. Pour chaque rackG14, il y a soit de l’équipement réseau (switches, routeurs), soit des serveurs. Il existe deux types de serveurs : rackableG14 ou châssis de bladesG4.
Un serveur rackableG14 possède son propre accès aux ressources. La connexion se fait directement et le temps de réponse est donc très bon. Un châssis de bladesG4 permet de mutualiser les ressources des serveurs (fond de panier commun : alimentation électrique, accès au réseau et au stockage), mais nécessite une taille minimale d’activité pour être rentable. Pour chaque châssis, jusqu’à 16 serveurs bladesG4 peuvent être installés. Les serveurs rackablesG14 sont utilisés pour des configurations spécifiques.
Les centres de données possèdent également des baies de stockage NASG9 et SANG16, qui possèdent chacune leur réseau dédié. Le NASG9 utilise le réseau LANG7 du centre de données alors que le SANG16 utilise un réseau fibre channel27 séparé. Les baies de stockage sont répliquées et les serveurs écrivent leurs données en miroir sur les deux baies (écriture en Y).
Le SANG16 permet principalement de faire des accès aux bases de données avec une connexion directe sur le réseau. Cette technologie est très rapide28 et donne un accès simultané à plusieurs utilisateurs. Le NASG9 sert à faire de l’accès aux fichiers sur des disques réseaux. Cette technologie est moins rapide que le SANG16.Au niveau énergétique, l’électricité ainsi que la climatisation sont redondées à l’intérieur des centres de données. Lors d’une panne de courant, un groupe électrogène de secours permet de prendre le relai.Lors des appels d’offres pour du matériel, l’OCSING11 valorise le développement durable et le Green IT.
Architecture logique
L’accès aux applications se fait au travers de reverse proxies, qui permettent d’avoir une couche d’abstraction. Tout client passe d’abord par un reverse proxy qui va ensuite appeler le service souhaité et renvoyer le résultat au client29. Cette architecture apporte une couche de sécurité, car le client ne connait jamais l’adresse exacte du service souhaité.Le reverse proxy n’appelle pas directement un serveur, mais plutôt un membre d’un clusterG1. Enfin, il permet de faire du load balancingG8 en fonction de l’utilisation des serveurs et de leur disponibilité.
Sauvegardes
Deux robots de sauvegardes sur bande physique sont répartis dans les deux centres. Chacun effectue la sauvegarde de son site et contient la copie des bandes de l’autre site. Les données stockées sur bandes physiques s’écrivent très rapidement (jusqu’à 160 Mo/s), mais le temps d’accès est plus long. C’est pourquoi la politique en place veut que seuls les fichiers qui doivent être stockés sur le long terme et qui ne sont pas souvent sollicités y sont enregistrés.
Lors de ma visite de DC1, j’ai pu voir le robot de sauvegarde sur bande physique [Figure 5]. Il possède quatre bras mécaniques qui vont chercher les bandes physiques rangées sur les quatre étages, en se déplaçant le long du couloir Il sélectionne la bande contenant l’information recherchée et la charge dans un lecteur. Lorsque l’opération est terminée, le bras range la bande automatiquement.Deux autres types de robots sont répartis dans les deux centres : les VTLG21. Ils fonctionnent de la même manière que les robots physiques, mais virtualisent le stockage sur des disques. À l’inverse des robots physiques, ils sont plus rapides en lecture qu’en écriture et sont donc utilisés pour des données qui seront accédées sous moins de 30 jours.
Les données sauvegardées sont dupliquées et chaque serveur de sauvegarde gère son site en priorité. Les deux systèmes VTLG21 se répliquent entre eux alors que la copie des données entre les deux robots physiques est réalisée le lendemain des sauvegardes.
Un certain nombre de politiques de sauvegardes ont été instaurées. Elles permettent de réaliser chaque jour des sauvegardes incrémentales des serveurs ainsi que des sauvegardes des bases de données, en fonction des besoins. Les sauvegardes incrémentales des serveurs sont rapides, car chaque sauvegarde se base sur la précédente30 et ajoute les nouvelles informations. En revanche, le temps de restauration est relativement long, car il faut pouvoir récupérer les informations sur les différents disques et les reconstituer. Les sauvegardes les plus anciennes sont stockées sur les bandes physiques. 3.3 Énergie 3.3.1 Origine de l’énergie
La partie énergétique de DC1 est gérée par l’OCBAG10 alors que DC2 est hébergée par une société externe qui s’occupe de toute l’infrastructure d’hébergement (racksG14, électricité, refroidissement). Pour ce qui est de l’électricité, DC1 est capable de produire sa propre énergie en cas de panne de courant par deux systèmes, soit avec une turbine à gaz, soit avec des groupes électrogènes. L’électricité produite en trop peut être redistribuée sur le réseau des SIGG17. Il n’y a pas de contrat d’électricité verte avec l’OCBAG.
Pour DC1, le centre de données fonctionne sur du courant secouru à 100%. Tout le courant utilisé vient d’une production ondulée. Les SIGG17 fournissent le courant et 2 transformateurs internes avec des redresseurs permettent de mettre l’énergie sur des batteries qui font office de tampon au cas où il y a une perte de courant.
|
Table des matières
1. Introduction
1.1 Qu’est-ce que le Green IT ?
1.2 Pourquoi favoriser le Green IT ?
1.2.1 Économies
1.2.2 Écologie
1.2.3 Législation
1.3 Pourquoi les bonnes pratiques du Green IT ne sont pas implémentées partout ?
1.3.1 Manque d’information
1.3.2 Manque de temps
1.3.3 Résistance au changement
1.3.4 Visibilité
1.3.5 Coût
2. Le Green IT dans un centre de données
2.1 Optimiser l’aménagement physique d’un centre de données
2.1.1 Maintenir la température
2.1.2 Regrouper les services
2.2 Optimiser le matériel d’un centre de données
2.2.1 Consolidation informatique
2.3 Optimiser la couche logicielle d’un centre de données
2.3.1 Architectures économiques et écologiques
2.4 Mesurer l’efficacité énergétique
3. Conception des centres de données de l’État de Genève et problématique liées
3.1 Architecture
3.1.1 Architecture physique
3.1.2 Architecture logique
3.2 Sauvegardes
3.3 Énergie
3.3.1 Origine de l’énergie
3.3.2 Efficacité énergétique
3.4 Climatisation
3.5 Recyclage
3.6 Identification des facteurs de consommation
3.6.1 Changement de matériel
3.6.2 Durée de migration
3.6.3 Calculs inutiles
4. Exemple d’actions prises pour d’autres organisations
4.1 GoogleTM
4.1.1 Plateforme informatique intelligente en carbone
4.1.2 Économie circulaire
4.2 Pure StorageTM
5. Actions envisageables pour l’État de Genève
5.1 Actions sur l’urbanisation
5.1.1 Profiter des jours froids
5.1.2 Optimiser la climatisation
5.2 Actions matérielles
5.2.1 Optimiser la durée de migration
5.3 Actions logicielles
5.3.1 Éteindre les VMG20
5.3.2 Sauvegardes
5.3.3 Déduplication
5.3.4 Valider l’architecture en place avec le besoin réel du client
5.3.5 Identifier les ressources mutualisables et statiques
5.3.6 Implémenter les architectures écologiques et économiques
6. Communication des résultats
6.1 Comment implémenter les améliorations ?
6.2 Quels seront les gains
6.3 Communication interne et externe
6.4 Accompagnement du changement
6.4.1 Application de la méthode de Kotter
7. Conclusion
Télécharger le rapport complet
