Возникла мысль посадить все наши серверы и домены 3-го уровня на 1 ip-адрес.
То есть, чтобы домены moodle.mysite.org, library.mysite.org, www.mysite.org и т.д. физически были на разных серверах, но в одном помещении и через некий шлюз висели бы на одном канале и одном адресе. В зависимости от имени в запросе запрос перенаправлялся бы на нужный сервер (мы можем себе позволить много дешёвых серверов на базе настольных компьютеров, а один полноценный и надёжный сервер для всех проектов позволить не можем; плюс за каждый проект отвечают отдельные люди и с отдельными машинами меньше проблем с администрированием).
Как это сделать в настройках apache, когда все сервера стоят на одной машине я научился. Но как это сделать, когда все машины отдельно? Можно просто настроить port-forwarding по принципу www.mysite.org:81->moodle, www.mysite.org:82->library, но в идеале хотелось бы, чтобы каждый сайт имел отдельное имя.
Вроде бы как подобное должно организовываться при помощи реверсного прокси, однако как именно, и какой лучше использовать, я так и не понял.
Кроме того, прокси "гасит" информацию об ip-адресе клиента и могут возникнуть сложности со всеми элементами безопасности, завязанными на ip-адреса.
Правильно ли я мыслю или есть какие-то более простые решения в этой области?
Есть ли опыт работы с moodle за реверсным прокси, может ли он там работать? Есть ли при этом повышение производительности?
Можно ли настроить apache, чтобы запросы на некоторые виртуальные сервера просто перенаправлялись бы на другие машины?
У нас работал moodle за nginx. nginx администрирую не я, потому деталей рассказать не могу. В нашем вузе так половину сайтов работают, которые без реальника.
Google по запросу nginx reverse proxy выдает достаточно много статей:
http://kovyrin.net/2006/05/18/nginx-as-reverse-proxy/lang/ru/
http://webo.in/articles/habrahabr/58-nginx-reverse-proxy/
и т.п.
Лично меня не устраивало в такой схеме то, что я хотел отдавать контент сжатый, а nginx отдавал несжатый. Все это, само собой, настраиваемо, но у нас в рамках института свои организационные заморочки.
> Есть ли при этом повышение производительности?
Классически nginx хорошо обрабатывает медленных клиентов, пожирая при этом меньше памяти. Основное условие nginx на одной машине, обработка php на другой. Если все на одной, то выигрыш может получиться и не настолько велик. Но у Вас явно будет не такой случай
А вот настраивать апач как reverse proxy, на мой взгляд, смысла нет. nginx по отдаче и работе с медленными клиентами точно выигрывает (в пожирании памяти и других оптимизационных нюансах).
Google по запросу nginx reverse proxy выдает достаточно много статей:
http://kovyrin.net/2006/05/18/nginx-as-reverse-proxy/lang/ru/
http://webo.in/articles/habrahabr/58-nginx-reverse-proxy/
и т.п.
Лично меня не устраивало в такой схеме то, что я хотел отдавать контент сжатый, а nginx отдавал несжатый. Все это, само собой, настраиваемо, но у нас в рамках института свои организационные заморочки.
> Есть ли при этом повышение производительности?
Классически nginx хорошо обрабатывает медленных клиентов, пожирая при этом меньше памяти. Основное условие nginx на одной машине, обработка php на другой. Если все на одной, то выигрыш может получиться и не настолько велик. Но у Вас явно будет не такой случай
А вот настраивать апач как reverse proxy, на мой взгляд, смысла нет. nginx по отдаче и работе с медленными клиентами точно выигрывает (в пожирании памяти и других оптимизационных нюансах).