Vi lanserte nye tjenester, trafikken vokste, erstattet servere, koblet til nye nettsteder og ombygde datasentre - og nå skal vi fortelle denne historien som vi introduserte deg for for fem år siden..
Fem år er en typisk tid for å summere opp delresultater. Derfor bestemte vi oss for å snakke om utviklingen av infrastrukturen vår, som de siste fem årene har gått gjennom en overraskende interessant utviklingsvei, som vi er stolte av. De kvantitative endringene vi har implementert har blitt til kvalitative, nå kan infrastrukturen operere i moduser som virket fantastiske i midten av det siste tiåret.
Vi sikrer driften av de mest komplekse prosjektene med de strengeste kravene til pålitelighet og belastning, inkludert PREMIER og Match TV. Sportssendinger og premiere på populære TV-serier krever trafikk i terabit/s, dette implementerer vi enkelt, og så ofte at det å jobbe med slike hastigheter for lengst er blitt vanlig for oss. Og for fem år siden var det tyngste prosjektet som kjørte på systemene våre Rutube, som siden har utviklet seg, økt volumer og trafikk, noe som måtte tas i betraktning ved planlegging av belastninger.
Vi snakket om hvordan vi utviklet maskinvaren til infrastrukturen vår () og utviklet et system som er ansvarlig for å laste opp videoer (), men det har gått mye tid siden disse tekstene ble skrevet, mange andre løsninger er laget og implementert, hvis resultater lar oss møte moderne krav og være fleksible nok til å tilpasse oss nye oppgaver.
Nettverkskjerne Vi utvikler oss hele tiden. Vi byttet til Cisco-utstyr i 2015, som vi nevnte i forrige artikkel. Den gang var det fortsatt den samme 10/40G, men av åpenbare grunner oppgraderte de etter noen år det eksisterende chassiset, og nå bruker vi aktivt 25/100G.
100G-koblinger har lenge verken vært en luksus (snarere er dette et presserende krav for tiden i vårt segment), eller en sjeldenhet (flere og flere operatører gir forbindelser med slike hastigheter). Imidlertid er 10/40G fortsatt relevant: gjennom disse koblingene fortsetter vi å koble operatører med en liten mengde trafikk, som det foreløpig er upassende å bruke en mer romslig port for.
Nettverkskjernen vi laget fortjener separat vurdering og vil bli tema for en egen artikkel litt senere. Der vil vi fordype oss i tekniske detaljer og vurdere logikken i handlingene våre når vi lager den. Men nå vil vi fortsette å tegne infrastrukturen mer skjematisk, siden din oppmerksomhet, kjære lesere, ikke er ubegrenset.
Videoutgangsservere utvikle seg raskt, noe vi tilbyr mye innsats for. Hvis vi tidligere hovedsakelig brukte 2U-servere med 4-5 nettverkskort med to 10G-porter hver, sendes nå mesteparten av trafikken fra 1U-servere, som har 2-3 kort med to 25G-porter hver. Kort med 10G og 25G er nesten like i pris, og raskere løsninger lar deg sende over både 10G og 25G. Resultatet var åpenbare besparelser: færre serverkomponenter og kabler for tilkobling - lavere kostnader (og høyere pålitelighet), komponenter tar mindre plass i racket - det ble mulig å plassere flere servere per enhetsareal og dermed lavere leiekostnader.
Men viktigere er gevinsten i fart! Nå kan vi sende mer enn 1G med 100U! Og dette er på bakgrunn av en situasjon der noen store russiske prosjekter kaller 40G-utgang fra 2U for en "prestasjon". Vi vil gjerne ha deres problemer!
Merk at vi fortsatt bruker generasjonen av nettverkskort som kun kan operere på 10G. Dette utstyret fungerer stabilt og er veldig kjent for oss, så vi kastet det ikke, men fant en ny bruk for det. Vi installerte disse komponentene i videolagringsservere, hvor ett eller to 1G-grensesnitt tydeligvis ikke er nok til å fungere effektivt; her viste 10G-kort seg å være relevante.
Lagringssystemer vokser også. I løpet av de siste fem årene har de endret seg fra tolv disker (12x HDD 2U) til trettiseks disker (36x HDD 4U). Noen er redde for å bruke slike romslige «skrotter», siden hvis et slikt chassis svikter, kan det være en trussel mot produktiviteten – eller til og med driftbarheten! – for hele systemet. Men dette vil ikke skje hos oss: vi har gitt sikkerhetskopiering på nivå med geodistribuerte kopier av data. Vi har distribuert chassiset til forskjellige datasentre - vi bruker tre totalt - og dette eliminerer forekomsten av problemer både ved feil i chassiset og når siden faller.
Selvfølgelig gjorde denne tilnærmingen maskinvare-RAID overflødig, noe vi forlot. Ved å eliminere redundans, økte vi samtidig systemets pålitelighet ved å forenkle løsningen og fjerne et av de potensielle feilpunktene. La oss minne deg på at våre oppbevaringssystemer er "hjemmelagde". Vi gjorde dette ganske bevisst og vi var helt fornøyd med resultatet.
Datasentre I løpet av de siste fem årene har vi endret oss flere ganger. Siden skrivingen av forrige artikkel har vi ikke endret bare ett datasenter - DataLine - resten krevde utskifting etter hvert som infrastrukturen vår utviklet seg. Alle overføringer mellom nettsteder var planlagt.
For to år siden migrerte vi inn i MMTS-9, og flyttet til et sted med høykvalitetsreparasjoner, et godt kjølesystem, stabil strømforsyning og uten støv, som tidligere lå i tykke lag på alle overflater og også tettet innsiden av utstyret vårt. . Velg kvalitetstjenester – og uten støv! – ble årsaken til flyttingen vår.
Nesten alltid «ett trekk tilsvarer to branner», men problemene under migrasjon er forskjellige hver gang. Denne gangen ble hovedvanskeligheten med å bevege seg innenfor ett datasenter "tilveiebrakt" av optiske kryssforbindelser - deres overflod mellom etasjer uten å bli kombinert til en enkelt kryssforbindelse av teleoperatører. Prosessen med å oppdatere og omdirigere kryssforbindelser (som MMTS-9-ingeniører hjalp oss med) var kanskje det vanskeligste stadiet i migreringen.
Den andre migreringen fant sted for et år siden; i 2019 flyttet vi fra et ikke særlig godt datasenter til O2xygen. Årsakene til flyttingen var lik de som ble diskutert ovenfor, men de ble supplert med problemet med uattraktiviteten til det opprinnelige datasenteret for teleoperatører - mange leverandører måtte "ta igjen" til dette punktet på egen hånd.
Migreringen av 13 stativer til et høykvalitetssted i MMTS-9 gjorde det mulig å utvikle denne lokasjonen ikke bare som en operatørs lokasjon (et par racks og "forwards" av operatører), men også å bruke den som en av de de viktigste. Dette forenklet til en viss grad migreringen fra et ikke særlig godt datasenter - vi fraktet det meste av utstyret fra det til et annet sted, og O2xygen fikk rollen som et utviklende, og sendte 5 rack med utstyr dit.
I dag er O2xygen allerede en fullverdig plattform, der operatørene vi trenger har "kommet" og nye fortsetter å koble seg til. For operatørene viste O2xygen seg også å være attraktivt med tanke på strategisk utvikling.
Vi gjennomfører alltid hovedfasen av flyttingen på én natt, og ved migrering innenfor MMTS-9 og til O2xygen, overholdt vi denne regelen. Vi understreker at vi strengt følger «flytt over natten»-regelen, uavhengig av antall stativer! Det var til og med en presedens da vi flyttet 20 stativer og fullførte dette også på en natt. Migrering er en ganske enkel prosess som krever nøyaktighet og konsistens, men det er noen triks her, både i forberedelsesprosessen, og ved flytting og ved utplassering til et nytt sted. Vi er klare til å snakke om migrering i detalj hvis du er interessert.
Funn Vi liker femårige utviklingsplaner. Vi har fullført byggingen av en ny feiltolerant infrastruktur fordelt på tre datasentre. Vi har økt trafikktettheten kraftig - hvis vi nylig var fornøyd med 40-80G med 2U, er nå normen for oss 100G med 1U. Nå oppfattes til og med en terabit trafikk av oss som vanlig. Vi er klare til å videreutvikle vår infrastruktur, som har vist seg å være fleksibel og skalerbar.
Spørsmål: Hva skal jeg fortelle dere om i de følgende tekstene, kjære lesere? Om hvorfor vi begynte å lage hjemmelagde datalagringssystemer? Om nettverkskjernen og dens funksjoner? Om triksene og finessene ved migrering mellom datasentre? Om å optimalisere leveringsbeslutninger ved å velge komponenter og finjustere parametere? Om å skape bærekraftige løsninger takket være flere redundanser og horisontale skaleringsmuligheter i et datasenter, som er implementert i en struktur med tre datasentre?
Forfatter: Petr Vinogradov - teknisk direktør for Uma.Tech
Kilde: www.habr.com