{"id":80952,"date":"2020-05-10T01:42:22","date_gmt":"2020-05-09T23:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2"},"modified":"2020-05-10T01:42:22","modified_gmt":"2020-05-09T23:42:22","slug":"monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2","title":{"rendered":"Monitoraggio nel Data Center: come abbiamo sostituito il vecchio BMS con il nuovo. Parte 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Monitoraggio<\/p>\n

Nella prima parte abbiamo spiegato perch\u00e9 abbiamo deciso di sostituire il vecchio sistema BMS nei nostri data center con uno nuovo. E non solo sostituirlo, ma svilupparlo da zero secondo le nostre esigenze. Nella seconda parte raccontiamo come lo abbiamo fatto.
\n<\/a><\/noindex><\/p>\n

Analisi del mercato<\/h2>\n

\nTenendo conto di quanto descritto in parte uno<\/a><\/noindex> richieste e della decisione di rinunciare all'aggiornamento del sistema esistente, abbiamo redatto un documento di specifiche per la ricerca di una soluzione sul mercato e abbiamo inviato richieste a diverse grandi aziende specializzate nella creazione di sistemi SCADA industriali.\u00a0<\/p>\n

Le prime risposte ci hanno mostrato che i leader del mercato dei sistemi di monitoraggio continuano prevalentemente a lavorare su server fisici, anche se il processo di migrazione verso il cloud \u00e8 gi\u00e0 iniziato in questo settore. Per quanto riguarda il ripristino delle macchine virtuali, nessuno ha supportato questa opzione. Inoltre, sembrava che nessuno dei noti sviluppatori sul mercato avesse dimostrato una comprensione anche della necessit\u00e0 di ripristino: \"il cloud non va mai gi\u00f9\" era la risposta pi\u00f9 comune. Di fatto, ci veniva proposto di ospitare il monitoraggio del data center nel cloud, fisicamente situato nello stesso data center.<\/p>\n

Qui \u00e8 necessario fare una piccola digressione sul processo di selezione del fornitore. Certo, il prezzo conta, ma durante qualsiasi gara per l'implementazione di un progetto complesso, nella fase di dialogo con i fornitori, inizi a percepire chi tra i candidati \u00e8 pi\u00f9 motivato e in grado di realizzarlo.\u00a0<\/p>\n

Questo \u00e8 particolarmente evidente nei progetti complessi.\u00a0<\/p>\n

In base alla tipologia delle domande di chiarimento sul capitolato, \u00e8 possibile suddividere i fornitori in quelli interessati solo a vendere (si percepisce un\u2019approccio standard da parte del responsabile commerciale) e in quelli che vogliono davvero sviluppare un prodotto, ascoltando e comprendendo il committente, apportando modifiche costruttive al capitolato anche prima della selezione finale (anche se c'\u00e8 il reale rischio di migliorare un capitolato altrui e perdere la gara), in fin dei conti, pronti ad accettare la sfida professionale e a realizzare un buon prodotto.<\/p>\n

Tutto ci\u00f2 ci ha portato a prestare attenzione a un relativamente piccolo sviluppatore locale - il gruppo di aziende \u00abSanline\u00bb, che ha risposto a gran parte delle nostre esigenze fin da subito ed era pronto a soddisfare tutte le necessit\u00e0 relative al nuovo BMS.\u00a0<\/p>\n

Rischi<\/h2>\n

\nMentre i grandi attori cercavano di capire cosa volessimo, portando avanti con noi una corrispondenza lenta coinvolgendo specialisti di livello pre-vendita, uno sviluppatore locale ha organizzato un incontro nel nostro ufficio con il suo team tecnico. Durante questo incontro, l'appaltatore ha riaffermato la sua volont\u00e0 di partecipare al progetto e, soprattutto, ha spiegato come il sistema richiesto sar\u00e0 realizzato.\u00a0\u00a0\u00a0\u00a0<\/p>\n

Prima dell'incontro, abbiamo identificato due rischi nel lavorare con un team privo del supporto di una grande azienda nazionale o internazionale:<\/p>\n

    \n
  1. Gli specialisti potrebbero sovrastimare le proprie capacit\u00e0 e, di conseguenza, non riuscire a portare a termine il lavoro, ad esempio utilizzando software complessi o progettando algoritmi di partizionamento non fattibili.<\/li>\n
  2. Dopo la realizzazione del progetto, il team potrebbe disintegrarsi e, di conseguenza, il supporto del prodotto risulterebbe a rischio.<\/li>\n<\/ol>\n

    \nPer ridurre questi rischi, abbiamo invitato ai nostri incontri i nostri specialisti di sviluppo. I dipendenti del potenziale appaltatore sono stati attentamente interrogati su cosa costituisca il sistema, come si prevede di realizzare il backup e su altre questioni in cui, come servizio operativo, non siamo abbastanza competenti.<\/p>\n

    Il verdetto \u00e8 stato positivo: l'architettura della piattaforma BMS esistente \u00e8 moderna, semplice e affidabile, pu\u00f2 essere migliorata, lo schema proposto per il backup e la sincronizzazione \u00e8 logico e funzionante.\u00a0<\/p>\n

    Abbiamo affrontato il primo rischio. Il secondo \u00e8 stato escluso, ricevendo dall'appaltatore conferma della disponibilit\u00e0 a fornirci il codice sorgente del sistema e la documentazione, oltre alla scelta del linguaggio di programmazione Python, ben noto ai nostri specialisti. Questo ci ha garantito la possibilit\u00e0 di mantenere il sistema autonomamente senza alcuna difficolt\u00e0 e senza un lungo periodo di formazione del personale nel caso in cui l'azienda sviluppatrice abbandonasse il mercato.<\/p>\n

    Un ulteriore vantaggio della piattaforma era che era implementata in contenitori Docker: in questo ambiente funzionano il kernel, l'interfaccia web e il database del prodotto. Questo approccio offre numerosi vantaggi, tra cui una configurazione preimpostata per la massima velocit\u00e0 di distribuzione della soluzione rispetto al \"classico\" e un'aggiunta semplice di nuovi dispositivi nel sistema. Il principio del \"tutto insieme\" semplifica al massimo l'implementazione del sistema: basta decomprimere il sistema e pu\u00f2 essere subito utilizzato.\u00a0<\/p>\n

    Con questa soluzione \u00e8 pi\u00f9 facile fare copie del sistema, e migliorarne e implementarne gli aggiornamenti \u00e8 possibile in un ambiente separato, senza fermare il funzionamento della soluzione nel suo complesso.\u00a0\u00a0<\/p>\n

    Dopo che entrambi i rischi sono stati minimizzati, il contraente ha fornito il preventivo. Questo ha affrontato tutti i parametri pi\u00f9 importanti per noi del sistema BMS.<\/p>\n

    Riserva<\/h2>\n

    \nIl nuovo sistema BMS doveva trovarsi nel cloud, su una macchina virtuale.\u00a0<\/p>\n

    Nessun hardware, nessun server e tutti i disagi e rischi legati a questo modello di distribuzione \u2013 la soluzione cloud ci ha permesso di eliminarli per sempre. \u00c8 stato deciso che il sistema funzioner\u00e0 nel nostro cloud su due sedi di data center a San Pietroburgo e Mosca. Questi sono due sistemi completamente funzionali che operano in modalit\u00e0 attiva standby con accesso per tutti i professionisti autorizzati.\u00a0<\/p>\n

    I due sistemi si proteggono a vicenda, garantendo una piena riserva sia delle capacit\u00e0 di calcolo che dei canali di trasmissione dati. Sono state inoltre configurate ulteriori misure di sicurezza, compresi il backup dei dati e dei canali, dei sistemi e delle macchine virtuali nel loro complesso, e un backup separato del database una volta al mese (il pi\u00f9 prezioso delle risorse in prospettiva di gestione e analisi).\u00a0<\/p>\n

    Va notato che la riserva come opzione della soluzione BMS \u00e8 stata sviluppata specificamente su nostra richiesta. Lo schema di riserva appariva in questo modo:<\/p>\n

    \"Monitoraggio<\/p>\n

    Supporto<\/h2>\n

    Un punto fondamentale per un'efficace operazione della soluzione BMS \u00e8 il supporto tecnico.\u00a0<\/p>\n

    \u00c8 tutto semplice: il nuovo sistema ci costerebbe 35.000 rubli al mese per un SLA di \"risposta entro 8 ore\", ovvero 35.000 x 12 \/ 80 = $5.250 all'anno. Il primo anno \u00e8 gratuito.\u00a0<\/p>\n

    A titolo di confronto: il supporto del vecchio BMS del fornitore ci costava 18.000 dollari all'anno, con un aumento della somma per ogni nuovo dispositivo aggiunto! Inoltre, l'azienda non forniva un manager dedicato; tutta l'interazione avveniva attraverso il manager delle vendite, il quale era interessato a noi come potenziale acquirente, con un corrispondente accentuato nella gestione delle richieste.\u00a0<\/p>\n

    Per una spesa inferiore abbiamo ottenuto un supporto completo del prodotto, con un account manager che partecipava attivamente allo sviluppo, con un unico punto di accesso, ecc. Il supporto \u00e8 diventato notevolmente pi\u00f9 flessibile, grazie all'accesso diretto agli sviluppatori per correzioni rapide in qualsiasi aspetto del funzionamento del sistema, integrazione tramite API, ecc.<\/p>\n

    Aggiornamenti<\/h2>\n

    \nNel nuovo sistema BMS proposto, tutti gli aggiornamenti sono inclusi nel costo del supporto, ovvero non richiedono un pagamento aggiuntivo. L'unica eccezione riguarda lo sviluppo di funzionalit\u00e0 aggiuntive, al di fuori di quelle indicate nel documento dei requisiti.\u00a0<\/p>\n

    Il sistema precedente prevedeva il pagamento sia per l'aggiornamento del software incorporato gratuito (come Java) sia per la correzione di errori. Non era possibile rinunciarvi; in assenza di aggiornamenti, il sistema in generale \"rallentava\" a causa delle vecchie versioni dei componenti interni.<\/p>\n

    E, ovviamente, non era possibile aggiornare il software senza acquistare un pacchetto di supporto.<\/p>\n

    Approccio flessibile<\/h2>\n

    \nUn'altra esigenza fondamentale riguardava l'interfaccia. Volevamo garantire l'accesso tramite browser web da qualsiasi punto, senza la necessit\u00e0 della presenza di un ingegnere presso il centro dati. Inoltre, puntavamo a creare un'interfaccia animata, affinch\u00e9 la dinamica di funzionamento dell'infrastruttura fosse pi\u00f9 visibile per gli ingegneri di guardia.\u00a0<\/p>\n

    Inoltre, nel nuovo sistema era necessario garantire il supporto per le formule per il calcolo del funzionamento dei sensori virtuali nei sistemi ingegneristici \u2013 ad esempio, per la distribuzione ottimale delle potenze elettriche nelle rack con attrezzature. A tal fine, \u00e8 necessario avere a disposizione tutte le operazioni matematiche abituali applicabili alle letture dei sensori.\u00a0<\/p>\n

    In seguito, era necessario avere accesso a un database SQL con la possibilit\u00e0 di estrarre i dati necessari sul funzionamento delle attrezzature \u2013 in particolare, tutte le registrazioni sul monitoraggio di duemila dispositivi e duemila sensori virtuali, che generano circa ventimila variabili.\u00a0<\/p>\n

    Era inoltre necessario un modulo di inventario delle attrezzature nel rack, in grado di fornire una rappresentazione grafica della disposizione dei dispositivi in ciascun'unit\u00e0, con il calcolo del peso totale dell'hardware, la gestione della biblioteca dei dispositivi e informazioni dettagliate su ciascun elemento.\u00a0<\/p>\n

    Conferma delle specifiche tecniche e firma del contratto<\/h2>\n

    \nQuando \u00e8 stato necessario iniziare a lavorare su un nuovo sistema, la corrispondenza con le 'grandi' aziende era ancora lontana dalla discussione sui costi delle loro offerte, quindi abbiamo confrontato l'allocazione ricevuta con i costi di aggiornamento del vecchio BMS (cfr. la prima parte<\/a><\/noindex>), e alla fine si \u00e8 rivelato pi\u00f9 conveniente e conforme alle nostre esigenze.<\/p>\n

    \u00c8 stata fatta la scelta.<\/p>\n

    Dopo la scelta del fornitore, gli avvocati hanno iniziato a redigere il contratto, mentre i team tecnici di entrambe le parti perfezionavano il capitolato tecnico. Come \u00e8 noto, un capitolato tecnico dettagliato e ben redatto \u00e8 la base del successo di qualsiasi lavoro. Maggiore \u00e8 la specificit\u00e0 nel capitolato, minori saranno le delusioni, come 'ma noi volevamo diversamente'.<\/p>\n

    Fornir\u00f2 due esempi di livello di dettaglio dei requisiti nel capitolato:<\/p>\n

      \n
    1. I Centri Dati di vigilanza hanno l'autorit\u00e0 di aggiungere nuovi dispositivi al BMS, di solito si tratta di PDU. Nella vecchia BMS, questo corrispondeva al livello \"administratore\", che consentiva anche di modificare le impostazioni variabili di tutti i dispositivi, e non era possibile separare le funzioni. Questo non ci soddisfaceva. Nella versione base della nuova piattaforma, il sistema era simile. Abbiamo subito specificato nel documento di specifiche che volevamo separare questi ruoli: solo un dipendente autorizzato deve modificare le impostazioni, mentre i turni devono poter continuare ad aggiungere dispositivi. Questo schema \u00e8 stato accettato per l'implementazione.<\/li>\n
    2. \u00a0In any standard BMS, there are three typical notification categories: RED \u2013 immediate action required, YELLOW \u2013 can be monitored, BLUE \u2013 \"Informational.\" We have traditionally used \"blue\" notifications for monitoring the exceeding of commercial parameters, for example, exceeding the power limit of a client's rack. This type of notification was intended for managers and was not of interest to the operations staff; however, in the old BMS, it regularly cluttered the list of active incidents and hindered operational work. We considered the logic and color differentiation of the notification banners to be successful and retained it, but in the specifications, we specifically indicated that \"blue\" notifications should fall silently into a separate section without distracting the duty personnel, where they would be handled by commercial specialists.<\/li>\n<\/ol>\n

      \nFormats for building charts and generating reports, interface outlines, a list of devices to be monitored, and many other things were stipulated with a similar level of detail.\u00a0<\/p>\n

      \u00c8 stato un lavoro veramente creativo di tre gruppi di lavoro: il servizio clienti, che ha dettato le proprie esigenze e condizioni; i tecnici di entrambe le parti, incaricati di trasformare queste esigenze in documentazione tecnica; e il team di programmatori dell'appaltatore, che ha realizzato le richieste del cliente secondo la documentazione tecnica sviluppata... Alla fine, abbiamo adattato alcune delle nostre richieste non fondamentali alle funzionalit\u00e0 gi\u00e0 esistenti della piattaforma, e l'appaltatore si \u00e8 impegnato a scrivere quanto necessario per noi.\u00a0<\/p>\n

      Lavoro parallelo di due sistemi<\/h2>\n

      \n\"Monitoraggio
      \n\u00c8 giunto il momento di mettere in pratica. In termini pratici, significa che diamo all'appaltatore la possibilit\u00e0 di implementare un prototipo BMS nel nostro cloud virtuale e forniamo accesso di rete a tutti i dispositivi che necessitano di monitoraggio.<\/p>\n

      Tuttavia, il nuovo sistema non era ancora pronto per funzionare. In questa fase, era importante per noi mantenere il monitoraggio nel vecchio sistema e allo stesso tempo consentire l'accesso ai dispositivi nel nuovo sistema. Non \u00e8 possibile costruire correttamente un sistema senza vedere i dispositivi in esso, che a loro volta non possono essere disconnessi dal monitoraggio del vecchio sistema.\u00a0<\/p>\n

      Era incerto se i dispositivi avrebbero sopportato un'interrogazione simultanea da due sistemi senza prove reali. C'era la probabilit\u00e0 che un'interrogazione simultanea doppia portasse a frequenti mancate risposte dai dispositivi, e avremmo ricevuto numerosi errori riguardanti l'inaccessibilit\u00e0 dei dispositivi, il che avrebbe bloccato il funzionamento del vecchio sistema di monitoraggio.<\/p>\n

      Il reparto di rete ha creato percorsi virtuali dal prototipo del nuovo BMS, distribuito nel cloud, ai dispositivi, e abbiamo ottenuto risultati:\u00a0<\/p>\n