Comments 24
если я правильно понял, написанные ранее под tomcat приложения можно будет без труда деплоить на сервера в облаке? или необходимо добавлять в проект определенные конфиги?
мне вот что всегда интересовало тв смысле масштабирования. Масшатбироваться в пределах одного сервера (ресурсов доступных с одного сервера железного) — это не очень интересно. Понятно, что 16 и даже 64Гб памяти — это пределы серверов, поэтому среди клауд и обычных впс нет предложений с большим обьемом. А вот прозрачное распределение одного неделимого приложения на возможности большего чем один сервер — вот это дело :)
Почему не очень интересно? Смотря для каких задач, большинству проектов этого достаточно.
Опишите детальнее что означает в вашем понимании «неделимое». Лучше на примере. Порассуждаем…
Опишите детальнее что означает в вашем понимании «неделимое». Лучше на примере. Порассуждаем…
ну веб-сервер он обычно можно запустить две копии и балансировать между ними. А неделимое приложение — это типа фотошопа. вот сколько на компьютер можно поставить памяти, столько ему доступно. не больше.
Вообще тема интереса с чисто технологической точки зрения, мы как-то в команде активно на эту тему рассуждали. Более того есть решения, которые виртуализируют ОС и проксируют логику на дополнительном кармане с памятью. Т.е. к примеру у вас сервер был на 8Гб, вы можете подключить комп-карман на 100Гб, но все равно это будет одна неделимая железка.
С другой стороны, какова реальная необходимость подобной задачи? я персонально не знаю ни одного такого неделимого java приложения, но отрицаю что они могут быть…
С другой стороны, какова реальная необходимость подобной задачи? я персонально не знаю ни одного такого неделимого java приложения, но отрицаю что они могут быть…
Правильно ли я понял вы говорите что у вас одно приложение работает целиком на одном хосте?
Как быть с тем что этот один хост упадет?
А как быть с GC и скоростью выделения памяти на 16Гб куче?
Как быть с тем что одно приложение может съесть всю память JVM и остальным не достанется?
Как насчет PermGen? Особенно если часто проиходит redeploy большого приложения?
Как быть с тем что этот один хост упадет?
А как быть с GC и скоростью выделения памяти на 16Гб куче?
Как быть с тем что одно приложение может съесть всю память JVM и остальным не достанется?
Как насчет PermGen? Особенно если часто проиходит redeploy большого приложения?
супер! спасибо за вопросы, большинство из них попадет в FAQ.
> Правильно ли я понял вы говорите что у вас одно приложение работает целиком на одном хосте?
правильно. но это только один из возможных вариантов построения топологии приложения, самый простой.
> Как быть с тем что этот один хост упадет?
для этого надо выбрать HA топологию, с резервными нодами, естественно будет стоит дороже. Доступность в платформе таких топологий появится во втором релизе, через месяц.
> А как быть с GC и скоростью выделения памяти на 16Гб куче?
отличный вопрос. все хорошо с этим делом. пока не могу ответить полноценно. у нас есть секретный соус, но детально распишу после второго релиза. посмотрите на график, скорость роста очень резкая. Все юзеры пришли практически одновременно. Горизонтальное масштабирование может не справится с такими скоростями роста.
> Как быть с тем что одно приложение может съесть всю память JVM и остальным не достанется?
отличный вопросище! ответ — срочная евакуация, миграция на более свободные ресурсы.
> Как насчет PermGen? Особенно если часто проиходит redeploy большого приложения?
никаких проблем, вы можете выставить свой требуемый PermGen. В добавок Hot redeploy мы не разрешаем, при редеплое сервер рестартует, дабы не было утечек. В связке с HA топологией рестарт нод идет последовательно.
> Правильно ли я понял вы говорите что у вас одно приложение работает целиком на одном хосте?
правильно. но это только один из возможных вариантов построения топологии приложения, самый простой.
> Как быть с тем что этот один хост упадет?
для этого надо выбрать HA топологию, с резервными нодами, естественно будет стоит дороже. Доступность в платформе таких топологий появится во втором релизе, через месяц.
> А как быть с GC и скоростью выделения памяти на 16Гб куче?
отличный вопрос. все хорошо с этим делом. пока не могу ответить полноценно. у нас есть секретный соус, но детально распишу после второго релиза. посмотрите на график, скорость роста очень резкая. Все юзеры пришли практически одновременно. Горизонтальное масштабирование может не справится с такими скоростями роста.
> Как быть с тем что одно приложение может съесть всю память JVM и остальным не достанется?
отличный вопросище! ответ — срочная евакуация, миграция на более свободные ресурсы.
> Как насчет PermGen? Особенно если часто проиходит redeploy большого приложения?
никаких проблем, вы можете выставить свой требуемый PermGen. В добавок Hot redeploy мы не разрешаем, при редеплое сервер рестартует, дабы не было утечек. В связке с HA топологией рестарт нод идет последовательно.
Спасибо за ответы.
Просто во все эти вопросы я уже «утыкался». И нормального решения не нашлось. В результате получилась инфраструктура с «тонкими» нодами, с кластером + failover + load balancing.
Только проблема в том что нет системы управления этой солянкой.
Просто во все эти вопросы я уже «утыкался». И нормального решения не нашлось. В результате получилась инфраструктура с «тонкими» нодами, с кластером + failover + load balancing.
Только проблема в том что нет системы управления этой солянкой.
> И нормального решения не нашлось
вот наша задача и дать хорошее решение, или хотя бы максимально упростить жизнь. Мы тоже натыкались на эти вопросы и не раз. Мы проводим «фундаментальные» исследования в этой области.
Горизонтальное решение тоже планируется, никуда от него не деться, нет одного универсального решения. Одним надо одно, другим другое.
вот наша задача и дать хорошее решение, или хотя бы максимально упростить жизнь. Мы тоже натыкались на эти вопросы и не раз. Мы проводим «фундаментальные» исследования в этой области.
Горизонтальное решение тоже планируется, никуда от него не деться, нет одного универсального решения. Одним надо одно, другим другое.
Кстати, в CloudFoundry, чтобы не терять клиентов при деплое новой версии, сделали такую штуку — вначале деплоится на другой инстанц, затем URL мапится на новый инстанц, дальше старый инстанц выгружается.
Да, банально — упал проект и всё — кердык — 504 internal error. А когда есть другие инстанцы, которые автоматом поднимаются — вот это дело. Тогда один упал — другой тут же подхватил.
другие инстанцы, которые автоматом поднимаются (балансировка нагрузки — LB) и кластеризация (высокая доступность — HA) это отличительные вещи. Чтобы обезопасить от 500 ошибок во втором релизе будет возможность поднять резервную ноду, выбрать HA топологию приложения.
возможно вам будет интересны результаты тестов, они добавлены в статью
Ребята, здравствуйте! Виделись на JavaOne. Я — ByteFy.
Вопрос. Как вы решаете вопрос с http сессиями? Или с server side jsf state?
Вопрос. Как вы решаете вопрос с http сессиями? Или с server side jsf state?
Жду анализа нагрузки после хабра :)
И все-таки я не понял момент с памятью.
Запустили вы JVM с -Xms1G -Xmx16G, приложение поработало с вечерней загрузкой, отъело у ОС 12 гигабайт, например. Затем наступила ночь и фактическое потребление упало обратно до 1 гига (то есть оно сначала упало, а потом когда-то там GC сделал очистку, после чего мы установились на 1 гигабайте хипа).
JVM-то операционке ничего не отдала, так каким образом вы сделали тарификацию по фактическому потреблению памяти? Предположу, что это как-то связано с cloudlet-ами, но одноименная страничка на сайте технического содержит мало. У меня есть смутное подозрение, что приложения работают внутри одной 16-гиговой JVM, но это, кхм, выходит shared-хостинг для явы.
Запустили вы JVM с -Xms1G -Xmx16G, приложение поработало с вечерней загрузкой, отъело у ОС 12 гигабайт, например. Затем наступила ночь и фактическое потребление упало обратно до 1 гига (то есть оно сначала упало, а потом когда-то там GC сделал очистку, после чего мы установились на 1 гигабайте хипа).
JVM-то операционке ничего не отдала, так каким образом вы сделали тарификацию по фактическому потреблению памяти? Предположу, что это как-то связано с cloudlet-ами, но одноименная страничка на сайте технического содержит мало. У меня есть смутное подозрение, что приложения работают внутри одной 16-гиговой JVM, но это, кхм, выходит shared-хостинг для явы.
> JVM-то операционке ничего не отдала
отдала, и если надо потом обратно возмет и еще раз отдаст. как-то был один человек, который на High-Load++ во время моей демонстрации кричал — это невозможно!!! я не зря сделал теги с топику «невозможное возможно».
На графиках показано потребление памяти операционной системой, это не heap JVM, а именно системная память.
отдала, и если надо потом обратно возмет и еще раз отдаст. как-то был один человек, который на High-Load++ во время моей демонстрации кричал — это невозможно!!! я не зря сделал теги с топику «невозможное возможно».
На графиках показано потребление памяти операционной системой, это не heap JVM, а именно системная память.
забыл ответить — каждое приложение работает внутри отдельной виртуальной ОС.
Кстати спасибо за вопрос, очень правильный.
Кстати спасибо за вопрос, очень правильный.
Sign up to leave a comment.
Vertical Scaling in Java Cloud