Обмен данными между узлами (серверами приложений) в облаке

Question

Я создаю веб-приложение Python / Pylons, которое до сих пор обслуживалось одним сервером, теперь я хочу исследовать, как оно будет масштабироваться между несколькими серверами с каким-то балансировщиком нагрузки впереди.

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

Для сеансов я мог бы использовать сеансы на основе файлов cookie: http://beaker.groovie.org/sessions.html#cookie-based

Для пользовательских данных и кеша (которые в настоящее время хранятся в локальной файловой системе) мне нужен другой подход, и я не уверен, какой из них лучше всего подойдет. Некоторые из вариантов, которые я рассмотрел:

• Распределенная файловая система
  • В частности, Amazon S3, поскольку я нацеливаюсь на Amazon в качестве облачного провайдера. Тем не менее, я бы хотел, чтобы мой код не становился слишком специфичным для поставщика, поэтому позднее возможно изменение поставщика облака.
• [распределенное] хранилище значений ключей, потребовало бы переписать / абстрагировать части моего кода, которые предполагают, что все данные отправляются в файловую систему
• Каким-то образом вообще избегать совместного использования данных, балансировщик нагрузки может быть очень умен, чтобы направлять запросы на узлы, которые имеют необходимые пользовательские данные / кэш локально. Подождите, это называется шардингом, верно?
• Доступная по сети файловая система, в частности NFS: каталог NFS экспортируется на один (возможно выделенный) узел, все остальные монтируют его. Возможные проблемы, о которых я могу думать:
  • Пропускная способность хоста NFS может стать узким местом
  • Условия гонки, когда несколько клиентов пытаются получить доступ к одним и тем же файлам одновременно

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

Answer 1

Я настоятельно рекомендую вам взглянуть на распределенное хранилище ключей / значений, а не на NFS.

Я бы, вероятно, использовал redis, а не cassandra, поскольку вы в настоящее время работаете в одной системе и хотите масштабировать до двух систем. Cassandra, хотя она и крутая, предназначена для систем с большим количеством операций записи, чем операций чтения, и работает лучше всего, когда у вас есть 3 или более узлов. Redis, с другой стороны, очень хорошо работает с одиночным узлом deamon, по сути, как memcached, но с ошибочной устойчивостью.

Redis тривиально прост в использовании под python, он очень производительный, поэтому до тех пор, пока вы не выполняете миллионы запросов, вам не нужно беспокоиться о разбиении или масштабировании самого Redis, но это аварийное переключение, которое, вероятно, будет самым большим вопрос. Я не развернул его лично, поэтому не уверен, насколько эффективно / легко восстановить все данные, если они потерпят неудачу и вы переключитесь на другую. Если вы думаете, что это вероятно, я бы расследовал это.

Если вы хотите хранить более сложные структуры данных, я рассмотрю MongoDB или один из его эквивалентов.

Answer 2

Кэширование

легко выполняется с использованием стандартного memecached - который может быть распределен по нескольким серверам. NFS звучит как плохая идея, поскольку вам нужно реализовать собственный механизм блокировки, чтобы избежать гоночных условий. Я бы выбрал одно из распределенных решений no-sql, таких как cassandra.