Да в продакшен, на пассивных узлах — узлах не несущих нагрузки. После внесения изменений в конфигурацию и проверки функционирования узла он возвращается в систему.
Существует немало технологий, которые в свое время активно продвигались в том числе лидирующими на рынке IT — компаниями и о которых сейчас ни вспоминает. Так что лидеры IT рынка тоже ошибаются.
В 2003 году развернул свою первую распределенную систему — реального времени. Масштаб развертывания — вся страна (напомню, у нас много часовых поясов). Система находится в эксплуатации до сих пор. Узлов системы много. С тех пор многократно менялось ПО системы. Происходила миграция узлов на другие аппаратные средства. Узлы меняли свою дислокацию на территории страны. И ни разу не было зафиксировано ни одно сбоя по причини ошибок установки ПО или изменения конфигурации узлов. "Косяки" при обслуживании БД были, проблемы связи — были, внесенные ошибки в отдельную функциональность — были, проблемы со смежными системами, влияющими на работоспособность — были.
Это противоречит практикам стабильного развертывания. Вы Хамбла/Фарли не читали?..
В промышленных системах непрерывной доступности не нужно быстрое развертывание. Там нужна плановость и управляемость, а так же свобода действий эксплуатирующей организации, что она по своему усмотрению могла менять конфигурацию исходя из текущих потребностей. Вы же когда меняете конфигурацию СУБД к ее производителю не обращаетесь, чтобы он вам собрал новый пакет СУБД исходя из ваших потребностей.
Простите за прямой вопрос: а как вы меняете конфигурацию в продакшн-системах?
А еще один тест вашего "решения". Заказчик начнет плановое обновления аппаратной среды, т.е последовательно будет проводить перемещение своих узлов системы на новые аппаратные средства, что ему по каждому чиху к вам обращаться за новой сборкой каждого узла? Перемещение одного узла может повлечь изменения конфигурации всех узлов! ваше решение будет просто ужас для заказчика
Пакет собран и развернут, конфигурация внешний объект по отношению в собранному и развернутому пакету. Тем более речь идет о системе с множеством узлов и у каждого узла может быть собственная индивидуальная конфигурация. ПО везде одинаковое, а конфигурация везде разная. Будете ваши пакеты под каждый узел собирать? А если их 40 штук? А завтра заказчик захочет 1000 иметь? Что будете делать?
Совершенно верно — гораздо лучше и гораздо удобнее. Доказано практикой. Не сталкивались вы с подобными проблемами, не можете осознать преимущества подобного подхода.
Все без исключения ошибки инициализации ловятся. Если заметили выдается предупреждение, а не сообщение об ошибке. То есть данная вид ошибок классифицирован, как не критическая ошибка и система может далее загружаться.
Моя точка зрения остается неизменной — изменение конфигурации не является изменением ПО. Для меня ваши аргументы не убедительны. Давайте закроем эту тему, она не относится к теме публикации.
Сегодня я отвечаю на множество вопрос и не только здесь и не только по этой теме, мог что то и пропустить.
Эту операцию выполняют администраторы, либо они сами знают что хотят изменить, либо выполняю данные рекомендации.
Любите Вы ходить "по кругу"
Да в продакшен, на пассивных узлах — узлах не несущих нагрузки. После внесения изменений в конфигурацию и проверки функционирования узла он возвращается в систему.
Ни в коем случае, лишь отметил, что они тоже могут ошибаться.
Существует немало технологий, которые в свое время активно продвигались в том числе лидирующими на рынке IT — компаниями и о которых сейчас ни вспоминает. Так что лидеры IT рынка тоже ошибаются.
У Вас свое представления — как правильно, у меня — свое. возможно мы оба правы. Но у меня пока нет причин менять свою точку зрения.
"опыт ошибок трудных"
ответил ниже
Тогда странно слышать от Вас некоторые вопросы, при наличии опыта то.
В 2003 году развернул свою первую распределенную систему — реального времени. Масштаб развертывания — вся страна (напомню, у нас много часовых поясов). Система находится в эксплуатации до сих пор. Узлов системы много. С тех пор многократно менялось ПО системы. Происходила миграция узлов на другие аппаратные средства. Узлы меняли свою дислокацию на территории страны. И ни разу не было зафиксировано ни одно сбоя по причини ошибок установки ПО или изменения конфигурации узлов. "Косяки" при обслуживании БД были, проблемы связи — были, внесенные ошибки в отдельную функциональность — были, проблемы со смежными системами, влияющими на работоспособность — были.
многолетней практикой эксплуатации распределенных систем
с проблемами эксплуатации распределенных систем
В промышленных системах непрерывной доступности не нужно быстрое развертывание. Там нужна плановость и управляемость, а так же свобода действий эксплуатирующей организации, что она по своему усмотрению могла менять конфигурацию исходя из текущих потребностей. Вы же когда меняете конфигурацию СУБД к ее производителю не обращаетесь, чтобы он вам собрал новый пакет СУБД исходя из ваших потребностей.
В продакшен, а каких же еще?
А еще один тест вашего "решения". Заказчик начнет плановое обновления аппаратной среды, т.е последовательно будет проводить перемещение своих узлов системы на новые аппаратные средства, что ему по каждому чиху к вам обращаться за новой сборкой каждого узла? Перемещение одного узла может повлечь изменения конфигурации всех узлов! ваше решение будет просто ужас для заказчика
Пакет собран и развернут, конфигурация внешний объект по отношению в собранному и развернутому пакету. Тем более речь идет о системе с множеством узлов и у каждого узла может быть собственная индивидуальная конфигурация. ПО везде одинаковое, а конфигурация везде разная. Будете ваши пакеты под каждый узел собирать? А если их 40 штук? А завтра заказчик захочет 1000 иметь? Что будете делать?
Совершенно верно — гораздо лучше и гораздо удобнее. Доказано практикой. Не сталкивались вы с подобными проблемами, не можете осознать преимущества подобного подхода.
На каком? На этапе написания кода? Код не изменялся, ловить там нечего!
А Вы доказать вашу правоту не можете. И кто из нас прав?
Все без исключения ошибки инициализации ловятся. Если заметили выдается предупреждение, а не сообщение об ошибке. То есть данная вид ошибок классифицирован, как не критическая ошибка и система может далее загружаться.
Не знаком с этим продуктом, может вы и правы. Я подобных решений не видел.
Моя точка зрения остается неизменной — изменение конфигурации не является изменением ПО. Для меня ваши аргументы не убедительны. Давайте закроем эту тему, она не относится к теме публикации.