Введение

Существует множество факторов, которые необходимо учитывать при выборе серверного окружения (environment), такие как производительность, масштабируемость, доступность, надежность, стоимость и простота управления.

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

1. Все на одном сервере

Окружение находится на одном сервере. Для типичного веб-приложения она будет включать в себя веб-сервер, сервер приложений и сервер баз данных. Частным случаем реализации этого набора является стек LAMP, название которого представляет собой сокращение от Linux, Apache, MySQL и PHP, на одном сервере.

Пример использования: Хорошо подходит для быстрого развертывания приложения, так как это простейшая конфигурация из всех, однако она дает мало возможностей в плане масштабируемости и изоляции компонентов.

Плюсы:

• Простота

Минусы:

• Приложение и база данных используют одни и те же ресурсы сервера (CPU, память, I/O и т.д.), что, помимо потенциально низкой производительности, затрудняет определение источника (приложение или база данных) этой самой низкой производительности.
• Затруднительно осуществлять горизонтальное масштабирование.

Дополнительные руководства:

• Как установить LAMP на Ubuntu 14.04

2. Выделенный сервер баз данных

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

Пример использования: Хорошо подходит для быстрого развертывания приложения, но при этом устраняет проблему конкуренции приложения и базы данных за одни системные ресурсы.

Плюсы:

• Приложение и база данных не конкурируют за одни и те же ресурсы сервера (CPU, память, I/O и т.д.).
• Вы можете вертикально масштабировать каждый компонент (приложение и базу данных) независимо друг от друга, добавляя дополнительные ресурсы к нужному серверу.
• При определенных настройках это может повысить безопасность, убрав базу данных из DMZ.

Минусы:

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

Дополнительные руководства:

• Как настроить удаленную базу данных MySQL для оптимизации производительности сайта
• Как перенести базу данных MySQL на новый сервер на Ubuntu 14.04

3. Балансировщик нагрузки (обратный прокси)

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

Примеры программного обеспечения, поддерживающего обратный прокси: HAProxy, Nginx, и Varnish.

Пример использования: Полезен для окружения, которое требует масштабирования путем добавления дополнительных серверов, так же известное как горизонтальное масштабирование.

Плюсы:

• Делает возможным горизонтальное масштабирование, то есть ресурсы окружения могут быть увеличены путем добавления в него новых серверов.
• Может защитить от DDOS-атак путем ограничения клиентских соединения до приемлемого количества и частоты.

Минусы:

• Балансировщик нагрузки может стать узким местом в производительности, если он испытывает нехватку ресурсов или плохо настроен.
• Может создать дополнительные сложности, требующие дополнительных усилий от администратора, например, работа с приложениями, которые требуют так называемых "липких сессий" (sticky session).

Дополнительные руководства:

• Введение в HAProxy и концепции балансировки нагрузки
• Как использовать HAProxy в качестве балансировщика нагрузки 4 уровня в Wordpress
• Как использовать HAProxy в качестве балансировщика нагрузки 7 уровня в Wordpress и Nginx

4. HTTP Accelerator (кэширующий обратный прокси)

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

Примеры программного обеспечения, поддерживающего HTTP acceleration: Varnish, Squid, Nginx.

Пример использования: Полезен для динамических веб-приложений с тяжелым контентом или с большим количеством файлов, к которым возможен одновременный доступ.

Плюсы:

• Повышает производительность сайта путем снижения нагрузки на процессор веб-сервера за счет кэширования и сжатия, тем самым увеличивая количество обслуживаемый пользователей.
• Может быть использован как балансировщик нагрузки обратного прокси.
• Некоторое программное обеспечение для кэширования может защищать от DDOS атак.

Минусы:

• Требуется настройка для достижения наилучшей производительности.
• Если сам характер запросов пользователей не предполагает возможности эффективного кэширования, это может снизить производительность сервера.

Дополнительные руководства:

• Как установить Wordpress, Nginx, PHP и Varnish на Ubuntu 12.04
• Как настроить кластерный веб-сервер с Varnish и Nginx
• Как настроить Varnish под Drupal c Apache на Debian и Ubuntu

5. Репликация базы данных по схеме ведущий-ведомый (Master-Slave)

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

Пример использования: Дает хорошее увеличение производительности приложения в части чтения из базы данных.

Вот пример репликации базы данных по схеме ведущий-ведомый с одним ведомым узлом:

Плюсы:

• Улучшает производительность чтения из базы данных путем распределения запросов на чтение между ведомыми узлами.
• Может улучшить производительность записи путем использования ведущего узла исключительно для записи (таким образом он не тратит время на обслуживание запросов на чтение)

Минусы:

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

Дополнительные руководства:

• Как оптимизировать производительность Wordpress путем репликации MySQL на Ubuntu 14.04
• Как настроить репликацию MySQL по схеме ведущий-ведомый

Пример: комбинирование концепций

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

Вот примерная диаграмма того, как может выглядеть серверное окружение:

Давайте предположим, что балансировщик нагрузки настроен на распознавание статических запросов (таких как изображения, CSS, JavaScript и т.д.) и отправляет эти запросы к серверам кэширования, а все другие запросы - к серверам приложений.

Вот что будет происходить, когда пользователь отправит запрос на динамический контент:

1. Пользователь запрашивает динамический контент с http://example.com/ (балансировщик нагрузки).
2. Балансировщик нагрузки посылает запрос на сервер приложения (app-backend).
3. Сервер приложения (app-backend) читает из базы и возвращает запрашиваемый контент обратно балансировщику нагрузки.
4. Балансировщик нагрузки возвращает запрашиваемый контент пользователю.

Если пользователь запрашивает статический контент:

1. Балансировщик нагрузки проверяет кэш (cache-backend) на предмет того, закэширован ли запрашиваемый контент.
2. Если закэширован, то запрашиваемый контент возвращается балансирощику нагрузки, переходим в шагу 7. Если не закэширован, то сервер кэширование перенаправит запрос на сервер приложения через балансировщик нагрузки.
3. Балансировщик нагрузки перенаправит запрос на сервер приложения.
4. Сервер приложения (app-backend) читает из базы и возвращает запрашиваемый контент обратно балансировщику нагрузки.
5. Балансировщик нагрузки перенаправляет ответ к серверу кэширования (cache-backend).
6. Сервер кэширования кэширует полученный контент и возвращает его балансировщику нагрузки.
7. Балансировщик нагрузки возвращает запрашиваемый контент пользователю.

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

Заключение

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

Дайте нам знать о любых конфигурациях, которые вы можете порекомендовать или о которых вы хотели бы узнать больше, ниже в комментариях!