The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Доступен системный менеджер systemd 238"
Отправлено Тузя, 08-Мрт-18 10:10 
TL;DR; На локалхосте не сильно нужно.

Видимо, systemd пытается реализовать в себе часть функционала windows, связанного со счётчиками производительности. У этой подсистемы есть 2 назначения:
1) Система производит учёт потребления ресурсов ОС, демонов и приложений пользователя, что позволяет:
- динамически выдавать приоритеты тем или иным задачам
- наглядно отображать утилизацию ресурсов и мониторировать процессы во времени.
2) Предоставить API для непривилегированных приложений, которое в свою очередь:
- Позволяет опубликовать свои счётчики мониторинга
- Принимать решения внутри клиентского ПО в случае получения тех или иных данных о загруженности системы или счётчиков мониторинга другого приложения.

Линуксу, конечно, не нужен perfmon.exe, ведь уже есть top, htop, iotop и много чего еще. Кроме того, сами cgroups и так позволяют делить процессорное время между задачами неравномерно. Динамика и API - другой момент.

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

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

Понимаю, пример искусственный... но он как раз демонстрирует, что функционал на стороне ядра есть давным давно. Есть даже шины IPC/RPC (dbus), но конечное решение всё равно придётся писать самим, потому что на стороне ОС (системы, дистрибутива) функционала не хватает. Докер в этом сильно поможет, чтобы совсем уж не велосипедить, но добавление виртуализации даже контейнерной бывает оправдано не всегда.
С другой стороны, на стороне windows этот функционал, как и всё чего касалось щупальце MS, переусложнён и извращён, поэтому городить отказоустойчивые пулы приложений в IIS-ах, которые имеют доступ (через kerberos) к системным API мониторинга, требует, так сказать, специфических вкусов и предпочтений. Уверен, что в линуксе получится намного лучше.

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

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру