-
+86-13811808484
- majiang@jinmatimes.com
+86-13811808484
Когда говорят про сервер для граничных вычислений, многие сразу представляют себе просто уменьшенную версию ЦОДа, коробку поменьше и попроще, которую можно воткнуть где угодно. Это, пожалуй, самый распространённый и опасный просчёт. На деле, требования к этой ?коробке? часто противоречивы и куда жёстче, чем кажется. Нужна и вычислительная мощь для локальной обработки данных с датчиков или камер в реальном времени, и надёжность работы в неконтролируемой среде — в цеху с вибрацией, на улице при -30 или в непроветриваемом подсобном помещении. И всё это — при минимальных затратах на обслуживание, потому что физически добраться до такого сервера бывает сложно или дорого. Именно здесь и кроется вся соль.
Мы в ?Чжунчуан Жуньцзинь? через это прошли, причём не раз. Наши НИОКР изначально были сфокусированы на классических серверных решениях для центров обработки данных. Но запросы от клиентов, особенно из промышленного и транспортного секторов, стали приходить другие. Нужно было обрабатывать видео-потоки с камер наблюдения на удалённых объектах, анализировать данные телеметрии прямо на месте, чтобы не гонять терабайты сырых данных по каналам связи. Стало ясно, что нужен принципиально иной подход к проектированию.
Первые наши попытки были, скажем так, адаптивными. Брали проверенную платформу для стоечного сервера, пытались её ?упаковать? в более компактный и защищённый корпус. Получалось громоздко, дорого и с проблемами теплоотвода. Один из проектов для логистического хаба чуть не провалился как раз из-за перегрева — сервер был установлен в металлическом контейнере на открытой площадке, и пассивного охлаждения, на которое мы рассчитывали, летом категорически не хватало. Пришлось срочно дорабатывать систему активного обдува с пылевыми фильтрами. Это был хороший урок: нельзя просто взять и масштабировать ЦОД-решение вниз. Требуется глубокая переработка архитектуры.
Сейчас мы смотрим на сервер для граничных вычислений как на законченный аппаратно-программный комплекс. Железо — это лишь часть. Критически важны средства удалённого управления (out-of-band management), которые должны работать даже если основная ОС ?упала?. Важна поддержка широкого диапазона температур и влажности, устойчивость к вибрации (особенно для установки на транспорт). И, что часто упускают из виду, — энергоэффективность. На периферии каждый ватт на счету, особенно если объект питается от резервных источников.
Один из наших наиболее показательных проектов был связан с цифровизацией сети АЗС. Задача — установить на каждой станции вычислительный узел для локальной обработки данных с касс, камер контроля территории и датчиков резервуаров. Данные нужно было агрегировать, частично анализировать (например, распознавать номера автомобилей) и отправлять в региональный центр только сводную информацию. Объём сырых данных был огромен, а каналы связи — не всегда стабильны.
Мы предложили решение на базе нашего компактного сервера для граничных вычислений с усиленным SSD-накопителем и GPU для задач видеоаналитики. Казалось бы, всё учли. Но на этапе пилота столкнулись с неочевидной проблемой: электропитание. На старых АЗС в электросети были частые микроскачки и помехи, от которых сервер периодически ?зависал?. Штатный блок питания не справлялся с фильтрацией. Пришлось в срочном порядке интегрировать внешний стабилизатор и источник бесперебойного питания в единый монтажный комплект. Это добавило к стоимости, но без этого надёжность всей системы была под вопросом. Подробности нашего подхода к таким комплексным решениям можно найти на https://www.itbktech.ru.
Другой пример — проект для университета, который разворачивал сеть метеостанций в полевых условиях. Там основной вызов был не в мощности, а в энергопотреблении и автономности. Серверы питались от солнечных панелей. Нам пришлось очень тонко настраивать баланс между производительностью процессора и энергопотреблением, отключать всё лишнее, даже подсветку индикаторов. В итоге получился крайне спартанский, но очень выносливый аппарат.
С ?железом? более-менее разобрались, но дальше встаёт вопрос программного обеспечения. Универсального образа ОС для edge-устройств не существует. Всё зависит от задачи. Где-то нужен легковесный Linux контейнер, где-то — специализированная RTOS (операционная система реального времени), а где-то — полноценная виртуализация для запуска нескольких изолированных рабочих нагрузок на одном физическом сервере.
Мы в ?Чжунчуан Жуньцзинь? не разрабатываем ОС, но наш отдел НИОКР плотно работает над созданием эталонных конфигураций и средств для удалённого развёртывания и обновления ПО. Это, поверьте, отдельная война. Как безопасно ?прошить? сотни разбросанных по стране устройств, если они подключены к интернету через разные, не всегда безопасные сети? Как откатить обновление, если оно ?сломало? работу на конкретном объекте? Приходится внедрять механизмы A/B-обновлений и отката, что накладывает дополнительные требования и на аппаратную часть (например, наличие двух разделов для прошивки).
Часто клиенты, особенно из госсектора и медицины, просят предустановленное и валидированное ПО. Здесь на первый план выходит тесное партнёрство с софтверными вендорами и тщательное тестирование совместимости. Один баг в драйвере под конкретную версию ядра может обернуться неделями простоя оборудования на удалённом объекте.
Сервер для граничных вычислений редко живёт сам по себе. Он — часть более крупной архитектуры: IoT-сети, распределённого ЦОДа, гибридного облака. Поэтому для нас критически важны вопросы интеграции. Поддержка стандартных протоколов мониторинга (SNMP, IPMI), совместимость с системами оркестрации вроде Kubernetes (особенно его edge-ориентированных дистрибутивов типа K3s), возможность работать как часть SD-WAN сети.
Наше участие в проектах цифровой трансформации для финансового сектора и МСП показало, что зачастую клиенту нужно не просто продать ?коробку?. Ему нужна гарантия, что это решение будет масштабироваться и взаимодействовать с уже существующей ИТ-инфраструктурой. Мы стали уделять больше внимания API для управления нашими устройствами, чтобы их можно было легко встроить в существующие панели управления заказчика.
Что дальше? Тренд очевиден: конвергенция. Граница между сетевым оборудованием, системами хранения и собственно серверами на периферии будет размываться. Появятся гибридные устройства, которые совмещают в себе функции коммутатора, маршрутизатора и вычислительного узла. И здесь на первый план выйдет не просто аппаратная надёжность, а интеллектуальность системы: способность к самоанализу, предсказательному обслуживанию и автономной работе при потере связи с центром. Над этим мы тоже работаем, постепенно внедряя элементы машинного обучения для мониторинга состояния самих edge-серверов.
Так что, если резюмировать мой опыт, то создание сервера для граничных вычислений — это постоянный поиск компромисса. Компромисса между мощностью и энергопотреблением, между надёжностью и стоимостью, между универсальностью и специализацией. Готовых решений на все случаи жизни нет. Каждый проект — это в какой-то степени НИОКР заново, глубокая работа с заказчиком, чтобы понять истинные, а не декларируемые условия эксплуатации.
Компании вроде нашей, ?Чжунчуан Жуньцзинь?, которые делают ставку на собственные исследования и разработки, находятся здесь в более выигрышной позиции. Мы можем быстро модифицировать платформу, провести дополнительные стресс-тесты, адаптировать решение под нестандартный кейс. Это не про массовое производство, это про создание инструмента под конкретную задачу. И в этом, как мне кажется, и есть главная ценность правильного подхода к edge computing. Не в том, чтобы поставить сервер где-то на краю сети, а в том, чтобы он действительно решал проблему именно в этой, конкретной точке, часто в самых недружелюбных условиях. Всё остальное — просто железо.
