TL, д-р: Каманда Bloomberg Storage Engineering стварыла хмарнае сховішча для ўнутранага выкарыстання, якое не перашкаджае інфраструктуры і вытрымлівае вялікую нагрузку пры зменлівасці таргоў падчас пандэміі.
Mattew Leonard, распавядаючы аб сваёй працы ў якасці тэхнічнага мэнэджара ў камандзе Bloomberg Storage Engineering, часта выкарыстоўвае словы "складаны" і "пацешны". Складанасці ўзнікаюць з-за шырокага ахопу сховішчаў, пачынальна з найноўшых масіваў SAN на аснове NVMe і сканчаючы праграмна вызначанымі сховішчамі з адчыненым зыходным кодам у DevOps. Тут і пачынаюцца «забавы» (гл. мой аватар на Хабры, заўв. перакладчыка).
Leonard і яго каманда з 25 калегаў назіраюць за больш за 100 петабайтамі ёмістасці і ўнутраным воблакам для 6000 інжынераў, якія распрацоўваюць прыкладанні для Bloomberg Terminal – тэхналогію, якая зрабіла Michael Bloomberg мільярдэрам. Каманда праектуе, будуе і абслугоўвае сістэмы захоўвання даных для Bloomberg Engineering.
Як і астатнім спецыялістам у IT, 2020 год стаў незвычайным для чальцоў каманды Storage Engineering, паколькі COVID-19 вымусіў іх працаваць выдалена. Leonard сказаў, што пандэмія паўплывала на яго "згуртаваную каманду" у сацыяльным плане, паколькі сышлі асабістыя зносіны, але супрацоўнікі вельмі хутка прыстасаваліся да працы дома на наўтбуках і правядзенню відэаканферэнцый.
Дзіўна, але хачу сказаць, што ад гэтага не стала горш. Быў невялікі перыяд адаптацыі - не ўсе былі настроены на працу з дому. Праз тыдзень ці два ўсё гэта зразумелі. Мы змаглі знайсці спосабы прымусіць сябе працаваць, купіць і абнавіць абсталяванне, павялічыць выдаткі для падтрымкі кампаніі ў такі час. Нам прыйшлося праявіць творчы падыход, але мы не пацярпелі.
Самая вялікая складанасць, магчыма, узнікла яшчэ да піка COVID-19. Гэта было выклікана нестабільнасцю рынкавага гандлю з-за боязі наконт таго, што пандэмія паўплывае на сусветную эканоміку. Аб'ём дадзеных, якія паступаюць на тэрміналы Bloomberg з глабальных рынкаў капіталу, амаль падвоіўся, дасягнуўшы 240 урыўкаў інфармацыі ў некаторыя дні ў канцы сакавіка. Гэта сур'ёзнае выпрабаванне сістэм захоўвання.
Калі вы імгненна падвойваеце патрабаванні да сховішча на працягу аднаго дня, гэта сапраўды стварае цікавыя праблемы. Мы змаглі справіцца з гэтым і гарантаваць, што камандам распрацоўшчыкаў прыкладанняў прадастаўлены неабходнае прастору і прадукцыйнасць. Большасць гэтага звязана з нашымі думкамі аб сістэмах захоўвання. Сёння мы нічога не ствараем. Мы не кажам: "У нас выкарыстоўваецца ABC, таму мы створым інфраструктуру для ABC". Мы робім тое, што мы называем «бюджэтаваннем дадзеных» з нашымі камандамі для прагназавання выкарыстання, аналізу тэндэнцый выкарыстання і прадукцыйнасці, а таксама мы клапоцімся аб бяспецы. Такое планаванне, мысленне і метадычная комплексная праверка дазваляюць нам прымаць рэзкія меры пры воплесках нагрузкі, нават не спацеўшы. Я, вядома, нерваваўся, але мне было зручна быць на сваім месцы.
Леанард нядаўна падрабязна распавёў SearchStorage аб кіраванні сховішчам для бізнэсу, кіраванага дадзенымі. Ён абмеркаваў, што трэба, каб прапанаваць прыватнае воблака захоўвання, з магчымасцю падавання яго карыстачам функцый AWS, але захоўваючы пры гэтым любыя дадзеныя ў цэнтрах апрацоўкі дадзеных Bloomberg.
Калі ўжо няма пандэміі, якія ёсць складанасці з кіраваннем сховішчам у інжынераў Bloomberg?
У нас шмат патрэб, нас проста разрывае ў розныя бакі. Так што мы павінны даць шмат розных тыпаў прадуктаў на розных узроўнях SLA, каб дапамагчы нашым распрацоўшчыкам прыкладанняў засяродзіцца на іх задачах, замест клопату аб саміх сховішчах.
І якой стратэгіі вы для гэтага прытрымліваецеся?
Часткова мы спрабуем павысіць прадукцыйнасць захоўвання. Падумайце аб мадэлі AWS, у якой інжынер-распрацоўшчык заходзіць, цісне кнопку, а затым "пстрык" - чароўнай выявай атрымлівае патрэбны тып сховішчы для рашэння яго праблемы.
Як выглядае ваша інфраструктура захоўвання дадзеных?
Паколькі ў нас вельмі разнастайная экасістэма, а таксама ў нас мноства розных распрацоўшчыкаў, мы не можам прапанаваць адзіны прадукт. У нас ёсць аб'ектнае, файлавае і блокавае сховішчы. Гэта розныя прадукты, і мы прапануем розныя тыпы тэхналогій для іх прадастаўлення. Для блокавага мы выкарыстоўваем SAN. У нас таксама ёсць SDS, які прадстаўляе яшчэ адзін варыянт блокавага сховішча з іншым наборам патрабаванняў да прадукцыйнасці. Для файлаў мы выкарыстоўваем NFS. SDS таксама выкарыстоўваецца для аб'ектнага сховішчы. Часткі блокавага і аб'ектнага ўтвараюць унутранае прыватнае воблака для вылічэнняў і захоўвання.
Дык вы не выкарыстоўваеце публічныя хмарныя сховішчы?
Усё дакладна. Частка каманд-распрацоўшчыкаў маюць дазвол на выкарыстанне публічных аблокаў. Але з-за асаблівасцяў нашага бізнесу мы аддаем перавагу больш кіравання за тымі рэчамі, што пакідаюць нашы сцены. Так што так, у нас ёсць свае аблокі, якія знаходзяцца пад нашым кантролем. Гэта абсталяванне, размешчанае ў нашым датацэнтры пад нашым кіраваннем.
Мы ў нашых датацэнтрах аддаем перавагу стратэгіі многіх пастаўшчыкоў. Яны - буйныя пастаўшчыкі, але мы не будзем казаць, хто менавіта (такая палітыка Bloomberg - не падтрымліваць якога-небудзь пастаўшчыка, заўв. перакладчыка).
Вы карыстаецеся гіперканвергентнай інфраструктурай для пабудовы вашага прыватнага аблокі?
Не. Мы ў Bloomberg выбіраем напрамак, пры якім мы не рухаемся ў бок гіперканвергенцыі. Мы спрабуем аддзяліць вылічэнні ад захоўвання, каб мы маглі іх маштабаваць незалежна сябар ад сябра. Кірунак, у якім мы рухаемся, асабліва ў стаўленні нашага аблокі, складаецца ў тым, каб мы мелі магчымасць падзелу гэтых двух сутнасцяў. А ўсё таму, што ў нас некаторыя рэчы патрабуюць інтэнсіўных вылічэнняў, іншыя ж - сховішчы. Калі вы іх будзеце раўнамерна маштабаваць - страціце рэсурсы, усё роўна, грашовыя, або месца ў датацэнтрах, або купляючы магутнасці, якія вам не патрэбныя. Вось чаму нам падабаецца выкарыстоўваць агульны інтэрфейс паміж гэтымі двума сутнасцямі, але няхай яны ўяўляюць сабой цалкам розныя сістэмы і кіруюцца рознымі камандамі.
Якія перашкоды трэба пераадолець для пабудовы прыватнага аблокі?
Праблему маштабу. Як і ў большасці за ўсё - д'ябал крыецца ў дробязях. Калі вы думаеце наконт таго, як працуюць гэтыя рэчы, як зрабіць іх адмоваўстойлівасцю, як справіцца з эксплуатацыйнай нагрузкай, як вы маеце зносіны з камандамі, якія займаюцца фізічнымі актывамі — усё становіцца крыху цікавым. Задача складаецца ў тым, каб знайсці спосаб зрабіць усё які маштабуецца і падтрымоўваным прадуктам, які захацелі б выкарыстаць нашы распрацоўнікі прыкладанняў, маючы магчымасць узбагаціць набор функцый, застаючыся на вастрыі прагрэсу таго, што робяць публічныя аблокі. А таксама пасябраваць усё гэта так, каб яно працягвала працаваць. Гэта і ёсць наша асноўная праблема - мы працуем па ўсіх напрамках бізнесу, спрабуючы задаволіць усе патрэбы, але не ігнаруючы іншыя патрэбы.
Як думаеце, вам патрэбныя апошнія функцыі, даступныя ў AWS і іншых публічных аблоках?
Найбольш пацешны факт пра S3 – пастаянна зменлівы ўзровень жыцця, заўсёды дадаюцца новыя функцыі. Гэта як новая цацка. Калі хтосьці бачыць новую функцыю ў свежым выпуску - ён гэтага захоча. Не ўсе функцыі AWS дастасавальныя ў нашым асяроддзі, так што важна і цікава ведаць, што дапаможа распрацоўнікам і як гэта атрымаць на ўласных магутнасцях.
Якое абсталяванне для захоўвання вы карыстаецеся?
Мы прымяняем найноўшае абсталяванне. Наша ўнутранае воблака цалкам заснавана на NVMe Flash, што робіць гэтыя сістэмы вельмі прадукцыйнымі. Гэта робіць нашы жыцця крышачку прасцей, а таксама гэта прыемная функцыя для нашых распрацоўшчыкаў, паколькі яны могуць не клапаціцца аб прадукцыйнасці сховішчы.
Для чаго выкарыстоўваеце аб'ектнае сховішча?
У нас ёсць 6000 распрацоўшчыкаў, якія працуюць з інфраструктурай, яны не аб'яднаны па нейкім адным варыянце выкарыстання. Любы варыянт, аб якім вы можаце задумацца, верагодна ў нас ёсць у аб'ектным сховішчы. Частка каманд выкарыстоўвае яго ў якасці халоднага архіўнага захоўвання, некаторыя - для перадачы дадзеных, ёсць і тыя, хто выкарыстоўвае яго для транзакцыйных прыкладанняў. Усе гэтыя варыянты выкарыстання патрабуюць розныя ўзроўні SLA, таму, як бачыце, у нас ёсць розныя віды трафіку, любыя патрэбнасці для розных карыстальнікаў нашай інфраструктуры. Гэта не аднастайны варыянт ужывання, які працуе па-над любым нашым сховішчам, што відавочна ўскладняе задачу.
Наколькі вялікую ролю адыгрываюць для вас Kubernetes і кантэйнеры, а таксама як гэта ўплывае на сховішча?
Мы прасоўваем прадуктывізацыю сховішча, каб стварыць пачуццё воблачнасці, пачуццё штосьці-як-сэрвіс, дзе ёсць кнопачка для распрацоўшчыкаў, якая дазваляе паскорыць іх майстэрства і прыбраць інфраструктуру на гэтым шляху.
NB рэдактара: 15 кастрычніка 2020 года будзе гатовы . Вы вывучыце тэхналогію сеткавага сховішча Ceph, каб выкарыстоўваць у сваіх праектах для павышэння адмоваўстойлівасці.
У нас ёсць тры каманды, першая - каманда па API для сховішчаў. Яны робяць праграмныя доступы, канцавыя кропкі і наканаваныя працоўныя працэсы для кліентаў - распрацоўшчыкаў прыкладання ў Bloomberg. Гэта каманда full stack web-распрацоўнікаў, яны выкарыстоўваюць node.js, python, тэхналогіі з адчыненым зыходным кодам, напрыклад Apache Airflow, вось яны і вывучаюць кантэйнерызацыю і віртуалізацыю.
Таксама ў нас ёсць дзве тэхнічныя каманды, якія фактычна і ганяюць біты і байты. Яны больш звязаны напрамую з абсталяваннем. Абсталявання ў нас дастаткова шмат, а гэтыя каманды не выкарыстоўваюць віртуалізацыю і кантэйнеры.
Мы стараемся не адставаць ад таго, што адбываецца ў галіны, вывучаем драйвера Kubernetes CSI, а таксама цесна маем зносіны з камандай, якая ўкараняе Kubernetes у Bloomberg, каб ацаніць, ці зможам мы забяспечыць прыстойную працу сховішчы з Kubernetes з наяўнымі ў нас тэхналогіямі, і такі ў нас яно зарабіла . Мы ўжываем SDS для падтрымкі Kubernetes, падлучанага да ўстойлівага сховішча. Мы паспяхова адпрацавалі гэтую тэхналогію, паміж дзвюма камандамі працягваецца абмеркаванне таго, як мы гэта зможам зрабіць даступным усім астатнім у Bloomberg. Мы паказалі, што гэта цалкам рэальна.
Якое яшчэ ПЗ з адкрытым зыходным кодам вы карыстаецеся, у прыватнасці для сховішчаў?
Мы выкарыстоўваем Apache Airflow, HAProxy для абмежавання трафіку прыкладанняў. Мы таксама ўжываем Ceph, платформу для SDS. З ім можна мець адну сістэму для каманд, але даваць некалькі інтэрфейсаў кліентам. Адна з платформаў для віртуалізацыі працуе на OpenStack - мы блізка супрацоўнічаем з гэтай камандай. У нас ёсць платформа віртуалізацыі з адчыненым зыходным кодам, якая выкарыстоўвае для захоўвання платформу SDS з адчыненым зыходным кодам. Гэта пацешна.
Якія тэхналогіі захоўвання вы разглядаеце на наступныя два-тры гады?
Мы заўсёды вывучаем іншыя цікавыя новыя вешы, якія здараюцца ў галіне захоўвання дадзеных. Гэта частка нашай працы, гэта не "вось твая SAN, кіраваць тут, а вось твой NFS, кіраваць там". Мы стараемся размаўляць з нашымі кліентамі, г.зн. нашымі распрацоўшчыкамі прыкладанняў. Мы працуем сумесна, каб разумець, якія праблемы яны спрабуюць вырашыць, а таксама як гэта паўплывае на нашых знешніх кліентаў Bloomberg - банкі і іншыя структуры, якія выкарыстоўваюць наша ПЗ. А затым мы вяртаемся назад у свет захоўвання дадзеных, каб знайсці магчымасць дапамагчы ім дасягнуць іх мэты. Як мы можам дапамагчы ім знайсці правільную тэхналогію захоўвання, прыдатную пад іх SLA, альбо пад тое, што яны спрабуюць зрабіць? Паколькі ў нас настолькі шмат інжынераў, якія займаюцца крутымі рэчамі, гэта ніколі не дадзене.
Цяпер мы шукаем спосаб павышэння прадукцыйнасці для SDS, якія патэнцыйна змогуць працаваць на серверах агульнага прызначэння. Так мы працуем над NVMe па-над TCP, гэта вельмі цікавая і крутая ініцыятыва, адна з шматлікіх. Мы таксама працуем з ключавымі людзьмі ў галіны і некаторымі пастаўшчыкамі з ужо існуючых, каб даведацца, што яны прапануюць і якая ў рэальнасці будзе прадукцыйнасць, ці зможам мы пачаць яе выкарыстоўваць на вытворчасці ў кампаніі. Гэта адкрывае новыя гарызонты, якія раней не былі доступы.
Трохі карысці ў PS
PS Калі дазволіце, хачу нагадаць, 28-30 верасня пройдзе , для тых, хто не ведае Kubernetes, але хоча з ім пазнаёміцца і пачаць працаваць.
Крыніца: habr.com