Валентин

netdata

Коллеги выше все верно написали.
Просто подсвечу для вас вот такую штуку x2Go.
Из всего, что я пробовал под Linux, это было самое быстрое.
Но подводные камни, тоже имеются.
Чтобы пощупать можете стартануть с этой статьи:
https://habr.com/ru/companies/ruvds/articles/514894/

в то время (Feb 4 06:18:19) когда сервис остановился без понятной причины:

Это сделали или пользователь или cronjob.
1) посмотрите .bash_history всех пользователей
2) посмотрите какие cron запускаются в это время (/var/spool/cron/crontabs или что-то похожее, плюс /etc/crontab , /etc/cron*)

sudo umount /dev/sd<?>
dd bs=4M if=path/to/input.iso of=/dev/sd<?> conv=fdatasync status=progress

повысить надёжность приложения, разместив его на нескольких серверах

А вы решайте ту задачу которую заявили изначально. Для hot spare никакая балансировка не нужна, от базы простая hot standby реплика.
При необходимости вывести основной сервер реплику базы поднимаете до нового мастера и работаете как на старом сервере.

Для бюджетного веба болезненный вопрос "как быстро перекинуть запросы пользователей на нужный IP". Через DNS даже с маленьким TTL это всё равно долго. Посмотрите у вашего хостера и у Cloudflare раз вы его используете, нет ли у них подходящего решения.

работа по сети достаточно замедляет ответы от БД

На время латентности сети, от этого никуда не деться. В пределах одной стойки можно пренебречь.
Безопасность - разумеется об этом при настройке надо будет подумать.

# svn up /usr/ports
# portupgrade -arR

Я начинаю надо с документации - трудовой договор, обязанности админа.
Далее выходим на знакомство с бухгалтерией и ключевыми лицами предприятия. Можно проставится. Слушаем какой был плохой/классный админ до нас.
Идем в бухгалтерию после "тимбилдинга" и просим предоставить документы на платежи за софт (хотя бы за антивирусы). Попутно ищем в сети и физически сервер, проводим его инвентаризацию хард+софт. Идем к пользователям и составляем перечень софта, установленного на их места, заодно выясняем про доступ (возможен ли Админский или у пользователя админские права стоят). Слушаем что им нужно, не нужно, жалобы. Кстати, можно попутно так найти себе "помощников", то есть тех, кто в компах сечет и картриджи меняет. Таких надо держать под неусыпным контролем и располагать к себе признанием их крутости (говорит на равных и хвалить).

А вот после этого делаем вывод о конторе, составляем перечень софта, который вне лицензионности, идем к руководству с бумагой, о внесении изменений в существующую структуру (купить то-то, переделать то-то и так далее). Это план на 6 месяцев.
После этого можно сканить сеть, резать доступ, закрывать дыры и тп. Почему? Да потому что если босс с бумагой этой не ознакомится или пошлет тебя с ней подальше - то нужно идти подальше от этой конторы.

Нет, не увидят. Точнее увидят, но через некоторое время будет каша из данных. Все дело в том, что файловая система живет не только на диске, но и в памяти компьютера, который сделал изменения.
Вам нужна распределенная файловая система для этого, когда компьютер, сделавший изменения данных, сообщает о них своим партнерам, а партнеры уже обновляют измененные данные.

Представим ситуацию, А создал файл в каталоге, а В перед этим читал этот каталог. В закешировал содержимое каталога и никогда не узнает, что в нем появился новый файл. В случае же распределенной FS, А после создания файла говорит В, чтобы он перечитал каталог.

В вашем случае вариантов несколько.
1) Развернуть GPFS (IBM, платная) или OCFS (Oracle) - это типы shared FS (используется одно хранилище, об изменениях сообщается всем)
2) Развернуть Gluster, lustre, CephFS или что-то подобное - distributed FS (используются отдельные хранилища, об изменениях сообщается всем, данные могут реплицироваться).
3) Если данные не завязаны на файлы - использовать распределенные хранилища/базыданных типа Сeph, S3, Mongo и т.д.

Есть несколько вариантов:
1. Запускать не "голый" KVM, а какое-либо облачное решение nebula\openstack. Там есть возможность передовать в гостя псевдоустройство на котором лежит скриптик и который будет запускаться, а в скрипте уже логика может любая.
2. Использовать систему контроля конфигурации (puppet, chef...). Машины при этом надо будет наливать из заготовленного образа, в котором уже будет присутствовать пакет нужной системы с прописанным в нем сервером.
3. Тоже самое, что и пункт 2, но реализованное через ansible. То-есть после установки гостя, откуда-то натравливается на него ansible и ставит подключает все что надо.

Второй и третий пункты требудт чтобы на машинке после установки работала сеть.