Это скорее вопрос теории, чтобы помочь мне как разработчику понять процесс, который наши системные администраторы будут использовать при развертывании приложения для распространения нашего приложения. Я бы очень признателен за понимание, поскольку оно поможет мне спланировать возможные возможные подводные камни (и может оказаться ценным ресурсом для других, у кого есть вопросы начального уровня по этой теме).
Предполагая, что существует несколько допустимых хост-компьютеров, которые могут отвечать на любой входящий HTTP-запрос, каков самый простой подход к балансировке нагрузки между ними? Моя основная гипотеза как программиста могла бы предложить, вероятно, что-то, использующее DNS, пока трафик не станет настолько высоким, потребуется что-то более надежное. Я предполагаю, что прокси-серверы в какой-то степени используются для проверки того, какие хосты заняты ответами на текущую обработку, а какие свободны.
У меня есть уровень данных приложения, который полностью построен на Python с использованием WSGI, и при его тестировании мы только что использовали mod_wsgi в Apache. Если теоретически развернуть это на нескольких идентичных машинах, все из которых подключены к одним и тем же базам данных / ресурсам на уровне приложения, каков будет первый порядок распределения запросов к общему домену между ними? Просто перечислить несколько записей A в DNS?
Прошу прощения за расплывчатость, просто не смог найти достойного учебника по этой теме с точки зрения разработчика. Я ценю помощь!
Подход к балансировке нагрузки полностью зависит от проектных спецификаций, которые, надеюсь, вы предоставили администраторам. Руководства по балансировке нагрузки нет, потому что есть несколько способов сделать это в зависимости от веб-сайта и надежности решения. Например, для статического веб-сайта, который нуждается только в избыточности и не влияет на бизнес, циклический DNS подойдет. Если вам просто нужна избыточность, тогда подойдет кластер. Если вам нужна надежность 99,999 и балансировка нагрузки на основе времени отклика, вам потребуются резервные выделенные аппаратные устройства для балансировки нагрузки сети.
Как администратору мне нужно знать, что именно делает ваше приложение и где оно будет наращивать нагрузку, чтобы определить, как лучше всего реализовать балансировку нагрузки. Кроме того, если у него есть бэкэнд базы данных, он также должен быть избыточным. Это все то, о чем вас должны были спросить или предоставить администраторам, чтобы правильно спроектировать инфраструктуру сервера.
Типичная настройка будет фактически работать в обратном направлении, чем вы предлагаете - сначала реализуйте интерфейсный балансировщик нагрузки (например, HAProxy, Nginx, даже Varnish и т. Д. Или аппаратно), и только позже используйте DNS.
Входящие запросы доходят до балансировщика нагрузки, который обычно может выполнять несколько функций, в том числе:
У этого подхода есть несколько преимуществ:
Однако проблема в том, что весь трафик должен проходить через один балансировщик нагрузки. На одном уровне это делает его серьезной точкой отказа (но вы можете переключиться на отказ, чтобы уменьшить влияние). Что еще более важно, в какой-то момент отдельный узел не сможет обрабатывать трафик, который должен проходить через него. Последняя проблема решается с помощью DNS - запросы возвращают разные IP-адреса, соответствующие разным балансировщикам нагрузки.
HTTP-запросы балансировки нагрузки можно выполнить несколькими способами. Циклический перебор DNS - это один из способов сделать это, но у вас нет особого контроля над этим.
Другой и лучший подход - использовать выделенное оборудование для балансировки нагрузки. Например, вы можете запустить Linux и установить программное обеспечение для балансировки нагрузки, такое как haproxy.
Одна важная проблема, на которую нужно обратить внимание, - это иметь одно и то же представление со стороны клиента независимо от того, какой сервер выбран из облачного сервера.