hint000

Можно ли поставить резервный контроллер домена если версии сервера отличаются?

Можно в том случае, если у вас сейчас установлен уровень леса и уровень домена не выше, чем 2012. Более новые версии сервера совместимы с более старыми уровнями домена и леса, наоборот - нет. Наверняка у вас по умолчанию уровень 2016, в этом случае не получится. Повысить уровень легко. Понизить - я не знаю способов, кроме как полностью снести домен и поднять заново. Для ознакомления первая попавшаяся нагугленная статья:
https://userman.ru/2019/03/26/kak-opredelit-povysi...

"Добавление сервера в контроллер домена"

Вряд ли так кто-то писал. Либо добавление сервера\ПК в домен, либо повышение роли компьютера до контроллера домена. Второе - это то, что вам нужно. Второй контроллер ничем не отличается от первого, давно уже не актуально понятие BDC (резервный DC). Подробный мануал не нужен. Всего лишь:
0) загоняете новый сервер в домен (если не уже);
1) добавляете на сервер роль AD DC;
...и всё :)

Если под словом "сервер" подразумевается железо, то...
в первом приближении архитектура сервера не отличается от архитектуры ПК. Есть лишь отдельные "серверные" компоненты, более навороченные функционально. Но архитектурно ничего необычного там нет. Об этом нет смысла писать книги. Ну ECC-память, ну IPMI, ну полноценные RAID-контроллеры, ну крутой сетевой адаптер на борту, ну FC (fiber channel), ну расширенные средства диагностики, ну поддержка двух БП, ну регистровая память (чтобы запихнуть её побольше), ну мультипроцессорность. Всё это фигня, ничего принципиально необычного для ПК там нет.

ну как вы посмотрите прямо сейчас, если после отрубания нагрузка уже прекратилась?
А вообще утилита iotop отлично показывает нагрузку на диски.
Также можно htop - она более универсальная, отображение скорости ввода-вывода процессов там можно легко добавить в настройках.

время исполнения заметно растёт при вызове функции и входа в неё

То, что время растёт - это закономерно. Но вот заметно расти будет в том случае, когда функция вызывается внутри цикла и цикл исполняется сотни..тысячи раз. Единичные вызовы не должны давать сколько-нибудь заметного замедления.

WD Blue - это дешевые диски потребительского уровня. Как и другие подобные диски, они не рассчитаны на установку в системный блок в количестве более 2 штук (хотя в явном виде производитель это нигде не заявляет). Чем больше дисков установлено, тем сильнее вибрация всего системного блока. Сами диски не очень рады этой вибрации. Но диски корпоративного (enterprise-) класса делаются так, чтобы продолжать нормальную работу при более высоком уровне вибрации, их нормально ставить по 8 штук в сервер (иногда и больше), но и цена на такие диски гораздо выше. Ну а у потребительских дисков в таких условиях производительность упадёт до плинтуса (они будут сбиваться и перечитывать сектора по несколько раз); может быть и умрут они раньше срока - тут не обещаю, как повезёт.
Хотите ставить 8 дисков в один сервер - покупайте диски WD Gold или аналоги других производителей.

Интересный вопрос, но боюсь, что все варианты будут костылями со своими недостатками. Судите сами: ввод-вывод должен быть заблокирован и одновременно не заблокирован (обычно так начинаются задачи в ТРИЗ, хе-хе).
Но нужно же предложить хоть один такой костыль. Это RDP. Локально комп заблокирован, но доступ по RDP есть. Основная задача работает на реальном железе, но управляющая задача (pyautogui) может крутиться на виртуальной машине и соединяться с основной по RDP. Ведь для управляллки скорость не критична? Но я не знаю возможностей pyautogui, надо разбираться, нет ли каких-то препятствий для такой схемы.

Если бы там был адрес реального клиента, то nginx и ответ отправил бы реальному клиенту.
Ситуация: 192.168.1.100 отправляет запрос на 192.168.1.2, а получает ответ от 192.168.1.3, от которого он ничего не ждёт. Клиент не знает, что ему делать с неожиданным ответом неизвестно от кого, и выбрасывает ответ в мусор. В итоге ничего не работает. Вот чтобы такого не происходило, оно и работает так, как вы наблюдаете. Типа прокси.

• iftop для первоначальной грубой оценки
  
• tcpdump для детального вынюхивания
  

Неверное имя пользователя или пароль

уже гораздо яснее. Могу сделать ставку на то, что ваш сервер прямо сейчас брутфорсят. И что защиты от этой угрозы на уровне файервола или VPN у вас нет. И ещё у вас какое-то простое и популярное имя пользователя на этом сервере (что-нибудь типа pavel или user1 или admin). Имя случайно угадали, идёт перебор паролей и учётная запись пользователя блокируется на некоторое время. Но когда вы зашли на сервер, то вам уже пофиг на блокировку, т.к. аутентификация для вас прошла и вы спокойно работаете, хотя в это время ваша учётка уже может быть заблокирована. Но повторно не зайдёте, пока не разблокируется по тайм-ауту.

Решение проблемы: усилить безопасность на уровне сети (файервол, VPN). Придумать более замысловатое имя пользователя (sidorov.f.e, user39021, admin-na-vse-ruki,..)

Решение методом зарывания головы в песок: отключить политику блокировки учётных записей при вводе неправильного пароля.