Инфраструктура

Наш первый ЦОД в советском бомбоубежище особенности вычислений в бункере

10.11.2020 14:15:42 |

Автор: admin

В 2009 году мы заехали в гражданское бомбоубежище при заводе, которое давным-давно сняли с боевого дежурства. Внутри было сухо, почти чисто, стояли окрашенные бронедвери, и терпеливо ждал своего часа мирный советский дизель.

Тогда нам казалось, что место выбрано идеально. Мы знали, что Uptime Institute не даёт свои Tier-уровни подземным сооружениям, но это нас не останавливало. Угроза там в том, что бункер создаёт единую нерезервируемую точку отказа: всё может затопить разом. Поэтому мы начали с того, что сделали дополнительную гидроизоляцию по метро-технологиям, пробуривая отверстия в бетоне и заливая туда специальный состав, проникающий в бетон и заполняющий его поры.

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

Почему именно бомбоубежище? Ответ прост: это было идеальное место с доступом к электрическим мощностям завода, близко к оптоволоконным магистралям на MSK-IX и MSK-X. А ещё не было конкуренции за место, потому что вряд ли кто-то захотел бы для себя такой офис или склад. Ну и три контура охраны, поскольку завод всё ещё непростой, что в перспективе позволяло очень легко хранить персональные данные.

Что это за бомбоубежище?

Когда-то это было гражданское убежище для сотрудников завода, которые должны были пережить первые поражающие факторы бомбардировки. Похоже, оно проектировалось и строилось до появления точных представлений о ядерном оружии, кластерных боеприпасах и так далее, поэтому по современным меркам защищает разве что от катапульты. До огромных металлических помещений, висящих глубоко под землёй на цепях на случай вибраций, ему было очень далеко. Естественно, что его списали (это называется снятие с боевого дежурства), и оно стало просто неиспользуемой частью производственного комплекса.

Бомбоубежище представляет собой несколько небольших комнат, разделённых металлическими дверями. На входе шлюз с двумя гермодверями (его мы сохранили), и такие же двери отделяли части модуля друг от друга.

На фото наш первый модуль, где сейчас сконцентрированы серверы для предоставления VDS-услуг. Ещё есть выделенные серверы с аттестацией ФСТЭК и немного другого оборудования в других модулях убежища, но в целом они отличаются разве что размером.

Что нужно было сделать

В 2009 году мы получили помещение в долговременную аренду (это тоже очень важно для ЦОДа!). Все помещения были сухими: если была бы хоть капля влаги, то брать это место мы категорически не стали бы. Закачали раствор в стены, сделали дополнительную гидроизоляцию сверху в общем, довольно сильно провозились, но получили базовые гарантии, что стены герметичны. Сейчас мы поддерживаем стабильную влажность на уровне от 40 до 50 %, и скачков почти нет.

Вот так выглядит современный вход для людей и серверов:

После поворота спуск к комнате для сборки оборудования к рабочему месту дежурного и админов заказчика:

Сама комната выглядит так:

Сделали замкнутую систему вентиляции: в машзале избыточное давление, и воздух ходит по кругу, не возобновляясь. Тёплый коридор ведёт к теплообменнику, там воздух охлаждается и возвращается через холодный коридор к оборудованию. Первая трасса была фреоновая прямо до кондиционеров, дальше машзалы потребовали большей длины трассы (около 50 метров), и мы перешли на систему чиллер-фанкойл с гликолевым теплоносителем. Гликоль доставляет холод до теплообменника, теплообменник охлаждает рециркулируемый воздух, и всё повторяется.

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

Для входа внешних трасс очень подходила старая шахта лифта (лифт не ходил ещё со времён СССР). Когда-то он использовался для загрузки оборудования, но с первого взгляда стало понятно, что это будет шахта для коммуникаций, а не что-то для заноса серверов внутрь.

Электричество было от двух подстанций сразу, но нужно было построить щитовую внутри убежища и проложить трассы.

Пришлось сделать дополнительные отверстия в стенах и продолжить использовать шахту лифта.

Каждый ввод дублируется двумя дизелями. В общей сложности у нас нагрузка в пики потребляет 1 МВт, но дизелей больше нужного: один дополнительный купили от жадности, увидев слишком сладкую цену.

Первый дизель прямо на входе:

Ещё два дизеля в контейнерах снаружи:

Есть топливо (часто ЦОДы нашего размера не хранят собственное, а надеются на подвоз):

Ещё один дизель стоит в комнате для дизеля. Рядом стоит его советский коллега. Он, кстати, оказался вполне себе на ходу, то есть сделанным на совесть:

Пожаротушение газом на базе хладона, сигнализация типовая, не Vesda, конечно:

Под фальшполом тоже:

Стойки завезли через полгода после того, как нога человека вновь ступила в это помещение.

Оптика

Поначалу были две оптические линии, сейчас три независимые, проходящие тремя разными маршрутами в трёх разных канализациях. Общих участков нет, сходятся они уже в кроссовой. Вот тут виден один из входов линии:

Разумеется, имеющиеся коммуникации мы никак не использовали. А они были, конечно.

Был один яркий фейл. Один из админов настраивал свитч на MSK-IX и не сохранил конфиг по незнанию. Точнее, перезагрузил устройство, думая, что это не сбросит его состояние. На деле свитч выждал два часа, чтобы усыпить бдительность предполагаемого противника, а потом откатил конфиг до старого. Пришлось ехать в пять утра на такси, чтобы разбирать кольца.

Серверы

Оборудование моно-Хуавей, я уже писал, почему так.

Большинство дисков флешовые. Кое-где есть ещё HDD, но они очень редки. Из-за особенностей монолитного бетона и постоянно работающей вентиляции монотонные вибрации легко передаются по помещению в стойки, но мы гасим их через фальшпол.

На практике это означает, что нужно не только очень ответственно крепить HDD, не допуская люфта или перезатягивания креплений, но и соблюдать особые требования к вентиляторам и качеству их крепления внутри сервера. После давней проблемы с новым сервером, где плохо закреплённый вентилятор разболтал несколько дисков и привёл к разрушению RAID-массива, мы тщательно расследовали случай. Там посыпался сам диск, что в совокупности с вибрацией вентилятора вызвало повреждения соседних устройств. Заодно нашли ещё один риск пластик на турбинах вентиляторов. Он пересыхает, лопается, турбина разваливается на две части. Все кулеры на всём оборудовании были заменены на не подверженные этой проблеме на всякий случай.

Серверы Хуавея очень удобны для администрирования на месте: они показывают коды ошибок прямо на панелях. Вот этот работает хорошо:

Если что-то случится, то он покажет конкретную проблему и её место, например, слот со сбойной плашкой памяти. Вот здесь на момент съёмки наблюдается глитч с шестым диском, но, по данным мониторинга, с ним всё в порядке, индикация только на панели. Админ как раз обсуждает с инженерами Хуавея, в чём дело.

Питание в каждую стойку приходит независимо с двух векторов.

Админская в шаге от машзала, можно сразу же попасть к стойкам. На фото дежурный админ Костя, про него есть вот здесь:

В админской комнате у нас ремкомплекты. Вообще-то у нас гарантия от вендора next business day, но мы закупили свой набор комплектующих, чтобы поддерживать работу серверов здесь и сейчас, а не на следующий день.

Ещё у нас там остатки фермы из одного из подземных модулей:

Куча кабелей:

Продолжение трасс:

И нечто особенное. Вот оно:

Это устройство поставили при получении лицензии ФСТЭК. Оно создаёт помеху для прослушивания. Вообще-то оно нужно для того, чтобы с оконного стекла нельзя было считать звук голоса с помощью лазера, но у нас нет окон. Но, тем не менее, во всех прилегающих к ЦОДу помещениях можно проводить важные переговоры: оборудование для электромагнитных и звуковых помех есть. При его включении работа связи и серверов не нарушается.

Лицензию мы получали целый год. У нас техзащита (то есть инфраструктура, а не разработка). Специальная компания проверяла помещения на предмет защиты с точки зрения проникновения чужих лиц. Их интересовали физическая охрана, контроль доступа. На производственном комплексе с этим очень гладко: три периметра, и даже своё оборудование завозить и вывозить достаточно сложно. Дальше интересовало, где стоит оборудование: исключена ли прослушка. Ещё аттестат подразумевает наличие аттестованных маршрутизаторов-файрволлов, которые исключают перехват информации с сервера, который этот маршрутизатор обслуживает. Эти специальные устройства не обслуживают всех клиентов, у них узкая пропускная способность. Ну и мало кому понравится, что он без спроса защищён таким образом. За этой услугой обращаются госкомпании, окологосударственные компании либо крупные компании с хорошим классом персданных. Для них это важно.

Поскольку само помещение аттестовано, мы имеем право закупить под их нужды сертифицированное оборудование (просто так защищённый коммутатор не купишь: он должен быть произведён специально). Без подобной лицензии такие работы не провести. Мы при этом исходим из того, что услуга аттестованного облака нужна большим заказчикам под узкие нужды. Есть несколько клиентов, для которых мы разработали стек от начала и до конца. И помогли с аттестацией уже готовой инсталляции, и они получили аттестат на свои облака под нормативы ФСТЭК.

Администрирование серверов при пропадании доступа можно делать вот с такой консоли:

Но у Хуавея есть удобный VLAN с сервисными портами, который можно развернуть и получать доступ сразу ко всему, поэтому тележку мы катаем относительно редко.

Итого

Мы продолжаем работы по улучшению живучести ЦОДа. Сейчас два луча питания, каждый задублирован дизелями с избытком, есть своё топливо. Две пожарные сигнализации, два набора датчиков. Вентиляция дублированная, используется воздух без обмена с внешней средой, давление избыточное. Машзалы надёжно спрятаны под землю и бетон, всё это гидроизолировано, а крыша двойная со стоками, внутри понатыканы датчики протечек. Внутри круглосуточная смена. Снаружи три кольца физической охраны. Две линии питания и два упса до каждого сервера. По сетевухам есть резервирование в соседние свитчи в соседних стойках. Набор для смены диска в RAID-массиве есть на месте, весь горячий ЗИП тоже. Гарантия вендора.

Относительно работы внутри: благодаря тому, что мы оставили несколько гермодверей, жуткий шум вентиляции почти не передаётся в админскую. Первые пять визитов в ЦОД, конечно, имеют привкус ада из-за пугающей мрачной обстановки, но потом легко привыкнуть.

В общем, из имеющихся ресурсов выжали максимум. Можно и больше, но это увеличит цену VDS-хостинга, поэтому это разумный компромисс между зашкаливающей паранойей и экономикой. У нас есть похожие по уровню защиты ЦОДы в других странах, например, инсталляция в Швейцарии в бункере тоже с тремя кольцами охраны, но именно этот ЦОД наш, и мы его очень любим.

Ближайшие работы перебрать питание, разложить всё аккуратнее, потому что накопился кавардак. Нужны ещё упсы для гермозоны.

Теперь вы увидели то, что скрывается под одной из десятка кнопок выбора ЦОДа для вашего виртуального сервера.

Подробнее..

Категории: Блог компании ruvds.com , It-инфраструктура , Инженерные системы , Цод , Управление проектами , Хостинг , Инфраструктура , Дата-центр

Как атаковали промышленную инфраструктуру на The Standoff анализ трафика с помощью PT ISIM

25.02.2021 18:11:56 |

Автор: admin

На прошедшем The Standoff эксперты PT Expert Security Center, в данном случае представляющие команду глобального SOC киберполигона, мониторили действия команд атакующих и защитников цифровой копии мегаполиса FF, противостояние проходило в режиме реального времени и длилось 123 часа. Ранее мы писали о том, как глобальный SOC следил за всем происходящим в инфраструктуре виртуального города, как отдел обнаружения вредоносного ПО вылавливал и исследовал троянские программы редтимеров с помощью песочницы PT Sandbox и как мы следили за всеми веб-ресурсами киберполигона с помощью PT Application Firewall. Теперь поговорим о защищенности технологических сетей объектов виртуального города и результатах мониторинга, проведенного с помощью системы глубокого анализа технологического трафика PT Industrial Security Incident Manager (PT ISIM).

В этой статье мы расскажем о том, какие атаки на технологический сегмент сети объектов города детектировала система, и отметим, насколько эти угрозы соответствуют реальному уровню защищенности промышленных систем.

Что атаковали на The Standoff

Макет города на киберполигоне The Standoff включал в себя цифровые копии объектов инфраструктуры, управляемые настоящими SCADA-системами и ПЛК: точно такие же устанавливают на реальных предприятиях. Вот элементы и объекты, которые могли атаковать участники соревнований от read teams:

системы управления стрелками и шлагбаумами на железной дороге,
багажная лента в аэропорту,
телескопический трап в аэропорту,
кран в морском порту,
HVAC делового центра,
колесо обозрения в парке развлечений,
светофоры в деловом центре,
уличное освещение,
подстанция (электричество всего города),
задвижки автоматизированной газораспределительной станции,
турбина ТЭЦ,
шкаф пожарной автоматики ТЭЦ,
ветрогенераторные установки на электростанции,
системы управления производством на нефтехимическом заводе,
системы управления добычей нефти.

Теперь рассмотрим самые интересные, как нам кажется, атаки, которые глобальный SOC The Standoff детектировал с помощью PT ISIM.

Остановка добычи нефти

Команды Back2oaz и Сodeby смогли успешно атаковать компанию Nuft, которая в рамках модели города управляла нефтедобывающим месторождением. Участники red teams получили доступ к серверу SCADA и отправили команды по специализированному промышленному протоколу, что привело к аварии остановке процесса добычи нефти. В реальности реализация такого бизнес-риска привела бы к репутационному ущербу, недополучению прибыли и падению рыночной стоимости компании.

Цепочка развития атаки выглядела так:

Неавторизованное подключение по RDP от узла из сегмента серверов 172.20.61.2 к серверу SCADA 172.20.22.11 (время 01:30). На данном этапе был получен доступ к SCADA-системе.

Подача команды управления по протоколу CIP от сервера SCADA 172.20.22.11 к ПЛК 172.20.23.11 (09:02). На данном этапе выполнялся перебор различных команд управления (команды подавались в разные области, в том числе в проприетарные: 0x349, 0x68 (SFC Forces), 0x6b (SymbolObject)). Это может говорить о том, что атака выполнялась с помощью инженерного или специализированного атакующего ПО.

Подключение по RDP

Перебор команд CIP

Инцидент об управляющем воздействии

В данном случае имело место управляющее воздействие по протоколу CIP. При этом атакующие, судя по всему, подбирали команды вслепую. Защитники в этой ситуации должны были предпринимать активные действия уже на предыдущих, ранних этапах атаки, которые были обнаружены с помощью MaxPatrol SIEM, PT Sandbox, PT NAD и PT ISIM. Естественно, по условиям учений производилось только наблюдение. После проникновения в сегмент АСУ ТП у защитников было очень мало времени для реакции на данную атаку, потому что со стороны наблюдателя все выглядело вполне легитимно: с управляющего АРМ или со SCADA-сервера подается легитимная команда на остановку или на изменение уставки.

В данном случае можно было бы рассчитывать на механизм белых списков команд протокола, при использовании которого подбор команд злоумышленниками был бы обнаружен. Опять же, если нарушитель владеет данными об атакуемом объекте, то он не будет заниматься перебором, а сразу отдаст опасную команду. В реальной жизни пока чаще встречаются сбои в работе систем и, как следствие, прохождение в сети опасных команд или данных, что удается выявить с помощью систем непрерывного анализа технологического трафика и уже упомянутых белых списков.

Запредельные обороты колеса обозрения

Была в городе FF и компания 25 Hours, которая по сценарию владела парком развлечений. Ей пришлось столкнуться с атакой команды Back2oaz, в ходе которой был осуществлен удаленный доступ к серверу SCADA и отправлены команды по специализированному промышленному протоколу. Это позволило спровоцировать аварийную ситуацию атакующие получили доступ к системе управления колесом обозрения и увеличили скорость вращения аттракциона до максимальной, что привело к падению колеса.

Атака развивалась следующим образом:

Неавторизованное соединение TCP от узла 172.17.61.17 к серверу SCADA 172.17.22.11 (03:29). Вероятнее всего, это была разведка.
Неавторизованное соединение по протоколу SMB от узла 172.17.61.17 к серверу SCADA 172.17.22.11 (06:06). Поиск файлов на общем ресурсе с целью найти чувствительную информацию или подсказки по дальнейшему подключению. Кроме того, на этом этапе может оставляться полезная нагрузка для дальнейшей эксплуатации.
Неавторизованное подключение RDP от узла 172.17.61.17 к серверу SCADA 172.17.22.11 (08:07). Получен доступ к SCADA-системе.
Изменение параметров или подача управляющего воздействия на мнемосхеме, вызвавшая отправку команды управления от сервера SCADA 172.17.22.11 к ПЛК 172.17.23.11 (08:25). Эта часть атаки могла при условии проникновения на сервер SCADA быть выполнена довольно простым способом путем подачи команды напрямую с мнемосхемы. Тем не менее атакующие серьезно исследовали систему, выявили управляющие теги и провели осмысленную атаку с помощью инженерного или специального ПО. В данном случае SCADA-система и ПЛК не имели защитных механизмов, призванных не допустить опасных ситуаций. Важно отметить, что с точки зрения NTA отправленная команда является абсолютно легитимной (если не учитывать контекст технологического процесса, который возможно заложить на уровне PT ISIM proView Sensor).

Вот как эта атака отражалась в интерфейсе PT ISIM.

Сводка взаимодействий с сервером SCADA

Атакующие смогли провести опасную атаку, поскольку после проникновения в технологическую сеть исследовали инфраструктуру объекта. Им удалось получить доступ к инженерному ПО, выяснить управляющие теги и отправить их на ПЛК. Как и в описанном выше кейсе, защитникам следовало предпринимать активные действия уже на предыдущих этапах атаки, которые были обнаружены с помощью MaxPatrol SIEM, PT Sandbox, PT NAD и PT ISIM. После проникновения в сегмент АСУ ТП в данном случае у защитников было достаточно возможностей для реакции в реальном времени, но в реальных условиях было бы недостаточно. Во время учений, когда каждый инцидент на виду, у нападающих есть в распоряжении несколько часов, чтобы довести атаку до завершения. А в реальных условиях у киберпреступников может быть гораздо больше времени и на исследование инфраструктуры, и на проведение самой атаки. Подобную атаку на финальном ее этапе возможно выявить с помощью глубокого разбора промышленного протокола с анализом конфигурации и выявлением опасных действий оператора, таких как превышение допустимой мощности вращения колеса или несанкционированная остановка.

Нарушение и остановка процесса производства химических веществ

Упомянутая выше компания Nuft владела еще одним важным объектом в городе нефтехимическим заводом. До его технологической сети тоже добралась команда нападающих Back2oaz. Им удалось осуществить вход на сервер SCADA RDP, а также нарушить работу ПЛК с помощью специализированного инженерного ПО, в итоге был реализован бизнес-риск нарушение и остановка производства. Возможными последствиями подобных атак в реальной жизни могут быть отзыв лицензии, падение капитализации компании, отставка руководства, травмы сотрудников предприятия, жертвы среди населения города, техногенная авария и экологическая катастрофа.

Цепочка развития атаки выглядела так:

Неавторизованное соединение по RDP от 172.20.61.17 к серверу SCADA 172.20.22.10 (19:30). Получен доступ к SCADA-системе.
Команда на перезагрузку в сервисный режим по проприетарному протоколу, переданная с помощью инженерного ПО от сервера SCADA 172.20.22.10 к ПЛК 172.20.23.10 (01:51 на следующий день). Для реализации данного риска атакующие использовали специализированное ПО для работы с ПЛК, штатно применяемое для данного технологического процесса. Перевод в сервисный режим означает фактическую остановку выполнения основного кода и прерывание технологического процесса. В условиях отсутствия резервирования и защитных механизмов на контроллерах нижнего уровня это может привести к серьезной аварии, в частности к перегреву, нарушению процесса производства и в итоге к остановке производства полностью.

PT ISIM детектировал каждый шаг атакующих.

Подключение по RDP

Команда на перевод ПЛК в сервисный режим

Информационный обмен между сервером SCADA и ПЛК

Киберполигоны и реальность

На The Standoff, конечно, существовали некоторые условия, которые облегчают жизнь атакующим и не должны встречаться на реальных промышленных объектах. Например, инженерное ПО на управляющих АРМ или дефолтные пароли для доступа в различные системы. Однако на практике оказывается, что их все же можно встретить в инфраструктуре промышленных компаний. Нередки случаи подключения промышленной сети к корпоративной, имеющей выход в интернет. В таких условиях крайне важно использование систем глубокого анализа технологического трафика в связке с другими инструментами SIEM-системами, решениями для управления уязвимостями; это позволяет выявлять атаки на промышленные объекты и своевременно реагировать на возникающие угрозы.

Автор: Сергей Петров, руководитель отдела экспертизы промышленных систем Positive Technologies

Подробнее..

Категории: Информационная безопасность , It-инфраструктура , Блог компании positive technologies , Инфраструктура , Scada , Плк

Как управлять облачной инфраструктурой с помощью Terraform

24.09.2020 10:22:34 |

Автор: admin

В этой статье мы рассмотрим из чего состоит Terraform, а также поэтапно запустим собственную инфраструктуру в облаке с VMware подготовим три VM для разных целей: прокси, файловое хранилище и CMS.

Обо всем подробно и в три этапа:

Terraform описание, преимущества и составляющие
Создание инфраструктуры
Инициализация инфраструктуры
- Работа Terraform с уже существующей инфраструктурой

1. Terraform описание, преимущества и составляющие

Terraform это IaC (Infrastructure-as-Code) инструмент для построения и управления виртуальной инфраструктурой с помощью кода .

В работе с инструментом мы отметили несколько преимуществ:

Скорость развертывания новых тенантов (пользовательских виртуальных сред). Обычно, чем больше новых клиентов, тем больше "кликов" требуется сделать сотрудникам технической поддержки для публикации новых ресурсов. С Terraform пользователи могут изменять параметры виртуальных машин (например, автоматически выключать ОС и увеличивать раздел виртуального диска ) без участия технической поддержки и выключения самой машины.
Моментальная проверка плана активации нового теннанта. С помощью описания кода инфраструктуры мы можем сразу же проверить, что и в каком порядке будет добавлено, а также в каком конечном состоянии будет та или иная виртуальная машина или виртуальная сеть с подключениями к виртуальным машинам.
Возможность описывать большинство популярных облачных платформ. Вы можете использовать инструмент от Amazon и Google Cloud, до частных платформ на базе VMware vCloud Director, предлагающих услуги в рамках IaaS, SaaS и PaaS решений.
Управлять несколькими облачными провайдерами и распространять инфраструктуру между ними для повышения отказоустойчивости, используя одну конфигурацию для создания, диагностики и управления облачными ресурсами.
Удобное использование для создания демо-стендов под тестирование и отладку программного обеспечения. Вы можете создавать и передавать стенды для отдела тестирования, параллельно проверять ПО в разных средах, а также моментально изменять и удалять ресурсы, создав всего лишь один план построения ресурсов

"Террариум" Terraform

Кратко рассказали про преимущества инструмента, теперь разберем его на составляющие

Providers (провайдеры).

В Terraform практически любой тип инфраструктуры можно представить в качестве ресурса. Связь между ресурсами и платформой API обеспечивается providers модулями, которые позволяют создавать ресурсы в рамках определённой платформы, например, Azure или VMware vCloud Director.

В рамках проекта вы можете взаимодействовать с разными провайдерами на разных платформах.

Resources (описание ресурсов).

Описание ресурсов позволяет управлять компонентами платформы, например виртуальными машинами или сетями.

Вы можете самостоятельно создать описание ресурсов для провайдера VMware vCloud Director и использовать это описание для создания ресурсов у любого хостинг-провайдера, который использует vCloud Director. Вам потребуется лишь заменить параметры аутентификации и параметры сетевого подключения к необходимому хостинг-провайдеру

Provisioners.

Эта составляющая дает возможность выполнять операции по первоначальной установке и обслуживанию операционной системы после создания виртуальных машин. После того, как вы создали ресурс виртуальной машины, с помощью provisioners вы можете настроить и подключиться по SSH, выполнить обновление операционной системы, а также загрузить и выполнить скрипт.

Переменные Input и Output.

Input переменные входные переменные для любых типов блоков.

Output переменные позволяют сохранить значения после создания ресурсов и могут быть использованы, как входные переменные в других модулях, например в блоке Provisioners.

States (состояния).

States-файлы хранят информацию о конфигурации ресурсов платформы провайдера. При первом создании платформы никаких сведений о ресурсах нет и перед любой операцией Terraform обновляет состояние с реальной инфраструктурой уже описанных ресурсов.

Основная цель состояний, это сохранение связки объектов уже созданных ресурсов для сравнение конфигурации добавляемых ресурсов и объектов, чтобы избежать повторного создания и изменений платформы.

Информация о состоянии по умолчанию хранится в локальном файле terraform.tfstate, но при необходимости есть возможность использовать удаленное хранение для работы в команде.

Также вы можете импортировать текущие ресурсы платформы в состояние, чтобы далее взаимодействовать с другими ресурсами, которые в свою очередь были созданы без помощи Terraform.

2. Создание инфраструктуры

Составляющие разобрали, теперь с помощью Terraform мы поэтапно создадим инфраструктуру с тремя виртуальными машинами. Первая с установленным прокси-сервером nginx, вторая с файловым хранилищем на базе Nextcloud и третья с CMS Bitrix.

Писать код и исполнять его мы будем на примере нашего облака на VMware vCloud Director. У нас пользователи получают учётную запись правами Organization Administrator, если вы используете учетную запись с теми же правами в другом облаке VMware, то сможете воспроизвести код из наших примеров. Поехали!

Сначала создадим для нашего нового проекта директорию, в которой будут размещены файлы с описанием инфраструктуры.

mkdir project01

Затем опишем компоненты инфраструктуры. Terraform создаёт связи и обрабатывает файлы на основании описания в файлах. Сами файлы можно именовать исходя из целевого назначения описываемых блоков, например, network.tf - описывает сетевые параметры для инфраструктуры.

Для описания компонентов нашей инфраструктуры, мы создали следующие файлы:

Список файлов.

main.tf - описание параметров для виртуальной среды - виртуальные машины, виртуальные контейнеры;

network.tf - описание параметров виртуальной сети и правил NAT, Firewall;

variables.tf - список переменных, которые используем;

vcd.tfvars - значения переменных проекта для модуля VMware vCloud Director.

Язык конфигурации в Terraform является декларативным и порядок блоков не имеет значения, кроме блоков provisioner, т.к. в этом блоке мы описываем команды для выполнения при подготовке инфраструктуры и они будут выполнятся по порядку.

Структура блоков.

<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {

# Block body

<IDENTIFIER> = <EXPRESSION> # Argument

}

Для описания блоков используется собственный язык программирования HCL (HashiCorp Configuration Language), возможно описывать инфраструктуру и с помощью JSON. Подробнее о синтаксисе можно прочитать на сайте разработчика.

Конфигурация переменной окружения, variables.tf и vcd.tfvars

Сначала создадим два файла, которые описывают список всех используемых переменных и их значений для модуля VMware vCloud Director. Первым создадим файл variables.tf.

Cодержимое файла variables.tf.

variable "vcdorguser" {

description = "vCD Tenant User"

}

variable "vcdorgpassword" {

description = "vCD Tenant Password"

}

variable "vcdorg" {

description = "vCD Tenant Org"

}

variable "vcdorgvdc" {

description = "vCD Tenant VDC"

}

variable "vcdorg_url" {

description = "vCD Tenant URL"

}

variable "vcdorgmaxretrytimeout" {

default = "60"

}

variable "vcdorgallowunverifiedssl" {

default = "true"

}

variable "vcdorgedgename" {

description = "vCD edge name"

}

variable "vcdorgcatalog" {

description = "vCD public catalog"

}

variable "vcdtemplateoscentos7" {

description = "OS CentOS 7"

default = "CentOS7"

}

variable "vcdorgssdsp" {

description = "Storage Policies"

default = "Gold Storage Policy"

}

variable "vcdorghddsp" {

description = "Storage Policies"

default = "Bronze Storage Policy"

}

variable "vcdedgelocalsubnet" {

description = "Organization Network Subnet"

}

variable "vcdedgeexternalip" {

description = "External public IP"

}

variable "vcdedgelocalipnginx" {}

variable "vcdedgelocalipbitrix" {}

variable "vcdedgelocalC11Cnextcloud" {}

variable "vcdC12Cexternal_network" {}

Значения переменных, которые мы получаем от провайдера.

vcd_org_user - имя пользователя с правами Organization Administrator,
vcd_org_password - пароль пользователя,
vcd_org - название организации,
vcd_org_vdc - название виртуального дата-центра,
vcd_org_url - API URL,
vcd_org_edge_name - название виртуального маршрутизатора,
vcd_org_catalog - название каталога с шаблонами виртуальных машин,
vcd_edge_external_ip - публичный IP-адрес,
vcd_edge_external_network - название внешней сети,
vcd_org_hdd_sp - название политики хранения HDD,
vcd_org_ssd_sp - название политики хранения SSD.

И вводим свои переменные:

vcdedgelocalipnginx - IP-адрес виртуальной машины с NGINX,
vcdedgelocalipbitrix - IP-адрес виртуальной машины с 1С: Битрикс,
vcdedgelocalipnextcloud - IP-адрес виртуальной машины с Nextcloud.

Вторым файлом создаем и указываем переменные для модуля VMware vCloud Director в файле vcd.tfvars: Напомним, что в нашем примере мы используем собственное облако mClouds, если вы работаете с другим провайдером уточните значения у него.

Содержимое файла vcd.tfvars.

vcdorgurl = "https://vcloud.mclouds.ru/api"

vcdorguser = "orgadmin"

vcdorgpassword = "*"

vcd = "org"

vcdorgvdc = "orgvdc"

vcdorgmaxretrytimeout = 60

vcdorgallowunverifiedssl = true

vcdorgcatalog = "Templates"

vcdtemplateos_centos7 = "CentOS7"

vcdorgssdsp = "Gold Storage Policy"

vcdorghddsp = "Bronze Storage Policy"

vcdorgedgename = "MCLOUDS-EDGE"

vcdedgeexternalip = "185.17.66.1"

vcdedgelocalsubnet = "192.168.110.0/24"

vcdedgelocalipnginx = "192.168.110.1"

vcdedgelocalipbitrix = "192.168.110.10"

vcdedgelocalipnextcloud = "192.168.110.11"

vcdedgeexternal_network = "NET-185-17-66-0"

Сетевая конфигурация, network.tf.

Переменные окружения заданы, теперь настроим схему подключения виртуальных машин к каждой виртуальной машине назначим приватный IP-адрес и с помощью Destination NAT "пробрасываем" порты во внешнюю сеть. Для ограничения доступа к портам управления установим доступ только для нашего IP-адреса.

Схема сети для создаваемой Terraform платформы

Создаем виртуальную организационную сеть с названием net_lan01, шлюзом по умолчанию: 192.168.110.254, а также с адресным пространством: 192.168.110.0/24.

Описываем виртуальную сеть.

resource "vcdnetworkrouted" "net" {

name = "netlan01"

edgegateway = var.vcdorgedgename

gateway = "192.168.110.254"

dns1 = "1.1.1.1"

dns2 = "8.8.8.8"

staticippool {

startaddress = "192.168.110.1"

end_address = "192.168.110.253"

}

Создадим правила для межсетевого экрана, которое позволяет предоставить виртуальным машинам доступ в сеть Интернет. В рамках этого блока все виртуальные ресурсы в облаке будут иметь доступ в сеть Интернет:

Описываем правила для доступа VM в интернет.

resource "vcdnsxvfirewallrule" "fwinternetaccess" {

edgegateway = var.vcdorgedgename

name = "Internet Access"

source {

gatewayinterfaces = ["internal"]

}

destination {

gatewayinterfaces = ["external"]

}

service {

protocol = "any"

}

dependson = [vcdnetworkrouted.net]

}

Установив зависимость, что после обработки блока vcdnetworkrouted.net мы приступаем к конфигурации блока vcdnsxvfirewallrule, с помощью dependson. Используем эту опцию, так как некоторые зависимости могут быть распознаны неявно в конфигурации.

Далее создадим правила разрешающее доступ к портам из внешней сети и указываем наш IP-адрес для подключения по SSH к серверам. Любой пользователь сети Интернет имеет доступ к портам 80 и 443 на веб-сервере и пользователь с IP-адресом 90.1.15.1 имеет доступ к портам SSH виртуальных серверов.

Разрешаем доступ к портам из внешней сети.

resource "vcdnsxvfirewallrule" "fwnatports" {

edgegateway = var.vcdorgedgename

name = "HTTPs Access"

source {

gatewayinterfaces = ["external"]

}

destination {

gateway_interfaces = ["internal"]

}

service {

protocol = "tcp"

port = "80"

}

service {

protocol = "tcp"

port = "443"

}

dependson = [vcdnetworkrouted.net]

}

resource "vcdnsxvfirewallrule" "fwnatadminports" {

edgegateway = var.vcdorgedgename

name = "Admin Access"

source {

ipaddresses = [ "90.1.15.1" ]

}

destination {

gatewayinterfaces = ["internal"]

}

service {

protocol = "tcp"

port = "58301"

}

service {

protocol = "tcp"

port = "58302"

}

service {

protocol = "tcp"

port = "58303"

}

depends_on = [vcdnetworkrouted.net]

}

Создаём правила Source NAT для доступа в сеть Интернет из облачной локальной сети:

Описываем правила Source NAT.

resource "vcdnsxvsnat" "snatlocal" {

edgegateway = var.vcdorgedgename

networktype = "ext"

networkname = var.vcdedgeexternalnetwork

originaladdress = var.vcdedgelocalsubnet

translatedaddress = var.vcdedgeexternalip

dependson = [vcdnetwork_routed.net]

}

И в завершении конфигурации сетевого блока добавляем правила Destination NAT для доступа к сервисам из внешней сети:

Добавляем правила Destination NAT.

resource "vcd_nsxv_dnat" "dnat_tcp_nginx_https" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "NGINX HTTPs"

original_address = var.vcd_edge_external_ip original_port = 443

translated_address = var.vcd_edge_local_ip_nginx translated_port= 443 protocol = "tcp"

depends_on = [vcd_network_routed.net]}resource "vcd_nsxv_dnat" "dnat_tcp_nginx_http" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "NGINX HTTP"

original_address = var.vcd_edge_external_ip original_port = 80

translated_address = var.vcd_edge_local_ip_nginx translated_port= 80 protocol = "tcp"

depends_on = [vcd_network_routed.net]

}

Добавляем правило NAT для трансляции портов к SSH-серверу под Nginx.

resource "vcd_nsxv_dnat" "dnat_tcp-nginx_ssh" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "SSH NGINX"

original_address = var.vcd_edge_external_ip original_port = 58301

translated_address = var.vcd_edge_local_ip_nginx translated_port= 22 protocol = "tcp"

depends_on = [vcd_network_routed.net]

}

Добавляем правило NAT для трансляции портов к SSH-серверу с 1С-Битрикс.

resource "vcd_nsxv_dnat" "dnat_tcp_bitrix_ssh" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "SSH Bitrix"

original_address = var.vcd_edge_external_ip original_port = 58302

translated_address = var.vcd_edge_local_ip_bitrix translated_port= 22 protocol = "tcp"

depends_on = [vcd_network_routed.net]

}

Добавляем правило NAT для трансляции портов к SSH-серверу с Nextcloud.

resource "vcd_nsxv_dnat" "dnat_tcp_nextcloud_ssh" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "SSH Nextcloud"

original_address = var.vcd_edge_external_ip original_port = 58303 translated_address = var.vcd_edge_local_ip_nextcloud translated_port= 22 protocol = "tcp"

depends_on = [vcd_network_routed.net]

}

Конфигурация виртуальной среды main.tf

Как мы и планировали в начале статьи, создадим три виртуальные машины. Они будут подготовлены с помощью "Guest Customization". Сетевые параметры пропишем согласно указанным нами настройками, а пароль от пользователя генерируется автоматически.

Опишем vApp в котором будут находится виртуальные машины и их конфигурацию.

Конфигурация виртуальных машин

Создадим контейнер vApp. Чтобы мы могли сразу же подключить vApp и ВМ к виртуальной сети также добавляем параметр depends_on:

Создаем контейнер

resource "vcd_vapp" "vapp" { name = "web" power_on = "true" depends_on = [vcd_network_routed.net]

}

Создадим виртуальную машину с описанием

resource "vcd_vapp_vm" "nginx" {

vapp_name = vcd_vapp.vapp.name

name = "nginx"

catalog_name = var.vcd_org_catalog

template_name = var.vcd_template_os_centos7

storage_profile = var.vcd_org_ssd_sp

memory = 8192

cpus = 1

cpu_cores = 1

network {

type = "org"

name = vcd_network_routed.net.name

is_primary = true

adapter_type = "VMXNET3"

ip_allocation_mode = "MANUAL"

ip = var.vcd_edge_local_ip_nginx

}

override_template_disk {

bus_type = "paravirtual"

size_in_mb = "32768"

bus_number = 0

unit_number = 0

storage_profile = var.vcd_org_ssd_sp

}

Основные параметры в описании VM:

name - имя виртуальной машины,
vappname - название vApp в который добавить новую ВМ,
catalogname / templatename - название каталога и название шаблона виртуальной машины,
storageprofile - политика хранения по умолчанию.

Параметры блока network:

type - тип подключаемой сети,
name - к какой виртуальной сети подключить ВМ,
isprimary - основной сетевой адаптер,
ipallocation_mode - режим выделения адреса MANUAL / DHCP / POOL,
ip - IP-адрес для виртуальной машины, укажем вручную.

Блок override_template_disk:

sizeinmb - размер boot-диска для виртуальной машины
storage_profile - политика хранения для диска

Создадим вторую VM с описанием файлового хранилища Nextcloud

resource "vcd_vapp_vm" "nextcloud" {

vapp_name = vcd_vapp.vapp.name

name = "nextcloud"

catalog_name = var.vcd_org_catalog

template_name = var.vcd_template_os_centos7

storage_profile = var.vcd_org_ssd_sp

memory = 8192

cpus = 1

cpu_cores = 1

network {

type = "org"

name = vcd_network_routed.net.name

is_primary = true

adapter_type = "VMXNET3"

ip_allocation_mode = "MANUAL"

ip = var.vcd_edge_local_ip_nextcloud

}

override_template_disk {

bus_type = "paravirtual"

size_in_mb = "32768"

bus_number = 0

unit_number = 0

storage_profile = var.vcd_org_ssd_sp

}

resource "vcd_vm_internal_disk" "disk1" {

vapp_name = vcd_vapp.vapp.name

vm_name = "nextcloud"

bus_type = "paravirtual"

size_in_mb = "102400"

bus_number = 0

unit_number = 1

storage_profile = var.vcd_org_hdd_sp

allow_vm_reboot = true

depends_on = [ vcd_vapp_vm.nextcloud ]

}

В секции vcdvminternal_disk опишем новый виртуальный диск, который подключается к виртуальной машине.

Пояснения по блоку vcdvminternaldisk:

bustype - тип дискового контроллера
sizeinmb - размер диска
busnumber / unitnumber - место подключения в адаптере
storage_profile - политика хранения для диска

Опишем последнюю VM на Битрикс

resource "vcd_vapp_vm" "bitrix" {

vapp_name = vcd_vapp.vapp.name

name = "bitrix"

catalog_name = var.vcd_org_catalog

template_name = var.vcd_template_os_centos7

storage_profile = var.vcd_org_ssd_sp

memory = 8192

cpus = 1

cpu_cores = 1

network {

type = "org"

name = vcd_network_routed.net.name

is_primary = true

adapter_type = "VMXNET3"

ip_allocation_mode = "MANUAL"

ip = var.vcd_edge_local_ip_bitrix

}

override_template_disk {

bus_type = "paravirtual"

size_in_mb = "81920"

bus_number = 0

unit_number = 0

storage_profile = var.vcd_org_ssd_sp

}

Обновление ОС и установка дополнительных скриптов

Сеть подготовлена, виртуальные машины описаны. Перед импортом нашей инфраструктуры мы можем заранее провести первоначальный провижининг с помощью provisioners блоков и без использования Ansible.

Рассмотрим как обновить ОС и запустить установочный скрипт CMS Bitrix с помощью provisioner блока.

Сначала выполним установку пакетов обновления CentOS.

resource "null_resource" "nginx_update_install" {

provisioner "remote-exec" {

connection {

type = "ssh"

user = "root"

password = vcd_vapp_vm.nginx.customization[0].admin_password

host = var.vcd_edge_external_ip

port = "58301"

timeout = "30s"

}

inline = [

"yum -y update && yum -y upgrade",

"yum -y install wget nano epel-release net-tools unzip zip" ]

}

Обозначение составляющих:

provisioner "remote-exec" - подключаем блок удаленного "провижининга"
В блоке connection описываем тип и параметры для подключения:
type - протокол, в нашем случае SSH;
user - имя пользователя;
password - пароль пользователя. В нашем случае указываем на параметр vcdvappvm.nginx.customization[0].admin_password, который хранит сгенерированный пароль от пользователя системы.
host - внешний IP-адрес для подключения;
port - порт для подключения, который ранее указывали в настройках DNAT;
inline - перечисляем список команд, которые будут вводится. Команды будут введены по порядку, как и указано в этой секции.

Как пример, дополнительно выполним скрипт установки 1С-Битрикс. Вывод результата выполнения скрипта будет доступен во время выполнения плана. Для установки скрипта, сначала опишем блок:

Опишем установку 1С-Битрикс.

provisioner "file" {

source = "prepare.sh"

destination = "/tmp/prepare.sh"

connection {

type = "ssh"

user = "root"

password = vcd_vapp_vm.nginx.customization[0].admin_password

host = var.vcd_edge_external_ip

port = "58301"

timeout = "30s"

}

provisioner "remote-exec" {

inline = [

"chmod +x /tmp/prepare.sh", "./tmp/prepare.sh"

]

}

И сразу же опишем обновление Битрикс.

Пример провижининга 1С-Битрикс.

resource "null_resource" "install_update_bitrix" {

provisioner "remote-exec" {

connection {

type = "ssh"

user = "root"

password = vcd_vapp_vm.bitrix.customization[0].admin_password

host = var.vcd_edge_external_ip

port = "58302"

timeout = "60s"

}

inline = [

"yum -y update && yum -y upgrade",

"yum -y install wget nano epel-release net-tools unzip zip",

"wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh -O /tmp/bitrix-env.sh",

"chmod +x /tmp/bitrix-env.sh",

"/tmp/bitrix-env.sh"

]

}

Важно! Скрипт может не сработать, если не отключить заранее SELinux! Если вам требуется подробная статья по установке и настройке CMS 1С-Битрикс с помощью bitrix-env.sh, оо вы можете воспользоваться нашей статьей в блоге на сайте.

3. Инициализация инфраструктуры

Инициализация модулей и плагинов

Для работы мы используем простой джентельменский набор: лэптоп с ОС Windows 10 и дистрибутив с официального сайта terraform.io. Распакуем и проинициализируем с помощью команды: terraform.exe init

После описания вычислительной и сетевой инфраструктуры, мы запускаем планирование для проверки нашей конфигурации, где мы можем увидеть, что будет создано и как между собой связано.

Выполняем команду - terraform plan -var-file=vcd.tfvars.
Получаем результат - Plan: 16 to add, 0 to change, 0 to destroy. То есть по этому плану будет создано 16 ресурсов.
Запускаем план по команде - terraform.exe apply -var-file=vcd.tfvars.

Виртуальные машины будут созданы, а затем выполняются перечисленные нами пакеты в рамках секции provisioner ОС будет обновлена и установится CMS Bitrix.

Получение данных для подключения

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

output "nginxpassword" {

value = vcdvappvm.nginx.customization[0].adminpassword

}

И следующий вывод сообщает нам пароль от созданной виртуальной машины:

Outputs: nginx_password = F#4u8!!N

В итоге мы получаем доступ к виртуальным машинам с обновлённой операционной системой и предустановленными пакетами для нашей дальнейшей работы. Все готово!

Но что если у вас уже есть существующая инфраструктура?

3.1. Работа Terraform с уже существующей инфраструктурой

Всё просто, вы можете импортировать текущие виртуальные машины и их vApp контейнеры с помощью команды import.

Опишем ресурс vAPP и виртуальную машину.

resource "vcd_vapp" "Monitoring" {

name = "Monitoring"

org = "mClouds"

vdc = "mClouds"

}

resource "vcd_vapp_vm" "Zabbix" {

name = "Zabbix"

org = "mClouds"

vdc = "mClouds"

vapp = "Monitoring"

}

Следующий шаг, это выполнить импорт свойств ресурсов vApp в формате vcdvapp.<vApp> <org>.<orgvdc>.<vApp>, где:

vApp - имя vApp;
org - название организации;
org_vdc - название виртуального дата-центра.

Импорт свойств ресурса vAPP

Выполним импорт свойств ресурсов VM в формате: vcdvappvm.<VM> <org>.<orgvdc>.<vApp>.<VM>, в котором:

VM - имя VM;
vApp - имя vApp;
org - название организации;
orgvdc - название виртуального дата-центра.

Импорт прошел успешно

C:\Users\Mikhail\Desktop\terraform>terraform import vcd_vapp_vm.Zabbix mClouds.mClouds.Monitoring.Zabbix

vcd_vapp_vm.Zabbix: Importing from ID "mClouds.mClouds.Monitoring.Zabbix"...

vcd_vapp_vm.Zabbix: Import prepared!

Prepared vcd_vapp_vm for import

vcd_vapp_vm.Zabbix: Refreshing state... [id=urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f]

Import successful!

The resources that were imported are shown above. These resources are now inyour Terraform state and will henceforth be managed by Terraform.

Теперь мы можем посмотреть на новый импортированный ресурс:

Импортированный ресурс

> terraform show

...

# vcd_vapp.Monitoring:

resource "vcd_vapp" "Monitoring" {

guest_properties = {}

href = "https://vcloud.mclouds.ru/api/vApp/vapp-fe5db285-a4af-47c4-93e8-55df92f006ec"

id = "urn:vcloud:vapp:fe5db285-a4af-47c4-93e8-55df92f006ec"

ip = "allocated"

metadata = {}

name = "Monitoring"

org = "mClouds"

status = 4

status_text = "POWERED_ON"

vdc = "mClouds"

}

# vcd_vapp_vm.Zabbix:

resource "vcd_vapp_vm" "Zabbix" {

computer_name = "Zabbix"

cpu_cores = 1

cpus = 2

expose_hardware_virtualization = false

guest_properties = {}

hardware_version = "vmx-14"

href = "https://vcloud.mclouds.ru/api/vApp/vm-778f4a89-1c8d-45b9-9d94-0472a71c4d1f"

id = "urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f"

internal_disk = [

{

bus_number = 0

bus_type = "paravirtual"

disk_id = "2000"

iops = 0

size_in_mb = 122880

storage_profile = "Gold Storage Policy"

thin_provisioned = true

unit_number = 0

},

]

memory = 8192

metadata = {}

name = "Zabbix"

org = "mClouds"

os_type = "centos8_64Guest"

storage_profile = "Gold Storage Policy"

vapp_name = "Monitoring"

vdc = "mClouds"

customization {

allow_local_admin_password = true

auto_generate_password = true

change_sid = false

enabled = false

force = false

join_domain = false

join_org_domain = false

must_change_password_on_first_login = false

number_of_auto_logons = 0

}

network {

adapter_type = "VMXNET3"

ip_allocation_mode = "DHCP"

is_primary = true

mac = "00:50:56:07:01:b1"

name = "MCLOUDS-LAN01"

type = "org"

}

Теперь точно готово - мы закончили с последним моментом (импорт в существующую инфраструктуру) ирассмотрели все основные моменты работы с Terraform.

Инструмент оказался очень удобным и позволяет описать вашу инфраструктуру как код, начиная от виртуальных машин одного облачного провайдера до описания ресурсов сетевых компонентов.

При этом независимость от окружения дает возможность работать с локальными, облачными ресурсами, так и, заканчивая управлением платформой. А при отсутствии поддерживаемой платформы и желании добавления нового, можно написать свой провайдер и использовать его.

Подробнее..

Категории: It-инфраструктура , Хостинг , Серверное администрирование , Инфраструктура , Terraform , Iac , Блог компании mclouds.ru , Iaas

История архитектуры Dodo IS ранний монолит

01.10.2020 18:11:51 |

Автор: admin

Или каждая несчастная компания с монолитом несчастлива по-своему.

Разработка системы Dodo IS началась сразу же, как и бизнес Додо Пиццы в 2011 году. В основе лежала идея полной и тотальной оцифровки бизнес-процессов, причем своими силами, что еще тогда в 2011 году вызывало много вопросов и скептицизма. Но вот уже 9 лет мы идем по такому пути с собственной разработкой, которая начиналась с монолита.

Эта статья ответ на вопросы Зачем переписывать архитектуру и делать такие масштабные и долгие изменения? к предыдущей статье История архитектуры Dodo IS: путь бэкофиса. Начну с того как начиналась разработка Dodo IS, как выглядела изначальная архитектура, как появлялись новые модули, и из-за каких проблем пришлось проводить масштабные изменения.

Серия статей Что такое Dodo IS? расскажет про:

Ранний монолит в Dodo IS (2011-2015 годы). (You are here)
Путь бэкофиса: раздельные базы и шина.
Путь клиентской части: фасад над базой (2016-2017 годы). (In progress)
История настоящих микросервисов. (2018-2019 годы). (In progress)
Законченный распил монолита и стабилизация архитектуры. (In progress)

Изначальная архитектура

В 2011 году архитектура Dodo IS выглядела так:

Первый модуль в архитектуре прием заказа. Бизнес-процесс был такой:

клиент звонит в пиццерию;
трубку берет менеджер;
принимает по телефону заказ;
параллельно набивает его в интерфейсе приема заказа: учитывается информация о клиенте, данные по деталям заказа, адрес доставки.

Интерфейс информационной системы выглядел примерно так

Первая версия от октября 2011:

Чуть улучшенная в январе 2012

Информационная система Додо Пицца Delivery Pizza Restaurant

Ресурсы для разработки первого модуля приема заказа были ограничены. Нужно было делать много, быстро и малым составом. Малый состав это 2 разработчика, которые и заложили фундамент всей будущей системы.

Их первое решение определило дальнейшую судьбу технологического стека:

Backend на ASP.NET MVC, язык C#. Разработчики были дотнетчиками, этот стек был им знаком и приятен.
Фронтенд на Bootstrap и JQuery: интерфейсы пользователя на самописных стилях и скриптах.
База данных MySQL: без затрат на лицензии, простая в использовании.
Серверы на Windows Server, потому что .NET тогда мог быть только под Windows (Mono обсуждать не будем).

Физически это все выражалось в дедике у хостера.

Архитектура приложения приема заказа

Тогда уже все говорили о микросервисах, а SOA лет 5 использовалось в крупных проектах, например, WCF вышел в 2006 году. Но тогда выбрали надежное и проверенное решение.

Вот оно.

Asp.Net MVC это Razor, который выдаёт по запросу с формы или от клиента HTML-страницу с рендерингом на сервере. На клиенте уже CSS и JS-скрипты отображают информацию и, по необходимости, выполняют AJAX-запросы через JQuery.

Запросы на сервере попадают в классы *Controller, где в методе происходит обработка и генерация итоговой HTML-страницы. Контроллеры делают запросы на слой логики, называемый *Services. Каждый из сервисов отвечал какому-то аспекту бизнеса:

Например, DepartmentStructureService выдавал информацию по пиццериям, по департаментам. Департамент это группа пиццерий под управлением одного франчайзи.
ReceivingOrdersService принимал и рассчитывал состав заказа.
А SmsService отправлял смс, вызывая API-сервисы по отправке смс.

Сервисы обрабатывали данные из базы, хранили бизнес-логику. В каждом сервисе был один или несколько *Repository с соответствующим названием. В них уже находились запросы к хранимым процедурам в базе и слой мапперов. В хранимках была бизнес-логика, особенно много в тех, которые выдавали отчетные данные. ОРМ не использовался, все полагались на написанный руками sql.

Еще был слой доменной модели и общих классов-хелперов, например, класс Order, хранивший заказ. Там же, в слое, находился хелпер для преобразования текста отображения по выбранной валюте.

Всё это можно представить такой моделью:

Путь заказа

Рассмотрим упрощенный первоначальный путь создания такого заказа.

Изначально сайт был статический. На нем были цены, а сверху номер телефона и надпись Хочешь пиццу звони по номеру и закажи. Для заказа нам нужно реализовать простой flow:

Клиент заходит на статический сайт с ценами, выбирает продукты и звонит по номеру, который указан на сайте.
Клиент называет продукты, которые хочет добавить в заказ.
Называет свой адрес и имя.
Оператор принимает заказ.
Заказ отображается в интерфейсе принятых заказов.

Все начинается с отображения меню. Залогиненный пользователь-оператор в один момент времени принимает лишь один заказ. Поэтому draft-корзина может храниться в его сессии (сеанс пользователя хранится в памяти). Там объект Cart, в котором продукты и информация о клиенте.

Клиент называет продукт, оператор нажимает на + рядом с продуктом, и на сервер отправляется запрос. По продукту вытаскивается информация из базы и добавляется информация о продукте в корзину.

Примечание. Да, здесь можно не вытаскивать продукт из базы, а передавать с фронтенда. Но для наглядности я показал именно путь из базы.

Далее вводим адрес и имя клиента.

При нажатии Создать заказ:

Запрос отправляем в OrderController.SaveOrder().
Получаем Cart из сессии, там лежат продукты в нужном нам количестве.
Дополняем Cart информацией о клиенте и передаем в метод AddOrder класса ReceivingOrderService, где он сохраняется в базу.
В базе есть таблицы с заказом, составом заказа, клиентом и они все связаны.
Интерфейс отображения заказа идет и вытаскивает последние заказы и отражает их.

Новые модули

Прием заказа был важен и необходим. Нельзя сделать бизнес по продаже пиццы, если нет приема заказа для продажи. Поэтому система начала обрастать функционалом примерно с 2012 по 2015 года. За это время появилось много различных блоков системы, которые я буду называть модулями, в противовес понятию сервиса или продукта.

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

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

Технически модули оформлялись как Area (вот такая идея даже осталась в asp.net core). Там были отдельные файлы для фронтенда, моделей, а также свои классы контроллеров. В итоге система преобразовалась из такой...

в такую:

Некоторые модули реализованы отдельными сайтами(executable project), по причине совсем уже отдельного функционала и частично из-за несколько отдельной, более сфокусированной разработки. Это:

Site первая версия сайта dodopizza.ru.
Export: выгрузка отчетов из Dodo IS для 1C.
Personal личный кабинет сотрудника. Отдельно разрабатывался и имеет свою точку входа и отдельный дизайн.
fs проект для хостинга статики. Позже мы ушли от него, переведя всю статику на CDN Akamai.

Остальные же блоки находились в приложении BackOffice.

Пояснение по названиям:

Cashier Касса ресторана.
ShiftManager интерфейсы для роли Менеджер смены: оперативная статистика по продажам пиццерии, возможность поставить в стоп-лист продукты, изменить заказ.
OfficeManager интерфейсы для роли Управляющий пиццерии и Франчайзи. Здесь собраны функции по настройке пиццерии, её бонусных акций, прием и работа с сотрудниками, отчеты.
PublicScreens интерфейсы для телевизоров и планшетов, висящих в пиццериях. На телевизорах отображается меню, рекламная информация, статус заказа при выдаче.

Они использовали общий слой сервисов, общий блок доменных классов Dodo.Core, а также общую базу. Иногда еще могли вести по переходам друг к другу. В том числе к общим сервисам ходили и отдельные сайты, вроде dodopizza.ru или personal.dodopizza.ru.

При появлении новых модулей старались по максимуму переиспользовать уже созданный код сервисов, хранимых процедур и таблиц в базе.

Для лучшего понимания масштаба модулей, сделанных в системе, вот схема из 2012 года с планами развития:

К 2015 году всё на схеме и даже больше было в продакшн.

Прием заказа перерос в отдельный блок Контакт Центра, где заказ принимается оператором.
Появились общедоступные экраны с меню и информацией, висящие в пиццериях.
На кухне есть модуль, который автоматически воспроизводит голосовое сообщение Новая пицца при поступлении нового заказа, а также печатает накладную для курьера. Это сильно упрощает процессы на кухне, позволяет не отвлекаться на большое количество простых операций сотрудникам.
Блок доставки стал отдельной Кассой Доставки, где заказ выдавался курьеру, который предварительно встал на смену. Учитывалось его рабочее время для начисления зарплаты.

Параллельно с 2012 по 2015 появилось более 10 разработчиков, открылось 35 пиццерий, развернули систему на Румынию и подготовили к открытию точек в США. Разработчики уже не занимались всеми задачами, а были разделены на команды. каждая специализировалась на своей части системы.

Проблемы

В том числе из-за архитектуры (но не только).

Хаос в базе

Одна база это удобно. В ней можно добиться консистентности, причем за счет средств, встроенных в реляционные базы. Работать с ней привычно и удобно, особенно, если там мало таблиц и немного данных.

Но за 4 года разработки в базе оказалось около 600 таблиц, 1500 хранимых процедур, во многих из которых была еще и логика. Увы, хранимые процедуры не приносят особого преимущества при работе с MySQL. Они не кэшируются базой, а хранение в них логики усложняет разработку и отладку. Переиспользование кода тоже затруднено.

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

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

К одним и тем же таблицам производились очень разнородные запросы. Особенно страдали популярные таблицы, вроде упоминавшейся таблицы orders или таблицы pizzeria. Они использовались для вывода оперативных интерфейсов на кухне, аналитики. Еще к ним обращался сайт(dodopizza.ru), куда в любой момент времени могло придти внезапно много запросов.

Данные не были агрегированными и много расчетов происходило на лету средствами базы. Это создавало лишние вычисления и дополнительную нагрузку.

Часто код ходил в базу тогда, когда мог этого не делать. Где-то не хватало bulk-операций, где-то надо было бы разнести один запрос на несколько через код, чтобы ускорить и повысить надежность.

Связность и запутанность в коде

Модули, которые должны были отвечать за свой участок бизнеса, не делали этого честно. Некоторые из них имели дублирование по функциям для ролей. Например, локальному маркетологу, который отвечает за маркетинговую активность сети в своем городе, приходилось пользоваться как интерфейсом Админа (для заведения акций), так и интерфейсом Менеджера Офиса (для просмотра влияния акций на бизнес). Конечно, внутри оба модуля использовали один сервис, который работал с с бонусными акциями.

Сервисы (классы в рамках одного монолитного большого проекта) могли вызывать друг друга для обогащения своих данных.

С самими классами-моделей, которые хранят данные, работа в коде велась различно. Где-то были конструкторы, через которые можно было указать обязательные поля. Где-то это делалось через публичные свойства. Конечно, получение и преобразование данных из базы было разнообразным.

Логика была либо в контроллерах, либо в классах сервисов.

Это вроде незначительные проблемы, но они сильно замедляли разработку и снижали качество, что приводило к нестабильности и ошибкам.

Сложность большой разработки

Трудности возникли и в самой разработке. Нужно было делать разные блоки системы, причем параллельно. Вместить нужды каждого компонента в единый код становилось все труднее. Было не просто договориться и угодить всем компонентам одновременно. К этому добавлялись ограничения в технологиях, особенно касаемо базы и фронтэнда. Нужно было отказываться от JQuery в сторону высокоуровневых фреймворков, особенно в части клиентских сервисов (сайт).

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

Команды и разработчики, занимающиеся своей областью явно хотели большей самостоятельности для своих сервисов, как в части разработки, так и в части выкатки. Конфликты при мерже, проблемы при релизах. Если для 5 разработчиков эта проблема несущественна, то при 10, а уж тем более при планируемом росте, все стало бы серьёзнее. А а впереди должна была быть разработка мобильного приложения (она стартанула в 2017, а в 2018 было большое падение).

Разные части системы требовали разных показателей стабильности, но в силу сильной связности системы, мы не могли этого обеспечить. Ошибка при разработке новой функции в админке, вполне могла выстрелить в приеме заказа на сайте, ведь код общий и переиспользуемый, база и данные тоже едины.

Вероятно, можно было бы и в рамках такой монолитно-модульной архитектуры не допускать этих ошибок и проблем: сделать разделение ответственности, проводить рефакторинг как кода, так и базы данных, чётко отделять слои друг от друга, следить за качеством каждый день. Но выбранные архитектурные решения и фокус на быстром расширении функционала системы привели к проблемам в вопросах стабильности.

Как блог Сила ума положил кассы в ресторанах

Если рост сети пиццерий (и нагрузки) продолжался бы в том же темпе, то через некоторое время падения были бы уже такими, что система и не поднимется. Хорошо иллюстрирует проблемы, с которыми мы начали сталкиваться к 2015 году вот такая история.

В блоге Сила ума был виджет, который показывал данные по выручке за год всей сети. Виджет обращался к публичному API Dodo, которое предоставляет эти данные. Сейчас эта статистика доступна на http://dodopizzastory.com/. Виджет показывался на каждой странице и делал запросы по таймеру каждые 20 секунд. Запрос уходил в api.dodopizza.ru и запрашивал:

количество пиццерий в сети;
общую выручку сети с начала года;
выручку за сегодня.

Запрос на статистику по выручке шел сразу в базу и начинал запрашивать данные по заказам, агрегировать данные прямо на лету и выдавать сумму.

В эту же таблицу заказов ходили Кассы в ресторанах, выгружали список принятых за сегодня заказов, в неё же добавлялись новые заказы. Кассы делали свои запросы каждые 5 секунд или по обновлению страницы.

Схема выглядела так:

Однажды осенью, Федор Овчинников написал в свой блог длинную и популярную статью. На блог пришло очень много людей и стали внимательно всё читать. Пока каждый из пришедших человек читал статью, виджет с выручкой исправно работал и запрашивал API каждые 20 секунд.

API вызывало хранимую процедуру на расчет суммы всех заказов с начала года по всем пиццериям сети. Агрегация шла по таблице orders, которая очень популярна. В неё же ходят все кассы всех открытых ресторанов на тот момент. Кассы перестали отвечать, заказы не принимались. Ещё они не принимались с сайта, не появлялись на трекере, менеджер смены не мог увидеть их в своем интерфейсе.

Это не единственная история. К осени 2015 года каждую пятницу нагрузка на систему была критическая. Несколько раз мы выключали публичное API, а однажды, нам пришлось даже отключить сайт, потому что уже ничего не помогало. Был даже список сервисов с порядком отключения при серьезных нагрузках.

С этого времени начинается наша борьба с нагрузками и за стабилизацию системы (с осени 2015 до осени 2018). Именно тогда случилось Великое падение. Дальше тоже иногда происходили сбои, некоторые были весьма чувствительными, но общий период нестабильности сейчас можно считать пройденным.

Бурный рост бизнеса

Почему нельзя было сделать сразу хорошо? Достаточно посмотреть на следующие графики.

Также в 2014-2015 было открытие в Румынии и готовилось открытие в США.

Сеть росла очень быстро, открывались новые страны, появлялись новые форматы пиццерий, например, открылась пиццерия на фудкорте. Всё это требовало значительного внимания именно к расширению функций Dodo IS. Без всех этих функций, без трекинга на кухне, учета продуктов и потерь в системе, отображения выдачи заказа в зале фудкорта, вряд ли бы мы сейчас рассуждали о правильной архитектуре и верном подходе к разработке.

Еще препятствиями для своевременного пересмотра архитектуры и вообще внимания к техническим проблемам, был кризис 2014 года. Такие вещи больно бьют по возможностям для роста команд, особенно для молодого бизнеса, каким была Додо Пицца.

Быстрые решения, которые помогли

Проблемы требовали решения. Условно, решения можно разделить на 2 группы:

Быстрые, которые тушат пожар и дают небольшой запас прочности и выигрывают нам время на изменения.
Системные и, поэтому, долгие. Реинжиниринг ряда модулей, разделение монолитной архитектуры на отдельные сервисы (большинство из них вполне не микро, а скорее макросервисы и про это есть доклад Андрея Моревского).

Сухой список быстрых изменений таков:

Scale up мастер базы

Конечно, первое, что делается для борьбы с нагрузками увеличивается мощность сервера. Это делали для мастер базы и для веб серверов. Увы, это возможно лишь до некоторого предела, дальше становится слишком дорого.

С 2014 года мы перешли в Azure, на эту тему мы тоже писали еще в то время в статье Как Додо Пицца доставляет пиццу с помощью облака Microsoft Azure. Но после череды увеличений сервера под базу уперлись по стоимости.

Реплики базы на чтение

Реплик для базы сделали две:

ReadReplica для запросов на справочники. Применяется для чтения справочников, типа, города, улицы, пиццерии, продуктов (slowly changed domain), и в тех интерфейсах, где допустима небольшая задержка. Этих реплик было 2, мы обеспечивали их доступность также, как и мастера.

ReadReplica для запросов на отчеты. У этой базы доступность была ниже, но в неё ходили все отчеты. Пусть у них тяжелые запросы на огромные пересчеты данных, но зато они не влияют на основную базу и операционные интерфейсы.

Кэши в коде

Кэшей в коде нигде не было (вообще). Это приводило к дополнительным, не всегда нужным, запросам в нагруженную базу. Кэши были сначала как в памяти, так и на внешнем кэш-сервисе, это был Redis. Все инвалидировалось по времени, настройки указывались в коде.

Несколько серверов для бэкэнда

Бэкэнд приложения тоже надо было масштабировать, чтобы выдерживать повышенные нагрузки. Необходимо было сделать из одного iis-сервера кластер. Мы перенесли сессию приложений из памяти на RedisCache, что позволило сделать несколько серверов, стоящих за простым балансировщиком нагрузки с round robin. Сначала использовался тот же Redis, что и для кэшей, потом разнесли на несколько.

В итоге архитектура усложнилась

но часть напряженности удалось снять.

А дальше нужно было переделывать нагруженные компоненты, за что мы и взялись. Об этом мы расскажем в следующей части.

Подробнее..

Категории: It-инфраструктура , Программирование , Анализ и проектирование систем , Микросервисы , Управление разработкой , Архитектура , Инфраструктура , Монолит , Блог компании dodo engineering , Dodois , Dodoengineering

Экономичные серверы Lenovo Data Center Group ST50 и SR250 на все случаи жизни

05.10.2020 18:05:13 |

Автор: admin

Крупные производители серверов из года в год (а иногда и чаще) представляют рынку свои новые, инновационные и уникальные продукты. При этом многие из них забывают о том, что большей части заказчиков нужны просто хорошие, недорогие серверы с качественной поддержкой. В них может не быть ~~вкуса мёда и лимона~~ каких-то очень уникальных новых разработок, они должны просто работать. И при этом стоить адекватных денег.

Когда у пользователя возникает запрос на подобные решения, очень часто в силу бюджетных ограничений он вынужден обращаться на рынок самосбора. Минусы этого подхода всем известны, однако стоит их ещё раз озвучить: низкое качество продукции в целом и проблемы с совместимостью комплектующих (которые могут проявиться не сразу, а в самый неподходящий момент), отсутствие качественной поддержки с возможностью быстрой замены оборудования, сложность централизованного управления таким зоопарком.

Для решения этой проблемы компания Lenovo Data Center Group (DCG) предлагает два экономичных и универсальных решения начального уровня.

Если серверной не существует

Компактный, экономичный и достаточно мощный сервер Lenovo ThinkSystem ST50 в корпусе tower создан для тех случаев, когда серверной нет и она не планируется. Таким образом сервер спокойно размещается в офисном пространстве. При этом он не создает дополнительных неудобств, которые обычно создают серверы.

В частности, использование высокоэффективных вентиляторов вместе с Intelligent Cooling Engine (ICE) позволяют серверу в активном режиме регулировать акустические и тепловые характеристики и работать практически бесшумно (не громче обычного ПК), а использование процессоров Intel Xeon E, оперативной памяти TruDDR4 наряду с эффективными блоками питания 80 PLUS (уровень platinum, 250W) минимизировать энергопотребление.

Сервер ST50 выполнен в стандартном towerкорпусе и при этом имеет достаточно мощную начинку.

На односокетной материнской плате используются процессоры Intel Xeon E2200-series с четырьмя ядрами, кэшем 8МБ и частотой в 3.4 ГГц. В сервере предусмотрено 4 слота под модули памяти UDIMM TruDDR4 с частотой 2666 МГц. В базовой конфигурации установлен один модуль 8ГБ. При этом максимально сервер поддерживает до 64ГБ оперативной памяти.

На сервере предусмотрено 3 отсека под диски (3,5" HDD или SSD), 4-ый отсек 5,25" поддерживает одну из следующих 4-х конфигураций: подключение оптического привода (либо DVD-ROM, либо DVD-RW), подключение блока резервного копирования (либо в/п лента, либо диск RDX), подключение диска 3,5" в 5,25-дюймовый лоток с помощью комплекта преобразования или комбинация 3,5-дюймового HDD или SSD с тонким оптическим DVD-RW.

На борту также предусмотрен встроенный SATA-RAID контроллер. В базовой конфигурации сервер поставляется с двумя дисками 1TB SATA 3.5". Также предусмотрены три слота PCIe, два встроенных порта Gigabit Ethernet, 4 USB-порта (2x3.1 и 2x2.0), два отдельных display-порта и serial-порт.

Есть ещё крайне полезная для сервера, установленного в офисном пространстве, конструктивная особенность. На сервере ST50 (как и на других серверах Lenovo DCG) предусмотрен intrusion switch. Простейшее аппаратное устройство в виде замка на корпусе, который подключается в специальный разъем на материнской плате и позволяет обнаружить несанкционированный физический доступ внутрь сервера. Чтобы было нагляднее, ниже видео, на котором показано, как это используется.

https://support.lenovo.com/cz/en/ytvideo/ytv100847/

Сервер ST50 идеально подойдет для небольших филиальных офисов или для компаний малого бизнеса, которые с одной стороны не могут себе позволить отдельное помещение для серверной, а с другой не хотят создавать дискомфорт в офисном пространстве размещением там шумной и прожорливой с точки зрения электроэнергии техникой.

Если серверная все-таки есть

Сервер Lenovo ThinkSystem SR250 начинкой очень похож на ST50, но выполнен в 1U rack корпусе с соответствующими преимуществами rack-ового исполнения.

Так же, как и в ST50 используются энергоэффективные процессоры Intel Xeon E2100- и E2200-series и оперативная память TruDDR4 (4 слота на материнскую плату).

Есть несколько вариантов корпусов, отличаются они передней панелью и количеством дисков с поддержкой горячей замены.

Вариант 1. 4 диска LFF SAS/SATA

Вариант 2. 8 дисков SFF SAS/SATA

Вариант 3. 10 дисков SFF SAS/SATA ИЛИ 8 8 дисков SFF SAS/SATA + 2 NVMe PCIe

Сервер оборудован двумя блоками питания с уровнем эффективности Gold и Platinum, двумя слотами PCIe, двумя встроенными портами Gigabit Ethernet и отдельным портом управления. Само собой, предусмотрены VGA разъем и Serial-порт.

Для охлаждения внутри установлены 4 вентилятора, на материнской плате предусмотрены M.2 и Mini-SAS HD (4xSATA) коннекторы.

Отдельной и очень полезной особенностью является полноценная интеграция сервера SR250 с системой управления Lenovo XClarity, которая позволяет осуществлять централизованное управление, мониторинг и инвентаризацию всех систем Lenovo ThinkSystem.

По сути сервер SR250 является недорогим аналогом SR650 (который, кстати, является самым покупаемым сервером Lenovo во всем мире), он также имеет достаточно мощности для своих задач и крайне эффективен с точки зрения бюджета и обслуживания. Сервер подойдёт как для малого бизнеса, так и для крупных корпораций, где требуется организовывать большие вычислительные кластеры для самых разных задач.

Сколько стоит?

Как говорят футбольные эксперты: Самое красивое в футболе это счёт на табло!. Если мы говорим о хорошей вычислительной технике (особенно для небольших компаний), то самое интересное в ней это цена.

И у компании Lenovo есть чем порадовать заказчиков.

Стоимость базовой конфигурации Lenovo ThinkSystem ST50 (tower) на текущий момент начинается от 787 долларов.

Стоимость базовой конфигурации Lenovo ThinkSystem SR250 (rack) на текущий момент начинается от 578 долларов. Дополнительно в подарок к серверу SR250 прилагается лицензия на XClarity Controller Standard для централизованного управления.

Кроме того, в стоимость (и ST50, и SR250) входит не только сам сервер, но и гарантия на всей территории России в режиме 9*5 с выездом специалиста к заказчику на следующий рабочий день.

Оба сервера находятся в наличии на складах в РФ, поэтому поставить их можно достаточно быстро (как правило, 1-2 недели).

Более полную информацию о доступности и стоимости можно узнать по ссылкам ниже:

ST50 узнать стоимость и сроки поставки

SR250 узнать стоимость и сроки поставки

А теперь подводим итог. Серверы Lenovo Data Center Group ST50 и SR250 по сути являются отличными бюджетными решениями на все случаи жизни небольших компаний и в ряде случаев подходят и для крупных корпораций. Серверы ST50 и SR250 серверы высокого качества, как и вся серверная линейка Lenovo DCG, покрываются 1- или 3-х летней поддержкой, а также доступны на складах для быстрой поставки.

Подробнее..

Категории: It-инфраструктура , Резервное копирование , Сервер , Администрирование , Intel , Сетевые технологии , Ssd , Инфраструктура , Восстановление данных , Серверная оптимизация , Hdd , Блог компании lenovo , Lenovo , Срк , Серверная

Технорадар Lamoda 2020 что изменилось за два года

26.10.2020 12:15:22 |

Автор: admin

Технологический радар диаграмма, на которой можно увидеть IT технологии и инструменты, которые мы используем в Lamoda, разделенные по областям применения и статусам. В 2018 году мы выкладывали здесь на Хабре подробную статью с расшифровкой актуального на тот момент техрадара. Что изменилось за два года, и зачем мы продолжаем регулярно обновлять радар читайте в этой статье.

На самом деле, технологический радар не просто картинка, которую мы можем показать на конференции. Хотя мы используем его и так тоже он отлично подходит, чтобы составить быстрое впечатление об IT-составляющей нашей компании. В 2018 году мы были единственной компанией, которая использовала для представления такой инструмент визуализации а сейчас на каждой конференции мы с радостью замечаем по 2-3 новых радара у различных компаний. Что сказать это действительно очень наглядно и удобно!

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

Во-вторых, на этой картинке не просто зафиксирована ситуация, которая как-то сама по себе сложилась. Изменения на техрадаре это отражение деятельности Архитектурного комитета. В него входят руководители всех основных IT-направлений, и каждая новая технология, которую хотят использовать специалисты, сперва должна пройти проверку и получить одобрение у комитета. Мы делаем это для того, чтобы сдерживать распухание технологического стека. У нас много сложных и совершенно разных систем, так что стек и так весьма внушительный.

Конкретный специалист просто не может знать всё, что уже применяется где-то в компании. Часто оказывается, что инструмент, нужный ему для решения задачи, уже внедрен другой командой. Тогда ему конечно лучше пойти за экспертизой к коллегам, чем самому придумывать велосипед. При таком размере IT-подразделения информация уже не распространяется достаточно хорошо сама по себе, по этой причине мы внедрили практики обмена знаниями. Техрадар одна из таких практик.

Я буду подробнее говорить про это дальше, но хочу подчеркнуть сразу: политика Архитектурного комитета направлена не на то, чтобы запрещать экспериментировать с новыми технологиями, а на то, чтобы эти эксперименты были более осознанными и управляемыми. Наши специалисты не оказываются зажаты в узкие рамки конкретных языков и инструментов на всё время работы в компании. Наоборот, благодаря понятному циклу внедрения новых (или хорошо забытых старых) технологий, если специалисту становится скучно с теми инструментами, с которыми он работает, мы практически всегда можем предложить ему принять участие в экспериментальном проекте. При этом ему не придётся полностью менять направление, и он сможет использовать накопленную экспертизу по той системе, над которой работал.

Итак, к чему же привела за два года такая политика? Подробно об используемых технологиях можно прочитать в предыдущей статье, здесь я расскажу об основных изменениях и каких-то интересных моментах.

Пройдем последовательно по четырем секторам радара, соответствующим основным IT-направлениям: Языки, Управление данными, Платформы и Инфраструктура, Фреймворки и Инструменты.

Но сначала напомню, что означают четыре слоя (статуса принятия технологии) на нашем радаре:

ADOPT технологии и инструменты, которые внедрены и активно используются;
TRIAL технологии и инструменты, которые уже прошли этап тестирования и готовятся к тому, чтобы работать с продакшн (или даже уже работают там);
ASSESS пробные инструменты, которые в данный момент оцениваются и пока не влияют на продакшн. С их участием реализуются только тестовые проекты;
HOLD в этой категории у нас есть экспертиза, но упомянутые инструменты используются только при поддержке существующих систем новые проекты на них не запускаются.

Языки

Как видите, по сравнению с 2018 годом точек в этом секторе стало меньше. Прямо сейчас у нас нет никаких языков в статусе Assess или Trial. Почему так получилось? Для каждой задачи у нас уже есть язык, который нас устраивает. Конечно, мы следим за развитием области и знаем интересные и перспективные языки, которые не используются сейчас в Lamoda, например Rust, но по своим возможностям они являются по сути дублирующими для тех, на которых написаны наши системы. Собственно, одна из целей ведения радара как раз в том, чтобы внедрение новых технологий происходило осознанно и с четким пониманием, какие плюсы нам это принесёт а не просто потому, что язык модный и о нем все говорят.

Если возникает задача, которую можно решить только с использованием нового языка, тут, конечно, внедрение происходит без вопросов. Но даже если мы уже пишем часть систем на чём-то, и в какой-то момент понимаем, что новый язык даст возможность сильно улучшить показатели наших систем или упростит в чём-то разработку тогда мы тоже выделяем ресурсы на эксперименты и потенциальное внедрение этого языка.

Именно так у нас произошло с Go. Когда мы начали активно развивать микросервисную архитектуру, то поняли, что Go для решения многих задач подходит лучше, чем PHP, на котором мы привыкли писать. Да, потребовалось приложить некоторые усилия, чтобы всей командой перейти на него (подробнее мы писали об этом тут). Но в результате очень выросла скорость работы приложений, да и по другим параметрам язык оказался удобен. За два года его стало у нас гораздо больше, в частности он практически полностью вытеснил Python из веб-разработки (но, конечно, Python остался в Data Science и других местах, где необходимо работать с большими массивами данных в таких задачах он однозначно лидер).

На радаре 2018 года видно, что мы пробуем Kotlin, но в 2020 мы уверенно присваиваем ему статус Adopt. Больше двух лет назад мы решили перевести часть Android-разработки на Kotlin язык казался очень перспективным, а наше мобильное приложение только развивалось и мы могли позволить себе эксперимент. Сейчас мы однозначно рады, что приняли такое решение. Не только все наши приложения под Android написаны на этом языке, но также часть бэкенда пока что это эксперимент, но мы возлагаем на него большие надежды. Помимо других очевидных достоинств, Kotlin очень универсальный язык а это значит, что на нем можно писать разные части систем, и передача экспертизы между командами сильно упрощается. И находить новых специалистов на рынке тоже становится проще.

Также по сравнению с 2018 годом из Trial в Adopt переместился TypeScript.
Он сильно расширяет возможности JavaScript, а весь наш огромный сервис доставки написан на нём, работает отлично, и мы пока не планируем это менять.

Управление данными

Практически все базы данных у нас по-прежнему реализованы на PostgreSQL (также мы используем MongoDB, а вот MySQL окончательно перевели в статус Hold).

Но за прошедшие два года у нас появились и новые технологии. В настоящий момент мы пилотируем использование СУБД Greenplum для задач развития нашей платформы данных. В нашем арсенале есть Oracle и Vertica прекрасные базы, но мы ищем способы удешевить стоимость владения инфраструктурой, поэтому рассматриваем Opensource решения. Возможно, это будет не замена, а дополнение время покажет.

Мы решили заменить Tableau на Microsoft Power BI как средство создания BI дашбордов, и уже завершили эту миграцию. Мы посчитали, что хотим дать доступ к дашбордам всем желающим, и в Power BI это выходит дешевле, так как на просмотр отчетов покупать лицензии не нужно.

Также мы внедрили Oracle APEX в качестве создания Web интерфейсов для ведения ручных справочников в хранилище данных. Ранее для этого использовались XLS-файлы, загружаемые с сетевого диска. Oracle APEX позволил нам сделать удобный интерфейс для бизнес-пользователей, теперь они могут самостоятельно обновлять данные в удобном Web приложении.

На радаре изменений в этом месте нет, но стоит отметить еще более глубокое проникновение Apache Airflow в процессы создания платформы данных. Сейчас это основной оркестратор задач обработки данных, он пришел у нас на замену Luigi.

Интересно произошло с RabbitMQ в свое время мы внедрили его, но он не всем нас устраивал, и мы даже думали совсем от него отказаться. Но потом пришли новые специалисты в команду администрирования, и оказалось, что RabbitMQ хорош, мы просто не умели его готовить. После того, как мы перешли с FreeBSD на Linux, RabbitMQ уверенно находится в статусе Adopt.

Платформы и инфраструктура

Вот здесь большие изменения произошли. Когда мы первоначально выбирали инструменты для деплоя, то остановились на связке Nomad + Consul. У нас был большой кредит доверия к компании Hashicorp, которая их выпускает, и в целом решение нас устраивало пока не произошло несколько критических падений при апгрейдах оборудования. Устранение неполадок каждый раз требовало много времени и ресурсов, а компания понесла определенные убытки. Тогда мы перешли на ставший более популярным Kubernetes.
Возможно, новые версии Nomad работают более стабильно, но у нас после той истории, можно сказать, остался шрам так что нет желания проверять. Тем более, что Kubernetes в связке с Docker нас полностью устраивают.

Фреймворки и инструменты

Пожалуй, именно в этом сегменте новые модные технологии появляются чаще всего. И именно здесь мы видим, как работает техрадар и Архитектурный комитет, сдерживая неоправданную трату ресурсов на эксперименты на продакшне (которые в последствии привели бы к необходимости управлять разношерстной системой, написанной на множестве фреймворков, или унифицировать её и то, и другое очень трудозатратно).

Например, мы пробовали разные фреймфорки для JavaScript, но старались экспериментировать на некритичных для бизнеса задачах. А главное, мы помнили, что это эксперимент, и в итоге мы хотим выбрать минимальный набор подходящих нам инструментов. Такая политика привела к тому, что React, например, так и не стал использоваться на проде. Angular и другие фреймворки ушли в статус Hold, и в основном на фронтенде мы используем vue.js, который показал себя в этом соревновании лучше остальных.

Естественно, какие-то фреймворки уходят вместе с языками, для которых их использовали. Так например произошло у нас с Django, когда Go почти полностью вытеснил Python из веб-разработки.

Это нам подходит!

В заключении статьи 2018 года мы сказали в двух словах мы пишем на GO, PHP, Java, JavaScript, держим базы на PostgreSQL, а деплоим на Docker и Kubernetes.
Такое обобщение верно и сейчас единственное, в список основных языков однозначно ворвался Kotlin.

Получается, что выбранные нами два года назад основные инструменты и технологии оказались действительно подходящими под наши задачи и наш подход к разработке.

И благодаря работе Архитектурного комитета и, в частности, ведению техрадара, мы знаем, что конкретно эти технологии попали в наш стек не случайно. Они честно победили своих конкурентов в борьбе на экспериментальных проектах, и обоснованно используются на продакшне.

Конечно, на рынке будут появляться новые инструменты, которые подходят нам больше тех, что мы используем сейчас.
Мы рассчитываем, что в нашей системе естественного отбора технологий эти инструменты пройдут свой путь от Assess до Adopt и при необходимости заменят текущие.

Подробнее..

Категории: It-инфраструктура , Микросервисы , Высокая производительность , Разработка под e-commerce , Инфраструктура , Блог компании lamoda , Lamoda

Основные тренды развития телекоммуникаций в эпоху всем надоевшей пандемии

29.10.2020 14:07:14 |

Автор: admin

28 октября Франция ушла в режим самоизоляции, аналогичным образом поступила Германия, хотя и с более мягкими условиями. Вероятно, в течение пары недель карантинный режим установят и другие страны например, Испания, которая уже закрыла некоторые регионы.

Понятно, что все это будет иметь очень сильные последствия для разных отраслей бизнеса, включая IT. Несмотря на кризис, выручка производителей от продаж оборудования для развертывания облачной инфраструктуры, растет. О тенденциях телекома в этот сложный период и рассказывается в статье.

Затраты компаний на оборудование для облачных сервисов растут

По данным экспертов Idc, выручка производителей сетевого оборудования, включая серверы, СХД, коммутаторы, постепенно растет. Объясняется это просто бизнесу и государственным учреждениям необходимо быстро развивать телекоммуникации, чтобы выдержать растущую нагрузку на сети. Соответственно, растут затраты у одних компаний и прибыли у других.

Так, увеличение выручки от продаж оборудования для облачной инфраструктуры по сравнению с прошлым годом составило 34,4%. А вот аналогичный показатель для оборудования, которое не связано с IT-инфраструктурой, снизился на 8,7%% по сравнению с прошлым годом.

Что касается общедоступных облачных сервисов, то здесь расходы за год выросли на 47,8%, достигнув показателя в $14,1 млрд. Аналитики утверждают, что в этом году расходы этого типа впервые превысили расходы на традиционную IT-инфраструктуру. Ну а поскольку пандемия развивается, то рост облаков будет продолжаться. По мнению экспертов, к концу года расходы бизнеса на этот сегмент составят примерно 54%.

Основные драйверы роста

Тренды, о которых идет речь, были хорошо заметны уже весной рынок очень активно реагирует на изменения во всех сферах работы и жизни. Стало популярным дистанционное образование, развивается телемедицина, увеличивается количество развлекательных сервисах. Это не могло не повлиять на увеличение закупок сетевого оборудования и всего, что связано с облаками. По мнению аналитиков, к концу этого года расходы бизнеса и государственных организаций на платформы для облачной инфраструктуры вырастут на 50,9%, достигнув объема в $37,7 млрд. Активнее всего растет рынок корпоративных СХД и коммутаторов Ethernet.

Эти тренды проявили себя не в каком-то одном регионе, а практически во всех странах, включая Европу, Китай и США. В последних двух регионах годовой показатель роста составил 60,5% и 36,9%. При этом публичные облака развиваются гораздо быстрее, чем частные. К концу этого года выручка от них повысится на 15% до $52,4 млрд.

Если говорить в общем, то к 2024 году расходы на облачную IT-инфраструктуру увеличатся до отметки в $109,3 млрд. Это около 63,6% от общего объема расходов на IT-инфраструктуру. Расходы на частную облачную инфраструктуру увеличатся в среднем на 9,3%.

Увеличился спрос и на гибридные решения. Дело в том, что у большинства компаний, как небольших, так и крупных, разнородная IT-инфраструктуры. Поэтому для оптимизации компании выбирают многокомпонентные среды, используют выделенные инфраструктуры в коммерческих ЦОДах.

Большинство компаний, которые стали использовать облачную инфраструктуры, оценили преимущества, которые она дает. Так, у кого-то резко увеличились масштабы использования внутренних IT-сервисов, так что потребовалось срочно расширять мощности. А у кого-то, наоборот, бизнес не такой активный, как в самом начале года, так что облаками такая компания пользуется меньше. Соответственно, гибкая инфраструктура дает возможность быстро снизить нагрузку и сэкономить средства.

А что в России?

Не удивительно, что в РФ рынок облачных услуг тоже растет он увеличился на 24,8% в этом году, превысив ожидания аналитиков. Понятно, что большинство прогнозов составлялись в прошлом году, так что они несколько отстают от реальных показателей. В РФ, как и во всем мире, превалирует рынок публичных облаков его доля составляет 85% на рынке облачных решений. Львиная доля этого рынка принадлежит корпорации Microsoft.

В 2019 году выручка 10 крупнейших отечественных поставщиков SAAS (Software-as-a-Service) увеличилась на 48% по сравнению с 2018 годом. В абсолютном значении объем рынка увеличился для 48 млрд рублей. Что касается рынка IaaS в РФ, то объем его был в два раза меньше. Выручка топ-10 компаний из РФ составила около 24 млрд роста. Если брать топ-100 компаний, то общий объем их выручки в РФ по итогам прошлого года увеличился на 22%.

Особенно востребованными облачные технологии стали в таких сферах, как финансовые услуги, телекоммуникации, производство, фармацевтика, автомобилестроение.

Кстати, по данным Mail.ru, сейчас у бизнеса и обычных пользователей растет интерес к таким инструментам, как облачные технологии, корпоративные мессенджеры и почта, порталы и чат-бота. По словам представителей компании, всего полгода назад ни одной из этих технологий не было в отчетах аналитиков, но сейчас они заняли в этих отчетах первые места.

Фиксированная связь с ней все хорошо?

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

Телеком не просто социально ответственный бизнес без нас самоизоляция невозможна в принципе. Мы помогаем пережить стресс, организовать общение с близкими, обеспечить снабжение продуктами питания и лекарствами, наладить взаимодействие все это возможно только благодаря интернету. И то, что у нас в стране высокий уровень проникновения ШПД, оказалось важно, заявил представитель одной из крупнейших IT-организаций в стране.

Но, к сожалению, у многих провайдеров и операторов падает выручка. Так, из-за того, что многие сервисы предоставлялись бесплатно, падение составило 5-10%. Правда, в условиях второй волны карантина возможно начало бурного роста, который перекроет падение выручки.

С другой стороны, нельзя забывать об инициативе правительства РФ в плане предоставления бесплатного доступа к социально значимым ресурсам. Операторы, хотя и без особого энтузиазма, стали искать решения, которое помогли бы выполнить эту инициативу.

Что дальше?

Распространение вируса тем либо иным образом удастся остановить. К сожалению, не все бизнесы смогут пережить вторую волну коронавируса уж слишком непростые у них экономические условия. Максимальный риск для небольшого бизнеса в сфере услуг. Тем не менее, большинство компаний все же вернутся к работе.

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

По душе пришлась дистанционная работа и многим работодателям ведь в этом случае никто на работу не опаздывает, связаться с человеком можно в любое время. Вероятно, в недалеком будущем на удаленку перейдут новые компании, которые не успели сделать это в начале текущего года. И тогда нагрузка на сети увеличится еще сильнее.

Выход здесь один закупать новое оборудование, строить сети и прокладывать кабели. Одними административными мерами здесь не поможешь.

В свете пандемии и удалёнки, присмотритесь к централизованной системе управления сеть Zyxel Nebula. Это экосистема аппаратных и программных компонентов, которая поможет не только развернуть сеть УДАЛЕННО, но и управлять и масштабировать. Прицепить точку доступа на потолок в филиале и воткнуть в нее RJ-45 может любой дядя Вася, а администратор, удаленно подключается к точке, настраивает ее и контролирует параметры ее работы. То же и с коммутаторами и межсетевыми экранами.

Задать вопрос специалистам, запросить оборудование на тестирование и вообще, удобно в нашем телеграме t.me/zyxelru.

Добро пожаловать!

Подробнее..

Категории: It-инфраструктура , Пандемия , Сетевое оборудование , Исследования и прогнозы в it , Инфраструктура , Блог компании zyxel в россии , Телеком , Оборудование

Как построить модульный ЦОД за три месяца и не наступить на грабли

30.10.2020 10:10:09 |

Автор: admin

Этот модульный ЦОД мы построили меньше, чем за три месяца. В первых числах ноября начали монтаж на площадке, а в конце декабря уже сдали его в эксплуатацию.

В общих чертах запрос от заказчика именно таким и был: очень быстро нарастить вычислительные мощности под свой ИТ-проект там, где дополнительного места совсем нет. Решено было построить модульный ЦОД. ~~И сделать это недорого.~~ Спустя год готов рассказать, как это было. Как мы делали полную предварительную сборку и разборку ЦОДа на площадке в Сибири. Как поливали его водой из мойки Керхер и разогревали, как духовку.

Заодно поделюсь нашим опытом обхода граблей при строительстве модульных дата-центров. А также расскажу о некоторых граблях, на которые мы все-таки наступили, но в каске.

Суровая правда жизни: начало подготовительных работ

Для тех, кто не особо следит за строительными технологиями ЦОД, краткая справка о модульных решениях:

а) для них не требуется разрешение на капитальное строительство;

б) их можно быстро поставить где угодно, хоть посреди леса, лишь бы было электричество и каналы связи;

в) они как конструктор лего можно разобрать и перевезти на новое место дислокации. И относительно легко, при необходимости, нарастить.

Что касается именно этого проекта, то основные критичные характеристики для заказчика обоснование некапитальности сооружения и демонстрация возможности неоднократной сборки и разборки. Плюс возможность наращивания ИТ-мощностей в дальнейшем.

Кроме того, в проекте требовалось выполнить монтаж внешних инженерных сетей (КЛ-0,4кВ, сети связи, водоснабжение, водоотведение) и модернизировать существующую электрощитовую. Она находилась в административном здании, от которой выполнялось подключение МЦОД.

Когда начали работу, выяснилось, что на площадке под асфальтом захоронен цокольный этаж старого здания, о котором никто, включая заказчика, не знал. В итоге спроектировали бетонную площадку, взяв категорию грунта Строительный мусор. Разработали котлован, выполнили отсыпку щебнем и песчаной подушкой. Дополнительно залили 300 мм армированного бетона. Таким образом исключили риски перепада плотности грунта под модульным зданием.

Бетонное основание под МЦОД

Внешние сети как это было

Первые грабли состояли в том, что у заказчика не оказалось актуальной версии геоподосновы. Нашелся только архивный файл. Более того, отсканирован он был не в масштабе, и нам было сложно понять привязку коммуникаций и самого модульного ЦОДа. В итоге в наши расчеты все же закралась ошибка в 2,5-3 метра. Из-за нее пришлось сначала убрать одно крытое парковочное место на территории, а потом его восстанавливать.

Работы по устройству внешних коммуникаций шли параллельно с подготовкой бетонного основания. Одновременно заказчик совместно с МОЭСК модернизировал трансформаторную подстанцию РУ-0,4кВ. Это все, конечно, добавило нам головной боли.

Прокладка коммуникаций

Электрощитовую в административном здании мы реконструировали ночью. Требовалось поэтапное отключение линий электропитания всего административного здания, а в нем потребители I особой категории. Например, в этом же здании находились серверы одной довольно крупной авиакомпании. Естественно, подключали резервный источник питания мобильный ДГУ на случай форс-мажорной ситуации. Успели, кстати, за одну ночь все сделать.

Когда закончили работы с коммуникациями, встал вопрос о восстановлении асфальта на парковке. Начали этот вопрос прорабатывать и поняли, что старый асфальт положен на все тот же строительный мусор, а мы-то свои траншеи засыпали по правилам! Что произойдет, если положим асфальт? Правильно, в лучшем случае он начнет трескаться на границах разных зон. Посоветовались со специалистами и сделали решение по легкому бетону. Забетонировали тонким слоем площадку, и уже на бетон положили новый асфальт.

Примерно вот так шли работы

Ну что сказать, год прошел - асфальт в хорошем состоянии.

Испытание водой и жарой

Одним из ключевых требований заказчика было провести предварительные испытания МЦОД на производстве и показать, что модульное здание соответствует основным требованиям. Пока мы занимались подведением коммуникаций, модульная конструкция уже была в производстве в Новосибирске. Дальше нам нужно было продемонстрировать заказчику возможность сборки и разборки ЦОДа. И вот тут началось самое интересное.

Обычно бывает предсборка модульных ЦОД на производстве, но это не наш случай. Заказчик требовал, чтобы модульное здание было собрано полностью с фальшполом, с освещением, с общей электрикой и даже с пандусом. План был такой: полностью собрать модульное здание, провести предварительные испытания, разобрать здание, привезти в Москву и затем собрать еще раз.

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

Оба снимка сделаны на площадке производителя 3 октября

Приехала целая делегацияи наши инженеры, и представители заказчика. Многочасовые испытания шли два дня. Проводили проверку геометрических параметров модульного здания и помещений, отсутствия возможных мостиков холода, отклонений высот фальшпола. Контролировали степень освещенности машинного зала на соответствие ТЗ. Еще была проверка на герметичность поливали ЦОД водой из мойки Керхер под давлением.

Но самое необычное испытание на теплопотери. Для этого мы арендовали тепловые пушки, и с утра в ЦОДе их запустили. Нагрев шел около двух с половиной часов. Температура внутри здания была на 50 градусов выше, чем снаружи. Жара стояла такая, что зайти в ЦОД было тяжело. Представители заказчика с тепловизором проходили вдоль стен и смотрели, нет ли тех самых мостиков холода мест, где теряется тепло. Это было эпично. Но зато мы точно были уверены, что нагрев и охлаждение ЦОД будет полностью предсказуем в боевых условиях.

История с фальшполом

После того, как испытания успешно прошли, примерно за неделю модульное здание было разобрано. Подрядчик погрузил его в фуры, и часть из них сразу выехала в Москву. Выезжали фуры по очереди, чтобы мы могли сразу с колес выгружать и начинать монтаж. Так мы избежали аренды склада. Можно сказать, это грабли, на которые мы не наступили.

Модульная конструкция готовится к отправке из Новосибирска в Москву. 29 октября

Интересная история была с фальшполом. Если кто не в курсе, фальшпол важная подсистема в ЦОД. Он держит все технологическое оборудование, и от его качества сборки и жесткости во многом зависит надежность ЦОДа.

14 ноября - сборка основных конструкций уже завершена. Занимаемся фальшполом.

В проекте у нас были предусмотрены ИБП весом под тонну, да еще и кондиционеры по 900 кг каждый. Подрядчик посчитал нагрузки и попытался убедить нас в том, что, мол, не извольте сумлеваться, выдержит!

Но слова должен выдержать нас не убедили.

Что мы сделали? Разработали рамы, усиливающие фальшпол под кондиционерами и ИБП. Для бесперебойников это была одна длинная мощная конструкция. Под фальшпол ее опускало человек пять или шесть.

Рамы для ИБП

А под кондиционеры мы сделали раму с ножками. Ножки эти вставали в паз в существующие металлические фермы основания модульного ЦОДа.

И тут снова грабли из-за спешки ребята-сварщики приварили ноги от другой рамы. Ноги получились короткими, и рама оказалась не на уровне фальшпола. А на следующий день уже все расписанокондиционеры приезжают, заключен договор на такелажные работы Звоним нашему инженеру (не просто инженеру, а с большой буквы И который). Пара звонков мужикам и за ночь вопрос удалось решить.

Переварили ножки, и раму мы установили. И так как все считали наши ребята, мы спокойны двукратный запас по прочности там точно есть.

Заказчику все тоже понравилось, кстати.

26 ноября - работа идет полным ходом.

ДГУ заказывали?

Самое большое зло в этом проекте сжатые сроки. ЦОД и так сложное сооружение, а тут нужно было уложиться в считанные недели. На сборке работало две смены. Одни люди выходили, другие заходили на объект. И так семь дней в неделю.

Конечно, не обходилось без накладок. Например, лежит материал в доступе у монтажников. Они его берут, но об экономии думать уже некогда. В итоге нашим инженерам-проектировщикам приходилось с ходу определять потребности и докупать расходники. Каждый день и час был на счету.

При сборке кондиционеров был вопрос в качестве пайки медных труб. Когда мы уже подключили кондиционеры и начали испытания, обнаружилось несколько утечек в фреонопроводе. Отдельная история была найти места этих утечек. Они ведь часто микроскопические.

Или, вот, например, дизель-генераторная установка (ДГУ). Заказчик говорит: у нас установка есть, привезем. Привозят и тут же выясняется, что ДГУ не соответствует их же собственным требованиям! Наигрались мы с ней в итоге: дорабатывали и в части хранения топлива, в части конструкции модуля. Ставили шумопоглощающие маркизы, которые направляют звук в землю, катализатор и глушитель.

Каждый день было перепланирование работ если что-то успевали быстрее сделать, план сразу переигрывали. Честно говоря, заказчик, да и мы сами, не до конца верили, что успеем за 3 месяца. Но все получилось, успели. Чистая стройка заняла вообще около месяца. Перед самым Новым годом ЦОД запустили.

И напоследок вот, как это было, три месяца работы в одном видео:

Ссылки

Особенности строительства национальных дата-центров, Михалыч
Как мы заморочились по фрикулингу для дата-центра и что из этого вышло
Моя почта - SMakhlin@croc.ru

Подробнее..

Категории: It-инфраструктура , Инженерные системы , Цод , Инфраструктура , Дата-центр , Блог компании крок , Строительство , Оборудование , Строительство цод , Инженерная инфраструктура

Recovery mode Компьютер с кипящим охлаждением представлен на семинаре в ИПС РАН

03.11.2020 12:06:29 |

Автор: admin

16 октября 2020 года на семинаре в Институте программных систем РАН (Переславль-Залесский) была показан экспериментальный компьютер, охлаждаемый кипящей жидкостью. Конечно, кипящей при невысокой температуре (40C). По словам исследователей, это позволяет в тысячи раз улучшить отбор тепла на процессоре и создать одинаково холодные условия во всей установке.

_{Слева монитор управляющей системы,

справа компьютер, на его процессоре заметно
кипение.}

Компьютер не перемещает никаких грузов, не обрабатывает сырья, не выпекает хлеб или керамику то есть не тратит электрическую мощность на производство продукции. Вся эта мощность должна быть рассеяна компьютером без перегрева, всё его тепло надо сбросить в окружающую среду. Поэтому охлаждение электроники становится очень важной, ключевой задачей. Шаг за шагом было придумано воздушное охлаждение, потом изолированное жидкостное (охладитель в трубках), потом погружное (электроника плавает в охладителе). А теперь сделан следующий шаг фазовый переход.

Стенд работает

Бросим взгляд на экспериментальную установку. Вот аквариум с материнской платой. В него налита фторкетонная жидкость. И да, она совсем сухая на ощупь, потому что мгновенно испаряется с ладони. На процессоре эта жидкость кипит пузырьками и превращается в пар.

_{Для проверки на стенде установлен набор
резисторов.}

Чуть выше стоит конденсатор, в нём течёт холодная вода и собирает всё тепло, которое несёт этот пар. Отдав тепло, пар конденсируется и капает вниз, а вода, нагревшись, течёт в теплообменник в нижней части стенда. Здесь тепло из воды уходит на улицу, а холодная вода возвращается в конденсатор.

_{Конденсатор, который собирает
тепло.}

Говорит один из разработчиков, кандидат технических наук Сергей Анатольевич Амелькин:

Мы погружаем процессор в кипящую жидкость, и его тепло передаётся кипящей жидкости. Если кипение происходит при достаточно низкой температуре, процессор не будет сильно греться, а тепло будет собрано жидкостью. При этом жидкость изменит фазовое состояние, станет паром. Этот пар сам поднимается через слой жидкости наверх к конденсатору. Экспериментальная установка и работает, и жидкость в ней кипит, и дождик капает!

_{Охлаждающая жидкость закипает, видны
капли и брызги.}

На 140 ваттах мощности, которые отдаёт экспериментальный вычислительный узел, разница температуры между процессором и жидкостью составила 35 градусов. Это соответствует коэффициенту теплопередачи 2500 Вт/(мК).

По расчёту в этом аквариуме можно утилизировать в окружающую среду 15 кВт мощности при температуре окружающей среды 20 градусов. Сейчас, подключённый к обычной розетке, стенд выводит в воздух 2,5 кВт мощности. (Таково ограничение электрической сети в лаборатории.) Кипеть начинает за пять минут. Опыт сделан на комплекте резисторов, включённом через ЛАТР.

Снова дадим слово разработчику. Говорит доктор технических наук Анатолий Михайлович Цирлин:

Опуская компьютер в кипящую жидкость, мы фиксируем температуру всех элементов. Они будут иметь ту температуру, при которой жидкость кипит. Это стабильная температура, не надо никакого регулирования.

_{Охлаждающая жидкость бурлит и
плещется.}

Коэффициент теплообмена теперь резко увеличился. За счёт этого процессор теперь охлаждается напрямую, без радиатора. Однако площадь самого процессора невелика, поэтому не удаётся снимать с него очень уж большую мощность. Есть мысль создать специальный радиатор, который будет контактировать с процессором в нескольких точках. Хотя площадь контакта у него будет маленькой, но ведь поверхность теплообмена будет значительно больше.

Что будет дальше

Лабораторная установка, показанная в ИПС РАН, позволит учёным экспериментально изучать режимы и процессы двухфазных охладительных систем. Тут можно сравнивать различные охлаждающие жидкости и хладагенты, проверять работу радиаторов, продолжая исследования в области кипящего охлаждения.

О продолжении этих исследований мы спросили Анатолия Михайловича Цирлина, и вот что он рассказывает.

Наша следующая цель кипящий струйный компьютер, в котором струя кипящей жидкости обтекает горячие элементы, чтобы распределять её на самые горячие места. За счёт движения жидкости можно увеличить коэффициент теплоотдачи в три раза. Но ещё важнее, что за счёт движения жидкости можно управлять переходом кипения от пузырькового режима к плёночному, когда образуется плёнка пара. Такой переход в плёночный режим опасен, при нём всё перегревается.

В перспективе эти работы могут быть использованы при разработке суперкомпьютеров. К сожалению, сейчас в России не строят коммерческих суперкомпьютеров, а недавно запущенный суперкомпьютер Сбербанка Кристофари был разработан и построен американской компанией Nvidia.

_{Тепло стремительно уходит за счёт
кипения.}

Кто придумал и построил всё это

В работе участвовали четыре человека: дтн Анатолий Михайлович Цирлин, ктн Сергей Анатольевич Амелькин, аспиранты Алексей Анатольевич Петров и Алексей Алексеевич Демидов. Они трудятся в Институте программных систем имени Айламазяна РАН в городе Переславле, Ярославская область.

_{Сергей Амелькин демонстрирует работу
стенда.}

Анатолий Михайлович Цирлин придумал эту идею (DOI) и предложил её в 2016 году, выступая на Национальном Суперкомпьютерном Форуме в Переславле.

Кандидат технических наук Сергей Анатольевич Амелькин разработал математическую модель системы охлаждения, основанной на фазовом переходе. Выбран оптимальный режим, соответствующий минимальной необратимости процесса охлаждения. Опираясь на модель, он предложил конструктивные решения, которые обеспечат реализацию такого режима, и разработал алгоритмы для управления погружными двухфазными системами охлаждения.

Аспирант Алексей Алексеевич Демидов проводил расчёты, проектировал инженерную 3D-модель экспериментальной установки. Исходя из гидравлической схемы, он расположил в столе и в аквариуме все компоненты гидравлики конденсатор, драйкулер, насосы, теплообменник, расширительный бак. Он моделировал вычислительный узел и испытательный блок с нагрузочными резисторами, подготовил чертежи и конструкторскую документацию. Наконец, он контролировал весь процесс сборки и наладки стенда в лаборатории.

Аспирант Алексей Анатольевич Петров уже несколько лет создаёт системы управления для погружного охлаждения фирмы Иммерс. Такая система управляет насосами и вентиляторами через программируемые контроллеры. Задача тут непростая надо поддержать в каждом контурне системы охлаждения постоянный температурный режим. С одной стороны, надо обспечить низкую температуру, а с другой стороны, хочется тратить минимум энергии на работу охладительной системы при самой разной температуре окружающего воздуха, куда, собственно, всё тепло в конечном счёте уходит. Здесь он писал SCADA-систему, которая слушает датчики температуры и давления, включает и выключает вентилятор, выводит сведения на экран оператора то есть управляет всей аппаратурой.

Вот такой был семинар и вот такие достижения. Надеюсь, не в последний раз.

Текст и иллюстрации: CC-BY-SA 3.0.

Подробнее..

Категории: It-инфраструктура , Инженерные системы , Производство и разработка электроники , Будущее здесь , Инфраструктура , Суперкомпьютеры , Охлаждение , Оборудование , Жидкостное охлаждение , Погружное охлаждение

Ламповая self-hosted инфраструктура на Vultr

13.12.2020 06:19:29 |

Автор: admin

О чём, зачем и почему?

Эту небольшую заметку я решил написать после собственного опыта разворачивания личной "инфраструктуры", состоящей из нескольких приложений для повседневных дел.

Здесь я расскажу, как развернуть сервисы для контроля финансов (FireFly3), заметок и чего покрупнее (BookStack) и контроля времени, уходящего на задачи в opensource проектах или на работе (Titra) всё это на Vultr с защитой с помощью firewall групп и доступа только с нужных ip, например, домашней статики или vpn (ещё развернём для этого Pritunl).

Vultr я выбрал, так как достаточно давно с ним работаю и уже знаю, что он может, а что нет в моём случае он подошёл идеально.

Надеюсь, что это окажется для кого-то полезным.

Разворачиваем сервисы

Для сервисов (всех трёх) я выбрал простой инстанс на Vultr + автоматические бэкапы, так как все они не особо требовательны к ресурсам.

Прим.: Предполагается, что у вас есть свой домен с DNS, где вы можете настроить субдомены для всего ниже описанного и получения сертификатов (certbot), исходя из этого, для удобства, в статье я буду писать про personal.io, а вы представляйте личный :)

Прим. 2: Ещё небольшое предупреждение я буду писать про сервисы в docker, однако, все они прекрасно разворачиваются и без контейнеров.

Финансы FireFly3

Demo

Собственно я люблю вести фин. учёт по всем своим доходам и расходам: видеть на что вы тратите ваши деньги и как возможно, что-то оптимизировать, по-моему достаточно важно.

Для моих целей вполне подходит FireFly3 в нём вы можете отслеживать все свои счета, регулярные транзакции, долги и т.д. и т.п.

На наше счастье разработчики firefly3 сделали удобную документацию с описанием развёртывания приложения, как с помощью docker, так и без оного. Приведу свой docker-compose файл c firefly и БД для него:

version: '3.3'services:  fireflyiii:    image: jc5x/firefly-iii:latest    volumes:      - firefly_iii_upload:/var/www/html/storage/upload    env_file:      - .env    restart: unless-stopped    ports:      - 127.0.0.1:34567:8080    depends_on:      - fireflyiiidb  fireflyiiidb:    image: yobasystems/alpine-mariadb:latest    restart: unless-stopped    env_file:      - .env.db    volumes:      - firefly_iii_db:/var/lib/mysqlvolumes:   firefly_iii_upload:     driver: local   firefly_iii_db:     driver: local

Так же, весьма важен env-файл для самого сервиса, так как в нём настраиваются все базовые моменты для развёртываемого инстанса, как то: тип используемой БД, с помощью чего отправлять вам письма счастья (SMTP или MAILGUN), логи, аутентификация (если, вдруг, вам вместо стандартного eloquent понадобится LDAP), ну и доменное имя на котором будет сервис, в нашем случае настроим его на finance.personal.io. Оставляю пример этого самого env-файла (с комментами от разработчиков) на pastebin с выставленными значениями под нашу статью.

С firefly3 на этом всё, после того как мы сделаем nginx proxypass и получим сертификат вам нужно зарегистрироваться в сервисе, после чего вы сможете отключить эту возможность.

Заметки, документация и т.д. BookStack

Demo

У меня часто возникает желание/необходимость, что-нибудь написать по работе или личное, поэтому для меня такой сервис, как BookStack показался крайне удобен возможность создавать отдельные полки, регулировать права, наглядный markdown редактор (приложу скриншот, как пишу это именно в нём), понятная иерархия: полки-книги-листы.

Такой сервис может подойти как для личного пользования, так и для командного в небольших компаниях.

docker-compose.yml:

version: "3.1"services:  bookstack:    image: linuxserver/bookstack    container_name: bookstack    volumes:      - bookstack-volume:/config    ports:      - 127.0.0.1:34568:80    env_file:       - .env.bookstack    restart: unless-stopped    depends_on:      - bookstack_db  bookstack_db:    image: linuxserver/mariadb    container_name: bookstack_db    volumes:      - bookstack-db:/config    env_file:       - .env.db    restart: unless-stoppedvolumes:  bookstack-volume:    driver: local  bookstack-db:    driver: local

Тут с предварительной конфигурацией всё намного проще, чем у firefly, так как почти всё можно настроить через web интерфейс.

.env.bookstack:

DB_HOST=bookstack_dbDB_USER=bookstackDB_PASS=bookstackpasswordDB_DATABASE=bookstackappAPP_URL=https://notes.personal.io

При первом входе, вам также понадобиться зарегистрировать admin юзера, но это позже.

В bookstack так же доступна аутентификация по LDAP, а так же по SAML или через социальные сети всё это настраиваемо. Так же есть экспорт опусов в pdf и html, публичный доступ к полкам или отдельным книгам, т.е. без пользователя.

Учёт потраченного времени Titra

Demo

У меня есть как личные, так и рабочие проекты, поэтому мне важно знать, сколько времени я потратил на ту или иную задачу. В Titra вы можете разграничить всё на разные проекты, проектные задачи, назначить стоимость вашей работы (например, за час), указать со скольки вы работаете и во сколько у вас перерыв (оплачиваемый или нет), ну и статистические отчёты за разное время тоже присутствуют с фильтрацией по отдельным проектам и т.д.

docker-compose.yml:

version: "3.1"services:  titra:    image: kromit/titra    container_name: titra    depends_on:      - mongodb    ports:      - "127.0.0.1:34569:3000"    env_file:      - .env.titra    restart: always  mongodb:    image: mongo:4.2    container_name: mongodb    restart: always    volumes:      - titra_db:/data/dbvolumes:  titra_db:    driver: local

.env.titra:

ROOT_URL=https://titra.personal.ioMONGO_URL=mongodb://mongodb/titra

Бонус: страница со ссылками на ваши сервисы Homer

Demo

Чтобы не потерять ссылки на все ваши сервисы особенно, если их станет больше, лучше всего иметь страницу, которая бы показывала, где и что у вас развёрнуто. Я когда задумался об этом, выбирал между heimdall и homer, остановился на последнем, так как его легче настроить и он вполне удовлетворяет условиям поставленной задачи.

На странице Homer вы сможете настроить ссылки на ваши сервисы, разнести их по разным группам, кастомизировать их отображение (например, присвоить каждому иконку).

docker-compose.yml:

version: "3.3"services:  homer:    image: b4bz/homer:latest    volumes:      - ./assets:/www/assets    ports:      - "127.0.0.1:34570:8080"    restart: unless-stopped

Для работы homer вам придётся создать assets директорию с файлом config.yml, где вы и укажите, что и как отображать.

Давайте первоначально напишем его таким образом:

title: "Infrastructure"subtitle: "Personal"documentTitle: "Personal/Infrastructure"icon: "fas fa-skull-crossbones"header: truecolumns: "3"theme: defaultcolors:  dark:    highlight-primary: "#3367d6"    highlight-secondary: "#4285f4"    highlight-hover: "#5a95f5"    background: "#131313"    card-background: "#2b2b2b"    text: "#eaeaea"    text-header: "#ffffff"    text-title: "#fafafa"    text-subtitle: "#f5f5f5"    card-shadow: rgba(0, 0, 0, 0.4)    link-hover: "#ffdd57"services:  - name: "Main"    icon: "fas fa-code-branch"    items:      - name: "Titra"        icon: "fas fa-clock"        subtitle: "time-tracking"        url: "https://titra.personal.io"      - name: "FireFly3"        icon: "fas fa-piggy-bank"        subtitle: "finance"        url: "https://finance.personal.io"      - name: "BookStack"        icon: "fas fa-book"        subtitle: "notes-articles-book"        url: "https://notes.personal.io"

Страница будет выглядеть так:

Разместим её на home.personal.io

Домены и сертификаты

После того, как мы всё написали и запустили нам нужно настроить nginx и попросить пару сертификатов у certbot. Я приведу пример общего для сервисов файла настройки, который можно и нужно разделить на несколько: apps.conf

Запустим nginx:

systemctl start nginx

Далее, предварительно создав необходимые A-записи в настройках DNS у вашего домена, чтобы поддомены home, notes, finance, titra ссылались на ip машины на Vultr, мы запросим с помощью certbot сертификаты Let's Encrypt, чтобы соединение было безопасным:

certbot run --nginx

После получения сертификатов, вы можете заходить на ваши сервисы и регистрироваться.

Защищаемся

Чтобы быть уверенным, что никто не зайдёт туда, куда не следует я сделал следующее:

Развернул Prtinul сервер
Создал firewall группу в панели управления Vultr

Собственно, как быстро (обещают за 60 секунд) pritunl на vultr уже написано.

Я расскажу лишь, как можно быстро настроить firewall правила для vultr машины (или нескольких)

Заходим на страницу ваших огненных стен

Жмём плюсик и в выпавшем меню "Add firewall group".
Добавляем правила, например, я решил, что лучше всего оставить открытым 22 порт, а остальные сделать доступными только из-под VPN. Например, так:

Ждём, так как правила накатятся не мгновенно, а примерно за две минуты.
Наслаждаемся ~~своей непохожестью~~ безопасностью и контролем за важными для вас данными.

Подробнее..

Категории: It-инфраструктура , Open source , Devops , Настройка linux , Vpn , Облачные сервисы , Инфраструктура , Finance , Self-development , Self-hosted , Notes , Vultr , Pritunl

Одна Kafka хорошо, а несколько лучше

26.01.2021 20:09:19 |

Автор: admin

Всем привет! Меня зовут Александр, я инженер команды, отвечающей за развитие централизованныхIT-сервисов, которыми пользуются продуктовые команды вX5RetailGroup.

В этой статье речь пойдёт обApacheKafkaи том, как этот продукт используется для обеспечения потребностей команд разработки. Статья не погружает в технические аспекты, но может быть полезна архитекторам и менеджерам, которые думают о том, чтобы попробовать использоватьKafka, но не знают, подойдёт ли она для их задач, а также разработчикам, которые могут открыть для себя новые инструменты для удобной работы с кластерами.

На момент написания статьи силами нашей команды развёрнуты и поддерживаются 14 продуктивных кластеров (1 централизованный и 13 у продуктовых команд) и 15 непродуктивных.

Централизованный кластер Kafka

Основной сценарий, в рамках которогоKafkaиспользует наша команда доставка логов вElasticsearch.

Немного цифр об этом кластере для начала:

брокеры - 5
топики 179
consumer группы 77
средний объем данных^[1]в топиках 555.1 ГБ

_{[1] значение за последние 90 дней}

Небольшое лирическое отступление. Многие сталкивались с ситуацией, когда в одно прекрасное утро ты видишь на графиках резкий рост количества логов, но не понимаешь, что именно стало причиной: новые команды не заезжали в сервис, новый функционал не планировался, и команды не предупреждали о том, что ожидается рост (потому что изначально команда закладывает вычислительные мощности под определенный объем данных). В результате расследования выясняется, что разработчики просто включили уровень логированияDebugилиTrace. Также, иногда, встречаются сложные системы, бизнес-логика которых требует сохранять максимально полную информацию, растущая, как снежный ком, с течением времени. Например,X5 использует в работе систему маркировки табачных изделий. В какой-то момент мы обнаружили, что размер одного сообщения с логами достигает порядка 600 кб, потому что вся информация о продукции и ее перемещении дополняется на всем пути до магазина.

Поэтому для нас также было важно обеспечить доступность сервиса и не позволить, чтобы поток логов перегрузил нашу систему до отказа в результате незапланированного роста количества данных.

На этапе проектирования сервиса сбора логов,командапоняла, чтонеобходимо гарантировать запись вElasticsearchвсех без исключения событий. Таким образом обеспечивается целостность данных, которые поступают от внешних систем, и команды всегда могут получить полную картину в том виде, в котором они пришли из внешних источников. Помимо этого, важно было иметь в виду, что количество команд будет расти со временем, а сервисы развиваться. Количество сообщений и информации в них будет увеличиваться, а для нас будет более затруднительно контролировать, какую информацию в логах пишут команды. Это значит, что мы должны сделать отказоустойчивую систему, которую можно сравнительно легко масштабировать в будущем.

Для достижения этих целей нам отлично подошло решениеApacheKafkaпо следующим причинам:

репликация и валидация записи.

Kafkaимеет механизм валидации записи acknowledgements. С помощью параметраacks можно настроить, сколько брокеров (реплик) должны отправить наproducerподтверждение записи. Конечно, использованиеacks, особенно в случае, если мы хотим быть уверены, что данные реплицировались на все брокеры, добавляет небольшую задержку, которая требуется на репликацию. Но для нас важнее быть уверенными, что данные, которые мы хотим передавать дальше, будут записаны вKafka;
хранение сообщений в очереди.Если потребитель (в нашем случае этоLogstash, который забирает сообщения изKafka) по какой-то причине не успевает обрабатывать сообщения или просто недоступен, эти данные будут прочитаны и доставлены в конечную систему сразу после стабилизации работы потребителей;
хранение сообщений после прочтения.

Kafkaне удаляет сообщения, а хранит в течение времени, которое описывается в параметрахretention. Это дает возможность восстановить данные в случае, если что-то случится с индексом вElasticsearchи данные станут недоступны;
партиционирование.

За счет увеличения числа партиций топика можно увеличить пропускную способностьKafka, добавив дополнительных потребителей. Это увеличивает количество потоков, которые могут читать данные параллель и полезно в случае, когдаproducerгенерирует большое количество сообщений.

Изначально кластер был развернут натрехмашинах, но после роста числа команд мы масштабировали кластер, добавив ещё две ноды.

#	vCPU	RAM	Storage^[2]	Kafka	Kafka Uptime	Zookeeper	ZK Uptime
1	4	16 ГБ	290 ГБ	+	1г1м	+	1г5м
2	4	16ГБ	270 ГБ	+	1г1м	+	1г5м
3	4	16ГБ	290 ГБ	+	1г1м	+	1г5м
4	4	16ГБ	270 ГБ	+	4м	-	-
5	4	16ГБ	270 ГБ	+	1г1м	-	-

[2] учитывается объем, отведенный под данныеKafka

Мы видим, что последние 2 ноды были добавлены в кластер чуть более года назад, как раз в это время и произошел перезапуск сервиса на нодах 1-3, а на 4-й ноде перезапуск происходил позднее, скорее всего, проводились какие-то работы.

Когда внутри одной системы хранятся данные нескольких команд важно обеспечить конфиденциальность данных и разграничить права доступа.

Управление доступами

Чтобы разграничить команды по топикам, мы используемKafkaSecurityManager (https://github.com/simplesteph/kafka-security-manager). Все правила доступа мы описываем в файле сACL. Выглядит это вот так:

User:projectprodwrite@srelogs,Topic,PREFIXED,projectprod,Create,Allow,User:projectprodread@srelogs,Topic,PREFIXED,projectprod,Read,Allow,User:projectprodread@srelogs,Group,PREFIXED,projectprod,All,Allow,

где:

UserCNсертификата, который используется для подключения,

srelogs имя кластера,

Topic/Group объект, которым управляет данная запись,

PREFIXED/LITERAL как будет применяться, относительно именем объекта вKafka(по префиксу или полное совпадение),

project_prod имя объекта и права, которые получает пользователь.

Producer/consumerавторизуются с помощьюSSLсертификатов, которые мы генерируем автоматически и храним вVault.

Интеграция в конвейер поставки логов

Подготовка всех необходимых компонентов выполняется с помощью ролейAnsible. В зависимости от окружения (продуктивное или непродуктивное), и прочих параметров, описанных в инвентаре, создается набор сущностей и конфигурируются нужные сервисы (индексы и тенанты вElasticsearch, пайплайны вLogstash)

После того, как все необходимые компоненты созданы и настроены, топики автоматически создаются, как только первые сообщения начинают отправляться вKafkaблагодаря параметруauto.create.topics.enable=True

Для обеспечения высокой производительности кластера, рекомендуется использоватьKafkaс сообщениями небольшого размера. По этой причине мы настоятельно рекомендуем командам следить за тем, чтобы в логи писалась только полезная информация, а дляElasticsearchпоставили ограничение на размер одного сообщения.

В целом, графики измеряющие поток входящих сообщений показывают нам стабильную и равномерную картину, однако, время от времени возникают неожиданные всплески (фиолетовые и желтые графики), которые создают команды разработки в топикахdevсред, предположительно, во время проведения тестов.

ИспользованиеKafkaв цепочке поставки логов позволяет нам контролировать поток входящих сообщений,Logstash(у каждой команды свой) будет равномерно вычитывать все, что попадает в топикKafka, а мы будем спокойны, что наш конвейер поставки логов не упадет от внезапно возросшей нагрузки. В случае, если нашconsumerстанет недоступен или не будет справляться с нагрузкой, все события так или иначе останутся в топике и будут прочитаны и отправлены вElasticsearchпосле восстановления работоспособностиLogstash.

Кластер для команды

Кроме большого кластера, который мы используем для гарантированной доставки логов, некоторые команды используют кластерыKafkaв своих проектах. При этом задачи, которые они решают с помощью этого продукта, схожи с нашими гарантированная запись данных, возможность обратиться к любым данным в течение времени их жизни в топике, отказоустойчивость и целостность.

У нас есть информационный ресурс, в котором описаны все сервисы, предоставляемые нашей командой, в том числе и параметры по умолчанию, которые устанавливаются для той или иной системы. Аналогичные дефолтные значения прописаны и для кластераKafka. Вот некоторые из них:

auto.create.topics.enable=Truedelete.topic.enable=Truelog.segment.bytes=1073741824log.retention.check.interval.ms=300000zookeeper.connection.timeout.ms=6000auto.leader.rebalance.enable=true

Нести в статью все, что описано в роляхAnsibleя не вижу смысла, но приведу некоторые примеры того, что используем мы вX5 .

Для обеспечения надежности кластера рекомендуется использовать количество реплик равное количеству нод и выставить значение минимально синхронизированных реплик на единицу меньше, чтобы в случае вылета одного узла, кластер смог продолжить работу. Для удобства мы используем именно эти значения, если иное не описано в инвентаре для проекта:

- name: 01|Set Kafka replication factor  set_fact:    kafka_cfg_default_replication_factor: "{{  kafka_cfg_default_replication_factor | default(kafka_hosts|length) }}"    kafka_cfg_offsets_topic_replication_factor: "{{ kafka_cfg_offsets_topic_replication_factor | default(kafka_hosts|length) }}"    kafka_cfg_transaction_state_log_replication_factor: "{{ kafka_cfg_transaction_state_log_replication_factor | default(kafka_hosts|length) }}"  run_once: True- name: 01|Set kafka ISR  set_fact:    kafka_cfg_min_insync_replicas: "{{ kafka_cfg_min_insync_replicas | default([kafka_cfg_default_replication_factor|int - 1 , 1] | max) }}"    kafka_cfg_transaction_state_log_min_isr: "{{ kafka_cfg_transaction_state_log_min_isr | default([kafka_cfg_transaction_state_log_replication_factor|int - 1 , 1] | max) }}"  run_once: True

По умолчанию мы выставляем удаление всех событий старше 30 дней, обычно этого хватает командам:

log.retention.hours=720

В случае, если команде требуются иные значения, то изменить какие-то параметры несложно. Нужно просто описать параметры и их значения в инвентаре нужного проекта:

Project.yml---project: name. . .kafka_scala_version: "2.11"kafka_zk_chroot: '/'kafka_enable_protocol: ['PLAINTEXT']kafka_cfg_default_replication_factor: 2kafka_cfg_log_retention_hours: 6kafka_cfg_log_segment_bytes: 52428800

Как и в случае с общим кластером, для обеспечения безопасности, мы используем SSL сертификаты. По умолчанию предоставляем кластер с параметромkafkaenableprotocol: ['SSL'], что гарантирует возможность подключения к кластеру только тех, кто имеет соответствующие клиентские сертификаты.

- name: Lookup for ssl data in Vault  set_fact:    jks_b64: "{{ lookup('hashi_vault', 'secret=sre/{{ env }}/{{ project }}/kafka/{{ inventory_hostname }}:kafka.keystore.jks.b64') }}"- name: Copy keystore data from Vault  copy:    dest: "/opt/kafka/ssl/{{ inventory_hostname }}/kafka.keystore.jks"    content: "{{ jks_b64 | b64decode }}"

Для удобства управления мы заворачиваемKafkaиZookeeperв сервисы, поскольку не используем контейнеры. Пример шаблона сервисаKafka, которыйAnsibleприносит на виртуальную машину:

[Unit]Description=Kafka DaemonAfter=zookeeper.service[Service]Type=simpleUser={{ kafka_user }}Group={{ kafka_group }}LimitNOFILE={{ kafka_nofiles_limit }}Restart=on-failureEnvironmentFile=/etc/default/kafkaExecStart={{ kafka_bin_path }}/kafka-server-start.sh {{ kafka_config_path }}/server.propertiesExecStop={{ kafka_bin_path }}/kafka-server-stop.shWorkingDirectory={{ kafka_bin_path }}[Install]WantedBy=multi-user.target

Плюсытакогоразделения:

разграничение ресурсов.

Каждая команда знает, сколько ресурсов выделено конкретно под их продукт, и не переживает о том, что проект-сосед может занять большой объем оперативной памяти, тем самым повлиять на производительность их системы. Помимо этого, мы можем предоставлять командам разработки дополнительные инструменты и не думать о том, что какие-то из их действий могут навредить кому-то еще кроме них самих;
гибкость управления.

В случае, если необходимо изменить какие-то параметры и перезапустить Kafka, не требуется согласовывать работы с большим количеством команд.

Пример нагрузки на одном из кластеров, который использует система маркировки:

Видно, что нагрузка на систему держится примерно на одном уровне на протяжении любого периода времени (в примере это неделя).

Из минусов можно выделить то, чтоKafkaможет быть избыточна для команд, которым нужен простой брокер сообщений.

Дополнительные инструменты для работы с Kafka

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

Таким набором по умолчанию у нас являются экспортеры для сбора метрик и панели графиковGrafanaдля визуализации этих метрик:

jmx-exporter позволяет отслеживать состояниеJavaVirtualMachine,

kafka-exporter,zookeeper-exporter для того чтобы понимать, как себя чувствуют наши сервисы и получать поверхностную картину,

telegraf дает информацию о состоянии ноды, на которой крутитсяKafka.

Большинству команд этого хватает. Для тех, кому нужно чуть больше информативности, мы предлагаемkafka-minionexporter(https://github.com/cloudworkz/kafka-minion), который позволяет получать больше информации о том, что происходит с топиками, например, сколько групп потребителей подключены к топику и т.п.

Поскольку у команд нет прямого доступа на сервер сKafka, им нужно дать возможность просматривать содержимое и, например, быстро удалять топики, не дергая для этого каждый раз нас. Для решения этих задач мы предлагаем использоватьKafdrop (https://github.com/obsidiandynamics/kafdrop). Для оперативного предоставленияKafdrop, мы используем готовыйCIpipeline, который поднимает в окруженииOpenShiftдва пода:Kafdropиnginx. В результате мы получаемwebUIсbasicаутентификацией, настроенной средствамиnginx.

Помимо этого, точечно по запросам команд мы можем подготовить различные коннекторы, например, коннекторы для баз данных (PostgreSQLConnector,MongoDBKafkaConnector),ksqlDBилиKafkaC22CC23CC24Cдля взаимодействия с кластером черезRESTAPI.C25C

Заключение

Как видно из нашего рассказа,Kafkaотлично зарекомендовала себя в качестве вспомогательного сервиса в цепочке поставки логов, в том числе за счет удобства масштабирования и возможности вернуться к сообщениям, которые уже были прочитаны. Для применения в разработке продуктовKafkaимеет всевозможные коннекторы, которые облегчают интеграцию с другими компонентами продукта. Кроме этого, существует большое количество инструментов, облегчающих жизнь инженеров и разработчиков, работающих с кластером.

Тем не менее, для команд не всегда этот инструмент подходит из-за возможной избыточности функционала и объема необходимых вычислительных ресурсов, что в свою очередь увеличивает затраты на бюджет проекта. Именно поэтому сейчас мы начинаем в пилотном режиме предоставлять командамRabbitMQ, но это уже совсем другаяистория.

Подробнее..

Категории: It-инфраструктура , Devops , Архитектура , Инфраструктура , Apache , Личный опыт , Блог компании x5 retail group , Apache kafka , Продукт , Apache flex , Retail , Хабра-папа

Перевод Как машинное обучение позволило Dropbox экономить ежегодно 1,7 миллиона долларов

29.01.2021 12:17:38 |

Автор: admin

Недавно благодаря предсказательной мощи машинного обучения (machine learning, ML) мы обеспечили экономию 1,7 миллионов долларов в год на инфраструктурных тратах, оптимизировав процесс генерации и кэширования превью документов Dropbox. Машинное обучение и раньше применялось в Dropbox для таких хорошо известных функций, как поиск, рекомендации файлов и папок, а также OCR при сканировании документов. Хоть и не все сферы применения ML непосредственно видны пользователю, они всё равно изнутри влияют на развитие бизнеса.

Что такое превью?

Функция Dropbox Previews позволяет пользователям просматривать файл без скачивания контента. В дополнение к превью-миниатюрам Dropbox имеет интерактивную поверхность Previews с возможностью обмена между пользователями и совместной работы, в том числе использования комментарии и тегирования других пользователей.

Наша внутренняя система надёжной генерации превью файлов под названием Riviera занимается генерацией превью для сотен поддерживаемых типов файлов. Этот процесс реализуется созданием цепочки различных преобразований контента, обеспечивающей генерацию ресурсов превью, соответствующих типу файла. Например, Riviera может растеризировать страницу из многостраничного PDF-документа для демонстрации в веб-поверхности Dropbox превью высокого разрешения. Функция превью всего контента поддерживает такие интерактивные возможности, как комментирование и передача другим пользователям. Крупные графические ресурсы в дальнейшем могут преобразовываться в миниатюры изображений, которые демонстрируются пользователю в различных контекстах, в том числе в результатах поиска или в браузере файлов.

В масштабах Dropbox система Riviera обрабатывает ежедневно десятки петабайтов данных. Для ускорения процесса создания превью определённых классов крупных файлов Riviera заранее генерирует и кэширует ресурсы превью (этот процесс мы называем предварительным прогревом). Учитывая объём поддерживаемых нами файлов, затраты на процессорные мощности и накопители, связанные с прогревом, оказываются довольно значительными.

Превью-миниатюры при просмотре файлов. Превью можно увеличивать и с ними можно взаимодействовать как с заменой файла приложения.

Мы увидели перспективу снижения этих затрат при помощи машинного обучения, поскольку часть этого заранее генерируемого контента пользователи никогда не просматривали. Если мы сможем эффективно предсказывать, будет ли использоваться превью, то сэкономим на вычислениях и хранении файлов, проводя предварительный прогрев только тех файлов, которые точно будут просмотрены. Мы назвали этот проект Cannes (Канны) в честь знаменитого города на Французской Ривьере, где проводятся предварительные показы фильмов со всего мира.

Баланс в машинном обучении

Существует два аспекта, поиск равновесия в которых повлиял на наши принципы оптимизации превью.

Первая задача заключалась в поиске компромисса между затратами и преимуществами экономии на инфраструктуре при помощи ML. Если выполнять предварительный прогрев меньшего количества файлов, то мы сэкономим деньги (а кому это не понравится!), но если отклонить файл ошибочно, то это навредит пользователю. Когда происходит промах кэша, системе Riviera нужно генерировать превью на лету, пока пользователь ждёт отображения результата. Совместно с командой разработчиков Previews мы задали предел снижения удобства для пользователей и использовали этот предел для настройки модели, которая обеспечит приемлемый уровень экономии.

Ещё одним компромиссом был поиск баланса: сложность и производительность модели против интерпретируемости и стоимости введения в эксплуатацию. В целом, в ML существует баланс сложности и интерпретируемости: более сложные модели обычно имеют более точные предсказания, но ценой этого становится снижение интерпретируемости того, почему были сделаны конкретные прогнозы; кроме того, при этом может повыситься сложность ввода в эксплуатацию. В первой версии системы мы решили как можно быстрее создать интерпретируемое ML-решение.

Так как Cannes стало новым ML-приложением, встроенным в существующую систему, выбор в пользу более простой и интерпретируемой модели позволил нам сосредоточиться на реализации работы модели, метрик и отчётности, после чего можно было повышать сложность. Если бы что-то пошло не так или мы обнаружили бы неожиданное поведение в Riviera, то команде ML-разработки было бы проще выполнить отладку и понять, вызваны ли проблемы Cannes, или чем-то ещё. Решение должно быть относительно простым и дешёвым для ввода в эксплуатацию и обслуживания примерно полумиллиарда запросов в день. Уже существующая система просто выполняла предварительный прогрев всех файлов с возможностью превью, поэтому любые усовершенствования привели бы к экономии, и чем скорее, тем лучше!

Cannes v1

Учтя описанные выше компромиссы, мы намеревались создать для Cannes простую, быструю в обучении и понятную людям модель. Модель v1 была классификатором посредством градиентного бустинга, обученным на таких входных данных, как расширение файла, тип аккаунта Dropbox, в котором хранится файл и последние 30 активности в этом аккаунте. В тесте, проведённом вне работающей системы, мы выяснили, что эта модель может предсказывать превью спустя даже 60 дней после предварительного прогрева с точностью >70%. В контрольной системе модель отклоняла примерно 40% запросов предварительного прогрева, а её производительность находилась в пределах интервала защитного механизма, который мы задали в самом начале. Возникало небольшое количество ложно-отрицательных результатов (файлов, которые по нашим прогнозам не должны были просматриваться, однако просматривались в течение последующих 60 дней), из-за которых возникали дополнительные затраты на генерацию ресурсов превью на лету. Мы использовали метрику процент отклонённых минус ложно-отрицательные результаты, получив общую сумму ежегодной экономии в 1,7 миллиона долларов.

Ещё до того, как мы начали исследовать пространство оптимизаций Previews, нам нужно было гарантировать, что потенциальная экономия перевесит стоимость создания решения на основе ML. Нам пришлось выполнить примерную оценку прогнозируемой экономии, которой мы хотели достичь при помощи Cannes. При проектировании и вводе в эксплуатацию ML-систем в крупных распределённых системах нужно смириться с тем, что внесение некоторых изменений в систему постепенно будет влиять на оценки. Из-за того, что первоначальная модель оставалась простой, мы надеялись, что порядок величин влияния на экономию будет стоящим вложенных усилий, даже если со временем придётся вносить незначительные изменения в соседние системы. Анализ обученной модели дал нам более обширное представление о тому, что мы сэкономим в v1, и подтвердил обоснованность вложений в разработку.

Мы провели A/B-тестирование модели на случайной 1-процентной выборке трафика Dropbox при помощи нашей внутренней службы управления доступностью функций Stormcrow. Мы убедились, что точность модели и количество сэкономленных прогревов соответствовали результатами отдельного анализа, и это было просто отлично! Так как Cannes v1 больше не выполняла предварительный прогрев всех возможных файлов, мы ожидали, что частота попаданий в кэш упадёт; во время эксперимента мы наблюдали, что частота попаданий в кэш стала на пару процентных пунктов меньше, чем у контрольной выборки из A/B-теста. Несмотря на это падение, общая задержка отображения превью осталась практически неизменной.

Нас особенно интересовала хвостовая задержка (задержка для запросов выше 90-го перцентиля), потому что промахи кэша, вносившие свой вклад в повышение хвостовой задержки, должны были серьёзнее повлиять на пользователей функции Previews. Нас вдохновило то, что мы не наблюдали ухудшения ни хвостовой задержки превью, ни общей задержки. Тест на работающей системе обеспечил нам уверенность в том, что можно начинать ввод в эксплуатации модели v1 на больший объём трафика Dropbox.

Прогнозирование в реальном времени на больших масштабах

Нам нужно было каким-то образом передавать прогнозы реального времени системе Riviera, чтобы она знала, необходимо ли выполнять прогрев файла при движении файлов по пути предварительного прогрева. Для решения этой проблемы мы превратили Cannes в конвейер прогнозов, получающий относящиеся к файлу сигналы и передающий их в модель, которая прогнозирует вероятность использования будущих превью.

Архитектура Cannes

Получаем от пути предварительного прогрева Riviera идентификатор файла. Riviera собирает идентификаторы всех файлов, для которых возможен предварительный прогрев. (Riviera может выполнять превью примерно 98% файлов, хранящихся в Dropbox. Существует небольшое количество файлов, которые относятся к неподдерживаемым типам или не могут создать превью по какой-то другой причине.) Riviera отправляет запрос на прогноз с идентификатором файла и его типом.
Получение сигналов реального времени. Для сбора самых последних сигналов для файла в момент предсказания мы использовали внутренний сервис под названием Suggest Backend. Этот сервис валидирует запрос на предсказание, а затем запрашивает соответствующие сигналы, относящиеся к этому файлу. Сигналы хранятся или в Edgestore (основной системе хранения метаданных Dropbox), или в User Profile Service (массиве данных RocksDB, выполняющем агрегацию сигналов активности Dropbox).
Кодируем сигналы в вектор признаков. Собранные сигналы передаются в Predict Service, кодирующий сырые сигналы в вектор признаков, который содержит всю важную информацию файла, а затем отправляет этот вектор модели для оценки.
Генерируем прогноз. Модель использует вектор признаков для возврата прогнозируемой вероятности того, что превью файла будет использоваться. Это прогноз затем отправляется обратно Riviera, которая прогревает файлы, у которых есть вероятность просмотра превью в течение 60 дней в будущем.
Журналируем информацию о запросе. Suggest Backend журналирует вектор признаков, результаты прогноза и статистику запроса всю критически важную информацию для контроля снижения производительности и проблем с задержками.

Дополнительный фактор

Снижение задержки прогнозирования важно, потому что описанный выше конвейер находится на критичном пути для функции предварительного прогрева Riviera. Например, при использовании системы для работы с 25% трафика мы наблюдали пограничные случаи, опускавшие уровень доступность Suggest Backend ниже наших внутренних SLA. Дальнейшее профилирование показало, что в этих случаях происходил таймаут на этапе 3. Мы усовершенствовали этап кодирования признаков и добавили в путь прогнозирования еще несколько других оптимизаций, снижающих хвостовую задержку для таких пограничных случаев.

Оптимизируем ML

Во время и после процесса ввода в эксплуатацию нашим приоритетом была устойчивость и гарантии того, что система не повлияет негативно на пользователей на поверхности Previews. Критически важными компонентами процесса ввода в эксплуатацию ML являются тщательный мониторинг и многоуровневая система предупреждений.

Метрики Cannes v1

Инфраструктурные метрики: у систем общего пользования есть собственные SLA, касающиеся аптайма и доступности. Для мониторинга и отправки предупреждений в реальном времени мы используем готовые инструменты наподобие Grafana. Есть следующие метрики:

Доступность Suggest Backend и Predict Service
Актуальность данных User Profile Service (или массива данных действий)

Метрики превью: мы выделили ключевые метрики производительности превью,
а именно распределение задержек превью. Мы оставили контрольные 3% для сравнения метрик превью с Cannes и без неё, защищаясь от дрейфа модели или непредусмотренных изменений систем, способных снизить производительность модели. Кроме того, Grafana является популярным решением и для контроля метрик на уровне приложений. Применяются следующие метрики:

Распределение задержек превью (сравнение Cannes и контрольной группы без Cannes); особое внимание уделяется задержкам выше p90
Частота попадания в кэш (сравнение Cannes и контрольной группы без Cannes): общее количество попаданий в кэш/общее количество запросов на превью контента

Метрики производительности модели: у нас есть метрики модели для Cannes v1, которые использует команда ML-разработчиков. Мы создали собственный конвейер для вычисления этих метрик. Нас интересуют следующие метрики:

Матрица неточностей; особое внимание уделяется изменениям в частоте ложно-отрицательных результатов
Площадь под кривой ошибок: одновременно с непосредственным контролем статистики матрицы неточностей вычисляется AUROC с целью сравнения производительности с будущими моделями.

Представленные выше метрики производительности вычисляются ежечасно и сохраняются в Hive. Мы используем Superset для визуализации важных метрик и создания дэшборда изменения производительности Cannes по времени. Предупреждения Superset, создаваемые на основе таблиц метрик, позволяют нам узнать об изменении поведения лежащей в основе системы модели ещё до того, как оно повлияет на пользователей.

Однако самих по себе мониторинга и предупреждений недостаточно для обеспечения здоровья системы; необходимо создание чёткой иерархии владения и процессов передачи на более высокие уровни. Например, мы задокументировали выше по потоку определённые зависимости ML-систем, способные повлиять на результаты модели. Также мы создали перечень задач для дежурных инженеров с подробными пошаговыми инструкциями, позволяющими определить, возникла ли проблема внутри Cannes или в другой части системы, а также путь передачи на более высокие уровни, если причиной являлась модель ML.

Современное состояние и дальнейшие исследования

Cannes теперь используется почти для всего трафика Dropbox. В результате этого мы заменили приблизительно 1,7 миллиона долларов ежегодных затрат на предварительный прогрев 9 тысячами в год на инфраструктуру ML (в основном эти траты вызваны повышением объёма трафика к Suggest Backend и Predict Service).

В следующей версии проекта можно исследовать множество захватывающих областей. Теперь, когда остальная часть системы Cannes выведена в продакшен, мы можем поэкспериментировать с более сложными типами моделей. Также можно разработать более точную функцию затрат для модели на основании более подробных данных об издержках и масштабах использования. Ещё один способ применения Previews, который мы обсуждали использование ML для более подробных предсказательных решений для каждого файла, чем просто прогрев нужен/не нужен. Возможно, нам удастся обнаружить потенциал дальнейшей экономии благодаря более творческому использованию предсказательного прогрева.

Мы надеемся обобщить выводы и инструменты, созданные для Cannes, на другие инфраструктурные проекты Dropbox. Применение машинного обучения в оптимизации инфраструктуры интересная область для вложения сил и средств.

На правах рекламы

Закажите и сразу работайте! Создание VDS любой конфигурации в течение минуты, в том числе серверов для хранения большого объёма данных до 4000 ГБ. Эпичненько :)

Подробнее..

Категории: It-инфраструктура , Искусственный интеллект , Машинное обучение , Финансы в it , Инфраструктура , Блог компании vdsina.ru — хостинг серверов , Обработка данных , Dropbox , Искуственный интеллект , Обработка текста

Что такое системы API Management

19.02.2021 18:05:42 |

Автор: admin

Зачем они нужны и какие функции они выполняют.

Всем привет! Меня зовут Антон, я инженер команды, отвечающей за развитие централизованныхIT-сервисов, которыми пользуются продуктовые команды вX5RetailGroup.

В этой статье я расскажу осистемах класса API Management и в частности о APIM Gravitee (https://www.gravitee.io), том, что это за класс систем, как они используются для обеспечения потребностей команд разработки. Статья не погружает в технические аспекты, но может быть полезна архитекторам и менеджерам, которые думают о том, чтобы попробовать использоватьданный класс систем, но не знают, подойдут ли они для их задач, а также разработчикам, которые могут открыть для себя новые инструменты для удобной работы с API.

Что такое системы API Management

Определение

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

С другой стороны, API Management - это набор инструментов и сервисов, которые позволяют разработчикам и компаниям создавать, анализировать, применять и масштабировать интерфейсы API в безопасных средах.

В данных вариантах определения понятия "API Management" мы видим, что это процессы и системы позволяющие публиковать внутренние API сервисов, прописывать им определенные политики обработки запросов и ответов, контролировать доступ и анализировать статистику использования и производительности. Также рядом могут располагаться несколько подсистем, которые организуют выполнение необязательных функций, но интересных с точки зрения других подразделений, например монетизация API.

Зачем еще один огород городить?

Необходимость этого класса систем возникла в связи с увеличением количества сервисов, которые могут предоставлять свое API как конечный продукт для других сервисов. Ничего не напоминает? Правильно - микросервисная архитектура. Для организации это возможность ускорения "цифровизации". Владельцы продукта публикуют API, документацию к ней и прочие документы типа: планов развития, лимиты и т.д. Также всем хочется контролировать качество работы API, а это уже анализ производительности, статистика использования, проведение все возможных маркетинговых исследований и простой мониторинг. Для коллег из информационной безопасности будет интересно осуществлять наблюдение за использованием API в части контроля доступа: авторизация, аутентификация, аудит, проверка по черным/белым спискам IP. Для аналитиков и тестировщиков возможно будет интересна функциональность проверки корректности запросов, проверка корректности JSON или динамическое изменение запросов, для DevOps инженеров возможность установки rate limit, чтобы не было DoS конечного сервиса, настройка кэша и возможность оптимизации сервиса под микросервисную архитектуру: Service Discovery, Load Balancing, Blue/Green или Canary deploy.

Архитектура сервиса

В архитектуру сервиса API Management обычно входят (см. рис. 1):

Management Core: ядро системы, которое отвечает за формирование политик, планов, работу точками входа и выхода, настроек API Gateways и API, настройку CORS, Failover, Healthcheck, формирование запросов на отображение статистики использования API и логов.

Web/Development Portal: отвечает за UI, отображение настроек, статистики использования API, healthcheck и логов, а также позволяет общаться разработчикам, администраторам и владельцам API.

API Gateways: шлюзы или прокси, они отвечают за обработку запросов от клиентов сервиса согласно установленных настроек и политик, ведение логов запросов и ответов, а также запуск healthcheck по Backend API.

Backend API: отвечает за обработку запросов согласно бизнес-логике конечного сервиса.

Databases: в части сервиса API Management, хранят данные по настройке API, API Gateways, логи запросов клиентов и ответы backend, healthcheck, данные мониторинга практически всех компонентов API Management.

рис. 1 Архитектура сервиса API Management

Плюсы и минусы систем API Management

У данных систем есть несколько преимуществ:

Абстракция: система упрощает сложность сервисов под ним и предоставляет клиентам единый опыт.

Аутентификация:система позволяет пройти аутентификацию, в том числе и через сторонние службы, например Keycloak.

Управление трафиком: система регулирует входящий и исходящий трафик API.

Мониторинг API: система может помочь в мониторинге запросов/ответов клиента.

Преобразования: система позволяет преобразовать запросы/ответы API.

К минусам можно отнести:

Увеличение Latency: шлюзу необходимо время для обработки запросов/ответов согласно настроенным политикам.

TCO: Совокупная стоимость владения для всей цепочки поставки ценности, естественно будет больше, чем просто установить nginx и выставить его наружу.

APIGateways

API Gateways работают как единая точка входа в ЦОД (центр обработки данных), группу распределенных служб или сервисов (см. рис. 2). Также API Gateways могут использоваться для связи между двумя продуктами/сервисами, развернутыми в одном ЦОД. API Gateways принимают вызовы от клиентов, обрабатывают их согласно политикам/правилам и направляют их в соответствующие сервисы. Чтобы API Gateways могли максимально быстро обрабатывать запросы от клиентов их делают максимально легковесными, с использованием асинхронных фреймворков. API Gateways, как правило, работают только на седьмом уровне (L7) модели OSI.

рис. 2

ТипыAPI Gateways

С точки зрения расположения есть два места установки API Gateways:

Local API Gatewaysработают как шлюз для сервисов внутри организации.

DMZ API Gatewaysработают как шлюз для внешних потребителей и клиентов сервисов.

Для одного сервиса возможно использование обоих типов шлюзов, когда сервисом пользуются как внутренние потребители, так и внешние клиенты. В остальных случаях использование обоих типов шлюзов зачастую не целесообразно. Это связанно с основным минусом шлюзов - добавлением задержек при обработке запросов и ответов.

Наиболее распространенные системы

Name	Tags
APIGee	Enterprise
WSO2 API Manager	Enterprise/Open source
SAP API	Enterprise
3scale	Enterprise
IBM API Management	Enterprise
Kong	Enterprise/Open source
Mashery	Enterprise
Microsoft Azure API Management	Enterprise
Mule Soft	Enterprise

Централизованный сервис Gravitee

В X5 Retail Group в свое время выбрали для использования систему APIM Gravitee (https://www.gravitee.io). Основной сценарий использования нашими командами публикация API в локальной сети и в DMZ.

Немного цифр об этом сервисе на текущий момент:

23 продуктивных команд зарегистрировано

69 API Gateways для обслуживания запросов

400 Гб логов за сутки

350 RPS в среднем по больнице за сутки

30 000 000+ запросов обрабатывается за сутки

Функциональность

Рассмотрим базовую функциональность, предоставленную системой APIM Gravitee.

Identity provider: Аутентификация внешних пользователей можешь осуществляться на основе следующих систем и сервисов:

MongoDB (по умолчанию для новых пользователей, которые приглашаются);
In-memory (по умолчанию для пользователя admin);
LDAP / Active Directory;
OpenID Connect IdP (Azure AD, Google);

Fetchers: стянуть настройки для новой версии API и документацию можно через:

File (Swagger, OpenAPI);
HTTP;
GIT;

Policies: политики предназначены для изменения поведения, обрабатываемых шлюзом запросов и ответов. Каждый запрос и ответ обрабатывается согласно настроенной цепочке политик. Политики можно рассматривать как прокси-контроллер, гарантирующий выполнение данного бизнес-правила во время обработки. Примеры политик:

API Key - политика авторизации с использованием API-ключа;
Rate-limiting - политика ограничения скорости или квот для предотвращения флудинга backend;
Transform Headers/Transform Query Parameters - политика преобразований параметров заголовка или запроса;
etc.

Политик обработки запросов в Gravitee Gateway более 30 штук и с каждой версией их число увеличивается. Так же можно сделать свои политики. Но стоит учитывать, что чем больше политик "навешано", тем медленнее будет обрабатываться запрос и тем больше ресурсов будет использовано.

Reporters: сборщики логов используются экземпляром шлюза для сообщения о событиях. Типы сборщиков логов:

Reporter file;
Elasticsearch;
Accesslog;

Типы событий, которые можно собрать:

Метрики запроса/ответа например, время ответа, длина содержимого, api-ключ;
Мониторинг метрик например, процессора, использования кучи, кол-во открытых файлов и т.д.;
Показатели проверки работоспособности например, состояние, код ответа;

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

MongoDB (по умолчанию);
Redis;
Elasticsearch;
PostgreSQL (коннектор через JDBC и надо использовать другой дистрибутив);

Resources: ресурсы, которые можно использовать при работе:

OAuth2 (подключение к OAuth2 как источнику данных для аутентификации);
Cache (создание локального кэша на шлюзе);
LDAP (подключение к LDAP как источнику данных для аутентификации);

Services: сервисы, которые может предоставлять сам шлюз:

Sync (Синхронизация состояния шлюза с конфигурацией из репозитория управления);
local-registry (Локальный реестр используется для загрузки API в формате json из файловой системы. Таким образом, вам не нужно настраивать свой API с помощью веб-консоли или rest API (но вам нужно знать и понимать формат json API, чтобы он работал.));
health-check (Сервис для проверки состояния других сервисов);
monitor (Сервис извлекает метрики, такие как метрики os / process / jvm, и отправляет их в базовую службу отчетов);

Notifiers: сервис нотификаций используется для отправки уведомлений. В настоящее время единственным доступным каналом является электронная почта, но в ближайшее время запланированы другие, включая Slack.

Email;

Alerts: оповещение используется для отправки триггеров или событий в механизм оповещений, которые могут быть обработаны для отправки уведомления с помощью настроенного плагина Notifier.

Vertx;

А так как система с открытыми исходниками:https://github.com/gravitee-io, то при знании Java, можно написать свои собственные плагины и использовать как вздумается.

Настройки API

Настройка нового API проходит несколько этапов:

Создание API

Настройка планов

Привязываем API к шлюзам

Создание API

На странице создания API можно выбрать, как и из чего создать скелет нового API

Вариантов немного, но выбор есть:

Вручную накликал и можно работать!

Импортировать из swagger файла.

Импортировать из Gitа/URLа.

Рассмотрим ручной вариант настройки, выбираем "->"

Ручное создание API проходит 5 шагов

На первом шаге указываем имя API, версию, описание и уникальный путь, по которому это API будет доступно.

Второй шаг может быть в двух модификациях:

В Simple mode указываем только адрес нашего backend api, например:https://msk-dpro-sre000.x5.ru:8443/testbackend/

В Advanced mode необходимо указатьадрес нашего backend api, используемые tenant и sharding tags.

tenant- область выделенная в Elasticsearch для логов запросов и событий.

sharding tags- теги, согласно которым связываются API и Gateways

На третьем шаге можно указать Plan

Plan - это указание ограничений, которые будут влиять на обработку запросов, проходящих через данный Gateway.

Name -имяплана

Security type -типплана: Keyless(public), API Key, JWT, OAuth2

Description - просто описание плана и его особенностей

Rate limit - ограничение кол-ва запросов в секунду/минуту

Quota -ограничение кол-ва запросов в час/день/неделя/месяц

Path authorization - черный и белый список путей и методов к ним

Данный пункт можно пропустить и заполнить уже в созданном API.

На четвертом шаге можно загрузить файл документации по API

Поддерживается формат swagger.json

Данный пункт можно пропустить и заполнить уже в созданном API.

На пятом шаге мы проверяем все что заполнили

И выбираем либо "Создать API без установки на шлюз", либо "Создать и запустить API"

Нажимаем CREATE и получаем частично настроенный API для работы.

Настройки планов

План предоставляет собой уровень обслуживания и доступа между API и приложениями. У одного API может быть несколько планов, но только один без ключевой - "keyless". План определяет ограничения доступа, режимы проверки подписи и другие настройки для адаптации к конкретному приложению.

Основные настройки:

Планы привязываются к конкретному шлюзу или группе шлюзов через Tags (см. рис. 3)

Рис. 3

2. В плане указывается какой тип Аутентификации будет использован (см. рис. 4)

Рис. 4

3. Можно сразу указать Rate и Quota лимиты и определить список разрешенных путей для запроса (см. рис. 5)

Рис. 5

4. В последней вкладке можно указать политики, которые будут отрабатывать на начальном этапе обработки запросов (см. рис. 6)

Рис. 6

Заключение

Итак, теперь вы знаете, что такое системы Management API, зачем они нужны и какой функциональностью обладают. Надеюсь, у вас сложилось понимание, какое место в архитектуре ИТ занимает данный класс систем и как их использовать с наибольшей отдачей.В следующей частия буду рассказывать и показывать, как поставить и настроить одну из систем класса Management API с нуля для тестового прогона.

Подробнее..

Категории: It-инфраструктура , Development , Тестирование it-систем , Тестирование , Devops , Api , Архитектура , Инфраструктура , Продуктивность , Менеджмент , Блог компании x5 retail group , Продукты

Психбольница в руках пациентов, или Инфраструктура как продукт

08.04.2021 16:21:10 |

Автор: admin

У бизнес-разработчиков за дедлайнами, сроками, клиентами и большими запусками может складываться впечатление, что инфраструктура выстраивает свой воздушный замок, который далек от того, что происходит в действительности. Захотев это изменить, Алексей Данилов из разработки перешел в команду инфраструктуры последние два года он развивает ее в Яндекс.Вертикали а это Яндекс.Работа, Яндекс.Недвижимость, auto.ru и Яндекс.Объявления.

Особенность Яндекс.Вертикалей ребята одновременно и бизнес-юнит Яндекса, и обычная IT-компания. Благодаря первому, у них есть возможность использовать яндексовую инфраструктуру, но, благодаря второму, разработчики смотрят на весь стек и используют то, что им удобно. Алексей сегодня поделится с нами, как это можно сделать более удобно и ближе к пользователям (в его случае к разработчикам). А также о том, почему на инфраструктуру сейчас надо смотреть как на продукт и какие вызовы это приносит команде, но что это дает в конечном итоге компании.

Infrastructure

Под инфраструктурой я подразумеваю всё, что окружает бизнесовый код и помогает ему от начала разработки фичи до момента ее доставки. Это и базы данных, и балансировка, и мониторинг, и CI с CD. Сюда же относятся особенности разработки/работы, библиотеки, тестирование, бизнес аналитика, бизнес-специфичные возможности и много чего еще. Это как завод, на котором вместо ручного труда автоматизированы все процессы, и результат мы получаем более быстрый и более качественный.:

При этом я рассматриваю инфраструктуру как единую платформу, а не набор разрозненных частей, которые я перечислил выше. И это уместно для компании любого размера. В облаках Amazon Web Services, Yandex Cloud автоматизация может строиться, например, на основе terraform. У вас может быть собственное железо или вы его где-то арендуете и на нем может быть развернут Kubernetes, Nomad, что-то еще. Команда тоже может быть любой от нескольких человек, которые в основном используют bash или terraform, и до сотен, со своими велосипедами.

И тогда возникает вопрос как добиться идеальной инфраструктуры Platform as a Service, который мы реализуем для наших пользователей, и вообще каковы критерии идеальности? Нам не нужно разрабатывать еще один Amazon или Kubernetes поэтому достаточно небольшой и простой системы, но у нас должна быть возможность ее расширения под наши use cases. Например, если у нас есть какие-то особенные АБ-тесты, особенные условия доставки (например, канареечный релиз ) и особенные правила безопасности это как раз то, что должна закрывать инфраструктура.

Ее основой, краеугольным камнем будут минимизация/ускорение разработки, упрощение поддержки и простота использования. Остальные требования понятность, доступность, стабильность и единообразность/распространение практик, а также скрытие низкоуровневых особенностей (чтобы никому не пришлось писать самому конфиг nginx или сложный Kubernetes манифест), техническая поддержка 24*7 и связанность компонентов конечно, тоже имеют место.

Если выполнить их все, ваша инфраструктура будет не только единой платформой или сервисом, но постепенно будет превращаться в продукт, как это случилось у нас.

Infrastructure/Platform as a product (PaaP)

Сначала мы, конечно, смотрели в сторону сторонних приложений. Например, мы серьезно рассматривали Spinnaker от Netflix. Но он написан на Java, а у нас все пишут на Go, и мы не хотели добавлять еще один язык. Во-вторых, он не поддерживает Nomad и Yandex.Cloud. Следовательно, нам пришлось бы его прилично дорабатывать и интегрировать с нашими внутренними особенностями, что практически равно форку. Поэтому мы стали писать свое.

Изначально мы задумывали Shiva как абстракцию над деплоем (в нашем случае над Nomad) и как multicloud. Но сейчас она уже приросла различными системами и интегрируется со всем, что у нас внутри есть:

Основная ее часть представлена в GitHub в виде карты сервисов. Она изменяется посредством пул-реквестов, конфигурирует балансировку, контролирует деплой и различные пайплайны доставки, SOX, PCI DSS и т.д. То есть это одно описание для полноценной работы:

Архитектура Shiva в упрощенном виде выглядит так:

Сервис постоянно развивается и сейчас он уже частично похож на продуктовый: есть БД, вокруг которой построены различные микро-сервисы, есть небольшие legacy-компоненты (компонент Updater и Shiva смотрят в одну базу) и т.д. То есть с технической точки зрения он развивается как обычный бизнесовый сервис.

UI мы реализовали в Telegram, а впоследствии написали WEBовский. Telegram-бот это CLI over Telegram все команды задаются в формате CLI, но дополнены различными контекстными действиями, кнопками и т.д. Нам нравится этот подход, потому что он кросс-платформенный, его легко обновлять и к нему всегда есть доступ. Можно спокойно обновить или откатить свой сервис в случае проблем. А также очень удобный механизм нотификации, когда вы получаете уведомление о начале процесса деплоя прямо в тележку.

И хоть WEB и получился удобным, все равно часть пользователей остается в Telegram. Потому что UX меняется в профессию приходит очень много молодых разработчиков. Мы привыкли к WEB, мы привыкли использовать Telegram-боты и вообще общаться в чате. С другой стороны, мы хоть и думаем сделать CLI с такой же функциональностью, но понимаем, что запросов на это не было.

Экономика

Когда встал вопрос об экономике, то первое, о чем мы подумали модная сейчас юнит-экономика: ее используют при создании стартапа, чтобы понять, насколько он экономически выгоден. К тому же это очень удобный фреймворк:

Но у инфраструктуры нет доходов, тогда как на этой схеме есть и доходы, и расходы. Доход от инфраструктуры равен 0 это расход компании, а ROI будет отрицательным: сколько инвестиций не вкладывай, они не отбиваются:

Profit = Revenue - Cost = 0 - X

Есть, конечно, плюшки в виде, например, бесконечного LTV (LifeTime Value) то есть наши клиенты от нас никогда не уйдут. Но в целом эта метрика нам не подходила, и мы стали думать в сторону velocity (скорость разработки), потому что ее довольно легко преобразовать в деньги. Например, если мы ускорили разработку на час в неделю, то это нетрудно соотнести со средней зарплатой у 500 разработчиков и получить какой-то видимый профит. Вообще инфраструктура это именно velocity, то есть скорость доставки ценности пользователю. Но у нас это не глобальная метрика, потому что velocity зависит от очень многих факторов. : Если смотреть сверху, то можно выделить:

code время написания самой логики ;
infrastructure code время написания инфраструктурного кода (код логов, метрик, алертов и т.д.)
environments время на настройку переменных окружения, секретов и т.д.;
delivery время, затраченное на доставку.

На последние три пункта инфраструктура влияет напрямую и может существенно упростить или ускорить их. Для примера рассмотрим механизм проверки новой конфигурации для сервиса. Сначала наша карта сервисов проверялась небольшим скриптом, и далее ее уже должен быть допроверить человек. Но там, где есть работа реального человека, Velocity стремится в 0, а скорость разработки сильно снижается. Поэтому, если у вас деплой или изменение конфигурации (базовые повседневные вещи) завязаны на тикеты или другие инструменты, где есть влияние ожидание работы человека это те точки роста, которые нужно сразу же автоматизировать.

В нашем случае мы написали GitHub-бота, который с очень большим спектром валидации проверял эту карту и мгновенно отвечал: либо всё хорошо, либо есть какие-то конфликты с другими картами и сервисами:

Следующим нашим пунктом разработки инфраструктуры как продукта стало внедрение user story.

User story

User story это фундамент любой продуктовой разработки и используется он в любых гибких методологиях идущих от Agile. Это не детальное описание задач давайте прикрутим здесь кнопку, которая будет делать вот это. User story это намерение пользователя: какую проблему пользователь решал, как он пытался её решать, почему он её решал, почему она возникла, и, наконец, как мы можем её решить. Разумеется, из user story выводится очень много различных решений. Но сам User story не является им это основа для решения и инструмент для выявления исходной проблемы.

В бизнесовой разработке user story пишется на повседневном и понятном пользователю языке. Для нас здесь была небольшая ловушка, потому что наши пользователи разработчики, они очень грамотные и могут принести любую историю вплоть до того, что надо внести изменения в БД. Поэтому мы должны были обязательно вытягивать основную проблематику находить инкремент ценной функциональности, реализуемой за короткий срок.

Приведу для примера две наши внутренние истории.

Пример 1. Залипает обработчик Кафки. Чинится только рестартом сервиса. Фикс в пути. Хочется иметь способ быстро перезапустить контейнеры.

Проблема была понятной и мы предложили сделать команду restart -l prod my_service, в которой указывается слой сервис, чтобы сервис рестартился через телеграм бота.

Пример 2. При обновлении конфигурации хочется перезапустить сервис без указания версии.

Решением стало: /run -l prod -v 1.0.7 my_service -> /run -l prod my_service.

Но изначально это выглядело как одна задача: сделайте нам такую команду для рестарта, после которого сервис притягивает новую конфигурацию. С точки зрения обычной таски это можно было сделать, а с точки зрения user story нельзя, потому что в первом примере люди видят проблему и периодически рестартят свой сервер, пытаясь найти, что же здесь не так. Если при этом приедет новая конфигурация, это принесет им куда больше проблем, то есть мы можем сделать хуже.

Поэтому первое, что мы сделали это идемпотентный рестарт, который ничего не подтягивал и при этом гарантировал, что конфигурация будет идентична. А вторым стал run, который можно указать без версии версии и он подтянет новую конфигурацию (новые переменные окружения, новые секреты и обновит остальное окружение). Более того, когда мы в дальнейшем их разделили, то user story с запуском из версии модифицировали и развили так, что run стал гарантировать изменение сервиса. А если ему нечего изменять и нечего подтягивать, то он об этом честно говорил.

То есть разделяя user story, мы можем их по фидбэку развивать дальше. Но даже просто использование user story дает огромный профит, так как мы начинаем слышать пользователя о его проблеме. Но если общаться с пользователями и вместе находить решение не каждая user story будет реализована, и не каждая так, как мы придумали.

Customer development (сustdev)

Инструмент сложный в продуктовой разработке, но в случае инфраструктуры он очень прост потому что мы разрабатываем новый продукт (фичу, решение или какую-то часть нашей системы) не сразу через код, а через пользователя. Можно даже провести ниндзя-сustdev, находясь в переговорке в ожидании какой-нибудь встречи или попивая кофеечек на кофе-поинт. Да и сам процесс не очень сложный:

Выявляем потенциальную проблему (строим гипотезу), формируем идею или решение, но не внедряем ее, а идем к пользователям, чтобы поговорить с ними об их потребностях/болях/проблемах.
Встречаемся с ними, например, на кофе-поинте или на рабочем месте. Можно пообщаться и в Зуме. И в обсуждении можно обнаружить, что проблема пользователям не важна она не так много времени занимает и не так сильно его напрягает, но зато у него есть более важные проблемы.
Прорабатывая решение вместе, мы получаем либо изначальное успешное решение (если определили проблему верно) или более успешное (поняв из общения, что волнует пользователей) то есть в выигрыше все.

Например, у нас не было истории деплоев, и мы понимали, что нам она нужна. Мы напридумывали очень много сложных вещей, вплоть до того, чтобы в Telegram с помощью пейджинга показывать список последних 10 сервисов и уже думали, как же их спейджить туда-обратно и т.д. Но пообщавшись с разработчиками, мы поняли, как история начинается у большинства из них: они видят на графиках аномалию и м нужно посмотреть, не было ли деплоя не новая ли версия принесла эту аномалию?

Эта история решилась довольно просто. Мы добавили время деплоя в аннотации на Grafana, и теперь видя какую-то аномалию, можно понять, не было ли деплоя, в том числе деплоя зависимых сервисов. Эта история, кстати, ускорила у нас создание WEB UI.

А потом мы пообщались с тимлидами и выяснили, что они это видят совсем по-другому:

Developer: Я вижу по графикам проблемы нужно проверить, не связано ли это с выкаткой новой версии (см. график выше).

Team leads: Нужна возможность посмотреть кто, что, когда и зачем катил в прод:

Для тимлидов эту историю со списком, сложными фильтрами, поиском и т.д. мы реализовали намного позже. Потому что, во-первых, наш основной пользователь это обычный разработчик тот человек, который каждый день пишет код, делает фичи, раскатывает их, дежурит, заботится о сервисе и т.д. А во-вторых, это был уже этап, когда мы начали выделять и использовать портреты пользователя, а затем и портреты сервисов.

Портреты пользователей и сервисов

И то, и другое сложно реализуется в продукте, но легко и быстро в инфраструктуре. Портреты пользователей у нас были довольно простыми:

Разработчики: бэкенд, фронтенд и инфраструктура;
Team leads;
Тестировщики/Автотестировщики;
Аналитики;
Менеджеры, продукты, руководители.

По сути частичное отражение рабочих позиций :)

А портреты сервисов можно классифицировать по типу, языку или размеру. Первые бывают внутренними (realtime api, back api, async, cron, gateway, и т.д.), DB, внешними, saas и т.д. И они богатая точка роста, потому что это место отказа каких-то инфраструктурных частей. Это и наша точка роста, которую мы рассматриваем в будущем для себя.

Языки разработки мы рассматриваем нечасто, но иногда приходится смотреть: почему эта история возникает, у кого она возникает, потому что, например, у java и node.js бывают небольшие различия в работе, и это приходится учитывать.

По размеру портреты сервисов могут быть: function, microservice, service, monolith, distributed monolith и т.д. И если мы, например, понимаем, что проблематика идет из распределенного монолита, то отказываем в этой истории, потому что у нас хорошей практикой считаются мироксервисы и нашим PaaS мы популяризируем и упрощаем жизнь именно с ними..

Вот для примера портрет сервиса БД. С помощью этой карты ставятся бэкапы, происходит доступ к БД на чтение/запись и т.д. Плюс, сам сервис в свои зависимости прочерчивает эту карту, и мы знаем, что это за карта и от чего она зависит то есть, мы знаем, что сервис А зависит от базы данных В:

Feature request

Но одно дело найти проблему. Совершенно другое когда приносят уже готовое решение. Это самая богатая тема, которую можно использовать себе на благо.

Конечно, у нас есть проблемы:

Технически грамотный пользователь может принести уже готовое решение, например: Сделайте такой API, в БД все сохраните, и на этом хватит.
Личное знакомство потому что иногда мы отказываем в feature request или говорим, что будем делать по-другому, и возникает небольшой конфликт.

Но есть и решения:

Превращать в user story находить проблематику: узнавать, с какой проблемой столкнулся пользователь и как пытался решать;
Смотреть на доработку в контексте портретов кто к нам пришел, что за сервис, о чем идет речь;
Спорную доработку или ту, в которой мы не уверены, проверять через castdev, потому что все-таки feature request приносит один пользователь и непонятно, насколько это ценный функционал для всех;
Механизм голосований/рейтинга это самый мощный инструмент. Он не нов, используется во всех хороших продуктовых разработках, например, в терминале Тинькофф-Инвестиции. У них открытые feature request, где люди открыто голосуют и в итоге в работу идут те, что в топе:

Внутри это также можно легко реализовать, потому что мы работаем в рамках одного issue-трекера. Например, здесь фильтры по нашим feature request:

Из интересного: мы недавно этот вид сделали через наш WEB не таким формальным и увидели, что люди с большей охотой голосуют за идеи то есть это тоже важно:

Механизм feature request очень удобно использовать как часть синергии с пользователем и нам не нужно будет сильно прорабатывать такую историю ведь очень много пользователей проголосовали за нее. Мы можем видеть, кто голосует и это могут быть разные люди, которые поддерживают разные сервисы. Получается в итоге даже небольшой scoring функциональности мы точно понимаем и то, что она нужна, и зачем, и насколько это нужно пользователям. Голосование к тому же может заменить множество внутренних исследований таких, как сustdev.

Roadmap

Хочу отдельно сказать про Roadmap. Это кажется довольно банальной темой, но пообщавшись с разными компаниями, я обнаружил, что у команды инфраструктуры часто не бывает долгосрочного видения. Есть понимание, что они делают через неделю или месяц, но нет понимания, какой должна быть в итоге инфраструктура. И обычно это инфраструктура посредством одной кнопки, когда все описано в GitHub-репозитории и сделана она, например, на CI сборках. Куда стремиться непонятно.

Ценность даже не в самом плане, а в процессе планирования. Когда мы планируем, мы думаем, что хотим дать пользователям, поэтому roadmap удобно сделать открытым можно сразу получить фидбэк. Мы можем расставить истории по приоритетам, фидбэк может сказать нам, что большинству намного важнее то, что мы отложили. Так что публичные и регулярно обновляемые планы помогут вам скорректировать roadmap и строить долгосрочный бэклог на его основе.

Кстати, как получать обратную связь?

Тикеты и подписки на них. В нашем случае это самый рабочий инструмент, потому что мы работаем в одной компании, и в одном трекере.
Большие посты анонсы. Несколько раз в квартал мы делаем большие анонсы, где рассказываем про всю большую функциональность и опять же получаем фидбэк. Иногда мы получаем негативные отзывы, например: Зачем вы это делаете, если можно взять вот это и то. Тогда мы либо объясняем, либо понимаем, что, может и правда можно реализовать более просто.
У нас есть групповой чатик в Telegram/Slack/Microsoft Teams. В основном мы там собираем обратную связь, хотя он работает как инструмент технической поддержки, а также в нем выкатываем нововведения с небольшими инкрементальными релизами.
Открытые встречи для вопросов/ответов. Мы пока что провели её только один раз, но результат был неплохой.
Еще можно встречаться на демо продуктовой разработки и там отвечать на вопросы. Но мы не проводим демо сейчас для нас это большая потеря времени.
Еще можно использовать индекс потребительской лояльности NPS (Net Promoter Score). Это простые анкеты: насколько вы удовлетворены нашим сервисом, насколько вам удобно базовые вопросы для того, чтобы собрать общую статистику лояльности пользователей. Мы не используем NPS, потому что из чата получаем и критику, и позитив, а остальных записываем как нейтральных пользователей.

MVP

После планирования хочу напомнить про инструмент MVP (Minimum Viable Product). Это известный подход, но в инфраструктуре есть нюансы. Мы, как любой бизнесовый продукт, выкатываем частично недоделанный продукт, где-то не самый удобный, но минимально рабочий. Потому что мы не можем делать 2-3 месяца какую-то историю, выкатить её, получить средний фидбэк и потом еще месяц переделывать:

Henrik Kniberg

Поэтому мы стараемся поддерживать максимально инкрементальные релизы для того, чтобы потихонечку двигаться к тому функционалу, который запланировали в будущем и который, опять же, всем известен. А получая фидбэк, мы успеваем его корректировать:

Henrik Kniberg

Например, когда мы резолвили свой первый WEB, его функциональность была далека от функциональности Telegram, да и выглядел он неказисто, если честно. Но впоследствии он развивался, мы получали фидбэк, и в результате даже пошли по другому пути, потому что UXe (пользовательский опыт) отличается от того, что было в Telegram, и от того, что есть в WEB.

WEB сейчас поддерживает тот же самый функционал, но он в той или иной мере реализован в WEB немного по-разному. Плюс, он расширился: в нем есть истории деплоев, работа с картой и манифестом, с переменными окружения и т.д.

Overkill

Важно понимать, когда продуктовый подход становится слишком сложным. Бизнесовые команды становятся настолько большими, что состоят из множества людей с разной направленностью и спецификой. Есть product owner, цель и задачи которого выстраивать roadmap и определять, какие из историй делаются. Есть product менеджер, UX-специалисты, разработчики, тестировщики и т.д. Когда большие истории разбиваются только по user story и пытаются делать с добавлением какой-то пользовательской ценности. Всё это очень круто, но сейчас для нашей команды это overkill. Как в принципе, и A/B-тестирование.

Поэтому нужно четко определять, что мы используем, а что нет. Для небольших команд инфраструктуры, как наша, есть лайфхаки, которые помогают иметь результат не хуже:

Стараться понять: Зачем? То есть не Разработчик хочет 500 Тб БД, а: Разработчику нужно сохранять информацию о машинках (которую мы никогда не сохраняли) тогда мы сможем работать вместе над одной проблемой пользователя
Добавить в команду продуктового разработчика, потому что DevOps расширяется, кода мы пишем сейчас больше, и нужен разработчик, который пропитан этой атмосферой.
Добавить в команду фронтендера, понимающего в той или иной мере в интерфейсах. Да, это не профессиональный дизайнер, но для инфраструктуры этого достаточно.
Обязательно нужен механизм голосования за идеи для того, чтобы упростить scoring задач.
Собирать roadmap и сделать его открытым.
Периодически собирать аналитику не сложные и большие графики, но чтобы плюс-минус понимать, что происходит у пользователей.
Нужно много автотестов , так как я все еще не представляю вакансии тестировщика в команде инфраструктуры, как и дизайнера по крайней мере в 2021 году.
И основной пойнт больше синергии с пользователями. Потому что хорошую инфраструктуру ограниченной командой с ограниченными ресурсами можно делать только в синергии с пользователями вытаскивая самые ценные истории.

Итог

В заключении рекомендую книгу Психбольница в руках пациентов Алана Купера я ее прочитал очень давно и с огромным удовольствием, она меня вдохновила. Сейчас настало время, когда ее стоит рекомендовать не только product owner, продуктовым разработчикам, дизайнерам, но и команде инфраструктуры. Там очень много полезных примеров, в которых можно найти себя.

Подытоживая:

Разговаривайте со своими пользователями, находите проблематику надо искать проблемы, а не решения.
Относитесь к внутренней инфраструктуре как к единой платформе, как к единому PaaS.
Разрабатывайте PaaS как полноценный внутренний продукт.
Используйте проверенные простые продуктовые подходы, но только те, которые окажутся простыми. Если тот или иной подход (тот же сustdev или портреты пользователей) кажется сложным, возможно, сейчас их не стоит использовать.
Повышайте ценность PaaS (скорость/расходы разработки/поддержки).
Создавайте современные интерфейсы.
Примите, что современная команда инфраструктуры приближается к продуктовой. Её уже официально называют командой DevOpsеров. Эта мифологическая команда приближается к продуктовой по своим требованиям и тому, как она должна работать. Следование новым веяниям и использование современных подходов поможет создавать действительно удобную инфраструктуру

А любые сложности можно обойти в синергии с пользователем. Если вы создадите коммуникации и инструменты для этого, вы получите максимум фидбэка, а значит максимум информации, как инфраструктура может сделать компанию эффективней. Пишите, я готов к обсуждению.

Профессиональная конференция DevOpsConf 2021 пройдёт 31 мая и 1 июня этого года в Москве, в отеле Radisson Slavyanskaya. Расписание уже сформировано. На сайте вы можете познакомиться с программой и спикерами.

Как всегда, будут реальные кейсы компаний, сложные инженерные аспекты цифровой трансформации, многообразие технологий и подходов: наглядно, просто, с конкретными рекомендациями. Билеты здесь.

До встречи в оффлайне!

Подробнее..

Категории: It-инфраструктура , Devops , It-компании , Управление продуктом , Инфраструктура , Mvp , Блог компании конференции олега бунина (онтико) , It-infrastructure , Customer development , Paas , Features , User story , Roadmap , Infrastructure as a product

Сюда Разработка Подлинная Java как работает AliExpress после переноса разработки в Россию

14.04.2021 16:05:26 |

Автор: admin

Привет, Хабр! Меня зовут Анатолий Орлов, и я технический директор AliExpress Россия. Сервис доступен русскоязычным пользователям уже 11 лет, при этом офис компании в Москве открылся только пять лет назад, а локальная команда разработки появилась лишь в прошлом году. Ее главная задача адаптировать площадку, изначально заточенную на китайский лад, к реалиям Рунета и сделать ее понятнее и проще для русскоязычных пользователей.

Почему китайский поисковый движок не подходит для рунета, как помочь локальным продавцам получить больше заказов, какие технологии и почему для этого нужно адаптировать в первой статье в нашем блоге на Хабре поговорим о процессе переноса разработки, трудностях на этом пути, первых проектах и планах инженерной команды. Поехали!

Зачем вообще переносили разработку

Решение о переносе разработки в Россию было принято после создания совместного предприятия (СП), в котором приняли участие Alibaba, Mail.Ru Group, Мегафон и РФПИ. Сделано это было для того, чтобы развивать площадку в сфере электронной коммерции по правилам и законам российского рынка и для удобства российских пользователей и селлеров.

Это я

В последние годы русскоязычная часть AliExpress интенсивно развивалась и требовала больше ресурсов и фокуса. При этом российский бизнес для Alibaba Group в целом это слишком маленький сегмент в сравнении с любым китайским сервисом компании, так что получить ресурсы для проведения изменений было очень сложно. Когда разработка русскоязычной платформы не находится в России, то проекту нужно ждать своей очереди на ресурсы разработки. А учитывая, что очередь приоретизируется по объему рынка, пользователям Рунета приходилось ждать улучшений продолжительное время. Если же инженеры работали бы в России и постоянно занимались именно российским AliExpress, понимая, как делать продукт, востребованный здесь, это открыло бы больше простора для развития.

После создания СП ситуация сдвинулась в эту сторону, мы активно начали наращивать техническую команду. Так, если в январе 2020-го нас было около 40 человек, то в январе 2021 года число инженеров выросло почти до 400. Что же делают все эти люди?

Адаптация глобального сервиса под рунет

Звучит всё довольно просто: нужно всего лишь забрать в свое ведение важные для локального рынка части системы (например, поиск), адаптировать их и развивать площадку в дальнейшем. На практике всё оказывается совсем не так легко.

Инфраструктура AliExpress изначально не была рассчитана на то, что в будущем могут появиться проекты в разных странах, которые будут развиваться по правилам локального рынка и силами местных специалистов. Код писался китайскими разработчиками, с использованием удобных им инструментов, в том числе внутренних технологий Alibaba, которые трудно применять вне Китая. Например, может быть отличная технология с документацией только на китайском языке и требующая логина из двух иероглифов, чтобы начать с ней работу.

Фото: Олег Лозовой / РБК

Несмотря на то что одним из главных языков программирования во всей экосистеме является Java, почти всё окружение и инструменты проприетарны. Довольно часто встречаются форки популярных известных открытых решений, но в общем объеме инфраструктуры их не так много. Часто такие системы сильно допилены и имеют мало общего с исходным проектом. Например, у Alibaba есть чудесная технология MaxCompute, которая внешне почти неотличима от hadoop и, видимо, когда-то была форкнута от hadoop, но размеры кластеров, находящихся под ее управлением, таковы, что у разработчиков hadoop глаз бы задергался от зависти.

Типичная локализация разработки чего-то выглядит так: мы берем часть системы AliExpress и делаем ее локальный форк в смысле копируем сервисы, деплоим вторую копию приложений и переключаем трафик. После этого мы получаем возможность изменять код, не влияя на китайские части системы в других странах.

Взаимодействие с китайскими коллегами-инженерами тоже необычный опыт. Существуют культурные особенности подхода к работе и самой рабочей этики, нельзя сбрасывать со счетов и большую разницу во времени. Плюс дает о себе знать и тот факт, что инженеры в Китае и России привыкли работать с разными технологиями и чтобы настроиться на одну волну в обсуждениях, людям с разным опытом требуется время.

В китайской культуре принят непрямой feedback. Это когда собеседнику напрямую не указывают на недочеты в его работе, да еще и публично чтобы не расстроить и не унизить, а осторожно намекают. С пониманием обычно не возникает трудностей. К примеру, слово suggest (по-русски предлагать) для китайцев имеет другое значение. Если такое предложение исходит от руководителя следует воспринимать это как приказ, который нужно исполнить. В случае когда что-то изменить предлагает коллега из другой команды это означает довольно настойчивую просьбу.

Русскоязычным разработчикам с их привычкой давать прямую обратную связь это не всегда понятно, а китайских коллег часто шокирует стандартный русский заход вы сделали не то, нужно переделать. Результатов можно в любом случае достигнуть, но на переговоры и обсуждения может уходить чуть больше времени, чем мы привыкли.

Даже сам процесс общения с китайскими коллегами выглядит иначе: они очень активно используют смайлики даже в сугубо деловой переписке. Неважно, насколько серьезный вопрос вы обсуждаете, чат будет полон эмодзи:

Смена стека технологий, замена поискового движка, промо локальных продавцов

Для AliExpress в России мы приняли решение в конечном итоге отказаться от проприетарного стека технологий в тех областях, где это имеет смысл. Например, где в open source есть сравнимые по качеству аналоги и где переход можно осуществить относительно малой кровью.

Часто вместо Java мы используем Kotlin, пишем отдельные сервисы на Go и .Net, применяем Kubernetes, GitLab, k8s, Prometheus, Grafana, Opsgenie и т. п.

При этом многие проекты Alibaba Group останутся в стеке, потому что они хорошие и/или нужные. Например, источником знаний о товарах кросс-бордера (то есть, которые можно купить у зарубежных поставщиков) всегда будет система Alibaba; мы можем написать свою, но заставить перейти туда 100 млн китайских селлеров будет довольно тяжело.

Одно из первых изменений: мы занялись заменой китайского движка поиска. Сейчас он отнюдь не всегда применим для русских запросов, например в некоторых местах поисковый запрос обрезается до 30 символов при этом посередине слова. На первый взгляд какой-то ужас, но для китайского движка это довольно логично, ведь там нет пробелов, а запросы длиной 30 символов (т. е. иероглифов) не встречаются в реальной жизни. На самом деле, поправить эту особенность несложно, но, когда дефектов много, более надёжным подходом будет сделать свой движок поиска. При всем этом технологически поисковая платформа Alibaba близка к state of art.

Другое важное изменение: мы начали работы по выделению в выдаче товаров локальных продавцов. Проблема глобального AliExpress заключалась в том, что даже если товар, который можно купить у российского продавца и заплатить меньше за доставку, существовал, то российские пользователи могли об этом не узнать.

Фото: Олег Лозовой / РБК

Алгоритмы machine learning Alibaba заточены под продвижение товаров с наибольшим объёмом продаж, и закономерно возникает проблема курицы и яйца: российский сегмент платформы здесь не может конкурировать с Китаем, а в итоге местные продавцы не получают достаточных позиций в поиске. После ряда неудачных попыток и экспериментов нам удалось повысить позиции российских товаров, но система всё еще далека от идеала, мы будем её улучшать.

В итоге российская инженерная команда взяла на себя развитие сайта aliexpress.ru, российского мобильного приложения, и вскоре в сферу ее ответственности войдут и все остальные аспекты вроде программы лояльности.

Что дальше: полностью свой поиск, еще больше трафика локальным товарам, багфиксинг

Мы активно пилим новый поиск, который будет включать алгоритм продвижения локальных товаров по самым популярным запросам и выдавать рекомендации к ним так, чтобы при этом не терять объем продаж. Ну и естественно, он будет искать так, как привыкли русскоязычные пользователи. Текущий статус: мы провели первый a/b тест, результаты которого нас радуют.

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

Очевидно, что некоторые части системы AliExpress полностью локализовать не удастся никогда, но мы хотим добиться состояния, при котором для пользователя и селлера платформа будет максимально удобна, без ограничений. Мы будем активно этим заниматься и рассказывать о своем опыте в блоге на Хабре. Так что подписывайтесь и пишите в комментариях, о чем нам рассказать в следующих статьях.

Подробнее..

Категории: It-инфраструктура , Разработка , Разработка под e-commerce , Инфраструктура , Электронная коммерция , Aliexpress , Блог компании aliexpress россия , Aliexpress.ru

От появления ЭВМ до периферийных вычислений в телекоме

18.01.2021 22:06:54 |

Автор: admin

Edge Computing введение в тему

С момента появления первых электронно-вычислительных машин (ЭВМ) в 40-х годах прошлого века системы обработки данных прошли огромный путь от отдельного, ненадежного и громоздкого вычислительного устройства до глобальных распределенных систем обработки больших данных (BigData) получаемых в реальном времени. Современные сетевые вычислительные системы несут в себе отпечаток предыдущего накопленного многолетнего опыта их построения и эксплуатации.

Одним из результатов исторического развития стало появление Edge Computing. Что важно знать об Edge Computing? Это не четкое определение или конкретные механизмы, а концепция, при которой часть обработки данных, критичная к скорости, выполняется на узлах, вынесенных за пределы крупных ЦОДов и размещенных перед последней милей или в минимальном количестве прыжков от конечного устройства-потребителя или поставщика данных. В русскоязычной среде для обозначения Edge Computing распространены два обозначения граничные вычисления и периферийные вычисления.

Рассмотрим, как произошёл переход от огромных машинных залов до периферийных вычислений на смартфонах.

Предыстория структура и задачи компонентов сетевых вычислительных систем

Задачей самых первых операционных систем (ОС), появившихся в 50-х годах (например, GM-HAA), была координация запуска пакетов программ и вывод полученных результатов. Более развитые ОС (такие как Unix, RSX, VMS) появились в 70-х и получили много дополнительных функций, в том числе связанных с межкомпьютерным взаимодействием. Если первым пользователям приходилось для работы использовать системы ввода/вывода расположенные непосредственно в центрах обработки данных (ЦОД), то с развитием коммуникационных систем в 60-х годах появилась возможность подключать пользовательские терминалы по выделенным и коммутируемым медным телефонным линиям, а в конце 70-х по волоконно-оптическим. В середине 60-х для организации линий связи стали доступны первые коммерческие спутниковые каналы.

Параллельно с развитием линий связи совершенствовались и протоколы передачи данных. После появления пакетных систем передачи данных канального уровня (в 70-х годах протокола Ethernet и подобных, в 80-х годах протоколов SLIP, Token ring, HDSL и т.д.), а затем в 80-х протоколов для пакетной связи на региональном и на глобальном уровне (сеть Internet на основе стека протоколов TCP/IP), пользователям для обработки и хранения данных стали с рабочего места доступны удаленные компьютерные центры.

С выпуском в 70-х годах первых микропроцессоров начали активно развиваться специализированные вычислительные устройства и персональные компьютеры. Они подключались к мощным ЦОД через глобальную сеть в качестве клиентских периферических устройств для доступа к вычислительным мощностям и хранилищам данных. Как правило рабочее место использовалось в качестве тонкого клиента (например, как терминал подсоединенный по протоколам Telnet, rlogin и т.д.) для запуска вычислительных задач на удаленном сервере или для получения данных по таким протоколам как FTP.

С 50-х годов для долговременного хранения компьютерных данных вместо перфокарт и перфолент начали применяться устройства с магнитными носителями информации, как для последовательного доступа (магнитные ленты, затем кассеты) больше подходящие для запуска системы и резервирования, так и для произвольного доступа (магнитные барабаны, диски, дискеты) позволяющие осуществлять быстрое обращение к необходимым фрагментам данных.

Первоначально наиболее распространенный в операционных системах способ организации хранения данных в виде файловых систем оказался не оптимальным для работы со сложными структурами характерными для бизнес-приложений, что привело к созданию в 50-х и 60-х годах специализированных языков программирования для работы с большим количеством разнотипных записей сравнительно небольшого объема (таких как язык Cobol, на котором написаны многие приложения используемые до сих пор), и к возникновению в 70-х годах концепции реляционных баз данных и языка SQL.

Другим способом доступа к серверным ресурсам стал появившийся в 80-х годах протокол RPC позволивший осуществлять удаленный запуск программ на сервере. На базе этого протокола в конце 80-х годов было разработано программное обеспечение первой массовой сетевой файловой системы NFS позволившей реализовать доступ к файлам и каталогам сервера как к локальным файлам и каталогам клиентского компьютера.

Развитие сетевых технологий

В 90-х годах произошел кардинальный скачок в количестве пользователей сети Интернет, объеме трафика, производительности рабочих станций и серверов, в развитии сетевых технологий и вычислительных систем обработки данных обусловленный целым набором факторов:

Широкое внедрение высокоскоростных соединений на основе семейства протоколов xDSL.
Развитие волоконно-оптических линий связи (ВОЛС).
Стали более доступны спутниковые системы связи VSAT и дешевый комбинированный доступ.
Появление протоколов распределенного поиска и передачи документов (gopher, http и т.д.).
Появление первых поисковых систем - Archie (90), Wandex (93), Yahoo! (94), Google (96).
Создание универсального протокола канального уровня PPP с автоматизированной настройкой параметров соединения, удобного для клиентского соединение по коммутируемым линиям и поверх xDSL.
Степень интеграции, параметры микропроцессоров и технология SMP позволили использовать микропроцессоры при проектировании серверного оборудования, а центральные процессоры (ЦП) рабочих станции приблизились по производительности к ЦП серверов.
Появление пользовательских операционных систем для персональных компьютеров с интегрированным программным обеспечением для подключения к интернет-провайдерам, простой настройкой сервисов Интернет и предустановленными Web-браузерами (Windows 95).
Появление свободнораспространяемого и юридически чистого программного обеспечения на основе юниксоподобных систем (386BSD, FreeBSD, NetBSD, OpenBSD, ОС на основе ядра Linux и т.д.) портированных для широкой номенклатуры серверного и другого оборудования.

Для того что бы справляться с многократно возросшей вычислительной нагрузкой в ЦОДах интернет-провайдеров начали формироваться распределенные серверные кластеры объединенные высокоскоростными локальными вычислительными сетями (ЛВС) включающие десятки, сотни и тысячи серверов, обрабатывающих запросы клиентов и балансирующих нагрузку.

Кроме необходимого коммуникационного и серверного оборудования такие кластеры включали системы резервирования и специализированные системы хранения данных (СХД), использующие избыточные массивы дисковых устройств (RAID) для надежного хранения данных и быстрого восстановления после сбоев. Данные расположенные на СХД стали использовать для формирования распределенных сетевых файловых систем доступных серверам кластера.

Облачные технологии

Развитие ЦОДов и необходимость кратного увеличения их безопасности, надежности и готовности привело к появлению в конце 90-х годов программного обеспечения для виртуализации технических средств и позволило сформулировать новую вычислительную парадигму названную облачные технологии, реализованную для коммерческих целей в 2000-х годах. В рамках этой парадигмы данные размазаны по системам хранения кластера и доступны через виртуальные интерфейсы виртуальных серверов, мигрирующих по кластеру.

Обычно в кластере выделяется внутреннее серверное ядро, имеющее доступ к наиболее защищенным данным через выделенную для этих целей приватную сеть. Во внутреннем ядре запускаются наиболее важные серверные приложения, которым требуется доступ к защищенным данным. Сами данные располагаются на распределенной файловой структуре с избыточной информацией для повышения надёжности хранения данных и позволяющей организовать доступ приложения, выполняющегося на серверах кластера, к необходимому ему логическому диску с данными.

Внешние серверы, на которые поступают пользовательские запросы из публичной сети имеют возможность переадресовать их внутреннему серверному ядру с помощью промежуточной сетевой инфраструктуры. Перед тем как запрос попадет на внешний сервер в кластере может быть предусмотрен дополнительный сетевой приемный контур из устройств, балансирующих нагрузку и распределяющих ее по внешним серверам.

В рамках облачной архитектуры виртуальная логическая структура кластера, видимая для прикладного программного обеспечения, может значительно отличаться от реальной физической структуры сформированной оборудованием. Прикладное программное обеспечение может запускаться в программных контейнерах на виртуальных серверах свободно мигрирующих по физическим серверам кластера в реальном времени.

У крупных провайдеров дополнительное повышение надежности и готовности обеспечивается формированием нескольких региональных ЦОДов, которые дублируют функции друг друга в случае потери связанности сети.

После появления на рынке глобальных облачных провайдеров у любой организации оказывающей услуги появляется альтернатива или строить свой собственный ЦОД с облачной инфраструктурой и содержать необходимый для его поддержания высококвалифицированный персонал, или арендовать доступ к готовому облачному сервису выбрав одну из трех обычно предлагаемых моделей:

IaaS аренда соединенных в сеть виртуальных серверов.
PaaS аренда программной платформы, например, доступ к данным и приложениям через пользовательский интерфейс без низкоуровневого доступа к виртуальному серверу.
SaaS доступ к данным через специализированный интерфейс.

Небольшой провайдер для своих целей скорее всего воспользуется моделью IaaS, т.к. другие две модели больше подходят для разработчика и клиента.

Edge Computing периферийные вычисления

Актуальная в настоящий момент модель сети представляет собой множество ЦОДов связанных между собой выделенными линиями или же туннелями через публичную сеть и окруженных удаленными периферическими устройствами рабочими станциями, мобильными устройствами, небольшими компьютерными кластерами (например, расположенными в офисных помещениях) и т.д., имеющими доступ к ЦОДам через публичные сети различной пропускной способности. Да и сами ЦОДы могут сильно различаться по своему составу и вычислительной мощности, поэтому некоторые из них могут рассматриваться для головных ЦОДов как периферия. Обработка данных на всех этих периферийных устройствах и приводит нас к концепции Edge Computing.

Напомним, Edge Computing концепция обработки критичных к скорости данных ближе к месту их возникновения без передачи в центральные ЦОДы.

Предпосылки для развития периферийных вычислений:

Рост объемов данных, которые требуют обработки и быстрого ответа на местах. Нельзя отменить ограничение на задержку передачи данных на большие расстояния, а это критично для реалтаймовых систем.
Рост загруженности сетей мобильных операторов увеличение пропускной способности скорее не успевает за ростом объемов потребления трафика.
Стремление разделить данные и сегменты сети для повышения безопасности.
Желание повысить надежность и автономность отдельных частей IT-системы.

Децентрализация и перенос места обработки информации ближе к источнику данных производится для:

Снижения нагрузки на сети передачи данных.
Уменьшения времени задержки при обработке.
Выполнения нормативных требований и законодательства.

Применимость концепции следует именно из этих трех основополагающих элементов. Фактически, любые системы, работающие в реальном времени, могут требовать использования периферийных вычислений. Развитию рынка периферийных вычислений способствуют IoT (концепция интернет вещей - Internet of Things) и массовый переход на сети 5G первые обеспечивают кратный рост устройств, подключенных к сети, а вторые дают возможность передачи довольно больших объемов данных при росте количества подключенных устройств.

Оборудование для периферических вычислений

Разница с обычной схемой, когда устройства сразу отдают данные в ЦОД, заключается в появлении промежуточных узлов, где накапливается сырая информация, преобразуется, только затем уходит в ЦОД. В ЦОД может отправляться только информация нужная для долговременного хранения, а все оперативные данные могут вообще существовать только на периферических устройствах.

Классификация устройств, которые применяются для периферийных вычислений может быть столь же размытой, как границы самой концепции. На практике встречаются разные варианты подхода, но для специфики телекоммуникационных компаний и облачных сервисов более близка следующая классификация:

Локальные устройства отдельные шлюзы, промышленные компьютеры, минисерверы, контроллеры, банкоматы, онлайн кассы, терминалы для приема платежей, иногда сами пользовательские устройства типа смартфонов, беспилотные автомобили и т.д. Пользовательские устройства при этом иногда обозначают как endpoint-устройства. А промышленные компьютеры, минисерверы как Edge-устройства.
Локальные ЦОДы или микроЦОДы 1-10 стоек, дают значительные возможности по обработке и хранению данных по сравнению с локальными устройствами.
Региональные ЦОДы более 10 стоек.

2 и 3 пункт фактически может быть приравнен к CDN (Content Delivery Network) - Сеть доставки содержимого. Либо наоборот на базе чьего-то CDN можно строить инфраструктуру для периферийных вычислений.

Локальные устройства в наибольшей мере распространены. Промышленный компьютер или периферийный сервер в таком контексте может представлять из себя устройство чуть ли не в герметичном корпусе с ограниченным энергопотреблением, пассивным охлаждением, способным находиться в агрессивных, пыльных, влажных производственных средах или на добывающих предприятиях. Часто локальные устройства могут подключаться по беспроводным и проводным каналам связи одновременно по воздуху получать данные с каких-то датчиков, СКД, телеметрии, а по Ethernet получать питание и отдавать уже обработанные данные вышестоящим серверам. Локальные устройства могут быть оснащены дополнительными датчиками акселерометрами, барометрами, температурными датчиками, гигрометрами.

Типичный пример endpoint-устройства смартфон собирает данные со своих датчиков, агрегирует их, выполняет вычисления в мобильном приложении, затем передаёт их через CDN в основное облако сервиса. Типичный сценарий использования в современной жизни: виртуальная примерка вещей в приложениях различных ритейлеров, игры с дополненной реальностью.

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

Если говорить про микроЦОДы (MDC), то существуют готовые решения под ключ на несколько стоек, которые могут быть быстро развернуты в месте потребления и обработки данных. Есть варианты и мобильных контейнерных микроЦОДов которые могут быть развернуты в любом самом удаленном месте. Обычно микроЦОДы содержат серверное оборудование, ИБП (Источники Бесперебойного Питания) и системы вентиляции, кондиционирования, пожаротушения, мониторинга. Микро ЦОДы могут быть использованы для размещения активного оборудования провайдера. Бывают и обратные ситуации базовые станции сотовых операторов являются хорошим местом размещения периферийного оборудования и можно арендовать место в стойке на базовой станции под свой сервер. Тем более, что сотовый оператор уже решил проблемы энергоснабжения, охлаждения и сохранности оборудования. А получить связь лучше, чем на базовой станции оператора довольно сложно.

Архитектура

Наиболее распространены двух- и трёхзвенные варианты построения Edge-систем.

Двухзвенная граничное устройство и ЦОД/облако.

Трёхзвенная граничное устройство, туман (микроЦОДы, микрооблака, отдельные сервера), ЦОД/облако.

Периферийные вычисления дополняют облачные системы. Сейчас по мере роста энергоэффективности, производительности и миниатюризации компьютерного оборудования происходит перебалансировка нагрузки между централизованными ЦОДами и децентрализованными Edge-устройствами.

В большинстве периферийных ЦОД нет IT-специалистов на постоянной основе. Периферийными устройствами и микроЦОДами управляют в большинстве случаев удаленно. При этом требуется упреждающее техобслуживание с выездом на место персонала.

Достоинства

С точки зрения бизнеса следование концепции даёт:

Повышение эксплуатационной эффективности работы.
Создание новых технологически ёмких услуг и продуктов.
Повышение доходов за счет обслуживания распределенной инфраструктуры и базирующихся на ней товаров и услуг.
Улучшение обслуживания клиентов.

Примеров использования множество и окружают они нас повсеместно.

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

Из популярных систем, которые сейчас активно внедряются установка в крупных городах систем распознавания лиц, системы учета интенсивности движения и беспилотные автомобили.

Как всё это работает? Возьмем несколько упрощенных примеров.

Камера в метро сканирует весь поток людей и отправляет агрегированные данные о пассажиропотоке (количество заходящих и выходящих людей на конкретную станцию) в ЦОД непрерывно. Благодаря этому можно регулировать частоту отправки поездов и выводить дополнительные составы на загруженные линии еще до того, как на перроне сформируется толпа. При этом на камеру загружена ограниченная по объему база фотографий преступников в розыске. Устройство на месте сверяет отсканированные лица с локальной базой. При совпадении срабатывает тревога.

Аналогично с камерами для фиксации потока автомобильного трафика - фиксируются количество и скорость автомобилей на трассе. На локальном оборудовании транспортные средства распознаются и классифицируются на мототранспорт, легковые авто, грузовые разного тоннажа и длины. Агрегированные данные отправляются в ЦОД. При нарушении скоростного режима, производится дополнительно фото/видеофиксация нарушителя номер ТС (Транспортного средства), фото авто и водителя (если возможно). Эти дополнительные данные также отправляются в ЦОД для формирования штрафа. Так же как с камерами в метро можно дополнительно отслеживать авто по госномерам по базе загруженной на локальное устройство.

Более сложный вариант - беспилотные авто или сельхозтехника, управление дронами. Здесь используются более сложные модели машинного обучения, чем для распознавания госномеров ТС. При этом выше и требования к оборудованию, потому что какая-то хотя бы минимальная логика управления беспилотным устройством во время чрезвычайной ситуации обязательно должна быть на локальном устройстве, иначе любые помехи с удаленным центром управления могут привести к ДТП или иной аварии.

По степени ответственности еще более важными являются промышленные роботизированные системы высокоскоростные сборочные или распределительные конвейеры, системы обслуживания инфраструктуры промышленных предприятий. И здесь уже речь может идти не о ДТП, а о каких-нибудь экологических катастрофах.

Что еще можно назвать из наиболее востребованных периферийных вычислений?

Мониторинг сетевой активности, предотвращение атак и распространения вредоносного ПО, блокирование подозрительного трафика в момент и точке обнаружения.
Формирование различных моделей при машинном обучении, предварительная обработка данных при работе с нейросетями и в области ИИ.
Умные дома.
Безопасный город.
Онлайн-игры.
Любые сети доставки контента, инфраструктурные проекты интернет-гигантов.
Виртуальная и дополненная реальность.

Еще в 2018 году аналитики McKinsey говорили в своём отчете New demand, new markets: What edge computing means for hardware companies о 100 вариантах использования в 11 наиболее перспективных отраслях. А сейчас 2020 год и рынок динамично развивается несмотря на пандемию и экономический кризис.

Законы

Про это надо сказать отдельно. Законы и локальные нормативные акты диктуют свои правила игры. Из-за этого надо хранить данные граждан России на территории России, данные граждан Евросоюза на территории Евросоюза. Таких ограничений достаточно и это вынуждает технологические компании дробить базы и выносить их в CDN в конкретном регионе Земли.

Тут даже добавить больше нечего надо создавать вынесенные из общей структуры сети локальные хранилища, как того требует местное законодательство, если жители страны представляют для компании коммерческий интерес.

Практика

Рассмотрим работу концепции переферических вычислений на примере компании Форвард-Телеком, одним из главных направлений работы которой является автоматизация деятельности операторов связи и интернет-провайдеров. Программное обеспечение Forward во многом является потребителем информации, полученной с edge- и endpoint-устройств. Система Forward BSS/OSS, как комплексная платформа, предназначена для поддержки бизнеса клиента практически при любой существующей модели сети оператора. Платформа Forward имеет логичную модульную структуру, легко масштабируется, поддерживает облачную и гибридную модель развертывания, при этом система позволяет настроить разнообразные внешние интерфейсы для взаимодействия с элементами сети оператора и клиентами.

Система OSS отвечает за правильную работу сетевой инфраструктуры и оборудования, а система BSS за учет оказанных услуг, взаиморасчеты с абонентами, управление ресурсами и проектами (элементы подсистемы ERP), за отношения с абонентами и хранение дополнительных данных (элементы системы CRM).

Для небольших операторов доступ к возможностям Forward BSS/OSS может предоставляться как стандартизованная услуга облачного сервиса по модели SaaS, при этом сеть оператора и его клиенты взаимодействуют с системой в рамках концепции Edge Computing.

В качестве периферии выступает коммуникационное и серверное оборудование оператора, рабочие станции и мобильные устройства клиентов, на которые могут устанавливаться выносные модули системы и специализированные мобильные приложения. При работе через веб-интерфейс системы Forward вычислительные ресурсы периферийных устройств могут быть задействованы при выполнении элементов страниц, использующих JavaScript и апплетов Java.

Для крупных операторов система Forward BSS/OSS может с минимальными затратами времени и усилий интегрироваться в их облачную или гибридную инфраструктуру. При этом в зависимости от поставленных задач система способна выполнять как ведущую роль, так и выступать в качестве периферийного предобработчика данных для других систем заказчика или работать с ними в кооперации.

Характерной особенностью многих крупных операторов является наличие исторически сложившегося зоопарка информационных систем. Плохо совместимое программное обеспечение различных вендоров, внедрённое на разных этапах развития компании в каких-то региональных подразделениях или полученное при покупке местных операторов. Быстрая замена такого зоопарка часто не возможна или слишком накладна. Интеграция исторических информационных систем может быть быстрее и дешевле произведена через Forward BSS/OSS через API или специально написанные шлюзы.

Поток обращений по интеграции OSS/BSS систем с мобильными приложениями становится больше. Все операторы связи, банки, ритейлеры, сервисные компании, госорганы постепенно обзаводятся приложениями B2B, B2C или B2B2C класса для коммуникации со своими заказчиками. Самостоятельное управление абонентскими услугами через мобильное приложение подразумевает глубокую интеграцию в бизнес-процессы компании и всё больше приближает нашу работу по автоматизации к endpoint-устройствам конечных пользователей.

Сложности при использования концепции

Все сложности возникающие при использовании переферических вычислений следуют из предпосылок и самой сути концепции:

Близкое к источнику данных место размещения оборудования может быть с недостаточным электроснабжением, плохой связью, удаленным на сотни километров от цивилизации, экстремальной температурой, суровыми погодными условиями.
Бывает сложно обеспечить физическую безопасность устройств от обычных вандалов или от кражи.
Информационная безопасность edge- и endpoint-устройств заслуживает отдельного упоминания. Удаленность от основных объектов инфраструктуры, отсутствие охраны может дать злоумышленнику возможность физического доступа к устройству и его компрометации.
Устройства могут обладать прекрасной энергоэффективностью, но оставлять желать лучшего по производительности и объему хранимой локально информации.
Необходимо контролировать доступ в помещения и на территорию, отведенную под микроЦОД. Приходится вести мониторинг окружения влажность, температура, дым, затопления, сила ветра, атмосферное давление и т.д. Обеспечивать надзор видео и аудио наблюдение за объектом.
Сложность восстановления работы удаленных узлов после природных катаклизмов в силу их потенциальной территориальной удаленности друг от друга.
Необходимость разрабатывать ПО, ориентированное на большую сегментированность источников данных, возможность выхода из строя отдельных частей инфраструктуры, большое количество единиц бэкапов.

Для разработчиков систем автоматизации, 7 пункт является наиболее важным. Именно он входит в сферу ответственности Форвард-Телеком перед заказчиком и разработчики стараются выполнять свою работу хорошо. О том, как идёт у Форвард-Телеком разработка биллинговых систем уже писалось на Хабре в статье Как там биллинг делается: когда заказчик и разработчик говорят на разных языках.

Уменьшение техпроцесса и широкое распространение энергоэффективных многоядерных вычислительных устройств будет способствовать дальнейшему перекладыванию обработки данных на локальные устройства и увеличению собираемой номенклатуры данных. Как минимум, можно ожидать, что будет необходимо готовить платформу Forward OSS/BSS к существенному расширению типов поступающей информации, обработке этих данных в реал-тайме с использованием Edge Computing инфраструктуры. Например, вполне вероятно, что в будущем данные какого-нибудь фитнес-браслета о кардио-ритме носителя могут быть использованы в банковской системе для скоринга рисков, оценки вероятности возврата задолженности и расчета процентной ставки по кредиту.

Так что Prepare yourselves because cyberpunk is coming

Подробнее..

Категории: Цод , Big data , Облачные сервисы , Инфраструктура , Периферия , Облако , Saas / s+s , Периферийные вычисления

Как из одной базы данных сделать 10 разных, храня только инкременты обзор решения

18.05.2021 10:20:20 |

Автор: admin

История очень простая: есть большая продуктовая база данных. Она нужна пяти-шести командам разработки, тестировщикам и другим командам. Можно сделать штук 10 разных инстансов + БД, но обычно это дорого и долго. Гораздо лучше взять одну мастер-базу и хранить её инкременты для тех команд, которые с ней работают. Для этого есть специальные утилиты. Если лет пять назад они только начинали распространяться в России, то теперь их использование абсолютно нормальная практика.

Давайте посмотрим, как это работает, на примере Actifio:

Слева Shapshots, на их основе можно создавать виртуальные БД (VDB).

Итак, берём продуктовую базу и начинаем её клонировать. Нужно это для того, чтобы, в частности, получать тестовую базу за 15 минут, а не за две недели (а бывает и дольше), как обычно в крупных компаниях.

Куда нужна такая БД?

Да почти везде:

Обычный процесс выглядит так:

На самом деле это процесс курильщика, потому что вот процесс здорового человека, подумавшего когда-то про правильную инфраструктуру:

Для этого мы делаем не вот так:

То есть каждый инстанс БД взаимодействует в режиме read-write (да-да, именно чтение и запись, это не оЧепятка ;) !!!) через Actifio с основной и единственной на всех БД и её инкрементами. Или, если вы не хотите нагружать её чтением, с единственным зеркалом для разработки/препрода/тестов и иных полезных задач.

То есть, допустим, разработчики говорят: нам нужна тестовая БД для быстрой выкатки нового функционала. ОК. Заходим в GUI Actifio, нажимаем раз пять-шесть мышкой и делаем провижн виртуальной БД (VDB), которая является клоном продуктивной БД. Таких клонов (VDB) может быть сколь угодно много. VDB готовится из одной-единственной копии продуктивной БД. И эта копия БД постоянно обновляется (догоняет) информацией из продуктивной БД (по графику, который можно установить произвольным образом).

У нас среднее время от тикета до предоставления базы 30 минут.

Actifio ещё можно использовать для задач Disaster Recovery:

Ну и бекапа и восстановления БД соответственно примерно так же.

Как выглядят интерфейсы?

Вот так. Процесс создания виртуальной БД (VDB):

Слева выбираем необходимый снэпшот для создания виртуальной БД (VDB) и нажимаем кнопку Mount (внизу справа):

Заполняем необходимую информацию о создаваемой VDB и нажимаем кнопку Submit. Процесс создания VDB начался, он займёт минут 1520:

Сам процесс создания VDB можно контролировать:

Собственно, всё.

Практика

У нас было так: сначала просишь железячников подготовить сервер, потом стораджиста, инженера, подготовить сторадж, сетевика подключиться к вопросам и так далее. Потом надо сделать копии этой базы, перетащить её на целевой сервер, где будут работать разработчики, развернуть эту базу, скоммутировать её со стораджем. Иногда при этом ещё нужно покупать саму хранилку (железо). А это тендер и прочие радости. Теперь мы берём, один раз делаем копию продуктивной базы, потом запускаем процедуру обновления вот этой базы. Клон базы используется как источник для всех остальных команд, он связан с основной базой асинхронной репликации или репликацией по типу бекапа (по ночам, например). Все команды работают с одним этим клоном независимо друг от друга.

Мы разворачиваем Актифио обычно в виртуальной среде заказчика, к которой подсоединён сторадж, где будет храниться основной клон. Обычно это железо из тестового, то есть либо доживающее свой пятый-шестой год, либо из недорогих. Хоть там и будет копия продуктовой базы, продуктовой нагрузки не будет, поэтому можно брать самые дешёвые хранилки. Дальше делается первая большая репликация, то есть фактически пишется этот самый клон в сторадж. Потом из основной базы делаются инкрементальные а-ля бекапчики по ночам.

От клона в разные стороны торчат тестовые инстансы, где команды могут полноценно работать с базой. Каждая запись хранится как инкремент для этого инстанса, то есть каждый работает со своей версией базы и может там менять что хочет, но база типа 15 ТБ занимает с 22 нашими инкрементами в районе 20 ТБ (потому что там ещё включён дедуп, который не используется на проде из-за хайлоада).

Разворачивается на Linux, UNIX, Windows. Нужно проверить версию операционки и версию СУБД, но всё популярное подходит. С легаси может не срастись.

Это всё в эксплуатации уже больше пяти лет.

С какого момента это окупается?

Обычно с баз от 3 ТБ и четырёх команд. Мы начали использовать на базе 6 ТБ и шести команд у себя лет пять назад.

Актифио не единственное решение, но построены они плюс-минус одинаково. Есть, конечно, ещё другие варианты, которые построены на подмножестве данных, которые как бы распиливают большую базу на много маленьких, с которыми работают команды, но при условии примерно одинаковой стоимости лицензий мы выбрали именно решение Actifio. Поднимается и проверяется всё за пару недель, маны стали простые и теперь уже с картинками.

Подробнее..

Категории: Анализ и проектирование систем , Администрирование баз данных , Обзор , Хранение данных , Инфраструктура , Блог компании крок , Субд , База данных , Инкременты , Actifio , Актифио , Виртуальные базы данных

Разработка инфраструктуры вождения автомобилей высокой автономности (HAD)

12.03.2021 10:04:49 |

Автор: admin

Технологии автономных автомобилей способны совершить настоящий переворот в транспортной отрасли и оказать существенное долгосрочное влияния на образ нашей жизни, работы и бизнеса: они могут снизить количество жертв дорожно-транспортных происшествий, разгрузить дорожную сеть и высвободить время. Кроме того, в этом случае появятся новые транспортные парадигмы, включая автономные такси и модели перевозка как услуга с автомобилями совместного владения. Продукты и услуги из области автономного вождения также включают автоматическую парковку и автоматическое техобслуживание. Преимущества образуются и в таких областях, как использование земли и городское проектирование, поскольку по дорогам перемещается меньше автомобилей. При этом обеспечивается существенная экономия за счет более эффективного использования топлива и снижения эксплуатационных расходов.

1. ВВЕДЕНИЕ

Помимо преимуществ у автономных автомобилей есть и немало серьезнейших проблем.

Водить даже обычный автомобиль бывает очень непросто, но ситуация дополнительно осложняется, если нужна автоматическая отказоустойчивая система, способная работать в любых условиях вождения с крайне низкими показателями допустимых ошибок. Автономные автомобили образуют и потребляют огромные объемы данных. При этом в новом отчете прогнозируется рост глобального рынка автомобилей с сетевыми возможностями на 270% к 2022 году. Предполагается, что к 2022 году будет продано свыше 125 миллионов пассажирских автомобилей с возможностями сетевого подключения [1].
Суммарные расходы на разработку автономных систем вождения могут достигать миллиардов долларов, при этом стоимость оборудования одного автомобиля всем необходимым для полностью автономного вождения также будет весьма велика и может достигать 100 тысяч долларов [2].
Потребуется модернизация инфраструктуры. Может потребоваться переделать дороги, чтобы обеспечить безопасность и согласованность условий для новых типов автомобилей. Достижение такого уровня согласованности на международном уровне или хотя бы в пределах городов будет непростой задачей.
Также необходимо учитывать нормативно-правовые аспекты и вопросы ответственности. Например, если из-за автономного автомобиля возникнет авария, чья будет вина: водителя, производителя автомобиля или компании, разработавшей программное обеспечение для автономной езды?
Необходимо обучение и информирование потребителей, чтобы дать им возможность принимать решения и не реагировать на слухи, мифы и ошибочные представления об отрасли и технологии автономных автомобилей.

Во все времена существования автомобилей именно технологии определяли самые современные возможности безопасности. С 70-х годов автопроизводители стали выпускать подушки безопасности, что позволило избежать множества человеческих жертв. Применение антиблокировочных тормозных систем, которыми автомобили оснащаются с 90-х годов, привело к снижению столкновений без человеческих жертв на 6-8% [3]. Тем не менее почти 1,3 миллиона человек ежегодно становятся жертвами дорожно-транспортных происшествий [4].

Передовые достижения в области высокопроизводительных вычислений и машинного обучения, использование новых технологий в датчиках (например, лидары технология получения и обработки информации дистанционного зондирования с помощью активных оптических систем (лазеров), использующих, в том числе, явления отражения света от поверхности Земли с проведением высокоточных измерений X, Y, Z координат) и мощные вычислительные системы периметра открывают новую перспективу снижение количества человеческих жертв в дорожно-транспортных происшествиях за счет реализации автономных автомобилей.

По мере роста экономики и урбанизации все более остро встает проблема перегруженности дорожных сетей. Средний городской житель проводит на дороге 40 минут в день. Таким образом, за год такой житель тратит 167 часов (свыше четырех полных рабочих недель) на сидение за рулем, и в течение этого времени он не может обращать внимание ни на что иное, кроме собственно вождения автомобиля.

Беспилотные автомобили будут играть важную роль в будущем умных городов и повлияют на построение и устройство городской инфраструктуры. В настоящее время только в США свыше 700 миллионов выделенных парковочных мест, занимаемая ими общая площадь сравнима с площадью всего штата Коннектикут. Автомобиль в среднем занимает парковочное место в течение всего 4% времени, тогда как при использовании беспилотных автомобилей коэффициент использования возрастает до 75% [5]. По этим причинам автономные автомобильные парки станут важным компонентом в умных городах будущего.

Распространение автономных автомобилей и транспортных решений совместного пользования может повлечь объединение бизнес-моделей агрегаторов такси и каршеринга.

Отчет, опубликованный компанией Allied Market Research, гласит, что объем глобального рынка автономных автомобилей составил 54,23 млрд долларов в 2019 году, а к 2026 году может вырасти до 556,67 млрд долларов, при этом совокупные темпы годового роста с 2019 по 2026 год составят 39,47% [6]. Для систем вождения высокой автономности (HAD) и полуавтономных функций в расширенных системах помощи водителям (ADAS) требуется платформа, способная получать и обрабатывать данные как в ядре, так и на границе сети. Высокопроизводительные решения HPE для хранения и архивации данных повышают надежность развертывания, обеспечивают защиту данных и их готовность к анализу. Множество решений HAD могут предоставляться по модели как услуга или по другим моделям потребления с оплатой по мере использования. Именно в этой области действуют решения пакета HPE GreenLake, упрощая обслуживание ИТ-инфраструктуры и сохраняя конфиденциальность и контроль над ней.

В этой статье рассматриваются проблемы HAD, включая составные части процесса разработки автомобилей с высоким уровнем автоматизации и автономности.

1.1. Общие характеристики задачи

Составные части процесса разработки автономного автомобиля

Обнаружение. Решения HAD опираются на технологии автомобильных встроенных датчиков. Основные датчики: спутниковая система геопозиционирования (GPS), блок инерциальных датчиков (IMU), камеры, лидары, радары, ультразвуковые источники, а также различные датчики, установленные внутри автомобиля и в его силовом агрегате. Некоторые технологии уже широко применяются (например, GPS и камеры), тогда как другие (например, лидары) в настоящий момент достаточно дороги, однако по мере развития автономных автомобилей такие системы будут становиться дешевле и компактнее. Таким образом, на первом этапе необходимо преобразовать объем данных, поступающих от всего комплекса датчиков автомобиля, в подробное представление окружающей обстановки.
Понимание. Модели машинного обучения в автомобиле (граница сети) и в подключенных центрах обработки данных (ядро) проводят сопоставление картины, поступившей от датчиков, с известными и заранее обработанными сценариями (например, плотный поток автомобилей на дороге дождливым днем, автомобильная стоянка ночью). Принятие решений автомобилем будет частично основываться на моделях, которые используются для понимания окружающей обстановки и обеспечения безопасности. По мере поступления новых данных автомобиль должен сопоставить их с уже обработанными и использовать результирующий поток данных на следующих шагах для принятия решения.
Распознавание объектов. На этапе обнаружения выделяются объекты вокруг автомобиля: другие автомобили, дорожная разметка, знаки дорожного движения, пешеходы, маршруты движения и т. п. Цель обнаруживать окружающие объекты и на основании этих данных строить картину окружающей обстановки, причем как при наличии карты высокого разрешения, так и на новой неизвестной местности. Разумеется, важно и обнаружение знаков дорожного движения, и обмен информацией между автомобилем и инфраструктурой, а также с другими автомобилями (V2X).
Восприятие. Для восприятия требуется передать модели новые собранные данные для распознавания объектов и их взаимоотношения с более крупными областями вокруг автомобиля. Компоненты этого этапа: локализация (где автомобиль?), контекстуализация (какая вокруг обстановка, возможно с использованием карт высокого разрешения?), распознавание объектов (интеграция данных с лидаров и с других датчиков) и отслеживание объектов (с помощью интеллектуальных моделей).
Принятие решения. Решение это подготовка к действию. Что автомобиль должен сделать? Повернуть? Затормозить? Продолжить ехать прямо? Бортовой компьютер автомобиля принимает решения на основе данных с датчиков, обработанных в контексте окружающей обстановки. Модели обучаются с помощью алгоритмов машинного обучения и огромного объема данных, полученных с комплексов автомобильных датчиков. это позволяет создать алгоритмы, способные предсказывать потенциальные события на основе поступающей в реальном времени ситуативной информации. После этого можно применять логические схемы для определения предпочитаемой последовательности действий. Основная цель состоит в составлении стратегии вождения: уклонении от препятствий, планировании поведения, управлении на основе данных GPS, планировании маршрутов, прогнозировании явно незафиксированных событий.
Действие. После принятия решения о дальнейших действиях автомобиль должен как можно быстрее приступить к их выполнению. Здесь требуется программный анализ, поскольку важно составить правильный план действий в зависимости от внешней обстановки. Если нужно, допустим, повернуть автомобиль влево, то летним днем на сухой дороге условия для этого будут совсем не такими, как зимой на скользкой дороге. Производители автомобилей уже делают шаги на пути к решению этой задачи: они уже сейчас предлагают функции помощи при перестроении и адаптивный круиз-контроль. Тем не менее по-прежнему очень непросто заставить систему управления правильно настроиться на внешнюю обстановку, в которой находится автомобиль.

От описания составных частей системы HAD перейдем к описанию ее важнейших компонентов. Данные с датчиков обычно собираются измерительными блоками в багажниках автомобилей. Первая задача при тестировании HAD заключается в выгрузке данных и в сохранении их в станции сбора данных (она также называется станцией отправки или станцией буферизации). Главное хранилище данных, как правило, представляет собой гибридное облачное решение с комплексом компонентов, по большей части расположенных в центре обработки данных (ЦОД) с возможностью использования облачных ресурсов при пиковой нагрузке.

Высокоуровневый вид компонентов разработки полного цикла системы HAD

В зависимости от сложности автомобиля и от степени использования программной эмуляции тестирование при разработке решений HAD обычно включает три этапа.

Модель в контуре управления (MIL). Тестирование модели системы и операционной среды без проведения тестов на оборудовании HAD (часто выполняется на обычных рабочих станциях). Проверка MIL обычно проводится на ранних этапах цикла разработки.
Программное обеспечение в контуре управления (SIL). Испытание и проверка автоматически созданного кода, используемого в контроллере системы. Тестирование SIL часто происходит в сэмулированной среде, также без проверки на системном оборудовании HAD.
Оборудование в контуре управления (HIL). Тестирование и проверка системного оборудования HAD для выявления всех ошибок в архитектуре оборудования или вызванных используемым компилятором.

Данные, полученные от различных датчиков, используются для разных целей. Видеоданные можно хранить вместе с данными трансмиссии или информацией с лидара. Файлы данных хранятся на общем хранилище и используются для обучения моделей ИИ, а также для тестирования программного обеспечения и оборудования в контурах управления (SIL и HIL). Разработчики внешних датчиков используют эти данные для тестирования и усовершенствования автомобильных датчиков.

2. УРОВНИ АВТОНОМНОСТИ

В соответствии с подходом SAE (Society of Automotive Engineers), который поддерживается Национальным управлением по безопасности движения автотранспорта США (NHTSA), автономность автомобилей определяется по шестиуровневой иерархии (с Уровня 0 по Уровень 5).

Уровень 0. Без автоматизации. Автомобилем всегда управляет только человек. При этом автомобиль может быть оснащен определенными системами предупреждения, но задача динамического вождения полностью выполняется человеком.
Уровень 1. Помощь водителю. Автомобиль может выполнять определенные задачи, такие как замедление и ускорение, с помощью информации, полученной из окружающей среды. При этом человек должен всегда контролировать автомобиль и выполнять задачу динамического вождения.
Уровень 2. Частичная автоматизация. Автомобиль может совершать маневры (перестраиваться из ряда в ряд), ускоряться и замедляться. При этом человек по-прежнему постоянно контролирует движение автомобиля и выполняет все остальные аспекты задачи динамического вождения.
Уровень 3. Условная автоматизация. Автомобиль выполняет все аспекты задачи динамического вождения, но человек должен быть способен вмешаться в управление при необходимости.
Уровень 4. Высокая автоматизация. Автомобиль выполняет все аспекты задачи динамического вождения и может принимать решения, даже если человек не отреагирует на запрос на вмешательство. Тем не менее это возможно лишь в определенных условиях вождения, например при совместных поездках в городской местности или в регионах, для которых составлены подробные карты.
Уровень 5. Полная автоматизация. Автомобиль выполняет все аспекты задачи динамического вождения на всех дорогах и в любых условиях, в которых в современной обстановке может вести машину человек.

Классификация уровней автономности HAD, установленная Обществом автомобильных инженеров США (SAE) [7: https://www.sae.org/standards/content/j3016_201806/]

Последние инвестиции и корпоративные приобретения свидетельствуют об интересе отрасли к разработке HAD и о стремлении как можно скорее добиться автономности Уровня 5. Корпорация Ford инвестировала 1 миллиард долларов в Argo AI [8]. Корпорация GM инвестировала средства в Lyft и приобрела Cruise Automation [9]. Корпорация Volvo создала совместное предприятие с Uber [10]. Корпорация Uber приобрела Otto [11]. Корпорация Intel инвестировала 15,3 миллиарда долларов для приобретения Mobileye [12]. Корпорации Hyundai и Toyota объявили о собственных инвестициях в исследования и разработку HAD. Это лишь небольшая, но достаточно репрезентативная выборка деятельности в этой весьма динамичной отрасли.

Некоторые производители рассматривают концепцию автономные автомобили как услуга и предполагают, что такая модель станет важным источником доходов. Автомобили Уровня 3 станут ключевым звеном для тестирования технологий и позволят решениям HAD выйти на массовый рынок.

Инициатива достижения Уровня 5 набирает все большие обороты. Тем временем крупнейшие автопроизводители осваивают направление автономных автомобилей самостоятельно либо заключают партнерские соглашения с другими компаниями, разрабатывающими такие программы. Все производители по-разному подходят к решению проблемы. Компания Waymo (принадлежит корпорации Alphabet/Google) объявила, что интересуется только Уровнем 5. Другие компании, такие как Uber и Ford, готовятся к Уровню 4 [13]. Корпорации Daimler и Bosch объявили [14] о планах разработки автономных автомобилей Уровней 4 и 5 с возможным стартом производства к началу следующего десятилетия. Другие компании выбрали последовательное развитие: по мере совершенствования технологий HAD они проходят каждый из уровней.

3. СБОР, ПРЕОБРАЗОВАНИЕ И АНАЛИЗ ДАННХ

Чтобы объединить все составные части инфраструктуры HAD, требуется организовать передачу больших объемов данных из автомобиля в центр обработки данных и в обратном направлении. Установленные в автомобиле (на границе сети) камеры, лидары и другие датчики генерируют огромные объемы данных, а в центре обработки данных производится обучение моделей ИИ и их настройка для принятия решений в реальном времени во время езды.

Поток данных от набора датчиков одного автомобиля составляет в среднем 33 Гбит/с, это примерно 120 ТБ данных за 8-часовую поездку. Технологии еще находятся на этапе разработки, поэтому в силу действующих правовых норм потребуется хранить весь объем данных с автономных автомобилей. Однодневный тест-драйв парка из 80 автомобилей это около 10 ПБ исходных данных. Следовательно, небольшой парк автомобилей будет генерировать от 100 до 500 ПБ данных в день.

3.1. Основные принципы

Кроме наличия гибкой, масштабируемой и высокопроизводительной файловой системы при создании среды исследований и разработки HAD необходимо создать возможности для параллельной разработки, моделирования и тестирования одновременно множеству разработчиков и команд разработки. Для поддержки этих потребностей со стороны разработчиков HPE может предоставить среды разработки, работающие по облачному принципу и расположенные как можно ближе к данным как в ядре, так и на границе сети.

В этих средах крайне важно свести к минимуму перемещения данных и разместить вычислительные мощности рядом с данными. Кроме того, необходимо обеспечить возможность быстрого планирования и общего использования вычислительных ресурсов и ускорителей, чтобы повысить эффективность использования среды. В такой обстановке могут оказаться полезными решения платформа как услуга и программное обеспечение как услуга, а также контейнеры с их возможностью быстрого развертывания для выполнения определенных задач.

Существуют инструменты для построения конвейеров непрерывной интеграции/непрерывной разработки (CI/CD), предоставляющие возможность гибкого и эффективного тестирования и разработки алгоритмов.

4. ПОИСК КОМПЛЕКСНОГО РЕШЕНИЯ HAD

Для систем HAD уровней 3 и 4 требуются современные информационные технологии. Корпорация HPE является одним из ведущих мировых поставщиков решений в области высокопроизводительных вычислений, предлагая мощнейшие решения своим заказчикам, имеющим самые сложные вычислительные задачи.

Конечная цель (уровень 5) в реализации автономных автомобилей повсеместно доступный каршеринг, причем все без исключения люди, находящиеся в автомобиле, являются его пассажирами (а не водителями), а часть пути автомобиль может проезжать вообще без людей в салоне. При этом автомобили будут обмениваться данными друг с другом, постоянно предупреждая о своих намерениях и ходе движения по маршруту. Для этого будут использоваться технологии беспроводной связи, такие как Wi-Fi и 5G.

Пока такой уровень автономности не достигнут, для вождения и тестирования на уровнях 3 и 4 по-прежнему требуется мощная платформа для сбора, получения, преобразования, хранения и потребления данных. В этой инфраструктуре данные поступают от датчиков в автомобильный регистратор данных. Затем через бортовое хранилище данные поступают на станцию сбора данных. Оттуда данные передаются в озеро данных, где они преобразуются и подготавливаются к анализу и потреблению.

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

Потоки данных в системе HAD

Высокоуровневый вид компонентов разработки системы HAD

4.1. Регистрация данных

Бортовое оборудование тестовых автомобилей собирает данные, поступающие от датчиков, и сохраняет их, при этом скорость потока данных может превышать 30 Гбит/с. Например, если эксплуатационный парк из 80 автомобилей собирает 18 ТБ данных за 8-часовую смену при скорости 5 Гбит/с в каждом автомобиле, за всю смену будет сгенерировано 1,44 ПБ сырых данных. сли же такой же автомобильный парк генерирует данные на скорости 30 Гбит/с в каждом автомобиле, за смену будет создано 8,64 ПБ данных.

Для таких высоких скоростей данных рекомендуется конвергентная система для границы сети HPE Edgeline EL8000. Это универсальная модульная конвергентная платформа, объединяющей вычислительные ресурсы и ресурсы хранения данных, и допускающая подключение датчиков. Системы HPE EL8000 могут работать в более жестких условиях окружающей среды, чем стандартное ИТ оборудование, и поддерживают удаленное управление. HPE EL8000 это идеальный регистратор данных, представляющий собой интегрированное расширение центра обработки данных.

Система HPE EL8000 может принимать десятки гигабит данных в секунду от лидаров, радаров и видеопотоков, это практичная конвергентная автомобильная вычислительная платформа для тестирования и разработки. Каналы ввода-вывода шины PCIe в системах HPE EL8000 связаны напрямую с ЦП, обеспечивается непосредственный доступ к внутренней шине ЦП. Таким образом, данные напрямую движутся в память и из памяти, а также в кэш процессора и в другие устройства PCIe.

HPE EL8000 это не просто модуль хранения данных. Эта система поддерживает 64-разрядные ЦП x86 и специализированные ускорители вычислений, в том числе видеоускорители (GPU) и П ИС. В этом отношении HPE EL8000 представляет первый шаг конвейера преобразования данных. HPE EL8000 может устранить одно из узких мест потока данных за счет автоматической разметки содержимого тегами на лету. При этом снижается объем необходимых операций предварительной обработки.

4.2. Получение данных

Существует два способа выгрузки данных.

Замена физических носителей. Система HPE EL8000 оборудована накопителями с поддержкой горячей замены; можно вставлять накопители в автомобильную систему и извлекать их. При этом в качестве носителей данных используются твердотельные накопители, чтобы свести к минимуму риск потери данных при манипуляциях и транспортировке. Носители информации передаются в местный центр сбора информации, информация с них считывается и по высокоскоростным каналам передачи данных передается в ЦОД.
Выгрузка данных по высокоскоростным локальным сетям в станции сбора данных или центры обработки данных. В этом случае для выгрузки данных с автомобилей в станции сбора данных используется локальная сеть. Станции сбора данных расположены в центрах обработки данных, где автомобили подключают непосредственно к сети ЦОД. После подключения автомобили выгружают данные в указанные целевые системы по каналам с пропускной способностью 100 Гбит/с.

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

Станция сбора данных не только осуществляет буферизацию, но и служит первой точкой определения приоритета данных. В любом тест-драйве большая часть данных с высокой вероятностью не будет содержать важных событий и не будет представлять немедленной ценности для процесса разработки. Тем не менее некоторые события будут очень важны для разработчиков. Для таких случаев на станции сбора данных проводится приоритетная отправка, что дает возможность быстрее высвободить автомобиль и предоставить разработчикам самые важные данные в первую очередь. Разработчики могут применять различные алгоритмы определения приоритета, для которых могут потребоваться и более мощные вычислительные ресурсы, чем есть в HPE EL8000.

Различные файловые системы. Производительность и масштабируемость

4.3. Озеро данных

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

Параллельные файловые системы, такие как Lustre, поддерживают линейное масштабирование решений. Система Lustre дает возможность создавать компоненты заданного размера и производительности, а также позволяет с высокой гибкостью добавлять дополнительные компоненты по мере необходимости. На рынке есть очень немного решений, обладающих такой надежностью, производительностью, высокой емкостью и масштабируемостью на этом ценовом уровне.

Для параллельных файловых систем также доступны программные интерфейсы доступа по традиционным файловым протоколам систем POSIX, а также интерфейсы Hadoop, традиционные для Больших данных.

Некоторые клиенты пользуются другими распределенными крупномасштабными средами, включая Hadoop Distributed File System (HDFS), Ceph и даже решения, совместимые с S3. Например, HDFS работает на стандартном оборудовании и легко масштабируется. HDFS также назначить разные уровни хранения данных в зависимости от их температуры. Самые горячие данные, к которым требуется быстрый доступ, размещаются на самых быстрых накопителях, а холодные данные на менее скоростных дисках. Такой подход дает возможность создать озеро данных с невысокими затратами и оптимизировать систему с точки зрения важности данных и потребности в них.

4.4. Методики Программное обеспечение в контуре управления (SIL) и Оборудование в контуре управления (HIL)

В отчете, опубликованном в 2016 году [15], корпорация RAND подсчитала, что для снижения количества ДТП со смертельным исходом на 20 % автономные автомобили должны проехать около 11 миллиардов миль. сли использовать парк из 100 автомобилей, которые ездят круглосуточно 365 дней в году со средней скоростью 25 миль в час, для выполнения этой задачи потребуется 518 лет. Очевидно, требуется другое решение.

Для решения этой задачи компании, занимающиеся разработкой автономных автомобилей, применяют методики SIL и/или HIL, ускоряющие тестирование.

Корпорация HPE располагает опытом создания и поставки систем моделирования для автомобильных компаний во всем мире. В этих решениях HPE обычно использует шасси HPE Apollo 2000 Gen10 с серверами HPE XL170r для вычислений с использованием центрального процессора и с серверами HPE XL190r для вычислений с использованием видеокарт (GPU).

Индивидуальные рабочие процессы SIL создаются на основе системы контроля и управления (CMS). Система CMS поддерживает планирование событий по времени и обработку очередей действий, которые будут выполняться параллельно в зависимости от наличия свободных ресурсов.

Размещение систем SIL вместе с системами хранения данных обеспечивает более высокую гибкость по выполнению требований к пропускной способности, необходимых для оптимальной работы SIL. Возможна организация доступа к системам SIL из любой точки мира для поддержки инженеров из разных стран.

Модель Оборудование в контуре управления (HIL) также можно интегрировать в основную сеть ЦОДа для организации высокоскоростного доступа к озеру данных. Поскольку требуется очень высокий уровень производительности, для конфигурации HAD предпочтительно использовать высокоскоростные среды передачи данных, такие как InfiniBand и Intel Omni-Path. Также стоит предусмотреть дополнительные каналы Ethernet 10 Гбит/с для реализации глобальной связности и индивидуальных проектов HIL.

4.5. Архивация и резервное копирование

Для создания системы HAD может потребоваться немало тестовых автомобилей, каждый из которых ежедневно генерирует терабайты данных. Легко заметить, что такой автомобильный парк может быстро создать сотни петабайт данных. При этом данные после их получения необходимо очищать, разделять и преобразовывать, создавая разные версии (в разных форматах) одной и той же информации.

Кроме того, в силу действующего законодательства и собственных политик, компании может также потребоваться архивация и резервное копирование данных. Для длительного хранения данных корпорация HPE предлагает решение Data Management Framework (DMF). Это иерархический диспетчер хранения данных с более чем 20-летней историей успешной эксплуатации. HPE DMF автоматически отслеживает свободное пространство в управляемой файловой системе. За счет этого гарантируется наличие необходимого свободного места, а системные администраторы избавляются от рутинной необходимости постоянно отслеживать загрузку ресурсов хранения данных и добавлять новые.

HPE DMF сохраняет информацию о метаданных и о данных предыдущих версий файлов, поэтому администраторам доступна полная история эволюции и полное содержимое файловых систем; можно вернуться к любому моменту и восстановить любые данные. При обращении к истории версий можно восстанавливать как файловые системы целиком, так и их фрагменты, указав необходимую точку во времени.

Ленточное решение HPE DMF построено на основе ленточной библиотеки HPE TFinity ExaScale на базе технологии Spectra. TFinity ExaScale это самая вместительная в мире отдельно стоящая система хранения данных [16]. Одна библиотека TFinity EE способна хранить до 53 450 ленточных картриджей на 44 шкафах.

При использовании технологии сжатия TS1150 емкость системы превышает 1 эксабайт. Благодаря решению Dual Robotics и 72 накопителям LTO-8 скорость записи достигает примерно 21 ГБ/с, а емкость 100,2 ПБ при использовании картриджей 8350 LTO-8 (четыре дорожки).

5. УСЛУГИ И РЕШЕНИЯ ПАРТНЕРОВ

Корпорация HPE занимает ведущую долю на рынке высокопроизводительных вычислений и обладает широчайшими возможностями для реализации решений HAD с самыми высокими требованиями к вычислительным ресурсам, системам хранения данных и сетевым ресурсам.

5.1. Создание

Организация HPE Pointnext Services создает полнофункциональную платформу для клиентов от центра обработки данных до конечных устройств (в данном случае это станции сбора данных и автомобильные регистраторы данных) и вплоть до готовых приложений для разработчиков. В зависимости от потребностей и целей клиента специалисты HPE Pointnext Services в области ИИ и обработки данных помогут:

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

5.2. Выполнение

Запуск в эксплуатацию налагает требования по необходимому уровню операционной поддержки для всех компонентов, чтобы обеспечить оптимальную доступность для поддержки бизнеса. Предоставляя услуги операционной поддержки HPE Pointnext Services, корпорация HPE может помочь в реализации операционных задач системы HAD.

Услуги адаптивного управления HPE являются составным компонентом решений HPE GreenLake: ИТ-услуги предоставляются по модели с оплатой за использование. Эта платформа позволяет решать эксплуатационные задачи для инфраструктуры компании, включающей серверы, системы хранения данных, сети, инфраструктурные программные решения, гипервизоры, системы резервного копирования и восстановления данных, а также средства безопасности, а также межплатформенное и прикладное ПО, разработанное компанией HPE и определенными сторонними поставщиками.

5.3. Потребление

Если вам требуется гибкость и полный контроль в локальной среде или публичном облаке, воспользуйтесь предложением HPE GreenLake это набор ИТ-решений с оплатой по фактическому потреблению. Предлагаем каталог полных проверенных решений, позволяющих добиться нужных результатов в области ИТ с использованием оборудования, программного обеспечения и знаний на ваших площадках по модели с оплатой за использование.

5.4. Партнеры

При разработке решений HAD могут возникать этапы, когда партнерами HPE могут становиться не только наши конечные потребители, но и другие организации (в целях создания лучших платформ и служб для HAD). Пример такого партнерства транспортировка носителей с информацией, собранной в процессе тест-драйва. В месте проведения тест-драйва пропускная способность сетевого подключения может оказаться недостаточной для отправки данных. В партнерстве с курьерской службой мы можем обеспечить доставку носителей информации в ближайшую станцию сбора данных в кратчайшие сроки.

Партнерство может работать в различных формах. Возможно, что у клиента уже есть поставщик ИТ-услуг и заказчик хотел бы реализовать платформу HAD силами этого же поставщика. Как вариант, клиентов заинтересует сотрудничество HPE с этими поставщиками услуг, чтобы обеспечить плавный и эффективный переход от этапа создания решения к этапу его использования. Корпорация HPE вместе с поставщиками услуг предлагает конечным потребителям создание и выполнение услуг, созданных HPE в содружестве с другими разработчиками. Каждый партнер привносит собственные услуги в экосистему и обеспечивает всестороннее обслуживание клиента.

6. ЗАКЛЮЧЕНИЕ

В дорожно-транспортных происшествиях во всем мире ежегодно гибнет около 1,35 миллиона человек. Аварии на дорогах обходятся большинству стран в 3% их внутреннего валового продукта. От 20 до 50 миллионов человек получают несмертельные травмы, часто приводящие к нетрудоспособности [18].

Автомобили высокой автономности стремительно растущий рынок, цель повышение безопасности и здоровья общества. По оценкам специалистов, если распространение автономных автомобилей достигнет 10, 50 и 90%, это может привести к снижению числа человеческих жертв соответственно на 1100, 9600 и 21 700 человек в США за год [19].

Разумеется, HAD непростая задача. Для ее решения требуются самые передовые и совершенные технологии, доступные на рынке в настоящее время, включая нейросети машинного обучения и глубинного обучения, современные ускорители вычислений, высокопроизводительные сети и среды передачи данных.

Предложения HPE позволяют удовлетворить потребности автомобильной промышленности в современных решениях ИИ и высокопроизводительных вычислений для облачных развертываний HAD. При этом клиенты могут приобрести и эксплуатировать решения самостоятельно, а также заключить договор с HPE (используя HPE Pointnext Services, HPE GreenLake и другие предложения услуг) и поручить нашей корпорации обработку некоторых или всех вычислительных задач для HAD. Корпорация HPE предлагает полный ассортимент вычислительных систем, сетевых решений, систем хранения данных и технической поддержки и услуг по всему миру, гарантируя, что разработчики уже сегодня могут приступить к созданию оптимальных решений HAD для надежных и безопасных транспортных сетей будущего.

Подробнее..

Категории: Администрирование баз данных , Резервное копирование , Искусственный интеллект , Машинное обучение , Хранение данных , Инфраструктура , Сбор данных , Автомобили , Программное обеспечение , Блог компании hewlett packard enterprise , Высокопроизводительные вычисления , Автономия

HPE Apollo 6500 Gen10 plus часть HPE Cray Supercomputer в вашем ЦОДе

19.03.2021 10:13:30 |

Автор: admin

Открывая будущее высокопроизводительных вычислений и искусственного интеллекта с революционными ускоренными вычислениями, представляем систему HPE Apollo 6500 Gen10 Plus. Это новаторское решение обеспечивает превосходно масштабируемую производительность и произведет революцию в использовании высокопроизводительных вычислений и искусственного интеллекта.

В современной цифровой экономике данные являются движущей силой инноваций. Интеллект меняет способ мышления, взаимодействия и понимания мира. Способность использовать достоверные прогностические данные вот разница между успехом и упущением для бизнеса уже сегодня.

Спрос на высокопроизводительные вычисления и искусственный интеллект резко возрастает, поскольку организации спешат заставить свои данные работать. Для достижения этой цели в ряде отраслей в России наблюдается значительный рост числа внедрений решений для высокопроизводительных вычислений и искусственного интеллекта, чтобы повысить производительность и получить стратегическое преимущество на высококонкурентном рынке. Такие сегменты, как финансовые услуги, здравоохранение и биологические науки, производство, автомобилестроение и розничная торговля по всему миру претерпевают полную трансформацию, поскольку организации вкладывают средства в передовые возможности и инструменты, помогающие им работать быстрее и разумнее.

Гибридные (с использованием специализированных ГПУ) вычисления обеспечивают отлично масштабируемую производительность, а также более быструю и надежную вычислительную мощность для оптимизации самых требовательных рабочих нагрузок высокопроизводительных вычислений и искусственного интеллекта. Не так давно HPE объявило о новаторском дополнении к портфелю HPE Apollo, которое выводит гибридные вычисления на новый уровень. Система HPE Apollo 6500 Gen10 Plus следующее поколение в этой линейке продуктов, которое выведет использование высокопроизводительных вычислений и искусственного интеллекта на новый практический уровень.

Система HPE Apollo 6500 Gen10 Plus специально создана для обеспечения большой ценности для заказчиков:

система позволяет производить более быстрый анализ для получения конкурентного преимущества, позволяющий лучше использовать данные;
cистема обладает лучшей производительностью за счет тесной связи вычислительной мощности с лучшими в отрасли графическими процессорами для предоставления максимальной производительности для решаемых задач;
полностью протестированное и настроенное решение HPE, сертифицированное NVIDIA и предназначенное для требовательных рабочих нагрузок высокопроизводительных вычислений, искусственного интеллекта, машинного обучения и глубокого обучения;
архитектура HPE Cray Supercomputer теперь включает систему HPE Apollo 6500 Gen10 Plus в качестве узла в ее версии с воздушным охлаждением, в сочетании с интерконнектом HPE Slingshot и поддерживаемой HPE Cray Operating System.

Для снижения нагрузок на устаревшую инфраструктуру и расширения возможностей для инноваций на основе обработки данных, система HPE Apollo 6500 Gen10 Plus использует вычислительную мощность новейших графических процессоров NVIDIA A100 с тензорными ядрами и процессоров AMD EPYC 2-го поколения. Графические процессоры NVIDIA A100 обеспечивают низкую задержку при высокой пропускной способности, чтобы улучшить эти мощные решения для гибридных вычислений. Благодаря тензорным ядрам третьего поколения NVIDIA A100 может эффективно масштабироваться до тысяч графических процессоров или, с помощью технологии NVIDIA Multi-Instance GPU (MIG), может быть разделена на семь изолированных инстансов графических процессоров для ускорения различных рабочих нагрузок. NVIDIA A100 предлагает значительные улучшения в тензорных ядрах и при работе с числами двойной точности, побив многочисленные рекорды по производительности на задачах ИИ и обеспечивая до 4,2 раза более высокую скорость обработки, чем в предыдущих поколениях ускорителей.

Система HPE Apollo 6500 Gen10 Plus обеспечивает максимальное использование графических процессоров (до 16 ГПУ на сервер) для быстрого сбора данных, их интеллектуального анализа и получения результатов, независимо от требований рабочих нагрузок высокопроизводительных вычислений и искусственного интеллекта. NVIDIA NVLink устанавливает бесшовное соединение между графическими процессорами, поэтому они могут работать вместе как единый мощный ускоритель. Интеконнект NVLink обеспечивает выделенную коммуникационную связь, которая позволяет переносить данные памяти с между ГПУ. Один ускоритель A100 поддерживает до 12 подключений NVLink с общей пропускной способностью 600 ГБ/с.

Процессоры AMD EPYC 2-го поколения предлагают огромную пропускную способность и большое количество ядер для непрерывной обработки требовательных к данным графических процессоров. Эти высокочастотные процессоры, интегрированные с NIVIDIA Mellanox HDR InfiniBand, добавляют до 200 Гб/с для полосы пропускания для каждых двух графических процессоров, поэтому даже продуктивные бизнес-системы, работающие в кластере, могут обмениваться данными с вдвое большей скоростью.

Для системы Apollo 6500 Gen10 Plus, HPE представила:

первый сервер оптимизированный для 4-х графических процессоров, который обеспечивает лучшую цену, чем когда-либо для HPC;
обновлённый двухпроцессорных сервер на базе процессоров AMD, который может поддерживать до 16 PCIe ГПУ, что в два раза больше, чем HPE поддерживало в прошлом.

Кроме того, система HPE Apollo 6500 Gen10 Plus предлагает обширные варианты организации подсистемы хранения, включая до 16 устройств хранения с доступом с передней панели, твердотельные диски SAS / SATA и до шести накопителей NVMe для более быстрого доступа к данным при меньшем потреблении энергии. HPE планирует дополнить эти возможности новыми решениями, которые будут включать 16 накопителей NVMe для увеличения пропускной способности почти в 6 раз. Теперь заказчики HPE могут использовать высокую мощность, частоту и вычислительную мощность гибридных вычислений, чтобы значительно сократить время, необходимое для получения аналитической информации.

Система HPE Apollo 6500 Gen10 Plus спроектирована с учетом плотности и гибкости для поддержки широкого спектра приложений HPC и ИИ. Наши решения давно признаны в отрасли благодаря высокой пропускной способности памяти, гибкости и безопасности для обеспечения быстрой передачи данных.

Созданные для эры Эксамасштабных вычислений, системы HPE Apollo 6500 Gen10 Plus еще больше увеличивают производительность для выполнения самых сложных рабочих нагрузок высокопроизводительных вычислений и искусственного интеллекта за счет графических процессоров NVIDIA HGX A100 с тензорными ядрами и интерконнектом NVLink или AMD Instinct MI100 с Infinity Fabric Link 2-го поколения. Суммарная производительность может превышать 100 Терафлопс (FP64). Возможность установки одного или двух процессоров позволяет улучшить баланс процессорных ядер, объема памяти и ввода/вывода. Повышение гибкости системы также достигается за счет поддержки 4, 8, 10 или 16 графических процессоров и широкого выбора операционных систем и предлагаемых опций, приближается к заказному (customized) дизайну, что означает для заказчиков снижение затрат, повышение надежности и удобства обслуживания.

Помимо ускорителей NVIDIA HGX A100 и AMD Radeon Instinct MI100, предлагается широкий выбор графических процессоров PCIe для высокопроизводительных вычислительных систем или искусственного интеллекта.

Система HPE Apollo 6500 Gen 10 Plus может содержать серверы следующих типов:

До двух серверов HPE ProLiant XL645d Gen10 Plus это однопроцессорный сервер с поддержкой 4-х ускорителей NVIDIA HGX A100 или 4-х ускорителей AMD Instinct MI100 или 4-х ускорителей PCIe двойной ширины или 8-ми ускорителей PCIe стандартной ширины;
один сервер HPE ProLiant XL675d Gen10 Plus это двухпроцессорный сервер с поддержкой 8-ми ускорителей NVIDIA HGX A100 или 8-ми ускорителей AMD Instinct MI100 или 10-ти ускорителей PCIe двойной ширины или 16-ти ускорителей PCIe стандартной ширины.

Также поддерживаются различные высокоскоростные фабрики интерконнекта Ethernet, HDR InfiniBand и HPE Cray Slingshot. В качестве опции для повышения эффективности и плотности мощности доступна система прямого жидкостного охлаждения (DLC), которая поставляется с заводов HPE предварительно заполненной, полностью интегрированной, установленной в стойку и готовой к подключению к водопроводу, что способствует сокращению сроков ввода в эксплуатацию, снижению стоимости владения, росту эффективности охлаждения и более высокой плотности по электрической мощности.

Для высокопроизводительных компонентов требуются такие же высокопроизводительные электропитание и охлаждение, обеспечивающие полное резервирование для топовых процессоров и ускорителей с тепловыделением до 500 Вт, благодаря чему ваша система будет готова к текущим и будущим бизнес-задачам.

Удобное для обслуживания и модернизации решение с полным резервированием питания, легкодоступная модульная конструкция, вентиляторы с двойными роторами и возможностью горячей замены, а также фабрика интерконнекта с подключением кабелей к задней панели полностью совместимы со стандартной серверной стойкой глубиной 1075 мм, что обеспечивает быстрое и эффективное развертывание. Доступен и широкий выбор операционных систем, в том числе HPE Cray Operating System, Microsoft Windows Server, Ubuntu, Red Hat или VMware.

В системе HPE Apollo 6500 Gen10 Plus используется технология HPE iLO5 с аппаратным корнем доверия и процессор AMD Secure специализированный процессор для обеспечения повышенной безопасности, встроенный в процессор (систему на кристалле, SOC) AMD EPYC. Конструктивно сервер занимает 6U и изготовлен по модульному принципу. Такая конструкция позволят гибко конфигурировать систему сейчас и дает возможность для будущей модернизации.

Серверная плата позволяет устанавливать процессоры AMD EPYC с термопакетом до 280 Вт и имеет 32 слота для оперативной памяти DDR4-3200. Внутренняя подсистема хранения поддерживает до 16 накопителей малого форм-фактора, либо до 6 SFF NVMe, с удобным доступом на передней панели сервера. Интерфейс PCIe 4.0 позволяет использовать различные высокоскоростные вычислительные фабрики, среди которых Infiniband HDR (200 Гбит/с) и HPE Cray Slingshot.

Система Apollo 6500 Gen10 plus содержит в себе технологии эксамасштабной эры эры в которой производительность систем исчисляется Эксафлопсами (квинтиллионами операций с плавающей точкой). HPE уже строит несколько Эксафлопсных систем в США. Для построения этих систем необходимо было пересмотреть все подходы, которые были применимы для суперкомпьютеров, чтобы преодолеть супер- и выйти за рамки в масштаб Экса. Нами были разработаны продукты для этих суперкомпьютеров и теперь некоторые технологии, которые мы включили в эти продукты, стали доступны для корпоративного рынка, в том числе и в России. Узнать больше про эти продукты и технологии, а также про их применимость в корпоративных ЦОДах можно будет на вебинаре Стимулирование инноваций и инсайты по требованию, который состоится 24 марта в 10:00 по Москве. Зарегистрироваться на него вы можете по этой ссылке.

Подробнее..

Категории: Высокая производительность , Процессоры , Искусственный интеллект , Данные , Инфраструктура , Суперкомпьютеры , Блог компании hewlett packard enterprise , Hewlett packard enterprise , Суперкомпьютер , Высокопроизводительные вычисления , Hpe apollo

Bare-Metal Provisioning инфраструктура с нуля

29.10.2020 20:09:21 |

Автор: admin

Приветствую, Хабр. Меня зовут Роман, я разработчик встраиваемых систем в Getmobit. Хочу поделиться кейсом по развёртыванию программного обеспечения на большом количестве устройств на производственной линии с нуля. Заставлять людей на производстве бегать вдоль конвейера с флешкой не хотелось, а для автоматизации мне необходимо было четко понимать: на какие шаги можно поделить этот процесс, что на каждом этапе должно происходить, а главное как модифицировать стандартный процесс, чтобы в итоге выполнять специфичные для нашего продукта операции. Основой для решения этой задачи стала технология загрузки устройств по сети (PXE). Об этом и расскажу.

На чем разворачиваем?

Bare Metal частью является устройство GM-Box в том виде, в котором его увидят пользователи.

В зависимости от модификации, в состав устройства могут входить разные подключаемые модули (Wi-Fi, LTE и др).
В процессе производства устройства должны пройти функциональные тесты подключенных блоков: например, Wi-Fi находит точки доступа и обеспечивает номинальную скорость, кнопки на устройстве нажимаются и работают, Bluetooth модуль находит устройство с контрольным MAC-адресом и тому подобное.
На всех экземплярах, прошедших тесты, должно оказаться конечное ПО (прошивка).

Немного теории

Preboot eXecution Environment (PXE)

Технология PXE позволяет загружать операционную систему на устройстве с помощью сетевой карты, а в нашем случае загрузку через сеть будет инициировать UEFI.
При этом можно получить информацию о загрузчике (pxelinux, grub и подобные) с помощью DHCP-опций. Это в свою очередь дает гибкость в управлении конфигурациями операционных систем для целевых устройств.
С точки зрения инфраструктуры типовой процесс загрузки с помощью PXE будет выглядеть, как на схеме:

где Device целевое устройство для развертывания ОС и настройки, Provisioning host инфраструктура или отдельно-стоящая машина.
На схеме, Device после включения питания и первоначальной загрузки UEFI запрашивает по DHCP параметры, в которых будет указано имя файла Zero image и где его найти (адрес TFTP-сервера). И далее передает на исполнение полученный образ (например, pxelinux).

Далее происходит загрузка программы из минимального образа (Zero image). С указанного ранее TFTP-сервера программа читает конфигурацию загрузки и исполняет ее. В нашем случае он автоматически загружает Provision agent для дальнейшей установки и передает ему параметры, полученные на предыдущем этапе. Сам агент представляет из себя ядро Linux и initial RAM disk и выполняет сценарий установки. Состав сценария зависит от задачи. В минимальном виде он выполняет следующие операции:

определяет оборудование загруженного устройства
производит разметку диска
производит настройку операционной системы
устанавливает необходимые пакеты

Агентами, например, могут быть preseed, kickstart или самостоятельно собранный дистрибутив со скриптами для развертывания.
После выполнения сценариев развертывания Provision agent автоматически перезагружает устройство.

PXE-less загрузка

Для систем без функции PXE, по классике, можно использовать готовый live-образ на внешнем носителе. Но если вам, например, требуется удаленный мониторинг процесса развертывания или есть зависимость от ресурсов в инфраструктуре, то вместо PXE в схему загрузки может быть добавлен discovery image, который также как live-образ загружается со внешнего носителя, но выполняет лишь функцию доставки provision-агента и далее цепочка загрузки будет идентична схеме.

Подготовка инфраструктуры

Подготовка выглядит достаточно просто для обеспечения каждого этапа необходимыми данными со стороны инфраструктуры потребуются следующие компоненты:

Устройства, поддерживающие PXE
DHCP сервер (например, isc-dhcp-server)
TFTP сервер (например, tftp-hpa)
Хранилище (например, репозиторий Ubuntu или python-пакетов)
Zero image (например, озвученный ранее, pxelinux.0)
Provision agent (ядро Linux и initrd)

В интернете достаточно много практик и инструкций по установке и настройке компонентов п.1-4, поэтому я приведу лишь примеры конфигураций. На схеме ниже представлена инфраструктура, в рамках которой описываются примеры конфигураций. Здесь все сервисы расположены на одном хосте.

Примеры конфигурационных файлов

Конфигурация DHCP /etc/dhcp/dhcpd.conf

option domain-name "provisioner";option domain-name-servers 8.8.8.8;default-lease-time 600;max-lease-time 7200;log-facility local7;authoritative;subnet 192.168.30.0 netmask 255.255.255.0 {  range 192.168.30.100 192.168.30.200;  option subnet-mask 255.255.255.0;  option domain-name-servers 192.168.30.1;  option domain-name "prod.provisioner";  option domain-search "prod.provisioner";  option broadcast-address 192.168.30.255;  # Имя файла-загрузчика  filename "pxelinux.0";  # Адрес сервера, откуда будет браться загрузчик  next-server 192.168.30.1;}

Конфигурация TFTP /etc/xinetd.d/tftp

service tftp{   protocol     = udp   port         = 69   socket_type  = dgram   wait         = yes   user         = user   server       = /usr/sbin/in.tftpd   server_args  = /var/lib/tftpboot   disable      = no}

Получить pxelinux для Preseed 5 и 6 можно здесь и далее расположить его в директории доступной по tftp (в нашем случае /var/lib/tftpboot).
Согласно этим конфигурациям, целевое устройство загрузит pxelinux.0 и далее развернет Provision agent для установки.

Пример настройки для pxelinux

DEFAULT linuxLABEL linux    KERNEL boot/vmlinuz    APPEND initrd=boot/initrd.gz ramdisk_size=10800 root=/dev/rd/0 rw auto console-setup/ask_detect=false console-setup/layout=USA console-setup/variant=USA keyboard-configuration/layoutcode=us localechooser/translation/warn-light=true localechooser/translation/warn-severe=true locale=en_US    IPAPPEND 2

Здесь ядру Linux можно передать дополнительные параметры, указав ссылки на локальные ресурсы и конфигурацию для preseed.

Наконец, как мы это применили

Итак, для решения исходной задачи нам потребуется модифицировать provision agent, ведь перед развертыванием ПО должно быть произведено тестирование аппаратных модулей. Тестирование, в свою очередь, не имеет фиксированного сценария и может варьироваться.
В нашем случае provision agent представляет из себя самостоятельно собранный live-образ со специализированным ПО для тестирования и функцией установки GM Soft Kit в память устройства. Сценарий тестирования текущей конфигурации берется со специального http-сервера.
Используя описанную инфраструктуру, мы можем выстроить производственный процесс, как показано на схеме:

В эту схему хорошо встраивается процесс обновление на производственной линии ПО для установки (continuous delivery), но это отдельная тема.

Подводные камни

Preseed плохо себя показал на масштабировании: при многократных установках одна и та же конфигурация может вести себя по-разному и зависать в неожиданные моменты. Как следствие нам пришлось отказаться от установки дистрибутива в классическом виде, собирать прошивку заранее и сделать свой provision agent, который теперь заливает образ в память устройства по сети.

На первой итерации мы пробовали размещать ядро Linux и initrd на простом http-сервере и сохраняли ссылки на них в pxelinux.cfg при такой конфигурации загрузчик периодически не загружал ядро и намертво зависал. Помогло размещении файлов на том же tftp-сервере, где лежит сам pxelinux.

Вывод

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

Дополнительные материалы

Как один из сценариев развития специальное EFI-приложение wiki.archlinux.org/index.php/Systemd-boot#Preparing_a_unified_kernel_image. Оно может выполнять функции zero image и provision agent одновременно.
О том как настроить PXE-инфраструктуру и как подготовить образ описано здесь habr.com/ru/company/X5RetailGroup/blog/493124

Подробнее..

Категории: Сетевые технологии , Разработка под linux , Инфраструктура , Uefi , Производство электроники , Блог компании гетмобит , Pxe

	Русский
	English