TL; DR: Il team di Bloomberg Storage Engineering ha creato un cloud storage per uso interno che non interferisce con l'infrastruttura e può sopportare il pesante carico della volatilità degli scambi durante la pandemia.
Mattew Leonard, quando parla del suo lavoro come responsabile tecnico nel team Bloomberg Storage Engineering, usa spesso le parole “stimolante” e “divertente”. Le sfide derivano dall’ampio ambito dello storage, dai più recenti array SAN basati su NVMe allo storage open source definito dal software in DevOps. Qui inizia il “divertimento” (vedi il mio avatar su Habré, ca. traduttore).
Leonard e il suo team di 25 colleghi supervisionano più di 100 petabyte di capacità e un cloud interno per 6000 ingegneri che sviluppano applicazioni per Bloomberg Terminal, la tecnologia che ha reso Michael Bloomberg un miliardario. Il team progetta, costruisce e mantiene sistemi di storage per Bloomberg Engineering.
Come il resto della professione IT, il 2020 è stato un anno insolito per i membri del team Storage Engineering poiché il COVID-19 li ha costretti a lavorare da remoto. Leonard ha affermato che la pandemia ha avuto un impatto sociale sul suo “team affiatato” poiché le interazioni faccia a faccia sono state eliminate, ma il personale si è adattato molto rapidamente a lavorare da casa su laptop e videoconferenze.
Sorprendentemente, voglio dire che questo non ha peggiorato le cose. C'è stato un breve periodo di adattamento: non tutti erano pronti a lavorare da casa. Dopo una o due settimane tutti lo capirono. Siamo riusciti a trovare modi per tenerci occupati, acquistare e aggiornare le attrezzature e aumentare i costi per supportare l'azienda in questi periodi. Dovevamo essere creativi, ma non ci siamo fatti male
La sfida più grande potrebbe essere stata antecedente al picco del COVID-19. Ciò è dovuto alla volatilità degli scambi di mercato dovuta alle preoccupazioni sull’impatto della pandemia sull’economia globale. Il volume dei dati che fluiscono nei terminali Bloomberg dai mercati finanziari globali è quasi raddoppiato, raggiungendo i 240 miliardi di informazioni in alcuni giorni di fine marzo. Questo è un test serio per i sistemi di archiviazione.
Quando raddoppi istantaneamente i tuoi requisiti di archiviazione in un giorno, crei problemi interessanti. Siamo riusciti a superare questo problema e a garantire che ai team di sviluppo delle applicazioni venissero concessi lo spazio e le prestazioni di cui avevano bisogno. La maggior parte di ciò ha a che fare con il modo in cui pensiamo ai sistemi di storage. Oggi non stiamo creando nulla. Non diciamo: "Utilizziamo ABC, quindi costruiremo l'infrastruttura per ABC". Eseguiamo ciò che chiamiamo "budget dei dati" con i nostri team per prevedere l'utilizzo, analizzare le tendenze di utilizzo e prestazioni e guardiamo anche alla sicurezza. Questo tipo di pianificazione, riflessione e due diligence metodica ci consente di intraprendere azioni drastiche in caso di picchi senza sudare troppo. Certo, ero nervoso, ma mi sentivo a mio agio al mio posto.
Leonard ha recentemente parlato in dettaglio con SearchStorage della gestione dello storage per le aziende basate sui dati. Ha discusso di cosa sarebbe necessario per offrire una soluzione di archiviazione nel cloud privato, con la capacità di fornire funzionalità AWS ai propri utenti mantenendo tutti i dati nei data center Bloomberg.
Se non ci fosse più la pandemia, quali difficoltà avrebbero gli ingegneri di Bloomberg nella gestione dello storage?
Abbiamo molti bisogni, siamo semplicemente divisi in direzioni diverse. Dobbiamo quindi fornire molti tipi diversi di prodotti a diversi livelli di SLA per aiutare i nostri sviluppatori di applicazioni a concentrarsi sulle proprie attività invece di preoccuparsi dello storage stesso.
E quale strategia segui per questo?
Parte di ciò che stiamo cercando di fare è migliorare le prestazioni di archiviazione. Pensa al modello AWS in cui un ingegnere di sviluppo entra, preme un pulsante e quindi "clicca" ottiene magicamente il tipo di storage giusto per risolvere il suo problema.
Che aspetto ha la tua infrastruttura di storage?
Poiché abbiamo un ecosistema molto diversificato e molti sviluppatori diversi, non possiamo offrire un unico prodotto. Disponiamo di storage di oggetti, file e blocchi. Si tratta di prodotti diversi e offriamo diversi tipi di tecnologie per fornirli. Per il blocco utilizziamo SAN. Abbiamo anche SDS, che fornisce un'altra opzione di storage a blocchi con una serie diversa di requisiti prestazionali. Per i file utilizziamo NFS. SDS viene utilizzato anche per l'archiviazione di oggetti. Le parti del blocco e dell'oggetto formano un cloud privato interno per l'elaborazione e l'archiviazione.
Quindi non usi il cloud storage pubblico?
Giusto. Alcuni team di sviluppo sono autorizzati a utilizzare cloud pubblici. Ma a causa della natura della nostra attività, preferiamo avere un maggiore controllo sulle cose che escono dalle nostre mura. Quindi sì, abbiamo le nostre nuvole che sono sotto il nostro controllo. Si tratta di apparecchiature situate nel nostro data center sotto la nostra gestione.
Nei nostri data center preferiamo una strategia multi-vendor. Sono grandi fornitori, ma non diremo chi esattamente (è politica di Bloomberg non sostenere alcun fornitore, ca. traduttore).
Stai utilizzando un'infrastruttura iperconvergente per creare il tuo cloud privato?
NO. Noi di Bloomberg stiamo scegliendo una direzione in cui non ci stiamo muovendo verso l’iperconvergenza. Stiamo cercando di separare l'elaborazione dallo spazio di archiviazione in modo da poterli ridimensionare in modo indipendente. La direzione in cui ci stiamo muovendo, soprattutto con il nostro cloud, è che siamo in grado di separare queste due entità. E tutto perché alcune cose nel nostro Paese richiedono calcoli intensivi, mentre altre richiedono l'archiviazione. Se li ridimensioni in modo uniforme, perderai risorse, indipendentemente dal denaro, dallo spazio nei data center o acquistando capacità di cui non hai bisogno. Ecco perché ci piace avere un'interfaccia comune tra le due entità, ma che siano sistemi completamente diversi e gestiti da team diversi.
Quali ostacoli devono essere superati per costruire un cloud privato?
Problema di scala. Come per la maggior parte delle cose, il diavolo è nei dettagli. Quando pensi a come funzionano queste cose, a come renderle resilienti, a come gestire il carico operativo, a come comunichi con i team delle risorse fisiche, le cose diventano un po' interessanti. La sfida è trovare un modo per rendere tutto un prodotto scalabile e sostenibile che i nostri sviluppatori di applicazioni vorrebbero utilizzare, potendo arricchire il set di funzionalità rimanendo all'avanguardia di ciò che sta facendo il cloud pubblico. E anche per riunire il tutto affinché continui a funzionare. Questo è il nostro problema principale: lavoriamo in tutte le aree del business, cercando di soddisfare tutte le esigenze, ma senza ignorare le altre esigenze.
Pensi di aver bisogno delle funzionalità più recenti disponibili in AWS e altri cloud pubblici?
La cosa più divertente di S3 è che lo standard di vita è in continua evoluzione e vengono sempre aggiunte nuove funzionalità. È come un nuovo giocattolo. Se qualcuno vede una nuova funzionalità in una nuova versione, la vuole. Non tutte le funzionalità AWS sono applicabili nel nostro ambiente, quindi è importante e interessante sapere cosa aiuterà gli sviluppatori e come ottenerlo internamente.
Quali attrezzature di stoccaggio utilizzi?
Utilizziamo le attrezzature più moderne. Il nostro cloud interno è completamente basato su NVMe Flash, il che rende questi sistemi molto potenti. Ci semplifica la vita ed è anche una funzionalità interessante per i nostri sviluppatori perché non devono preoccuparsi delle prestazioni di archiviazione.
Per cosa usi l'archiviazione di oggetti?
Abbiamo 6000 sviluppatori che lavorano sull'infrastruttura, non sono uniti da nessun caso d'uso. Qualunque opzione ti venga in mente, probabilmente la abbiamo nell'archiviazione degli oggetti. Alcuni team lo utilizzano per l'archiviazione a freddo, alcuni per il trasferimento dei dati e altri ancora per applicazioni transazionali. Tutti questi casi d'uso richiedono diversi livelli di SLA, quindi, come puoi vedere, abbiamo diversi tipi di traffico, tutti i tipi di esigenze per diversi utenti della nostra infrastruttura. Questo non è un caso d'uso omogeneo eseguito su nessuno dei nostri storage, il che ovviamente rende le cose più complesse.
Che ruolo hanno per te Kubernetes e i container e che impatto hanno sullo storage?
Stiamo spingendo la produttività dello storage per creare un senso di cloud, un senso di qualcosa come servizio, in cui è disponibile un pulsante che consente agli sviluppatori di accelerare il proprio lavoro e rimuovere l'infrastruttura lungo il percorso.
N.B. dell'editore: Il 15 ottobre 2020 sarà pronto . Imparerai la tecnologia di archiviazione di rete Ceph da utilizzare nei tuoi progetti per migliorare la tolleranza agli errori.
Abbiamo tre team, il primo è il team dell'API di archiviazione. Realizzano accesso programmatico, endpoint e flussi di lavoro predefiniti per i clienti di sviluppo di app presso Bloomberg. Questo è un team di sviluppatori web full stack, usano node.js, python, tecnologie open source, come Apache Airflow, quindi studiano la containerizzazione e la virtualizzazione.
Abbiamo anche due team tecnici che spostano effettivamente i bit e i byte. Sono più direttamente correlati all'attrezzatura. Disponiamo di molte attrezzature e questi team non utilizzano virtualizzazione e contenitori.
Stiamo cercando di tenere il passo con ciò che accade nel settore, studiando i driver CSI di Kubernetes e lavorando a stretto contatto con il team che implementa Kubernetes a Bloomberg per valutare se possiamo far funzionare lo storage Kubernetes in modo coerente con le tecnologie di cui disponiamo, e abbiamo funziona. Utilizziamo SDS per supportare Kubernetes connesso allo storage persistente. Abbiamo sviluppato con successo questa tecnologia e continuano le discussioni tra i due team su come renderla disponibile a tutti gli altri in Bloomberg. Abbiamo dimostrato che ciò è del tutto possibile.
Quali altri software open source utilizzi, in particolare per l'archiviazione?
Utilizziamo Apache Airflow, HAProxy per limitare il traffico delle applicazioni. Utilizziamo anche Ceph, una piattaforma per SDS. Con esso, puoi avere un sistema per i comandi, ma fornire più interfacce ai client. Una delle piattaforme di virtualizzazione funziona su OpenStack: lavoriamo a stretto contatto con questo team. Disponiamo di una piattaforma di virtualizzazione open source che utilizza la piattaforma SDS open source per l'archiviazione. È divertente.
Quali tecnologie di storage state prendendo in considerazione per i prossimi due o tre anni?
Siamo sempre alla ricerca di altre novità interessanti che accadono nel settore dello storage. Questo fa parte del nostro lavoro, non è "ecco il tuo SAN, gestisci qui, ed ecco il tuo NFS, gestisci lì". Cerchiamo di comunicare con i nostri clienti, ad es. dai nostri sviluppatori di applicazioni. Lavoriamo insieme per capire quali problemi stanno cercando di risolvere e quale impatto avrà sui nostri clienti Bloomberg esterni: le banche e altri che utilizzano il nostro software. E poi torniamo nel mondo dell'archiviazione dei dati per trovare opportunità per aiutarli a raggiungere il loro obiettivo. Come possiamo aiutarli a trovare la tecnologia di storage più adatta al loro SLA o a ciò che stanno cercando di fare? Poiché abbiamo così tanti ingegneri che fanno cose interessanti, non diventa mai noioso.
Stiamo attualmente cercando modi per migliorare le prestazioni di SDS che potrebbero potenzialmente essere eseguiti su server generici. Quindi stiamo lavorando su NVMe su TCP, questa è un'iniziativa molto interessante e interessante, una delle tante. Stiamo anche lavorando con persone chiave del settore e con alcuni dei fornitori esistenti per scoprire cosa offrono e quali saranno le prestazioni effettive, se possiamo iniziare a utilizzarlo nella produzione dell'azienda. Ciò apre nuovi orizzonti che prima non erano accessibili.
Un piccolo aiuto in PS
PS Se posso permettervi ricordo che si terrà il 28-30 settembre , per coloro che non conoscono Kubernetes, ma vogliono conoscerlo e iniziare a lavorarci.
Fonte: habr.com