Отказоустойчивость и балансировка нагрузки - взаимоисключающие?

Question

Для следующего поколения одного из наших продуктов мне было предложено создать систему с возможностью переключения на другой ресурс (т. Е. Имеется несколько узлов, и если один из узлов падает, минимальная/потеря данных) и балансировка нагрузки (поэтому каждый из узлов обрабатывает только часть данных). Я не могу понять, как я могу сделать то и другое. Предположим, что узел имеет все данные, но обрабатывает только согласованное подмножество. Например, он меняет элемент 8. Теперь все остальные узлы имеют неправильный элемент 8. Поэтому мне нужно синхронизировать - изменить все остальные элементы 8 элемента, чтобы сохранить целостность. Но, конечно, это просто издевается над балансировкой нагрузки ?!

Answer 1

Короткий ответ: во многом это зависит от архитектуры приложения.

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

Путь подойти к этой проблеме состоит из двух полностью отдельных слоев:

Layer 1 - приложение. Создайте проект высокого уровня для своего приложения, как будто для DR нет требования. Игнорируйте тот факт, что может быть другой экземпляр этого приложения в другом месте, которое будет использоваться в DR. Сосредоточьтесь на функциональных & аспектах производительности вашего приложения - какие должны быть отдельные подсистемы, если они должны быть масштабированы по причинам рабочей нагрузки. Это приложение в целом обрабатывает 100% данных - решите, существует ли подход масштабирования/федерации, необходимый в самом приложении, - это не относится к требованию DR.

Layer 2 - DR. Теперь подумайте о своем приложении как о черном ящике. Сколько экземпляров черного ящика вам нужно для удовлетворения ваших требований к доступности и как вы будете поддерживать требуемую степень синхронизации между этими экземплярами? Каковы требования к производительности для восстановления после сбоя & восстановление (время доступности, допустимая потеря данных, если таковая имеется, как долго, пока вам не понадобится следующий переход на резервный ресурс &)?

Назад к уровню 1 - выберите подход внедрения для своего высокоуровневого проекта, который использует подход восстановления и инструменты, идентифицированные в слое 2. Например, если вы будете использовать подход БД-мастер-подчиненный для синхронизации данных между DR, сохраните все, что вы хотите сохранить, в отказоустойчивости на уровне БД, а не в локальных файлах или памяти приложения-узла. Эти варианты зависят от структуры DR, которую вы выбираете.

Дизайн слоя приложения и уровня DR связаны, но если вы выберете подходящие инструменты &, они не обязательно должны быть сильно связаны. Например. в веб-службах Amazon вы можете использовать балансировку нагрузки IP для пересылки запросов на экземпляр приложения с отказоустойчивостью, и если вы храните все необходимые данные (включая сеансы и другие переходные моменты) в базе данных и используете возможности репликации СУБД, это довольно просто.

Итог:

1. Не путайте производительность горизонтального масштабирования узлов (приложение-внутренний) с DR узлами (целые приложения)
2. Используйте свой выбор DR подхода к реализации решений привода в приложении слой

Удача