Евгений Вольф

Постараюсь по порядку:

Какой мощности должен быть сервер для проксирования? Если я правильно Вас понял, задача заключается в том, что бы поднять/настроить реверс (обратный) прокси. Так как это именно прокси, а не "зеркало" по железкам я бы начал с машину уровня: 2 ядра, 2-4Гб ОЗУ. Диск особого значения не имеет, т.к. это прокси. В теории такой машины для прокси должно хватать вполне. Ключевой упор нужно сделать на скорость порта (сети) этого самого прокси-сервера, т.к. 500Гб в сутки свободно прокачивать может далеко не каждый VPS. При очень хорошем качестве связи порт 100Мбит/сек. (а именно такую номинальную скорость порта предоставляют большинство VPS) может прокачивать около 1Тб/сутки. У Вас трафик 0.5Тб в сутки. С учётом того, что трафик на сайте никогда не бывает равномерным (в какой-то период времени трафик выше, в какой-то ниже, есть какие-то пики по трафику и т.д.), а так же с учётом того, что скорость 100Мбит/сек. на VPS - исключительно номинальная - я думаю стоит искать VPS со скоростью порта 1Гбит/сек.

Может ли снизиться скорость работы сайта при использовании проксирования?Не только может, но и вероятнее всего она снизится. Любой прокси - это дополнительное расстояние которое трафик должен пройти от сервера до клиента (и обратно). Чем дальше прокси будет находится от сервера-источника - тем больше будет просадка по скорости. И опять таки, если у прокси будет недостаточно хорошая пропускная способность (скорость порта) - падение скорости для клиента так же помножится на недостаток пропускной способности.

Безусловно, бывают и обратные случаи, когда сервер-источник стоит где-то далеко, а прокси-сервер где-то рядом с клиентом и до сервера-источника у клиента какой-то очень плохой маршрут (плохая связь), а с прокси-сервером связь хорошая и между прокси-сервером и сервером источником - тоже хорошая связь... в этом случае связь может даже ускориться, но в современных сетях это скорее исключение из правил, я бы на это особо не рассчитывал. Отдельно можно выделить различные кэширующие прокси и CDN, которые ускоряют загрузку... но это Ваш случай.

Какие другие подводные камни могут возникнуть в данном случае?
Ключевой "камень" который в данный момент вижу я - не понятно, зачем оно Вам вообще нужно? На сервере просто изменится IP адрес? - серверу можно добавить сколько угодно IP адресов, можно держать и старый и новый IP на сервере в течение 48-72 часов (цикл обновления DNS), потом старый IP отвязать... Если в какой-то момент у Вас будет 2 копии сайта, старая и новая (с разными соотв. IP) - то тут прокси тоже не нужен, держите просто их две сразу два, потом отключите старый. Или сначала мы делаем прокси на текущий сайт, потом меняем DNS-запись, ждём полного обновления DNS, потом переносим сайт на другой сервер, потом меняем запись DNS ещё раз... - но даже в этом случае, всё равно будет какое-то время простоя на перенос сайта и/или синхронизацию БД (конечно есть способы этого избежать, но это отдельная большая тема).

P.S. Возможно, в Вашем случае, так как мы говорим про прокси 1-1 - имеет смысл настроить прокси не через Nginx, а полностью завернуть трафик на другой сервер? Через какой-нибудь туннель, например, WireGuard + iptables/nftables - это позволит проксировать вообще всё (весь трафик), а не только HTTP/HTTPS и соответственно избежать казусов при прокси через Nginx, в частности, Nginx-прокси может добавлять какие-то свои заголовки, или наоборот, удалять какие-то (да, это всё настраивается, разумеется, но это нужно настраивать и проверять). Потом HTTPS, я не пробовал проксировать HTTPS-сервер через Nginx, но полагаю с этим могут возникнуть какие-то трудности, соотв. нужно будет поднять HTTP на сервере-источнике (это на уровне моих предположений, я не пробовал проксировать через Nginx именно HTTPS).

Так же, предлагаю Вам рассмотреть альтернативные варианты прокси, например HAProxy, гипотетически, использование ПО ориентированного в исключительно на решение задач именно прокси - даст лучший эффект, нежели Nginx, у которого прокси - лишь побочная функция. Так же по этой ссылке Вы можете посмотреть, какие ресурсы потребуются для прокси-сервера (раздел "Производительность").

Стрим будет на 30+ клиентов.

На счёт 30+ клиентов - не могу точно сказать, но демонстрировать рабочий стол так же можно в:
1. TeamViewer (и передавать звук тоже, в режиме конференции в т.ч., мы обычно его используем при проведении закрытых уроков)
2. Skype (в конференции тоже, передачей звука можно что-нибудь придумать)
3. Tox (версия под Windows умеет передавать рабочий стол, под Linux'ом ещё проверить не успел, звук тоже)
4. VNC
5. Есть масса различных расширений для хрома позволяющих демонстрировать экран, возможно среди них Вы что-то найдете для себя
6. Как уже упоминал автор выше - OBS, его прелесть в том, что можно не просто транслировать рабочий стол, но и настроить сцену (или несколько) и в качестве клиента использовать любой современный браузер. В качестве сервера (ре)трансляции можно использовать Nginx. Такой вариант мы обычно используем для проведения публичных трансляций или записи "под ютуб".

На вскидку, вариантов несколько:
1. Вы можете настроить (или запустить) закрытую трансляцию, как Вам уже рекомендовали выше, через какой-то готовый сервис, позволяющий вести трансляцию в закрытом режиме (кажется, GoodGame так умеет), воспользовавшись программой OBS.

2. Вы можете поднять свой собственный RTMP-сервер и транслировать с него. Как это сделать описано например тут. Проблему с NAT'ом - можно решить либо путём приобретения "белого" IP, либо с помощью проброса трафика через другой сервер, у которого "белый" IP уже в наличии, в т.ч. можно воспользоваться различными бесплатными VPN (для этих целей существует масса программ, в т.ч. различные Hamachi, Garena и т.п.), либо же пробросить трафик через VPS/VDS, по VPN, SSH или любым другим удобным способом (на VPS к слову, можно заодно и сайт поднять, с плеером который будет отображать происходящее + сделать защиту доступа к нему).

Есть подозрение, что диск который Вы пытаетесь смонтировать - имеет файловую систему отличную от iso9660, о чём собственно и сообщает команда.

может кто сталкивался на ubuntu с подобной проблемой?

Эта проблема решается довольно легко. Есть такая штука, как "сборщики проектов" различные или другого рода пост-инсталляционные скрипты, в т.ч. к ним (к этой же области) относятся и различные хуки самого GIT'а.

Пишите соотв. скрипт, который будет выставлять нужные права при каждом pull'e или ином действии. Либо же, запускаете этот скрипт руками, в нужный момент и проблема решена.

Точно по такому же принципу, при первом клонировании проекта, в 95% случаев Вам нужно будет запустить менеджер пакетов, что бы "наполнить" папку "vendor". В случае PHP/Laravel - это соотв. будет composer. А ещё не редко бывают различные сборщики на базе NodeJS, аки WebPack или Gulp (и другие), которые так же нужно запускать в тот или иной момент времени...

Почему по этим причинам выбирают Ubuntu LTS вместо надежного (как я понял) Debian?

Надежность - это понятие субъективное в данном случае.

Какая проблема в старых пакетах? - по большому счёту, никакой, кроме того, что они (пакеты) - старые.

Что мешает поставить новые? В целом, - тоже ничего. Но, давайте приведу Вам пример. Вы когда-нибудь пользовались смартфоном на Androide? Если да, я думаю Вы знакомы с такой штукой как "Google play market". А теперь представьте себе, что в этом маркете, все программы будут иметь версии выпущенные несколько лет назад. Что при этом мешает взять и поставить программу с какого-то другого места - в общей сложности - ничего.

PHP там надо запускать в CGI режиме, что существенно снизит скорость работы

Есть же FCGI или как Вы уже успели заметить далее есть PHP-FPM... Из оставшегося, я бы посоветовал PHP-FPM, т.к. он есть уже готовый и настраивается "в два клика".

SSD или HDD лучше для этого использовать?

HDD обычно служат дольше и дешевле за единицу объёма, SSD - быстрее. По этому, "лучше" зависит от контекста.

2. Какая файловая система подойдет наилучшим образом?

Можно попробовать Btrfs, там ограничения на кол-во файлов нет. Не могу пока ничего сказать кардинально хорошего или плохого про эту ФС... для пробы поставил на одну боевую машину, где-то с год с небольшим стоит, полёт нормальный.

3. Как быстро диск от подобного погибнет?

У меня в обычном сервере (небольшая однопроцессорная машина в 4 ядра) лет 5 HDD'шник простоял, под приличной нагрузкой, обычный WD. Потом "от греха подальше" я его сменил.

Поддерживает ли Ubuntu видеокарту GTX 1050? Если да, то где взять драйвера?

Как Вы понимаете, за поддержку устройств отвечает в большей степени не дистрибутив, а ядро и его составляющие. Иначе говоря, если что-то поддерживает дистрибутив "A", с большей вероятностью такую поддержку можно сделать и в дистрибутиве "Б".

Конкретно по Вашему вопросу:
Если судить по сайту производителя - поддерживает, если у вас 64-битная версия, в чем Вы можете убедиться лично, пройдя по этой ссылке, раздел "поддерживаемые продукты". Там же есть и кнопка "Загрузить сейчас".

Какой-то "Расширенный раздел" (объясните плз что это)

Тут подробно написано, что это

Пробовал форматировать sdb5, не получилось.

Отформатировать не получилось?

Подкачка (я так понимаю что-то необходимое)

Это раздел в который сливаются данные из оперативной памяти при нехватке оной, условно говоря, кусок диска который используется как оперативная память когда её не хватает. В новых версиях Ubuntu'ы собирались перенести этот раздел в файл, без создания отдельного раздела (как в винде). Касательно его необходимости - вопрос риторический и философский (с учётом того, что уже на телефонах по 16+ Гб оперативки стоит иной раз).

Вопрос как избавиться от не нужного дистрибутива?

Вам от дистрибутива нужно избавиться или от меню в загрузчике? Если от дистрибутива, насколько я понимаю, он должен быть способен загрузиться. Это так? Если да - просто удалите раздел (совсем) на котором стоял этот дистрибутив и дело с концом. Если же речь идёт про меню загрузчика - довольно хорошо про него расписано здесь.

Если через SSH, то безопасно ли и не возникнет проблем с автоподключением?

Достаточно безопасно и проблем с автоподключением быть не должно, по крайней мере в теории точно (на практике - может случиться что угодно). Ещё есть вариант WebDAV (доступ к файлам через веб-сервер/HTTP-протокол), ещё есть FTPFS (аналогично SSHFS). Но, так как Вы не указали, к чему больше склоняетесь - сложно сказать точнее, что именно "лучше". Безопаснее, пожалуй, SSH-FS будет, т.к. там шифрование трафика "из коробки" и все дела...

На счёт Samba - не знаю, её настройка меня лично не впечатлила, она скорее для тех, я бы скорее поставил её в виду "крайней нужны", при отсутствии других вариантов.

Для Windows-* есть программы, позволяющие подключать сетевые диски (такие же как обычные, через Samba'у), и через FTP, и по моему даже через SSH, и через WebDAV в т.ч. (кстати, если мне не изменяет память, программы на подобии "Яндекс.Диск" работают как раз через WebDAV)

sudo или suid устроят?

P.S. suid на shll-скриптах в подавляющем большинство случаев - не работает... Спасибо тов. jcmvbkbc за подробную информацию.