да, в этих логах чисто
стоит посмотреть логи ОС (журналы windows в compmgmt.msc)
также посмотрите логи агента sql
и посмотрите нет ли странных файлов в автозагрузке и заданий в планировщике
возможно периодически запускается какой-то скрипт или процесс и останавливает службу, также посмотрите какие задания у вас выполняется агентом sql, ну и совсем фантастический вариант это отрабатываемые триггеры таблиц или запускаемые процедуры в пользовательских сессиях
Скорей всего вам требуются правила маршрутизации, как написали ниже, следующего вида:
# для микротика
/ip route add dst-address=192.168.2.0/24 gateway=192.168.1.254
# для другого роутера, если он не mikrotik, требуется изменить синтаксис на соответствующий
/ip route add dst-address=192.168.1.0/24 gateway=192.168.2.254
Спасибо за подсказку, а не подскажите как оно работает?
Почитал несколько статей на эту тему, но понял только то, что можно создать виртуальную шару, которая сама по себе будет неким иерархическим списком со ссылками на имеющиеся шары в сети.
И есть возможность репликации. Тут тоже не понял, реплицируется только этот список, позволяя при отказе одного сервера использовать список другого, или всё-таки как-то сами данные реплицируются?
Если мы говорим о развертывании такой системы на уже эксплуатируемой сети, то действительно потребуется либо явное описание сетевых устройств, либо функция автообнаружения (Device Autodiscovery).
Такой функционал уже давно поддерживается большинством систем.
Происходит опрос всех или заданных устройств по snmp или cli в автоматическом режиме. Также представление о сети формируется путём прослушки пакетов таких протоколов как cdp и пр.
Уже обладая всей необходимой информацией о сети, не тривиально будет разрабатывать алгоритм, который учитывает все эти исходные данные при программировании сети.
Безусловно при разработке такой системы прийдётся столкнуться с множеством нюансов и спецификой оборудования вендора, но где нет их (нюансов)? Я убеждён, что такая система сможет решать не только типовые задачи, а проблемы тонокой настройки скрыть для сисадмина и перенести на интерпретатор. В особо сложных ситуациях всегда можно подключиться к оборудование напрямую.
Тут главный вопрос - как быстро будет разрабатываться такая система.
Не понимаю, что специфического в ваших примерах? Причём они проще решаются стандартными способами (рядом команд через cli или snmp). А про костыли.. так это только в идеальном мире без костылей
Не хотел вступать в полемику, но оставлю свои 5 копеек.
Вообще технологический прогресс это нормально. Автоматизация управления сетью снизит затраты на эксплуатацию и упростит работу сисадминам.
Нужно понимать, что размеры предприятий бывают разными, так и организация ИТ очень сильно отличается. Где-то множество ИТ отделов, где-то один сисадмин решает все задачи и ему не знаком термин kpi. Но нужно стремиться работать эффективно. Поэтому иногда случаются сокращения, когда что-то автоматизируют или перестраивают бизнес-процессы и это тоже нормально.
У каждого своя голова на плечах, и если она конечно чего-то стоит, то можно всегда найти другое место работы, где нет автоматизации, или изучить новые технологии и сохранить рабочее место, получив повышение.
Про вендорозависимые системы и snmp всё понятно. Я имею ввиду систему позволяющую буквально программировать сеть, которая построена на разнородном оборудовании.
Вот про ansible не знал, спасибо за наводку. Сейчас курю маны и статьи, но судя по всему он тоже не подходит для этих целей, т.к. предполагает наличие питона на управляемом устройстве.
стоит посмотреть логи ОС (журналы windows в compmgmt.msc)
также посмотрите логи агента sql
и посмотрите нет ли странных файлов в автозагрузке и заданий в планировщике
возможно периодически запускается какой-то скрипт или процесс и останавливает службу, также посмотрите какие задания у вас выполняется агентом sql, ну и совсем фантастический вариант это отрабатываемые триггеры таблиц или запускаемые процедуры в пользовательских сессиях