До сих пор я всегда настраивал свои проекты на одном экземпляре (облачном или vps). Всегда одна и та же процедура: установите LAMP, пусть он создает дампы mysql для резервных копий, защищает ssh, позволяет ему работать годами без особого обслуживания.
Это все небольшие проекты, никогда не было проблем.
Сейчас проекты становятся крупнее, и только что у меня произошел сбой оборудования в Rackspace. 4 часа простоя, клиент ушел в ожидании. и т.п.
Итак, вот мой вопрос: Что мне нужно узнать, чтобы перейти на следующий «уровень»?
Должен ли я начать разделять вещи: отдельный сервер БД, отдельный веб-сервер и т. Д. Следует ли мне узнать о быстром развертывании нового облачного экземпляра в случае простоя? Должен ли я быть ... чем-то, о чем я еще не думал ...
Это зависит от того, насколько критично ваше приложение. Вы можете настроить конфигурацию HA (высокой доступности), в которой вы удваиваете размер кластера (удваиваете цену) и получаете автоматическое переключение при сбое в случае каких-либо проблем.
Что касается разделения серверов, это может быть хорошей идеей. Например, у вас может быть два интерфейсных узла с балансировкой нагрузки, обслуживающих ваши веб-страницы. Если вы заметили какие-либо проблемы с одним из ваших серверов, вы можете извлечь отказавший узел из балансировщика нагрузки, пока исследуете проблему. В то же время весь трафик будет продолжать обслуживаться оставшимся узлом.
Вы должны спланировать стратегии высокой доступности (HA) и аварийного восстановления (DR).
1. Build for server failure
Экземпляры в облаке - как и в типичном центре обработки данных - эфемерны. Вы должны быть готовы к отказу сервера. Создание на случай сбоя сервера начинается с разработки приложений без сохранения состояния, устойчивых к восстановлению после перезагрузки или перезапуска сервера или службы.
Настройте автоматическое масштабирование, чтобы ваше приложение могло реагировать на динамические шаблоны трафика на основе набора показателей производительности. Настройте зеркальное отображение базы данных, конфигурации главный / подчиненный и / или первичную обработку, чтобы обеспечить целостность данных и минимальное время простоя. Используйте динамический DNS и статические IP-адреса, чтобы компоненты инфраструктуры вашего приложения всегда имели правильный контекст.
2. Build for zone failure
Иногда выходят из строя не только отдельные серверы - случаются сбои в подаче электроэнергии, сбои в сети и удары молнии. Вы должны убедиться, что ваши приложения готовы к сбоям зоны. Зоны (Amazon Web Services называет их «зонами доступности») - это отдельные местоположения, которые спроектированы так, чтобы быть изолированными от сбоев в других зонах.
Распределите серверы на каждом уровне приложений как минимум по двум зонам. Репликация данных по зонам.