Традиционное устройство веб-продуктов

Стандартное веб приложение работает на одном сервере: собственно веб-сервер, кеширование, база данных приложения. Достаточно часто ресурсов сервера перестаёт хватать и приходится переходить на новый тарифный план или производить апгрейд сервера. Это первый шаг в долгом процессе - вертикальное масштабирование, когда добавляются ресурсы сервера. Рано или поздно происходит упор в ограничение возможностей либо хостинга, либо "железа".

Следующий шаг - разделение приложения, когда приложение делится на составные части (web, БД, кеш) и эти части работают на разных серверах. С точки зрения производительности большинству проектов бывает достаточно такого разделения. Однако такое деление не решает задачу надёжности и отказоустойчивости. Каждый узел не зарезервирован и в случае выхода из строя любого из них перестаёт работать весь проект в целом.

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

Основные задачи, которые решает веб-кластер - это задача производительности и задача отказоустойчивости:

• Обеспечение высокой доступности сервиса, так называемые HA (High Availability или Failover) кластеры.
• Масштабирование веб-проекта в условиях возрастающей нагрузки (HP - High Performance кластеры).
• Балансирование нагрузки, трафика, данных между несколькими серверами.
• Создание целостной резервной копии данных для MySQL.