- PVSM.RU - https://www.pvsm.ru -
Недавно в пресс-релизе мы рассказали о том, что запустили Tarantool IIoT [1] — платформу для промышленного интернета вещей. Новость [2] облетела многие электронные издания. Но что такое Tarantool IIoT и как он работает — тема оставалась не до конца раскрытой. Мы решили это исправить. Подробности под катом.
Сначала я напомню, что IIoT — это industrial internet of things (промышленный интернет вещей). Это такая концепция, когда у объектов промышленности появляется доступ в интернет как в сеть и доступ к интернет-сервисам (которые работают в центрах обработки данных — ЦОДах). Давайте посмотрим на рисунок:
Что мы тут видим? Рисунок поделен на две части — «центр» и «на местах».
«Центр» — это ЦОД или облако, т. е. любой облачный IaaS-сервис, в котором можно разворачивать IT-инфраструктуру: Amazon, Azure и т. д.
«На местах» — я, если честно, не знаю, какой правильный термин тут использовать. Уверен, читатели меня поправят и предложат красивое определение. Я лучше расскажу, что имею в виду под «на местах»: в поле (в прямом смысле слова — на агрокультурном поле), на производственной площадке (на заводе, фабрике, металлообрабатывающих, горнодобывающих и нефтегазовых объектах), на ремонтной площадке, на транспорте (в автомобиле, грузовике, ж/д вагоне, локомотиве), на объектах городской инфраструктуры (в местах сбора информации о потреблении электричества и воды, в канализации, вдоль улиц, в объектах освещения), на объектах междугородной инфраструктуры (вдоль шоссе, железных дорог, возможно, линий электропередач). В общем, «на местах» — это везде, куда рука интернета только начинает добираться. Еще можно сказать «в поле», но тогда появляется риск сузить круг промышленного интернета вещей только до агрокультурного поля.
Tarantool IIoT — это распределенная софтверная платформа для сбора информации с датчиков и отправки ее в центр и на локальные системы управления. Tarantool IIoT работает и «в центре», и «на местах», соединяя их в единую информационную сеть. В этой сети максимум логики унесено в софт, поэтому с точки зрения железа она может быть собрана из commodity-компонентов, т. е. не нуждается в специальных поставщиках закрытых проприетарных программно-аппаратных платформ. Стало понятнее? Если нет, то читайте дальше :-)
Под commodity-компонентами имеются в виду легко заменяемые дешевые компоненты. Например, если мы вспомним дата-центры, то с точки зрения их железа commodity — это недорогие серверы, например supermicro или даже полностью самосборные серверы. С точки зрения железа «на местах» это могут быть самые дешевые датчики и IoT-хабы (т. е. маленькие компьютеры на основе ARM).
Внутри своих дата-центров в Mail.Ru Group мы уже достаточно давно почти полностью перешли на commodity-железо. Иногда без фирменной брендовой гарантии и саппорта, зато недорогое и взаимозаменяемое. При этом надежность и производительность обеспечиваются на уровне софта. Если что-то ломается, то это не критично для сервисов, потому что все задублировано и зареплицировано на уровне софта — мы просто спокойно отправляем железо в ремонт. Сроки и вообще возможность починки железа не влияют на непрерывность бизнеса. По такому же пути давно прошли крупные американские IT-корпорации: вся сложность переносится на софт, при этом железо максимально стандартизируется и удешевляется. И теперь мы предлагаем распространить этот подход и на мир IoT.
Спрашивается, зачем места и центр соединять в единую информационную сеть? Ответ такой:
На местах, как вы понимаете, есть своя специфика, отличная от ЦОДа. Оговорюсь сразу, что мы в Mail.Ru Group только в начале пути развития своей IIoT-стратегии и не так давно прощупываем рынок IIoT, поэтому, возможно, пока не до конца понимаем все тонкости. Вот что мы сейчас думаем о специфике. Это:
Что вся эта специфика означает? Что мы не можем строить на заводах, полях, кораблях, городских улицах и прочих объектах то, что мы строим в ЦОДах: ряды одинаковых стоек с серверами внутри, скоммутированные через оптоволокно. Это будет безумно дорого.
А что мы еще не можем? В мире IoT роль серверов играют IoT Hubs — микрокомпьютеры (промышленные аналоги Raspberry PI), которые разбросаны на многих километрах площадок. Между ними оптоволокно тянуть — дорого. И в стойки собирать их тоже дорого, потому что из-за огромных расстояний IoT Hubs слишком много, и предприятия, ограниченные финансово, не могут формировать локальные кластеры из большого количества IoT Hubs. То есть нет локализованных стоек. Есть разбросанное по местности железо. Далее, у предприятий/объектов есть миллионы разбросанных повсюду датчиков (см. выше, о каких датчиках речь), с которых IoT Hubs собирают информацию. Опять же — как ее собирать? Если датчиков мало, то по проводам. А если их миллион, то через радиоканалы (миллион проводов, по проводу от датчика — представляете, какой клубок?).
В итоге, чтобы решение было более-менее cost-effective, вся эта конструкция может выглядеть вот так:
Датчики собирают информацию и отправляют ее на хабы (это не сетевые хабы, просто называются так же: это микрокомпьютеры с маленькой материнкой, процем, памятью и операционкой), хабы передают информацию в интернет (через мобильную связь, Wi-Fi, спутниковую связь, Ethernet и т.п.), и она долетает до ЦОДа. Ровно так же путешествует обратный поток — из ЦОДа на хабы, с хабов на датчики (или на локальные программируемые логические контроллеры).
Идем далее. Еще помните о специфике мира IIoT? Чтобы вся эта конструкция не стоила космических денег, хочется, чтобы:
То есть хорошо бы, иными словами, иметь то, что мы привыкли видеть в ЦОДах: заменяемое недорогое железо, вся логика на уровне софта и весь fault-tolerance на уровне софта.
А теперь давайте обратим взгляд на софт в ЦОДе. Там, кроме операционки, почти всегда используется много других компонентов — СУБД, серверы приложений, системы мониторинга, DevOps-скрипты и системы. И уже поверх этой инфраструктуры пишется бизнес-логика. По-хорошему, вся описанная инфраструктура конфигурируется так, чтобы автоматически (ну или полуавтоматически) брать на себя основные проблемы сбоев на стороне железа (переключать нагрузку на реплику базы данных, если мастер-копия недоступна, распределять нагрузку между несколькими нодами серверов приложений, автоматом наливать чистую машину, которая подключена в кластер, и т. д.).
То есть появилось несколько специализаций. Разработчики бизнес-логики (продуктовые разработчики), по-хорошему, думают в основном о бизнес-логике и фокусируются на бизнес-проблемах. А еще имеются инженеры и разработчики остальной, огромной подводной части айсберга — DevOps, системные администраторы, разработчики СУБД, разработчики серверов приложений, систем мониторинга и других (назовем их инфраструктурными) компонентов.
Вот бы и на местах так было. Круто же? Вот бы разработка на IoT Hubs была такой же специализированной.
И тут мы плавно подходим к Tarantool IIoT. Я не скажу, что он призван заменить всю вышеуказанную инфраструктуру на IoT Hubs, но он может сделать это частично. Посмотрите на рисунок:
Tarantool IIoT — это обычный Tarantool, но собранный и оттестированный под ARM и под x86 (версия для MIPS сейчас создается). Кроме того, внутрь него встроена автоматическая поддержка протоколов MQTT и MRAA — это основные протоколы для работы с датчиками. Tarantool IIoT инсталлируется непосредственно на IoT Hubs. Еще можно тут добавить, что для передачи данных между датчиками и хабом (на схеме «на местах») нужно специальное оборудование LORA1 или 6LoWPAN. Что, казалось бы, плохо (помните, мы не хотим уникальных вендорских коробок). Но вся соль в том, что это оборудование не обязано понимать протоколы множества датчиков. Его задача — только завернуть протокол в понятный для хаба протокол (обычно это наш любимый старый добрый TCP/IP). Весь остальной разбор можно делать на Tarantool IIoT с помощью скриптов, которые работают прямо на IoT Hub.
В этом преимущества программной платформы над железной — любое оборудование и любые протоколы можно поддержать самостоятельно, без вендора. Технические детали, как это все устроено и как программируется с помощью Tarantool, можно почитать в статье «Master-master репликация и масштабирование приложений между всеми IoT-устройствами и облаком [3]».
Во всем остальном Tarantool IIoT — это полнофункциональный Tarantool, т. е. СУБД со встроенным сервером приложений, синхронным логом транзакций, репликацией между узлами, двумя движками (in-memory — memtx и on-disk — vinyl), хранимыми процедурами, асинхронными джобами, поддержкой очередей и прочими пирогами.
Tarantool IIoT инсталлируется на IoT Hubs. Что это дает?
Как итог — продуктовый разработчик получает шажок в сторону той степени комфорта, которая присутствует при создании софта, работающего в ЦОДе. Не приходится думать о том, что каналы между хабами локально и между хабом и ЦОДом ненадежны и рвутся: репликация все равно доставит данные в обе стороны без потерь и без задвоения. У разработчика меньше болит голова о клиент-серверной архитектуре, о файликах, о потере данных, о выходе из строя хабов — все это хендлит Tarantool IIoT ровно так же, как это происходит в ЦОДе при использовании обычного Tarantool. Разработчик может больше сконцентрироваться на бизнес-логике.
Еще добавлю тут, что доставкой данных занимается штатный механизм репликации между узлами, который тестируется в Tarantool на протяжении уже девяти лет. То есть надежность механизма достаточно высока.
По сути, Tarantool IIoT — это полностью программируемая открытая платформа, которая позволяет не только разрабатывать приложения под IIoT на локальных устройствах (без выезда на места!), но и переносить best practices из ЦОДа на IoT-устройства на местах.
И еще эта платформа развязывает вам руки в том смысле, в котором производители оборудования вам их ранее связали. Например, у вас уже есть готовая и работающая железная IoT-инфраструктура, которая автоматом доставляет все из датчиков в ЦОД. Вы закупили новую партию более дешевых датчиков, которые не поддерживаются вашим текущим оборудованием. Вам придется валяться в ногах у вендора оборудования, чтобы он за большие деньги внес туда изменения. Ну или просто закупить новую версию оборудования. Или отказаться от дешевых датчиков. И все эти изменения — железные, не софтверные, т. е. с downtime, выездом на места, монтажом и прочими неприятностями.
С помощью Tarantool IIoT же можно без проблем получать данные с этих новых дешевых датчиков, парсить их и далее выдавать в ваше оборудование или в локальный софт в нужном формате. Без downtime и без больших затрат.
Понятно, что самого по себе Tarantool IIoT мало. Для полного комфорта нужны и остальные инфраструктурные системы — мониторинг, удаленный апгрейд софта (тот же Tarantool надо апгрейдить), автоматическая наливка Linux и прочие радости. Но, как нам кажется, это уже шаг в нужном направлении.
В заключение я хочу рассказать, почему в качестве основы для нашего IIoT-продукта мы взяли именно Tarantool. Давайте на секунду вернемся к специфике IoT Hubs: у этих устройств медленные процессоры с малым количеством ядер (обычно одно-два ядра), мало оперативной памяти, мало флеш-памяти, которая к тому же медленная и ненадежная. Почему? Устройства должны быть очень дешевыми (ценовой диапазон приблизительно такой: 30—100 долларов), потому что их очень много, потому что инфраструктура разбросана на многие километры — и еще по ряду причин, см. выше. Помните, я говорил о специфике? От нее не уйти. Это с одной стороны. А с другой стороны, датчики генерируют огромное количество информации (с одного датчика могут поступать десятки и сотни параметров в секунду, а количество датчиков на хаб иногда исчисляется сотнями и тысячами). Всю информацию надо успевать обрабатывать, несмотря на жесткие условия и не очень быстрое оборудование.
Соответственно, для таких устройств нужны о-о-очень быстрый софт, очень быстрая СУБД и очень быстрый сервер приложений, способный работать на одном ядре процессора, максимально эффективно использующий память и не напрягающий диск.
И в условиях всех этих ограничений Tarantool на наших тестах показал лучшие результаты. Ближайшим конкурентом по скорости может быть Redis (с CouchBase и Aerospike, к сожалению, у нас ничего не получилось: они очень медленные на одноядерных машинах, но, возможно, мы просто не умеем их готовить). Главные минусы Redis с точки зрения применимости в IoT: в нем недостаточно развит сервер приложений, нет хранимых процедур (и нельзя в рантайме обновлять код внутри СУБД), нет джобов, нет мастер-мастер репликации, нет транзакций — больше вероятность потери данных. Плюс непонятно, планируют ли авторы продукта вообще развиваться в эту сторону. Вот тут пример сравнения двух продуктов: Tarantool vs Redis [4]. Связка Python и Redis может в каком-то смысле заменить Tarantool, но по скорости, скорее всего, сильно проиграет. Сразу оговорюсь — сравнительных тестов пока нет, плюс мы рекомендуем скорость работы сравнивать в каждом случае, case by case.
Еще один важный нюанс: на IoT-девайсах, когда СУБД и сервер приложений объединены (а в Tarantool они объединены и работают в одном процессе), накладных расходов на их общение друг с другом, очевидно, будет сильно меньше (вот тут о накладных расходах, которые огромны даже при взаимодействии с быстрыми СУБД: Asynchronous processing with in-memory databases or how to handle one million transactions per second on a single CPU core [5]). При этом любые накладные расходы на передачу информации между разными процессами получаются очень большими в свете невысокой производительности устройств и огромного количества информации, которую нужно обрабатывать.
Еще есть такая неплохая штука — SQLite, он хороший и быстрый, но, к сожалению, у него нет репликации и сервера приложений из коробки — т. е. поверх него надо еще поплясать с бубном. Остальные традиционные СУБД (не буду называть, тут большой список уважаемых продуктов, все их прекрасно знают) у нас просто не завелись нормально на маленьких железочках IoT или даже близко не справились с той нагрузкой, которая идет от датчиков. Однако если у вас есть положительный опыт применения других СУБД на IoT-девайсах, то мы будем рады, если вы поделитесь им!
Это все, что я хотел рассказать о Tarantool IIoT. У нас уже в процессе пилоты с различными производственными, транспортными и другими компаниями. Как только будет продакшн, мы обязательно про это детально напишем. Следите за новостями!
Автор: Mail.Ru Group
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/open-source/247034
Ссылки в тексте:
[1] Tarantool IIoT: https://corp.mail.ru/en/press/releases/9876/
[2] Новость: http://www.rbc.ru/technology_and_media/15/02/2017/58a1de9a9a79476d0aaf2d85
[3] Master-master репликация и масштабирование приложений между всеми IoT-устройствами и облаком: https://habrahabr.ru/company/mailru/blog/320878/
[4] Tarantool vs Redis: https://hackernoon.com/tarantool-vs-redis-38a4041cc4bc#.7h2lroqin
[5] Asynchronous processing with in-memory databases or how to handle one million transactions per second on a single CPU core: https://medium.com/@denisanikin/asynchronous-processing-with-in-memory-databases-or-how-to-handle-one-million-transactions-per-36a4c01fc4e4#.ftvh7thvd
[6] Источник: https://habrahabr.ru/post/322730/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.