👩🏾‍🚀 ⛽️ 👨🏾‍🤝‍👨🏼 Surveillance dans le centre de données: comment nous avons changé l'ancien BMS en un nouveau. Partie 2 🍞 🧕🏻 🏕️

Dans la première partie, nous avons expliqué pourquoi nous avons décidé de remplacer l'ancien système BMS de nos centres de données par un nouveau. Et pas seulement changer, mais développer à partir de zéro pour répondre à vos besoins. Dans la deuxième partie, nous expliquons comment nous l'avons fait.

Analyse de marché

Sur la base des souhaits et décisions décrits dans la première partie , de refuser de mettre à niveau le système existant, nous avons rédigé un énoncé des travaux pour trouver une solution sur le marché et interrogé plusieurs grandes entreprises qui ne sont impliquées que dans la création de systèmes industriels SCADA.

Les premières réponses de leur part ont montré que les leaders du marché des systèmes de surveillance continuent principalement de travailler sur des serveurs de fer, bien que le processus de migration vers les nuages dans ce segment ait déjà commencé. Quant aux machines virtuelles de sauvegarde - personne n'a pris en charge cette option. De plus, il y avait le sentiment qu'aucun des développeurs visibles sur le marché ne montrait même une compréhension du besoin de redondance: «le cloud ne tombe pas» était la réponse la plus courante. En fait, on nous a proposé de placer la surveillance du centre de données dans un cloud physiquement situé dans le même centre de données.

Ici, il est nécessaire de faire une petite digression sur le processus de sélection d'un entrepreneur. Le prix importe bien sûr, mais lors de tout appel d'offres pour la mise en œuvre d'un projet complexe, au stade du dialogue avec les fournisseurs, vous commencez à ressentir lequel des candidats est le plus intéressé et capable de le mettre en œuvre.

Cela est particulièrement visible sur les projets complexes.

Par la nature des questions de clarification pour les savoirs traditionnels, il est possible de diviser les contractants entre ceux qui souhaitent simplement vendre (la pression standard du directeur des ventes se fait sentir) et ceux qui souhaitent développer le produit, après avoir entendu et compris le client, pour apporter des modifications constructives aux spécifications techniques avant même le choix final (même en dépit du réel) risque d'améliorer les savoirs traditionnels de quelqu'un d'autre et de perdre l'appel d'offres), au final, juste prêt à relever le défi professionnel et à faire un bon produit.

Tout cela nous a fait prêter attention à un développeur local relativement petit - le groupe d'entreprises Sunline, qui a immédiatement répondu à la plupart de nos exigences et était prêt à répondre à tous les besoins concernant le nouveau BMS.

Les risques

Alors que les grands acteurs essayaient de comprendre ce que nous voulons, et que nous étions en correspondance tranquille avec l'aide de spécialistes de la prévente, un développeur local a pris rendez-vous à notre bureau avec la participation de son équipe technique. Lors de cette réunion, le contractant a une nouvelle fois démontré sa volonté de participer au projet et - surtout - expliqué comment le système requis sera mis en œuvre.

Avant la réunion, nous avons vu deux risques de travailler avec une équipe qui ne dispose pas des ressources d'une grande entreprise nationale ou internationale:

Les spécialistes pourraient surestimer leurs capacités et, par conséquent, ne peuvent tout simplement pas faire face, par exemple, ils utiliseront des logiciels sophistiqués ou concevront des algorithmes de sauvegarde impraticables.
Après la mise en œuvre du projet, l'équipe du projet peut se séparer et, par conséquent, le support produit sera en danger.

Pour minimiser ces risques, nous avons invité nos propres spécialistes du développement à la réunion. Les employés d'un entrepreneur potentiel ont été interrogés de manière approfondie sur les fondements du système, la manière dont il est prévu de mettre en œuvre les réservations et sur d'autres questions sur lesquelles nous, en tant que service d'exploitation, ne sommes pas suffisamment compétents.

Le verdict est positif: l'architecture de la plateforme BMS existante est moderne, simple et fiable, peut être finalisée, le schéma de sauvegarde et de synchronisation proposé est logique et efficace.

Ils ont fait face au premier risque. Ils ont exclu le second, après avoir reçu la confirmation de l'entrepreneur qu'ils étaient prêts à nous donner le code source du système et de la documentation, ainsi que le choix du langage de programmation Python, bien connu de nos spécialistes. Cela nous a garanti la possibilité de maintenir le système par nous-mêmes sans aucune difficulté et une longue période de formation pour les employés au cas où la société de développement quitterait le marché.

Un avantage supplémentaire de la plate-forme était qu'elle était implémentée dans des conteneurs Docker: dans cet environnement, le noyau, l'interface Web et la fonction de base de données de produits. Cette approche offre de nombreux avantages, notamment des paramètres prédéfinis pour la vitesse de déploiement la plus élevée de la solution par rapport aux "classiques" et l'ajout simple de nouveaux appareils au système. Le principe du «tout ensemble» simplifie au maximum la mise en œuvre du système: il suffit de déballer le système et vous pouvez immédiatement le faire fonctionner.

Avec une telle solution, il est plus facile de faire des copies du système, et il est possible de l'améliorer et de mettre en œuvre des mises à niveau dans un environnement séparé, sans arrêter la solution dans son ensemble.

Une fois les deux risques minimisés, l'entrepreneur a fourni KP. Il a élaboré pour nous tous les paramètres les plus importants du système BMS.

Réservation

Le nouveau système BMS était censé être dans le cloud sur une machine virtuelle.

Aucun matériel, aucun serveur et tous les inconvénients et risques associés à ce modèle de déploiement - la solution cloud nous a permis de nous en débarrasser à jamais. Il a été décidé que le système fonctionnerait dans notre cloud sur deux sites de centres de données à Saint-Pétersbourg et à Moscou. Il s'agit de deux systèmes entièrement fonctionnels fonctionnant en mode veille active avec accès pour tous les spécialistes autorisés.

Les deux systèmes s'assurent mutuellement, offrant une réserve complète pour la puissance de calcul et les canaux de transmission de données. Des mesures de sécurité supplémentaires ont également été mises en place, notamment la sauvegarde des données et des canaux, des systèmes, des machines virtuelles en général et une sauvegarde de base de données distincte une fois par mois (la ressource la plus précieuse dans la perspective de la gestion et de l'analyse).

Notez que la redondance en option de la solution BMS a été développée spécifiquement pour notre demande. Le schéma de sauvegarde lui-même ressemblait à ceci:

Soutien

Le point le plus important pour le fonctionnement efficace d'une solution BMS est le support technique.

Tout est simple ici: un nouveau système nous coûterait 35 000 roubles dans cet indicateur. par mois pour le SLA "réponse dans les 8 heures", soit 35 000 x 12/80 = 5 250 $ par an. La première année est gratuite.

A titre de comparaison: le support de l'ancien BMS du vendeur coûte 18 000 dollars par an avec une augmentation du montant pour chaque nouveau périphérique ajouté! Dans le même temps, la société n'a pas mis à disposition de manager dédié, toutes les interactions ont eu lieu via un responsable commercial qui s'intéresse à nous en tant qu'acheteur potentiel avec une emphase correspondante dans le traitement des demandes.

Pour moins d'argent, nous avons reçu un support complet pour le produit, avec un gestionnaire de compte qui participerait au développement du produit, avec un point d'entrée unique, etc. Le support est devenu beaucoup plus flexible - grâce à un accès direct aux développeurs pour les ajustements opérationnels sur tous les aspects du système, l'intégration via l'API, etc.

Mises à jour

Selon le KP proposé dans le nouveau BMS, toutes les mises à jour sont incluses dans le coût du support, c'est-à-dire ne nécessitent pas de paiement supplémentaire. Une exception est le développement de fonctionnalités supplémentaires au-delà de celles spécifiées dans les TdR.

L'ancien système assumait le paiement à la fois pour la mise à jour du firmware des logiciels libres (tels que Java) et pour la correction des bugs. Il était impossible de refuser cela, en l'absence de mises à jour, le système dans son ensemble «a ralenti» en raison des anciennes versions des composants internes.

Et, bien sûr, il était impossible de mettre à jour le logiciel sans acheter un package de support.

Approche flexible

Une autre exigence fondamentale concernait l'interface. Nous voulions y accéder via un navigateur Web de n'importe où, sans la présence d'un ingénieur dans le centre de données. De plus, nous nous sommes efforcés de créer une interface animée, afin que la dynamique du fonctionnement de l'infrastructure soit plus visible pour les ingénieurs de garde.

Toujours dans le nouveau système, il était nécessaire de fournir un support pour les formules de calcul du fonctionnement des capteurs virtuels dans les systèmes d'ingénierie - par exemple, pour la distribution optimale de la puissance électrique entre les racks équipés. Pour ce faire, vous devez avoir à votre disposition toutes les opérations mathématiques usuelles applicables aux indicateurs de capteurs.

De plus, l'accès à la base de données SQL était nécessaire, avec la possibilité de prendre les données nécessaires sur le fonctionnement de l'équipement - à savoir, tous les enregistrements sur la surveillance de deux mille appareils et deux mille capteurs virtuels générant environ 20 mille variables.

Nous avions également besoin d'un module de comptabilisation des équipements dans le rack, donnant une représentation graphique de l'emplacement des appareils dans chaque unité avec le calcul du poids total du matériel, le maintien d'une bibliothèque d'appareils et des informations détaillées sur chaque élément.

Harmonisation des savoirs traditionnels et signature d'un accord

À cette époque, alors qu'il était nécessaire de commencer à travailler sur le nouveau système, la correspondance avec les "grandes" entreprises était encore très loin de discuter du coût de leurs propositions, nous avons donc comparé le KP reçu avec les coûts de mise à jour de l'ancien BMS (voir la première partie ), et En conséquence, il s'est avéré plus attractif en termes de prix et correspondant à nos exigences.

Le choix est fait.

Après avoir choisi un entrepreneur, les avocats ont commencé à rédiger un contrat et les équipes techniques des deux côtés ont peaufiné les spécifications techniques. Comme vous le savez, un savoir traditionnel détaillé et compétent est la base de la réussite de tout travail. Plus il y a de détails sur les savoirs traditionnels, moins il y a de déceptions comme "mais nous n'aimions pas ça".

Je vais donner deux exemples du niveau de détail des exigences en savoirs traditionnels:

BMS , PDU. BMS «», , . . . , : , . .
BMS : – , – , – «». «» , , . , BMS . , , «» , , «» , .

Avec un degré de détail similaire, des formats de création de graphiques et de rapports, des contours d'interface, une liste des appareils à surveiller et bien d'autres choses étaient prescrites.

C'était un travail vraiment créatif de trois groupes de travail - le service client, qui a dicté ses exigences et ses conditions; des spécialistes techniques des deux parties dont la tâche était de convertir ces conditions en documentation technique; des équipes de programmeurs sous-traitants qui ont mis en œuvre les exigences des clients pour la documentation technique développée ... En conséquence, nous avons adapté certaines de nos exigences sans principes aux fonctionnalités d'une plate-forme existante, ce que l'entrepreneur s'est engagé à ajouter pour nous.

Fonctionnement parallèle de deux systèmes

Il est temps de mettre en œuvre. En pratique, cela signifiait que nous donnions à l'entrepreneur la possibilité de déployer un prototype BMS dans notre cloud virtuel et de fournir un accès réseau à tous les appareils qui nécessitent une surveillance.

De plus, le nouveau système n'était pas encore prêt à fonctionner. À ce stade, il était important pour nous de maintenir la surveillance dans l'ancien système et en même temps de donner accès aux appareils du nouveau système. Il est impossible de construire un système normalement sans y voir des périphériques, qui à leur tour ne peuvent pas être déconnectés de la surveillance par l'ancien système.

La question de savoir si les périphériques peuvent résister à l'interrogation simultanée par deux systèmes n'était pas évidente sans de vrais tests. Il était possible qu'une double enquête simultanée conduise à un refus fréquent des réponses des appareils et nous recevrions de nombreuses erreurs en raison de l'indisponibilité des appareils, ce qui à son tour bloquerait le fonctionnement de l'ancien système de surveillance.

Le département réseau a lancé des itinéraires virtuels depuis le prototype du nouveau BMS déployé dans le cloud vers les appareils, et nous avons obtenu les résultats:

les appareils connectés via le protocole SNMP ne se sont pratiquement pas déconnectés en raison d'appels simultanés,
les périphériques connectés via des passerelles utilisant des protocoles modbas-TCP ont rencontré des problèmes qui ont été résolus par une réduction raisonnable de la fréquence de leur interrogation.

Et puis nous avons commencé à observer comment un nouveau système se construit sous nos yeux, les appareils que nous connaissons déjà y apparaissent, mais dans une interface différente - pratique, rapide, accessible même depuis le téléphone.

Nous parlerons de ce qui s'est passé à la suite dans la troisième partie de notre article.

Surveillance dans le centre de données: comment nous avons changé l'ancien BMS en un nouveau. Partie 2