Веб-система

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

(Различия между версиями)
Перейти к: навигация, поиск
(Внутренний уровень. apache)
 
(11 промежуточных версий не показаны.)
Строка 5: Строка 5:
'''Веб-система''' [[VirtHost|виртуальной площадки]] хостинга состоит из двухуровневой системы веб-серверов. Внешний уровень принимает запросы из сети, пересылает его на внутренний уровень, читает ответ и отдаёт его в сеть. Такая схема позволяет разгрузить внутренний уровень за счёт его независимости от скорости сегментов сети Интернет и гибко управлять внутренним уровнем системы, распределяя запросы извне к веб-серверам внутреннего уровня с различной, иногда несовместимой между собой, функциональностью.  
'''Веб-система''' [[VirtHost|виртуальной площадки]] хостинга состоит из двухуровневой системы веб-серверов. Внешний уровень принимает запросы из сети, пересылает его на внутренний уровень, читает ответ и отдаёт его в сеть. Такая схема позволяет разгрузить внутренний уровень за счёт его независимости от скорости сегментов сети Интернет и гибко управлять внутренним уровнем системы, распределяя запросы извне к веб-серверам внутреннего уровня с различной, иногда несовместимой между собой, функциональностью.  
-
[[File:Websystem-1.jpg|уровни веб-системы]]
+
[[File:Websystem-1.png|link=|уровни веб-системы]]
=== Внешний уровень. nginx ===
=== Внешний уровень. nginx ===
Строка 28: Строка 28:
Поддерживаются следующие технологии и их версии:
Поддерживаются следующие технологии и их версии:
-
* PHP версий 5.2, 5.3 и 5.4, для версии PHP 5.2 возможен режим с ZendOptimizer, выключенный по умолчанию, на некоторых тарифах для версий 5.3 и 5.4 есть возможность включить кэширование APC, для серверов с PHP также поддерживается и запуск CGI-скриптов;
+
* PHP версий 5.2, 5.3 и 5.4, для версии PHP 5.2 возможен режим с ZendOptimizer, выключенный по умолчанию, на некоторых тарифах для версий 5.3 и 5.4 есть возможность включить кэширование APC, для версий 5.6, 5.6, 7.0, 7.1 и 7.2 есть возможность включить кэширование APCu и OPCache, для версий 5.3, 5.4, 5.5, 5.6, 7.0, 7.1 и 7.2 есть возможность включить модуль ionCube, для серверов с PHP также поддерживается и запуск CGI-скриптов;
-
* WSGI для Python версий 2.5, 2.6, 2.7 и 3.1.  
+
* WSGI для Python версий 2.5, 2.6, 2.7, 3.3, 3.4, 3.5  и 3.6.  
Т.е. если у пользователя хостинга есть сайт на php 5.2 закодированный ZendOptimizer, есть три сайта на php 5.3 и есть тестовый WSGI-сайт на python 2.7, то будет запущено три выделенных apache для обработки вышеперечисленных пяти сайтов аккаунта.
Т.е. если у пользователя хостинга есть сайт на php 5.2 закодированный ZendOptimizer, есть три сайта на php 5.3 и есть тестовый WSGI-сайт на python 2.7, то будет запущено три выделенных apache для обработки вышеперечисленных пяти сайтов аккаунта.
-
[[File:Websystem-001.jpg|веб-система хостинга]]
+
[[File:Websystem-2.png|400px|link=|веб-система хостинга]]
Выполнение скриптов PHP всех версий обеспечивается стандартным модулем php для веб-сервера apache. Для каждой версии PHP на каждом аккаунте запускается свой сервер с модулем для этой версии. Apache запускается в режиме preforked (обработчики - отдельные процессы).
Выполнение скриптов PHP всех версий обеспечивается стандартным модулем php для веб-сервера apache. Для каждой версии PHP на каждом аккаунте запускается свой сервер с модулем для этой версии. Apache запускается в режиме preforked (обработчики - отдельные процессы).
Строка 45: Строка 45:
=== Контроль нагрузки ===
=== Контроль нагрузки ===
-
[[File:Websystem-003.jpg|right|работа очереди]]Запросы из сети к сайту направляются веб-сервером nginx на выделенный аккаунту apache. У веб-сервера apache количество одновременных обработчиков фиксировано. Если все обработчики заняты, то остальные запросы не принимаются и становятся в очередь до истечения предела времени ожидания (задан в [[VirtSpec|спецификации виртуальной площадки]], обычно составляющего 5 минут. По истечению предела времени, веб-сервер nginx выдаёт [[Error502|ошибку 502]] и закрывает соединение. Очередь запросов тоже имеет предел, который составляет 128 запросов на каждый веб-сервер apache. Если очередь заполнена, то новый запрос не принимается, nginx выдаёт [[Error502|ошибку 502]] и закрывает соединение. Так происходит, пока не появляется хотя бы одно свободное место в очереди.  
+
[[File:Websystem-3.png|400px|link=|right|работа очереди]]Запросы из сети к сайту направляются веб-сервером nginx на выделенный аккаунту apache. У веб-сервера apache количество одновременных обработчиков фиксировано. Если все обработчики заняты, то остальные запросы не принимаются и становятся в очередь до истечения предела времени ожидания (задан в [[VirtSpec|спецификации виртуальной площадки]], обычно составляющего 5 минут. По истечению предела времени, веб-сервер nginx выдаёт [[Error502|ошибку 502]] и закрывает соединение. Очередь запросов тоже имеет предел, который составляет 128 запросов на каждый веб-сервер apache. Если очередь заполнена, то новый запрос не принимается, nginx выдаёт [[Error502|ошибку 502]] и закрывает соединение. Так происходит, пока не появляется хотя бы одно свободное место в очереди.  
Такая схема позволяет "размазывать" всплески нагрузки во времени. Всплески могут быть и просто случайными, и результатом индексирования сайта поисковыми системами, и результатом так называемых "слэшдот-эффектов" или "хабра-эффектов" (появление ссылки на сайт на популярном портале), и результатом действий злоумышленников, а также результатом ошибок самого сайта. Количество обработчиков - основной инструмент ограничений на нашем хостинге. Оно подобрано экспериментальным путём так, чтобы выдерживать большую посещаемость даже «тяжёлых» сайтов на основном тарифе хостинга. Сколько на каком тарифе предусмотрено обработчиков можно узнать в  [[VirtSpec|спецификации виртуальной площадки]].
Такая схема позволяет "размазывать" всплески нагрузки во времени. Всплески могут быть и просто случайными, и результатом индексирования сайта поисковыми системами, и результатом так называемых "слэшдот-эффектов" или "хабра-эффектов" (появление ссылки на сайт на популярном портале), и результатом действий злоумышленников, а также результатом ошибок самого сайта. Количество обработчиков - основной инструмент ограничений на нашем хостинге. Оно подобрано экспериментальным путём так, чтобы выдерживать большую посещаемость даже «тяжёлых» сайтов на основном тарифе хостинга. Сколько на каком тарифе предусмотрено обработчиков можно узнать в  [[VirtSpec|спецификации виртуальной площадки]].
-
[[File:Websystem-002.jpg|контроль нагрузки]]
+
[[File:Websystem-4.png|400px|link=|контроль нагрузки]]
Но есть и некоторые особенности (они есть и в классической схеме, но заметить их там сложнее):
Но есть и некоторые особенности (они есть и в классической схеме, но заметить их там сложнее):
Строка 62: Строка 62:
Веб-сервер внешнего уровня nginx в некоторых конфигурациях (рецептах) имеет прямой доступ к данным пользователя. Но он ограничен сайтом пользователя, а на символьные ссылки (специальный вид файлов) установлено ограничение - файл, на который они указывают, должен принадлежать тому же пользователю, что и ссылка. Это не даёт возможности выйти за предел домашнего каталога пользователя.
Веб-сервер внешнего уровня nginx в некоторых конфигурациях (рецептах) имеет прямой доступ к данным пользователя. Но он ограничен сайтом пользователя, а на символьные ссылки (специальный вид файлов) установлено ограничение - файл, на который они указывают, должен принадлежать тому же пользователю, что и ссылка. Это не даёт возможности выйти за предел домашнего каталога пользователя.
-
Каждый веб-сервер внутреннего уровня apache запущен с привилегиями того системного аккаунта, файлы которого он будет обслуживать. Задачи по расписанию cron, скрипты запущенные из консоли [[SSH]] и скрипты сайта - все работают с привилегиями одного системного аккаунта. Это освобождает от необходимости специальных дополнительных настроек, например, запуска CGI через модуль suexec или найстройки open_basedir в php. Не требуется никаких дополнительных специальных действий с правами доступа к файлам, часто упоминаемые в документации к программированию сайтов.
+
Каждый веб-сервер внутреннего уровня apache запущен с привилегиями того системного аккаунта, файлы которого он будет обслуживать. Задачи по расписанию cron, скрипты запущенные из консоли [[SSH]] и скрипты сайта - все работают с привилегиями этого же системного аккаунта. Это освобождает от необходимости специальных дополнительных настроек, например, запуска CGI через модуль suexec или найстройки open_basedir в php. Не требуется никаких дополнительных специальных действий с правами доступа к файлам, часто упоминаемые в документации к программированию сайтов.
Доступ программ (включая скрипты сайта) одного аккаунта к файлам другого аккаунта невозможен. Ограничения реализованы стандартными средствами операционной системы.  
Доступ программ (включая скрипты сайта) одного аккаунта к файлам другого аккаунта невозможен. Ограничения реализованы стандартными средствами операционной системы.  

Текущая версия на 22:27, 27 января 2018

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

уровни веб-системы

Содержание

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

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

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

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

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

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

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

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

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

  • PHP версий 5.2, 5.3 и 5.4, для версии PHP 5.2 возможен режим с ZendOptimizer, выключенный по умолчанию, на некоторых тарифах для версий 5.3 и 5.4 есть возможность включить кэширование APC, для версий 5.6, 5.6, 7.0, 7.1 и 7.2 есть возможность включить кэширование APCu и OPCache, для версий 5.3, 5.4, 5.5, 5.6, 7.0, 7.1 и 7.2 есть возможность включить модуль ionCube, для серверов с PHP также поддерживается и запуск CGI-скриптов;
  • WSGI для Python версий 2.5, 2.6, 2.7, 3.3, 3.4, 3.5 и 3.6.

Т.е. если у пользователя хостинга есть сайт на 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 выдаёт ошибку 502 и закрывает соединение. Очередь запросов тоже имеет предел, который составляет 128 запросов на каждый веб-сервер apache. Если очередь заполнена, то новый запрос не принимается, nginx выдаёт ошибку 502 и закрывает соединение. Так происходит, пока не появляется хотя бы одно свободное место в очереди.

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

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

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

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

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

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

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

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

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

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

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

Категория:

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