TL; DR: Zespół Bloomberg Storage Engineering stworzył pamięć masową w chmurze do użytku wewnętrznego, która nie koliduje z infrastrukturą i jest w stanie wytrzymać duże obciążenie zmiennością transakcji podczas pandemii.
Mattew Leonard, mówiąc o swojej pracy jako menedżera technicznego w zespole Bloomberg Storage Engineering, często używa słów „wyzwanie” i „zabawa”. Wyzwania wynikają z szerokiego zakresu pamięci masowej, od najnowszych macierzy SAN opartych na NVMe po pamięć masową zdefiniowaną programowo typu open source w DevOps. Tutaj zaczyna się „zabawa” (zobacz mój awatar na Habré, około. tłumacz).
Leonard i jego 25-osobowy zespół nadzorują ponad 100 petabajtów pojemności i wewnętrzną chmurę dla 6000 inżynierów tworzących aplikacje dla Bloomberg Terminal – technologii, która uczyniła Michaela Bloomberga miliarderem. Zespół projektuje, buduje i utrzymuje systemy magazynowania dla Bloomberg Engineering.
Podobnie jak reszta branży IT, rok 2020 był rokiem niezwykłym dla członków zespołu Inżynierii Magazynowania, ponieważ COVID-19 zmusił ich do pracy zdalnej. Leonard powiedział, że pandemia wpłynęła na jego „zgrany zespół” pod względem społecznym, ponieważ wyeliminowano interakcje twarzą w twarz, ale pracownicy bardzo szybko przystosowali się do pracy z domu na laptopach i wideokonferencji.
Co ciekawe, chcę powiedzieć, że to nie pogorszyło sytuacji. Okres adaptacyjny był krótki – nie wszyscy byli gotowi na pracę zdalną. Po tygodniu lub dwóch wszyscy to zrozumieli. Udało nam się znaleźć sposób na zajęcie się, zakup i modernizację sprzętu oraz zwiększenie kosztów, aby wesprzeć firmę w tych czasach. Musieliśmy wykazać się kreatywnością, ale nie odnieśliśmy kontuzji
Największe wyzwanie mogło nastąpić przed szczytem epidemii Covid-19. Było to spowodowane niestabilnością notowań na rynku wynikającą z obaw o wpływ pandemii na światową gospodarkę. Ilość danych napływających do terminali Bloomberga z globalnych rynków kapitałowych niemal się podwoiła, osiągając w niektóre dni pod koniec marca 240 miliardów informacji. To poważny test systemów pamięci masowej.
Gdy w ciągu jednego dnia natychmiast podwoisz zapotrzebowanie na pamięć masową, stwarza to interesujące problemy. Udało nam się przezwyciężyć ten problem i zapewnić zespołom zajmującym się tworzeniem aplikacji przestrzeń i wydajność, których potrzebowały. Większość z nich ma związek z tym, jak myślimy o systemach pamięci masowej. Dziś nic nie tworzymy. Nie mówimy: „Używamy ABC, więc zbudujemy infrastrukturę dla ABC”. Razem z naszymi zespołami przeprowadzamy coś, co nazywamy „budżetowaniem danych”, aby prognozować wykorzystanie, analizować trendy użytkowania i wydajności, a także przyglądamy się bezpieczeństwu. Ten rodzaj planowania, myślenia i metodycznego należytej staranności pozwala nam podejmować drastyczne działania w przypadku przepięć bez większego wysiłku. Oczywiście, denerwowałem się, ale czułem się komfortowo będąc na swoim miejscu.
Leonard niedawno szczegółowo rozmawiał z SearchStorage na temat zarządzania pamięcią masową w firmach opartych na danych. Omówił, czego potrzeba, aby zaoferować rozwiązanie do przechowywania danych w chmurze prywatnej z możliwością zapewnienia użytkownikom funkcji AWS przy jednoczesnym przechowywaniu dowolnych danych w centrach danych Bloomberg.
Jeśli nie ma już pandemii, jakie trudności mają inżynierowie Bloomberga z zarządzaniem magazynowaniem?
Mamy wiele potrzeb, jesteśmy po prostu rozdarci w różnych kierunkach. Musimy więc zapewnić wiele różnych typów produktów na różnych poziomach SLA, aby pomóc naszym twórcom aplikacji skoncentrować się na swoich zadaniach, zamiast martwić się o samą pamięć masową.
I jaką strategię w tym celu stosujesz?
Częścią tego, co staramy się zrobić, jest poprawa wydajności pamięci masowej. Pomyśl o modelu AWS, w którym wchodzi inżynier programista, naciska przycisk, a następnie „kliknięciem” w magiczny sposób wybiera odpowiedni typ pamięci masowej, aby rozwiązać swój problem.
Jak wygląda Twoja infrastruktura pamięci masowej?
Ponieważ mamy bardzo zróżnicowany ekosystem i wielu różnych programistów, nie możemy zaoferować jednego produktu. Mamy magazyn obiektów, plików i bloków. Są to różne produkty i oferujemy różne rodzaje technologii ich dostarczania. Do bloku używamy SAN. Mamy również SDS, który zapewnia inną opcję przechowywania blokowego z innym zestawem wymagań wydajnościowych. W przypadku plików używamy NFS. SDS jest również używany do przechowywania obiektów. Części blokowe i obiektowe tworzą wewnętrzną prywatną chmurę do przetwarzania i przechowywania.
Więc nie korzystasz z przestrzeni dyskowej w chmurze publicznej?
Zgadza się. Niektóre zespoły programistów mają uprawnienia do korzystania z chmur publicznych. Jednak ze względu na charakter naszej działalności wolimy mieć większą kontrolę nad tym, co opuszcza nasze ściany. Więc tak, mamy własne chmury, które są pod naszą kontrolą. Jest to sprzęt znajdujący się w naszym centrum danych pod naszym zarządem.
W naszych centrach danych preferujemy strategię obejmującą wielu dostawców. To duzi dostawcy, ale nie powiemy kto dokładnie (polityką Bloomberga jest nie polecanie żadnego dostawcy, około. tłumacz).
Czy korzystasz z infrastruktury hiperkonwergentnej do budowy swojej chmury prywatnej?
NIE. My w Bloomberg wybieramy kierunek, w którym nie zmierzamy w stronę hiperkonwergencji. Próbujemy oddzielić obliczenia od pamięci, abyśmy mogli skalować je niezależnie. Kierunek, w którym zmierzamy, szczególnie w przypadku naszej chmury, polega na tym, abyśmy mogli oddzielić te dwa podmioty. A wszystko dlatego, że niektóre rzeczy w naszym kraju wymagają intensywnych obliczeń, a inne wymagają przechowywania. Jeśli skalujesz je równomiernie, stracisz zasoby, niezależnie od pieniędzy, miejsca w centrach danych lub kupując pojemność, której nie potrzebujesz. Dlatego chcemy mieć wspólny interfejs między obydwoma podmiotami, ale żeby były to zupełnie różne systemy i były zarządzane przez różne zespoły.
Jakie przeszkody należy pokonać, aby zbudować chmurę prywatną?
Problem skali. Jak w przypadku większości rzeczy, diabeł tkwi w szczegółach. Kiedy pomyślisz o tym, jak te rzeczy działają, jak zapewnić im odporność, jak radzić sobie z obciążeniem operacyjnym, jak komunikujesz się z zespołami zajmującymi się zasobami fizycznymi, sytuacja staje się nieco interesująca. Wyzwanie polega na znalezieniu sposobu, aby wszystko stało się skalowalnym i wspieralnym produktem, z którego chcieliby korzystać nasi twórcy aplikacji, mając możliwość wzbogacenia zestawu funkcji, pozostając jednocześnie w czołówce tego, co robi chmura publiczna. A także połączyć to wszystko w jedną całość, aby nadal działało. To jest nasz główny problem – działamy we wszystkich obszarach działalności, starając się zaspokoić wszystkie potrzeby, ale nie ignorując innych.
Czy uważasz, że potrzebujesz najnowszych funkcji dostępnych w AWS i innych chmurach publicznych?
Najbardziej zabawnym faktem w S3 jest to, że standard życia stale się zmienia, ciągle dodawane są nowe funkcje. To jak nowa zabawka. Jeśli ktoś widzi nową funkcję w nowej wersji, chce jej. Nie wszystkie funkcje AWS mają zastosowanie w naszym środowisku, dlatego ważne i interesujące jest wiedzieć, co pomoże programistom i jak je zdobyć we własnym zakresie.
Jakiego sprzętu do przechowywania używasz?
Korzystamy z najnowocześniejszego sprzętu. Nasza wewnętrzna chmura jest całkowicie oparta na NVMe Flash, co czyni te systemy bardzo wydajnymi. Ułatwia nam to trochę życie, a także jest fajną funkcją dla naszych programistów, ponieważ nie muszą się martwić o wydajność pamięci.
Do czego wykorzystujesz pamięć obiektową?
Mamy 6000 programistów pracujących nad infrastrukturą, nie łączy ich żaden jeden przypadek użycia. Każda opcja, jaką przyjdzie Ci do głowy, prawdopodobnie mamy ją w magazynie obiektowym. Niektóre zespoły używają go do zimnego przechowywania archiwalnego, inne do przesyłania danych, a jeszcze inne do zastosowań transakcyjnych. Wszystkie te przypadki użycia wymagają różnych poziomów SLA, więc jak widać mamy różne rodzaje ruchu, wszelkiego rodzaju potrzeby dla różnych użytkowników naszej infrastruktury. Nie jest to jednorodny przypadek użycia działający na dowolnej naszej pamięci, co oczywiście komplikuje sprawę.
Jak dużą rolę odgrywa dla Ciebie Kubernetes i kontenery i jaki ma to wpływ na pamięć masową?
Zwiększamy produktywność pamięci masowej, aby stworzyć wrażenie chmury, czegoś jako usługi, w której programiści mają przycisk pozwalający przyspieszyć pracę i po drodze usunąć infrastrukturę.
Uwaga redaktora: 15 października 2020 r. będzie gotowy . Poznasz technologię sieciowej pamięci masowej Ceph, którą możesz wykorzystać w swoich projektach w celu poprawy odporności na awarie.
Mamy trzy zespoły. Pierwszy to zespół API pamięci masowej. Zapewniają dostęp programowy, punkty końcowe i predefiniowane przepływy pracy dla klientów zajmujących się tworzeniem aplikacji w Bloomberg. To zespół programistów webowych typu full-stack, używają node.js, python, technologii open source, takich jak Apache Airflow, więc studiują konteneryzację i wirtualizację.
Mamy także dwa zespoły techniczne, które faktycznie przenoszą bity i bajty. Są one bardziej bezpośrednio związane ze sprzętem. Mamy dużo sprzętu, a te zespoły nie korzystają z wirtualizacji i kontenerów.
Staramy się na bieżąco śledzić to, co dzieje się w branży, badając sterowniki Kubernetes CSI, a także ściśle współpracujemy z zespołem wdrażającym Kubernetes w Bloomberg, aby ocenić, czy uda nam się sprawić, aby pamięć masowa Kubernetes działała spójnie z posiadanymi technologiami i mamy to działa. Używamy SDS do obsługi Kubernetesa podłączonego do trwałej pamięci masowej. Pomyślnie opracowaliśmy tę technologię, a między obydwoma zespołami trwają dyskusje na temat tego, w jaki sposób możemy udostępnić ją wszystkim innym osobom w Bloomberg. Pokazaliśmy, że jest to całkiem możliwe.
Jakiego innego oprogramowania typu open source używasz, zwłaszcza do przechowywania danych?
Do ograniczenia ruchu aplikacji używamy Apache Airflow, HAProxy. Korzystamy również z Ceph, platformy dla SDS. Dzięki niemu możesz mieć jeden system poleceń, ale zapewniać klientom wiele interfejsów. Jedna z platform wirtualizacyjnych działa na OpenStack - z tym zespołem ściśle współpracujemy. Posiadamy platformę wirtualizacyjną typu open source, która wykorzystuje platformę SDS typu open source do przechowywania. To jest zabawne.
Jakie technologie przechowywania rozważacie na najbliższe dwa-trzy lata?
Zawsze przyglądamy się innym, nowym, fajnym rzeczom, które dzieją się w branży pamięci masowych. To część naszej pracy, a nie „tutaj jest Twoja sieć SAN, zarządzaj tutaj, a tutaj jest Twój NFS, zarządzaj tam”. Staramy się komunikować z naszymi klientami, tj. przez naszych twórców aplikacji. Współpracujemy, aby zrozumieć, jakie problemy próbują rozwiązać i jaki będzie to miało wpływ na naszych zewnętrznych klientów Bloomberg – banki i inne osoby korzystające z naszego oprogramowania. A potem wracamy do świata przechowywania danych, aby znaleźć możliwości, które pomogą im osiągnąć swój cel. Jak możemy pomóc im znaleźć odpowiednią technologię przechowywania danych, która będzie odpowiadać ich umowie SLA lub temu, co próbują zrobić? Ponieważ mamy tak wielu inżynierów, którzy robią fajne rzeczy, nigdy nie jest nudno.
Obecnie szukamy sposobów na poprawę wydajności oprogramowania SDS, które mogłoby potencjalnie działać na serwerach ogólnego przeznaczenia. Pracujemy więc nad NVMe przez TCP. To bardzo interesująca i fajna inicjatywa, jedna z wielu. Współpracujemy także z kluczowymi osobami w branży i niektórymi z istniejących dostawców, aby dowiedzieć się, co oferują i jaka będzie rzeczywista wydajność, czy będziemy mogli zacząć używać go w produkcji w firmie. Otwiera to nowe horyzonty, które wcześniej nie były dostępne.
Mała pomoc w PS
PS Jeśli można, przypominam, że w dniach 28-30 września odbędzie się , dla tych, którzy nie znają Kubernetesa, ale chcą się z nim zapoznać i zacząć z nim pracować.
Źródło: www.habr.com