{"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\/da\/blog\/administrirovanie\/monitoring-v-czode-kak-my-menyali-staruyu-bms-na-novuyu-chast-2","title":{"rendered":"Overv\u00e5gning i datacenteret: hvordan vi skiftede fra det gamle BMS til det nye. Del 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Overv\u00e5gning<\/p>\n

I den f\u00f8rste del fortalte vi, hvorfor vi besluttede at skifte det gamle BMS-system i vores datacentre til et nyt. Og ikke bare skifte, men udvikle det fra bunden til vores krav. I den anden del fort\u00e6ller vi, hvordan vi gjorde det.
\n<\/a><\/noindex><\/p>\n

Markedsanalyse<\/h2>\n

\nMed de beskrevne f\u00f8rste del<\/a><\/noindex> \u00f8nsker og afg\u00f8relsen om at undlade opdatering af det eksisterende system, skrev vi en kravspecifikation til at finde en l\u00f8sning p\u00e5 markedet og sendte anmodninger til flere store virksomheder, der kun besk\u00e6ftiger sig med oprettelse af industrielle SCADA-systemer.\u00a0<\/p>\n

De f\u00f8rste svar fra dem viste, at markedslederne inden for overv\u00e5gningssystemer prim\u00e6rt fortsatte med at arbejde p\u00e5 fysiske servere, selvom migrationsprocessen til skyen i denne sektor allerede var begyndt. Hvad ang\u00e5r reservering af virtuelle maskiner \u2013 denne mulighed blev ikke underst\u00f8ttet af nogen. Desuden virkede det som om, at ingen af de bem\u00e6rkelsesv\u00e6rdige udviklere p\u00e5 markedet engang demonstrerede forst\u00e5elsen af n\u00f8dvendigheden af reservation: 'clouden falder jo ikke ned' var det mest almindelige svar. Faktisk blev vi tilbudt at placere overv\u00e5gningen af datacentret i skyen, der fysisk var placeret i det samme datacenter.<\/p>\n

Her skal vi lave et lille afsnit om processen med at v\u00e6lge en entrepren\u00f8r. Prisen betyder selvf\u00f8lgelig noget, men under enhver udbudsrunde for implementeringen af et komplekst projekt, i dialogen med leverand\u00f8rerne, begynder man at f\u00f8le, hvem af kandidaterne der er mest interesseret og i stand til at realisere det.\u00a0<\/p>\n

Dette er is\u00e6r bem\u00e6rkelsesv\u00e6rdigt ved komplekse projekter.\u00a0<\/p>\n

Ud fra karakteren af de afklarende sp\u00f8rgsm\u00e5l til kravspecifikationen kan man opdele entrepren\u00f8rerne i dem, der er interesserede i blot at s\u00e6lge (man m\u00e6rker det standard press fra salgsafdelingen) og dem, der er interesserede i at udvikle et produkt ved at h\u00f8re og forst\u00e5 kunden, foretage konstruktive \u00e6ndringer i kravspecifikationen allerede inden det endelige valg (selv p\u00e5 trods af den reelle risiko for at forbedre andres kravspecifikation og miste udbuddet), til sidst blot dem, der er villige til at tage imod den professionelle udfordring og lave et godt produkt.<\/p>\n

Alt dette fik os til at l\u00e6gge m\u00e6rke til en relativt lille lokal udvikler \u2013 gruppen af selskaber 'Sanline', som hurtigt opfyldte de fleste af vores krav og var klar til at im\u00f8dekomme alle behov vedr\u00f8rende det nye BMS.\u00a0<\/p>\n

Risici<\/h2>\n

\nMens de store akt\u00f8rer fors\u00f8gte at forst\u00e5, hvad vi \u00f8nskede, og f\u00f8rte en langsom korrespondance med involvering af pre-sales specialister, indkaldte den lokale udvikler til et m\u00f8de p\u00e5 vores kontor med deltagelse af sit tekniske team. Under dette m\u00f8de demonstrerede leverand\u00f8ren endnu en gang vilje til at deltage i projektet, og \u2013 vigtigst af alt \u2013 forklarede, hvordan det kr\u00e6vede system vil blive implementeret.\u00a0\u00a0\u00a0\u00a0<\/p>\n

F\u00f8r m\u00f8det identificerede vi to risici ved at arbejde med et team, som ikke har ressourcerne fra en stor national eller international virksomhed:<\/p>\n

    \n
  1. Specialisterne kunne overvurdere deres evner og i sidste ende simpelthen ikke kunne klare opgaven, f.eks. blande kompliceret software eller designe urealiserbare backupsalgoritmer.<\/li>\n
  2. Efter projektets afslutning kunne projektteamet opl\u00f8ses, hvilket ville s\u00e6tte produktst\u00f8tten i fare.<\/li>\n<\/ol>\n

    \nFor at minimere disse risici indkaldte vi vores egne udviklingsspecialister til m\u00f8det. Medarbejderne fra den potentielle leverand\u00f8r blev omhyggeligt spurgt til, hvordan systemet blev bygget, hvordan backup ville blive implementeret og andre emner, hvor vi, som driftsteam, ikke var tilstr\u00e6kkeligt kompetente.<\/p>\n

    Dommen var positiv: arkitekturen for den eksisterende BMS-platform er moderne, enkel og p\u00e5lidelig, kan tilpasses, og den foresl\u00e5ede backup- og synkroniseringsordning er logisk og funktionel.\u00a0<\/p>\n

    Den f\u00f8rste risiko blev h\u00e5ndteret. Den anden blev udelukket, da vi fik bekr\u00e6ftelse fra leverand\u00f8ren om beredskabet til at overgive os kildekoden til systemet og dokumentationen, samt ved at v\u00e6lge programmeringssproget Python, som vores specialister er godt bekendte med. Dette garanterede os muligheden for at vedligeholde systemet selv uden vanskeligheder og uden en lang indl\u00e6ringsperiode for medarbejderne, hvis udviklingsfirmaet forlod markedet.<\/p>\n

    En ekstra fordel ved platformen var, at den blev implementeret i Docker-containere: i dette milj\u00f8 fungerer kernen, webinterfacet og produktets database. Denne tilgang giver mange fordele, herunder forudinstallerede indstillinger for den h\u00f8jeste implementeringshastighed sammenlignet med \"klassiskt\" og nem tilf\u00f8jelse af nye enheder til systemet. Princippet \"alt sammen\" forenkler i h\u00f8j grad implementeringen af systemet: det er tilstr\u00e6kkeligt at udpakkes systemet for straks at kunne tage det i brug.\u00a0<\/p>\n

    Med en s\u00e5dan l\u00f8sning er det lettere at lave sikkerhedskopier af systemet, og forbedringer samt opgraderinger kan udf\u00f8res i et separat milj\u00f8 uden at stoppe arbejdet i l\u00f8sningen som helhed.\u00a0\u00a0<\/p>\n

    Efter at begge risici var blevet minimeret, pr\u00e6senterede entrepren\u00f8ren et tilbud. I det blev alle de vigtigste parametre for os i BMS-systemet gennemarbejdet.<\/p>\n

    Redundans<\/h2>\n

    \nDet nye BMS-system skulle v\u00e6re i skyen, p\u00e5 en virtuel maskine.\u00a0<\/p>\n

    Ingen hardware, ingen servere og alle de ulemper og risici forbundet med denne implementeringsmodel \u2013 den cloud-l\u00f8sning gjorde det muligt for os at slippe for dem for altid. Det blev besluttet, at systemet ville k\u00f8re i vores cloud p\u00e5 to data center-lokationer i Sankt Petersborg og Moskva. Det er to fuldt funktionelle systemer, der k\u00f8rer i aktiv standby med adgang for alle autoriserede specialister.\u00a0<\/p>\n

    De to systemer sikrer hinanden og giver fuld backup b\u00e5de i beregningskapacitet og datatransmissionskanaler. Der er ogs\u00e5 indf\u00f8rt yderligere sikkerhedsforanstaltninger, herunder data- og kanalbackup, systemer, virtuelle maskiner generelt, og separat databackup \u00e9n gang om m\u00e5neden (den mest v\u00e6rdifulde ressource i perspektivet af administration og analyse).\u00a0<\/p>\n

    Det skal understreges, at backup som en mulighed for BMS-l\u00f8sningen blev udviklet specifikt efter vores anmodning. Selve backup-skemaet s\u00e5 s\u00e5ledes ud:<\/p>\n

    \"Overv\u00e5gning<\/p>\n

    Support<\/h2>\n

    Et vigtigt punkt for effektiv drift af BMS-l\u00f8sningen er teknisk support.\u00a0<\/p>\n

    Her er alt enkelt: det nye system ville koste os 35 000 rubler om m\u00e5neden p\u00e5 dette parameter for SLA \"reaktion inden for 8 timer\", det vil sige 35 000 x 12 \/ 80 = $5 250 om \u00e5ret. Det f\u00f8rste \u00e5r er gratis.\u00a0<\/p>\n

    Til sammenligning kostede supporten af den gamle BMS fra leverand\u00f8ren $18.000 om \u00e5ret med en stigende pris for hver ny enhed, der blev tilf\u00f8jet! Desuden stillede virksomheden ikke en dedikeret manager til r\u00e5dighed; al kommunikation foregik gennem salgsmannen, som var interesseret i os som en potentiel k\u00f8ber med den tilsvarende fokus i behandling af anmodninger.\u00a0<\/p>\n

    For f\u00e6rre penge fik vi fuld produktst\u00f8tte med en konto-manager, der ville deltage i produktudviklingen, med et enkelt kontaktpunkt osv. St\u00f8tten blev langt mere fleksibel \u2013 takket v\u00e6re direkte adgang til udviklerne for hurtige justeringer af alle aspekter af systemets funktion, integration via API osv.<\/p>\n

    Opdateringer<\/h2>\n

    \nIf\u00f8lge det foresl\u00e5ede tilbud i den nye BMS er alle opdateringer inkluderet i prisen for support og kr\u00e6ver derfor ikke ekstra betaling. Undtagelsen er udviklingen af ekstra funktionalitet ud over det, der er angivet i specifikationen.\u00a0<\/p>\n

    Det gamle system kr\u00e6vede betaling b\u00e5de for opdatering af den indbyggede gratis software (som Java) og for fejlretning. Det var umuligt at undg\u00e5 dette; uden opdateringer blev systemet generelt \"langsomt\" p\u00e5 grund af de gamle versioner af de interne komponenter.<\/p>\n

    Og selvf\u00f8lgelig kunne man ikke opdatere softwaren uden at k\u00f8be supportpakken.<\/p>\n

    Fleksibel tilgang<\/h2>\n

    \nEt andet v\u00e6sentligt krav gjaldt brugergr\u00e6nsefladen. Vi \u00f8nskede at sikre adgang til den via webbrowser fra enhver lokation, uden at en tekniker n\u00f8dvendigvis skulle v\u00e6re til stede i datacenteret. Derudover str\u00e6bte vi efter at oprette en animeret gr\u00e6nseflade, s\u00e5 dynamikken i infrastrukturen blev mere synlig for de vagthavende teknikere.\u00a0<\/p>\n

    I det nye system var det ogs\u00e5 n\u00f8dvendigt at sikre support for formler til beregning af data fra virtuelle sensorer i ingeni\u00f8rsystemer \u2013 for eksempel til optimal fordeling af elektrisk kapacitet blandt udstyr i racks. For dette skal man have alle de velkendte matematiske operationer, der g\u00e6lder for sensorv\u00e6rdier, til r\u00e5dighed.\u00a0<\/p>\n

    Derudover var der behov for adgang til SQL-databasen med mulighed for at hente de n\u00f8dvendige data om udstyrets drift \u2013 specifikt alle optegnelser om overv\u00e5gningen af to tusinde enheder og to tusinde virtuelle sensorer, der genererer cirka 20 tusinde variabler.\u00a0<\/p>\n

    Der var ogs\u00e5 behov for en modul til udstyrsoverv\u00e5gning i rack, der giver en grafisk fremstilling af placeringen af enhederne i hver enhed med en opg\u00f8relse af den samlede v\u00e6gt af \"hardware\", vedligeholdelse af et bibliotek med enheder og detaljeret information om hvert element.\u00a0<\/p>\n

    Godkendelse af kravspecifikation og underskrift af kontrakt<\/h2>\n

    \nP\u00e5 det tidspunkt, hvor det var n\u00f8dvendigt at p\u00e5begynde arbejdet p\u00e5 det nye system, var kommunikationen med de \"store\" virksomheder stadig meget langt fra at diskutere priserne p\u00e5 deres tilbud, s\u00e5 vi sammenlignede det modtagne tilbud med omkostningerne ved at opgradere det gamle BMS (se. f\u00f8rste del<\/a><\/noindex>), og resultatet viste sig at v\u00e6re mere prisattraktivt og i overensstemmelse med vores krav.<\/p>\n

    Valget blev truffet.<\/p>\n

    Efter valget af entrepren\u00f8r begyndte juristerne at udarbejde kontrakten, mens de tekniske teams fra begge sider finpudsede kravspecifikationen. Som bekendt er en detaljeret og korrekt kravspecifikation grundlaget for enhver succesfuld opgave. Jo mere konkret kravspecifikationen er, desto f\u00e6rre skuffelser som \"men vi ville ikke have det s\u00e5dan\".<\/p>\n

    Her er to eksempler p\u00e5 detaljegraden af kravene i kravspecifikationen:<\/p>\n

      \n
    1. D\u00f8gnvagterne i datacentrene har bef\u00f8jelse til at tilf\u00f8je nye enheder til BMS, oftest PDU'er. I det gamle BMS var dette niveau \"administrator\", hvilket ogs\u00e5 tillod \u00e6ndring af indstillingerne for alle enheder, og det var umuligt at adskille funktioner. Det var vi ikke tilfredse med. I den eksisterende basisversion af den nye platform var skemaet dog analogt. Vi angav straks i kravspecifikationen, at vi \u00f8nskede at adskille disse roller: indstillingerne skulle kun \u00e6ndres af en bemyndiget medarbejder, men d\u00f8gnvagterne skulle fortsat have mulighed for at tilf\u00f8je enheder. Dette skema blev godkendt til implementering.<\/li>\n
    2. \u00a0I enhver standard BMS er der tre typiske kategorier af meddelelser: R\u00d8D \u2013 der skal straks reagere, GUL \u2013 kan overv\u00e5ges, BL\u00c5 \u2013 \u201eInformations\u201c. Vi har traditionelt brugt \u201ebl\u00e5\u201c meddelelser til at overv\u00e5ge overskridelse af kommercielle parametre, for eksempel overskridelse af str\u00f8mmens gr\u00e6nse for kundens rack. Denne type meddelelser var i vores tilf\u00e6lde beregnet til ledere og var ikke interessant for driftstjenesten, men i den gamle BMS fyldte de regelm\u00e6ssigt listen over aktive h\u00e6ndelser og h\u00e6mmede det operative arbejde. Vi fandt selve logikken og den farvem\u00e6ssige differentiering af meddelelserne vellykket og bevarede den, men specificerede i kravspecifikationerne, at \u201ebl\u00e5\u201c meddelelser skulle diffuse stille i et separat afsnit uden at forstyrre vagtpersonalet, hvor de ville blive h\u00e5ndteret af kommercielle specialister.<\/li>\n<\/ol>\n

      \nMed tilsvarende detaljegrad blev formaterne for opbygning af diagrammer og rapportering, gr\u00e6nsefladerne, listen over enheder, der skulle overv\u00e5ges, og mange andre ting nedskrevet.\u00a0<\/p>\n

      Det var et virkelig kreativt arbejde for tre arbejdsgrupper \u2013 bestillingstjenesten, som dikterede sine krav og betingelser; tekniske specialister fra begge sider, hvis opgave var at omforme disse betingelser til teknisk dokumentation; og programmeringsteamet fra entrepren\u00f8ren, der implementerede kundens krav baseret p\u00e5 den udarbejdede tekniske dokumentation\u2026 I sidste ende tilpassede vi nogle af vores ikke-principielle krav til funktionaliteten af den allerede eksisterende platform, mens entrepren\u00f8ren forpligtede sig til at skrive yderligere til os.\u00a0<\/p>\n

      Parallel drift af to systemer<\/h2>\n

      \n\"Overv\u00e5gning
      \nDet var tid til implementering. I praksis bet\u00f8d det, at vi gav entrepren\u00f8ren mulighed for at implementere en prototype af BMS i vores virtuelle sky og tilbyde netv\u00e6rksadgang til alle de enheder, der kr\u00e6vede overv\u00e5gning.<\/p>\n

      P\u00e5 samme tid var det nye system endnu ikke klar til drift. P\u00e5 dette stadium var det vigtigt for os at bevare overv\u00e5gningen i det gamle system, samtidig med at vi gav adgang til enhederne i det nye system. Det er umuligt at opbygge et system ordentligt, uden at se de enheder, som ikke kan frakobles overv\u00e5gningen fra det gamle system.\u00a0<\/p>\n

      Det var ikke indlysende, om enheder ville kunne klare en samtidig foresp\u00f8rgsel fra to systemer uden reelle tests. Der var en sandsynlighed for, at en dobbelt samtidig foresp\u00f8rgsel ville f\u00f8re til hyppige svarfejl fra enhederne, hvilket ville resultere i et v\u00e6ld af fejl ang\u00e5ende utilg\u00e6ngelighed af enheder, og dermed blokere den gamle overv\u00e5gningssystem.<\/p>\n

      Netv\u00e6rksafdelingen har oprettet virtuelle ruter fra prototypen af det nye BMS, der er implementeret i skyen, til enhederne, og vi har f\u00e5et resultaterne:\u00a0<\/p>\n