Зеркала узлов - или это балансировка нагрузки или обратное проксирование?

Question

Если у вас есть решение, желательно с открытым исходным кодом, конечно (!), Мне было бы интересно узнать, но на самом деле я хочу знать правильную терминологию.

Устройство, о котором я думаю, - это преобразователь адресов (например, NAT), который принимает запрос URL-адреса и отвечает на него либо из своего кэша, либо с одной из возможных серверных машин.

Если есть запись (запрос POST), это устройство отправит ее на все серверы.

Таким образом, все серверы могут находиться в одном состоянии без необходимости синхронизации. В случае сбоя одного узла остальные узлы будут в том же состоянии, поэтому могут отвечать запросами.

Итак, в виде диаграммы:

Client -> read -> device -> Server A/B (load balancing) or from cache


                                     ->  Server A
Client -> write (POST url) -> device ->  Server B
                                     ->  Server N

Все серверы имеют одинаковые записи, поэтому сервер A, B, ...N находятся в абсолютно одинаковом состоянии (если они запущены).

Любой сервер или кеш может ответить на чтение.

Вопросы:

• Как называется это устройство?
• Это легко настроить с помощью Apache/Squid? - если так, то где руководство идиота?
• Это делает само устройство SPOF (единая точка отказа), как вы его настраиваете, чтобы у вас было два независимых устройства, чтобы, если одно из них выйдет из строя, другое без проблем перешло в другое место?

Answer 1

Коммерческое, частное и немного дорогое решение: переключение контента CISCO
CISCO имеет линейку продуктов под названием Content Service Switches (их серия CSS 11500). Исходя из вашего вопроса, это близко к тому, что вы ищете. Используемые ими термины (и вы можете использовать их в Google для аналогичных продуктов) - это "переключение контента" или "переключение приложений".

(Я не использовал такие устройства в реальной жизни и не имею никакого отношения к Cisco)

Принципы проектирования высокой доступности: не усложняйте
На мой взгляд, в вашей диаграмме есть слабое место - запись (POST) на все серверы. Вы полагаетесь на "устройство" для синхронизации всех экземпляров сервера (Apache, папки NSF, базы данных и т.д.). Это вводит новый SPoF (само устройство, как вы уже заметили) и добавляет сложность синхронизации. Если один из серверов (временно) недоступен, кто отвечает за повторную синхронизацию? Сам сервер или "устройство"?

Лучшим вариантом будет возложить ответственность за отказоустойчивость / высокую доступность на саму инфраструктуру:

• на аппаратном уровне (RAID, избыточное оборудование, несколько сетевых путей и т. д.),
• на уровне операционной системы (под Linux: Heartbeat: уровень обмена сообщениями кластера, Pacemaker: менеджер ресурсов кластера и Cluster Glue: инструменты управления кластером) и
• на уровне приложения. Например, у Apache было несколько опций, таких как Camel, все платформы баз данных поставляются с опциями кластеризации, и NSF может быть настроен с использованием функций высокой доступности ОС).

Высокий доступный отказоустойчивый сервер LAMP
Я думаю, что для MediaWiki общее решение состоит в том, чтобы создать высокую доступную аварийную лампу LAMP. Если вы пользуетесь Google на этих условиях, появляется множество решений, таких как описанные в этой статье, и отличная схема установки LAMP с высокой доступностью здесь на сервере.