TL;DR: Команда 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 и контейнеры, а также как это влияет на хранилище?

Мы продвигаем продуктивизацию хранилища, чтобы создать чувство облачности, чувство что-либо-как-сервис, где есть кнопочка для разработчиков, позволяющая ускорить их мастерство и убрать инфраструктуру на этом пути.

N.B. редактора: 15 октября 2020 будет готов видео-курс по Ceph. Вы изучите технологию сетевого хранилища 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, это весьма интересная и крутая инициатива, одна из многих. Мы так же работаем с ключевыми людьми в отрасли и некоторыми поставщиками из уже существующих, чтобы узнать, что они предлагают и какая в реальности будет производительность, сможем ли мы начать ее использовать на производстве в компании. Это открывает новые горизонты, которые ранее не были доступы.