Может кто уже решал подобную задачу.

Есть один жбос - с нагрузкой не справляется - хочу развернуть ещё один и объеденить в кластер, для распределения нагрузки.

С чего начать ? В какую сторону смотреть  ?

в документацию   больше некуда

Вряд-ли там что-нибудь подобное найдешь. Самый простой способ - поставить JBoss на нескольких серверах и на каждый задиплоить свой вэб аппликейшн. Если им нужны общие файлы - выносишь их на отдельный файловый сервер и расшариваешь директорию для доступа из твоего кластера. Если используешь базу данных, то подключаешь все свои приложения к одному и тому-же серверу баз данных. Далее пишешь сервлет, который проверяет загрузку на каждом сервере и который будет форвардить запросы на менее загруженный.

В документации есть документ "Clustering with JBoss", думаю в любом случае должен помочь хотя в том, чтобы разобраться что проще сделать - использовать средства JBoss или реализовать самому.

во-первых, надо разобраться для чего надо делать кластер на джейбоссе. Джейбосс - это аппсервер, веб контейнер - это всего лишь его компонент, т.ч. рассматривать кластер на джейбоссе в рамках простейших веб аппликейшенов просто глупо. Чаще всего на джейбоссе деплоятся EAR-ники, состоящие из двух частей - серверной и веб. В серверной части лежат все бины и пр. Если разворачивать такие приложения на нескольких джебоссах, где гарантии, что во-первых, все синглтоны, которые я использую, с учетом сериализации/десериализации будут существовать действительно в единичном экземпляре? Вы это как собираетесь контролировать на разных серверах? Если отстроить кластер, то у кластера будут общие спейсы, бины сами разберутся по каким интерфейсам им бегать по локальным или ремоутным на уровне контейнера, получается, такого рода контролем заморачиваться не нужно, все равно грамотно его сделать достаточно сложно. То же самое относится к EJB... Кластер джейбосса, равно как и EJB изначально разрабатывались под распределенные приложения, лично я не понимаю, зачем извращаться, нужно просто изучить документацию...

ПыСы
просто у меня есть тут у знакомых девелоперов яркий пример, у них как раз сделан не кластер а сделаны именно несколько срверов, так вот, приложение достаточно крупное, 60% времени написания, устранения багов и текущей поддержки уходит как раз на синхронизацию серверов и прочую лабудень, с бизнес логикой приложения абсолютно ни как не связаной... оно кому надо?

Это сообщение отредактировал(а) y3u - 29.9.2006, 11:08

Думаю как раз на вэб часть идет наибольшая нагрузка и именно ее следует кластеризировать. 


Да, действительно, пожалуй надо было с него начать   

а вот и ни фига  сервлет отработал и сдох, JSP один раз скомпилилась и стала сервелетом, а больше в вебе ничего и нету... Если хочется разгрузить именно веб, тогда надо сделать томкету связку с апачем, там даже на оффсайте написано по каким причинам 
Ну естественно, за DDOSить можно все что угодно, но тут  уже  дроугой вопрос, тут решается не кластером 

Но сервлет или JSP запустили код который отрабатывает в той же виртуальной машине и соотвественно пожирает ресурсы. Ты наверно говоришь про такую идеальную модель, когда у тебя сервлеты лишь перенаправляют запросы EJB, которые выполняется в своем отдельном Java процессе, возможно даже на другой машине, но гораздо чаще вэб приложение несет в себе тяжелую бизнес-логику и в таком случае кластеризация вполне уместна.

с одной стороны да, но что мешает сделать Runnable и увеличить хип?  Вообще тут можно долго спорить  Это архитектурная задача, которую нужно решать комплексно, начиная с профайлинга.

Она архитектурная до тех пор пока идет разработка, а когда она уже вышла в продакшн - это уже административная задача   


Не совсем понял про Runable, это в смысле новый поток создать? Но он ведь все равно будет крутится в той же виртуальной машине и точно также жрать ресурс, даже больше, так как на новый поток нужны дополнительные затраты. А тюнить сервер до бесконечности также невозможно.

повторюсь, тут можно спорить до усрачки   
Это как раз та ситуация, где во всех случаях нужна башка и прямые руки     




ага, значит поставить новый сервак и увеличить память это сложнее, чем сделать кучу серверов с одним и тем же апликейшыном  Кстати, я так и не услышал ни одного предложения по поводу синхронизации в таком случае синглтонов   

А какие проблемы с синглтонами? Для каждого кластеризированого приложения будет свой личный синглтон, с которым будет работать данное приложение. Синхронизировать их совершенно не нужно и каждый из них будет сериализироватся в своё личное хранилище. Если тебе такая схема не нравится - опиши ситуацию когда она не сработает.


Тема интересная, почему бы её не развить?   



А если приложение ну очень распределённое. Одни юзера сидят в штатах - другие в Австралии, третьи в Москве? Узким местом уже становится сеть. И всем надо одинаково быстро работать.

не совсем справедливое замечание, так как JVM всё равно не сможет адресовать более ~1 ГБт (для крупного приложения этого явно не достаточно) .. так что тут увеличивай не увеличивай хип, - а выше головы не прыгнешь...


приложение таки действительно ну очень распределённое (филиалы по всей украине)

Но в моём случае сервлет на JBoss'е не является точкой входа - запросы проиходят на BEAS(там что - то вроде кластера из  8 серверов уже организовано, но с физич. распределением нагрузки путём случайной маршрутизации), а тот в свою очередь либо обрабатывает их сам - либо форвардит на JBoss(а он пока один, почему так - это уже совсем другая история), причём форвардит посредством вызова уже непосредственно EJB.

Я вот ещё подумал, может достаточно организовать что то вроде "зеркала", например, когда один JBoss выходит из строя, что бы запросы автоматич. перенаправлялись на другой - у JBoss'a есть какие то средства для этого ? (что то подобное видел у WebSpherЫ)

За ссылки на доку спасибо - буду сейчас смотреть. 
Но хотелось бы несколько примеров из личных практик.    


Это сообщение отредактировал(а) KostenkoSergey - 30.9.2006, 11:20