TL; DR: Bloomberg Storage Engineering-teamet skapade molnlagring för internt bruk som inte stör infrastrukturen och som tål den tunga belastningen av handelsvolatilitet under pandemin.
När Mattew Leonard pratar om sitt arbete som teknisk chef på Bloomberg Storage Engineering-teamet, använder han ofta orden "utmanande" och "roligt". Utmaningarna uppstår från det breda omfånget av lagring, från de senaste NVMe-baserade SAN-arrayerna till mjukvarudefinierad lagring med öppen källkod i DevOps. Det är här det "roliga" börjar (se min avatar på Habré, cirka. översättare).
Leonard och hans team på 25 kollegor övervakar mer än 100 petabyte kapacitet och ett internt moln för 6000 XNUMX ingenjörer som utvecklar applikationer för Bloomberg Terminal, tekniken som gjorde Michael Bloomberg till miljardär. Teamet designar, bygger och underhåller lagringssystem för Bloomberg Engineering.
Liksom resten av IT-yrket var 2020 ett ovanligt år för medlemmar i Storage Engineering-teamet eftersom covid-19 tvingade dem att arbeta på distans. Leonard sa att pandemin hade påverkat hans "tight-knit team" socialt eftersom interaktioner ansikte mot ansikte eliminerades, men personalen hade anpassat sig mycket snabbt till att arbeta hemifrån på bärbara datorer och videokonferenser.
Förvånansvärt nog vill jag säga att detta inte gjorde saken värre. Det blev en kort anpassningstid – alla var inte redo att jobba hemifrån. Efter en eller två veckor förstod alla detta. Vi kunde hitta sätt att hålla oss sysselsatta, köpa och uppgradera utrustning och öka kostnaderna för att stödja företaget under dessa tider. Vi var tvungna att vara kreativa, men vi blev inte sårade
Den största utmaningen kan ha föregått toppen av covid-19. Detta berodde på volatil marknadshandel på grund av oro för pandemins inverkan på den globala ekonomin. Volymen av data som flödade in i Bloombergs terminaler från globala kapitalmarknader nästan fördubblades och nådde 240 miljarder bitar av information vissa dagar i slutet av mars. Detta är ett seriöst test av lagringssystem.
När du omedelbart fördubblar dina lagringskrav på en dag skapar det intressanta problem. Vi kunde övervinna detta och säkerställa att applikationsutvecklingsteamen fick det utrymme och den prestanda de behövde. Det mesta av detta har att göra med hur vi tänker kring lagringssystem. Idag skapar vi ingenting. Vi säger inte "Vi använder ABC, så vi bygger infrastrukturen för ABC." Vi gör vad vi kallar "databudgetering" med våra team för att prognostisera användning, analysera användning och prestandatrender, och vi tittar även på säkerhet. Denna typ av planering, tänkande och metodisk due diligence tillåter oss att vidta drastiska åtgärder vid överspänningar utan att svettas. Naturligtvis var jag nervös, men jag kände mig bekväm att vara på min plats.
Leonard pratade nyligen med SearchStorage i detalj om hantering av lagring för datadrivna företag. Han diskuterade vad som skulle krävas för att erbjuda en privat molnlagringslösning, med möjligheten att tillhandahålla AWS-funktioner till sina användare samtidigt som data bevaras i Bloombergs datacenter.
Om det inte längre finns en pandemi, vilka svårigheter har Bloombergs ingenjörer med att hantera lagring?
Vi har många behov, vi slits helt enkelt åt olika håll. Så vi måste tillhandahålla många olika typer av produkter på olika SLA-nivåer för att hjälpa våra applikationsutvecklare att fokusera på sina uppgifter istället för att oroa sig för själva lagringen.
Och vilken strategi följer du för detta?
En del av det vi försöker göra är att förbättra lagringsprestanda. Tänk på AWS-modellen där en utvecklingsingenjör går in, trycker på en knapp och sedan "klickar" på magiskt sätt får rätt lagringstyp för att lösa sitt problem.
Hur ser din lagringsinfrastruktur ut?
Eftersom vi har ett väldigt mångsidigt ekosystem och många olika utvecklare kan vi inte erbjuda en enda produkt. Vi har objekt-, fil- och blocklagring. Det är olika produkter och vi erbjuder olika typer av teknologier för att leverera dem. För block använder vi SAN. Vi har också SDS, som ger ytterligare ett blocklagringsalternativ med en annan uppsättning prestandakrav. För filer använder vi NFS. SDS används också för objektlagring. Block- och objektdelarna bildar ett internt privat moln för beräkning och lagring.
Så du använder inte offentlig molnlagring?
Det är rätt. Vissa utvecklingsteam har tillstånd att använda offentliga moln. Men på grund av vår verksamhets natur föredrar vi att ha mer kontroll över de saker som lämnar våra väggar. Så ja, vi har våra egna moln som är under vår kontroll. Detta är utrustning som finns i vårt datacenter under vår ledning.
I våra datacenter föredrar vi en strategi för flera leverantörer. De är stora leverantörer, men vi kommer inte att säga exakt vem (det är Bloombergs policy att inte godkänna någon leverantör, cirka. översättare).
Använder du hyperkonvergerad infrastruktur för att bygga ditt privata moln?
Nej. Vi på Bloomberg väljer en riktning där vi inte går mot hyperkonvergens. Vi försöker frikoppla beräkningar från lagring så att vi kan skala dem oberoende. Riktningen vi rör oss i, särskilt med vårt moln, är att vi ska kunna separera dessa två enheter. Och allt för att vissa saker i vårt land kräver intensiva beräkningar, medan andra kräver lagring. Om du skalar dem jämnt kommer du att förlora resurser, oavsett pengar, eller utrymme i datacenter, eller genom att köpa kapacitet som du inte behöver. Det är därför vi gillar att ha ett gemensamt gränssnitt mellan de två enheterna, men att de ska vara helt olika system och hanteras av olika team.
Vilka hinder måste övervinnas för att bygga ett privat moln?
Problem med skala. Som med det mesta sitter djävulen i detaljerna. När man tänker på hur dessa saker fungerar, hur man gör dem motståndskraftiga, hur man hanterar den operativa belastningen, hur man kommunicerar med de fysiska tillgångsteamen, blir saker lite intressanta. Utmaningen är att hitta ett sätt att göra allt till en skalbar och stödbar produkt som våra applikationsutvecklare skulle vilja använda, att kunna berika funktionerna samtidigt som de håller sig i framkant av vad det offentliga molnet gör. Och även att få ihop det hela så att det fortsätter att fungera. Detta är vårt huvudproblem - vi arbetar över alla delar av verksamheten, försöker tillfredsställa alla behov, men ignorerar inte andra behov.
Tror du att du behöver de senaste funktionerna tillgängliga i AWS och andra offentliga moln?
Det roligaste med S3 är att levnadsstandarden ständigt förändras, nya funktioner läggs alltid till. Det är som en ny leksak. Om någon ser en ny funktion i en ny version vill de ha den. Alla AWS-funktioner är inte tillämpliga i vår miljö, så det är viktigt och intressant att veta vad som hjälper utvecklare och hur man får det internt.
Vilken förvaringsutrustning använder du?
Vi använder den senaste utrustningen. Vårt interna moln är helt baserat på NVMe Flash, vilket gör dessa system väldigt kraftfulla. Det gör våra liv lite enklare, och det är också en trevlig funktion för våra utvecklare eftersom de inte behöver oroa sig för lagringsprestanda.
Vad använder du objektlagring till?
Vi har 6000 XNUMX utvecklare som arbetar med infrastruktur, de är inte förenade av ett enda användningsfall. Alla alternativ du kan tänka dig, vi har förmodligen det i objektlagring. Vissa team använder det för kall arkivlagring, vissa för dataöverföring och andra som använder det för transaktionsapplikationer. Alla dessa användningsfall kräver olika nivåer av SLA, så som du kan se har vi olika typer av trafik, alla typer av behov för olika användare av vår infrastruktur. Det här är inte ett homogent användningsfall som körs ovanpå någon av våra lagringar, vilket uppenbarligen gör saker och ting mer komplexa.
Hur stor roll spelar Kubernetes och containrar för dig, och hur påverkar det lagringen?
Vi driver på lagringsproduktiviteten för att skapa en känsla av moln, en känsla av något-som-en-tjänst, där det finns en knapp för utvecklare att påskynda sitt hantverk och ta bort infrastruktur längs vägen.
Redaktörens n.b.: 15 oktober 2020 kommer att vara klar . Du kommer att lära dig Ceph nätverkslagringsteknik att använda i dina projekt för att förbättra feltoleransen.
Vi har tre team, det första är lagrings-API-teamet. De skapar programmatisk åtkomst, slutpunkter och fördefinierade arbetsflöden för apputvecklingsklienter hos Bloomberg. Det här är ett team av webbutvecklare i full stack, de använder node.js, python, öppen källkodsteknik, såsom Apache Airflow, så de studerar containerisering och virtualisering.
Vi har också två tekniska team som faktiskt flyttar bitarna och byten. De är mer direkt relaterade till utrustningen. Vi har mycket utrustning, och dessa team använder inte virtualisering och behållare.
Vi försöker hålla jämna steg med vad som händer i branschen, studerar Kubernetes CSI-drivrutiner och arbetar också nära med teamet som implementerar Kubernetes på Bloomberg för att bedöma om vi kan få Kubernetes lagring att fungera konsekvent med de teknologier vi har, och vi har det fungerar. Vi använder SDS för att stödja Kubernetes anslutna till beständig lagring. Vi har framgångsrikt utvecklat den här tekniken, och diskussionerna fortsätter mellan de två teamen om hur vi kan göra detta tillgängligt för alla andra på Bloomberg. Vi har visat att detta är fullt möjligt.
Vilken annan programvara med öppen källkod använder du, särskilt för lagring?
Vi använder Apache Airflow, HAProxy för att begränsa applikationstrafiken. Vi använder även Ceph, en plattform för SDS. Med den kan du ha ett system för kommandon, men tillhandahålla flera gränssnitt till klienter. En av virtualiseringsplattformarna körs på OpenStack - vi arbetar nära detta team. Vi har en virtualiseringsplattform med öppen källkod som använder SDS-plattformen med öppen källkod för lagring. Det är roligt.
Vilka lagringstekniker överväger du för de kommande två till tre åren?
Vi tittar alltid på andra coola nya saker som händer inom lagringsbranschen. Det här är en del av vårt arbete, det är inte "här är ditt SAN, hantera här, och här är ditt NFS, hantera där." Vi försöker kommunicera med våra kunder, d.v.s. av våra applikationsutvecklare. Vi arbetar tillsammans för att förstå vilka problem de försöker lösa och hur det kommer att påverka våra externa Bloomberg-kunder - bankerna och andra som använder vår programvara. Och sedan går vi tillbaka till datalagringens värld för att hitta möjligheter att hjälpa dem att nå sina mål. Hur kan vi hjälpa dem att hitta rätt lagringsteknik som passar deras SLA eller vad de försöker göra? Eftersom vi har så många ingenjörer som gör coola saker blir det aldrig tråkigt.
Vi undersöker för närvarande sätt att förbättra prestanda för SDS som potentiellt kan köras på servrar för allmänna ändamål. Så vi jobbar på NVMe över TCP, det här är ett väldigt intressant och coolt initiativ, ett av många. Vi arbetar också med nyckelpersoner i branschen och några av de befintliga leverantörerna för att ta reda på vad de erbjuder och vad den faktiska prestandan blir, om vi kan börja använda den i produktionen i företaget. Detta öppnar upp för nya horisonter som tidigare inte var tillgängliga.
Lite hjälp i PS
PS Om jag får så vill jag påminna om att 28-30 september kommer att hållas , för de som inte känner till Kubernetes, men vill bekanta sig med det och börja arbeta med det.
Källa: will.com