Разработка архитектуры и инструментов для модернизации распределенной многопотоковой обработки спутниковых данных

Стремительное развитие систем спутникового мониторинга Земли в последние десятилетия привело к резкому увеличению объемов спутниковых данных и числа их типов. Это закономерно еще более повысило требования к эффективности организации систем обработки спутниковых данных. Необходимо максимально полно использовать имеющиеся вычислительные ресурсы и контролировать сотни различных процессов по обработке спутниковых данных. Для решения вышеперечисленных задач в рамках центра коллективного пользования ЦКП «ИКИ-Мониторинг» была разработана технология организации многопотоковой обработки спутниковых данных на кластере windows серверов. В настоящее время она успешно используется для проведения широкого спектра различных типов обработки спутниковых данных на кластере, включающем в себя более 200 серверов, включая виртуальные. Впервые эта технология была внедрена в 2016 году, при этом в нее регулярно вносились изменения, которые повышали ее эффективность. В 2023 году велись работы по совершенствованию схемы управления выполнением большого количества процедур обработки с разным приоритетом и продолжительностью выполнения. Как уже было отмечено выше, необходимо максимально полно использовать имеющиеся вычислительные ресурсы, однако это вступает в противоречие с требованиями на время выполнения «срочных» заданий на обработку. Одним из решений является указание максимального количества потоков выполнения для длительных, но не очень оперативных процедур обработки. Также в 2023 году были проведены работы по оптимизации запросов к базе данных, отвечающей за управление обработкой и контроль  ее выполнения, что позволило минимизировать задержки при их проведении. В то же время на текущий момент реализация системы многопотоковой обработки перестала в полной мере отвечать предъявляемым к ней требованиям. Поэтому в 2023 году были начаты работы по более масштабной ее модернизации.

Рисунок 1 - Текущая схема организация обработки спутниковых данных

 

Текущая схема организации обработки спутниковых данных приведена на рисунке 1. Для хранения информации о типах обработки, в том числе и соответствующих им требований к вычислительным узлам реализована база данных конфигураций. В первом слое скриптов (xvcron.pl) вычислительный узел обращается к базе данных, скачивает себе комплект .ini файлов с метаинформацией, и в соответствии с прописанными внутри них путями размещения исходных данных, начинает опрашивать различные сервера на предмет наличия комплектов готовых к обработке. Если такой комплект находится, то запускается второй слой скриптов, соответствующий сессии выполнения (session.pl), функционал которого изначально сводился к определению количества комплектов, которые возможно обработать на вычислительном узле параллельно, подготовки скриптов для обработки этих комплектов и запуске скриптов третьего слоя потоков выполнения (thread.pl). В рамках последнего слоя уже непосредственно осуществляется обработка отобранных комплектов исходных данных. Но со временем во втором слое накопилось достаточно много функциональных особенностей, которые с точки зрения логики обработки, необходимо было включить в первый слой, но которые в силу различных обстоятельств оказались во втором. В некоторых случаях это приводит к ситуациям, когда факт наличия комплекта данных и вычислительного узла для его обработки, не гарантирует выполнение этой обработки. Это может происходить, когда на сервере для результатов закончилось свободное место, на вычислительном узле накопилось критическое количество ошибочно выполненных заданий этого вида или же вычислительный узел перестал отвечать характеристикам (по оперативной памяти, свободном месте на жестком диске и т.п.). Т.к. проверка всех этих характеристик осуществлялась из второго слоя, то на вычислительных узлах начали в массовом количестве появляться так называемые «пустые сессии», инициированные первым слоем по факту наличия комплекта на обработку, и завершённые вторым слоем из-за невозможности эту обработку осуществить.

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

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

 
Рисунок 2 - Новая схема организация обработки спутниковых данных

 

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

 
Рисунок 3 - Параллельная работа процессов обработки данных и выгрузки результата

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