Мы получили это JavaEE WebApp (JSP+Struts+Hibernate+MySQL), которое в настоящее время работает на одном сервере. Из-за роста веб-сайта и проблем с производительностью мы решили кластеризовать проект на нескольких машинах. Веб-сайт должен выдерживать что-то около 5000 запросов в секунду. После некоторого гугления и чтения материала я пришел к нескольким стратегиям, чтобы сделать это:
- Использование Apache в качестве front-end Load Balancer и обратного прокси-сервера, несколько экземпляров Tomcat, каждый на отдельной машине, и, наконец, сервер БД, работающий под управлением MySQL. Экземпляры Tomcat могут масштабироваться при необходимости.
- С использованиемNginxкак front-end Load Balancer и обратный прокси. Остальное будет таким же, как указано выше.
- С использованиемHAProxyкак front-end Load Balancer и обратный прокси. Остальное будет таким же, как указано выше.
Я полагаю, что в вышеупомянутых подходах весь трафик должен проходить через фронтенд-балансировщик нагрузки (сервер Apache, Nginx или HAProxy). Это делает фронтенд-сервер узким местом и также SPOF. Так ли это? Может ли один фронтенд-сервер выдержать весь трафик большого веб-приложения?
Чтобы обойти эту проблему, я придумал своего рода самодельную стратегию:
- Размещение страницы входа и действий аутентификации на внешнем сервере (например, он будет доступен с myapp.com). Когда пользователь успешно входит в систему, он перенаправляется на один из внутренних серверов (например, srv1.myapp.com) и продолжает свою деятельность там.
Итак, на правильном ли я пути?
Поделитесь со мной своим мнением об этих подходах, и если вы думаете о лучшем подходе, пожалуйста, упомяните его здесь.
решение1
Размещение страницы входа на сервере frontend и перенаправление на backend — плохая идея. Пользователи могут добавить ваши backend-серверы в закладки, вы можете получить неравномерное распределение, и когда сервер выйдет из строя, пользователи все равно будут пытаться попасть на него, если они находятся в том же сеансе.
Вам нужен активный/пассивный (Сердцебиение/Кардиостимулятор/IP-отказоустойчивость/DNS-отказоустойчивость) или активный/активный (DNS-циклический перебор/балансировка сетевой нагрузки) фронтенд-серверы.
При использовании активного/пассивного режима весь ваш трафик будет перенаправлен на один фронтенд-сервер, а второй будет находиться в режиме ожидания (горячий резерв). Когда первый сервер выйдет из строя, вам придется каким-то образом выполнить аварийное переключение (Ether, переназначив IP-адрес или изменив DNS*), чтобы указать на второй сервер.
При использовании active/active у вас будет два (или более) постоянно активных сервера, использующих эфирDNS-циклический переборилиБалансировка нагрузки IP/сетичтобы распределить нагрузку (примерно) равномерно между ними. Затем два сервера снова распределят нагрузку на ваши внутренние серверы.
Метод «активный/активный» используется большинством крупных веб-приложений (посмотрите на записи DNS Youtube/Google/Twitter/Wordpress.com/Tumblr, и вы увидите, что у них есть несколько IP-адресов для серверов для циклического перебора DNS).
После того, как вы приняли это решение и реализовали его, все, что у вас есть, это выбор между решениями. Лично я бы предложилNGINXно у каждого свои предпочтения (HAProxy,Кальмар,чероки,Скорость света,Ф5(аппаратное обеспечение),Циско(аппаратное обеспечение) и бесчисленное множество других).
К сожалению, на этот тип вопросов мы не можем просто сказать "сделайте это", потому что это действительно зависит от ваших требований. Изучите некоторые из ключевых слов выше, и если у вас есть какие-либо конкретные вопросы, не стесняйтесь спрашивать.
*По возможности следует избегать отказоустойчивости на основе DNS, поскольку некоторые клиенты кэшируют DNS сверх его TTL, поэтому этот вариант не идеален.
решение2
Я не знаю, как обстоят дела с nginx, но вы можете объединить несколько балансировщиков нагрузки haproxy в конфигурации «активный/пассивный», чтобы haproxy не стал единой точкой отказа.
Существуют также коммерческие решения, но по какой-то причине они не получают столько внимания на serverfault.