Кластер Mongodb с формированием облака aws и автоматическим масштабированием

Это очень хороший вопрос, и я сам недавно прошел через это очень болезненное путешествие. Я пишу здесь довольно обширный ответ в надежде, что некоторые из этих мыслей о запуске кластера MongoDB через CloudFormation будут полезны другим.

Я предполагаю, что вы создаете производственный кластер MongoDB следующим образом: -

• 3 конфигурационных сервера (здесь могут работать экземпляры Micro / Smalls)
• По крайней мере, 1 осколок, состоящий, например, из 2 (первичный и вторичный) экземпляра сегментов (минимальный или большой) с большими дисками, настроенными для дисков данных / журналов / журналов.
• арбитр машина для голосования (микро наверное ОК).

т.е. https://docs.mongodb.org/manual/core/sharded-cluster-architectures-production/

Как и вы, я сначала попробовал шаблон AWS MongoDB CloudFormation, который вы разместили по ссылке (https://s3.amazonaws.com/quickstart-reference/mongodb/latest/templates/MongoDB-VPC.template), но, честно говоря, это было слишком, слишком сложно, т.е. это 9300 строк long и настраивает несколько серверов (т. е. шарды реплик, конфиги, арбитры и т. д.). Запуск шаблона CloudFormation занял много времени, и он продолжал давать сбои (например, через 15 минут), что означало, что все серверы снова отключились, и мне пришлось попробовать снова, что действительно расстраивало / отнимало много времени.

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

1. MongoDbConfigServer.template (шаблон для создания серверов конфигурации - запустите его 3 раза)
2. MongoDbShardedReplicaServer.template (шаблон для создания реплики - запускается 2 раза для каждого шарда)
3. MongoDbArbiterServer.template (шаблон для создания арбитра - запускается один раз для каждого шарда)

ПРИМЕЧАНИЕ: шаблоны доступны по адресу https://github.com/adoreboard/aws-cloudformation-templates

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

• InstanceType e.g. t2.micro
• ReplicaSetName например s1r (реплика осколка 1)
• ReplicaSetNumber например 2 (используется с ReplicaSetName для создания имени, например, имя становится s1r2)
• VpcId например vpc-e4ad2b25 (очевидно, не настоящий VPC!)
• SubnetId например subnet-2d39a157 (очевидно, не настоящая подсеть!)
• GroupId (имя существующего идентификатора группы MongoDB)
• Route53 (логическое для добавления записи во внутренний DNS - лучшие практики)
• Route53HostedZone (если логическое значение истинно, то идентификатор внутреннего DNS, использующего Route53)

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

    "Route53HostedZone": {
        "Description": "Route 53 hosted zone for updating internal DNS (Only applicable if the parameter [ UpdateRoute53 ] = \"true\"",
        "Type": "AWS::Route53::HostedZone::Id",
        "Default": "YA3VWJWIX3FDC"
    },

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

Помимо параметров, каждый из трех упомянутых ранее шаблонов имеет раздел "Resources", в котором создается экземпляр. Мы также можем делать интересные вещи в разделе "AWS::CloudFormation::Init". например

"Resources": {

    "MongoDbConfigServer": {
        "Type": "AWS::EC2::Instance",
        "Metadata": {
            "AWS::CloudFormation::Init": {
                "configSets" : {
                    "Install" : [ "Metric-Uploading-Config", "Install-MongoDB", "Update-Route53" ]
                },

"configSets" в предыдущем примере показывает, что создание сервера MongoDB - это не просто вопрос создания экземпляра AWS и установки на нем MongoDB, но также мы можем (а) установить метрики диска / памяти CloudWatch (б) обновить Route53 DNS и т. Д. идея в том, что вы хотите максимально автоматизировать такие вещи, как DNS / мониторинг и т. д.

IMO, создание шаблона и, следовательно, стека для каждого сервера имеет очень приятное преимущество, заключающееся в возможности очень быстро заменить сервер через веб-консоль CloudFormation. Кроме того, поскольку у нас есть server-per-template, легко постепенно наращивать кластер MongoDB.

Мой последний совет по созданию шаблонов - скопировать то, что работает для вас, из других шаблонов GitHub MongoDB CloudFormation, например. Я использовал следующее, чтобы создать серверы-реплики для использования RAID10 (вместо значительно более дорогих дисков IOPS, выделенных AWS).

https://github.com/CaptainCodeman/mongo-aws-vpc/blob/master/src/templates/mongo-master.template

В своем вопросе вы упомянули автоматическое масштабирование - я бы предпочел добавить осколок / заменить сломанный экземпляр вручную (автоматическое масштабирование имеет смысл с веб-контейнерами, например, Tomcat / Apache, но кластер MongoDB действительно должен медленно расти с течением времени). Однако мониторинг очень важен, особенно размеры дисков на серверах сегментов, чтобы предупреждать вас, когда диски заполняются (поэтому вы можете добавить новый сегмент для удаления данных). Мониторинг можно довольно легко осуществить с помощью метрик / сигналов тревоги AWS CloudWatch или с помощью службы MMS MongoDB.

Если узел выходит из строя, например, одна из реплик в сегменте, вы можете просто убить сервер, воссоздать его с помощью шаблона CloudFormation, и диски будут синхронизироваться автоматически. Это мой нормальный процесс, если экземпляр выходит из строя и, как правило, не требуется повторная конфигурация. В прошлом я потратил слишком много времени, пытаясь починить серверы - иногда удачно, а иногда нет. Моя стратегия резервного копирования теперь заключается в запуске mongodump важных коллекций базы данных один раз в день через crontab, zip up и загрузку в AWS S3. Это означает, что если произойдет ядерный вариант (полное повреждение базы данных), мы сможем воссоздать всю базу данных и mongorestore за час или два.

Однако, если вы создаете новый осколок (потому что вам не хватает места), конфигурация необходима. Например, если вы добавляете новый Shard 3, вы должны создать 2 узла реплики (например, первичный с именем => mongo-s3r1 / вторичный с именем => mongo-s3r2) и 1 арбитра (например, с именем mongo-s3r-arb), тогда вы должны подключиться через оболочку MongoDB к mongos (маршрутизатор MongoDB) и выполнить эту команду: -

sh.addShard("s3r/mongo-s3r1.internal.mycompany.com:27017,mongo-s3r2.internal.mycompany.com:27017")

ПРИМЕЧАНИЕ. - в этой команде предполагается, что вы используете частный DNS через Route53 (наилучшая практика). Вы можете просто использовать частные IP-адреса двух реплик в команде addShard, но в прошлом я очень сильно пострадал от этого (например, несколько месяцев назад все экземпляры AWS были перезапущены, и для всех них были созданы новые частные IP-адреса. Кластер MongoDB занял у меня 2 дня, так как мне пришлось перенастроить все вручную - тогда как изменение IP-адресов в Route53 занимает несколько секунд ... ;-)

Вы можете возразить, что мы также должны добавить команду addShard в другой шаблон CloudFormation, но IMO это добавляет ненужной сложности, потому что он должен знать о сервере, на котором есть маршрутизатор MongoDB (mongos), и подключаться к нему для выполнения команды addShard. Поэтому я просто запускаю это после создания экземпляров в новом сегменте MongoDB.

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