Назад | Перейти на главную страницу

Балансировка географической нагрузки

В компании в настоящее время есть типичная настройка веб-сервера: один веб-сервер и один сервер базы данных. К сожалению, часто возникают проблемы из-за высокой нагрузки на веб-сервер и базу данных, поэтому меня попросили настроить балансировку нагрузки с двумя веб-серверами.

Однако кто-то попросил меня разместить второй веб-сервер на сайте другой компании (в другой стране), чтобы минимизировать влияние сетевых проблем.

Это хорошая идея? Разве это не вызовет больше сетевых проблем из-за перенаправлений на удаленный веб-сервер?

Судя по предоставленным вами деталям, я не думаю, что информации достаточно, чтобы утверждать, что это хорошая идея или нет. Это зависит от того, используется ли приложение в нескольких странах или нет, а также от других факторов, таких как чувствительность к задержке. Балансировка нагрузки между двумя центрами обработки данных может быть немного сложнее и дороже, чем балансировка нагрузки в одном центре обработки данных.

Некоторые хитрости, которые можно использовать для повышения производительности:

  • Рассмотрим кеш приложения (например, Сервер кэширования Varnish): Это снизит нагрузку на ваши веб-серверы, а именно статический контент.

Низкая сложность балансировки нагрузки:

  • Добавьте новую DNS-запись «A» для вашего веб-сайта, указывающую на второй веб-сервер. Например: www.mysite.com будет разрешаться циклически для webserver1 и webserver2 - будьте осторожны, как ваше веб-приложение обрабатывает сеансы. Если у вас несколько серверов БД, вам нужно, чтобы все БД синхронизировались друг с другом.

Балансировка нагрузки средней сложности:

  • Рассмотрим устройство балансировки нагрузки, такое как F5, расположенное перед веб-кластерами.
  • Рассмотрим такую ​​услугу CDN: Инкапсула, Акамай или CloudFlare

Предполагая, что у вас все еще есть только одна база данных, самый важный вопрос, который следует задать, - насколько удаленный веб-сервер будет зависеть от базы данных?

Если все, что делает веб-сервер, будет зависеть от связи с базой данных в другом месте, тогда у вас будет повышенная уязвимость в случае сетевых проблем. Если у вас есть страницы, требующие нескольких запросов к базе данных, они будут отображаться медленнее из-за дополнительных сетевых циклов между веб-сервером и базой данных.

Репликация базы данных была бы вариантом. Но сохранить согласованность в реплицированных базах данных очень сложно. (Чтобы справиться со случаем, когда одна реплика выходит из строя произвольным образом, вам нужно как минимум четыре реплики. Любое решение, претендующее на достижение этого с меньшим количеством реплик, делало предположения о том, как ведут себя отказы, и если отказы не соответствуют этим предположениям, система выходит из строя.)

Если репликация базы данных для вас нецелесообразна, а веб-сервер не может делать ничего значимого без базы данных, я бы рекомендовал следующую конфигурацию для максимальной избыточности:

Используйте три сервера, каждый из которых оснащен двумя сетевыми интерфейсами. Один будет базой данных, два других - веб-серверами. Каждый веб-сервер подключается непосредственно к базе данных с помощью кабеля Ethernet. Между ними не будет даже переключателя, так что пока и веб-сервер, и база данных работают, они могут связываться друг с другом.

Эти два кабеля Ethernet занимают большую часть интерфейсов. У вас остается по одному доступному интерфейсу на каждом веб-сервере. Остальные интерфейсы подключены к двум независимым сетевым провайдерам. По моему опыту, подключение к сетевому провайдеру является наименее надежной частью настройки и, следовательно, наиболее важной частью для обеспечения избыточности, и описанная здесь настройка может сделать эту часть избыточной без репликации базы данных на несколько серверов. Даже если один из провайдеров испортит BGP до такой степени, что вся его AS отключится от Интернета, ваш сайт останется доступным через другой веб-сервер.