Hvad er BMS
Overvågningssystemet til driften af tekniske systemer i et datacenter er et nøgleelement i infrastrukturen, der direkte påvirker en så vigtig indikator for et datacenter som hastigheden af personalets reaktion på nødsituationer og følgelig varigheden af uafbrudt drift.
BMS (Building Monitoring System) overvågningssystemer tilbydes af mange globale leverandører af udstyr til datacentre. Under arbejdet i Linxdatacenter i Rusland havde vi mulighed for at stifte bekendtskab med forskellige systemer og støde på diametralt modsatte tilgange fra leverandører til driften af disse systemer.
Vi fortæller dig, hvordan vi fuldstændig har opdateret vores BMS-system i løbet af det seneste år og hvorfor.
Roden til problemet
Det hele startede for 10 år siden med lanceringen af datacentret Linxdatacenter i St. Petersborg. BMS-systemet var ifølge branchestandarder fra disse år en fysisk server med installeret software, tilgået via et klientprogram (den såkaldte "tykke" klient).
Der var få virksomheder, der tilbød sådanne løsninger på markedet på det tidspunkt. Deres produkter var standarden, det eneste svar på et eksisterende behov. Og vi skal give dem deres ret: Både dengang og i dag klarer markedsledere generelt deres grundlæggende opgave - at levere funktionelle løsninger til drift af datacentre.
Det logiske valg for os var BMS-løsningen fra en af verdens største producenter. Det valgte system på det tidspunkt opfyldte alle kravene til overvågning af en kompleks ingeniørfacilitet, såsom et datacenter.
Men over tid har brugernes (det vil sige os, datacenteroperatører) krav og forventninger til IT-løsninger ændret sig. Og store leverandører, som vist af en analyse af markedet for de foreslåede løsninger, var ikke klar til dette.
Erhvervs-IT-markedet har oplevet alvorlig indflydelse fra B2C-sektoren. Digitale løsninger skal i dag give en behagelig oplevelse for slutbrugeren – det er det mål udviklerne sætter sig. Dette er tydeligt i forbedringerne i brugergrænseflader (UI) og brugeroplevelse (UX) i mange virksomhedsapplikationer.
En person vænner sig til komforten ved alt, hvad der er relateret til digitale værktøjer i hverdagen, og stiller de samme krav til de værktøjer, som han bruger til arbejdsopgaver. Folk forventer af virksomhedsapplikationer den samme synlighed, intuitivitet, enkelhed og gennemsigtighed, som er tilgængelige for dem i finansielle tjenester, taxaopkald eller online shopping. IT-specialister, der implementerer løsninger i et virksomhedsmiljø, stræber også efter at modtage alle de moderne "godbidder": enkel implementering og skalering, fejltolerance og ubegrænsede tilpasningsmuligheder.
Store internationale leverandører overser ofte disse tendenser. Idet de stoler på deres mangeårige autoritet i branchen, viser virksomheder sig ofte at være kategoriske og ufleksible, når de arbejder med kunder. Illusionen om deres egen uundværlighed tillader dem ikke at se, hvordan unge teknologivirksomheder bogstaveligt talt dukker op under næsen på dem, og tilbyder alternative løsninger skræddersyet til en specifik kunde, og uden at betale for meget for brandet.
Ulemper ved det gamle BMS-system
Den største ulempe ved den eksisterende forældede BMS-løsning for os var dens langsomme drift. Undersøgelsen af flere hændelser, hvor vagthavende personale ikke reagerede hurtigt nok, fik os til at forstå, at der nogle gange var en betydelig forsinkelse i hændelser, der blev vist i BMS. Samtidig var systemet ikke overbelastet eller defekt, det var bare at versionerne af dets komponenter (for eksempel JAVA) var forældede og kunne ikke fungere korrekt med nye versioner af operativsystemer uden opdateringer. De kunne kun opdateres sammen med BMS-systemet, og leverandøren sørgede ikke for automatisk kontinuitet af versioner, det vil sige, at processen for os ville være næsten lige så arbejdskrævende som at skifte til et nyt system, og den nye løsning beholdt nogle af manglerne ved den gamle.
Lad os tilføje nogle flere ubehagelige "småting" her:
- Betaling for tilslutning af nye enheder efter princippet om "én IP-adresse - en betalt licens";
- Manglende evne til at opdatere software uden at købe en supportpakke (dette betyder opdatering af gratis komponenter og eliminering af fejl i selve BMS-programmet);
- Høje omkostninger til support;
- Placering på en "jern"-server, som kan fejle og har begrænsede computerressourcer;
- "Redundans" ved at installere en anden hardwareserver med en dublet licenspakke. Samtidig er der ingen synkronisering af databaser mellem hoved- og backup-serveren – hvilket betyder manuel databaseoverførsel og lang tid med overgang til backup;
- "Tyk" brugerklient, utilgængelig udefra, uden udvidelse til en mobilenhed og mulighed for fjernadgang;
- En strippet webgrænseflade uden grafikkort og lydmeddelelser, tilgængelig udefra, men praktisk talt ikke brugt af medarbejderne på grund af dens manglende information;
- Mangel på animation i grænsefladen - al grafik består kun af et "baggrunds" billede og statiske ikoner. Resultatet er et generelt lavt udsynsniveau;
Alt så nogenlunde sådan her ud:
- En begrænsning ved at skabe virtuelle sensorer er, at kun additionsfunktionen er tilgængelig, mens modeller af rigtige sensorer kræver evnen til at udføre et sæt matematiske operationer for korrekte beregninger, der afspejler driftens realiteter;
- Manglende evne til at indhente data i realtid eller fra arkivet til ethvert formål (for eksempel til visning på kundens personlige konto);
- Fuldstændig mangel på fleksibilitet og mulighed for at ændre noget i BMS'et, så det passer til eksisterende datacenterprocesser.
Krav til nyt BMS-system
Under hensyntagen til ovenstående var vores vigtigste krav som følger:
- To uafhængige gensidigt redundante maskiner med automatisk synkronisering, der kører på to forskellige cloud-platforme i forskellige datacentre (i vores tilfælde Linxdatacenter St. Petersburg og Moskva datacentre);
- Gratis tilføjelse af nye enheder;
- Gratis softwareopdateringer og dets komponenter (undtagen funktionelle forbedringer);
- Åben kildekode, der giver os mulighed for uafhængigt at understøtte systemet i tilfælde af problemer på udviklerens side;
- Muligheden for at modtage og bruge data fra BMS, for eksempel på en hjemmeside eller på din personlige konto;
- Adgang via WEB-browser uden en tyk klient;
- Brug af domænemedarbejderkonti til at få adgang til BMS;
- Tilgængelighed af animation og mange andre små og knap så små ønsker, der udmøntede sig i en detaljeret teknisk specifikation.
Sidste strå
I det øjeblik, hvor vi indså, at datacentret var vokset ud af sit BMS, forekom den mest oplagte løsning for os at opdatere det eksisterende system. "De skifter ikke hest midtvejs," vel?
Imidlertid tilbyder store virksomheder som regel ikke tilpassede ændringer til deres årtier gamle "polerede" løsninger, der sælges i snesevis af lande. Mens unge virksomheder tester en idé eller prototype af et fremtidigt produkt på potentielle forbrugere og stoler på brugerfeedback for at udvikle produktet, fortsætter virksomheder med at sælge licenser til et engang virkelig cool produkt, men desværre er det i dag forældet og ufleksibelt.
Og vi mærkede selv forskellen i tilgang. Under korrespondancen med producenten af det gamle BMS blev det hurtigt klart, at opdateringen af det eksisterende system foreslået af leverandøren faktisk ville resultere i køb af et nyt system til os med semi-automatisk databaseoverførsel, høje omkostninger og faldgruber under overførsel, som selv fabrikanten ikke selv kunne forudsige. Selvfølgelig steg omkostningerne til teknisk support til den opdaterede løsning i dette tilfælde, og behovet for at købe licenser under udvidelsen forblev.
Og det mest ubehagelige var, at det nye system ikke fuldt ud kunne opfylde vores reservationskrav. Det opdaterede BMS-system kunne implementeres, som vi ønskede, på en cloud-platform, hvilket ville give os mulighed for at opgive hardwaren, men redundansmuligheden var ikke inkluderet i prisen. For at sikkerhedskopiere dataene skal vi købe en anden virtuel BMS-server og et ekstra sæt licenser. Med prisen for en licens på omkring $76, og antallet af IP-adresser er 1000 enheder, tilføjer det op til $76 i ekstra udgifter kun for licenser til backupmaskinen.
"Kirsen" i den nye version af BMS var behovet for at købe yderligere licenser "til alle enheder" - selv til hovedserveren. Her er det nødvendigt at præcisere, at der er enheder forbundet til BMS gennem gateways. Gatewayen har én IP-adresse, men styrer flere enheder (10 i gennemsnit). I det gamle BMS krævede dette én licens pr. gateway-IP-adresse, statistikkerne så nogenlunde således ud: "1000 IP-adresser/licenser, 1200 enheder." Det opdaterede BMS fungerede efter et andet princip, og statistikken ville se sådan ud: "1000 IP-adresser, 1200 enheder/licenser." Det vil sige, at leverandøren i den nye version ændrede princippet om tildeling af licenser, og vi skulle købe cirka 200 yderligere licenser.
"Opdateringsbudgettet" bestod i sidste ende af fire punkter:
- omkostningerne ved cloud-versionen og migreringstjenester til den;
- yderligere licenser til den eksisterende pakke til enheder forbundet via gateways;
- omkostninger til backup af cloud-versionen;
- et sæt licenser til backupmaskinen.
De samlede omkostninger ved projektet var mere end $100! Og dette er ikke at nævne behovet for at købe licenser til nye enheder i fremtiden.
Som et resultat indså vi, at det ville være nemmere for os - og måske endda billigere - at bestille et system, der er skabt fra bunden, under hensyntagen til alle vores krav og giver mulighed for modernisering i fremtiden. Men dem, der ønskede at udvikle et så komplekst system, skulle stadig findes, sammenligne forslag, vælges og sammen med finalisten gå vejen fra tekniske specifikationer til implementering... Læs om dette i anden del af materialet meget snart.
Kilde: www.habr.com