Извините, если я выдуваю это изо всех сил.
Имея в виду определение единой точки отказа (SPOF), если ваш LB выходит из строя, ваше приложение будет недоступно, так что, короче говоря, да, один LB или обратный прокси-сервер является SPOF.
Почему это так? Предполагая, что у вас есть только один LB, и он все еще может легко обрабатывать весь трафик, который у вас может быть, вам также необходимо быть уверенным в том, что вы защищены от любого аппаратного сбоя или любого другого сбоя, который может вывести ваше устройство из строя. (экстремальная ситуация обвала дата-центра).
Как справиться с проблемой?
Я просто упомяну здесь, что простое добавление слоев перед вашими серверами приложений не обязательно решает все ваши проблемы, вместо этого вы добавляете «сетевые переходы», которые в результате имеют, даже незначительные, накладные расходы времени на каждый запрос. Также иногда усложняет устранение неполадок, увеличивает затраты и все прочие неприятности, которые приносит сложная инфраструктура. Вот почему мне понадобится очень веская причина для наличия разных LB в очереди.
Кстати, архитектура, которой я буду следовать (подобная той, которую вы видели в статьях, как сказано), - это два LB перед вашей инфраструктурой (более двух, только если у них есть трудности с обработкой вашего трафика) и балансировка нагрузки DNS между их.
Конечно, у этого решения есть недостатки. DNS не зависит от состояния вашей серверной части, поэтому у вас нет функции переключения при отказе.
Вы можете решить эту проблему, используя надежную систему мониторинга в сотрудничестве с вашим DNS, чтобы выполнить автоматическое изменение DNS и, таким образом, функциональность аварийного переключения. Опять же, вы должны согласиться с тем, что DNS привязан к Time To Live (TTL), и некоторые клиенты будут кэшировать "неправильный" IP-адрес во время сбоя.
Как вы понимаете, вышеперечисленное не идеально, но, вероятно (в большинстве случаев), это ваш единственный выход.
Для ситуаций, когда время простоя еще менее терпимо (даже для части клиентов), я оставлю несколько альтернатив.
Global Server Load Balancer (GSLB), это услуга, и вот так вы ее купите. Он всегда выполняет сложную работу, направляя трафик по вашему желанию, либо в архитектуру Active-Passive, скажем Primary-Disaster, либо в Active-Active, например, в один центр обработки данных в США, а другой в Азии. Конечно, это решение (за исключением того, что оно будет стоить довольно дорого) кажется простым в реализации, хотя имейте в виду все вещи, которые вы должны учитывать, чтобы оно работало должным образом, я не буду углубляться в технические вопросы, я просто упомяну, что вам понадобится двойное оборудование, которое нужно будет настроить для независимой работы между вашими центрами обработки данных, но с полной синхронизацией там, где это необходимо.
Протокол пограничного шлюза (BGP), вам нужно будет реализовать это с помощью своего провайдера. Реализация здесь может быть довольно сложной, и она должна быть индивидуальной, чтобы быть оптимизированной для ваших нужд. Здесь, как и прежде, у вас вся головная боль двойной инфраструктуры. Но если вы дошли до этого решения, скорее всего, вы будете работать более чем в одном месте.
Сказав все вышесказанное, одного мощного LB, размещенного в облаке, будет достаточно для большинства веб-приложений / сайтов.
person
zochamx
schedule
16.11.2016
