TL; DR: La teamo de Bloomberg Storage Engineering kreis nuban stokadon por interna uzo, kiu ne malhelpas infrastrukturon kaj povas elteni la pezan ŝarĝon de komerca volatilo dum la pandemio.
Mattew Leonard, parolante pri sia laboro kiel teknika manaĝero en la Bloomberg Storage Engineering-teamo, ofte uzas la vortojn "defia" kaj "amuzo". La defioj ŝprucas de la larĝa amplekso de stokado, de la plej novaj SAN-aroj bazitaj en NVMe ĝis malfermfonta programaro difinita stokado en DevOps. Ĉi tie komenciĝas la "amuzo" (vidu mian avataron ĉe Habré, ĉ. tradukisto).
Leonard kaj lia teamo de 25 kolegoj kontrolas pli ol 100 petabajtojn da kapacito kaj internan nubon por 6000 inĝenieroj disvolvantaj aplikojn por Bloomberg Terminal, la teknologio kiu faris Michael Bloomberg miliardulo. La teamo dizajnas, konstruas kaj prizorgas stokadsistemojn por Bloomberg Engineering.
Kiel la resto de la IT-profesio, 2020 estis nekutima jaro por membroj de la Stokada Inĝenieristiko-teamo ĉar COVID-19 devigis ilin labori malproksime. Leonard diris, ke la pandemio efikis sian "ligitan teamon" socie, ĉar vizaĝ-al-vizaĝaj interagoj estis eliminitaj, sed dungitaro tre rapide adaptiĝis al laboro hejme per tekkomputiloj kaj videokonferenco.
Mirinde, mi volas diri, ke ĉi tio ne plimalbonigis la aferojn. Okazis mallonga adaptperiodo - ne ĉiuj estis pretaj labori de hejme. Post unu aŭ du semajnoj ĉiuj komprenis tion. Ni povis trovi manierojn teni nin okupataj, aĉeti kaj ĝisdatigi ekipaĵon, kaj pliigi kostojn por subteni la kompanion dum ĉi tiuj tempoj. Ni devis esti kreivaj, sed ni ne vundiĝis
La plej granda defio eble antaŭis la pinton de COVID-19. Ĉi tio ŝuldiĝis al volatila merkatkomerco pro zorgoj pri la efiko de la pandemio al la tutmonda ekonomio. La volumo de datumoj fluantaj en Bloomberg-terminalojn de tutmondaj kapitalmerkatoj preskaŭ duobliĝis, atingante 240 miliardojn da informoj en kelkaj tagoj fine de marto. Ĉi tio estas serioza provo de stokaj sistemoj.
Kiam vi tuj duobligas viajn konservajn postulojn en unu tago, ĝi ja kreas interesajn problemojn. Ni povis venki ĉi tion kaj certigi, ke aplikaĵdisvolvaj teamoj ricevis la spacon kaj efikecon, kiujn ili bezonis. Plejparto de ĉi tio rilatas al kiel ni pensas pri stokadsistemoj. Hodiaŭ ni nenion kreas. Ni ne diras, "Ni uzas ABC, do ni konstruos la infrastrukturon por ABC." Ni faras tion, kion ni nomas "datumbuĝetado" kun niaj teamoj por antaŭvidi uzadon, analizi uzadon kaj agado-tendencojn, kaj ni ankaŭ rigardas sekurecon. Ĉi tiu tipo de planado, pensado kaj metoda devita diligento permesas al ni preni drastan agon kontraŭ pliiĝos sen ŝviti. Kompreneble, mi estis nervoza, sed mi sentis min komforta estante en mia loko.
Leonard lastatempe parolis kun SearchStorage detale pri administrado de stokado por datumaj entreprenoj. Li diskutis, kion necesus por oferti privatan nuban stokan solvon, kun la kapablo provizi AWS-funkciojn al siaj uzantoj konservante ajnajn datumojn en Bloomberg-datumcentroj.
Se ne plu ekzistas pandemio, kiajn malfacilaĵojn havas Bloomberg-inĝenieroj por administri stokadon?
Ni havas multajn bezonojn, ni simple estas ŝiritaj en malsamaj direktoj. Do ni devas provizi multajn malsamajn specojn de produktoj je malsamaj SLA-niveloj por helpi niajn programprogramistojn koncentriĝi pri siaj taskoj anstataŭ zorgi pri la stokado mem.
Kaj kian strategion vi sekvas por tio?
Parto de tio, kion ni provas fari, estas plibonigi konservadon. Pensu pri la AWS-modelo, kie evoluinĝeniero eniras, premas butonon, kaj tiam "klaku" magie ricevas la ĝustan stokan tipon por solvi sian problemon.
Kiel aspektas via stoka infrastrukturo?
Ĉar ni havas tre diversan ekosistemon kaj multajn malsamajn programistojn, ni ne povas proponi ununuran produkton. Ni havas objekton, dosieron kaj blokan stokadon. Ĉi tiuj estas malsamaj produktoj kaj ni ofertas malsamajn specojn de teknologioj por liveri ilin. Por blokado ni uzas SAN. Ni ankaŭ havas SDS, kiu provizas alian blokan stokado-opcion kun malsama aro de agado-postuloj. Por dosieroj ni uzas NFS. SDS ankaŭ estas uzita por objektostokado. La bloko kaj objektopartoj formas internan privatan nubon por komputado kaj stokado.
Do vi ne uzas publikan nuban stokadon?
Tio ĝustas. Iuj evoluigaj teamoj havas permeson uzi publikajn nubojn. Sed pro la naturo de nia komerco, ni preferas havi pli da kontrolo super la aferoj, kiuj forlasas niajn murojn. Do jes, ni havas niajn proprajn nubojn, kiuj estas sub nia kontrolo. Ĉi tio estas ekipaĵo situanta en nia datumcentro sub nia administrado.
En niaj datumcentroj, ni preferas mult-vendantan strategion. Ili estas grandaj provizantoj, sed ni ne diros, kiu ĝuste (estas la politiko de Bloomberg ne apogi neniun provizanton, ĉ. tradukisto).
Ĉu vi uzas hiperkonverĝan infrastrukturon por konstrui vian privatan nubon?
Ne. Ni ĉe Bloomberg elektas direkton, kie ni ne iras al hiperkonverĝo. Ni provas malkunligi komputadon de stokado por ke ni povu skali ilin sendepende. La direkto en kiu ni moviĝas, precipe kun nia nubo, estas ke ni povu apartigi tiujn du estaĵojn. Kaj ĉio ĉar iuj aferoj en nia lando postulas intensajn kalkulojn, dum aliaj postulas stokadon. Se vi skalas ilin egale, vi perdos rimedojn, negrave mono aŭ spaco en datumcentroj, aŭ aĉetante kapaciton, kiun vi ne bezonas. Tial ni ŝatas havi komunan interfacon inter la du estaĵoj, sed ke ili estu tute malsamaj sistemoj kaj administritaj de malsamaj teamoj.
Kiuj obstakloj devas esti venkitaj por konstrui privatan nubon?
Problemo de skalo. Kiel ĉe plej multaj aferoj, la diablo estas en la detaloj. Kiam vi pensas pri kiel ĉi tiuj aferoj funkcias, kiel igi ilin rezistemaj, kiel pritrakti la operacian ŝarĝon, kiel vi komunikas kun la fizikaj aktivaj teamoj, aferoj fariĝas iom interesaj. La defio estas trovi manieron fari ĉion skalebla kaj subtenebla produkto, kiun niaj aplikaĵprogramistoj dezirus uzi, povante riĉigi la funkciojn dum restado sur la avangardo de tio, kion faras la publika nubo. Kaj ankaŭ kunigi ĉion, por ke ĝi daŭre funkcias. Ĉi tiu estas nia ĉefa problemo - ni laboras trans ĉiuj areoj de la komerco, provante kontentigi ĉiujn bezonojn, sed ne ignorante aliajn bezonojn.
Ĉu vi pensas, ke vi bezonas la plej novajn funkciojn disponeblajn en AWS kaj aliaj publikaj nuboj?
La plej amuza fakto pri S3 estas, ke la vivnivelo konstante ŝanĝiĝas, novaj funkcioj estas ĉiam aldonitaj. Ĝi estas kvazaŭ nova ludilo. Se iu vidas novan funkcion en nova eldono, ili volas ĝin. Ne ĉiuj funkcioj de AWS estas aplikeblaj en nia medio, do gravas kaj interese scii, kio helpos programistojn kaj kiel akiri ĝin interne.
Kian stokajn ekipaĵojn vi uzas?
Ni uzas la plej novajn ekipaĵojn. Nia interna nubo estas tute bazita sur NVMe Flash, kio faras ĉi tiujn sistemojn tre potencaj. Ĝi faras nian vivon iomete pli facila, kaj ĝi ankaŭ estas bonega funkcio por niaj programistoj ĉar ili ne devas zorgi pri stokado-rendimento.
Por kio vi uzas konservadon de objektoj?
Ni havas 6000 programistojn laborantajn pri infrastrukturo, ili ne estas kunigitaj per iu ajn uzokazo. Ajna opcio, kiun vi povas pensi, ni verŝajne havas ĝin en objektostokado. Iuj teamoj uzas ĝin por malvarma arkiva stokado, iuj por transdono de datumoj, kaj aliaj, kiuj uzas ĝin por transakciaj aplikoj. Ĉiuj ĉi tiuj uzkazoj postulas malsamajn nivelojn de SLA, do kiel vi povas vidi, ni havas malsamajn specojn de trafiko, ĉiajn bezonojn por malsamaj uzantoj de nia infrastrukturo. Ĉi tio ne estas homogena uzkazo kuranta super iu ajn el nia stokado, kio evidente igas aferojn pli kompleksaj.
Kiom grandan rolon ludas Kubernetes kaj ujoj por vi, kaj kiel tio influas stokadon?
Ni puŝas stokan produktivecon por krei senton de nubo, senton de io-kiel-servo, kie estas butono por programistoj por akceli sian metion kaj forigi infrastrukturon laŭ la vojo.
Redaktoro n.b.: la 15-a de oktobro 2020 estos preta . Vi lernos retan stokadon de Ceph por uzi en viaj projektoj por plibonigi misfunkciadon.
Ni havas tri teamojn, la unua estas la stokada API-teamo. Ili faras programan aliron, finpunktojn kaj antaŭdifinitajn laborfluojn por app-disvolvaj klientoj ĉe Bloomberg. Ĉi tio estas teamo de plenstakaj retaj programistoj, ili uzas node.js, python, malfermfontajn teknologiojn, kiel Apache Airflow, do ili studas kontenerigon kaj virtualigon.
Ni ankaŭ havas du teknikajn teamojn, kiuj efektive movas la bitojn kaj bajtojn. Ili estas pli rekte rilataj al la ekipaĵo. Ni havas multajn ekipaĵojn, kaj ĉi tiuj teamoj ne uzas virtualigon kaj ujojn.
Ni provas sekvi tion, kio okazas en la industrio, studante la Kubernetes CSI-ŝoforojn, kaj ankaŭ laborante proksime kun la teamo efektiviganta Kubernetes ĉe Bloomberg por taksi ĉu ni povas fari Kubernetes-stokadon funkcii konsekvence kun la teknologioj kiujn ni havas, kaj ni havas ĝi funkcias. Ni uzas SDS por subteni Kubernetes konektitan al konstanta stokado. Ni sukcese evoluigis ĉi tiun teknologion, kaj diskutoj daŭras inter la du teamoj pri kiel ni povas disponigi ĉi tion al ĉiuj aliaj ĉe Bloomberg. Ni montris, ke tio estas tute ebla.
Kiun alian liberkodan programon vi uzas, precipe por stokado?
Ni uzas Apache Airflow, HAProxy por limigi aplikan trafikon. Ni ankaŭ uzas Ceph, platformon por SDS. Kun ĝi, vi povas havi unu sistemon por komandoj, sed provizi plurajn interfacojn al klientoj. Unu el la platformoj de virtualigo funkcias per OpenStack - ni laboras proksime kun ĉi tiu teamo. Ni havas malfermfontecan virtualigplatformon kiu uzas la malfermfontecan SDS-platformon por stokado. Estas amuza.
Kiajn konservajn teknologiojn vi pripensas por la venontaj du-tri jaroj?
Ni ĉiam esploras aliajn bonegajn novajn aferojn okazantajn en la stokadindustrio. Ĉi tio estas parto de nia laboro, ĝi ne estas "ĉi tie estas via SAN, administru ĉi tie, kaj jen via NFS, administru tie." Ni provas komuniki kun niaj klientoj, t.e. de niaj programistoj de aplikaĵoj. Ni kunlaboras por kompreni kiajn problemojn ili provas solvi kaj kiel ĝi influos niajn eksterajn klientojn de Bloomberg - la bankojn kaj aliajn, kiuj uzas nian programaron. Kaj tiam ni reiras en la mondon de datumstokado por trovi ŝancojn helpi ilin atingi sian celon. Kiel ni povas helpi ilin trovi la ĝustan stokan teknologion, kiu kongruas kun ilia SLA aŭ kion ili provas fari? Ĉar ni havas tiom da inĝenieroj farantaj bonegajn aferojn, ĝi neniam enuiĝas.
Ni nuntempe serĉas manierojn plibonigi rendimenton por SDS, kiuj eble povus funkcii per ĝeneraluzeblaj serviloj. Do ni laboras pri NVMe super TCP, ĉi tio estas tre interesa kaj bonega iniciato, unu el multaj. Ni ankaŭ laboras kun ĉefaj homoj en la industrio kaj iuj el la ekzistantaj provizantoj por ekscii, kion ili ofertas kaj kia estos la reala agado, ĉu ni povas komenci uzi ĝin en produktado en la kompanio. Ĉi tio malfermas novajn horizontojn, kiuj antaŭe ne estis alireblaj.
Iom da helpo en PS
PS Se mi permesas, mi ŝatus memorigi al vi, ke la 28-30-a de septembro okazos , por tiuj, kiuj ne konas Kubernetes, sed volas konatiĝi kun ĝi kaj eklabori kun ĝi.
fonto: www.habr.com