Я пытался исследовать эту тему, но не нашел нигде, где бы рекомендовали устанавливать такие службы, как Redis и ElasticSearch, при переходе на облачную среду.
В настоящее время я запускаю приложение Symfony2 на двух статических серверах - на одном работает MySQL, а на другом - общедоступный веб-сервер, на котором также работают Redis и ElasticSearch. Оба этих сервера виртуализированы, но они статичны с точки зрения невозможности репликации в настоящее время (различные аспекты все еще зависят от локальной файловой системы).
Цель состоит в том, чтобы перейти на AWS и использовать автоматическое масштабирование, чтобы иметь возможность запускать и отключать веб-серверы по мере необходимости, но я не понимаю, что я должен поставить на каждый экземпляр EC2. Должны ли они быть только с единственной ответственностью? т.е. настроить отдельные экземпляры для веб-серверов, Redis и ElasticSearch и, скорее всего, для экземпляра RDS для MySQL и настроить автоматическое масштабирование только на веб-серверах?
Я не предвижу, что в ближайшее время придется масштабировать сервер ElasticSearch, поскольку он только управляет функциями поиска, но возможно, что Redis может потребоваться репликация в какой-то момент - но следует ли это делать вручную? Я не уверен, как это можно сделать автоматически, поскольку, насколько мне известно, каждый экземпляр должен быть настроен так, чтобы знать о своем главном / подчиненном (ах). Буду признателен за совет по этому поводу.
Еще один быстрый вопрос, пока я здесь - как я смогу развернуть изменения кода, если в данный момент активны X веб-серверы? Я использую сценарий развертывания Capifony (версия Capistrano для Symfony2), который, как мне кажется, может достаточно легко обрабатывать несколько серверов, указав массив :domain адреса ... но как с этим справиться, если количество веб-серверов может варьироваться?
Мы справляемся с этим путем создания нескольких групп серверов в многоуровневом стеке (даже если группе в настоящее время нужен только один экземпляр). Первый слой - это ваш Балансировщик эластичной нагрузки, ясно.
Второй слой - это Группа автоматического масштабирования веб-серверов (зона мультидоступности). Они загружают настраиваемый AMI, который при запуске находится в надлежащем состоянии готовности для этой задачи. (Теперь, когда наши процессы стали более зрелыми, мы фактически загружаем общий AMI, который может автоматически настраиваться при запуске с помощью Chef.) Но мы также делаем git pull репозитория последнего производственного кода при запуске, поэтому нам не нужно создавать новый AMI при каждом развертывании кода. Это также позволяет нам более легко изменять конфигурации, такие как хосты базы данных, хосты Redis и т. Д.
Третий уровень предназначен для базы данных и других сервисов, таких как ElasticSearch и Redis. Вы можете разместить все три сервиса на одном устройстве, а затем заняться управлением своими собственными подчиненными серверами mysql, или вы можете разместить Redis и ElasticSearch на отдельном сервере и использовать RDS Amazon для своих сервисов Mysql. Ваш выбор, основанный на том, хотите ли вы управлять собственной репликацией / отказоустойчивостью в MySQL.
Часто самый простой способ - использовать Amazon RDS в конфигурации зоны множественной доступности. Мы всегда стараемся развернуть мульти-зону доступности со всем, поэтому мы по-прежнему работаем, даже если одна зона доступности выйдет из строя. Затем вы запускаете меньший экземпляр для размещения только Redis и ElasticSearch.
С участием ElasticSearch, вот совет, который мы используем для установки через рельсы: установите и поддерживайте полный экземпляр вашего приложения вместе с ElasticSearch на коробке. Затем создайте AMI для этой роли (или роли Chef). Причина в том, что вы можете запускать служебные задачи при загрузке для создания индексов ElasticSearch с нуля, если вы загружаете новый AMI. Затем поместите этот экземпляр в группу ASG с несколькими зонами доступности с минимальным и максимальным значением одного сервера. Если этот ящик или зона доступности перестают работать, ASG загрузит замену, восстановит свои индексы при запуске и будет готова обслуживать клиентов.
Для Redis, на горизонте хорошие новости. redis-cluster скоро появится, что обещает упростить управление масштабированием хранилищ Redis. А пока вы можете обрабатывать собственную репликацию или попробуйте Garantia, размещенное масштабируемое серверное решение Redis, который сейчас использует бета-версию redis-cluster (в настоящее время ограничен регионом us-east-1). Это дает преимущество в том, что для ваших конфигураций используются одни и те же IP-адреса, независимо от того, что происходит с пулами экземпляров.
Наконец, чтобы защитить ваши данные, поступающие в ваши базы данных и из них, я бы рекомендовал построить это внутри частной сетевой части общедоступного / частного Виртуальное частное облако. Это создает вашу собственную частную сеть, изолированную от анализаторов пакетов. Вы также можете использовать SSL-шифрование для соединений с базой данных MySQL.