TL; DR: Het Bloomberg Storage Engineering-team heeft cloudopslag voor intern gebruik gecreëerd die de infrastructuur niet verstoort en bestand is tegen de zware handelsvolatiliteit tijdens de pandemie.
Mattew Leonard gebruikt vaak de woorden ‘uitdagend’ en ‘leuk’ als hij het heeft over zijn werk als technisch manager bij het Bloomberg Storage Engineering-team. De uitdagingen komen voort uit de brede reikwijdte van opslag, van de nieuwste NVMe-gebaseerde SAN-arrays tot open source, softwaregedefinieerde opslag in DevOps. Dit is waar het “plezier” begint (zie mijn avatar op Habré, ca. vertaler).
Leonard en zijn team van 25 collega's houden toezicht op meer dan 100 petabytes aan capaciteit en een interne cloud voor 6000 ingenieurs die applicaties ontwikkelen voor Bloomberg Terminal, de technologie die Michael Bloomberg miljardair maakte. Het team ontwerpt, bouwt en onderhoudt opslagsystemen voor Bloomberg Engineering.
Net als de rest van het IT-vak was 2020 een ongebruikelijk jaar voor de leden van het Storage Engineering-team, omdat COVID-19 hen dwong om op afstand te werken. Leonard zei dat de pandemie sociale gevolgen had gehad voor zijn ‘hechte team’, omdat persoonlijke interacties waren geëlimineerd, maar het personeel had zich zeer snel aangepast aan het thuiswerken op laptops en videoconferenties.
Verbazingwekkend genoeg wil ik zeggen dat dit de zaken niet erger heeft gemaakt. Er was een korte aanpassingsperiode: niet iedereen was klaar om thuis te werken. Na een week of twee begreep iedereen dit. We hebben manieren gevonden om onszelf bezig te houden, apparatuur te kopen en te upgraden en de kosten te verhogen om het bedrijf in deze tijden te ondersteunen. We moesten creatief zijn, maar we raakten niet gewond
De grootste uitdaging dateert mogelijk van vóór de piek van COVID-19. Dit was te wijten aan de volatiele markthandel als gevolg van zorgen over de impact van de pandemie op de wereldeconomie. Het volume aan gegevens dat vanuit de mondiale kapitaalmarkten de Bloomberg-terminals binnenstroomde, is bijna verdubbeld en bereikte op sommige dagen eind maart 240 miljard stukjes informatie. Dit is een serieuze test van opslagsystemen.
Wanneer u uw opslagbehoefte op één dag onmiddellijk verdubbelt, levert dit interessante problemen op. We hebben dit kunnen overwinnen en ervoor gezorgd dat applicatieontwikkelingsteams de ruimte en prestaties kregen die ze nodig hadden. Het meeste hiervan heeft te maken met hoe we over opslagsystemen denken. Vandaag creëren we niets. We zeggen niet: "We gebruiken ABC, dus we zullen de infrastructuur voor ABC bouwen." We doen met onze teams wat we 'databudgettering' noemen om het gebruik te voorspellen, gebruiks- en prestatietrends te analyseren, en we kijken ook naar de beveiliging. Dit soort planning, denken en methodisch due diligence stelt ons in staat drastische maatregelen te nemen tegen pieken zonder te zweten. Natuurlijk was ik zenuwachtig, maar ik voelde me op mijn gemak op mijn plek.
Leonard sprak onlangs uitgebreid met SearchStorage over het beheer van opslag voor datagestuurde bedrijven. Hij besprak wat er nodig zou zijn om een private cloud-opslagoplossing aan te bieden, met de mogelijkheid om AWS-functies aan zijn gebruikers te bieden en tegelijkertijd alle gegevens in de Bloomberg-datacenters te bewaren.
Als er geen pandemie meer is, welke problemen hebben Bloomberg-ingenieurs dan met het beheer van de opslag?
We hebben veel behoeften, we worden eenvoudigweg in verschillende richtingen verscheurd. We moeten dus veel verschillende soorten producten op verschillende SLA-niveaus aanbieden om onze applicatieontwikkelaars te helpen zich op hun taken te concentreren in plaats van zich zorgen te maken over de opslag zelf.
En welke strategie volg je hiervoor?
Een deel van wat we proberen te doen is het verbeteren van de opslagprestaties. Denk aan het AWS-model waarbij een ontwikkelingsingenieur binnenkomt, op een knop drukt en vervolgens met een “klik” op magische wijze het juiste opslagtype krijgt om zijn probleem op te lossen.
Hoe ziet uw opslaginfrastructuur eruit?
Omdat we een zeer divers ecosysteem en veel verschillende ontwikkelaars hebben, kunnen we niet één product aanbieden. We beschikken over object-, bestands- en blokopslag. Dit zijn verschillende producten en we bieden verschillende soorten technologieën om deze te leveren. Voor blok gebruiken we SAN. We hebben ook SDS, dat nog een optie voor blokopslag biedt met een andere set prestatie-eisen. Voor bestanden gebruiken we NFS. SDS wordt ook gebruikt voor objectopslag. De blok- en objectonderdelen vormen een interne privécloud voor computergebruik en opslag.
U maakt dus geen gebruik van openbare cloudopslag?
Dat is juist. Sommige ontwikkelingsteams hebben toestemming om openbare clouds te gebruiken. Maar vanwege de aard van ons bedrijf hebben we liever meer controle over de dingen die onze muren verlaten. Dus ja, we hebben onze eigen wolken die onder onze controle staan. Het betreft apparatuur die zich in ons datacenter onder ons beheer bevindt.
In onze datacenters geven wij de voorkeur aan een multi-vendorstrategie. Het zijn grote leveranciers, maar we zullen niet zeggen wie precies (het is het beleid van Bloomberg om geen enkele leverancier te onderschrijven, ca. vertaler).
Maakt u gebruik van een hypergeconvergeerde infrastructuur om uw privécloud te bouwen?
Nee. Wij bij Bloomberg kiezen een richting waarin we niet op weg zijn naar hyperconvergentie. We proberen rekenkracht los te koppelen van opslag, zodat we ze onafhankelijk kunnen schalen. De richting waarin we ons bewegen, vooral met onze cloud, is dat we deze twee entiteiten kunnen scheiden. En dat allemaal omdat sommige dingen in ons land intensieve berekeningen vereisen, terwijl andere opslag vereisen. Als je ze gelijkmatig schaalt, verlies je middelen, ongeacht geld, of ruimte in datacenters, of door capaciteit te kopen die je niet nodig hebt. Daarom willen we graag een gemeenschappelijke interface tussen de twee entiteiten, maar dan wel totaal verschillende systemen en beheerd door verschillende teams.
Welke obstakels moeten worden overwonnen om een private cloud te bouwen?
Probleem van schaal. Zoals bij de meeste dingen zit de duivel in de details. Als je nadenkt over hoe deze dingen werken, hoe je ze veerkrachtig kunt maken, hoe je met de operationele belasting om moet gaan, hoe je communiceert met de teams voor fysieke activa, wordt het een beetje interessant. De uitdaging is om een manier te vinden om van alles een schaalbaar en ondersteunbaar product te maken dat onze applicatieontwikkelaars zouden willen gebruiken, waarbij we de functionaliteit kunnen verrijken en tegelijkertijd op de hoogte blijven van wat de publieke cloud doet. En ook om het allemaal bij elkaar te brengen, zodat het blijft werken. Dit is ons grootste probleem: we werken in alle geledingen van het bedrijf en proberen aan alle behoeften te voldoen, maar negeren andere behoeften niet.
Denk je dat je de nieuwste functies nodig hebt die beschikbaar zijn in AWS en andere publieke clouds?
Het leukste feit over S3 is dat de levensstandaard voortdurend verandert en er altijd nieuwe functies worden toegevoegd. Het is als nieuw speelgoed. Als iemand een nieuwe functie in een nieuwe release ziet, wil hij die hebben. Niet alle AWS-functies zijn toepasbaar in onze omgeving, dus het is belangrijk en interessant om te weten wat ontwikkelaars zal helpen en hoe je dit intern kunt krijgen.
Welke opslagapparatuur gebruikt u?
Wij maken gebruik van de nieuwste apparatuur. Onze interne cloud is volledig gebaseerd op NVMe Flash, wat deze systemen zeer krachtig maakt. Het maakt ons leven een beetje eenvoudiger, en het is ook een leuke functie voor onze ontwikkelaars omdat ze zich geen zorgen hoeven te maken over de opslagprestaties.
Waarvoor gebruikt u objectopslag?
We hebben 6000 ontwikkelaars die aan infrastructuur werken, ze zijn niet verenigd door één gebruiksscenario. Elke optie die u maar kunt bedenken, hebben wij waarschijnlijk in objectopslag. Sommige teams gebruiken het voor koude archiefopslag, sommige voor gegevensoverdracht en andere voor transactionele toepassingen. Al deze gebruiksscenario's vereisen verschillende SLA-niveaus, dus zoals u kunt zien, hebben we verschillende soorten verkeer en allerlei soorten behoeften voor verschillende gebruikers van onze infrastructuur. Dit is geen homogeen gebruik dat bovenop onze opslag draait, wat de zaken uiteraard complexer maakt.
Welke grote rol spelen Kubernetes en containers voor u, en welke impact heeft dat op de opslag?
We stimuleren de opslagproductiviteit om een gevoel van cloud te creëren, een gevoel van iets-als-een-service, waarbij er een knop is waarmee ontwikkelaars hun vak kunnen versnellen en gaandeweg de infrastructuur kunnen verwijderen.
Redacteur n.b.: 15 oktober 2020 zal klaar zijn . U leert Ceph-netwerkopslagtechnologie die u in uw projecten kunt gebruiken om de fouttolerantie te verbeteren.
We hebben drie teams, het eerste is het Storage API-team. Ze maken programmatische toegang, eindpunten en vooraf gedefinieerde workflows voor app-ontwikkelingsklanten bij Bloomberg. Dit is een team van full-stack webontwikkelaars, ze gebruiken node.js, python en open source-technologieën, zoals Apache Airflow, dus bestuderen ze containerisatie en virtualisatie.
We hebben ook twee technische teams die de bits en bytes daadwerkelijk verplaatsen. Ze houden meer direct verband met de apparatuur. We hebben veel apparatuur en deze teams maken geen gebruik van virtualisatie en containers.
We proberen op de hoogte te blijven van wat er in de branche gebeurt, bestuderen de Kubernetes CSI-drivers en werken ook nauw samen met het team dat Kubernetes bij Bloomberg implementeert om te beoordelen of we Kubernetes-opslag consistent kunnen laten werken met de technologieën die we hebben, en we hebben het werkt. We gebruiken SDS om Kubernetes te ondersteunen die zijn verbonden met permanente opslag. We hebben deze technologie met succes ontwikkeld en er zijn nog steeds discussies tussen de twee teams over hoe we dit beschikbaar kunnen maken voor alle anderen bij Bloomberg. Wij hebben laten zien dat dit heel goed mogelijk is.
Welke andere open source-software gebruikt u, vooral voor opslag?
We gebruiken Apache Airflow, HAProxy om applicatieverkeer te beperken. Ook maken wij gebruik van Ceph, een platform voor SDS. Hiermee kunt u één systeem voor opdrachten hebben, maar meerdere interfaces voor clients bieden. Eén van de virtualisatieplatforms draait op OpenStack – wij werken nauw samen met dit team. We hebben een open source virtualisatieplatform dat gebruik maakt van het open source SDS-platform voor opslag. Het is grappig.
Welke opslagtechnologieën overweegt u de komende twee tot drie jaar?
We zijn altijd op zoek naar andere coole nieuwe dingen die gebeuren in de opslagindustrie. Dit maakt deel uit van ons werk, het is niet “hier is uw SAN, beheer hier, en hier is uw NFS, beheer daar.” Wij proberen met onze klanten te communiceren, d.w.z. door onze applicatieontwikkelaars. We werken samen om te begrijpen welke problemen ze proberen op te lossen en welke impact dit zal hebben op onze externe Bloomberg-klanten - de banken en anderen die onze software gebruiken. En dan gaan we terug naar de wereld van dataopslag om mogelijkheden te vinden om hen te helpen hun doel te bereiken. Hoe kunnen we hen helpen de juiste opslagtechnologie te vinden die past bij hun SLA of bij wat ze proberen te doen? Omdat we zoveel ingenieurs hebben die coole dingen doen, wordt het nooit saai.
We onderzoeken momenteel manieren om de prestaties te verbeteren voor SDS die mogelijk op servers voor algemene doeleinden kunnen worden uitgevoerd. We werken dus aan NVMe via TCP, dit is een heel interessant en cool initiatief, een van de vele. We werken ook samen met sleutelfiguren in de branche en een aantal bestaande leveranciers om uit te zoeken wat zij aanbieden en wat de daadwerkelijke prestaties zullen zijn, en of we het in de productie van het bedrijf kunnen gaan gebruiken. Dit opent nieuwe horizonten die voorheen niet toegankelijk waren.
Een beetje hulp in PS
PS Als het mag, wil ik u eraan herinneren dat 28-30 september zal plaatsvinden , voor wie Kubernetes niet kent, maar er wel kennis mee wil maken en ermee aan de slag wil.
Bron: www.habr.com