Выбирали ли вы DFS и из каких систем? Делали ли тесты по производительности и надежности? Сравнивали ли возможности?
Около 4 лет назад мы выбирали систему для работы в облаке. Сравнивали Ceph, Gluster и другие FS. В нашем сравнении победила малоизвестная FS SeaWeedFS.
SeaweedFS is a simple and highly scalable distributed file system, to store and serve billions of files fast! SeaweedFS implements an object store with O(1) disk seek, transparent cloud integration, and an optional Filer supporting POSIX, S3 API, AES256 encryption, Rack-Aware Erasure Coding for warm storage, FUSE mount, Hadoop compatible, WebDAV.
У меня есть предложения:
1. У вас в планах окружение для выполнения. Это очень хорошо. Можно ли еще добавить туда возможность, чтобы исходники лежали на сервере и сборка и компиляция могла быть тоже на сервере. То есть было бы «Окружение для сборки и выполнения». Или добавить «окружение для сборки». Чтобы собрать часто приходится настраивать окружение, если работаешь с разных компьютеров. Удобно настроить его на сервере, положить туда проект, а работать с ним с IDE с компьютера дома или на работе или коллега может туда зайти и т.д.
2. Многие хотят быстрый запуск. Сейчас появилась концепция compile time инициализации, то есть когда объекты инициализируются при компиляции, а во время выполнения грузится сразу область памяти целиком. Например, запуск Quarkus native приложения может занимать 0.001 секунды. Для компиляции используется GraalVM. Тут будет проблема с плагинами, но и для нее есть варианты решения. Мне кажется, направление перспективное.
Большое спасибо за внимание.
При использовании Commercial Features надо не забыть купить лицензию на Java SE Advanced Desktop (40$) или Java SE Advanced (5000$) или Java SE Suite (15000$).
Искал систему, сервер для которой можно запустить в виртуалке под линукс в докер контейнере, желательно, чтобы он был написан на java, чтобы масштабировался (можно запустить несколько экземпляров), в качестве базы можно было использовать PostgreSQL.
У всех российских производителей сервера под винду. Софт написан в лучшем случае на .Net и С++ в худшем на Delphi.
Ни кто не дает исходники софта. Так как функционал системы одинаковый у всех, то удобно бы было иметь одну опенсоурсную систему с разными драйверами для разных контроллеров.
Нашел только одного производителя в Беларусии. Но цены у него довольно высокие и много заморочек с иностранной покупкой.
Прям застой в софте полный и беда. Весь мир переходит на линуксовые сервера и контейнеры, а у нас еще разработка на Delphi.
По поводу Большого взрыва есть интересная лекция про современную теорию:
Многоликая Вселенная. Андрей Дмитриевич Линде elementy.ru/lib/430484
Снимает много вопросов и теория более красивая.
А как быть в ситуации, когда сертификат подписан сразу двумя сертификатами. Например, Крипто Про выдает сертификаты, которые первично подписаны самоподписанным корневым сертификатом Крипто Про, но у него еще существует подпись и от цепочки с началом у МинСвязи РФ (что и дает сертификату юридическую силу). При попытке вытащить цепочку, у меня вытаскивался именно первый, самоподписанный сертификат Крипто Про.
В связи с развитием современных распределенных систем на базе docker, в которых заранее предполагается возможность выхода из строя программных компонентов на различных уровнях: контейнер, сервер, стойка, датацентр, существует ли необходимость учитывать и проектировать с такой тщательностью аппаратную инфраструктуру? Ведь для правильной работы такой системы достаточно обеспечить безотказную работу и возможность восстановления аппаратуры на время синхронизации параллельно работающих распределенных систем, что сейчас может обеспечить самый обычный простой сервер на базе самой обычной линукс платформы на kvm. Не будет ли дешевле предусмотреть возможность самовосстановления системы на массивах простых серверов, чем гоняться за девятками после зяпятой?
Уважаемый Автор!
Результат статьи виден в разделе «Что делаем мы». Вы предлагаете один дорогой контроллер.
В своем сообщении, я спрашиваю, почему бы не разработать серию умных недорогих защищенных автономных исполнительных устройств именно ориентированых для умного дома, для которых не нужен центральный дорогой контроллер для обычной работы.
Да, систему можно построить, но для одной лампочки мне надо поставить контроллер, релюху, переключатель и патч-панель с коммутацией для реализации аналога распаечной коробки.
Это вообще не удобно и дорого. Однако разработчик устройств может легко запихнуть их в один корпус и сделать приемлемую цену. Я это писал в надежде, что вам интересно, что нужно конечному потребителю.
Хотелось бы от вас увидеть конкретный пример построения умного дома с конкретными марками релюшек, датчиков и других устройств, чтобы можно было задать вопросы. Хотелось бы, чтобы вы предлагали решение, а не просто контроллер.
В своем предыдущем посте, я, ваш потенциальный клиент, рассказал, что я хочу сделать. Можете ли вы рассказать мне как я могу с помощью вашей продукции сделать это?
Странно, но почему-то все разработчики «умных домов» сначала стараются сделать головное устройство. Оно понятно, так как по стоимости оно самое выгодное. Однако, хотелось бы больше заострить внимание на исполнительных устройствах и на надежности.
Мне кажется, что важно иметь надежный «умный дом», который бы поддерживал «обратную совместимость», чтобы всю умность в щитке можно было бы отключить.
Возьмем, например, обычную лампочку. Без умного дома выключатель был бы соединен в распаечной коробке с лампочкой. Теперь, предположим, что мы ведем провода от выключателя и лампочки в щиток. Тогда правильное исполнительное устройство (умное реле), по моему мнению, выглядело бы так:
1. Могло управляться с центрального контроллера по открытому протоколу, например http. Передавать туда сведения о нажатом выключателе, получать команды на включение и выключение.
2. Могло так же работать автономно при недоступности центрального контроллера: включать/выключать лампочку от выключателя и/или передавать/принимать команды на другое похожее устройство(а) согласно заранее запрограммированному поведению.
3. Если вдруг релюшка выходит из строя или мы просто хотим отключить эту функциональность, то мы одним физическим выключателем на приборе можем скоммутировать выключатель и лампочку аналогично коммутации в распаечной коробке. То есть, если даже у нас все умерло, то обычная квартира с обычными выключателями у нас останется жить.
Как мы видим, исполнительное устройство должно иметь возможность инициировать передачу данных, поэтому часть шин, в которых присутствуют объекты типа master/slave тут использовать нельзя.
По моему мнению, система должна по-умолчанию работать во 2 режиме (исполнительные устройства должны быть запрограммированы на относительно простое автономное поведение), а основной «большой» контроллер должен ими управлять, обобщая события от разных источников, выполняя скрипты и выдавая команды, которые являются более приоритетными, чем обычное поведение исполнительного устройства.
В этом случае главный контроллер может уже не иметь кучи выводов, а просто быть подключенным через ethernet к общей сети и представлять собой обычную серверную программу с набором rest сервисов, которая может принимать события, выполнять внутри скрипты, срабатывать от таймера и вызывать через http срабатывание исполнительных устройств. Она так же может иметь веб и мобильный интерфейсы, постоянное хранилище для скриптов и других данных и даже может иметь простую базу данных. Выскажу крамольную мысль, но, в крайнем случае, она может быть запущена даже на домашнем роутере, который всегда есть, всегда работает и всегда подключен к интернету и wifi, чтобы пользователь через мобильное приложение или веб мог управлять домом.
Таким образом, мне кажется, что все создатели «умных домов» идут по самому простому пути создания мощных головных устройств, вместо создания относительно дешевых (3-4 тыс. руб.) стакающихся программируемых исполнительных устройств, доступных через ethernet.
Кроме этого остро стоит проблема управления высокотоковой и нерезистивной нагрузкой. Светодиодные лампочки уже не резистивная нагрузка, поэтому в паспорте реле обычно пишут количество переключений для резистивной нагрузки и для светодиодных ламп, которое сильно меньше. А при управлении розетками в доме выбор реле является большой проблемой, так как для тока 16 ампер для нерезистивной нагрузки обычно создатель умных домов предлагает использовать сторонние мощные реле, но для людей не являющимися профессиональными электротехниками, выбор их представляет большую проблему. Хотелось бы, чтобы разработчики прорабатывали этот вопрос и явно предлагали решения.
Светодиодные лампы, на которые заменяются обычные в доме, потребляют от 5 до 15 ватт. Поэтому очень заманчиво продумать возможность запитки системы освещения от UPS, чтобы при отключении электричества освещение оставалось работать и была возможность, например, зарядить телефон в специальном месте. Правильно бы было, чтобы система сама переключалась на специальную схему электроснабжения при отключении электричества и предупреждала на мобильном приложении об этом.
Возможно, какой-нибудь производитель умного дома сделает нечто похожее на мое представление о нем и я сделаю его именно так в своей новой квартире.
Планирую реализовать в своей квартире умный дом. Смотрю различные варианты.
Согласно нормам для приборов освещения реле должны быть рассчитаны на 10 ампер, для розеток на 16 ампер, для потребляющих нагрузок на 25 ампер. Конечно, физически ток может быть меньше, но по нормам положено именно так. Очень желательно, чтобы реле было не твердотельным.
Сооветственно, для обеспечения надежности хорошо бы иметь автономные управляемые блоки:
1. Для освещения один два цифровых входа/реле или регулятор/диммер на 10 ампер с возможностью включения при отказе электронной части устройства включить руками прямо на блоке. Или набор таких устройств в одном корпусе.
2. Для розеток управляемое реле с возможностью вручную включить розетку прямо на блоке.
3. Для теплого пола два входа термодатчиков, вход регулятора, дисплей для отображения температуры, совмещенные с реле.
4. Для кондиционера, телевизора инфракрасный эмулятор пульта ДУ.
5. Для диммирования светодиодной ленты ШИМ регулятор.
6. Входа для различных датчиков для охраны и т.д.
Сам центральный регулятор нормальный, имеет Linux на борту, позволяет подключать модули прямо на рейке, как Siemens контроллеры.
К сожалению, я не нашел в вашем магазине реле на 16 ампер, регулятор для теплого пола, диммер для светодиодной ленты. Реле на 10 ампер есть, но там отсутствуют входа для выключателя и возможность вручную скоммутировать прямо на приборе (например реле Finder 22 серии имеют ручной переключатель).
Подскажите, появятся у вас отсутствующие компоненты и когда?
Около 4 лет назад мы выбирали систему для работы в облаке. Сравнивали Ceph, Gluster и другие FS. В нашем сравнении победила малоизвестная FS SeaWeedFS.
Может кому-то это будет полезно.
1. У вас в планах окружение для выполнения. Это очень хорошо. Можно ли еще добавить туда возможность, чтобы исходники лежали на сервере и сборка и компиляция могла быть тоже на сервере. То есть было бы «Окружение для сборки и выполнения». Или добавить «окружение для сборки». Чтобы собрать часто приходится настраивать окружение, если работаешь с разных компьютеров. Удобно настроить его на сервере, положить туда проект, а работать с ним с IDE с компьютера дома или на работе или коллега может туда зайти и т.д.
2. Многие хотят быстрый запуск. Сейчас появилась концепция compile time инициализации, то есть когда объекты инициализируются при компиляции, а во время выполнения грузится сразу область памяти целиком. Например, запуск Quarkus native приложения может занимать 0.001 секунды. Для компиляции используется GraalVM. Тут будет проблема с плагинами, но и для нее есть варианты решения. Мне кажется, направление перспективное.
Большое спасибо за внимание.
Гейт для протоколов RDP, VNC, ssh. Клиент — браузер. Нужно поставить и выставить наружу сервер с этой программой по http.
У всех российских производителей сервера под винду. Софт написан в лучшем случае на .Net и С++ в худшем на Delphi.
Ни кто не дает исходники софта. Так как функционал системы одинаковый у всех, то удобно бы было иметь одну опенсоурсную систему с разными драйверами для разных контроллеров.
Нашел только одного производителя в Беларусии. Но цены у него довольно высокие и много заморочек с иностранной покупкой.
Прям застой в софте полный и беда. Весь мир переходит на линуксовые сервера и контейнеры, а у нас еще разработка на Delphi.
Многоликая Вселенная. Андрей Дмитриевич Линде elementy.ru/lib/430484
Снимает много вопросов и теория более красивая.
Результат статьи виден в разделе «Что делаем мы». Вы предлагаете один дорогой контроллер.
В своем сообщении, я спрашиваю, почему бы не разработать серию умных недорогих защищенных автономных исполнительных устройств именно ориентированых для умного дома, для которых не нужен центральный дорогой контроллер для обычной работы.
Да, систему можно построить, но для одной лампочки мне надо поставить контроллер, релюху, переключатель и патч-панель с коммутацией для реализации аналога распаечной коробки.
Это вообще не удобно и дорого. Однако разработчик устройств может легко запихнуть их в один корпус и сделать приемлемую цену. Я это писал в надежде, что вам интересно, что нужно конечному потребителю.
Хотелось бы от вас увидеть конкретный пример построения умного дома с конкретными марками релюшек, датчиков и других устройств, чтобы можно было задать вопросы. Хотелось бы, чтобы вы предлагали решение, а не просто контроллер.
В своем предыдущем посте, я, ваш потенциальный клиент, рассказал, что я хочу сделать. Можете ли вы рассказать мне как я могу с помощью вашей продукции сделать это?
Мне кажется, что важно иметь надежный «умный дом», который бы поддерживал «обратную совместимость», чтобы всю умность в щитке можно было бы отключить.
Возьмем, например, обычную лампочку. Без умного дома выключатель был бы соединен в распаечной коробке с лампочкой. Теперь, предположим, что мы ведем провода от выключателя и лампочки в щиток. Тогда правильное исполнительное устройство (умное реле), по моему мнению, выглядело бы так:
1. Могло управляться с центрального контроллера по открытому протоколу, например http. Передавать туда сведения о нажатом выключателе, получать команды на включение и выключение.
2. Могло так же работать автономно при недоступности центрального контроллера: включать/выключать лампочку от выключателя и/или передавать/принимать команды на другое похожее устройство(а) согласно заранее запрограммированному поведению.
3. Если вдруг релюшка выходит из строя или мы просто хотим отключить эту функциональность, то мы одним физическим выключателем на приборе можем скоммутировать выключатель и лампочку аналогично коммутации в распаечной коробке. То есть, если даже у нас все умерло, то обычная квартира с обычными выключателями у нас останется жить.
Как мы видим, исполнительное устройство должно иметь возможность инициировать передачу данных, поэтому часть шин, в которых присутствуют объекты типа master/slave тут использовать нельзя.
По моему мнению, система должна по-умолчанию работать во 2 режиме (исполнительные устройства должны быть запрограммированы на относительно простое автономное поведение), а основной «большой» контроллер должен ими управлять, обобщая события от разных источников, выполняя скрипты и выдавая команды, которые являются более приоритетными, чем обычное поведение исполнительного устройства.
В этом случае главный контроллер может уже не иметь кучи выводов, а просто быть подключенным через ethernet к общей сети и представлять собой обычную серверную программу с набором rest сервисов, которая может принимать события, выполнять внутри скрипты, срабатывать от таймера и вызывать через http срабатывание исполнительных устройств. Она так же может иметь веб и мобильный интерфейсы, постоянное хранилище для скриптов и других данных и даже может иметь простую базу данных. Выскажу крамольную мысль, но, в крайнем случае, она может быть запущена даже на домашнем роутере, который всегда есть, всегда работает и всегда подключен к интернету и wifi, чтобы пользователь через мобильное приложение или веб мог управлять домом.
Таким образом, мне кажется, что все создатели «умных домов» идут по самому простому пути создания мощных головных устройств, вместо создания относительно дешевых (3-4 тыс. руб.) стакающихся программируемых исполнительных устройств, доступных через ethernet.
Кроме этого остро стоит проблема управления высокотоковой и нерезистивной нагрузкой. Светодиодные лампочки уже не резистивная нагрузка, поэтому в паспорте реле обычно пишут количество переключений для резистивной нагрузки и для светодиодных ламп, которое сильно меньше. А при управлении розетками в доме выбор реле является большой проблемой, так как для тока 16 ампер для нерезистивной нагрузки обычно создатель умных домов предлагает использовать сторонние мощные реле, но для людей не являющимися профессиональными электротехниками, выбор их представляет большую проблему. Хотелось бы, чтобы разработчики прорабатывали этот вопрос и явно предлагали решения.
Светодиодные лампы, на которые заменяются обычные в доме, потребляют от 5 до 15 ватт. Поэтому очень заманчиво продумать возможность запитки системы освещения от UPS, чтобы при отключении электричества освещение оставалось работать и была возможность, например, зарядить телефон в специальном месте. Правильно бы было, чтобы система сама переключалась на специальную схему электроснабжения при отключении электричества и предупреждала на мобильном приложении об этом.
Возможно, какой-нибудь производитель умного дома сделает нечто похожее на мое представление о нем и я сделаю его именно так в своей новой квартире.
Согласно нормам для приборов освещения реле должны быть рассчитаны на 10 ампер, для розеток на 16 ампер, для потребляющих нагрузок на 25 ампер. Конечно, физически ток может быть меньше, но по нормам положено именно так. Очень желательно, чтобы реле было не твердотельным.
Сооветственно, для обеспечения надежности хорошо бы иметь автономные управляемые блоки:
1. Для освещения один два цифровых входа/реле или регулятор/диммер на 10 ампер с возможностью включения при отказе электронной части устройства включить руками прямо на блоке. Или набор таких устройств в одном корпусе.
2. Для розеток управляемое реле с возможностью вручную включить розетку прямо на блоке.
3. Для теплого пола два входа термодатчиков, вход регулятора, дисплей для отображения температуры, совмещенные с реле.
4. Для кондиционера, телевизора инфракрасный эмулятор пульта ДУ.
5. Для диммирования светодиодной ленты ШИМ регулятор.
6. Входа для различных датчиков для охраны и т.д.
Сам центральный регулятор нормальный, имеет Linux на борту, позволяет подключать модули прямо на рейке, как Siemens контроллеры.
К сожалению, я не нашел в вашем магазине реле на 16 ампер, регулятор для теплого пола, диммер для светодиодной ленты. Реле на 10 ампер есть, но там отсутствуют входа для выключателя и возможность вручную скоммутировать прямо на приборе (например реле Finder 22 серии имеют ручной переключатель).
Подскажите, появятся у вас отсутствующие компоненты и когда?