Автоматическая настройка для многосерверного кластера RethinkDB через службу ECS

Question

Я пытаюсь настроить кластер RethinkDB с 3 серверами, равномерно распределенными по 3 частным подсетям, каждая в разных AZ в одном регионе.

В идеале я хотел бы развернуть программное обеспечение БД через ECS и обеспечить автоматическое масштабирование экземпляров EC2, но у меня возникают проблемы при попытке выяснить, как настроить экземпляры RethinkDB для присоединения к кластеру RethinkDB.

Чтобы создать / присоединить кластер в RethinkDB, при запуске нового экземпляра RethinkDB вы указываете host:port комбинацию одной из других машин в кластере. Здесь я сталкиваюсь с проблемами. Служба автоматического масштабирования создает новые первичные ENI для моих экземпляров EC2 и использует случайный IP-адрес в диапазоне моей подсети, поэтому я не могу заранее знать IP-адрес экземпляра EC2. Кроме того, я использую сетевое задание awsvpc, поэтому ECS создает новые вторичные ENI, выделенные для каждого контейнера-докера, и присоединяет их к экземплярам, ​​когда он их развертывает, а также к тем, которые получают новые IP-адреса, чего я не делаю. знать заранее.

До сих пор я разработал одно возможное решение, которое заключается в том, чтобы не использовать группу автоматического масштабирования, а вместо этого вручную развернуть 3 экземпляра EC2 в частных подсетях, что позволило бы мне назначить свой собственный заранее определенный частный IP-адрес. Насколько я понимаю, это все равно не поможет, если я использую awsvpc сетевое задание, хотя каждый контейнер, работающий на моих экземплярах, получит свой собственный выделенный вторичный ENI, и я заранее не буду знать IP этого вторичного ENI , Я думаю, что могу переключить свою работу сети в режим bridge, чтобы обойти это. Таким образом, я могу использовать предопределенный IP экземпляров EC2 (основной ENI) в команде RethinkDB join.

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

Answer 1

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

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

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

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

Затем вы должны создать другую службу ECS, которая в основном совпадает с первой, но в сценарии точки входа должна перечислить службы в пространстве имен RethinkDB, а затем разрешить их, отбрасывая собственный IP-адрес контейнера, а затем использовать обнаруженный хост для присоединиться к --join при запуске RethinkDB в контейнере.

Затем я установил бы для службы ECS без начальной загрузки только одну задачу, чтобы он мог обнаружить версию начальной загрузки, а затем вы сможете продолжать добавлять задачи в службу по одной, пока не будете удовлетворены размер кластера без начальной загрузки, позволяющий получить n + 1 экземпляров кластера, включая исходный экземпляр начальной загрузки.

После этого я бы полностью удалил службу начальной загрузки ECS.

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

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

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