{"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 raccontato perch\u00e9 abbiamo deciso di sostituire il vecchio sistema BMS nei nostri DC 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 prima parte<\/a><\/noindex> richieste e della decisione di rinunciare all'aggiornamento del sistema esistente, abbiamo redatto un piano per la ricerca di soluzioni sul mercato e abbiamo inviato richieste a diverse grandi aziende che si occupano esclusivamente della creazione di sistemi SCADA industriali.\u00a0<\/p>\n

Le prime risposte da parte loro hanno mostrato che i leader del mercato nei sistemi di monitoraggio continuano prevalentemente a lavorare su server fisici, anche se il processo di migrazione verso il cloud in questo segmento \u00e8 gi\u00e0 iniziato. Per quanto riguarda la virtualizzazione delle macchine \u2013 nessuno supportava questa opzione. Inoltre, si aveva l'impressione che nessuno tra i noti sviluppatori di mercato avesse nemmeno dimostrato di comprendere l'importanza della virtualizzazione: \"il cloud non crolla mai\" era la risposta pi\u00f9 comune. Di fatto, ci veniva proposto di collocare il monitoraggio del DC nel cloud, fisicamente situato nello stesso DC.<\/p>\n

\u00c8 necessario fare una piccola digressione sul processo di scelta del fornitore. Il prezzo, certo, ha importanza, ma durante qualsiasi gara per l'attuazione di un progetto complesso, nella fase di dialogo con i fornitori, inizi a capire chi tra i candidati \u00e8 pi\u00f9 interessato e capace di realizzarlo.\u00a0<\/p>\n

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

In base alla natura delle domande di chiarimento al piano, \u00e8 possibile suddividere i fornitori in quelli interessati semplicemente a vendere (si percepisce una pressione standard da parte del manager delle vendite) e in quelli interessati invece a sviluppare un prodotto, ascoltando e comprendendo il cliente, apportando modifiche costruttive al piano anche prima della scelta finale (anche nonostante il reale rischio di migliorare il piano di qualcun altro e perdere la gara), e, infine, pronti a raccogliere la sfida professionale e fare un buon prodotto.<\/p>\n

Tutto questo ci ha portato a considerare un relativamente piccolo sviluppatore locale \u2013 il gruppo di aziende \"Sunline\", che ha risposto a gran parte delle nostre richieste fin da subito ed era pronto a soddisfare tutte le esigenze relative al nuovo BMS.\u00a0<\/p>\n

Rischi<\/h2>\n

\nMentre i grandi attori cercavano di capire cosa volessimo e avevano scambi di corrispondenza tranquilli coinvolgendo specialisti di livello presale, un sviluppatore locale ha fissato un incontro nel nostro ufficio con la sua squadra tecnica. Durante questo incontro, l'appaltatore ha nuovamente dimostrato il desiderio di partecipare al progetto e, cosa principale, 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 che non ha alle spalle le risorse di una grande azienda nazionale o internazionale:<\/p>\n

    \n
  1. Gli specialisti potrebbero aver sovrastimato le loro capacit\u00e0 e, di conseguenza, non riuscire a gestire il progetto, ad esempio, utilizzando software complessi o progettando algoritmi di prenotazione impraticabili.<\/li>\n
  2. Dopo l'implementazione del progetto, il team potrebbe sciogliersi e, di conseguenza, il supporto del prodotto sarebbe a rischio.<\/li>\n<\/ol>\n

    \nPer minimizzare questi rischi, abbiamo invitato i nostri specialisti per lo sviluppo all'incontro. I dipendenti del potenziale appaltatore sono stati accuratamente interrogati riguardo a come \u00e8 costruito il sistema, come si prevede di implementare la prenotazione e su altre questioni in cui, come servizio di exploitation, 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, il piano di prenotazione e sincronizzazione proposto \u00e8 logico e funzionante.\u00a0<\/p>\n

    Abbiamo gestito il primo rischio. Il secondo \u00e8 stato escluso, ottenendo dall'appaltatore la conferma della disponibilit\u00e0 a trasferirci il codice sorgente del sistema e la documentazione, oltre a scegliere il 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 per i dipendenti in caso di uscita della societ\u00e0 di sviluppo dal mercato.<\/p>\n

    Un ulteriore vantaggio della piattaforma era il fatto che fosse realizzata in contenitori Docker: in questo ambiente funzionano il nucleo, l'interfaccia web e il database del prodotto. Questo approccio offre numerosi vantaggi, inclusa la pre-configurazione delle impostazioni per la massima velocit\u00e0 di distribuzione delle soluzioni rispetto alla \"classica\" e la semplice integrazione di nuovi dispositivi nel sistema. Il principio \"tutto insieme\" semplifica notevolmente l'implementazione del sistema: basta estrarre il sistema e pu\u00f2 essere immediatamente utilizzato.\u00a0<\/p>\n

    Con questa soluzione \u00e8 pi\u00f9 semplice effettuare copie del sistema, mentre il miglioramento e l'implementazione di aggiornamenti possono avvenire in un ambiente separato, senza interrompere il funzionamento della soluzione in generale.\u00a0\u00a0<\/p>\n

    Dopo che entrambi i rischi sono stati minimizzati, l'appaltatore ha fornito un preventivo. In esso sono stati elaborati tutti i parametri pi\u00f9 importanti per noi del sistema BMS.<\/p>\n

    Ridondanza<\/h2>\n

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

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

    I due sistemi si garantiscono reciprocamente, assicurando pieno backup sia delle capacit\u00e0 di calcolo che dei canali di trasmissione dei dati. Sono state anche configurate misure di sicurezza aggiuntive, incluso 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 (la risorsa pi\u00f9 preziosa 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 aspetto fondamentale per un'efficace operativit\u00e0 della soluzione BMS \u00e8 il supporto tecnico.\u00a0<\/p>\n

    Qui \u00e8 tutto semplice: il nuovo sistema ci costerebbe per questo parametro 35.000 rubli al mese per SLA \"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 per il vecchio BMS da parte del fornitore costava 18.000 dollari all'anno, con un aumento dell'importo per ogni nuovo dispositivo aggiunto! Inoltre, l'azienda non forniva un manager dedicato, tutte le interazioni avvenivano attraverso il manager delle vendite, il quale era interessato a noi come potenziali acquirenti con un corrispondente accento nella gestione delle richieste.\u00a0<\/p>\n

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

    Aggiornamenti<\/h2>\n

    \nSecondo la proposta di offerta, nel nuovo BMS tutti gli aggiornamenti sono inclusi nel costo del supporto, quindi non richiedono pagamenti aggiuntivi. Fanno eccezione lo sviluppo di funzionalit\u00e0 aggiuntive, oltre a quelle indicate nel documento di specifica.\u00a0<\/p>\n

    Il vecchio sistema prevedeva pagamenti sia per l'aggiornamento di software integrato gratuito (come Java), sia per la correzione di errori. Non era possibile fare a meno di questo; 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 altro requisito fondamentale riguardava l'interfaccia. Volevamo garantire l'accesso attraverso un browser web da qualsiasi luogo, senza la necessit\u00e0 della presenza di un ingegnere presso il data center. Inoltre, miravamo a creare un'interfaccia animata, affinch\u00e9 la dinamica di funzionamento dell'infrastruttura fosse pi\u00f9 visibile per gli ingegneri in servizio.\u00a0<\/p>\n

    Inoltre, nel nuovo sistema era necessario garantire il supporto per formule per il calcolo del funzionamento di sensori virtuali nei sistemi ingegneristici, ad esempio, per la distribuzione ottimale delle potenze elettriche tra i rack con l'attrezzatura. A tal fine, era necessario avere a disposizione tutte le operazioni matematiche consuete, applicabili ai dati dei sensori.\u00a0<\/p>\n

    Inoltre, era necessario avere accesso a un database SQL per poter estrarre i dati necessari sul funzionamento delle apparecchiature: in particolare, tutte le registrazioni di monitoraggio di duemila dispositivi e duemila sensori virtuali che generano circa 20.000 variabili.\u00a0<\/p>\n

    Era inoltre necessario un modulo per la gestione delle apparecchiature nel rack, che fornisse una rappresentazione grafica della disposizione dei dispositivi in ogni unit\u00e0, contando il peso totale dell'\u00abhardware\u00bb, mantenendo una libreria dei dispositivi e informazioni dettagliate su ogni elemento.\u00a0<\/p>\n

    Conferma del capitolato e firma del contratto<\/h2>\n

    \nAl momento in cui era necessario iniziare a lavorare sul nuovo sistema, la corrispondenza con le \u00abgrandi\u00bb aziende era ancora molto lontana dalla discussione sui costi delle loro proposte, quindi abbiamo confrontato l'offerta ricevuta con le spese per l'aggiornamento del vecchio BMS (vedi la prima parte<\/a><\/noindex>), e alla fine si \u00e8 rivelata pi\u00f9 conveniente e conforme ai nostri requisiti.<\/p>\n

    La scelta \u00e8 stata fatta.<\/p>\n

    Dopo la selezione dell'appaltatore, gli avvocati hanno iniziato a redigere il contratto, mentre i team tecnici di entrambe le parti affinavano il capitolato. Come \u00e8 noto, un capitolato dettagliato e ben redatto \u00e8 la base del successo di qualsiasi lavoro. Maggiore \u00e8 la specificit\u00e0 nel capitolato, minori saranno le delusioni come \u00abma noi non volevamo cos\u00ec\u00bb.<\/p>\n

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

      \n
    1. Gli operatori del data center hanno il potere di aggiungere nuovi dispositivi al BMS, spesso si tratta di PDU. Nel vecchio BMS questo era il livello di \u00abamministratore\u00bb, che consentiva anche di modificare le impostazioni delle variabili di tutti i dispositivi, e non era possibile separare le funzioni. Questo non ci andava bene. Nella versione base attuale della nuova piattaforma la configurazione era simile. Abbiamo subito indicato nel capitolato che volevamo separare questi ruoli: solo un dipendente autorizzato deve poter modificare le impostazioni, mentre gli operatori devono comunque avere la possibilit\u00e0 di aggiungere dispositivi. Questa configurazione \u00e8 stata accettata per l'implementazione.<\/li>\n
    2. \u00a0In ogni standard BMS ci sono tre categorie tipiche di notifiche: ROSSA \u2013 \u00e8 necessario reagire immediatamente, GIALLA \u2013 pu\u00f2 essere monitorata, BLU \u2013 \u00abInformativa\u00bb. Abbiamo tradizionalmente utilizzato le notifiche \u00abblu\u00bb per monitorare il superamento dei parametri commerciali, ad esempio, il superamento del limite di potenza del rack del cliente. Questo tipo di notifiche, nel nostro caso, era destinato ai manager e non interessava il servizio operativo, ma nella vecchia BMS intasava regolarmente l'elenco degli incidenti attivi e ostacolava il lavoro operativo. Abbiamo ritenuto che la logica e la differenziazione cromatica delle notifiche siano state fortunate e le abbiamo mantenute; tuttavia, nel documento di specifiche abbiamo specificamente indicato che le notifiche \u00abblu\u00bb dovevano, senza distrarre i turnisti, \u00abcadere\u00bb silenziosamente in una sezione separata, dove sarebbero state gestite da specialisti commerciali.<\/li>\n<\/ol>\n

      \nCon un grado di dettaglio simile sono stati definiti i formati di costruzione dei grafici e di generazione dei rapporti, le contornature delle interfacce, l'elenco dei dispositivi da monitorare e molte altre cose.\u00a0<\/p>\n

      \u00c8 stato veramente un lavoro creativo di tre gruppi di lavoro - il servizio clienti, che dettava i propri requisiti e condizioni; esperti tecnici di entrambe le parti, il cui compito era trasformare queste condizioni in documentazione tecnica; il team di programmatori dell'appaltatore, che implementava i requisiti del cliente secondo la documentazione tecnica sviluppata... Alla fine, alcune delle nostre richieste non essenziali le abbiamo adattate alla funzionalit\u00e0 della piattaforma gi\u00e0 esistente, mentre l'appaltatore si \u00e8 impegnato a scriverne alcune per noi.\u00a0<\/p>\n

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

      \n\"Monitoraggio
      \n\u00c8 arrivato il momento dell'implementazione. Nella pratica ci\u00f2 significava che davamo all'appaltatore la possibilit\u00e0 di sviluppare un prototipo della BMS nel nostro cloud virtuale e fornivamo accesso di rete a tutti i dispositivi che richiedevano monitoraggio.<\/p>\n

      A questo punto, tuttavia, il nuovo sistema non era ancora pronto per l'uso. In questa fase era importante per noi mantenere il monitoraggio nella vecchia sistema e allo stesso tempo dare accesso ai dispositivi al nuovo sistema. Non \u00e8 possibile costruire un sistema correttamente senza vedere i dispositivi in esso, che a loro volta non possono essere disconnessi dal monitoraggio della vecchia sistema.\u00a0<\/p>\n

      Se i dispositivi possono sopportare un interrogatorio simultaneo da due sistemi, era poco chiaro senza test reali. Esisteva la possibilit\u00e0 che un interrogatorio doppio simultaneo portasse a frequenti errori di risposta dai dispositivi, generando una serie di errori per l'inaccessibilit\u00e0 degli stessi, il che a sua volta avrebbe bloccato il funzionamento del vecchio sistema di monitoraggio.<\/p>\n

      Il reparto di rete ha configurato percorsi virtuali dal prototipo della nuova BMS, distribuito nel cloud, verso i dispositivi, e abbiamo ottenuto i seguenti risultati:\u00a0<\/p>\n