Веб-система

Материал из DiPHOST.Ru wiki system

Перейти к: навигация, поиск

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

Содержание

Внешний уровень. nginx

Для внешнего уровня веб-системы выбран веб-сервер nginx. Веб-сервер nginx очень производительный, не требовательный к ресурсам и позволяет создавать гибкие конфигурации, хотя и не обладает возможностью исполнять скрипты на php, perl, python и прочих языках.

На внешнем уровне выполняются следующие задачи:

  • приём запросов по протоколу HTTP из сети;
  • приём запросов по протоколу HTTPS из сети, обеспечение установки SSL-соединения;
  • борьба с DDoS, обработка аварийных ситуаций;
  • выбор сервера внутреннего уровня;
  • передача пришедших запросов на внутренний уровень без кеширования (т.е. передаются абсолютно все запросы) по протоколу HTTP;
  • чтение ответов и передача их без кеширования (т.е. всегда отдаётся ответ внутреннего уровня, не сохраняется никаких копий) в сеть.

Для каждого сайта создаётся отдельная конфигурация в nginx, что позволяет направлять запросы из сети к выделенному вплоть до сайта веб-серверу внутреннего уровня. Также предусмотрена возможность применять уникальные конфигурации для каждого сайта по запросу в службу поддержки. Возможность создавать уникальные конфигурации позволяет обеспечивать SSL-доступ к сайтам.

Внутренний уровень. apache

Для внутреннего уровня веб-системы выбран веб-сервер apache. Веб-сервер apache является самым популярным в мире веб-сервером, обслуживающим сайты. К нему существует множество расширений, позволяющих исполнять программы на различных языках программирования, применять различные технологии для создания содержимого сайтов. Некоторые из предоставляемых технологий (например, приложения на языке Python) не хуже, а иногда возможно и лучше, предоставлялись бы с использованием иных веб-серверов. Но мы выбрали apache, ввиду стандартности конфигурирования и возможности частично конфигурировать его пользователем самостоятельно через файл .htaccess.

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

Поддерживаются следующие технологии и их версии:

  • PHP версий 5.2 и 5.3, для версии PHP 5.2 возможен режим с ZendOptimizer, выключенный по умолчанию, для серверов с PHP также поддерживается и запуск CGI-скриптов;
  • WSGI для Python версий 2.5, 2.6, 2.7 и 3.1.

Т.е. если у пользователя хостинга есть сайт на php 5.2 закодированный ZendOptimizer, есть три сайта на php 5.3 и есть тестовый WSGI-сайт на python 2.7, то будет запущено три выделенных apache для обработки вышеперечисленных пяти сайтов аккаунта.

Выполнение скриптов PHP всех версий обеспечивается стандартным модулем php для веб-сервера apache. Для каждой версии PHP на каждом аккаунте запускается свой сервер с модулем для этой версии. Apache запускается в режиме preforked (обработчики - отдельные процессы).

Выполнение CGI-программ обеспечивается только веб-серверам, настроенными для работы с PHP (при этом CGI-программы могут быть на любом другом поддерживаемом языке).

Работа приложений на языке Python обеспечивается модулем mod_wsgi для веб-сервера apache в режиме "демона". Для каждой версии Python на каждом аккаунте запускается свой сервер с модулем для этой версии. Apache запускается в режиме worker (обработчик - один процесс и множество тредов), поскольку обработка приложений осуществляется отдельными процессами. Ограничения в спецификации относятся к обработчикам приложения, а не к самому веб-серверу apache.

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

Контроль нагрузки

Запросы из сети к сайту направляются веб-сервером nginx на выделенный аккаунту apache. У веб-сервера apache количество одновременных обработчиков фиксировано. Если все обработчики заняты, то остальные запросы не принимаются и становятся в очередь до истечения предела времени ожидания (задан в спецификации виртуальной площадки, обычно составляющего 5 минут. По истечению предела времени, веб-сервер nginx выдаёт ошибку 504 и закрывает соединение. Очередь запросов тоже имеет предел, который составляет 50 запросов на каждый веб-сервер apache. Если очередь заполнена, то новый запрос не принимается, nginx выдаёт ошибку 502 и закрывает соединение. Так происходит, пока не появляется хотя бы одно свободное место в очереди.

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

Но есть и некоторые особенности (они есть и в классической схеме, но заметить их там сложнее):

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

В данной схеме ограничений слово "сайт" не имеет технического смысла и служит для удобства. Ограничения по количеству сайтов в тарифах оставлены только в маркетинговых целях.

Безопасность

Веб-сервер внешнего уровня nginx не имеет прямого доступа к данным пользователя. Его работа изолирована от соответственно безопасна.

Каждый веб-сервер внутреннего уровня apache запущен с привилегиями того системного аккаунта, файлы которого он будет обслуживать. Задачи по расписанию cron, скрипты запущенные из консоли SSH и скрипты сайта - все работают с привилегиями одного системного аккаунта. Это освобождает от необходимости специальных дополнительных настроек, например, запуска CGI через модуль suexec или найстройки open_basedir в php. Не требуется никаких дополнительных специальных действий с правами доступа к файлам, часто упоминаемые в документации к программированию сайтов.

Доступ программ одного аккаунта к файлам другого аккаунта невозможен. Ограничения реализованы стандартными средствами операционной системы.

Аккаунты могут обменяться файлами только через внешнее хранилище, с помощью FTP или SSH как если бы они были на разных серверах, или через каталог /tmp/ файловой системы, в который разрешён доступ на запись всем (не рекомендуется).

Источник — «https://wiki.diphost.ru/WebSystem»

Категория:

Личные инструменты
© 2006 — ООО «Дремучий лес»
Служба техподдержки: support@diphost.ru
Тексты этого сайта являются полностью оригинальными
или оригинальными компиляциями ООО «Дремучий Лес».
Распространяются по лицензии WTFPL
Отзывы о хостинге diphost.ru Отзывы на hostobzor.ru