A la primera part, vam parlar de per què vam decidir substituir l'antic sistema BMS dels nostres centres de dades per un de nou. I no només canvieu, sinó que desenvolupeu des de zero per adaptar-vos a les vostres necessitats. A la segona part us expliquem com ho hem fet.
L'anàlisi del mercat
Tenint en compte els descrits a desitjos i la decisió de negar-nos a actualitzar el sistema existent, vam redactar una especificació tècnica per trobar una solució al mercat i vam fer consultes a diverses grans empreses dedicades només a la creació de sistemes SCADA industrials.
Les primeres respostes d'ells van mostrar que els líders del mercat de sistemes de monitorització segueixen treballant principalment en servidors de maquinari, tot i que el procés de migració als núvols en aquest segment ja ha començat. Pel que fa a la reserva de màquines virtuals, ningú no admetia aquesta opció. A més, hi havia la sensació que cap dels desenvolupadors visibles al mercat demostrava ni tan sols una comprensió de la necessitat de redundància: "el núvol no cau" era la resposta més habitual. De fet, ens van proposar col·locar el monitoratge del centre de dades en un núvol situat físicament al mateix centre de dades.
Aquí hem de fer una petita digressió sobre el procés de selecció d'un contractista. El preu, per descomptat, importa, però durant qualsevol licitació per a la implementació d'un projecte complex, en l'etapa de diàleg amb els proveïdors, es comença a sentir quin dels candidats està més interessat i capaç d'implementar-lo.
Això es nota especialment en projectes complexos.
A partir de la naturalesa d'aclarir qüestions a les especificacions tècniques, els contractistes es poden dividir en els interessats en vendre simplement (es sent la pressió estàndard d'un responsable de vendes) i els interessats a desenvolupar un producte, havent escoltat i entès el client, fent modificacions a les especificacions tècniques fins i tot abans de l'elecció final (malgrat el risc real de millorar les especificacions tècniques d'una altra persona i perdre la licitació), al final estan disposats a acceptar un repte professional i fer un bon producte.
Tot això ens va fer prestar atenció a un desenvolupador local relativament petit: el grup d'empreses Sunline, que va respondre a la majoria dels nostres requisits immediatament i estava preparat per implementar totes les necessitats relacionades amb el nou BMS.
Riscos
Mentre els grans jugadors intentaven entendre què volíem i mantenien una correspondència pausada amb nosaltres amb especialistes en prevenda, el promotor local va programar una reunió a la nostra oficina amb la participació del seu equip tècnic. En aquesta reunió, el contractista va tornar a demostrar la seva voluntat de participar en el projecte i, sobretot, va explicar com s'implementaria el sistema requerit.
Abans de la reunió, vam veure dos riscos de treballar amb un equip que no compta amb els recursos d'una gran empresa nacional o internacional al darrere:
- Els especialistes podrien sobreestimar les seves capacitats i, com a resultat, simplement no fer front; per exemple, utilitzaran programari complex o dissenyaran algorismes de reserva inviables.
- Un cop finalitzat el projecte, l'equip del projecte es pot desintegrar i, per tant, el suport del producte es veurà en perill.
Per minimitzar aquests riscos, vam convidar els nostres propis especialistes en desenvolupament a la reunió. Els empleats del contractista potencial van ser entrevistats a fons sobre en què es basa el sistema, com es preveu implementar la redundància i altres qüestions en què nosaltres, com a servei d'explotació, no som prou competents.
El veredicte va ser positiu: l'arquitectura de la plataforma BMS existent és moderna, senzilla i fiable, es pot millorar, l'esquema de redundància i sincronització proposat és lògic i viable.
El primer risc es va afrontar. El segon es va excloure després de rebre la confirmació del contractista que estaven preparats per transferir-nos el codi font del sistema i la documentació, i també escollint el llenguatge de programació Python, que era molt conegut pels nostres especialistes. Això ens va garantir l'oportunitat de mantenir el sistema pel nostre compte sense cap dificultat i un llarg període de formació dels empleats en cas que l'empresa de desenvolupament abandonés el mercat.
Un avantatge addicional de la plataforma va ser que es va implementar en contenidors Docker: el nucli, la interfície web i la funció de base de dades de productes en aquest entorn. Aquest enfocament ofereix molts avantatges, incloses la configuració predeterminada per a la màxima velocitat de desplegament de la solució en comparació amb el "clàssic" i l'addició fàcil de nous dispositius al sistema. El principi de "tots junts" simplifica la implementació del sistema tant com sigui possible: només cal desempaquetar el sistema i el podreu utilitzar immediatament.
Amb aquesta solució, és més fàcil fer còpies del sistema, i podeu millorar-lo i implementar actualitzacions en un entorn independent, sense aturar el funcionament de la solució en conjunt.
Un cop minimitzats ambdós riscos, el contractista va proporcionar el CP. Va cobrir tots els paràmetres més importants del sistema BMS per a nosaltres.
Reserva
El nou sistema BMS s'havia d'ubicar al núvol, en una màquina virtual.
Sense maquinari, sense servidors i amb tots els inconvenients i riscos associats a aquest model de desplegament: la solució al núvol ens va permetre desfer-nos-ne per sempre. Es va decidir que el sistema funcionaria al nostre núvol en dos centres de dades a Sant Petersburg i Moscou. Es tracta de dos sistemes totalment funcionals que funcionen en mode d'espera actiu amb accés a tots els especialistes autoritzats.
Els dos sistemes s'asseguren mútuament, proporcionant una reserva total tant de potència de càlcul com de canals de transmissió de dades. També s'han configurat mesures de seguretat addicionals, com ara còpia de seguretat de dades i canals, sistemes, màquines virtuals en general, i una còpia de seguretat de la base de dades separada un cop al mes (el recurs més valuós pel que fa a la gestió i l'anàlisi).
Tingueu en compte que la redundància com a opció a la solució BMS es va desenvolupar específicament per a la nostra sol·licitud. El propi esquema de reserves tenia aquest aspecte:
suport
El punt més important per al funcionament efectiu d'una solució BMS és el suport tècnic.
Aquí tot és senzill: un nou sistema ens costaria 35 rubles segons aquest indicador. al mes per a l'SLA "resposta en 000 hores", és a dir, 8 x 35 / 000 = 12 dòlars anuals. El primer any és gratuït.
Per comparar, mantenir l'antic BMS del venedor va costar 18 dòlars anuals amb un augment de la quantitat per a cada dispositiu nou afegit. Al mateix temps, l'empresa no va proporcionar un gestor dedicat; tota la interacció es va fer a través d'un responsable de vendes que està interessat en nosaltres com a comprador potencial amb l'èmfasi corresponent en la tramitació de les sol·licituds.
Per menys diners, vam rebre suport complet del producte, amb un gestor de comptes que participaria en el desenvolupament del producte, amb un únic punt d'entrada, etc. El suport es va fer molt més flexible, gràcies a l'accés directe als desenvolupadors per a ajustos ràpids a qualsevol aspecte del sistema, integració mitjançant API, etc.
Actualitzacions
Segons el CP proposat al nou BMS, totes les actualitzacions s'inclouen en el cost del suport, és a dir. no requereixen pagament addicional. L'excepció és el desenvolupament de funcionalitats addicionals més enllà del que s'especifica a les especificacions tècniques.
El sistema antic requeria el pagament tant per a les actualitzacions de microprogramari (com ara Java) com per a les correccions d'errors. Va ser impossible rebutjar-ho; en absència d'actualitzacions, el sistema en conjunt es va "alentir" a causa de les versions antigues dels components interns.
I, per descomptat, era impossible actualitzar el programari sense comprar un paquet de suport.
Enfocament flexible
Un altre requisit fonamental es refereix a la interfície. Volíem donar-hi accés a través d'un navegador web des de qualsevol lloc, sense la presència obligatòria d'un enginyer al territori del centre de dades. A més, hem intentat crear una interfície animada perquè la dinàmica de la infraestructura fos més clara per als enginyers de torn.
També en el nou sistema calia donar suport a fórmules per calcular el funcionament dels sensors virtuals en sistemes d'enginyeria, per exemple, per a la distribució òptima de l'energia elèctrica entre bastidors d'equips. Per fer-ho, cal tenir a la seva disposició totes les operacions matemàtiques habituals aplicables als indicadors de sensor.
A continuació, es va requerir l'accés a una base de dades SQL amb la possibilitat d'extraure-ne les dades necessàries sobre el funcionament de l'equip, és a dir, tots els registres de monitorització de dos mil dispositius i dos mil sensors virtuals que generen aproximadament 20 mil variables.
També calia un mòdul de comptabilitat d'equips de bastidor, que proporcionés una representació gràfica de la disposició dels dispositius en cada unitat amb càlcul del pes total del maquinari, mantenint una biblioteca de dispositius i informació detallada sobre cada element.
Aprovació de les especificacions tècniques i signatura d'un conveni
En el moment en què va ser necessari començar a treballar en el nou sistema, la correspondència amb empreses "grans" encara estava molt lluny de discutir el cost de les seves propostes, per la qual cosa vam comparar el CP rebut amb els costos d'actualització de l'antic BMS (vegeu. ), i com a resultat va resultar ser més atractiu en preu i complir els nostres requisits.
L'elecció s'ha fet.
Després de seleccionar un contractista, els advocats van començar a redactar un acord i els equips tècnics d'ambdues parts van començar a polir les especificacions tècniques. Com sabeu, les especificacions tècniques detallades i competents són la base per a l'èxit de qualsevol obra. Com més detalls hi hagi a les especificacions tècniques, menys decepcions com "però això no és el que volíem".
Posaré dos exemples del nivell de detall dels requisits a les especificacions tècniques:
- Els centres de dades de servei estan facultats per afegir nous dispositius al BMS, la majoria de vegades es tracta de PDU. A l'antic BMS, aquest era el nivell "administrador", que també permetia canviar la configuració variable de tots els dispositius i era impossible separar les funcions. Això no ens va bé. A la versió bàsica existent de la nova plataforma, l'esquema era similar. Immediatament vam indicar als termes de referència que volíem separar aquests rols: només un empleat autoritzat hauria de canviar la configuració, però els de guàrdia haurien de continuar podent afegir dispositius. Aquest esquema va ser acceptat per a la seva implementació.
- En qualsevol BMS estàndard hi ha tres categories típiques de notificacions: VERMELL: heu de respondre immediatament, GROC: podeu observar, BLAU: "Informatiu". Tradicionalment hem utilitzat alertes blaves per controlar quan s'han superat els paràmetres empresarials, com ara que el bastidor d'un client supera el seu límit de capacitat. Aquest tipus de notificacions en el nostre cas anaven destinades als gestors i no interessava al servei d'operacions, però a l'antic BMS obstruïa regularment la llista d'incidències actives i interferia en el treball operatiu. Vam considerar que la lògica i la diferenciació de color dels pantalons de notificació van tenir èxit i la vam mantenir, però, les especificacions tècniques van indicar específicament que les notificacions "blaves" haurien, sense distreure els agents de servei, "abocar-se" en silenci a una secció separada, on serà tractada per especialistes comercials.
Amb un grau de detall similar, es van prescriure els formats per construir gràfics i generar informes, els contorns de les interfícies, la llista de dispositius que calia controlar i moltes altres coses.
Aquest va ser un treball realment creatiu de tres grups de treball: el servei d'atenció al client, que dictava els seus requisits i condicions; tècnics especialistes d'ambdues parts, la tasca dels quals era transformar aquestes condicions en documentació tècnica; equips de programadors contractistes que van implementar els requisits del client segons la documentació tècnica desenvolupada... Com a resultat, vam adaptar alguns dels nostres requisits sense principis a la funcionalitat d'una plataforma existent, i el contractista es va comprometre a afegir alguna cosa per a nosaltres.
Funcionament paral·lel de dos sistemes
És el moment de la implementació. A la pràctica, això vol dir que donem al contractista l'oportunitat de desplegar un prototip de BMS al nostre núvol virtual i proporcionar accés a la xarxa a tots els dispositius que requereixen monitorització.
Tanmateix, el nou sistema encara no estava a punt per funcionar. En aquesta etapa, era important per a nosaltres mantenir la monitorització en el sistema antic i alhora donar accés als dispositius al nou sistema. És impossible construir correctament un sistema sense veure-hi dispositius, que al seu torn no es poden desactivar de la supervisió del sistema antic.
Si els dispositius podien suportar la interrogació simultània de dos sistemes no era obvi sense proves reals. Hi havia la possibilitat que la doble votació simultània conduís a denegacions freqüents a respondre des dels dispositius i rebríem molts errors pel que fa a la indisponibilitat dels dispositius, que al seu torn bloquejarien el funcionament de l'antic sistema de monitorització.
El departament de xarxes va executar rutes virtuals des d'un prototip del nou BMS desplegat al núvol fins als dispositius, i vam obtenir els resultats:
- els dispositius connectats mitjançant el protocol SNMP pràcticament mai es van desconnectar a causa de peticions simultànies,
- els dispositius connectats a través de passarel·les mitjançant protocols modbas-TCP tenien problemes que es resolien reduint de manera intel·ligent la seva freqüència de sondeig.
I llavors vam començar a observar com s'estava construint un nou sistema davant els nostres ulls, hi van aparèixer dispositius que ja ens coneixíem, però en una interfície diferent: còmode, ràpid, accessible fins i tot des d'un telèfon.
T'explicarem què va passar al final a la tercera part del nostre article.
Font: www.habr.com