TL; DR: Bloomberg Storage Engineering-teamet opprettet skylagring for intern bruk som ikke forstyrrer infrastrukturen og tåler den store belastningen av handelsvolatilitet under pandemien.
Når Mattew Leonard snakker om arbeidet sitt som teknisk sjef i Bloomberg Storage Engineering-teamet, bruker han ofte ordene «utfordrende» og «morsomt». Utfordringene oppstår fra det store omfanget av lagring, fra de nyeste NVMe-baserte SAN-arrayene til åpen kildekode-programvaredefinert lagring i DevOps. Det er her "moroa" begynner (se min avatar på Habré, ca. oversetter).
Leonard og hans team på 25 kolleger overvåker mer enn 100 petabyte med kapasitet og en intern sky for 6000 ingeniører som utvikler applikasjoner for Bloomberg Terminal, teknologien som gjorde Michael Bloomberg til milliardær. Teamet designer, bygger og vedlikeholder lagringssystemer for Bloomberg Engineering.
I likhet med resten av IT-profesjonen var 2020 et uvanlig år for medlemmer av Storage Engineering-teamet da COVID-19 tvang dem til å jobbe eksternt. Leonard sa at pandemien hadde påvirket hans "sammensveisede team" sosialt ettersom ansikt-til-ansikt-interaksjoner ble eliminert, men personalet hadde tilpasset seg veldig raskt til å jobbe hjemmefra på bærbare datamaskiner og videokonferanser.
Utrolig nok vil jeg si at dette ikke gjorde ting verre. Det var kort tilvenningsperiode – ikke alle var klare for å jobbe hjemmefra. Etter en uke eller to forsto alle dette. Vi var i stand til å finne måter å holde oss opptatt, kjøpe og oppgradere utstyr og øke kostnadene for å støtte selskapet i disse tider. Vi måtte være kreative, men vi ble ikke skadet
Den største utfordringen kan ha vært før toppen av COVID-19. Dette var på grunn av ustabil markedshandel på grunn av bekymringer om pandemiens innvirkning på den globale økonomien. Volumet av data som strømmet inn til Bloomberg-terminaler fra globale kapitalmarkeder ble nesten doblet, og nådde 240 milliarder opplysninger enkelte dager i slutten av mars. Dette er en seriøs test av lagringssystemer.
Når du øyeblikkelig dobler lagringskravene dine på én dag, skaper det interessante problemer. Vi var i stand til å overvinne dette og sikre at applikasjonsutviklingsteamene fikk plassen og ytelsen de trengte. Det meste av dette har å gjøre med hvordan vi tenker om lagringssystemer. I dag skaper vi ingenting. Vi sier ikke «Vi bruker ABC, så vi bygger infrastrukturen for ABC». Vi gjør det vi kaller «databudsjettering» med teamene våre for å forutsi bruk, analysere bruk og ytelsestrender, og vi ser også på sikkerhet. Denne typen planlegging, tenkning og metodisk due diligence lar oss ta drastiske tiltak på overspenninger uten å svette. Selvfølgelig var jeg nervøs, men jeg følte meg komfortabel med å være på plassen min.
Leonard snakket nylig med SearchStorage i detalj om administrasjon av lagring for datadrevne virksomheter. Han diskuterte hva som skulle til for å tilby en privat skylagringsløsning, med muligheten til å tilby AWS-funksjoner til brukerne mens de beholder data i Bloombergs datasentre.
Hvis det ikke lenger er en pandemi, hvilke problemer har Bloomberg-ingeniører med å administrere lagring?
Vi har mange behov, vi blir rett og slett revet i forskjellige retninger. Så vi må tilby mange forskjellige typer produkter på forskjellige SLA-nivåer for å hjelpe applikasjonsutviklerne våre med å fokusere på oppgavene sine i stedet for å bekymre seg for selve lagringen.
Og hvilken strategi følger du for dette?
Noe av det vi prøver å gjøre er å forbedre lagringsytelsen. Tenk på AWS-modellen der en utviklingsingeniør går inn, trykker på en knapp og deretter "klikk" på magisk vis får riktig lagringstype for å løse problemet sitt.
Hvordan ser lagringsinfrastrukturen din ut?
Fordi vi har et veldig mangfoldig økosystem og mange forskjellige utviklere, kan vi ikke tilby ett enkelt produkt. Vi har objekt-, fil- og blokklagring. Dette er forskjellige produkter og vi tilbyr forskjellige typer teknologier for å levere dem. For blokkering bruker vi SAN. Vi har også SDS, som gir et annet blokklagringsalternativ med et annet sett med ytelseskrav. For filer bruker vi NFS. SDS brukes også til lagring av objekter. Blokken og objektdelene danner en intern privat sky for databehandling og lagring.
Så du bruker ikke offentlig skylagring?
Det er riktig. Noen utviklingsteam har tillatelse til å bruke offentlige skyer. Men på grunn av virksomhetens natur, foretrekker vi å ha mer kontroll over tingene som forlater veggene våre. Så ja, vi har våre egne skyer som er under vår kontroll. Dette er utstyr plassert i vårt datasenter under vår ledelse.
I våre datasentre foretrekker vi en flerleverandørstrategi. De er store leverandører, men vi vil ikke si hvem nøyaktig (det er Bloombergs policy å ikke støtte noen leverandør, ca. oversetter).
Bruker du hyperkonvergert infrastruktur for å bygge din private sky?
Nei. Vi i Bloomberg velger en retning der vi ikke beveger oss mot hyperkonvergens. Vi prøver å koble fra databehandling fra lagring slik at vi kan skalere dem uavhengig. Retningen vi beveger oss i, spesielt med skyen vår, er at vi skal kunne skille disse to enhetene. Og alt fordi noen ting i vårt land krever intensive beregninger, mens andre krever lagring. Hvis du skalerer dem jevnt, vil du miste ressurser, uansett penger, eller plass i datasentre, eller ved å kjøpe kapasitet du ikke trenger. Det er derfor vi liker å ha et felles grensesnitt mellom de to enhetene, men at de skal være helt forskjellige systemer og administreres av forskjellige team.
Hvilke hindringer må overvinnes for å bygge en privat sky?
Skalaproblem. Som med de fleste ting, er djevelen i detaljene. Når du tenker på hvordan disse tingene fungerer, hvordan du gjør dem motstandsdyktige, hvordan du håndterer den operasjonelle belastningen, hvordan du kommuniserer med de fysiske aktivateamene, blir ting litt interessant. Utfordringen er å finne en måte å gjøre alt til et skalerbart og støttebart produkt som applikasjonsutviklerne våre ønsker å bruke, og være i stand til å berike funksjonssettet mens de holder seg i forkant av hva den offentlige skyen gjør. Og også å samle det hele slik at det fortsetter å fungere. Dette er vårt hovedproblem - vi jobber på tvers av alle områder av virksomheten, prøver å tilfredsstille alle behov, men ikke ignorere andre behov.
Tror du at du trenger de nyeste funksjonene som er tilgjengelige i AWS og andre offentlige skyer?
Det morsomste med S3 er at levestandarden er i konstant endring, nye funksjoner blir alltid lagt til. Det er som et nytt leketøy. Hvis noen ser en ny funksjon i en ny utgivelse, vil de ha den. Ikke alle AWS-funksjoner er aktuelle i miljøet vårt, så det er viktig og interessant å vite hva som vil hjelpe utviklere og hvordan man får det internt.
Hvilket lagringsutstyr bruker du?
Vi bruker det nyeste utstyret. Vår interne sky er fullstendig basert på NVMe Flash, noe som gjør disse systemene svært kraftige. Det gjør livene våre litt enklere, og det er også en fin funksjon for utviklerne våre fordi de ikke trenger å bekymre seg for lagringsytelsen.
Hva bruker du objektlagring til?
Vi har 6000 utviklere som jobber med infrastruktur, de er ikke forent av noen brukssak. Ethvert alternativ du kan tenke deg, vi har det sannsynligvis i objektlagring. Noen lag bruker det til kald arkivlagring, noen til dataoverføring og andre som bruker det til transaksjonsapplikasjoner. Alle disse brukstilfellene krever ulike nivåer av SLA, så som du kan se, har vi ulike typer trafikk, alle slags behov for ulike brukere av infrastrukturen vår. Dette er ikke en homogen brukssak som kjører på toppen av noen av lagringsplassene våre, noe som åpenbart gjør ting mer komplekse.
Hvor stor rolle spiller Kubernetes og containere for deg, og hvordan påvirker det lagring?
Vi presser lagringsproduktivitet for å skape en følelse av sky, en følelse av noe-som-en-tjeneste, hvor det er en knapp for utviklere for å akselerere håndverket og fjerne infrastruktur underveis.
Redaktørens NB: 15. oktober 2020 vil være klar . Du vil lære Ceph nettverkslagringsteknologi å bruke i prosjektene dine for å forbedre feiltoleransen.
Vi har tre team, det første er lagrings-API-teamet. De lager programmatisk tilgang, endepunkter og forhåndsdefinerte arbeidsflyter for apputviklingsklienter hos Bloomberg. Dette er et team av fullstack-webutviklere, de bruker node.js, python, åpen kildekode-teknologier, slik som Apache Airflow, så de studerer containerisering og virtualisering.
Vi har også to tekniske team som faktisk flytter bitene og bytene. De er mer direkte relatert til utstyret. Vi har mye utstyr, og disse teamene bruker ikke virtualisering og containere.
Vi prøver å holde tritt med hva som skjer i bransjen, studerer Kubernetes CSI-driverne, og jobber også tett med teamet som implementerer Kubernetes hos Bloomberg for å vurdere om vi kan få Kubernetes lagring til å fungere konsekvent med teknologiene vi har, og vi har det fungerer. Vi bruker SDS for å støtte Kubernetes koblet til vedvarende lagring. Vi har utviklet denne teknologien med suksess, og diskusjoner fortsetter mellom de to teamene om hvordan vi kan gjøre dette tilgjengelig for alle andre hos Bloomberg. Vi har vist at dette er fullt mulig.
Hvilken annen åpen kildekode-programvare bruker du, spesielt for lagring?
Vi bruker Apache Airflow, HAProxy for å begrense applikasjonstrafikk. Vi bruker også Ceph, en plattform for SDS. Med det kan du ha ett system for kommandoer, men gi flere grensesnitt til klienter. En av virtualiseringsplattformene kjører på OpenStack – vi jobber tett med dette teamet. Vi har en virtualiseringsplattform med åpen kildekode som bruker SDS-plattformen med åpen kildekode for lagring. Det er morsomt.
Hvilke lagringsteknologier vurderer du for de neste to til tre årene?
Vi ser alltid etter andre kule nye ting som skjer i lagringsbransjen. Dette er en del av arbeidet vårt, det er ikke "her er ditt SAN, administrer her, og her er din NFS, administrer der." Vi prøver å kommunisere med våre kunder, dvs. av våre applikasjonsutviklere. Vi jobber sammen for å forstå hvilke problemer de prøver å løse og hvordan det vil påvirke våre eksterne Bloomberg-kunder – bankene og andre som bruker programvaren vår. Og så går vi tilbake til datalagringens verden for å finne muligheter for å hjelpe dem med å nå målet sitt. Hvordan kan vi hjelpe dem med å finne den rette lagringsteknologien som passer deres SLA eller det de prøver å gjøre? Fordi vi har så mange ingeniører som gjør kule ting, blir det aldri kjedelig.
Vi ser for øyeblikket på måter å forbedre ytelsen for SDS som potensielt kan kjøre på servere for generell bruk. Så vi jobber med NVMe over TCP, dette er et veldig interessant og kult initiativ, ett av mange. Vi jobber også med nøkkelpersoner i bransjen og noen av de eksisterende leverandørene for å finne ut hva de tilbyr og hva den faktiske ytelsen blir, om vi kan begynne å bruke det i produksjonen i bedriften. Dette åpner for nye horisonter som tidligere ikke var tilgjengelige.
Litt hjelp i PS
PS Hvis jeg får lov, vil jeg minne om at 28.-30. september avholdes , for de som ikke kjenner Kubernetes, men ønsker å bli kjent med det og begynne å jobbe med det.
Kilde: www.habr.com