5 вариантов настройки сервера для обслуживания веб-приложения
Cloud Server, VPS | Комментировать запись
При выборе архитектуры сервера для вашей среды необходимо учитывать много факторов: производительность, масштабируемость, доступность, надежность, стоимость и простота управления.
В этой статье вы найдете список популярных вариантов настройки сервера с кратким описанием каждого, включая их плюсы и минусы. Имейте в виду, что все описанные здесь концепции могут использоваться в различных комбинациях друг с другом. Также следует помнить, что каждая среда имеет разные требования, поэтому нет единой правильной конфигурации.
1: Все на одном сервере
Вся среда находится на одном сервере. Подходит для простого веб-приложения, которое включает в себя веб-сервер, сервер приложений и сервер базы данных. Часто для этой настройки является стек LAMP – это Linux, Apache, MySQL и PHP на одном сервере.
Пользователь
↓
Сервер
http://example.com/
Плюсы:
- Эта настройка очень проста.
Минусы:
- Приложение и база данных используют одни и те же серверные ресурсы (CPU, память, I/O и т. д.). Это может снизить производительность и затруднить поиски источника сбоев.
- Сложно горизонтально масштабировать.
Читайте также: Установка стека LAMP в Ubuntu 16.04
2: Отдельный сервер баз данных
Систему управления базами данных (СУБД) можно отделить от остальной среды, чтобы исключить конфликт ресурсов между приложением и базой данных, а также повысить безопасность, ограничив доступ к серверу БД.
Такая настройка подходит для быстрого развертывания приложения, при котором между БД и приложением не будет возникать конфликтов за системные ресурсы.
Пользователь
↓
Сервер приложения
http://example.com/
↓
Сервер баз данных
(в частной сети)
Примечание: Здесь и далее красным выделены компоненты, которые находятся в частной сети.
Плюсы:
- Приложение и база данных используют индивидуальные серверные ресурсы (CPU, память и т. д.).
- Можно выполнить вертикальное масштабирование каждого уровня в индивидуальном порядке (добавить больше ресурсов тому серверу, который в этом нуждается).
- В отдельных ситуациях это может повысить безопасность базы данных.
Минусы:
- Чуть более сложная настройка (по сравнению с первым вариантом).
- При высокой задержке сетевого соединения между двумя серверами (например, если серверы географически далеко друг от друга) или невысокой пропускной способности могут возникнуть проблемы с производительностью.
Читайте также: Перемещение базы данных MySQL на новый сервер
3: Балансировщик нагрузки, или обратный прокси-сервер
Балансировщик нагрузки повышает производительность и ошибкоустойчивость среды распределения рабочей нагрузки между несколькими серверами. Если один из серверов выходит из строя, другие серверы будут обрабатывать входящий трафик до тех пор, пока неисправный сервер не восстановится. Также балансировщик может обслуживать нескольких приложений через один и тот же домен и порт с помощью обратного прокси-сервера на уровне 7 (прикладной уровень).
Такая настройка подходит среде, которой необходимо горизонтальное масштабирование.
Пользователь
↓
Балансировщик нагрузки
↓
Серверы приложений
Сервер 1 Сервер 2
↓ ↓
Сервер баз данных
Плюсы:
- Упрощает горизонтальное масштабирование.
- Может защитить от DDOS-атак путем ограничения клиентских подключений.
Минусы:
- Балансировщик нагрузки может стать узким местом, если у него недостаточно ресурсов или он плохо настроен.
- Может вызвать дополнительные сложности с обработкой SSL-терминации и липких сессий.
- Балансировщик нагрузки является единственной точкой отказа; если он прекратит работу, приложение будет недоступно. Инфраструктура высокой доступности – это инфраструктура без единой точки отказа. Чтобы узнать, как устранить эту точку отказа, читайте Использование плавающих IP-адресов.
Читайте также:
- Основы работы с HAProxy и базовые понятия балансировки нагрузки
- Что такое балансировка нагрузки?
4: HTTP-ускоритель (кэширующий обратный прокси-сервер)
HTTP-ускоритель (или HTTP-акселератор, кэширующий обратный прокси-сервер HTTP) позволяет снизить время обработки контента с помощью различных технологий. Главная технология, которую реализует HTTP-ускоритель – это кэширование ответов веб-сервера или сервера приложений.
Популярные HTTP-ускорители: Varnish, Squid, Nginx.
Такой вариант настройки подходит динамическим приложениям, обрабатывающим много контента.
Пользователь
↓
HTTP-ускоритель
http://example.com/
↓
Сервер приложений
↓ ↓
Сервер баз данных
Плюсы:
- Увеличивает производительность сайта за счет снижения загрузки CPU путем кэширования и сжатия.
- Может использоваться как резервный балансировщик.
- Некоторые программы кэширования могут защитить от DDOS-атак.
Минусы:
- Требуется дополнительная настройка для достижения высокой производительности.
- Если частота попадания в кеш низка, это может снизить производительность приложения.
Читайте также:
- Установка WordPress, Nginx, PHP и Varnish на Ubuntu 12.04
- Настройка кластерного веб-сервера с помощью Varnish и Nginx на Ubuntu 13.10
5: Репликация базы данных по типу «master-slave»
Одним из способов повышения производительности СУБД, которая выполняет множество операций чтения, является репликация данных по типу master-slave. Для репликации master-slave требуется один ведущий сервер (мастер) и один или несколько ведомых нод (slave). Все обновления отправляются на мастер-сервер, а операции чтения могут быть распределены между всеми нодами.
Такая настройка позволяет повысить производительность операций чтения.
Пользователь
↓
Балансировщик нагрузки
↓
Серверы приложений
Сервер 1 Сервер 2
↑↓ ↓
Master Slave
_________________
Репликация
Плюсы:
- Улучшает производительность операций чтения базы данных, распределяя операции между ведомыми устройствами
- Может улучшить производительность операций записи (если использовать мастер-сервер только для записи данных, он не будет тратить время на чтение запросов).
Минусы
- Приложение, обращающееся к базе данных, должно уметь определять ноды базы данных, которые обрабатывают запросы обновления и чтения.
- Обновления ведомых нод асинхронны, поэтому есть вероятность, что их данные могут устареть.
- Если мастер-сервер выходит из строя, в базе данных не будут появляться обновления, пока проблема не будет устранена.
- Нет встроенной обработки сбоев.
Читайте также:
- Оптимизация производительности WordPress с помощью репликации MySQL в Ubuntu 14.04
- Репликация баз данных MySQL по типу Master/Slave
Пример: Комбинирование нескольких вариантов настройки веб-сервера
Вы можете использовать балансировку нагрузки для кэширующих серверов, а БД переместить в отдельную среду. Объединение этих методов позволяет извлечь преимущества каждого из них.
Предположим, что балансировщик нагрузки может распознавать статические запросы (изображения, css, javascript и т.д.) и отправлять их непосредственно на серверы кеширования, а другие запросы передавать серверам приложений.
Когда пользователь запрашивает динамический контент:
- Он отправляет запрос контента балансировщику (на http://example.com/).
- Балансировщик нагрузки отправляет запрос на бэкенд приложения.
- Бэкенд считывает запрашиваемый контент из базы данных и возвращает его балансировщику.
- Балансировщик нагрузки возвращает запрашиваемые данные пользователю
Когда пользователь запрашивает статический контент:
- Балансировщик обращается к серверу кэширования, чтобы узнать, не поступал ли запрос на этот контент ранее.
- Если запрос попадает в кэш, балансировщик извлекает контент и переходит к шагу 7. Если запроса нет в кэше, сервер кэширования передает запрос балансировщику.
- Балансировщик передает его серверу приложения на бэкенд.
- Бэкенд считывает данные из БД и возвращает их балансировщику.
- Балансировщик передает ответ кэширующему серверу.
- Он кэширует контент, а затем возвращает его балансировщику нагрузки.
- Балансировщик нагрузки возвращает запрашиваемые данные пользователю.
В этой среде есть две точки отказа (балансировщик нагрузки и мастер-сервер базы данных), но она обеспечивает высокую надежность и производительность приложения.
Заключение
Теперь вы знакомы с базовыми вариантами настройки веб-сервера для обслуживания приложений.
