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

Ответ 1

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

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

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

то есть. 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 строк и устанавливает несколько серверов (т.е. осколки реплик, configs, arbitors и т.д.). Запуск шаблона CloudFormation занял много времени, и он продолжал терпеть неудачу (например, после 15 минут), что означало, что серверы все снова завершались, и мне пришлось повторить попытку, которая была действительно расстраивающей/отнимающей много времени.

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

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

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

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

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

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

    "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 (b) Update Route53 DNS и т.д. Идея заключается в том, что вы хотите как можно больше автоматизировать такие функции, как DNS/Monitoring и т.д.

IMO, создавая шаблон, и поэтому стек для каждого сервера имеет очень хорошее преимущество в том, что вы можете быстро заменить сервер через веб-консоль CloudFormation. Кроме того, поскольку у нас есть сервер для каждого шаблона, он легко побито монтирует кластер 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.

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

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

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

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

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

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