Скала + Акка:Как разработать многомашинный высокодоступный кластер

Question

Мы разрабатываем серверную систему на Scala + Akka для игры, которая будет обслуживать клиентов на Android, iPhone и Second Life.Некоторые части этого сервера должны иметь высокую доступность и работать на нескольких машинах.Если один из этих серверов выйдет из строя (скажем, из-за аппаратного сбоя), система должна продолжать работать.Я думаю, что хочу, чтобы у клиентов был список машин, к которым они попытаются подключиться, аналогично тому, как работает Cassandra.

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

Есть ли примеры, демонстрирующие такую ​​отказоустойчивость оборудования для Akka?Или у вас есть какие-нибудь мысли о хороших способах добиться этого?

На данный момент лучший ответ, который мне удалось придумать, — это изучить документацию Erlang OTP, поразмышлять над ней и попытаться выяснить, как собрать мою систему, используя строительные блоки, доступные в Akka.

Но если есть ресурсы, примеры или идеи о том, как разделить состояние между несколькими машинами таким образом, чтобы, если одна из них выйдет из строя, все продолжало работать, я бы, конечно, признателен за них, потому что я обеспокоен тем, что могу заново изобрести колесо здесь.Может быть, существует многоузловой контейнер STM, который автоматически синхронизирует общее состояние на нескольких узлах?Или, может быть, это настолько легко сделать, что в документации не удосужились показать примеры того, как это сделать, или, возможно, я еще недостаточно тщательно провел исследования и эксперименты.Любые мысли и идеи будут оценены по достоинству.

Answer 1

HA и управление нагрузкой является очень важным аспектом масштабируемости и доступна как часть AkkaSource коммерческое предложение.

Answer 2

Если вы уже указали несколько потенциальных хостов в своих клиентах, то они могут эффективно стать балансировщиками нагрузки.

Вы можете предложить услугу предложения хоста и порекомендовать клиенту, к какому компьютеру ему следует подключиться (в зависимости от текущей нагрузки или чего-то еще), тогда клиент может подключиться к нему до тех пор, пока соединение не прервется.

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

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

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

Убедитесь, что ваш список хостов представляет собой реальные имена хостов, а не IP-адреса, что дает вам большую гибкость в долгосрочной перспективе (т. е.у вас «всегда» будут хост1.example.com, хост2.example.com...и т. д.даже если вы переместите инфраструктуру и поменяете IP-адреса).

Answer 3

Вы можете посмотреть, как Reddwarf. и это вилка Димдварф построены. Они оба горизонтально масштабируемыми сбоями, только для комбинированных игр-серверов приложений и DIMDWARF частично написаны в Scala (новые функции обмена сообщениями). Их подход и архитектура должны соответствовать вашим потребностям вполне хорошо :)

Answer 4

2 цента ..

«Как поделиться состоянием между несколькими машинами таким образом, что если один из них идет вниз, продолжайте работать»

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

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

Используя Akka, мы получаем удаление между узлами почти бесплатно. Это означает, что какой-то узел обрабатывает запрос, который может потребоваться взаимодействовать с совокупностью / объектом на других узлах, может сделать это с помощью RemoteActors.

То, что я изложил здесь, очень общий, но дает подход к распределенной неисправности с Аккой и зоофильем. Это может или не может помочь. Я надеюсь, что это делает.

Всего наилучшего, Энди