Övervakning i datacentret: hur vi bytte ut det gamla BMS mot det nya. Del 2

I den första delen berättade vi varför vi beslutade att byta ut vårt gamla BMS-system i våra datacenter till ett nytt. Och inte bara byta, utan utveckla det från grunden för att möta våra krav. I den andra delen berättar vi hur vi gjorde det.

Marknadsanalys

Med hänsyn till de önskemål som beskrivits i första delen och beslutet att avstå från att uppgradera det befintliga systemet skrev vi en kravspecifikation för att hitta en lösning på marknaden och gjorde förfrågningar till flera stora företag som bara sysslar med skapandet av industriella SCADA-system. 

De första svaren från dem visade att marknadsledarna inom övervakningssystem främst fortsatt att jobba på fysiska servrar, även om migreringen till molnet i denna sektor redan hade inletts. När det gäller reservdelning av virtuella maskiner - denna alternativ stödde ingen. Dessutom fanns det en känsla av att ingen av de framstående utvecklarna på marknaden ens visade förståelse för behovet av reservdelning: "molnet går ju inte ner" var det vanligaste svaret. Faktiskt erbjöds vi att placera övervakningen av datacentret i ett moln som fysiskt befann sig i samma datacenter.

Här måste vi göra en liten avstickare om processen att välja entreprenör. Priset spelar självklart en roll, men under varje anbud för genomförandet av ett komplext projekt, i dialogen med leverantörerna, börjar man känna vem av kandidaterna som är mer intresserad och kapabel att genomföra det. 

Detta märks särskilt tydligt i komplexa projekt. 

Baserat på arten av förtydligande frågor till kravspecifikationen kan man dela upp entreprenörerna i två grupper: de som är intresserade av att bara sälja (man märker den standardiserade pressen från försäljningschefen) och de som är intresserade av att utveckla produkten genom att lyssna på kunden, förstå deras behov, och göra konstruktiva ändringar i kravspecifikationen redan innan det slutliga valet (även om det innebär en verklig risk att förbättra någon annans kravspecifikation och förlora anbudet), och till slut de som helt enkelt är beredda att anta en professionell utmaning och skapa en bra produkt.

Allt detta fick oss att rikta vår uppmärksamhet mot en relativt liten lokal utvecklare - företagsgruppen "Sanline", som omedelbart svarade på de flesta av våra krav och var beredda att möta alla behov gällande det nya BMS. 

Risker

Medan de stora aktörerna försökte förstå vad vi ville och förde ett långsamt samtal med inblandning av specialister på presale-nivå, bokade en lokal utvecklare ett möte på vårt kontor med sin tekniska grupp. Under detta möte visade entreprenören återigen sin vilja att delta i projektet och - viktigt - förklarade hur det önskade systemet skulle genomföras.    

Innan mötet identifierade vi två risker med att arbeta med ett team som inte har resurser från ett stort nationellt eller internationellt företag:

1. Specialisterna kan ha överskattat sina möjligheter och misslyckas, till exempel genom att använda komplex programvara eller designa orealistiska algoritmer för reservlösningar.
2. Efter genomförandet av projektet kan projektteamet upplösas och därmed kan produktstödet sättas i fara.

För att minimera dessa risker bjöd vi in våra egna utvecklingsspecialister till mötet. Anställda från den potentiella entreprenören blev noggrant tillfrågade om hur systemet är uppbyggt, hur reservlösningar ska genomföras och andra frågor där vi, som driftavdelning, inte var tillräckligt insatta.

Uttalandet var positivt: arkitekturen för den redan existerande BMS-plattformen är modern, enkel och pålitlig, kan utvecklas vidare, och den föreslagna reserv- och synkroniseringsschemat är logiskt och fungerar. 

Den första risken hanterades. Den andra eliminierades, efter att ha fått bekräftelse från entreprenören om beredskap att överlämna källkoden till systemet och dokumentationen, samt genom att välja programmeringsspråket Python, som våra specialister är väl bekanta med. Detta garanterade oss möjligheten att stötta systemet med våra egna resurser utan några svårigheter och utan lång träningsperiod för anställda i händelse av att utvecklarföretaget lämnar marknaden.

En extra fördel med plattformen var att den var implementerad i Docker-containrar: i denna miljö fungerar kärna, webbgränssnitt och produktens databas. Denna metod ger många fördelar, inklusive förinställda konfigurationer för högsta möjliga hastighet vid driftsättning av lösningen jämfört med 'klassiska' metoder och enkel tillägg av nya enheter till systemet. Prinsipen 'allt tillsammans' förenklar införandet av systemet maximalt: det räcker med att packa upp systemet för att kunna börja använda det direkt. 

Med en sådan lösning är det enklare att skapa kopior av systemet, och att förbättra det samt utföra uppgraderingar kan ske i en separat miljö utan att stoppa driften av lösningen som helhet.  

Efter att båda riskerna hade minimerats, presenterade entreprenören en offert. I den hade alla de viktigaste parametrarna för vårt BMS-system arbetats fram.

Reservkraft

Det nya BMS-systemet skulle finnas i molnet, på en virtuell maskin. 

Ingen hårdvara, inga servrar och alla de besvär och risker som är förknippade med denna distributionsmetod – molnlösningen gjorde att vi kunde bli av med dem för alltid. Det beslutades att systemet skulle köras i vårt moln på två platser i datacentren i Sankt Petersburg och Moskva. Det rör sig om två fullt funktionella system som körs i aktiv standby-läge med tillgång för alla auktoriserade specialister. 

De två systemen försäkrar varandra, vilket ger full redundans både när det gäller beräkningskraft och datakommunikationskanaler. Dessutom har ytterligare säkerhetsåtgärder implementerats, inklusive säkerhetskopiering av data och kanaler, system, virtuella maskiner och en separat backup av databasen en gång i månaden (den mest värdefulla resursen ur förvaltnings- och analysperspektiv). 

Det är värt att notera att reservplanering som en del av BMS-lösningen utvecklades specifikt på vår begäran. Själva backup-schemat såg ut så här:

Support

En avgörande punkt för en effektiv användning av BMS-lösningen är teknisk support. 

Här är det enkelt: det nya systemet skulle kosta oss 35 000 rubel per månad för SLA 'respons inom 8 timmar', det vill säga 35 000 x 12 / 80 = $5 250 per år. Första året – gratis. 

För jämförelse: stödet för den gamla BMS från leverantören kostade $18 000 per år med en ökning för varje ny enhet som lades till! Dessutom tillhandahöll företaget ingen dedikerad chef, all interaktion skedde via en försäljningschef som var intresserad av oss som en potentiell kund med motsvarande betoning i hanteringen av förfrågningar. 

För mindre pengar fick vi fullt produktstöd, med en account manager som deltog i produktutvecklingen, med en enda kontaktpunkt etc. Stödet blev avsevärt mer flexibelt – tack vare direkt tillgång till utvecklarna för snabba justeringar av alla aspekter av systemets funktionalitet, integration via API etc.

Uppdateringar

Enligt det föreslagna KP i den nya BMS ingår alla uppdateringar i kostnaden för stödet, d.v.s. kräver ingen ytterligare betalning. Undantaget är utvecklingen av ytterligare funktionalitet, utöver den som anges i TZ. 

Det gamla systemet innebar kostnader både för uppdatering av den inbyggda gratis programvaran (som Java) och för felkorrigeringar. Det gick inte att avstå från detta, och i avsaknad av uppdateringar blev systemet i allmänhet 'långsamt' på grund av gamla versioner av interna komponenter.

Och självklart kunde inte programvaran uppdateras utan att köpa ett supportpaket.

Flexibelt tillvägagångssätt

Ett annat grundläggande krav gällde gränssnittet. Vi ville tillhandahålla tillgång till det via webbläsare från vilken plats som helst, utan krav på att en ingenjör måste vara på plats i datacentret. Dessutom strävade vi efter att skapa ett animerat gränssnitt så att infrastrukturen skulle vara mer visuell för jouringenjörer. 

Dessutom behövde det nya systemet stödja formler för beräkning av arbetet hos virtuella sensorer i tekniska system – till exempel för optimal fördelning av elektrisk effekt till utrustningsställ. För detta måste alla vanliga matematiska operationer som tillämpas på sensorernas indikatorer finnas tillgängliga. 

Dessutom krävdes åtkomst till SQL-databasen för att hämta nödvändig information om utrustningens prestanda – nämligen alla registreringar av övervakning för två tusen enheter och två tusen virtuella sensorer som genererar cirka 20 000 variabler. 

Det behövdes också en modulför utrustning i rack, som ger en grafisk representation av utrustningens placering i varje enhet, med beräkning av den totala vikten av "hårdvara", en enhetshuvudgrupp och detaljerad information om varje enhet. 

Överenskommelse om kravspecifikationen och undertecknande av kontrakt

Vid den tidpunkt då det var nödvändigt att börja arbetet på det nya systemet var kommunikationen med de "stora" företagen fortfarande långt ifrån att diskutera deras erbjudanden, så vi jämförde det mottagna erbjudandet med kostnaderna för att uppgradera det gamla BMS-systemet (se. den första delen), och som ett resultat visade det sig vara mer prisvärt och motsvara våra behov.

Valet var gjort.

Efter valet av entreprenör började advokaterna att utarbeta kontraktet, medan de tekniska teamen från båda sidor arbetade på kravspecifikationen. Som bekant är en detaljerad och noggrant upprättad kravspecifikation grunden för framgången i allt arbete. Ju mer konkret information i kravspecifikationen, desto mindre besvikelse såsom "men vi ville ha det på ett annat sätt".

Jag kommer att ge två exempel på nivån av detaljrikedom i kravspecifikationen:

1. Övervakande datacenter har befogenhet att lägga till nya enheter i BMS, oftast PDU-enheter. I det gamla BMS var det en "administratörsnivå" som också tillät att ändra inställningarna för variablerna för alla enheter, och det var omöjligt att separera funktionerna. Detta tillfredsställde inte oss. I den befintliga grundversionen av den nya plattformen var schemat liknande. Vi angav genast i kravspecifikationen att vi ville separera dessa roller: inställningarna ska endast ändras av en bemyndigad anställd, men de övriga bör fortfarande ha möjlighet att lägga till enheter. Detta schema antogs för genomförande.
2.  I varje standard BMS finns tre typiska kategorier av meddelanden: RÖD – måste reageras omedelbart, GUL – kan övervakas, BLÅ – "Informations". Vi har traditionellt använt "blå" meddelanden för att övervaka överskridanden av kommersiella parametrar, till exempel överskridande av effektuttaget för kundens rack. Denna typ av meddelanden var i vårt fall avsedd för chefer och var ointressant för driftavdelningen, men i den gamla BMS:en fyllde den regelbundet listan över aktiva incidenter och störde det operativa arbetet. Själva logiken och den färgkodade differentieringen av meddelandena tyckte vi var lyckad och behöll, men i kravspecifikationen angav vi särskilt att "blå" meddelanden skulle, utan att distrahera de jourhavande, tyst "regna" ned i en separat sektion där kommersiella specialister skulle ta hand om dem.

Med samma detaljnivå skapades format för grafritning och rapportering, gränssnittens konturer, en lista över enheter som behövde övervakas och många andra saker. 

Det var ett verkligt kreativt arbete av tre arbetsgrupper – beställartjänsten, som dikterade sina krav och villkor; tekniska specialister från båda sidor, vars uppgift var att omvandla dessa villkor till teknisk dokumentation; och programmerarteamet från entreprenören, som implementerade beställarens krav enligt den utvecklade tekniska dokumentationen… Slutligen anpassade vi något av våra mindre viktiga krav efter funktionaliteten i den redan existerande plattformen, medan entreprenören åtagit sig att skriva till något för oss. 

Samtidig drift av två system

Det var dags för genomförande. I praktiken innebar det att vi gav entreprenören möjlighet att driftsätta en prototyp av BMS i vår virtuella moln och gav nätverksåtkomst till alla enheter som krävde övervakning.

Vid denna tidpunkt var dock det nya systemet inte redo för drift. I detta skede var det viktigt för oss att behålla övervakningen i det gamla systemet och samtidigt ge tillgång till enheterna i det nya systemet. Det är omöjligt att bygga ett system ordentligt utan att se enheterna i det, vilket i sin tur inte kan kopplas bort från övervakningen av det gamla systemet. 

Om enheter skulle klara av samtidig begäran från två system var det inte uppenbart utan verkliga tester. Det fanns en risk att dubbel simultan begäran skulle leda till frekventa avbrott i svaren från enheterna, vilket skulle resultera i många felmeddelanden om otillgängliga enheter, vilket i sin tur skulle blockera den gamla övervakningssystemets funktion.

Nätverksavdelningen har kopplat virtuella rutter från prototypen av det nya BMS som distribuerades i molnet till enheterna, och vi fick resultaten: 

• enheterna kopplade via SNMP-protokollet föll praktiskt taget aldrig ur anslutningen på grund av samtidiga begärningar, 
• enheterna kopplade via gateways med modbas-TCP-protokoll hade problem som löstes genom ett rimligt minskande av frekvensen på deras begärningar.  

Och sedan fick vi se hur ett nytt system byggdes framför våra ögon; enheter vi redan kände igen dök upp, men i ett annat gränssnitt – bekvämt, snabbt och tillgängligt även från telefonen.

Vad som slutligen blev resultatet kommer vi att berätta om i del tre av vår artikel.

Källa: habr.com