Назад | Перейти на главную страницу

Автомасштабирование и сервер NFS

У меня WebServer говорит, что WS-1, а сервер NFS говорит о настройке NFS-1 на AWS. WS-1 управляется эластичным балансировщиком нагрузки, а также автоматически масштабируется. Он также имеет EBS, установленную на / var / www, который содержит весь код приложения.

При увеличении масштаба том EBS и его данные не будут «клонированы». Чтобы иметь такое поведение, вам нужно автоматизировать его при загрузке.

  1. Получите последний снимок тома WS-1 EBS
  2. Создайте и прикрепите том

Другой метод, зависящий от объема данных в EBS, - это загрузить их с S3.

С помощью группы безопасности вы можете разрешить любому серверу в app_security_group иметь доступ к любому серверу в nfs_server_group. Это позволит вам динамически обновлять группы безопасности.

Надеюсь, это имеет смысл.

Ваш экземпляр будет «клонирован» только в том случае, если у вас есть недавний AMI (образ машины Amazon), созданный для этого экземпляра. Вероятно, с тех пор, как был сделан этот снимок, в вашей файловой системе произойдут некоторые изменения, поэтому рекомендуется использовать Пользовательские данные AWS для создания сценария Bash / CloudInit, который будет запускать обновление в областях, которые будут изменены, например кодовая база, медиа и т. д.

Варианты обновления определенных областей могут быть одним из следующих (перечисление плюсов и минусов):

  1. Центральная точка хранения на S3
    • Разрешения на доступ к сегменту управляются через роль IAM, которую вы назначаете своим экземплярам.
    • Пропускная способность быстрого ввода-вывода между сервисами AWS
    • Постоянное время безотказной работы
    • Против: Если вы не используете ведение версий, у вас нет гибкости, которую дает вам система контроля версий для изменений
  2. Репозиторий системы управления версиями (Git, Subversion) для загрузки данных:
    • Позволяет динамически обновлять сценарии начальной загрузки через систему управления версиями, вносить вклад и историю для этого и т. Д.
    • Против: Для этого требуется (потенциально) внешнее соединение с вашим хостом Git, разрешения и конфигурация группы безопасности.
    • Против: Наверное, немного медленнее, чем S3

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

#!/bin/bash
# Update your packages
yum update -y
# Get/execute bootstrapping
cd /tmp
git clone ssh://your-git-server/bootstrapping-repo.git
chmod +x /tmp/your-repo/bootstrapping.sh
# Execute it
/tmp/your-repo/bootstrapping.sh
# Remove the bootstrapping script remnants
rm -rf /tmp/your-repo

Этот метод позволяет вам гибко обновлять ваше «начальное репо» так часто, как вам нужно, без необходимости регулярно создавать новые AMI.

В качестве фона я использую S3 в своих пользовательских данных для получения соответствующих ключей SSH, файлов хоста и т. Д. И Git для репозитория начальной загрузки.

Также неплохо поддерживать ваши AMI в актуальном состоянии как можно чаще и сохранять их в конфигурации запуска, чтобы новые запускаемые экземпляры не тратили слишком много времени на обновление. Делаете ли вы это время от времени вручную или пишете скрипт для этого через API или CLI - решать вам.

К вашему сведению: вывод пользовательских данных и последующих скриптов, которые вызываются при запуске экземпляра, будут записаны в файл /var/log/cloud-init-output.log