Очерёдность локейшенов не имеет отношения к последовательности их применения, почитайте. Видимо, у вас запросы к скриптам обрабатываются в какой-то другой, более глобальной ветке конфига.
Адреса, которые можно использовать независимо от провайдеров ЦОДов называются PI-адреса, они покупаются сразу пачкой от /24 и требуют некоторых телодвижений технического и организационного характера (регистрация ASN, настройка BGP-анонсов). В связи с исчерпанием IPv4-адресов всё стало ещё запутаннее, теперь наиболее реалистичный сценарий получения - это покупка на вторичном рынке.
Как это "при скачке устанавливается другая версия"? Вот отсюда пробовали? То, что при установке метапакета 5.0 ставится самая последняя минорная версия - это нормально.
Имеется три сервера - и что вы с ними хотите сделать?
По контексту подозреваю, что вы хотите какой-то кластер создать, но Заббикс так не умеет. Для распределения нагрузки используются zabbix-proxy, для обеспечения отказоустойчивости - реплики БД и остального ПО (см. например).
Если под "не потерять сессию" вы имеете в виду процесс, который у вас выполняется в терминале, то можно его отправить выполняться в фоновый режим с помощью Ctrl+Z, bg, открыть screen/etc, а потом вернуть его через fg.
Administration > Media Types. Внутри добавляете новый тип "Script", указав его имя и замапив нужные параметры. Скрипт должен лежать в каталоге, указанном в директиве AlertScriptsPath.
Программы, собирающие данные с устройства и показывающие на их основе графики, называются системами мониторинга - выбирайте любую, хоть тот же Заббикс.
Никто обычно не реплицирует "весь сервер", это делается для конкретных компонентов, и, в зависимости от их специфики - по-разному. Можно настроить распределённую файловую систему, но для СУБД, например, такой вид репликации не подходит, потому что не обеспечивает консистентность данных.
Всё верно, iops обычно отличается при разных профилях нагрузки - разные блоки, последовательная или рандомная запись, регулярная или с периодическими пиками, параллельность. Именно поэтому нельзя посмотреть на какую-то одну цифру и сказать, что устройство хранения идеально подходит для задачи.
На устройствах ничего прописывать и не нужно - достаточно, чтобы роутер, являющийся для той сети шлюзом, знал, куда отправлять пакеты для 10.10.10.3. Ну и впн-сервер, соответственно, понимал, что делать с этими пакетами.
Огромные таблицы однотипных и упорядоченных по времени данных - это моветон. Партиционирование таблиц по дням/месяцам и схлопывание старых данных в агрегаты должны помочь - именно так, например, происходит в БД Заббикса.
У пинга (линуксового, по крайней мере) есть возможность указать IP-адрес или интерфейс, с корого поедет пакет. Если ваша специфическая железка такого не умеет - возможно, имеет смысл пинговать гугл откуда-то из-за неё, с более умного устройства.
А почему, собственно, у вас данные после фронтэнда ходят по такой сети, что требуется шифрование?
Даже если это какая-то географически-распределённая структура, то обычно её объединяют в защищённую виртуальную локальную сеть. Если же всё настолько плохо, что не на чем поднять VPN - то, если это HTTP, напрашивается вариант с TLS.
Разберитесь, что означает каждый ключ в обеих ваших командах - на мой взгляд, даже несмотря на то, что я не знаком со спецификой обработанного напильников для 1С постгреса, около половины из них нафиг не нужна.
Возможно, стоит загуглить какие-то стандартные, общерекомендованные решения по бэкапу.
Ваш второй вариант вполне неплох - каждую ночь контрольный ребут с восстановлением состояния из замороженной копии раздела. Пару-тройку раз обнаружат девственно-чистый десктоп - моментально рефлекс выработается :) Главное, чтобы шары были легко достижимы - да хотя бы в виде ярлыков на том же рабочем столе.
