lubezniy

На роутере 2 проверить настройки проброса соответствующих портов, если он работает в NAT. Возможно, они слетели.

FireBug уже достаточно давно не поддерживается. Замена - встроенные средства отладки.

1. В двух секциях server одинаковое server_name , а прокси настроен только во второй. Потенциально это источник проблемы.
2. Попробуйте выделить сервер-получатель в отдельный блок upstream и в proxy-pass прописать его.

Должно заработать, если подключить рабочие диски в те же порты нового контроллера, в каких диски были на старом.

На Web-сервере могут быть виртуальные хосты, и сервер при обращении к нему будет выдавать содержимое в зависимости от значения параметра Host заголовка HTTP-запроса. Так что мало обращаться по IP, надо ещё и заголовки прописывать.

Саму Windows настроить в режиме "Расширить рабочий стол на этот монитор".

Судя по тексту, скрипт не был исходно предназначен для вызова не Web-сервером и посему считает, что в суперглобальной переменной $_SERVER всегда установлены параметры, относящиеся к обратившемуся клиенту и запросу. Чтобы адаптировать скрипт, можно пройтись по указанным в логе строкам и там заменить текст на:

$_SERVER ["SERVER_PROTOCOL"] на (isset ($_SERVER ["SERVER_PROTOCOL"]) ? $_SERVER ["SERVER_PROTOCOL"] : "http")
$_SERVER ["SERVER_PORT"] на (isset ($_SERVER ["SERVER_PORT"]) ? $_SERVER ["SERVER_PORT"] : 80)
$_SERVER ["SERVER_NAME"] на (isset ($_SERVER ["SERVER_NAME"]) ? $_SERVER ["SERVER_NAME"] : "example.com")
$_SERVER ["REQUEST_URI"] на (isset ($_SERVER ["REQUEST_URI"]) ? $_SERVER ["REQUEST_URI"] : "/")

? - это тернарный оператор, слева от которого указывается булевое выражение, а справа - варианты результата выполнения через двоеточие: слева от двоеточия ставится результат, выдаваемый, если выражение даёт в результате true, справа - если false . isset - функция, проверяющая наличие (в данном случае) элемента в массиве. Есть параметр в массиве $_SERVER - его и возвращаем. Нет - возвращаем какое-нибудь удобное значение по умолчанию (можно подставить своё, чтобы, например, в логах ловить).

Как я понимаю, для таких операций нужно иметь достаточно времени (на время преобразования таблица будет полностью заблокирована, а переписываться в MyISAM она будет вся) и места на диске. И, разумеется, крайне желательно перед выполнением операции сделать бэкап.

Плюс - освоение нового продукта.
Минус - на уровне мартышки, с работой строго по алгоритмам.

php.net/manual/en/function.fsockopen.php

Соединение используется одно? Или каждый вызов создаёт своё?

Как вариант, взять Raspberry Pi. На ней поднять Web-сервер со скриптами, которые бы при получении запроса подавали единицу на конкретный GPIO-порт и нули на остальные. На GPIO-порты вешается или светодиодная подсветка напрямую, если мощности большой не надо, или входы релейного скетча (платы с несколькими реле и транзисторными ключами для них) от Arduino. А в качестве клиента использовать какую-нибудь машинку с браузером и тачскрином вместо мыши. Естественно, между клиентом или Малинкой нужно сделать и настроить сеть (пойдёт даже кросс-оверный патчкорд), а на Малинку подать питание (5В не ниже 2А через MicroUSB-порт). Ну и MicroSD-карта гигов на 8 потребуется, чтобы загрузочный Linux-дистрибутив на неё для Малинки записать.

Будут.

Полагаю, проще будет сделать печатный разъём в виде SIM-карты соответствующего форм-фактора, вывести с него короткий шлейф на механический многопозиционный переключатель с множеством контактных групп по количеству контактов на симке (6 или 8) и цеплять симки к соответствующим позициям. Только аппарат придётся выключать перед переключением. Альтернативные варианты надо изучать; может, получится что-то реализовать через USB-COM.
Вот немного подробностей: https://habrahabr.ru/company/beeline/blog/133388/

Мы, когда делали вебинар, тоже пытались использовать аудиоинтерфейс (по сути переходник с Conon на USB), но качества нормального добиться не удалось, да и уровень громкости был никакой, хотя микрофон был вполне нормальный. В итоге сделали совсем по-другому: взяли простенький трёхканальный микшерный пульт, ему на входы посадили микрофоны и плейер, крутивший музыку, выход подключили к звуковой карте (Creative, модель не помню точно), которая уже по USB цеплялась к выделенному компу с ПО платформы вебинара (на нём ещё была web-камера, через которую шло видео). В ходе подготовки отстроили на микшере нужные уровни по входам и выходу, записали их значения и по ходу мероприятия просто работали ручками на микшере.

Микросервис - это, скорее, не библиотека, а автономный (ключевое слово!) небольшой модуль, выполняющий какие-либо функции. И делается он так, чтобы его можно было свободно перенести не то, что в другую БД, а даже на другое оборудование, поменяв для этого лишь настройки связи с другими частями приложения. Или масштабировать, если задействовать несколько серверов одновременно - каждый со своим экземпляром микросервиса. При проектировании микросервисной архитектуры нужно детально описывать связи между модулями (в т. ч. микросервисами) и передаваемую информацию - вплоть до полного протокола обмена.
По Вашему описанию применение микросервисной архитектуры вряд ли можно считать разумным. SQL-сервер всяко лучше разберётся с выборкой данных из связанных таблиц, чем самопальная архитектура. А масштабироваться при большой посещаемости вполне можно обычным кластером с балансировщиком нагрузки, данные (они же сравнительно редко обновляются?) при этом передавать через репликацию или просто скриптовым деплоем изменений в БД по всем серверам.