Преимущества развертывания нескольких экземпляров для обслуживания / данных / кэша - PullRequest
2 голосов
/ 27 декабря 2011

хотя у меня большой опыт написания кода.У меня действительно нет большого опыта развертывания вещей.Я пишу проект, который использует mongodb для персистентности, redis для мета-кеширования и play для обслуживания страниц.Я решаю, покупать ли выделенный сервер по сравнению с покупкой нескольких малых / средних экземпляров из amazon / linode (по одному для каждого, mongo, redis, play).Я подумал о компромиссах, как показано ниже. Интересно, кто-нибудь может добавить в список или предоставить дополнительную информацию.Я склоняюсь к (б) покупке двух наборов экземпляров от линод и амазонок, поэтому, если у одного из них произойдет сбой, он перейдет к другому провайдеру.Также, если у кого-то есть какие-либо советы по развертыванию кластера Scala / Maven или инструментов для этого, мы очень ценим.

A.положить все в один экземпляр
Плюсы:

  1. более высокая скорость между базой данных и сервлетом страницы (один и тот же хост).
  2. дешевле.
  3. меньше конечных точек для обеспечения безопасности.

Минусы :

  1. сложнее в управлении.(на мой взгляд)
  2. сложнее обновить один модуль.если возникают проблемы с установкой, это может привести к выходу из строя всей системы.

B.поместите каждый модуль (монго, редис, игра) в разные экземпляры
Плюсы:

  1. шардинг легче.
  2. легчесоздать кластер для одной цели.(т. е. кластер redis)
  3. проще распределять ресурсы между модулями.
  4. менее вероятно, что все сразу выйдет из строя.

Минусы:

  1. пропускная способность между модулями -> $
  2. защищает каждое соединение и конечную точку.

1 Ответ

2 голосов
/ 27 декабря 2011

Я могу комментировать только технические аспекты (не стоимость, удобство обслуживания и т. Д.)

Не упоминается, является ли выделенный экземпляр физическим блоком или просто большой виртуальной машиной. Если приложение генерирует много обращений к MongoDB или Redis, тогда разница будет весьма значительной.

В случае виртуальной машины стоимость операций ввода-вывода, планирования ОС и системных вызовов выше. Эти элементы, как правило, представляют собой важную часть затрат на производительность эффективных удаленных хранилищ данных, таких как MongoDB или Redis, и плата за виртуализацию для них выше.

С системной точки зрения я бы не стал размещать MongoDB и Redis / Play в одном окне, если ожидается, что база данных MongoDB будет больше доступной памяти. MongoDB отображает файлы данных в памяти и полагается на ОС для выполнения обмена памяти. Он предназначен для этого. Других процессов нет. Обмен, вызванный MongoDB, будет иметь катастрофические последствия для времени отклика Redis и Play, если они все находятся на одной коробке. Так что я бы хотя бы отделил MongoDB от Redis / Play.

Если вы планируете использовать Redis для кэширования, имеет смысл хранить его в том же окне, что и сервер Play. Redis будет использовать память, но низкий процессор. Play будет использовать процессор, но не так много памяти. Так что, похоже, хорошо подходит. Кроме того, я не уверен, что это возможно из Play, но если вы используете сокет домена unix для подключения к Redis вместо обратной петли TCP, вы можете увеличить пропускную способность примерно на 50% бесплатно.

...