РЕКЛАМА НА ФОРУМХАУС И немного об организации взаимодействия устройств: После экспериментов с проводными протоколами, радиомостами и прочим подобным пришел к идее разделить физический уровень (провода или радио) и логический (сигналы). Сразу стало легче. Логический реализован на основе обмена mqtt-сообщениями. Кто-то их инициализирует, кто-то их исполняет. Устройства разные, поэтому в mqtt-пространстве получилась настоящая каша из разнообразных топиков и форматов сообщений, которую тоже пришлось стандартизировать под себя: - event/XXX - событие, типа что-то включилось, выключилось, камера поймала движение и т. д. - alarm/XXX - событие, на которое надо отреагировать (отправить сообщение мне, зажечь сигнальную лампочку и т. д.) - etc/XXX - просто какое-то сообщение от устройства, текущий статус, что-то не требующее особого внимания само по себе - state/XXX - retain-сообщения, которые можно получить в любой момент, не ожидая event: текущая температура, состояния датчиков и т. д. - command/XXX - сообщения управления. Вся остальная каша либо сводится к этой системе, либо игнорируется. Если что-то где-то происходит и требует реакции - формируется event, если серьезное - alarm, в любой момент доступны state, управление идет через command. Исполнительные устройства на базе esp8266 или Tasmota-zigbee принимают эти command и реагируют. Соответственно используются скрипты-драйвера, которые обрабатывают события и рассылают команды. Вот для них-то и нужен маленький сервер-коробочка, который может физически находиться примерно где угодно. А за отображение на экране отвечает отдельный, самостоятельный вебсервер, который читает state и отправляет command. Больше он ничего не делает, да ему и не надо. Если он сломается - ну, запущу на новой коробочке, делов-то. Именно поэтому дешевизна устройств, компактность - для меня важны, а наличие кучи интерфейсов и производительность - нет...
HA, Z2M, кучу еще чего-то, что в доме нужно Даже не знаю как ответить. А где прикажете их запускать? Странно, почему у меня такая же маленькая коробочка. Можно в пластике или металле интерфейсные выходы нужны редко, это бонус Ну т. е. вы вместо одного сервера-коробочки, на котором HA и куча всего еще предлагаете стопку из 20 серверов и к ним кучу соплей? Мне проще организовать бекап одного и запуск резервного, чем 20. 20 серверов - это в 20 раз выше вероятность поломки, хотя каждая поломка в 20 раз менее критична.
Здравствуй, 1960 год. Для каждого скрипта - отдельный компьютер! Человечество придумало многозадачные системы очень давно.
Чувствуется, не работали вы с системами гарантированной доступности, что такое резервирование и дублирование не прочувствовали...
Чувствуется, не работали вы с системами гарантированной доступности, что такое резервирование и дублирование не прочувствовали...
Мне иногда лень самому выдумывать бессмысленный личный выпад, поэтому (в связи с полным отсутствием смысла) для сокращения умственных трудозатрат считаю оптимальным просто написать аффтару то же самое, что он написал мне. Тем более что к нему эта фраза намного, намного ближе
Вообще-то все это проходят в институтах, ну те кто когда-то учился про профильной специальности. И обеспечение надежности системы точно реализуется не раскидыванием задачи частями на 20 серверов, которые делают то же самое, что один, тем более что речь не проуправление ядерным реактором, а домом, и минута, а то и 10 на включение резервного сервера, даже если вручную - ни на что не влияет
Согласен. Это если не нужны детальные данные за прошлые периоды. Типа посмотреть в деталях, что было год назад. А так концепция RRD красивая. Фиксированный объем БД, но "разрешение" чем дальше, тем хуже.
Я просто знаю, как сервак зарезервировать. Все просто. Резервный стартанул, всосал бекап и полетел дальше. А идея "если поломается - пусть поломается часть, поэтому разобью сервер на 20 мыльниц, которые будут раз в месяц дохнуть" - она бредовая Поэтому возвращаясь к теме, взять мыльницы на 1000р дешевле, чем апельсинка - она ни о чем, если не набирать их в дом десятками.
Собственно говоря у меня сейчас работает центр обслуживания вызовов, где по SIPу прет около 50 вызовов в секунду, для десятков клиентов, в ЧНН больше. Никому в голове не пришло тупо поднять 20 серваков по числу клиентов, чтобы при падении пострадал кто-то один, а остальные работали. 2 сервера, каждый на всех. Операторы знают, куда отправлять вызовы, если сервер упал.
Вопрос как проценты считать. Вот предложено UI считать 5%, не обязательными та же концепция реализуется на других средствах, было бы желание, правда без фиксации размера БД
То есть, ни балансировки, ни горячего резерва нет? Ну ничо, ничо, будет со временем... А то вот есть еще такая ГАС Правосудие, у которой как оказалось то ли не было бекапов, то ли они все лежали на каком-нибудь одном сервере в единственной серверной, где внезапно прорвало канализационную трубу. Была такая история, с прорвавшейся канализацией. И другая с пожаром из-за гастарбайтеров-кровельщиков, и третья с экскаватором и датацентром - это можно как байки часами травить. Всё - крупные компании, логотипы которых вы каждый день видите, сотни специалистов, высокооплачиваемых, все "институты кончали"...
Невнимательно читаете. 2 сервака - это и есть горячий резерв. Балансировка не нужна. У операторов штатная фишка, при недоступности принимающего сервера перенаправлять все вызовы на резервный. Поскольку операторов несколько, половине первый прописан основным, второй резервным, второй половина - наоборот. Вы путаете причину и следствие в логических цепочках Отсутствие знаний, которые в институте проходят - это как бы плохой сигнал. Но вот изучение чего бы то ни было в институте - не гарантия того, что человек это знает.