Назад | Перейти на главную страницу

рекомендация по оборудованию для веб-приложения tomcat

Мы запускаем веб-приложение в нашей тестовой системе (CentOS), подобное этому - один веб-сервер (apache), два экземпляра tomcat, запускающие одно и то же веб-приложение, одна база данных PostgreSQL - каждый на четырех виртуальных серверах. Приложение [предназначено для] использования тысячами пользователей, а также требует некоторых хранилищ конфиденциальных пользовательских данных. Мы планируем перенести это в производственную систему и попросить совета по выбору подходящего оборудования для этой функции. Я в значительной степени открыт для любых предложений (виртуальных машин, выделенных или смешанных), которые экономически эффективны и лучше всего подходят в этой среде. Я думаю я ищу это instant failover. Может ли кто-нибудь предложить мне спецификацию и любое дополнительное оборудование, которое может потребоваться для работы этих служб?

На мой взгляд, пара вещей: для сервера БД я думаю о выделенном сервере - RAID 1 с зеркалированием для системного диска и RAID10 для БД (локальное хранилище). Или мы должны пойти на какое-то общее хранилище с FC? Самые быстрые диски для tomcat (это узкое место, не так ли?), Round-Robin DNS для аварийного переключения веб-сервера и выделенный GbE на коробку для пропускной способности ввода-вывода в сети. Но мне очень интересно посмотреть, как другие проектируют свою систему (ЦП, ОЗУ, дополнительное оборудование, процессы и т. Д.), Учитывая эти требования. Любой вклад приветствуется и очень ценится. Заранее спасибо. ура !!

На стороне httpd / tomcat мы делаем это так:

на одном сервере запустите один httpd и два экземпляра tomcat на разных портах. Мы используем mod_jk, чтобы общаться с котами через ajp и настраивать mod_jk для балансировки нагрузки между ними (или, в некоторых случаях, активный / пассивный переход при отказе и позволяющий mod_jk выяснить, когда переходить на другой ресурс).

Мы запускаем несколько экземпляров серверов, указанных выше, с фактическим балансировщиком нагрузки оборудования впереди, который общается со всеми httpds. Чтобы справиться с единой точкой отказа, которой является аппаратный балансировщик нагрузки, мы реплицируем всю эту настройку в другом центре обработки данных, а затем используем игры DNS для балансировки нагрузки людей географически с помощью Dynect (который также имеет возможность перенести нагрузку на другой центр обработки данных. при выходе из строя).

Отчасти причина, по которой мы запускаем два экземпляра tomcat на каждом сервере, заключается в том, что мы можем более легко применять обновления программного обеспечения к приложению, не влияя на нашу способность справляться с пиковой нагрузкой. Да, это увеличивает потребность в оперативной памяти в 2 раза, но это намного дешевле, чем удваивать количество систем, чтобы работать так, как мы работаем.

В вашей настройке вы обрабатываете случай смерти одного сервера tomcat, но не интерфейс httpd. Возможно, вам лучше создать пару серверов httpd переднего плана, которые используют heartbeat / corosync / pacemaker для обработки отказоустойчивого интерфейса. Это не будет «мгновенное переключение на другой ресурс», но оно будет близко к нему. Большинство людей могут терпеть несколько секунд, пока все меняется.