Мне нравятся эти вопросы, потому что на них всегда так просто ответить, хотя на самом деле это не так.
Для начала, ваш САМЫЙ БОЛЬШОЙ SPF - это то, что все на Amazon.Я люблю AWS по многим причинам, но во всех ситуациях, когда вам нужна реальная доступность, вы, по сути, стреляете себе в ногу, полагаясь на них на 100%.Таким образом, ваш первый план должен заключаться в том, чтобы распространять ваши услуги более чем одному провайдеру (облачному, VPS или выделенному).
Я хочу задать вам вопрос: если AWS выйдет из строя, как долго будет / может / будетвам нужно заметить, а затем что-то предпринять, и как быстро вам нужно, чтобы ваши службы были запущены и запущены?
Причина, по которой я спрашиваю, такова: DNS-балансировка нагрузки записей A / AAAAпрекрасное решение, к сожалению, вы не можете установить вес или приоритеты, как вы можете с записями SRV / MX.Это означает, что если AWS станет полностью недоступным, вам придется быстро изменить DNS, чтобы удалить IP.Это МОЖЕТ * автоматизироваться, если у вашего DNS-провайдера есть API, который позволяет это.С другой стороны, DNS-кэширование выполняется во многих местах, поэтому изменение DNS может не стоить того, что означает, что вы будете иметь доступность от 50% до 100%, если 1 IP недоступен (при условии, что у вас 2 записи A),потому что некоторые браузеры могут пробовать второй IP, если первый не работает.
По моему мнению, учитывая превосходное время безотказной работы AWS, вы не ошибетесь, если назначите 2 разных IP (на 2 разных провайдера).) в ваш домен.Я думаю, что это лучше, чем 0% доступности, когда 1 IP не работает, но по-прежнему нет радости потерять 50% ваших запросов.
Вы можете иметь 2 балансировщика нагрузки на каждого провайдера и разрешать им переадресовывать запросы.другому провайдеру, если некоторые экземпляры / серверы не работают.Другими словами, вам нужны только функциональные балансировщики нагрузки у ОБАХ поставщиков и функциональные серверы / экземпляры у ОДНОГО поставщика.Убедитесь, что вы выбрали альтернативного провайдера, который не имеет слишком большой задержки для AWS;)
MMM также является отличным инструментом, но он никак не связан с Rails.Лично я предпочитаю размещать балансировщик нагрузки перед всеми моими серверами баз данных и позволять им обрабатывать, кто получает запросы и т. Д. Поскольку data на сервере базы данных очень важен, обычно лучше взглянуть на человекаи убедитесь, что все в порядке, когда есть проблема, а не позволяйте инструменту управлять его доступностью, конфигурацией и т. д. MMM работает во многих ситуациях, возможно, вам следует попробовать и посмотреть, отвечает ли он вашим потребностям.Я не могу сказать ничего плохого об этом.
Я совсем не знаком с медиа-сервером Wowza, но быстрый поиск объяснил несколько вещей.Поскольку Wowza использует RTSP (UDP и TCP), HAProxy является NOT решением, так как он использует только TCP.С другой стороны, Keepalived может выполнять балансировку нагрузки UDP (он использует IVPS / LVS).Фактически, Keepalived также следует использовать для балансировки нагрузки ведомой базы данных, если у вас длинные запросы.
И последнее замечание: существует много способов «свернуть свои» AWS-подобные сервисы, такие как хранилище S3.Если вы хотите избежать использования SPF, но по-прежнему нуждаетесь в той же функциональности, что и сервисы AWS, вам следует изучить варианты с открытым исходным кодом, такие как Eucalyptus / Cloud.com / Openstack / GlusterFS.Настройка всего этого требует большой работы, но вы будете счастливы в тот день, когда сможете сказать: «ну что, если провайдер X не работает, Y может взять на себя управление».