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

установка балансировщика нагрузки на виртуальную машину сервера базы данных

У меня простой макет моего сайта, балансировщик нагрузки, расположенный перед 3 серверами приложений, которые запрашивают базу данных. У меня есть 4 виртуальных машины, 3 виртуальные машины для 3 серверов приложений и одна виртуальная машина для базы данных. Разумно ли устанавливать балансировщик нагрузки на той же виртуальной машине, что и база данных? или это должно быть на полностью отдельной виртуальной машине? Возникает вопрос по поводу стоимости.

Нецелесообразно устанавливать LB на той же виртуальной машине, что и база данных, по нескольким причинам:

  1. Сетевая сантехника - LB традиционно являются прокси-серверами приложений и предназначены для использования в качестве общедоступного интерфейса приложения. Обычно это означает некоторую форму сетевой сегрегации. Серверы баз данных традиционно не должны принимать общедоступный трафик (использовать общедоступный для любого клиентского трафика).
  2. Производительность - LB, хотя и не сильно влияет на небольшие среды, загруженное приложение вызовет конфликт ресурсов между маршрутизацией трафика клиента и вызовами базы данных. Вы столкнетесь с потенциальной медлительностью из-за того, что система пытается обрабатывать принятие решений о трафике клиентов и доступ к базе данных.
  3. Безопасность - если приложение спроектировано так, чтобы быть даже полубезопасным, LB будет действовать не только как прокси, но и как базовый интерфейс безопасности, завершая, а возможно, даже передавая трафик SSL. Вы не хотите прерывать общедоступное соединение с сервером базы данных.
  4. Исправление проблем. Попытка устранить проблемы с LB, когда это тот же интерфейс или интерфейсы, что и сервер db, немного запутает вас, учитывая, что у вас будут странные шаблоны маршрутизации для client => Web => Database.

Имейте в виду, что если это только для тестирования, LB должен быть одной виртуальной машиной, а сеть / база данных может быть на одном компьютере.

Если это для постановки или производства, перейдите на отдельную виртуальную машину. Если у вас есть проблемы с LB, перезапуск всей БД и приложения не имеет смысла.

Это совсем не хорошая идея. Вы можете найти причины в предыдущих постах, я просто добавлю проблему масштабирования и аварийного переключения. Я думаю, вам следует переосмыслить свою архитектуру с учетом SPOF и установить ее так:

Internet ----> Virtual IP ----> LB1 \_____/  APP1 \    /- DB1
                          \---> LB2 /     |- APP2  >--<
                                          \  APP3 /    \- DB2

LB1 и LB2 являются балансировщиками нагрузки в настройке аварийного переключения с виртуальным IP (для этого можно использовать Keepalived), поэтому, когда LB1 умирает, LB2 автоматически получает VIP, и все работает. У вас также должна быть репликация настройки БД, поэтому, когда один из серверов БД умирает, приложение использует другой. LB также могут работать как брандмауэры и вообще только «вещи с выходом в Интернет», серверы APP и DB вообще не должны иметь общедоступный IP.