Я не понимаю, как настроить аварийное переключение для моего довольно простого сценария. Я создаю сервисный шлюз для API. Я хочу иметь два сервера размещены в разных центрах обработки данных. И я просто хочу, чтобы у пользователя был доступ к службе, даже если один из серверов не работает. Нет проблем с синхронизацией БД, меня волнует только доступность сервиса.
Как это сделать, не позволяя пользователю реализовать на своей стороне какую-либо логику аварийного переключения? Я хочу, чтобы пользователю был предоставлен один домен или один IP-адрес и он мог постоянно получать доступ к службе, используя эту единую конечную точку.
Я не понимаю, как этого можно достичь. Я знаю, что могу настроить сетевой узел, который будет перенаправлять запросы на первый или второй сервер, в зависимости от того, какой из этих двух сейчас в сети. Однако я не вижу, как эта установка решила проблему высокой доступности, поскольку мы только что ввели единственную точку отказа в системе - узел пересылки. Итак, если этот узел выйдет из строя, служба будет недоступна.
Не могли бы вы объяснить, как это реализовать в реальном мире? Можно ли этого добиться при разумных затратах (т.е. не более стоимости хостинга самих серверов).
Редактировать: Было высказано предположение, что использование различных центров обработки данных требует больших затрат. Итак, не стесняйтесь предлагать предложения для 2 серверов в 1 центре обработки данных.
Изменить 2: Не стесняйтесь упоминать, какова разумная стоимость такой установки.
работает довольно просто. Первое правило: вы должны иметь что-нибудь более одного раза. Для простоты я настрою его в одном центре обработки данных и с IP-адресами, принадлежащими этому DC (вы можете сделать это со своими собственными IP-адресами и несколькими центрами обработки данных, но мы говорим о некоторых материалах AS с множественной адресацией, BGP и некоторых других вещах, которые не являются так дешево и просто в реализации).
Вам понадобится как минимум 4 сервера (вы можете сделать это только с двумя, но это не лучший способ). 2 для приложения и 2 для балансировки нагрузки, каждый сервер с несколькими сетевыми картами.
Базовая настройка выглядит так:
/---\ /------\ /----------\
| S |-----| LB 1 |-----| SERVER 1 |
--NET--| W | \------/\ /\----------/
| I | \_/
| T | / \
--NET--| C | /------\/ \/----------\
| H |-----| LB 2 |-----| SERVER 2 |
\---/ \------/ \----------/
У вас есть две разделенные линии на сеть, предоставленную вашим DC. Обе эти линии находятся в одной VLAN, и обе подключены к коммутатору (лучший способ - 2 коммутатора). К этим коммутаторам подключены 2 балансировщика нагрузки, которые совместно используют один виртуальный IP-адрес. Это IP, который может передаваться между этими двумя машинами. Для этого вы можете использовать VRRP и keepalived.
За этими двумя балансировщиками нагрузки расположены два зеркальных сервера. А вот и волшебство:
Вы должны знать, что HA - дорогостоящий способ, и вы не можете сделать это с небольшим бюджетом. Вам нужно рассчитать, не дешевле ли отключение вашего сервиса, чем стоимость HA, иногда это так.
Вам следует взглянуть на ключевые слова vrrp, keepalived и haproxy, чтобы узнать о некоторых идеях и способах их рассмотрения.
Обычный подход, конечно, заключается в использовании двух узлов пересылки (балансировки) в той или иной форме. HA кластер. Последовательность с точки зрения внешнего мира достигается различными формами общий IP-адрес - VRRP, CARP (такой же, как VRRP, но с открытой реализацией) и т. Д. Таким образом, у вас будет избыточность на обоих уровнях - на уровне балансировки и на уровне данных / услуг.
Согласованность уровня данных / услуг выходит за рамки этого ответа, однако обычно это довольно просто. Вы используете централизованное хранилище сеансов (возможно, тоже реплицируемое, например, redis или memcached) и реплицированный набор БД.
В общем, это возможно только на двух физических серверах, каждый из которых играет разные роли одновременно: балансировщик, сервер БД и так далее.