Web-Hosting-Server-RoomРассмотрим технические вопросы. «Что же можно улучшить?» Предела совершенству нет, для начала разделим на две части систему «back-end» и «front-end». На «front-end» приходят все запросы, далее этот сервер распределяет их между прочими серверами «back-end». Может показаться, что это самая идеальная схема, однако, что произойдет, если сломается «front-end»?

Действительно, безграничное количество «back-end» не исправит ситуацию, если сервера «front-end» нет. Следовательно, необходимо разработать альтернативное решение для этой проблемы. Для этого нужно подняться выше, этот уровень — маршрутизирующее оборудование. Именно сюда на уровне IP пришел пакет, и находится в пределах досягаемости системы, однако не успел достичь ваших серверов и есть шанс перенаправить пакет, вмешавшись в процесс.

Куда его направить?

Момент конечно интересный и существует много решений: к примеру, если ваш роутер с поддержкой Web Cache Communication Protocol (WCCP), то его можно использовать. Суть сводиться к тому, что если «front-end» живой и отвечает роутеру на запросы регулярно или оповещает его, роутер пакет перехватит и направит его на «front-end». Однако, когда с «front-end» связь потеряна, роутер направит запросы непосредственно на один или несколько «back-end», это зависит от типа настроек и желания.

Даже если нет роутера, есть огромное поле деятельности. В роутер превратить можно простой сервер, при помощи систем pf, iptables, ipfw. Вы сами можете управлять при написании простых программ. Если к этому подключить еще и, к примеру, Common Address Redundancy Protocol (CARP), то можно продублировать этот сервер. Тогда при поломке одного, другой подхватит работу, при этом увеличив надежность вашей системы. Больше того, имея такие системы, проще бороться с насущной проблемой Distributed Denial of Service (DDOS). Поскольку вы исключите попадание негативного трафика на сервера облачного хостинга, и этим защитите их.

«Что еще можно улучшить?»

Нет проблем, рассмотрим почтовую систему, здесь самое важное не допускать ошибок. К примеру, по всем почтовым протоколам клиентам выдать одно имя типа mail.domain.ru. Однако, расширяясь, придется вам разделять это имя по различным протоколам, не ленитесь, и для различных протоколов зафиксируйте отдельные имена: imap, pop, smtp, если даже пока они идут на один сервер. При необходимости можно легко отделить протоколы imap от pop и smtp, при этом для надежности, smtp разделить можно на два отдельных сервера: исходящей и входящей почты.

При увеличении количества исходящих или входящих сообщений, можно увеличивать число smtp серверов. В исходящих сообщений использовать можно нескольких ip адресов в сервере dns. Тогда по round-robin алгоритму исходящий -будет выбираться клиентом согласно подбору адресов в круговом цикле.
Аналогичные мероприятия можно выполнить на серверах входящей почты, однако для управления процессом есть еще один инструмент, куда доставить почту, которая идет на домены клиентов (паркуем домен к хостингу). Параметр MX, запись типа в dns, он указывает на mail-exchange, обслуживающие почту для доменов. В этом типе записи указывать можно приоритет каждого сервера либо множества компов, при этом контролируя порядок и сервер доставки писем для ваших клиентов.

Протоколы pop и Imap проще, по своей сути, находиться они должны рядом с большим почтовым хранилищем, чтобы не ограничивать клиентов в размерах ящика. Для этого подойдет любой сервер, имеющий большие диски, лучше, конечно, использовать системы raid — исходя из информации на сайте hostmanual.ru. Они обеспечат надежность хранения почты в случае, если вы хотите брать за это деньги.

С почтой разобрались, чем заняться еще…